tezvyn:

Resilience Engineering: Studying Success, Not Just Failure

AI-drafted, machine-checkedSource: Wikipedia: Resilience engineeringadvanced

Resilience Engineering studies how systems succeed despite surprises, not just why they fail. It applies to incident analysis and chaos engineering, focusing on building adaptive capacity for unknown events rather than just preventing known failure modes.

WHY IT EXISTS Complex systems have countless failure modes, many impossible to predict. Trying to prevent every possible failure is a losing game. Resilience Engineering was created to shift the focus from preventing all errors to building systems that can adapt, survive, and learn from unexpected events.

THE MENTAL MODEL Think of it as studying a system's immune response, not just individual diseases. Instead of creating a specific vaccine for every known virus (preventing known failures), you study how the immune system mounts a general defense against novel pathogens. Resilience Engineering studies how the combination of people and software adapts under pressure, focusing on how things go right even in the face of constant partial failure.

HOW IT WORKS Resilience Engineering is a perspective, not a specific tool. It manifests in practices that examine the gap between "work-as-imagined" (the design docs) and "work-as-done" (how engineers actually keep the system running). This involves deep, non-blameful incident analysis that uncovers the successful adaptations people made during a crisis. It also informs proactive work like chaos engineering, which tests the system's adaptive capacity by injecting surprising failures.

WHEN TO USE IT This mindset is crucial for any complex, distributed system where failure is inevitable. Use it to guide your post-incident reviews (moving from "root cause" to "contributing factors"), to justify investments in observability (seeing how the system is adapting), and when designing systems that need to degrade gracefully rather than collapsing entirely.

WHEN NOT TO USE IT It's less applicable to simple, predictable systems where all failure modes are known and can be exhaustively tested, like a simple command-line utility with no external dependencies. Applying this level of deep systemic analysis to a trivial system is overkill; traditional testing and hardening are sufficient.

ONE CANONICAL EXAMPLE A classic example is the move from "Root Cause Analysis" (RCA) to blame-free post-mortems. An RCA seeks a single, preventable cause, which is often an illusion in complex systems. A resilience-informed analysis, however, looks for multiple contributing factors and, more importantly, identifies the adaptive actions operators took that prevented a much worse outcome. It asks "How were we able to recover?" not just "Why did we fail?".

Read the original → en.wikipedia.org

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.