The "Broken Part" Obsession
Think about how a car mechanic works. When a car breaks down, they look for the broken part — the worn brake pad, the cracked hose, the dead battery. Fix the broken part, and the car is "safe" again. This is intuitive, and for simple mechanical systems, it works well.
We apply the same instinct to software systems. When something goes wrong, we ask:
- "Why did the server crash?"
- "Why did the database lock up?"
- "How do we prevent this specific bug from recurring?"
This approach assumes that safety is simply the absence of failure. Eliminate all the errors, and you will be safe.
The Problem with Safety I
This traditional view is called Safety I. It works reasonably well for simple, predictable systems. But complex software systems are not simple or predictable — and crucially, failures in them are rare.
If your system has 99.9% uptime, the Safety I lens only examines the 0.1% of the timeline when things went wrong. It completely ignores the 99.9% of the time when things went right — often despite incomplete runbooks, ambiguous alerts, undertrained staff, and infrastructure held together with duct tape and tribal knowledge.
Safety II is a paradigm shift developed by resilience engineering researcher Erik Hollnagel. It argues that to truly understand safety, you must understand why things go right despite the constant chaos, stress, and unpredictability of the real world. The question is not just "what broke?" but "how does anything ever work at all?"
Interviewers at companies with mature SRE practices sometimes ask: "How do you learn from incidents that didn't cause an outage?" The Safety II answer is that near-misses and successful recoveries contain just as much signal as failures — often more, because they reveal the adaptive capacity of your team. Saying "we only do post-mortems on outages" signals a Safety I mindset.