Planning on GeekyRyan

Building an Operational Strategy for Understanding and Responding to Alerts

Thu, 05 Sep 2024 09:00:00 +0000

You can have all the alerts configured you want, but if the team doesn’t agree on what they mean, who’s responsible for them, and what a good response looks like, they’re just noise. This was about building that operational strategy - making sure every alert had a clear owner, a documented playbook, and an agreed severity/escalation path.

It’s the human side of alerting, not the technical side. Once you’ve got the right metrics feeding into alerts, you need the operational discipline to make sure those alerts actually get owned and responded to consistently, whoever’s on call.

Developing a Plan for SLA Reporting and Shipping Version 1

Thu, 05 Sep 2024 09:00:00 +0000

SLAs don’t mean much if you can’t actually measure and report on them. This project was about figuring out what metrics mattered for our SLA commitments, finding where that data lives, and building a v1 reporting system so stakeholders could see how we were actually tracking.

I wasn’t trying to solve everything on day one - just get a credible baseline in front of people and iterate from there. That’s usually the right approach for reporting work anyway.

Developing and Documenting a Disaster Recovery Plan

Wed, 28 Aug 2024 09:00:00 +0000

DR plans usually exist in people’s heads until you actually need one - at which point tribal knowledge doesn’t cut it. Time to actually write one down.

Turn the ad hoc recovery knowledge into a structured plan: recovery point/time objectives, failover procedures, who does what during an incident. A document so someone who wasn’t in the room when the environment was built can still execute a recovery under pressure.

The plan becomes the runbook you actually use during the DR exercises, so it pays for itself immediately.