Postmortem blameless: mẫu, ví dụ và theo action item tới khi xong Trung cấp

Trang này trả lời: viết postmortem thế nào để không đổ lỗi mà vẫn có trách nhiệm, và làm sao để action item thực sự được làm.

Khi nào viết

Postmortem là bản ghi về sự cố: tác động, hành động đã làm để giảm thiệt hại, nguyên nhân, và việc cần làm để không tái diễn. SRE book nêu các tiêu chí kích hoạt thường gặp:

• Người dùng thấy downtime hoặc suy giảm vượt ngưỡng.
• Mất dữ liệu ở bất kỳ mức nào.
• On-call phải can thiệp (rollback, chuyển traffic…).
• Thời gian xử lý vượt ngưỡng.
• Monitoring thất bại (thường nghĩa là sự cố được phát hiện thủ công).

Blameless nghĩa là gì

Theo SRE book, postmortem blameless tập trung tìm các nguyên nhân góp phần, không quy kết cá nhân hay team về hành vi sai. Lý do: “bạn không thể ‘sửa’ con người, nhưng có thể sửa hệ thống và quy trình”.

Blameless là	Blameless không phải
Hỏi “hệ thống nào cho phép lỗi này đi tới production?”	Giả vờ không ai làm gì
Mô tả đúng ai làm gì, lúc nào, dựa trên thông tin họ có khi đó	Xoá tên khỏi timeline cho “lịch sự”
Người trong cuộc vẫn chịu trách nhiệm kể lại và sửa (accountability)	Không ai phải làm action item
Chấp nhận lỗi người là bình thường, thiết kế guardrail	Bỏ qua hành vi cố ý vi phạm (đó là chuyện quản lý, không phải postmortem)

Ngôn ngữ quyết định văn hoá. SRE Workbook nêu ví dụ xấu: gọi hành động của kỹ sư là “careless ignorance”. Câu viết lại nên mô tả điều kiện, không mô tả tính cách:

Xấu:  "Bình đã deploy mà không test, gây sự cố."
Tốt:  "Bản v2.31 qua CI và được deploy lúc 13:58 UTC. Test suite không có
       test tải cho endpoint export, nên việc render đồng bộ 400 ms/request
       không bị phát hiện trước production."

Mẫu postmortem

Copy mẫu dưới đây. Mọi mốc thời gian dùng UTC để không lệch giữa các team và log.

# Postmortem: <tên ngắn của sự cố> — <YYYY-MM-DD>

Trạng thái: Draft | Đang review | Đã duyệt
Tác giả: <owner duy nhất>   Người review: <...>
Incident doc: <link>   Mức độ: SEV1 | SEV2 | SEV3

## 1. Tóm tắt (3-5 câu)
Chuyện gì xảy ra, ảnh hưởng ai, kéo dài bao lâu, đã khắc phục bằng cách nào.

## 2. Tác động (có số)
- Thời gian ảnh hưởng: HH:MM → HH:MM UTC (N phút)
- Người dùng / request bị ảnh hưởng: <số tuyệt đối và %>
- SLO: tiêu tốn <x>% error budget của chu kỳ
- Dữ liệu: có / không mất hoặc sai lệch; nếu có thì đã đối soát thế nào
- Doanh thu / đơn hàng / ticket support (nếu đo được)

## 3. Timeline (UTC)
| Thời điểm | Sự kiện | Nguồn |
|---|---|---|
| HH:MM | Thay đổi kích hoạt (deploy, config...) | CI / audit log |
| HH:MM | Alert đầu tiên / người dùng báo | Alertmanager |
| HH:MM | Declare incident, IC = ... | Kênh incident |
| HH:MM | Mitigate: ... | |
| HH:MM | SLI về bình thường | Dashboard |

## 4. Root cause và các yếu tố góp phần
- Trigger: sự kiện kích hoạt.
- Root cause: điều kiện có sẵn trong hệ thống khiến trigger gây sự cố.
- Yếu tố góp phần: vì sao không bị chặn ở review / test / canary / alert.

## 5. Phát hiện và xử lý
- Phát hiện bằng gì, sau bao lâu? Alert có đúng người, đúng mức không?
- Mitigate bằng gì, mất bao lâu từ lúc declare?

## 6. Bài học
### Điều làm tốt
### Điều làm chưa tốt
### Chỗ ta gặp may
(những điều kiện lẽ ra làm sự cố tệ hơn nhưng không xảy ra)

## 7. Action items
| # | Việc | Loại | Ưu tiên | Owner | Hạn | Ticket |
|---|---|---|---|---|---|---|
| 1 | ... | prevent / detect / mitigate | P0-P2 | @... | YYYY-MM-DD | ... |

## 8. Phụ lục
Đồ thị, query, report, link PR.

Mục Chỗ ta gặp may và phân loại action item lấy từ ví dụ postmortem của SRE Workbook. Workbook còn dùng thêm loại investigate và repair; ba loại chính dưới đây đủ cho hầu hết team.

Loại	Câu hỏi	Ví dụ
prevent	Làm sao để lỗi này không xảy ra được?	Lint rule cấm *Sync trong handler HTTP
detect	Làm sao để biết sớm hơn?	Alert event loop delay max trên 200 ms trong 5 phút
mitigate	Lần sau xảy ra thì giảm thiệt hại thế nào?	Feature flag cho endpoint export; runbook rollback 1 lệnh

Ví dụ điền mẫu (giả định, số liệu minh hoạ)

Tình huống dựng từ Demo 1, không phải sự cố thật:

• Trigger: bản v2.31 thêm endpoint export hoá đơn, render HTML đồng bộ khoảng 400 ms mỗi request.
• Root cause: handler CPU-bound chạy trên main thread, nên mỗi request export chặn mọi request khác trong cùng process.
• Yếu tố góp phần: không có test tải cho endpoint mới; không có alert event loop delay; dashboard chỉ có latency trung bình.
• Gặp may: sự cố xảy ra ngoài giờ cao điểm, và rollback không kèm migration nên hoàn tác trong 2 phút.

Action items:

1. mitigate, P0: kill switch cho endpoint export.
2. prevent, P1: chuyển render sang worker thread / job queue.
3. detect, P1: alert event loop delay max.
4. prevent, P2: thêm bước test tải vào checklist release cho endpoint xử lý dữ liệu lớn.

“5 Whys” và giới hạn của nó

5 Whys hỏi “tại sao?” liên tiếp tới khi chạm nguyên nhân gốc. Nó hữu ích để đẩy qua lớp triệu chứng đầu tiên:

Checkout chậm → tại sao? Event loop bị chặn 400 ms
  → tại sao? Endpoint export render HTML đồng bộ
  → tại sao? Không có quy ước chạy việc CPU-bound ngoài main thread
  → tại sao? ...

Giới hạn, theo John Allspaw (“The Infinite Hows”, 2014):

• Một chuỗi tuyến tính, trong khi một sự cố thường có nhiều nhánh nguyên nhân song song.
• “Tại sao” dễ trượt thành “ai”, phá vỡ tinh thần blameless.
• Root cause là thứ người điều tra chọn ra, không phải thứ tìm thấy sẵn; dừng ở “why” thứ năm là quy ước, không phải sự thật.

Cách dùng an toàn: chạy 5 Whys cho từng yếu tố góp phần, hỏi “như thế nào” (how) thay vì “tại sao”, và dừng khi tới một thứ sửa được trong hệ thống.

Theo action item tới khi xong

SRE Workbook dẫn lời Ben Treynor Sloss: với người dùng, postmortem không có hành động tiếp theo thì không khác gì không có postmortem. Workbook cũng ghi nhận: thiếu quy trình theo dõi chính thức, action item thường bị quên và dẫn tới sự cố lặp lại.

Đang tải diagram…

1. Mỗi item là một ticket trong backlog thật, có link ngược về postmortem.
2. Một owner duy nhất, có hạn chót. “Team backend” không phải owner.
3. Cụ thể, kiểm chứng được. “Cải thiện monitoring” là sai; “alert khi event loop delay max trên 200 ms trong 5 phút, gửi tới on-call checkout” là đúng.
4. Không dựa vào “mọi người cẩn thận hơn”. Item prevent tốt thay đổi hệ thống: lint, test, guardrail, automation.
5. Review định kỳ (ví dụ họp vận hành hằng tuần) các item P0/P1 quá hạn.
6. Postmortem phải được review. SRE book: postmortem chưa review thì coi như chưa từng tồn tại.

Checklist review postmortem

1. Tác động có số (thời lượng, request, % error budget), timeline đủ, dùng UTC.
2. Phân biệt trigger, root cause và các yếu tố góp phần.
3. Không có câu quy lỗi cá nhân hay ngôn ngữ cảm xúc; mô tả điều kiện, không mô tả tính cách.
4. Có mục “Chỗ ta gặp may”.
5. Mỗi yếu tố góp phần có ít nhất một action item; có cả prevent, detect và mitigate.
6. Mỗi action item: một owner, hạn chót, ticket, kiểm chứng được, không dựa vào “cẩn thận hơn”.
7. Ưu tiên của action item tương xứng với tác động.
8. Postmortem được chia sẻ rộng, và có lịch theo dõi item tới khi đóng.

Tiếp theo: Lỗi hay gặp.