Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng: 2 giờ sáng, hệ thống thanh toán của một sàn thương mại điện tử lớn ở Việt Nam sập trong 40 phút giữa lúc chạy flash sale. Hàng chục nghìn đơn hàng thất bại, doanh thu bốc hơi, khách hàng chửi rủa trên fanpage. Sáng hôm sau, sếp gọi cả team vào phòng họp và câu đầu tiên là: "Ai đẩy cái commit đó lên production?"
Đó chính là khoảnh khắc quyết định văn hóa của cả một tổ chức kỹ thuật. Nếu câu chuyện đi theo hướng "tìm thủ phạm", bạn vừa dạy cho toàn bộ engineer một bài học: lần sau có sự cố, hãy che giấu, hãy đổ lỗi, hãy im lặng. Còn nếu nó đi theo hướng "tìm hiểu vì sao hệ thống cho phép sai lầm này xảy ra", bạn đang xây một tổ chức học hỏi được từ thất bại.
Trong DevOps và SRE, sự cố (incident) là chuyện KHÔNG THỂ tránh khỏi. Không có hệ thống nào đủ phức tạp mà không hỏng. Câu hỏi không phải là "có sự cố hay không", mà là "sau mỗi sự cố, tổ chức có mạnh lên hay yếu đi". Công cụ để biến sự cố thành bài học chính là postmortem — bản phân tích sau sự cố. Và triết lý để postmortem thực sự có tác dụng chính là blameless — không đổ lỗi cá nhân. Đây là một trong những di sản văn hóa quan trọng nhất mà Google SRE để lại cho ngành, và là chủ đề của bài học hôm nay.
Khái niệm cốt lõi
Postmortem là gì?
Postmortem (nghĩa đen là "khám nghiệm tử thi") là một tài liệu được viết ra SAU KHI một sự cố đáng kể đã được khắc phục. Nó ghi lại: chuyện gì đã xảy ra, tác động ra sao, dòng thời gian diễn biến, nguyên nhân gốc rễ (root cause), cách khắc phục, và quan trọng nhất — những hành động cụ thể để ngăn sự cố tương tự tái diễn.
Postmortem KHÔNG phải là báo cáo để đổ lỗi hay để "chốt sổ" trách nhiệm. Nó là công cụ học hỏi có tổ chức. Nếu team bạn xử lý xong sự cố rồi ai về chỗ nấy, không viết lại gì cả, thì gần như chắc chắn sự cố đó sẽ quay lại — có thể dưới một hình dạng khác — trong vài tháng tới.
Vì sao phải "blameless"?
Đây là phần cốt lõi, và cũng là phần bị hiểu sai nhiều nhất. "Blameless" nghĩa là khi phân tích sự cố, ta tập trung vào hệ thống và quy trình, thay vì đổ lỗi cho cá nhân.
Cơ chế tâm lý đằng sau nó rất dễ hiểu. Con người có bản năng tự vệ. Khi một engineer biết rằng nếu mình gây ra sự cố thì sẽ bị nêu tên, bị khiển trách, bị đánh giá thấp trong kỳ review lương, thì họ sẽ làm gì? Họ sẽ giấu. Họ sẽ không dám thừa nhận "chính tôi đã gõ nhầm lệnh". Họ sẽ mô tả sự cố một cách mập mờ. Và khi thông tin bị che giấu, tổ chức mất đi dữ liệu quý giá nhất để học hỏi.
Ngược lại, blameless tạo ra tâm lý an toàn (psychological safety) — một khái niệm được Google chứng minh qua dự án nghiên cứu Aristotle là yếu tố số 1 tạo nên đội nhóm hiệu quả. Khi engineer tin rằng thừa nhận sai lầm sẽ không bị trừng phạt, họ sẽ nói ra toàn bộ sự thật. Và chỉ khi có toàn bộ sự thật, ta mới sửa được gốc rễ.
Nguyên tắc nền tảng: giả định thiện chí
Blameless đứng trên một giả định gọi là "assumption of good intent" — giả định rằng mọi người liên quan đến sự cố đều đã hành động với thông tin tốt nhất họ có, với ý định tốt nhất, vào thời điểm đó. Không ai cố tình phá hoại hệ thống.
Từ giả định đó, câu hỏi phân tích thay đổi hoàn toàn. Thay vì hỏi:
> "Tại sao anh Nam lại xóa nhầm database production?"
Ta hỏi:
> "Tại sao HỆ THỐNG của chúng ta cho phép một người có thể xóa database production chỉ bằng một lệnh, không có xác nhận, không có phân quyền, không có backup tự động?"
Bạn thấy sự khác biệt chứ? Câu hỏi thứ nhất dẫn đến một người bị trừng phạt và một lỗ hổng vẫn còn nguyên. Câu hỏi thứ hai dẫn đến việc thêm cơ chế xác nhận, phân quyền RBAC, và backup — tức là hệ thống thực sự mạnh lên.
Human error là triệu chứng, không phải nguyên nhân
Một tư duy quan trọng cần khắc cốt ghi tâm: khi bạn kết luận "nguyên nhân là do con người sai sót" (human error), bạn đã DỪNG phân tích quá sớm. "Human error" gần như không bao giờ là nguyên nhân gốc — nó là triệu chứng của một hệ thống dễ mắc lỗi. Một hệ thống tốt phải được thiết kế để chịu đựng được sai lầm của con người, vì con người CHẮC CHẮN sẽ mắc lỗi.
Phân biệt "blameless" với "accountability-free"
Đây là hiểu lầm nguy hiểm nhất. Blameless KHÔNG có nghĩa là "không ai chịu trách nhiệm gì cả", cũng không phải "làm gì cũng được, sai cũng không sao". Nó vẫn có trách nhiệm giải trình (accountability) — nhưng trách nhiệm ở đây là trách nhiệm sửa hệ thống, không phải trách nhiệm chịu phạt. John Allspaw (từ Etsy) gọi đây là "blameless nhưng không blame-free" — ta vẫn phân tích nghiêm túc hành động của con người để hiểu, chứ không phải để bỏ qua.
Tình huống thực tế
Tình huống 1: Sàn TMĐT Việt Nam — cú xóa nhầm cấu hình CDN
Một sàn thương mại điện tử lớn tại TP.HCM (gọi là công ty A) gặp sự cố toàn bộ hình ảnh sản phẩm biến mất trong 25 phút vào giờ cao điểm buổi tối. Nguyên nhân trực tiếp: một bạn junior engineer khi cập nhật cấu hình CDN đã apply nhầm một file config của môi trường staging lên production, khiến toàn bộ đường dẫn ảnh trỏ sai.
Cách xử lý sai (giả định): Sếp gọi bạn junior lên, mắng trước cả team, ghi vào hồ sơ. Kết quả? Bạn junior sợ hãi, hai tuần sau xin nghỉ. Team mất một người. Và điều tệ hơn: quy trình deploy config vẫn không thay đổi, ai cũng có thể mắc lại lỗi này.
Cách xử lý blameless (thực tế công ty A đã làm): Trong buổi postmortem, câu hỏi đặt ra là "vì sao một file staging config có thể được apply lên production mà không có bất kỳ rào chắn nào?". Phân tích cho thấy: tên file staging và production giống nhau đến 90%, không có bước review, không có phân tách rõ ràng thư mục. Action items rút ra: (1) tách hẳn repo config theo môi trường, đặt tên rõ ràng; (2) thêm bước CI kiểm tra file config phải khớp môi trường đích; (3) yêu cầu 1 người approve trước khi apply production.
Bài học: Người "gây ra" sự cố lại chính là người hiểu rõ lỗ hổng nhất, và trở thành người viết postmortem, đề xuất giải pháp. Bạn junior đó ở lại, sáu tháng sau lên mid-level. Sự cố biến thành cơ hội trưởng thành.
Tình huống 2: GitLab và vụ mất dữ liệu database năm 2017
Đây là ví dụ kinh điển của ngành. Năm 2017, một sysadmin của GitLab trong lúc xử lý sự cố tải cao đã gõ nhầm lệnh rm -rf trên database production thay vì trên server phụ, xóa mất khoảng 300GB dữ liệu. Tệ hơn, khi đi khôi phục thì phát hiện 5 trong 5 cơ chế backup đều... không hoạt động như mong đợi.
Điều làm GitLab trở thành huyền thoại không phải là sự cố, mà là cách họ phản ứng. Họ livestream toàn bộ quá trình khôi phục trên YouTube, cập nhật công khai từng bước qua Google Doc, và sau đó xuất bản một postmortem cực kỳ chi tiết và hoàn toàn blameless. Họ không nêu tên người gõ lệnh để chỉ trích; thay vào đó họ phân tích: vì sao môi trường cho phép nhầm lẫn giữa hai server? vì sao không có cảnh báo? và đặc biệt — vì sao KHÔNG có backup nào hoạt động mà không ai biết?
Bài học: Nguyên nhân gốc thực sự không phải cú gõ nhầm — cú gõ nhầm chỉ là giọt nước tràn ly. Nguyên nhân gốc là 5 lớp backup đều hỏng âm thầm. Sự minh bạch của GitLab khiến cộng đồng kỹ thuật kính trọng họ HƠN, chứ không phải khinh thường. Blameless ở quy mô công khai đã biến một thảm họa PR thành một điểm cộng về văn hóa.
Tình huống 3: Fintech Đông Nam Á — sự cố cổng thanh toán lặp lại
Một công ty fintech (ví điện tử) hoạt động ở Việt Nam và Indonesia gặp sự cố timeout cổng thanh toán ba lần trong hai tháng. Ban đầu, mỗi lần sự cố họ chỉ "restart service cho hết lỗi" và không viết postmortem vì "có gì đâu, restart là xong".
Đến lần thứ ba, sự cố kéo dài 1 tiếng vào cuối tuần, ảnh hưởng hàng chục nghìn giao dịch. Lúc này họ mới bắt buộc viết postmortem đầy đủ. Khi phân tích dòng thời gian và ghép cả ba lần lại, họ phát hiện nguyên nhân gốc chung: một connection pool cấu hình quá nhỏ, cứ đến ngưỡng tải nhất định là cạn kết nối. Ba lần "restart cho xong" thực chất chỉ là che đi triệu chứng.
Bài học: Việc bỏ qua postmortem cho các sự cố "nhỏ" khiến họ mất cơ hội phát hiện sớm một vấn đề hệ thống lớn. Bài học rút ra thêm: cần định nghĩa rõ ngưỡng bắt buộc viết postmortem (ví dụ: mọi sự cố ảnh hưởng khách hàng trên 5 phút, hoặc mọi lần đốt error budget đáng kể). Sau đó họ bổ sung cả cơ chế cảnh báo connection pool và load test định kỳ.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để viết một postmortem blameless chất lượng.
Bước 1 — Xác định ngưỡng trigger. Định nghĩa trước loại sự cố nào bắt buộc viết postmortem. Ví dụ: downtime khách hàng nhìn thấy trên 5 phút, mất dữ liệu, vi phạm SLO nghiêm trọng, hoặc phải rollback khẩn cấp. Điều này tránh tranh cãi "vụ này có đáng viết không" ngay giữa lúc đang căng thẳng.
Bước 2 — Cử người chủ trì (owner) trung lập. Người viết postmortem lý tưởng nên là người tham gia xử lý sự cố nhưng không phải người "bị nghi" gây ra nó, để đảm bảo góc nhìn khách quan. Owner chịu trách nhiệm điều phối, không phải chịu tội.
Bước 3 — Dựng lại dòng thời gian (timeline) chính xác. Ghi lại theo mốc giờ: khi nào lỗi bắt đầu, khi nào alert kêu, ai vào xử lý lúc mấy giờ, đã thử gì, khi nào khôi phục. Dùng log, dữ liệu monitoring, lịch sử chat để dựng lại — đừng dựa vào trí nhớ. Timeline là xương sống của phân tích.
Bước 4 — Đo lường tác động (impact). Định lượng cụ thể: bao nhiêu phút downtime, bao nhiêu request lỗi, bao nhiêu khách hàng ảnh hưởng, thiệt hại doanh thu ước tính. Con số cụ thể giúp xác định mức độ ưu tiên của action items về sau.
Bước 5 — Phân tích nguyên nhân gốc bằng "5 Whys". Hỏi "tại sao" liên tiếp, mỗi câu trả lời lại hỏi tiếp cho đến khi chạm tới nguyên nhân hệ thống. Ví dụ: "Site sập → tại sao? → server hết bộ nhớ → tại sao? → memory leak → tại sao không phát hiện sớm? → không có alert về memory → tại sao? → chưa ai cấu hình → tại sao? → không có checklist khi lên service mới." Chú ý: mọi câu "tại sao" đều phải trỏ về hệ thống/quy trình, không trỏ về "vì anh X lười".
Bước 6 — Viết bằng ngôn ngữ blameless. Dùng chủ ngữ trung lập. Thay vì "Nam đã đẩy code lỗi", viết "một thay đổi chưa được test đầy đủ đã được đưa lên production do quy trình review chưa bắt buộc". Mô tả hành động và điều kiện, không quy kết cá nhân.
Bước 7 — Đề ra action items cụ thể, có người chịu trách nhiệm và deadline. Đây là phần quyết định postmortem có giá trị hay chỉ là giấy lộn. Mỗi action item phải: cụ thể (không mơ hồ kiểu "cẩn thận hơn"), có owner rõ ràng, có deadline, và được đưa vào backlog/ticket để theo dõi. Action item không có deadline = sẽ không bao giờ làm.
Bước 8 — Tổ chức buổi review công khai. Trình bày postmortem cho team (và các team liên quan) để lan tỏa bài học. Buổi này phải giữ đúng tinh thần blameless — người điều phối cần cắt ngang ngay nếu có ai bắt đầu chỉ trích cá nhân.
Bước 9 — Lưu trữ và theo dõi. Đưa postmortem vào một kho tri thức chung (wiki, Confluence, repo) để tra cứu sau này, và theo dõi action items đến khi đóng hết. Postmortem viết xong mà action items treo mãi thì coi như vô nghĩa.
Lỗi thường gặp & mẹo
Lỗi 1 — "Blameless" kiểu hình thức. Team nói là blameless nhưng trong phòng họp vẫn liếc nhìn "người gây ra", vẫn có giọng điệu trách móc ngầm. Tâm lý an toàn cảm nhận được, không giả vờ được. Mẹo: người quản lý cấp cao phải làm gương — kể lại chính sai lầm của mình một cách cởi mở để cả team thấy an toàn.
Lỗi 2 — Dừng ở "human error". Kết luận "do bạn X thao tác nhầm" rồi đóng lại. Đây là dấu hiệu phân tích lười. Mẹo: mỗi khi định viết "human error", ép mình hỏi thêm ít nhất 3 câu "tại sao hệ thống cho phép điều đó".
Lỗi 3 — Action items chung chung. Viết "cần cẩn thận hơn", "nâng cao ý thức", "test kỹ hơn". Đây không phải action item — không đo được, không ai làm. Mẹo: mọi action item phải trả lời được "ai làm, làm cụ thể cái gì, xong khi nào".
Lỗi 4 — Viết xong rồi bỏ xó. Postmortem trở thành nghĩa vụ giấy tờ, viết cho có, action items không ai theo dõi. Mẹo: gắn action items vào sprint planning, và định kỳ (hàng tháng) review tỷ lệ action items đã đóng.
Lỗi 5 — Chỉ viết cho sự cố lớn. Bỏ qua các near-miss (suýt sự cố) và sự cố nhỏ lặp lại — nơi chứa nhiều bài học rẻ tiền nhất. Mẹo: khuyến khích viết postmortem cho cả near-miss; đó là học được bài học mà chưa phải trả giá.
Lỗi 6 — Trừng phạt ngầm. Miệng nói blameless nhưng đến kỳ đánh giá lại nhớ "vụ đó là do nó". Điều này giết chết văn hóa nhanh nhất. Mẹo: tách bạch hoàn toàn postmortem khỏi đánh giá hiệu suất cá nhân.
Bài tập thực hành
Bài 1 — Viết lại theo giọng blameless. Cho câu sau: "Sự cố xảy ra vì bạn Hùng deploy lúc 5 giờ chiều thứ Sáu mà không test, làm sập API." Hãy viết lại theo ngôn ngữ blameless, tập trung vào hệ thống, và chỉ ra ít nhất 3 câu hỏi "tại sao hệ thống cho phép".
Bài 2 — Chạy 5 Whys. Lấy một sự cố (thật hoặc giả định) bạn từng biết, chạy đủ chuỗi "5 Whys" cho đến khi chạm nguyên nhân hệ thống. Viết ra từng bước và nguyên nhân gốc cuối cùng.
Bài 3 — Soạn template postmortem. Tạo một template postmortem gồm các mục: Tóm tắt, Tác động (định lượng), Timeline, Nguyên nhân gốc, Điều gì diễn ra tốt, Điều gì diễn ra chưa tốt, Action items (owner + deadline). Đây là tài sản bạn có thể mang đi dùng thật ở công ty.
Bài 4 — Chấm điểm action items. Cho 5 action items sau, đánh giá cái nào tốt cái nào tệ và giải thích: (a) "cẩn thận hơn khi deploy"; (b) "thêm bước approve bắt buộc cho deploy production, owner: team lead, deadline: 2 tuần"; (c) "nâng cao ý thức team"; (d) "cấu hình alert memory usage trên 85%, owner: Minh, deadline: thứ Sáu tuần này"; (e) "học hỏi từ sự cố này".
Tóm tắt
Postmortem là công cụ biến sự cố — thứ không thể tránh khỏi trong mọi hệ thống phức tạp — thành bài học giúp tổ chức mạnh lên. Nhưng postmortem chỉ thực sự có tác dụng khi nó blameless: tập trung vào hệ thống và quy trình thay vì đổ lỗi cá nhân. Lý do rất thực tế: khi engineer không sợ bị trừng phạt, họ mới dám nói ra toàn bộ sự thật, và chỉ với sự thật đầy đủ ta mới sửa được gốc rễ.
Hãy nhớ ba điều cốt lõi: (1) "human error" là triệu chứng, không phải nguyên nhân — một hệ thống tốt phải chịu được sai lầm của con người; (2) blameless không phải là vô trách nhiệm — trách nhiệm ở đây là sửa hệ thống, không phải chịu phạt; (3) một postmortem chỉ đáng giá khi nó đẻ ra được các action items cụ thể, có owner, có deadline và được theo dõi đến cùng.
Câu chuyện GitLab, sàn TMĐT Việt Nam và fintech Đông Nam Á đều dạy chung một điều: cách một tổ chức phản ứng sau sự cố nói lên nhiều về sức khỏe văn hóa của nó hơn là bản thân sự cố. Xây được văn hóa blameless, bạn không chỉ có hệ thống bền vững hơn, mà còn giữ được con người — tài sản quý nhất của mọi đội ngũ kỹ thuật.