4 ms·
In my experience: 1) Make a goal: we should get paged for at most N incidents per week. That goal should be closer to 0 than 10 IMO. 2) Track stats on th
by throwaway210620 5y ago
In my experience:
1) Make a goal: we should get paged for at most N incidents per week. That goal should be closer to 0 than 10 IMO.
2) Track stats on this goal, both in aggregate and broken down by cases you think you can address separately. Example: tickets from alarms vs tickets filed by people. Alarms having to do with external dependencies vs alarms caused by your own bugs. Don't just make this a "it seems like we've had fewer pages lately" thing. Real numbers.
3) Review these stats on a graph every week. Someone should have an explanation of why they have spiked, why they haven't dropped, the breakdown of problem type, etc. There should be congratulations when they drop and a request for plans when they don't.
4) have management that can communicate upwards to leadership that ops improvement is a priority for your team and that you ultimately won't be able to continue other feature development if you are always mired in ops pain and people are either busy with mundanity or driven to leave the team.
5) dedicate time in each sprint to working on the most recent identified target from plans made in #3.
This isn't particularly complicated, and typing it out almost sounds like I'm giving you worthless common sense advice, but I think the key here is that multiple levels of your organization need to commit to making this important enough to spend time reviewing it, agree it is a priority, and put actual dedicated dev work into it.
edit: formatted so indented list is readable on mobile. I have no idea how to do this without a code block. HN, please make this easier :)