Mở đầu — vì sao bài này quan trọng
Hãy hình dung một buổi tối thứ Sáu. Hệ thống thanh toán của một ví điện tử lớn ở Việt Nam bất ngờ sập trong 47 phút, đúng vào giờ cao điểm mọi người chuyển tiền cuối tuần. Hàng chục nghìn giao dịch treo, tổng đài nghẽn, mạng xã hội bắt đầu lan tin. Đội kỹ thuật khôi phục được dịch vụ lúc gần nửa đêm. Ai cũng thở phào. Nhưng câu hỏi thật sự chưa bắt đầu: Vì sao chuyện này xảy ra, và làm sao để nó không bao giờ lặp lại?
Trả lời được câu hỏi đó một cách nghiêm túc, có hệ thống, không đổ lỗi — đó chính là Post-Mortem & Incident Review. Đây không phải là "họp kiểm điểm" hay tìm người để trách. Đó là quá trình học tập có tổ chức của cả tổ chức, biến một sự cố đau đớn thành tài sản tri thức.
Với vai trò một QA Leader, bạn cần hiểu rõ hai điều. Thứ nhất, chất lượng không chỉ được đảm bảo trước khi phát hành mà còn được củng cố sau mỗi sự cố. Một tổ chức trưởng thành về chất lượng là tổ chức học nhanh từ thất bại. Thứ hai, chính bạn thường là người có tư duy điều tra hệ thống tốt nhất — bạn quen với việc truy vết nguyên nhân, tái hiện lỗi, và đặt câu hỏi "nếu... thì sao". Vì vậy QA Leader rất thường được giao vai trò dẫn dắt hoặc điều phối các buổi post-mortem. Nắm chắc bài này, bạn nâng tầm từ người kiểm thử tính năng lên người bảo vệ độ tin cậy của cả hệ thống.
Khái niệm cốt lõi
Post-Mortem là gì
Post-Mortem (còn gọi là Incident Review, hoặc Retrospective sự cố) là một buổi rà soát có cấu trúc sau khi một sự cố nghiêm trọng đã được khắc phục. Mục tiêu không phải là "kết thúc vụ việc" mà là trả lời đầy đủ ba câu hỏi:
- Chuyện gì đã xảy ra? (What) — dòng thời gian khách quan của sự cố.
- Vì sao nó xảy ra? (Why) — các nguyên nhân gốc rễ, không dừng ở triệu chứng.
- Làm sao để ngăn nó tái diễn? (How to prevent) — các hành động cụ thể, có người chịu trách nhiệm.
Văn hóa "Blameless" (không đổ lỗi)
Đây là linh hồn của toàn bộ bài học. Blameless post-mortem nghĩa là buổi rà soát tập trung vào thất bại của hệ thống và quy trình, chứ không phải thất bại của con người.
Nghe có vẻ lý tưởng, nhưng nó dựa trên một logic rất thực dụng. Nếu bạn trừng phạt người gây ra lỗi, bạn không đạt được gì cả — bạn chỉ dạy mọi người giấu lỗi. Lần sau khi ai đó nhấn nhầm nút, họ sẽ im lặng, sẽ tìm cách che đậy, và bạn mất đi dữ liệu quý giá nhất để cải thiện. Ngược lại, khi mọi người tin rằng họ có thể kể sự thật mà không bị "xử", họ sẽ nói hết — và bạn mới thấy được toàn bộ bức tranh.
Nguyên tắc nền tảng: Giả định thiện chí (assume good intent). Không ai đến công ty với ý định phá hoại. Nếu một kỹ sư xóa nhầm database production, câu hỏi blameless không phải "Tại sao anh cẩu thả thế?" mà là "Tại sao hệ thống của chúng ta cho phép một người xóa nhầm database production chỉ bằng một câu lệnh, không cảnh báo, không xác nhận, không sao lưu tức thời?"
Bạn hãy nhớ câu nói kinh điển trong ngành: "Con người không phải là nguyên nhân gốc rễ; con người vận hành trong một hệ thống đã tạo điều kiện cho lỗi xảy ra."
Root Cause và kỹ thuật "5 Whys"
Sai lầm phổ biến nhất là dừng lại ở nguyên nhân bề mặt. "Server sập vì hết bộ nhớ" — đó là triệu chứng, không phải nguyên nhân gốc. Kỹ thuật 5 Whys giúp đào sâu bằng cách hỏi "tại sao" liên tiếp:
- Vì sao dịch vụ sập? → Vì server hết bộ nhớ.
- Vì sao hết bộ nhớ? → Vì một truy vấn nạp toàn bộ 2 triệu bản ghi vào RAM.
- Vì sao truy vấn đó chạy? → Vì tính năng xuất báo cáo mới không phân trang.
- Vì sao nó không phân trang? → Vì yêu cầu không nêu giới hạn dữ liệu, và không ai kiểm thử với dữ liệu lớn.
- Vì sao không kiểm thử với dữ liệu lớn? → Vì môi trường test chỉ có 500 bản ghi, và không có tiêu chí bắt buộc test tải cho tính năng báo cáo.
Phân biệt các mức độ và các khái niệm liên quan
- Severity (mức nghiêm trọng): SEV1 (sập toàn hệ thống, mất tiền/dữ liệu), SEV2 (chức năng chính lỗi nặng), SEV3 (ảnh hưởng cục bộ). Post-mortem thường bắt buộc cho SEV1 và SEV2.
- MTTD / MTTR: Mean Time To Detect (thời gian trung bình để phát hiện sự cố) và Mean Time To Recover (thời gian để khôi phục). Đây là hai chỉ số post-mortem giúp cải thiện.
- Action item vs. Recommendation: Khuyến nghị là ý tưởng chung chung ("nên cải thiện monitoring"); action item là việc cụ thể, có người và có hạn ("Thêm cảnh báo khi memory > 85%, giao anh Nam, deadline 15/7").
Tình huống thực tế
Ví dụ 1 — Ví điện tử "PayFast" (giả định, bối cảnh Việt Nam): sự cố blameless đúng cách
PayFast — một ví điện tử với 4 triệu người dùng — gặp sự cố sập cổng thanh toán 47 phút vào tối thứ Sáu như đề cập ở đầu bài. Điều tra ban đầu cho thấy: một kỹ sư đã deploy một bản cập nhật cấu hình lúc 20h, và cấu hình đó vô tình đặt sai giá trị timeout kết nối database, khiến hàng loạt kết nối bị treo và dồn ứ.
Trong buổi post-mortem, người điều phối (chính là QA Lead) đã cố ý không hỏi "Ai deploy?" mà tập trung vào hệ thống. Kết quả 5-Whys lộ ra ba nguyên nhân gốc: (1) không có kiểm tra tự động cho file cấu hình trước khi deploy; (2) việc deploy cấu hình vào giờ cao điểm không bị chặn bởi bất kỳ quy trình nào; (3) hệ thống mất tới 12 phút mới cảnh báo vì ngưỡng alert quá cao.
Action items rất cụ thể: thêm bước validate cấu hình trong CI, cấm deploy cấu hình sản xuất trong khung 19h–22h trừ trường hợp khẩn cấp có phê duyệt, hạ ngưỡng cảnh báo timeout xuống 30 giây.
Bài học rút ra: Không một dòng nào trong tài liệu ghi tên người deploy. Ba tháng sau, chính kỹ sư đó chủ động báo cáo một lỗi cấu hình khác trước khi nó gây hậu quả — bởi anh biết mình sẽ được đối xử công bằng. Đó là giá trị thật của văn hóa blameless.
Ví dụ 2 — Sàn thương mại điện tử khu vực (bối cảnh Đông Nam Á): khi post-mortem chỉ để "cho có"
Một sàn TMĐT tại khu vực bị lỗi tính giá khuyến mãi trong đợt sale lớn: một số đơn hàng bị tính giảm giá gấp đôi, gây thất thoát ước tính hơn 1,8 tỷ đồng trong 3 giờ. Họ có tổ chức post-mortem, nhưng buổi họp biến thành phiên "truy tố": quản lý chất vấn tester "sao không phát hiện", tester đổ cho dev, dev đổ cho yêu cầu mơ hồ. Tài liệu cuối cùng ghi nguyên nhân gốc là "human error — tester sơ suất".
Kết quả: sáu tháng sau, một lỗi tính giá gần y hệt lại xảy ra ở một chương trình sale khác. Vì post-mortem lần trước không đào tới nguyên nhân hệ thống (không có bộ test case cho các quy tắc khuyến mãi chồng nhau, không có môi trường staging phản ánh đúng cấu hình khuyến mãi thật), nên chẳng có gì thay đổi ngoài việc một tester bị chuyển bộ phận.
Bài học rút ra: Post-mortem đổ lỗi tệ hơn không có post-mortem — nó tạo cảm giác an toàn giả, tiêu tốn thời gian, và bỏ lỡ cơ hội sửa chữa thật. "Human error" gần như không bao giờ là kết luận cuối cùng chấp nhận được.
Ví dụ 3 — Cách Etsy và Google định hình chuẩn ngành
Trong ngành công nghệ toàn cầu, Etsy nổi tiếng với việc phổ biến khái niệm "blameless post-mortem" và thậm chí tổ chức các buổi "Boundary" chia sẻ thất bại công khai trong nội bộ. Google, trong cuốn SRE Book của mình, đặt ra một tiêu chuẩn: mỗi sự cố đủ nghiêm trọng phải có một post-mortem, và post-mortem đó phải blameless. Họ còn nhấn mạnh nguyên tắc "no post-mortem left unreviewed" — mọi tài liệu đều được một người khác rà lại để đảm bảo chất lượng và tính hành động.
Bài học rút ra: Post-mortem không phải phát minh riêng của bạn — nó là thực hành đã được các tổ chức vận hành hệ thống lớn nhất thế giới kiểm chứng. Bạn hoàn toàn có thể áp dụng khung của họ, điều chỉnh cho quy mô đội mình.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành một buổi post-mortem hoàn chỉnh mà bạn có thể áp dụng ngay.
Bước 1 — Kích hoạt (trigger). Xác định trước tiêu chí nào bắt buộc post-mortem: ví dụ mọi SEV1/SEV2, mọi sự cố gây mất dữ liệu hoặc downtime > 5 phút cho dịch vụ chính. Đừng để việc "có làm post-mortem hay không" phụ thuộc vào cảm tính.
Bước 2 — Dựng dòng thời gian (timeline). Trước buổi họp, thu thập log, timestamp, tin nhắn để dựng lại chuỗi sự kiện khách quan: khi nào lỗi bắt đầu, khi nào được phát hiện, ai làm gì lúc mấy giờ, khi nào khôi phục. Timeline là xương sống — nó giữ mọi người bám vào sự thật thay vì phỏng đoán.
Bước 3 — Họp trong "vùng an toàn". Chọn thời điểm sau khi mọi người đã nghỉ ngơi (không họp lúc còn đang chữa cháy, cũng không để quá lâu — lý tưởng trong vòng 3–5 ngày). Người điều phối mở đầu bằng cách nhắc lại nguyên tắc blameless một cách rõ ràng thành lời.
Bước 4 — Phân tích nguyên nhân gốc. Dùng 5 Whys hoặc sơ đồ xương cá (Ishikawa/fishbone) để đào sâu. Với mỗi nhánh, luôn kéo câu hỏi về hệ thống và quy trình. Ghi nhận nhiều nguyên nhân gốc nếu có.
Bước 5 — Xác định hành động. Mỗi action item phải theo nguyên tắc SMART: cụ thể, có người phụ trách, có hạn chót. Phân loại: hành động ngăn ngừa (để không tái diễn), hành động phát hiện (để lần sau biết sớm hơn — cải thiện MTTD), hành động giảm nhẹ (để lần sau khôi phục nhanh hơn — cải thiện MTTR).
Bước 6 — Viết tài liệu post-mortem. Cấu trúc chuẩn gồm: Tóm tắt (summary) — Tác động (impact: bao nhiêu người dùng, bao nhiêu tiền, bao lâu) — Dòng thời gian — Nguyên nhân gốc — Điều gì đã làm tốt — Điều gì có thể tốt hơn — Danh sách action items.
Bước 7 — Rà soát chéo và chia sẻ. Cho một người ngoài cuộc đọc lại. Sau đó chia sẻ rộng — post-mortem tốt là tài liệu học tập cho cả tổ chức, không phải hồ sơ mật.
Bước 8 — Theo dõi đến cùng. Đây là bước hay bị bỏ. Đưa action items vào backlog/Jira, gán độ ưu tiên, và rà lại định kỳ. Một post-mortem mà action items không được làm thì chỉ là văn bản chết.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến buổi họp thành phiên đổ lỗi. Dấu hiệu: nhiều câu hỏi bắt đầu bằng "Tại sao anh/chị...". Mẹo: người điều phối chuyển mọi câu hỏi hướng-người thành câu hỏi hướng-hệ thống ngay tại chỗ.
Lỗi 2 — Dừng ở triệu chứng. "Do lỗi mạng", "do human error" là nơi phân tích bắt đầu, không phải nơi kết thúc. Mẹo: bắt buộc mỗi nguyên nhân gốc phải trả lời được "chúng ta sẽ thay đổi gì trong hệ thống/quy trình để chặn nó?".
Lỗi 3 — Action items chung chung. "Cải thiện giám sát" là mong muốn, không phải hành động. Mẹo: mỗi item phải có động từ cụ thể + người + deadline.
Lỗi 4 — Không ai theo dõi action items. Đây là lý do phổ biến nhất khiến sự cố lặp lại. Mẹo: gán một "owner" cho toàn bộ danh sách và rà trong họp định kỳ.
Lỗi 5 — Làm post-mortem quá muộn hoặc quá vội. Quá muộn thì ký ức phai; quá vội (khi còn đang mệt và bức xúc) thì cảm xúc lấn át. Mẹo: 3–5 ngày là khoảng vàng.
Lỗi 6 — Chỉ ghi cái sai, bỏ qua cái đúng. Mẹo: luôn có mục "Điều gì đã làm tốt" — nó củng cố hành vi tốt và giữ tinh thần đội.
Mẹo nâng cao cho QA Leader: Hãy dùng dữ liệu từ nhiều post-mortem để tìm mẫu lặp (patterns). Nếu 3 sự cố trong quý đều liên quan đến môi trường staging không giống production, đó là tín hiệu về một vấn đề hệ thống lớn hơn cần đầu tư — mạnh mẽ hơn bất kỳ đề xuất đơn lẻ nào.
Bài tập thực hành
Bài tập 1 — Viết một post-mortem hoàn chỉnh. Lấy tình huống PayFast ở trên (hoặc một sự cố có thật trong công ty bạn, đã ẩn danh). Viết tài liệu post-mortem đầy đủ theo 7 mục ở Bước 6. Yêu cầu: phần nguyên nhân gốc phải dùng 5 Whys và tìm ra ít nhất hai nguyên nhân gốc thuộc về hệ thống/quy trình.
Bài tập 2 — Chuyển câu hỏi đổ lỗi thành câu hỏi hệ thống. Viết lại 5 câu sau theo tinh thần blameless: (a) "Sao tester không phát hiện lỗi này?" (b) "Tại sao dev deploy vào giờ cao điểm?" (c) "Ai đã phê duyệt bản build lỗi này?" (d) "Sao không ai đọc log cảnh báo?" (e) "Tại sao anh xóa nhầm dữ liệu?".
Bài tập 3 — Thiết kế action items SMART. Với tình huống sàn TMĐT tính giá gấp đôi (Ví dụ 2), hãy đề xuất 4 action items: một để ngăn ngừa, một để phát hiện sớm hơn, một để giảm nhẹ tác động, và một để cải thiện quy trình kiểm thử. Mỗi item ghi rõ người phụ trách (giả định) và hạn chót.
Bài tập 4 — Soi chiếu bản thân. Nghĩ về sự cố gần nhất mà đội bạn gặp. Bạn đã làm post-mortem chưa? Nếu có, nó blameless đến mức nào (thang 1–5)? Nếu chưa, viết ra ba lý do khiến nó chưa xảy ra và một hành động bạn sẽ làm để thay đổi.
Tóm tắt
Post-Mortem & Incident Review là cách một tổ chức trưởng thành biến sự cố thành tri thức. Ba câu hỏi cốt lõi luôn là: chuyện gì đã xảy ra, vì sao, và làm sao để không tái diễn. Linh hồn của nó là văn hóa blameless — tập trung vào thất bại của hệ thống và quy trình, giả định thiện chí, để mọi người dám nói sự thật và tổ chức mới có dữ liệu thật để cải thiện.
Về mặt kỹ thuật, bạn dùng 5 Whys hoặc sơ đồ xương cá để đào tới nguyên nhân gốc, phân biệt triệu chứng với nguyên nhân, và luôn kéo phân tích về hệ thống. Sản phẩm đầu ra là một tài liệu post-mortem có cấu trúc và một danh sách action items SMART được theo dõi đến khi hoàn thành — vì action items không được làm chính là lý do số một khiến sự cố lặp lại.
Với vai trò QA Leader, bạn thường là người dẫn dắt quá trình này. Hãy nhớ: một post-mortem đổ lỗi còn tệ hơn không có post-mortem. Làm đúng, bạn không chỉ sửa một lỗi — bạn xây dựng một tổ chức học nhanh, tin tưởng nhau, và ngày càng đáng tin cậy hơn. Đó chính là đỉnh cao của QA Leadership.