Postmortem tồi thường là Word dài mà không đổi được một dòng code hoặc một alert. Postmortem tốt cập nhật mô hình thất bại của hệ thống: chúng ta đã 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.

Phạm vi: incident kỹ thuật (outage, data, security). Không: điều tra HR.

Tham chiếu Linux/host: Linux networking ops, SSH & hardening khi incident liên quan host.

1. Timeline với độ phân giải đủ dùng

  • T+0: triệu chứng user/SLO vi phạm.
  • Phát hiện: ai phát hiện, qua kênh nào (alert, user, internal).
  • Mitigate: rollback, scale, feature flag, traffic shed.
  • Khôi phục: SLO xanh trở lại theo định nghĩa.

Thiếu timestamp → không học được “vì sao mất 40 phút mới rollback”.

2. Contributing factors (bỏ “một root cause thần thánh”)

Nhiều sự cố là chuỗi điều kiện:

  • deploy + cache cũ + missing alert + con người mệt.

Ghi nhiều factor có trọng số; tránh câu chuyện một anh hùng / một kẻ nhận lỗi.

3. Mitigation theo ba lớp

LớpVí dụ
PreventFix bug, thêm constraint, test regression
DetectAlert SLO, synthetic check, dashboard
RecoverRunbook rollback, runbook DB restore drill

Nếu chỉ có “prevent” mà không có “detect”, bạn vẫn mù cho lần sau khác.

4. Blameless vs accountability

  • Blameless: không trừng phạt người báo tin; tập trung hệ thống.
  • Accountability: vẫn có owner cho action items; deadline thực tế.

Hai khái niệm không loại trừ nhau. Blameless không có nghĩa “không ai chịu trách nhiệm đóng ticket”.

5. Template một trang

Impact: (user/SLO, thời lượng, blast radius)
Timeline: (bullet có giờ)
Root causes / contributing factors: (danh sách)
What went well:
What went poorly:
Action items:
  - [owner] [due] [type: prevent/detect/recover] ...
Verification: (metric/alert nào chứng minh item xong)

Action item “đủ nhỏ để ship”: một PR hoặc một ticket có acceptance criteria đo được — tránh “cải thiện observability” vô hạn.

6. Verification sau sự cố

Sau 30 ngày: action items đóng chưa? alert mới có noise không? drill rollback có chạy?

Không verification → postmortem là archive, không phải học.

Khi không nên họp postmortem dài

  • Incident P4 nhỏ: blameless note ngắn + một PR có thể đủ.
  • Khi team đang trong war room liên tục: hoãn họp dài, ưu tiên action nhanh + note timeline liên tục.

7. Severity và customer communication

Postmortem nên gắn severity đã dùng lúc incident (P1–P4) để sau này so sánh. Phần “customer impact” nên có:

  • Thời lượng downtime / error rate peak.
  • Vùng ảnh hưởng (region, tenant).
  • Dữ liệu có bị sai/lệch không (data incident).

Giải thích thêm: nếu không ghi customer impact, tổ chức sẽ không biết đầu tư vào đâu (SLO vs DR vs QA).

8. Action items: SMART và tránh “tech debt vĩnh cửu”

Mỗi action nên có:

  • Owner duy nhất (không “team backend”).
  • Due date thực tế.
  • Verification: “alert X im lặng trong 7 ngày”, “test Y pass trên CI”.

Tránh: “cải thiện monitoring” không đo được.

9. Pre-mortem cho incident tái diễn

Nếu cùng loại incident lặp lại trong 90 ngày, hãy làm pre-mortem: giả định nó xảy ra lần nữa vì sao? Điều này buộc team nhìn vào hệ thống incentive (ví dụ: không ai sở hữu alert noisy nên alert bị tắt).

10. Liên kết mạng và hạ tầng

Nhiều incident là cutover DNS/TLS/LB. Giữ link tới Release networking incidents và checklist Debug mạng trong postmortem để người đọc sau tái sử dụng được.

11. Data incident: thêm mục “integrity”

Nếu có sai lệch dữ liệu:

  • Phạm vi row ảnh hưởng.
  • Cách backfill / reconcile.
  • Communication tới khách hàng (nếu cần).

Đừng chỉ nói “đã fix bug” mà không nói “dữ liệu đã được sửa thế nào”.

12. Mẫu timeline chi tiết (fill-in)

T0  SLO breach bắt đầu (metric/link)
T0+2m  On-call ack pager
T0+8m  Xác định release v123 là nghi phạm
T0+12m Rollback hoàn tất
T0+18m SLO phục hồi
T0+24m Comms nội bộ / status page update

Thiếu mốc giờ → không học được coordination.

Bài tập ngắn

Viết postmortem giả định 1 trang cho incident “deploy làm spike 5xx 12 phút đã rollback” — ít nhất 3 contributing factors.

Mở rộng: Thêm một action “detect” và một action “recover” có verification cụ thể.

13. Customer trust và transparency

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 (sau khi legal/comms review): thành thật về impact, không jargon, có bước cải thiện cụ thể.

14. Incident commander và vai trò tạm thời

Trong sự cố lớn, chỉ định một IC để giảm song song hội thoại. Postmortem nên ghi ai là IC, ai là comms lead — để sau này training vai trò.

15. Game day / drill: biến recover thành muscle memory

Action item “cải thiện runbook” chỉ có giá trị nếu có drill định kỳ (restore backup, failover DNS). Ghi kết quả drill vào ticket verification.

16. Sự cố bảo mật: phân nhánh quy trình

Nếu có chỉ dấu data breach, postmortem cần legal/privacy tham gia sớm; template kỹ thuật vẫn dùng được nhưng phần public khác với outage thuần.

17. Metrics của quy trình incident

  • Time to detect (TTD)
  • Time to mitigate (TTM)
  • Time to resolve (TTR)

Đặt mục tiêu cải thiện dần theo quý; không cần số hoàn hảo ngay.

Tóm tắt cho người vội

  • Timeline + contributing factors > một root cause.
  • Action items nhỏ, có owner, có verification.
  • Data và customer impact là phần không tùy chọn cho nhiều loại incident.

Đọc thêm