Postmortem tồi thường là document Word 10 trang mà không đổi được một dòng code hay một alert. Một pattern hay gặp: viết postmortem mô tả chi tiết incident, phân tích root cause, liệt kê action items đầy tham vọng. Ba tháng sau, cùng loại incident xảy ra lại. Mở postmortem cũ ra xem, 4/5 action items chưa close, alert đề xuất chưa tạo, runbook chưa viết.
Postmortem tốt không phải document dài, nó là quá trình cập nhật mô hình thất bại của hệ thống: team đã tin điều gì là đúng, bằng chứng nào cho thấy sai, và thay đổi có thể đo nào giảm xác suất tái diễn. Keyword là “có thể đo”, nếu action item không có verification criteria, nó sẽ nằm trong backlog mãi mãi.
Timeline: kể câu chuyện bằng timestamp
Timeline là xương sống của postmortem. Không có timestamp, bạn không học được “vì sao mất 40 phút mới rollback” hay “vì sao alert không fire”.
Timeline theo các mốc quan trọng:
T+0, SLO breach bắt đầu. Error rate vượt ngưỡng, latency spike, hoặc user report. Ghi metric cụ thể: “5xx rate từ 0.1% lên 15%”, không phải “hệ thống có vấn đề”.
Phát hiện, ai phát hiện, qua kênh nào. Alert PagerDuty? User email? Internal monitoring dashboard? Khoảng cách giữa T+0 và phát hiện là time to detect (TTD), metric quan trọng nhất để cải thiện.
Mitigate, hành động giảm impact. Rollback deploy, scale out, bật kill-switch, traffic shed. Ghi rõ ai quyết định, quyết định dựa trên gì.
Khôi phục, SLO xanh trở lại. Error rate về baseline, latency bình thường. Timestamp này xác định time to mitigate (TTM).
Ví dụ timeline:
14:32 5xx rate spike lên 15% (SLO breach)
14:34 PagerDuty alert, on-call ack
14:38 Xác định deploy v2.3.1 là nghi phạm (commit diff)
14:42 Rollback v2.3.0 hoàn tất
14:48 5xx rate về 0.2% (SLO phục hồi)
14:55 Comms nội bộ + status page update
Mỗi mốc giờ là cơ hội học, “vì sao từ ack đến xác định mất 4 phút?”, “rollback mất 4 phút vì pipeline chậm hay vì không có runbook?”.
Contributing factors thay vì “root cause thần thánh”
Hầu hết incident không có một root cause duy nhất, chúng là chuỗi điều kiện hội tụ. Deploy có bug + cache stale che giấu bug 2 giờ + alert threshold quá cao nên không fire + on-call mệt sau 3 incident liên tiếp nên phản ứng chậm.
Liệt kê nhiều contributing factors có trọng số thay vì tìm “một kẻ nhận lỗi”. Cách này có hai lợi ích: tránh blame (không phải “anh A deploy sai”) và bắt được nhiều điểm cải thiện hơn.
Ví dụ cho incident deploy bug:
Factor 1 (primary): Code bug, missing null check cho field optional mới thêm. Test coverage cho field này = 0.
Factor 2: Alert threshold 5xx rate set 20% (quá cao cho service có SLO 99.9%). Bug gây 15% 5xx → dưới threshold → alert không fire.
Factor 3: Staging test không cover data pattern production, staging không có user với field optional = null.
Factor 4: Rollback mất 4 phút vì pipeline phải build lại, không có pre-built rollback artifact.
Mỗi factor dẫn đến action item khác nhau, fix bug, hạ alert threshold, cải thiện staging data, pre-build rollback artifact.
Mitigation theo ba lớp
Action items mà chỉ có “prevent” (fix bug, thêm test) là thiếu. Hệ thống luôn có bug mới, bạn cần detect sớm và recover nhanh.
Prevent, giảm xác suất xảy ra. Fix bug, thêm constraint, regression test, code review cho change type này.
Detect, phát hiện sớm hơn. Hạ alert threshold, thêm synthetic check (probe gọi API định kỳ verify response), dashboard cho metric liên quan.
Recover, giảm thời gian phục hồi. Runbook rollback rõ ràng, drill database restore, pre-build rollback artifact, feature flag kill-switch.
Mỗi incident nên có ít nhất một action ở mỗi lớp. Nếu chỉ prevent thì lần sau bug khác xảy ra, bạn vẫn detect chậm và recover chậm.
Blameless vs accountability
Hai khái niệm này hay bị hiểu sai là loại trừ nhau.
Blameless nghĩa là không trừng phạt người báo tin, không tìm “ai sai” để kỷ luật, tập trung vào hệ thống cho phép lỗi xảy ra. Nếu deploy bug dễ dàng lên production, vấn đề là thiếu gate (test, canary, review) chứ không phải người deploy.
Accountability nghĩa là mỗi action item có owner cụ thể, deadline thực tế, và verification. “Team backend cải thiện monitoring” không phải accountability, “Alice tạo alert 5xx > 5% cho /api/orders, due 2 tuần, verify bằng alert fire khi inject error” là accountability.
Blameless không có nghĩa “không ai chịu trách nhiệm đóng ticket”. Nó có nghĩa “chúng ta tập trung vào hệ thống, và mỗi người chịu trách nhiệm phần cải thiện cụ thể”.
Template một trang
Template sau dùng cho mọi postmortem, buộc ngắn gọn, buộc có action đo được:
Impact:
- SLO vi phạm: [metric cụ thể]
- Thời lượng: [phút/giờ]
- Blast radius: [% user, region, tenant]
Timeline: (bullet có giờ, xem section trên)
Contributing factors: (danh sách có trọng số)
What went well:
- [những gì hoạt động tốt, alert fire đúng, team respond nhanh]
What went poorly:
- [những gì cần cải thiện]
Action items:
- [owner] [due] [type: prevent/detect/recover] [description]
- [owner] [due] [type] [description]
Verification:
- [metric/alert nào chứng minh item done]
- [drill nào confirm recovery works]
Action item “đủ nhỏ để ship”, một PR hoặc một ticket có acceptance criteria đo được. “Cải thiện observability” là vô hạn, “tạo alert 5xx > 5% cho endpoint X” là shippable.
Verification: phần hay bị bỏ quên nhất
Sau 30 ngày: action items close chưa? Alert mới có noise không (fire quá nhiều false positive)? Drill rollback có chạy thực tế?
Schedule calendar reminder 30 ngày sau postmortem, review action items status, kiểm tra alert đã tạo có fire đúng không (inject error test). Không verification → postmortem là archive, không phải learning.
Incident tái diễn: pre-mortem
Nếu cùng loại incident lặp lại trong 90 ngày, nên chuyển sang pre-mortem: giả định nó xảy ra lần nữa, vì sao? Câu hỏi này buộc team nhìn vào hệ thống sâu hơn, có phải action items postmortem trước chưa đủ? Có phải incentive structure khiến alert bị tắt (alert noisy quá, không ai own)?
Pre-mortem hiệu quả hơn postmortem lần hai cho cùng bug class, vì nó hỏi “vì sao chúng ta không fix được từ lần trước?” thay vì chỉ “bug gì lần này?”.
Data incident: thêm phần integrity
Nếu incident gây sai lệch dữ liệu, không chỉ downtime mà data thực sự sai, postmortem cần thêm phần integrity: phạm vi row ảnh hưởng, cách backfill hoặc reconcile, và communication tới khách hàng nếu cần.
“Đã fix bug” không đủ, phải trả lời “dữ liệu sai đã được sửa chưa, bằng cách nào, verify bằng gì?”.
Customer impact và severity
Postmortem nên gắn severity đã dùng lúc incident (P1-P4) để sau này so sánh trend. Phần customer impact ghi rõ: thời lượng downtime, error rate peak, vùng ảnh hưởng (region, tenant), data có bị sai không.
Không ghi customer impact → tổ chức không biết đầu tư vào đâu. P1 incident 30 phút ảnh hưởng 100% user khác hoàn toàn P3 incident 2 giờ ảnh hưởng 0.1% user, nhưng nếu không ghi rõ, cả hai trông giống nhau trong dashboard.
Sau incident nghiêm trọng, khách hàng đọc status page. Postmortem nội bộ nên có một đoạn có thể chuyển thành public post, thành thật về impact, không jargon, có bước cải thiện cụ thể.
Incident commander
Trong sự cố lớn, chỉ định một Incident Commander (IC) giảm song song hội thoại, một người quyết định ai làm gì, khi nào escalate, khi nào communicate. Postmortem ghi ai là IC, ai là comms lead, để training vai trò cho team.
IC không cần là senior nhất, cần là người giữ được overview và coordinate. Practice qua game day drill.
Game day: biến recover thành muscle memory
Action item “cải thiện runbook” chỉ có giá trị khi có drill thực tế. Restore backup database mỗi quý, verify data đúng, measure thời gian. Failover DNS, verify traffic chuyển đúng, measure TTL propagation. Rollback deploy, verify pipeline chạy, measure thời gian.
Kết quả drill ghi vào verification ticket. Drill fail → tìm ra gap trong runbook trước khi incident thật.
Metrics quy trình incident
Ba metric nên track để cải thiện quy trình incident theo thời gian:
Time to Detect (TTD), từ lúc SLO breach đến lúc phát hiện. Cải thiện bằng alert tốt hơn, synthetic check.
Time to Mitigate (TTM), từ lúc phát hiện đến lúc impact giảm. Cải thiện bằng runbook, pre-built rollback, kill-switch.
Time to Resolve (TTR), từ lúc phát hiện đến lúc root cause fixed. Thường dài hơn TTM, nhưng không quan trọng bằng TTM cho customer impact.
Đặt mục tiêu cải thiện dần theo quý, không cần số hoàn hảo ngay, cần trend đi xuống.
Khi không cần postmortem dài
Incident P4 nhỏ (ảnh hưởng ít user, resolve nhanh): blameless note ngắn + một PR có thể đủ. Không cần meeting 1 giờ.
Team đang trong war room liên tục (nhiều incident dồn dập): hoãn meeting postmortem dài, ưu tiên action nhanh + ghi timeline liên tục. Postmortem chính thức sau khi ổn định.
Tóm tắt
Postmortem tốt thay đổi hệ thống, không chỉ ghi lại sự kiện. Timeline có timestamp để học coordination. Contributing factors thay vì root cause duy nhất, bắt nhiều điểm cải thiện hơn.
Action items theo ba lớp: prevent (giảm xảy ra), detect (phát hiện sớm), recover (phục hồi nhanh). Chỉ prevent là không đủ, bug mới luôn có, cần detect và recover tốt.
Blameless không loại trừ accountability, không blame người, nhưng mỗi action item có owner, deadline, verification. Action item “đủ nhỏ để ship”, một PR, một alert, một drill.
Verification 30 ngày sau: action items close chưa, alert mới hoạt động chưa, drill đã chạy chưa. Không verification → postmortem là archive, không phải learning.