Ozymandias on rails, cartography of a ruin
Nice pointers for working with legacy:
What do we measure and alert on then? The Google SRE Workbook gives a mechanism for this: instead of alerting on “CPU > 80%” or “queue depth over 1000,” you define a service level objective like “checkout succeeds within four seconds, 99.9% of the time.” That 0.1% gap between perfection and your target is your error budget, the amount of failure you’ve decided is acceptable over a rolling window.
I kept hearing problems that never made it into a ticket or a dashboard. Friction they’d accepted as permanent, patterns they didn’t know other teams were also hitting, pain they assumed nobody could fix. That listening gave me two things: insight into what was hurting, and the ability to convince people to work with me on fixing it.
The temptation here, especially with engineers, is to create rows that are focused on solutions rather than problems. Think cart before horse here. Things like adopting Packwerk and adding types are solutions. Reducing latency is also a solution, right up until you can connect it to tangible pain the business feels. Name the pain, and drive from there. A quote I heard forever ago is that you earn substantially more curing pain than you do suggesting supplements.