Retrospective và Post-Mortem: không đổ lỗi, hữu dụng, được track

Khả năng học của một team chính là lợi thế bền vững duy nhất khi dự án ngày càng lớn. Retrospective biến từng sprint thành một thí nghiệm nhỏ; còn post-mortem biến từng sự cố thành một thay đổi ở cấp hệ thống. Chương này giới thiệu format, template, và kỷ luật theo dõi để cả hai không trở thành kịch.

Khi nào retro / post-mortem chính thức trở nên quan trọng?

Có ba tín hiệu chính.

Sự cố lặp lại. Cùng kiểu bug, cùng kiểu trễ, cùng kiểu ma sát với stakeholder - khi chúng quay lại, nghĩa là bài học lần trước đã không dính được. Một post-mortem có action item là cách trả lời đúng.

Team đang lớn lên hoặc đang xoay người. Thành viên mới chưa có lịch sử của team. Retro chính là nơi ngữ cảnh được chuyển sang.

Chất lượng đi xuống một cách lặng lẽ. Bug bò lên dần, deploy chậm hơn, on-call bị page nhiều hơn. Retro làm lộ trend này ra trước khi nó kịp biến thành một sự cố lớn.

Nếu team đang ổn định, ship trơn tru, sự cố hiếm xảy ra, nhịp retro nhẹ (mỗi tháng một lần) là đủ. Chương sprint execution cũng cung cấp một bề mặt ở cấp standup để bắt vấn đề giữa các retro. Chỉ bỏ qua post-mortem cho những sự cố thực sự không đáng kể.

Cái giá khi bỏ retro và post-mortem là gì?

Có ba kiểu lỗi thường gặp.

Cùng pattern bug lặp lại. Ba lần trong sáu tháng cùng một kiểu regression được ship ra. Khi không có post-mortem, team coi mỗi lần như một sự cố một-lần riêng lẻ; còn cái gap bên dưới (không có integration test, không có canary deploy) thì vẫn nguyên đó.

Quy trình trôi dần. Standup dài lê thê, retro ngắn lại, doc thưa dần. Không ai nhận ra vì không có bề mặt review nào bắt được điều đó.

Attrition trong im lặng. Engineer cảm thấy không được lắng nghe. Họ ngừng nêu vấn đề. Rồi họ rời đi. Buổi phỏng vấn nghỉ việc cuối cùng làm lộ ra những gì retro đáng lẽ phải bắt được.

Format retro tối thiểu trông thế nào?

Cho team 5 người, vào cuối sprint:

# Retrospective — Sprint 2026-12

## Cái gì tốt (5 phút)
- Luồng refund ship đúng hạn
- Engineer mới ramp nhanh nhờ pairing
- Không sự cố production sprint này

## Cái gì đau (10 phút)
- Stripe sandbox flaky 3 ngày, chặn Bob
- Thêm scope giữa sprint cho khách VIP (không dùng template)
- Queue review PR tăng lên 8 PR cuối tuần

## Nên thử gì (10 phút)
- Action: Tài liệu hoá đường escalation Stripe-flake
  - Owner: Bob
  - Hạn: cuối sprint kế
- Action: Dùng template điều chỉnh giữa sprint mỗi lần
  - Owner: PM
  - Hạn: ngay

## Action retro trước (check trạng thái)
- [x] Thêm WIP limit vào review PR (XONG; queue giảm)
- [ ] Refresh runbook luồng refund (kéo qua; Carol sở hữu)
- [x] Chuyển standup sang 10 giờ (XONG; engineer vui hơn)

Phần "Action retro trước" chính là kỷ luật giúp retro thật sự dính. Nếu không có nó, các action item sẽ được thêm vào rồi quên đi.

Template post-mortem tối thiểu trông thế nào?

Sau một sự cố P1 hoặc P2, trong vòng 48 giờ:

# Post-Mortem: {{ Tiêu đề sự cố }} — 2026-06-13

## Tóm tắt
{{ Hai câu: cái gì xảy ra, ai bị ảnh hưởng, dài bao lâu }}

## Timeline
| Giờ (UTC) | Sự kiện |
|-----------|---------|
| 14:32 | Deploy v2.4.1 |
| 14:38 | Alert error rate nổ (0.8%) |
| 14:42 | On-call bị page; điều tra bắt đầu |
| 14:55 | Quyết roll back |
| 15:01 | Rollback xong; metric về baseline |
| 15:15 | All clear |

## Tác động
- {{ X khách bị ảnh hưởng }}
- {{ Thời gian: 33 phút }}
- {{ Tác động doanh thu: ước $Y }}

## Root cause (5 whys)
1. Vì sao error nhảy? - Code mới throw NullReferenceException
2. Vì sao? - Method refactor giả thiết param non-null
3. Vì sao? - Caller path legacy pass null trong 0.5% case
4. Vì sao? - Path legacy không trong test coverage
5. Vì sao? - Báo cáo coverage không review trong PR

## Cái gì tốt
- Rollback trong 30 phút (đạt target)
- Comms cập nhật khách lúc 14:50

## Cái gì không tốt
- Ngưỡng alert error rate quá thấp (0.8% nên là 0.3%)
- Không bước canary deploy cho service này

## Action item
| # | Action | Owner | Hạn | Track |
|---|--------|-------|-----|-------|
| 1 | Thêm bước canary deploy vào CI | Bob | 2026-06-30 | TICKET-1234 |
| 2 | Hạ alert error rate xuống 0.3% | Carol | 2026-06-20 | TICKET-1235 |
| 3 | Cổng coverage trong review PR | Alice | 2026-07-15 | TICKET-1236 |

## Trạng thái: Mở. Sẽ đóng khi mọi action xong.

Có ba chi tiết đáng chú ý. Timeline phải là cái thực sự đã xảy ra, chứ không phải cái chúng ta nghĩ là đã xảy ra - hãy tái dựng từ log và lịch sử channel. Phần root cause dùng phương pháp 5 whys để khoan từ dấu hiệu xuống cấp hệ thống. Còn các action item phải có ticket gắn theo, chứ không phải chỉ là ý định mơ hồ.

Scale lên đa team ra sao?

flowchart TB
    TeamA[Retro Team A] --> Org[Theme cấp tổ chức<br/>review tháng]
    TeamB[Retro Team B] --> Org
    TeamC[Retro Team C] --> Org
    Inc1[Post-mortem 1] --> Org
    Inc2[Post-mortem 2] --> Org
    Org --> Engineering[Cập nhật practice engineering<br/>vd cổng CI]

Retro của từng team vẫn nằm ở cấp team. Buổi review ở cấp tổ chức sẽ tổng hợp các theme xuyên các team (ví dụ "test flaky" lộ ra ở 3 retro liên tiếp = đây là vấn đề toàn tổ chức). Các action item xuyên team được chuyển sang team practice engineering để đẩy đi tiếp.

Retro / post-mortem có thể tự tạo ra những lỗi nào?

• Retro biến thành trị liệu. Một giờ thảo luận đầy cảm xúc, không có action. Cách phòng: time-box, tối đa 60 phút; nếu hết 60 phút mà không có action item, hãy kết thúc cuộc họp.
• Đổ lỗi len lén vào. Câu kiểu "Bob deploy không test." Cách phòng: rephrase về cấp hệ - "chúng ta đang deploy mà không có cổng test bắt buộc". Action là thêm cái cổng đó.
• Action item rơi rớt. Được liệt kê ra nhưng không track. Cách phòng: mỗi action có ticket gắn theo; ticket được review ở retro kế.
• Bỏ post-mortem cho các sự cố "rõ ràng". "Chúng ta đã biết cái gì xảy ra rồi, không cần viết". Cách phòng: quy tắc viết áp dụng cho mọi sự cố P1/P2, bất kể cảm giác chủ quan về độ rõ ràng.

Khi nào retro chi tiết là quá liều?

Có hai trường hợp.

Team hai engineer đang ở trong deep flow. Đôi khi một buổi chat nhanh cuối sprint đã là đủ retro. Đừng chính thức hoá nếu team đang thật sự nói chuyện với nhau.

Một fix bằng một PR gây ra sự cố P3. Một sự cố một dòng với cách fix một dòng không cần một post-mortem 5-whys đầy đủ. Hãy ghi vào runbook của team rồi đi tiếp.

Format đầy đủ chỉ đáng thời gian khi team từ 5 người trở lên và sự cố ở mức P2 trở lên. Dưới đó, ghi chú nhẹ là chạy được.

Đi tiếp từ đây như thế nào?

Bạn đã hoàn tất nhóm lifecycle. Chương tiếp theo: 1-on-1 - artifact lãnh đạo con người, làm lộ vấn đề trước khi nó kịp đi đến retro. Sau đó, tuyển dụng và onboarding sẽ nói về cách đưa engineer mới vào team.