46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# Incident Response and Stabilization
|
|
|
|
## Purpose
|
|
|
|
Guide high-pressure response to live or high-impact issues by separating immediate stabilization from deeper root-cause correction.
|
|
|
|
## When to use
|
|
|
|
- A production issue is actively impacting users or operators
|
|
- A regression needs containment before a complete fix is ready
|
|
- The team needs a calm sequence for triage, mitigation, and follow-up
|
|
- Communication and operational clarity matter as much as code changes
|
|
|
|
## Inputs to gather
|
|
|
|
- Current symptoms, severity, affected users, and timing
|
|
- Available logs, metrics, alerts, dashboards, and recent changes
|
|
- Safe rollback, feature flag, degrade, or traffic-shaping options
|
|
- Stakeholders who need updates and what they need to know
|
|
|
|
## How to work
|
|
|
|
- Stabilize user impact first if a safe containment path exists.
|
|
- Keep mitigation, diagnosis, and communication distinct but coordinated.
|
|
- Prefer reversible steps under uncertainty.
|
|
- Record what is confirmed versus assumed while the incident is active.
|
|
- After stabilization, convert the incident into structured debugging and prevention work.
|
|
|
|
## Output expectations
|
|
|
|
- Stabilization plan or incident response summary
|
|
- Clear mitigation status and next actions
|
|
- Follow-up work for root cause, observability, and prevention
|
|
|
|
## Quality checklist
|
|
|
|
- User impact reduction is prioritized appropriately.
|
|
- Risky irreversible changes are avoided under pressure.
|
|
- Communication is clear enough for collaborators to act.
|
|
- Post-incident follow-up is not lost after immediate recovery.
|
|
|
|
## Handoff notes
|
|
|
|
- Note what was mitigated versus actually fixed.
|
|
- Pair with debugging workflow and observability once the system is stable enough for deeper work.
|