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 công ty bạn sập trong 47 phút. Sáng hôm sau, cả team ngồi vào phòng họp. Câu hỏi đầu tiên của sếp là: "Ai đã deploy cái commit đó?". Không khí đông cứng. Người kỹ sư trực đêm hôm qua cúi mặt. Từ giây phút đó, mọi người trong phòng đều rút ra một bài học — nhưng không phải bài học kỹ thuật. Bài học họ rút ra là: lần sau, đừng để bị bắt.
Đây chính là lý do tại sao "blameless postmortem" — biên bản phân tích sự cố không đổ lỗi — lại là một trong những kỹ năng giao tiếp quan trọng bậc nhất mà một tech team có thể xây dựng. Ở Bài 23, chúng ta đã bàn về giao tiếp trong giờ đầu tiên khi sự cố đang xảy ra (Incident Communication). Bài 24 này nói về chuyện xảy ra sau đó: khi khói đã tan, hệ thống đã ổn định, và team ngồi lại để hiểu chuyện gì đã thực sự xảy ra.
Postmortem không phải là một tài liệu kỹ thuật khô khan. Nó là một hành động giao tiếp mang tính văn hóa. Cách bạn viết và điều phối một postmortem sẽ quyết định: liệu team của bạn có học được điều gì thật, hay chỉ học được cách che giấu. Với vai trò một kỹ sư — dù bạn là IC hay tech lead — biết cách viết và tham gia postmortem một cách "blameless" là kỹ năng giúp bạn được tin tưởng, giúp hệ thống bền vững hơn, và giúp bạn giữ được sự tỉnh táo khi mọi thứ cháy.
Khái niệm cốt lõi
"Blameless" thực sự nghĩa là gì?
Blameless không có nghĩa là "không ai chịu trách nhiệm" hay "mọi lỗi đều được tha thứ". Đó là hiểu lầm phổ biến nhất. Blameless nghĩa là chúng ta chuyển trọng tâm phân tích từ con người sang hệ thống và quy trình.
Triết lý nền tảng của nó rất đơn giản và rất người: con người sẽ luôn mắc lỗi. Đây không phải điều có thể sửa được bằng cách la mắng, cảnh cáo hay sa thải. Một kỹ sư giỏi vẫn sẽ gõ nhầm lệnh lúc 2 giờ sáng. Một người cẩn thận vẫn sẽ copy nhầm config production và staging. Nếu một cá nhân có thể làm sập cả hệ thống chỉ bằng một thao tác, thì lỗi không nằm ở cá nhân đó — lỗi nằm ở việc hệ thống đã cho phép một thao tác đơn lẻ gây ra hậu quả lớn đến vậy.
Câu hỏi cốt lõi của blameless postmortem không phải là "Ai gây ra chuyện này?" mà là "Điều gì trong hệ thống của chúng ta đã khiến sai lầm này trở nên khả thi và trở nên nghiêm trọng?"
Second Story: đằng sau "lỗi con người"
Có một khái niệm hay từ ngành an toàn hàng không và y tế, gọi là "second story". "First story" luôn là: "Anh A xóa nhầm database, thế là sập." Đó là câu chuyện dễ kể và dễ khép lại. Nhưng "second story" hỏi tiếp: Tại sao lệnh xóa database production lại không có bước xác nhận? Tại sao credential production lại nằm sẵn trong terminal của anh A? Tại sao không có backup tự động? Tại sao anh A phải làm việc đó một mình lúc nửa đêm mà không có ai review?
Khi bạn khai thác second story, bạn nhận ra "lỗi con người" gần như luôn là triệu chứng, không phải nguyên nhân. Và triệu chứng thì không đáng để sửa — nguyên nhân mới đáng.
Tại sao đổ lỗi lại phá hủy an toàn
Đây là điểm mà nhiều quản lý ở Việt Nam chưa thấm: văn hóa đổ lỗi trực tiếp làm giảm độ an toàn của hệ thống, chứ không tăng.
Khi người ta sợ bị đổ lỗi, họ sẽ giấu thông tin. Họ không dám khai báo lỗi sớm. Họ không viết đúng những gì đã xảy ra. Họ không dám nói "thực ra tôi đã bỏ qua bước kiểm tra vì đang gấp". Và khi bạn mất đi những thông tin trung thực đó, postmortem của bạn trở thành một tài liệu chính trị — đúng về mặt hình thức nhưng vô dụng về mặt học hỏi. Ngược lại, khi người ta biết rằng nói thật sẽ không bị trừng phạt, họ sẽ kể hết. Và chỉ khi có sự thật đầy đủ, bạn mới sửa được hệ thống.
Postmortem gồm những gì?
Một biên bản postmortem tiêu chuẩn thường có: tóm tắt (summary) ngắn gọn về sự cố, mức độ ảnh hưởng (impact — bao nhiêu user, bao nhiêu tiền, bao lâu), timeline chi tiết theo mốc thời gian, phân tích nguyên nhân gốc (root cause), phần "cái gì đã diễn ra tốt / chưa tốt / gặp may", và cuối cùng là danh sách action items có người phụ trách và deadline rõ ràng. Chúng ta sẽ đi qua từng phần ở mục "Hướng dẫn từng bước".
Tình huống thực tế
Tình huống 1: Fintech Việt và cú xóa nhầm bảng giao dịch
Một công ty fintech tại TP.HCM (gọi là công ty M, khoảng 40 kỹ sư) gặp sự cố nghiêm trọng. Một kỹ sư backend tên Tuấn chạy một script migration lúc 23h để dọn dữ liệu test. Do biến môi trường trỏ nhầm, script chạy trên database production và xóa mất 3 giờ dữ liệu giao dịch trước khi bị phát hiện. Khoảng 12.000 giao dịch phải khôi phục thủ công từ log, mất gần 2 ngày công của 4 người.
Phiên bản "có đổ lỗi": Sếp gọi Tuấn lên, kết luận "cẩu thả, thiếu tập trung", ghi vào đánh giá cuối kỳ. Tuấn im lặng, vài tháng sau nghỉ việc. Vấn đề gốc — script migration không phân biệt môi trường — vẫn còn nguyên.
Phiên bản "blameless" mà team M cuối cùng đã chọn: Postmortem chỉ ra rằng script không có cơ chế kiểm tra môi trường trước khi chạy, biến DATABASE_URL được share chung trong .env của cả dev lẫn prod, và không có ai bắt buộc review migration chạy trên prod. Action items sinh ra: (1) mọi migration production phải qua một wrapper hiển thị đỏ chói "BẠN ĐANG CHẠY TRÊN PRODUCTION" và yêu cầu gõ tên database để xác nhận; (2) tách hoàn toàn credential prod ra khỏi máy cá nhân; (3) bật point-in-time recovery cho database. Sáu tháng sau, một kỹ sư khác suýt lặp lại lỗi tương tự — nhưng wrapper đã chặn kịp.
Bài học: cùng một sự cố, hai cách xử lý cho ra hai kết quả trái ngược. Đổ lỗi làm mất một người và giữ lại lỗ hổng. Blameless giữ được người và vá được lỗ hổng.
Tình huống 2: GitLab và cú xóa database công khai năm 2017
Đây là một ví dụ có thật, kinh điển trong ngành. Năm 2017, một kỹ sư của GitLab, trong lúc xử lý sự cố về database replication lúc đêm khuya và trong trạng thái mệt mỏi, đã vô tình chạy lệnh xóa thư mục dữ liệu trên primary database production thay vì trên máy phụ. Khoảng 300GB dữ liệu biến mất trong vài giây. Tệ hơn, khi kiểm tra lại, họ phát hiện 5 cơ chế backup/replication đều... không hoạt động đúng như mong đợi.
Điều khiến ngành công nghệ nhớ mãi vụ này không phải là lỗi, mà là cách GitLab phản ứng. Họ livestream cả quá trình khôi phục trên YouTube, viết một postmortem công khai cực kỳ chi tiết, và nêu đích danh vấn đề: không phải người kỹ sư kia, mà là năm lớp phòng thủ đã âm thầm hỏng mà không ai biết. Họ không sa thải người kỹ sư. Thay vào đó, họ đầu tư vào việc giám sát backup, thêm cơ chế cảnh báo, và làm cho lệnh nguy hiểm khó thực thi nhầm hơn.
Bài học: một sự cố tồi tệ, xử lý theo hướng blameless và minh bạch, lại tăng niềm tin của cộng đồng vào GitLab thay vì làm sụp đổ nó. Sự trung thực có sức mạnh xây dựng thương hiệu kỹ thuật mà tiền không mua được.
Tình huống 3: E-commerce Đông Nam Á và cái deadline bị bỏ quên
Một sàn thương mại điện tử khu vực (gọi là công ty S) gặp sự cố khác dạng: không phải ai xóa gì, mà là một certificate SSL hết hạn vào đúng ngày flash sale, khiến toàn bộ ứng dụng mobile không kết nối được API trong 26 phút cao điểm, ước tính mất khoảng 180 triệu đồng doanh thu.
Phản xạ đầu tiên của quản lý là tìm "người phụ trách certificate". Nhưng khi làm postmortem blameless, team nhận ra sự thật khó chịu hơn: không có ai phụ trách cả. Certificate được cài từ 2 năm trước bởi một người đã nghỉ việc, không nằm trong bất kỳ hệ thống theo dõi nào, không có cảnh báo hết hạn, và tài liệu về nó không tồn tại. Đây không phải lỗi của một cá nhân — đây là lỗ hổng có tổ chức về "ownership" và "monitoring".
Action items: (1) đưa toàn bộ certificate vào một hệ thống quản lý tập trung với cảnh báo trước 30 ngày; (2) chạy một cuộc audit tìm mọi thứ "không có chủ"; (3) thiết lập nguyên tắc mọi tài nguyên hạ tầng phải có một team owner rõ ràng.
Bài học: blameless đặc biệt hữu ích khi lỗi thuộc về "khoảng trống" giữa mọi người — những chỗ mà văn hóa đổ lỗi sẽ không bao giờ tìm ra, vì đơn giản là không có ai để đổ.
Hướng dẫn từng bước
Bước 1 — Kích hoạt postmortem đúng lúc và đúng phạm vi. Không phải mọi sự cố đều cần postmortem đầy đủ. Hãy có tiêu chí rõ ràng: ví dụ, mọi sự cố mức SEV1/SEV2 (ảnh hưởng khách hàng, mất dữ liệu, downtime đáng kể) đều bắt buộc có postmortem. Tổ chức trong vòng 24–72 giờ sau khi sự cố được giải quyết — đủ gần để ký ức còn tươi, đủ xa để mọi người đã ngủ và bình tĩnh lại.
Bước 2 — Dựng timeline dựa trên sự thật, không dựa trên ký ức. Đây là phần nền móng. Thu thập từ log, từ lịch sử Slack, từ dashboard giám sát, từ commit history. Ghi theo mốc thời gian: 23:04 deploy commit X → 23:12 error rate tăng → 23:19 alert bắn → 23:47 rollback hoàn tất. Timeline phải khách quan và trung lập về mặt cảm xúc: viết "lệnh migration được chạy trên production" chứ không viết "Tuấn ẩu chạy nhầm lên production".
Bước 3 — Đào root cause, đừng dừng ở triệu chứng. Kỹ thuật phổ biến là "5 Whys" — hỏi "tại sao" nhiều lần cho đến khi chạm được nguyên nhân hệ thống. "Tại sao sập? Vì migration chạy nhầm prod. Tại sao chạy được lên prod? Vì credential prod nằm sẵn trên máy. Tại sao nằm sẵn? Vì chúng ta không tách môi trường..." Lưu ý: đừng để "5 Whys" biến thành đường thẳng dẫn tới một cá nhân. Sự cố thật thường có nhiều nguyên nhân đóng góp (contributing factors), không phải một root cause duy nhất.
Bước 4 — Phân tích What went well / What went wrong / Where we got lucky. Đây là phần thường bị bỏ qua nhưng cực giá trị. "Chỗ nào may mắn" đặc biệt quan trọng: nó phơi bày những rủi ro mà lần này bạn thoát được nhờ hên — và lần sau có thể sẽ không. Ví dụ: "Chúng ta may mắn vì kỹ sư trực tình cờ còn thức và thấy alert; nếu là 4 giờ sáng, downtime có thể đã kéo dài hàng giờ."
Bước 5 — Viết action items cụ thể, có chủ, có hạn. Một action item tồi: "Cần cẩn thận hơn khi deploy." Không đo được, không ai làm. Một action item tốt: "Thêm bước xác nhận môi trường bắt buộc vào migration wrapper — @Linh — trước 15/07." Mỗi action item cần: mô tả rõ, một người chịu trách nhiệm (owner), deadline, và được track như một task thật trong Jira/Linear, không để trôi.
Bước 6 — Điều phối cuộc họp một cách an toàn. Người dẫn (thường là một facilitator không liên quan trực tiếp) mở đầu bằng việc nhắc lại luật chơi: "Đây là buổi blameless, mục tiêu là hiểu hệ thống, không phải tìm người sai." Nếu ai đó bắt đầu chỉ trích cá nhân, facilitator phải nhẹ nhàng lái lại: "Ta hãy hỏi hệ thống đã cho phép điều đó xảy ra thế nào."
Bước 7 — Chia sẻ rộng rãi. Postmortem chỉ có giá trị khi được lưu lại và người khác đọc được. Lưu vào một kho tập trung, để team khác học từ sự cố của bạn mà không phải tự vấp phải.
Lỗi thường gặp & mẹo
Lỗi 1 — "Blameless giả". Trên giấy thì trung lập, nhưng trong phòng họp thì ánh mắt và giọng điệu vẫn dồn về một người. Nhân viên không ngốc; họ cảm nhận được. Mẹo: kiểm tra ngôn ngữ trong tài liệu — nếu tên riêng xuất hiện gắn với động từ tiêu cực ("A quên", "B bỏ qua"), hãy viết lại theo hướng hệ thống.
Lỗi 2 — Dừng ở root cause đầu tiên. Tìm được một nguyên nhân là dễ, và cảm giác nhẹ nhõm khiến ta muốn dừng. Nhưng sự cố lớn hiếm khi có một nguyên nhân. Hãy luôn hỏi: "Còn yếu tố nào khác góp phần không?"
Lỗi 3 — Action items không ai làm. Đây là cái chết thầm lặng phổ biến nhất. Postmortem viết đẹp, họp xong, rồi 6 tháng sau sự cố y hệt lặp lại vì action items chưa bao giờ được thực hiện. Mẹo: đưa action items vào sprint kế tiếp và review chúng ở retro.
Lỗi 4 — Biến "no blame" thành "no accountability". Blameless không phải là không có trách nhiệm. Con người vẫn chịu trách nhiệm thực hiện các cải tiến. Sự khác biệt: trách nhiệm hướng về tương lai (sửa hệ thống), không phải hình phạt hướng về quá khứ (trừng phạt lỗi).
Mẹo vàng cho IC: nếu bạn là người "gây ra" sự cố, hãy chủ động tình nguyện dựng timeline và viết postmortem. Điều này thể hiện sự chuyên nghiệp và giúp bạn chuyển hóa một khoảnh khắc xấu hổ thành một đóng góp có giá trị. Một kỹ sư dám nói "tôi đã chạy lệnh đó, và đây là những gì hệ thống lẽ ra nên ngăn tôi" được tôn trọng hơn nhiều so với người tìm cách chối.
Bài tập thực hành
Bài 1 — Viết lại cho blameless. Lấy câu sau và viết lại theo hướng tập trung vào hệ thống: "Hùng đã đẩy code lên production mà không test, làm sập trang chủ 20 phút." Gợi ý: hỏi tại sao code chưa test lại có thể lên production, và cơ chế nào lẽ ra phải chặn.
Bài 2 — Dựng timeline giả định. Chọn một sự cố nhỏ bạn từng chứng kiến (hoặc tưởng tượng: API chậm đột ngột lúc cao điểm). Viết một timeline 6–8 dòng theo mốc thời gian, hoàn toàn trung lập về cảm xúc, chỉ nêu sự kiện.
Bài 3 — 5 Whys. Với sự cố "certificate SSL hết hạn gây downtime" ở Tình huống 3, tự chạy 5 lần "tại sao" và viết ra 3 action items cụ thể, mỗi cái có owner (bạn tự đặt tên) và deadline.
Bài 4 — Săn "chỗ may mắn". Nhìn lại một sự cố trong team bạn và trả lời: "Lần đó chúng ta may mắn ở điểm nào? Nếu điều kiện xấu hơn một chút, hậu quả sẽ thế nào?" Viết 2–3 câu.
Tóm tắt
Blameless postmortem là một kỹ năng giao tiếp mang tính văn hóa, không chỉ là một tài liệu kỹ thuật. Cốt lõi của nó: chuyển trọng tâm từ "ai sai" sang "hệ thống nào đã cho phép điều này xảy ra", vì con người luôn mắc lỗi và điều đó không thể sửa bằng trừng phạt. Một postmortem tốt gồm timeline dựa trên sự thật, phân tích root cause đa yếu tố qua kỹ thuật như 5 Whys, phần "may mắn ở đâu", và trên hết là các action items cụ thể có chủ và có hạn.
Ba tình huống — fintech Việt xóa nhầm database, GitLab với sự cố công khai năm 2017, và sàn e-commerce với certificate vô chủ — đều cho thấy cùng một chân lý: đổ lỗi làm mất người và giữ lại lỗ hổng, còn blameless giữ được người, vá được hệ thống, và xây được niềm tin. Là một kỹ sư, khả năng viết và điều phối một postmortem trung thực, không đổ lỗi, chính là dấu hiệu của sự trưởng thành nghề nghiệp — và là món quà bạn tặng cho hệ thống, cho đồng đội, và cho chính bạn của tương lai.