← Feed
@laird@hachyderm.io
2025-10-21 18:41 UTC
Watching all of the random things that people have been saying about AWS's #outage yesterday reminded me of a discussion that I had with one of my teams while working at Google.
We were doing longer-term planning, and people were proposing multi-year goals. One (moderately senior) teammate wanted a goal of roughly "MTTR decreases X% per quarter".
So, that sounds nice in theory but it's not how mature services really work. As you fix the easy bugs, you get fewer and fewer trivial outages. "Admin typed dumb thing" mostly goes away with better checking and deployment policies. "Partial backend failure caused cascading failure" is mostly handled by avoiding patterns that cause cascading failures, and then dealing with partial failures as best as they can be handled. "Trivially bad software release broke things" gets handled by improved testing and canarying over time.
Unfortunately, once you get rid of the easy outages, you're left with *weird* stuff. I/O patterns that trigger latent firmware bugs in SSDs, causing accelerated failure fleet-wide, with a multi-year lead time on replacements. Datacenter fires. Natural disasters. CPU bugs. ROMs that get overwritten by excessive reading. Software bugs that cut across 4 or more services and somehow manage to find decade-old fatal flaws. Overloading some resource *that no one knew existed* (per-second-level domain HTTP cookie jar size, undocumented stateless router hardware state limits). Or (one of my favorites) BGP stops converging correctly because several racks were too heavy and their plastic wheels had cracked (yes, really!).
The sorts of things that you *can't* fix fast, because no one even has a good model for what is happening, and none of the usual quick fixes (roll back, drain, loadshed, etc) are helpful.
In this specific service's case, we weren't *quite* to the maturity level where I expected MTTR to start rising, but we were getting close. And, frankly, we didn't track MTTR very closely anyway.
Reading takes on AWS's outage like "when we had our own datacenters, we never had long outages without any ETA for recovery" mostly just means that you never had any of the really *fun* problems.
Remember, the reward for a job well-done is a new, harder job.
Replies (5)
-
And yes, I've seen outages (or near-outages) that involved every one of those problems.
Open ##2030014
-
@laird one additional but of when we had our own data center, we can get timely updates and direct access to the broken system.
If nothing else, someone is rolling out the crash cart and plugging into a port on the machine.
Open ##2030015
-
@laird
"...the reward for a job well-done is a new, harder job."
This is what I live for.
Open ##2030017
-
@laird The CDC and NTSB could both tell you all about hunting the long tail.
Open ##2030018
-
@laird@hachyderm.io While it's fun to point and laugh at AWS and the massive failure, the truth is that if folks were doing their own hosting instead then on average their failure rate would go up. OTOH the blast radius for failure would be a lot smaller, so for *users* it might be better.
Open ##4409522