Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng buổi sáng thứ Hai, hệ thống thanh toán của bạn sập trong 47 phút. Hàng chục nghìn giao dịch thất bại, khách hàng gọi điện tới tấp, CEO nhắn tin trong nhóm lãnh đạo. Sau khi khôi phục, sếp tổ chức một cuộc họp và câu đầu tiên là: "Ai đẩy cái commit này lên production vậy?"
Ngay khoảnh khắc đó, bạn đã thua. Không phải vì sự cố — sự cố nào cũng sẽ xảy ra — mà vì cách bạn phản ứng với nó. Câu hỏi "ai" biến buổi họp thành một phiên tòa. Người kỹ sư vô tình gây ra sự cố sẽ cúi đầu, tìm cách biện minh, giấu bớt chi tiết. Cả đội học được một bài học duy nhất: lần sau nếu lỡ tay, hãy che đậy càng kín càng tốt. Và thế là bạn đã chôn vùi thông tin quý giá nhất để hệ thống an toàn hơn.
Postmortem blameless (biên bản phân tích sự cố không đổ lỗi) là một trong những công cụ lãnh đạo kỹ thuật mạnh mẽ nhất mà lại ít tốn kém nhất. Nó không phải một tài liệu hành chính bạn viết cho có. Nó là cách bạn biến mỗi sự cố tốn kém thành một khoản đầu tư dài hạn cho độ tin cậy của hệ thống và cho văn hóa đội. Với vai trò tech lead, bạn thường không phải người viết code gây ra lỗi, nhưng bạn là người quyết định: sau sự cố, đội của bạn sẽ sợ hãi hơn hay khôn ngoan hơn.
Bài này tập trung riêng vào văn hóa và kỹ thuật viết postmortem blameless — triết lý, template, cách vận hành cuộc họp và những cạm bẫy tâm lý. Các bài khác trong khóa đã và sẽ nói về on-call, playbook ứng cứu sự cố và SLO; ở đây ta nói về chuyện xảy ra sau khi sự cố đã được dập tắt: làm sao để học từ nó.
Khái niệm cốt lõi
Blameless nghĩa là gì và không nghĩa là gì
"Blameless" thường bị hiểu nhầm là "không ai chịu trách nhiệm gì cả" — kiểu vô can tập thể. Đó là hiểu sai nguy hiểm. Blameless không có nghĩa là không có trách nhiệm (accountability). Nó có nghĩa là ta tách bạch con người khỏi hệ thống.
Nguyên tắc nền tảng đến từ John Allspaw (Etsy) và triết lý an toàn của ngành hàng không: khi một kỹ sư giỏi, có thiện chí, đưa ra một quyết định mà sau này hóa ra sai, thì lỗi không nằm ở con người đó, mà nằm ở hệ thống đã cho phép quyết định sai đó gây ra thiệt hại lớn. Tại sao không có kiểm thử tự động chặn lại? Tại sao một người có thể deploy thẳng lên production mà không cần review? Tại sao alert không kêu sớm hơn?
Đây gọi là giả định thiện chí cơ bản (fundamental assumption of good intent): mọi người đến làm việc mỗi ngày để làm tốt công việc, không ai cố tình phá hoại. Khi bạn tin điều đó, câu hỏi tự động chuyển từ "ai sai" sang "cái gì trong hệ thống của chúng ta đã khiến một người bình thường mắc lỗi này, và nó có thể khiến bất kỳ ai khác mắc lại".
Vì sao đổ lỗi lại phản tác dụng về mặt kỹ thuật
Đây là điểm nhiều lãnh đạo bỏ qua: đổ lỗi không chỉ là vấn đề "tử tế" — nó là vấn đề chất lượng dữ liệu. Một postmortem chỉ hữu ích khi nó phản ánh chính xác chuỗi sự kiện thực tế. Nhưng con người khi sợ bị trừng phạt sẽ bóp méo sự thật một cách vô thức: họ bỏ qua chi tiết bất lợi, kể lại theo hướng có lợi cho mình, không dám thừa nhận "tôi không hiểu đoạn code đó nhưng vẫn deploy".
Khi văn hóa đổ lỗi ngự trị, bạn mất đi near-miss reporting — những suýt-sự-cố. Kỹ sư sẽ không bao giờ chủ động báo "hôm nay tôi suýt xóa nhầm database production nhưng may dừng kịp", vì báo lên chỉ tổ chuốc rắc rối. Trong khi đó, chính những near-miss này là mỏ vàng: chúng cho bạn biết chỗ yếu của hệ thống trước khi nó gây thiệt hại thật.
Counterfactual và ngôn ngữ trung lập
Một khái niệm kỹ thuật quan trọng là tránh counterfactual reasoning — kiểu suy luận "lẽ ra". "Lẽ ra anh ta phải chạy test", "nếu cô ấy cẩn thận hơn thì đã không sao". Những câu này vô dụng vì chúng mô tả một thế giới không tồn tại. Con người đó đã không chạy test — câu hỏi hữu ích là: tại sao trong ngữ cảnh lúc đó, không chạy test lại là một hành động hợp lý? Có phải test mất 40 phút? Có phải deadline gấp? Có phải không ai biết test đó tồn tại?
Cách bạn viết ra cũng quan trọng. So sánh:
- "Nam deploy code lỗi làm sập hệ thống." (đổ lỗi, ám chỉ)
- "Bản build chứa lỗi ở module tính phí được đưa lên production lúc 09:14; pipeline không có bước kiểm thử regression cho module này." (trung lập, mô tả hệ thống)
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT "ShopViet": sập giỏ hàng ngày sale đôi
ShopViet (giả định, một sàn thương mại điện tử tại TP.HCM, khoảng 120 kỹ sư) gặp sự cố lớn vào ngày 11/11 — ngày sale lớn nhất năm. Đúng 20:00 khi flash sale mở, dịch vụ giỏ hàng quá tải và sập trong 23 phút, ước tính mất khoảng 1,8 tỷ đồng doanh thu.
Nguyên nhân trực tiếp: một kỹ sư backend tên Hùng đã đẩy một thay đổi cấu hình connection pool xuống database từ chiều hôm đó, giảm số kết nối tối đa để "tối ưu tài nguyên". Trong ngày thường, thay đổi này vô hại. Nhưng dưới tải flash sale, pool cạn kiệt kết nối và toàn bộ request giỏ hàng bị nghẽn.
Trong cuộc họp postmortem, tech lead — thay vì hỏi "sao lại đổi config sát ngày sale?" — đã dẫn dắt theo hướng khác. Chị đặt câu hỏi: Tại sao hệ thống của chúng ta cho phép một thay đổi cấu hình hạ tầng đi lên production mà không ai review, và không có cờ đóng băng (change freeze) trước ngày sale lớn nhất năm?
Kết quả điều tra hé lộ nhiều tầng: (1) không có quy trình change freeze cho các sự kiện high-traffic; (2) thay đổi config không nằm trong version control nên không đi qua code review; (3) không có load test mô phỏng tải flash sale; (4) Hùng thậm chí không biết ngày 11/11 là sự kiện đặc biệt vì anh mới vào 3 tuần, chưa ai onboard cho anh về lịch business.
Bài học rút ra: Nếu đội đã sa thải hoặc khiển trách Hùng, họ vẫn giữ nguyên bốn lỗ hổng hệ thống đó, và người tiếp theo sẽ lại vấp. Sau postmortem, ShopViet thiết lập change freeze tự động 72 giờ trước mọi sự kiện lớn, đưa toàn bộ config vào Git, và bổ sung một mục "lịch business quan trọng" vào tài liệu onboarding. Sự cố tốn 1,8 tỷ, nhưng bốn hành động cải tiến đó ngăn được vô số sự cố tương lai.
Ví dụ 2 — Fintech "PayNhanh": lỗi được che giấu suýt thành thảm họa
PayNhanh (giả định, ví điện tử) từng có văn hóa "tìm thủ phạm". Mỗi sự cố kết thúc bằng việc một cái tên bị nêu trong email gửi toàn công ty. Kết quả tất yếu: kỹ sư học cách che giấu.
Một lần, một kỹ sư DevOps phát hiện mình vô tình cấp quyền truy cập rộng hơn cần thiết cho một service account — về lý thuyết có thể đọc được dữ liệu KYC của khách hàng. Không có bằng chứng bị khai thác, nhưng đó là một lỗ hổng bảo mật nghiêm trọng. Vì sợ bị nêu tên, anh im lặng tự sửa và không báo cáo. Ba tháng sau, trong một đợt audit bảo mật bên ngoài, lỗ hổng tương tự ở một service khác bị phát hiện — và lần này đã có log cho thấy truy cập bất thường.
Khi ban lãnh đạo truy ngược, họ nhận ra: nếu lỗ hổng đầu tiên được báo cáo minh bạch ngay từ đầu như một near-miss, đội đã có thể rà soát toàn bộ chính sách phân quyền và bịt cả service thứ hai. Văn hóa đổ lỗi đã trực tiếp làm chậm việc phát hiện một vấn đề nghiêm trọng suốt ba tháng.
Bài học rút ra: Cái giá của văn hóa đổ lỗi không phải là "kỹ sư buồn". Cái giá là thông tin an toàn bị chôn giấu. PayNhanh sau đó chuyển sang blameless, và điểm bước ngoặt là khi CTO công khai cảm ơn — chứ không phạt — kỹ sư đầu tiên dám tự báo cáo một sai lầm của mình trong postmortem. Hành động đó gửi tín hiệu mạnh hơn mọi tuyên bố chính sách.
Ví dụ 3 — Bài học kinh điển từ GitLab và AWS
Không cần bịa để có ví dụ mạnh. Năm 2017, một kỹ sư GitLab trong lúc xử lý sự cố database đã gõ nhầm lệnh và xóa thư mục dữ liệu production, mất khoảng 6 giờ dữ liệu. Điều đáng nói: GitLab livestream quá trình khôi phục trên YouTube và công bố postmortem chi tiết công khai, không nêu tên để trừng phạt mà mô tả rõ năm cơ chế backup đều thất bại theo những cách khác nhau. Người kỹ sư đó không bị đuổi. Cộng đồng, thay vì chê cười, lại khen ngợi sự minh bạch — và GitLab học được rằng "có backup" khác xa "backup thực sự khôi phục được".
Tương tự, sự cố AWS S3 năm 2017 (sập một phần lớn Internet ở Mỹ) bắt nguồn từ một kỹ sư gõ sai tham số một câu lệnh trong quy trình vận hành bình thường. Postmortem của AWS không nhắc tên người đó một lần nào; nó tập trung vào việc công cụ đã cho phép gỡ quá nhiều capacity cùng lúc, và cam kết thêm safeguard.
Bài học rút ra: Những công ty vận hành hệ thống đáng tin cậy nhất thế giới đều chọn blameless không phải vì họ tử tế, mà vì họ hiểu đó là con đường kỹ thuật duy nhất dẫn tới độ tin cậy cao.
Hướng dẫn từng bước
Template postmortem blameless
Một postmortem tốt nên có các mục sau. Bạn có thể dùng làm mẫu chuẩn cho đội:
- Summary (Tóm tắt) — Sự cố gì, ảnh hưởng ai, mức độ nghiêm trọng, thời lượng. Viết ngắn gọn để một người ngoài đội đọc trong 30 giây là hiểu. Ví dụ: "Dịch vụ giỏ hàng không phản hồi trong 23 phút (20:00–20:23, 11/11), ảnh hưởng ~100% người dùng đang mua sắm, ước tính mất 1,8 tỷ doanh thu."
- Impact (Tác động) — Định lượng cụ thể: bao nhiêu người dùng, bao nhiêu request lỗi, bao nhiêu tiền, có vi phạm SLA/SLO không. Con số làm postmortem có sức nặng và giúp ưu tiên hành động.
- Timeline (Dòng thời gian) — Mốc thời gian chi tiết, dùng timestamp và múi giờ rõ ràng: khi nào lỗi được đưa vào, khi nào alert kêu, khi nào phát hiện, khi nào bắt đầu xử lý, khi nào khôi phục. Đây là xương sống của điều tra.
- Root cause analysis (Phân tích nguyên nhân gốc) — Dùng kỹ thuật 5 Whys hoặc phân tích nhiều nguyên nhân. Đào sâu qua nguyên nhân bề mặt để chạm tới nguyên nhân hệ thống. Nhớ: hầu hết sự cố lớn không có một nguyên nhân duy nhất mà là chuỗi nhiều lỗ hổng cùng xếp hàng (mô hình "phô mai Thụy Sĩ").
- What went well / What went poorly (Điều làm tốt / chưa tốt) — Đừng chỉ ghi cái sai. Ghi cả cái đúng: alert kêu đúng lúc, quy trình rollback nhanh. Điều này giúp đội biết cái gì đáng giữ.
- Action items (Hành động cải tiến) — Phần quan trọng nhất. Mỗi hành động phải có người chịu trách nhiệm cụ thể, thời hạn, và được đưa vào backlog như một ticket thực sự. Ưu tiên các hành động sửa hệ thống (thêm test, thêm guardrail) hơn là "nhắc nhở mọi người cẩn thận hơn".
Cách chạy 5 Whys mà không biến thành 5 lời buộc tội
Với sự cố giỏ hàng ở trên: Tại sao sập? → Pool cạn kết nối. Tại sao cạn? → Config giảm số kết nối tối đa. Tại sao config đó lên production? → Không có review cho thay đổi config. Tại sao không có review? → Config không nằm trong Git. Tại sao lại đổi vào ngày sale? → Người thực hiện không biết về sự kiện. Bạn thấy không — mỗi câu "why" hướng vào hệ thống, không vào con người.
Quy trình vận hành
- Kích hoạt: Mọi sự cố từ mức nghiêm trọng nhất định (ví dụ SEV1, SEV2) bắt buộc có postmortem. Đừng chỉ làm khi "có ai đó yêu cầu".
- Thời điểm: Viết trong vòng 24–48 giờ khi ký ức còn tươi, nhưng đủ xa để mọi người bớt căng thẳng.
- Người viết: Thường là người dẫn dắt xử lý sự cố hoặc một facilitator trung lập, không phải "người gây lỗi" tự viết bản kiểm điểm.
- Cuộc họp review: Mời những người liên quan, đọc cùng nhau, bổ sung góc nhìn. Facilitator có nhiệm vụ chặn ngay mọi câu mang tính buộc tội, chuyển hướng về hệ thống.
- Lưu trữ và chia sẻ: Postmortem phải được lưu ở nơi cả công ty đọc được (wiki, kho tài liệu). Kiến thức bị khóa trong một đội là kiến thức lãng phí. Định kỳ đọc lại các postmortem cũ để tìm mẫu lặp.
Lỗi thường gặp & mẹo
Lỗi 1 — Blameless trên giấy, blameful trong phòng họp. Bạn viết tài liệu rất trung lập, nhưng trong cuộc họp mọi ánh mắt vẫn đổ dồn về "người gây lỗi", giọng điệu vẫn trách móc. Văn hóa nằm ở hành vi thực tế, không ở template. Mẹo: tech lead phải làm gương bằng cách chính mình thừa nhận sai lầm trước, tạo an toàn tâm lý.
Lỗi 2 — Action items không bao giờ được làm. Rất nhiều postmortem kết thúc với 10 hành động cải tiến rồi… nằm im. Postmortem không có follow-through chỉ là liệu pháp cảm xúc. Mẹo: mỗi action item thành một ticket có owner và deadline; review tiến độ trong stand-up hoặc sprint planning. Nếu bạn không định làm một action, đừng ghi nó vào.
Lỗi 3 — Quá nhiều action, không ưu tiên. Ngược lại với lỗi trên: đội liệt kê 25 việc, quá tải, làm loãng. Mẹo: chọn 3–5 hành động có đòn bẩy cao nhất — thường là các guardrail chặn cả một lớp lỗi.
Lỗi 4 — Chỉ dừng ở nguyên nhân kỹ thuật gần nhất. "Do lỗi null pointer." OK, nhưng tại sao null pointer đó lọt qua? Mẹo: đào tới tầng hệ thống và quy trình. Nguyên nhân gốc hiếm khi là một dòng code.
Lỗi 5 — Xử tệ near-miss. Có đội chỉ làm postmortem khi khách hàng bị ảnh hưởng thật. Mẹo: khuyến khích cả postmortem cho suýt-sự-cố. Đây là cách rẻ nhất để học.
Mẹo văn hóa: Khi ai đó dũng cảm tự nhận "chính tôi đã gõ lệnh đó", phản ứng đầu tiên của lãnh đạo nên là cảm ơn vì sự minh bạch. Khoảnh khắc đó định hình văn hóa mạnh hơn bất kỳ chính sách nào.
Bài tập thực hành
- Viết lại theo ngôn ngữ trung lập. Lấy ba câu sau và viết lại theo hướng blameless, tập trung vào hệ thống: (a) "Lan làm sập server vì quên tắt debug mode." (b) "Đội QA lười nên không phát hiện bug." (c) "Vì Minh không đọc tài liệu nên deploy sai phiên bản."
- Thực hành 5 Whys. Chọn một sự cố gần đây trong công việc của bạn (dù nhỏ) và viết ra chuỗi 5 câu hỏi "tại sao", đảm bảo mỗi câu trả lời hướng về hệ thống/quy trình chứ không về một cá nhân. Nếu bạn thấy mình đang chỉ tay vào một người, hãy hỏi tiếp: "hệ thống nào đã cho phép điều đó?"
- Soạn template cho đội. Dựa trên sáu mục trong bài, tạo một template postmortem chuẩn cho đội bạn (dạng file markdown trong wiki). Thêm một checklist facilitator gồm 3 câu nhắc để giữ cuộc họp blameless.
- Audit action items cũ. Nếu đội bạn đã có postmortem trước đây, hãy rà lại: bao nhiêu phần trăm action item thực sự được hoàn thành? Đây là thước đo trung thực nhất cho việc postmortem của bạn có giá trị thật hay chỉ là hình thức.
Tóm tắt
Postmortem blameless không phải là tỏ ra tử tế — nó là chiến lược kỹ thuật để xây hệ thống đáng tin cậy. Mục tiêu không bao giờ là tìm thủ phạm, mà là học để không lặp lại. Ba ý cần nhớ:
Thứ nhất, tách con người khỏi hệ thống. Giả định thiện chí cơ bản: không ai đến làm để phá hoại. Khi một người giỏi mắc lỗi, hãy hỏi hệ thống nào đã cho phép lỗi đó gây thiệt hại lớn, thay vì hỏi "ai".
Thứ hai, đổ lỗi hủy hoại chất lượng dữ liệu. Sợ hãi khiến người ta che giấu sự thật và không báo near-miss — chính là thứ thông tin quý nhất để phòng ngừa. Ngôn ngữ trung lập và tránh suy luận "lẽ ra" giữ cho postmortem trung thực.
Thứ ba, giá trị nằm ở action items được thực thi. Một postmortem đẹp nhưng không ai làm gì tiếp theo chỉ là giấy. Mỗi hành động phải có owner, deadline, và ưu tiên các guardrail chặn cả một lớp lỗi.
Với vai trò tech lead, cách bạn dẫn dắt cuộc họp sau sự cố sẽ quyết định đội của bạn ngày càng khôn ngoan hay ngày càng sợ hãi. Hãy chọn khôn ngoan.