O+M 2024-08-26

[FuhuXia]

As part of day-to-day operation of Data.gov, there are many Operation and Maintenance (O&M) responsibilities. Instead of having the entire team watching notifications and risking some notifications slipping through the cracks, we have created an O&M Triage role. One person on the team is assigned the Triage role which rotates each sprint. This is not meant to be a 24/7 responsibility, only East Coast business hours. If you are unavailable, please note when you will be unavailable in Slack and ask for someone to take on the role for that time.

Check the O&M Rotation Schedule for future planning.

Acceptance criteria

You are responsible for all O&M responsibilities this week. We've highlighted a few so they're not forgotten. You can copy each checklist into your daily report.

Daily Checklist

• [ ] Check Production State/Actions

  Note: Catalog Auto Tasks You will need to update the chart values manually. Click the Action link in each issue and grab the values from monitor task output and check runtime.

• [ ] Check auto generated O&M tickets from no status column
• [ ] Check Harvesting Emails
• [x] New Relic Alerts Triaged
• [ ] Triage DMARC Report from Google

Weekly Checklist

• [ ] DB-Solr Sync
• [x] Audit Log (more info on AU-3 and AU-6 Log auditing)
• [x] Tracking Update
  • NOTE: This job will consistently timeout, but it is processing results ((more details)[https://github.com/GSA/data.gov/issues/4345])
• [ ] Check Catalog Solr
• [x] Catalog Dupe Check
• [ ] Check user management requests
• [x] Check Snyk Dashboard and cleanup

Monthly Checklist

• [ ] Invicti Scan

ad-hoc checklist

• [ ] audit/review applications on cloud foundry and determine what can be stopped and/or deleted.

Reference

• Watch for user email requests
• Watch in #datagov-alerts and Vulnerable dependency notifications (daily email reports) for critical alerts.
• Monitor and improve Data.gov O&M Dashboard
• Update and revise Data.gov O&M Tasks

[FuhuXia]

catalog-gather and catalog-fetch in staging are stuck, no deployment can go thru.

catalog-fetch          started           web:0/0, web:0/0   
catalog-gather         started           web:0/0, web:0/0   

[FuhuXia]

Deleted staging catalog-gather and catalog-fetch. Deployment is fine now.

[FuhuXia]

After deployment, catalog-gather and catalog-fetch are back to stuck state web:0/0, web:0/0.

[FuhuXia]

setting instance 1 (instead of 0) for catalog-gather and catalog-fetch is the workaround. https://github.com/GSA/catalog.data.gov/pull/1439

[FuhuXia]

set IMLS to manual schedule and marked it as a broken source, since there is no response to our request to unblock harvesting traffic. https://github.com/GSA/data.gov/issues/4799#issuecomment-2187000549

[FuhuXia]

monthly harvest ioos with 30k+ records just refreshed all its timestamps to 2024-08-25 in source https://data.noaa.gov/waf/NOAA/ioos/iso/xml/ .

Sent 33790 objects to the fetch queue

UPDATE: It finished after 3+ days. The scary part is that it appears the timestamp changes are mpstly legit due to file content change, not simple refreshing.

Some (1127 to be exact, 3.5% ) are caught as simple file refreshing, for exchange this one https://data.noaa.gov/waf/NOAA/ioos/iso/xml/world_equator.xml, timestamped 2024-08-25 but <gmd:dateStamp> 2021-03-30

[rshewitt]

apparently i don't have edit access to the audit log. ooooooooooof. can someone grant me that?

[FuhuXia]

apparently i don't have edit access to the audit log. ooooooooooof. can someone grant me that?

Done.