​
Incident Response — Xử lý sự cố production

Quy trình xử lý sự cố production có hệ thống: emergency triage, coordination, root cause analysis, postmortem.

​
Cú pháp

/incident-response                 # Bắt đầu quy trình xử lý sự cố

​
Luồng hoạt động

1

Bước 1: Triage

Đánh giá severity (P1-P4), impact scope, affected services.
  • P1: Service down, data loss — tất cả hands on deck
  • P2: Major feature broken — team lead + on-call
  • P3: Minor degradation — on-call engineer
  • P4: Cosmetic issue — normal sprint
2

Bước 2: Coordinate

Phân công roles: Incident Commander, Tech Lead, Communicator. Tạo war room (Lark group/thread).
3

Bước 3: Mitigate

Ưu tiên giảm impact trước, fix root cause sau. Options: rollback, feature flag off, scale up, hotfix.
4

Bước 4: Root Cause Analysis

Sau khi mitigate xong → tìm root cause. Dùng 5-Whys hoặc fault tree analysis.
5

Bước 5: Postmortem

Viết postmortem report: timeline, root cause, action items. Blameless — focus vào process, không blame người.

​
Severity Levels

LevelResponse TimeWhoExample
P1 — Critical< 15 minAll handsService down, data breach
P2 — Major< 1 hourTeam lead + on-callPayment broken, auth fail
P3 — Minor< 4 hoursOn-callSlow queries, minor UI bug
P4 — LowNext sprintAssigneeCosmetic, non-blocking

​
Ví dụ thực tế

INCIDENT REPORT
├── Severity: P2
├── Impact: Payment processing failed for 12% of users
├── Duration: 45 minutes (12:30 - 13:15)
├── Root Cause: Redis connection pool exhausted 
│   after config change reduced max from 50 → 5
├── Mitigation: Reverted config change
├── Action Items:
│   ├── [ ] Add connection pool monitoring alert
│   ├── [ ] Config change requires 2 approvals
│   └── [ ] Add integration test for Redis pool
└── Postmortem: Scheduled for 2026-04-08

​
Khi nào dùng / không dùng

DùngKhông dùng
Production incident đang xảy raBug trên staging (dùng /fix)
Cần structured response processIssue đã biết, đang fix theo sprint
Viết postmortem sau incidentRegular retrospective (dùng /retro)