Incident Management: Operational Resilience

Incident Management is the process used by DevOps and SRE teams to respond to unplanned events or service interruptions and restore service as quickly as possible. In a high-maturity SRE organization, this isn't just about "fixing the bug"—it's about forensic precision and systemic immunity.

1. Incident Lifecycle and Severities

Every incident must be categorized to dictate the response level:


2. The 'Golden Hour' Forensics

In SRE, the Golden Hour refers to the first 60 minutes of a major incident. Actions taken here determine the Mean Time to Recovery (MTTR) and the quality of the subsequent Root Cause Analysis (RCA).

A. Non-Destructive Mitigation

The primary goal is restoration, but the secondary goal is Preservation.

B. Forensic Data Capture Checklist

Before applying a patch or restarting, capture the following state:

  1. Thread Dumps & Heap Dumps: For JVM/Go/Node processes, capture the state of concurrency and memory.
  2. Kernel/Network State: Use ss -atp (socket state), dmesg, and conntrack tables to identify network saturation or resource leaks.
  3. eBPF Probes: Use tools like bpftrace to capture syscall latency or file I/O spikes that metrics might aggregate away.
  4. Log Snapshot: Tail and preserve the last 10,000 lines of application and system logs before they are rotated or lost.

3. The Response Role: Incident Commander (IC)

The IC is the single source of truth during a SEV-1. They do not write code; they manage the Flow of Information.

4. The PACE Communication Plan

Relying on one channel is an operational risk.


5. Root Cause Analysis (RCA) Patterns

A "Blameless" culture is the prerequisite for effective RCA. We move from "Who did it?" to "Why did the system allow this?".

A. The Five Whys (Systemic Depth)

B. RCA Methodology: The Three Perspectives

  1. Proximate Cause: The immediate trigger (e.g., a deployment, a configuration change, a spike in external traffic).
  2. Underlying Cause: The vulnerability that made the trigger catastrophic (e.g., missing retry limits, lack of timeout on a dependency).
  3. Systemic Cause: The organizational or architectural debt that allowed the vulnerability to exist (e.g., lack of automated integration testing for failure modes).

C. Common RCA Anti-Patterns to Avoid


6. Closing the Loop: Action Items

Every post-mortem must result in prioritized tickets.


See Also: