Phase 4: Incident Management

Incident lifecycle: detection, triage, mitigation & resolution

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're building the most amazing, giant LEGO castle you can think of. It has tall towers, strong walls, and secret passages – it’s super fun to play with! But even the best LEGO castles can have problems. Maybe a tower starts wobbling, or a crucial brick falls off. In the world of computers, we call these problems "incidents," and we have a special plan, an "incident lifecycle," for how to deal with them to keep everything working smoothly.

First, we need to detect problems. How do you know if your LEGO tower is leaning before it falls down and crashes? Maybe you have a special little sensor brick that blinks red if the tower starts to wiggle too much. Or, maybe your friend playing with you points out, "Hey, a piece just fell off the main gate!" This is like a computer program constantly watching itself for trouble. It’s like having tiny robots looking for loose bricks so you know something’s wrong right away, even before the whole castle starts to crumble.

Once an alert blinks or your friend shouts, the next step is triage. You rush over to the castle. Is it just one tiny decoration piece that fell off, or is the entire drawbridge about to collapse? Is the dragon's perch wobbling dangerously, or just a small flag missing from a turret? You quickly figure out how bad the problem is, which part of the castle is affected, and if it’s stopping anyone from playing. This helps you decide if it’s a small fix you can do later, or something you need to drop everything and work on immediately to save your magnificent castle.

After understanding the problem, you move to mitigation and resolution. If the drawbridge is about to fall, you might quickly prop it up with a big, strong brick just to stop it from crashing right now – that’s mitigation, a quick fix to stop things getting worse. Then, for resolution, you properly rebuild the drawbridge, making it even stronger than before. You might add extra supports or use different, more secure bricks. You also think: "Why did it fall in the first place? Was it a weak design? Did someone accidentally bump it?" By understanding the 'why', you can prevent the same problem from happening again, making your castle even more reliable for future play.

So, when you learn to build your own amazing computer programs and websites, knowing these steps means you can design them to be super strong and resilient. You’ll be ready to quickly spot, understand, and fix any problems that pop up, keeping your creations fun and functional for everyone who uses them!

The incident lifecycle for an SRE is a structured approach to managing unexpected disruptions, ensuring system reliability and user satisfaction. It begins with detection, where issues are identified, typically through automated monitoring and alerting systems, or sometimes via direct user reports. As SREs, you'll configure tools like Prometheus or Datadog to watch key metrics (e.g., latency, error rates, resource utilization) and trigger alerts when predefined thresholds are breached. Robust detection mechanisms are your early warning system, designed to surface problems before they significantly impact users.

Once an alert fires, the next critical step is triage. This phase involves quickly assessing the scope, impact, and severity of the incident. An SRE on-call will analyze dashboards, logs, and recent changes to answer questions like: What service is affected? How many users are impacted? Is this a complete outage or degraded performance? What's the potential business impact? Based on this assessment, the incident is prioritized, an owner is assigned, and relevant stakeholders are notified. The goal of triage is to understand "what's wrong and how bad is it?" to inform the next steps.

Following triage, the focus shifts to mitigation. This is the urgent act of "stopping the bleeding" and restoring service functionality or reducing user impact as rapidly as possible. Mitigation strategies are often tactical and might include rolling back a recent deployment, restarting affected services, failing over to a healthy replica, or scaling up resources. The key here is speed; a permanent fix is secondary. Once the immediate crisis is contained and service is restored, the final phase is resolution. This involves a thorough investigation to identify the root cause, implementing a long-term, permanent fix (e.g., a code patch, infrastructure update), and then rigorously verifying that the issue is fully resolved and unlikely to recur. This entire cycle, from detection to resolution, often feeds into post-incident reviews and continuous improvement, strengthening the system against future incidents.

Key Takeaways

  • Robust monitoring and alerting are essential for early incident detection.
  • Triage quickly assesses incident scope, impact, and severity to prioritize and assign.
  • Mitigation focuses on rapid service restoration, even with temporary solutions.
  • Resolution involves implementing permanent fixes and verifying their effectiveness.
  • The lifecycle is iterative, driving continuous system improvement.

Code Example

yaml
# Prometheus alert rule example for detection
groups:
- name: service_alerts
  rules:
  - alert: HighServiceErrorRate
    expr: sum(rate(http_requests_total{job="my-api", status_code=~"5xx"}[5m])) / sum(rate(http_requests_total{job="my-api"}[5m])) * 100 > 5
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "High 5xx error rate detected on my-api"
      description: "The 5xx error rate for my-api is above 5% for more than 2 minutes. Investigate immediately."

How this code works

This Prometheus alert rule (HighServiceErrorRate) defines an automated detection mechanism for a web service named my-api. Its job is to detect when the service is experiencing a high percentage of server-side errors (5xx status codes), thereby triggering the "detection" phase of the incident lifecycle.

The expr line calculates the percentage of 5xx errors out of all requests to my-api over a 5-minute window. It uses the rate function to track the per-second increase in the http_requests_total counter for both 5xx errors (status_code=~"5xx") and total requests, then converts this ratio to a percentage. If this percentage exceeds 5%, the alert condition is met. A subtle but critical detail is for: 2m, which means the error rate must remain above 5% for two continuous minutes before the alert actually fires. This prevents transient network glitches or brief spikes from generating unnecessary alerts. Finally, labels like severity categorize the alert, and annotations provide a human-readable summary and description to aid responders in quickly understanding the problem.