🧠 Phần 6: Học từ sự cố – Postmortem không đổ lỗi

📌 Tại sao cần Postmortem?

Sự cố là không thể tránh khỏi
Mỗi sự cố là cơ hội học hỏi và cải tiến
Nếu không học từ lỗi → sẽ lặp lại → mất uy tín và độ tin cậy

🚫 Tại sao phải "blameless" (không đổ lỗi)?

Con người là một phần hệ thống
Lỗi thường đến từ quy trình, giao tiếp, thiết kế chưa đủ tốt
Đổ lỗi làm team mất niềm tin, không dám báo lỗi

🔑 "Người ta thường làm điều hợp lý theo dữ liệu họ có tại thời điểm đó"

📝 Mục tiêu của Postmortem

Tái dựng sự cố (timeline, hành động)
Xác định nguyên nhân gốc (root cause)
Tìm cải tiến dài hạn
Ghi chép rõ ràng, chia sẻ công khai (trong nội bộ)

🧩 Cấu trúc 1 bản Postmortem hiệu quả

Mục	Nội dung
Sự cố là gì	Mô tả đơn giản nhưng đủ chi tiết
Timeline	Thời gian từng hành động chính
Tác động	Ảnh hưởng tới người dùng, SLO
Nguyên nhân	Cả kỹ thuật & quy trình
Hành động xử lý	Đã làm gì để khôi phục
Phân tích	Điều gì có thể làm tốt hơn
Hành động tiếp theo	Cải tiến/automation/training...
Tài liệu liên quan	Ticket, Grafana, PR, log...

✅ Checklist khi viết Postmortem

Ghi rõ timeline: ai làm gì, lúc nào?
Không đổ lỗi cá nhân
Xác định được nguyên nhân gốc kỹ thuật & tổ chức
Có hành động khắc phục và cải tiến lâu dài
Được chia sẻ cho toàn team kỹ thuật
Gắn link với alert, SLO, dashboard liên quan

📦 Mô hình quy trình Postmortem

Sự cố xảy ra
     ↓
Phục hồi hệ thống
     ↓
Viết báo cáo Postmortem (blameless)
     ↓
Chia sẻ nội bộ & học hỏi
     ↓
Triển khai hành động cải tiến

🛠️ Công cụ hỗ trợ

Google Docs / Confluence Template
Incident.io / Jeli / Rootly (tự động hóa)
GitHub Issues + Template Markdown
Grafana / Loki / Prometheus để điều tra

📌 Kết luận:
Postmortem không chỉ là báo cáo – mà là công cụ học tập giúp team mạnh hơn sau mỗi lần gục ngã.
Nếu không viết postmortem, ta sẽ lặp lại lỗi – mãi mãi.

Chương tiếp theo sẽ trình bày về lịch trực on-call bền vững và tránh burnout!