Website lỗi gần 2 tiếng đã sửa xong, báo cáo sau sự cố viết gì?

Chiều thứ Hai, trang đặt hàng của cửa hàng online treo gần 2 tiếng sau lần cập nhật. Cả đội sửa xong trong buổi tối, rồi 2 tuần sau một lỗi gần giống xảy ra lại. Đây là tình huống minh họa, không phải sự cố của công ty nào.

Thứ còn thiếu là báo cáo sau sự cố (postmortem): bản ghi viết sau khi lỗi đã xử lý xong, nói rõ chuyện gì xảy ra, vì sao, và cần làm gì để lần sau đỡ lặp lại. Bài dựa trên sách của Google, tài liệu của Atlassian và PagerDuty, và bài "How Complex Systems Fail" của Richard Cook, đối chiếu ngày 26/10/2026.

Điểm chính

• Báo cáo sau sự cố ghi lại tác động, cách xử lý, nguyên nhân và việc ngăn lặp lại. Quay lui bản lỗi chỉ khôi phục dịch vụ, không giải thích vì sao lỗi xảy ra.
• Nên đặt ngưỡng bắt buộc viết trước khi sự cố xảy ra. Các trang đã đọc không nêu số phút sập đủ lớn để phải viết.
• Không đổ lỗi nghĩa là hỏi vì sao hệ thống cho phép sai sót, không hỏi ai sai.
• "5 lần hỏi vì sao" có ích nếu không ép về 1 nguyên nhân duy nhất: Atlassian bảo vệ cách này và cho phép chuỗi thành cây nhiều yếu tố, còn PagerDuty (dẫn Richard Cook) khuyên tìm các yếu tố góp phần thay vì 1 nguyên nhân gốc.
• Phần quyết định là việc cần làm: mỗi việc cụ thể, có 1 người phụ trách, 1 hạn (khung của Click Star), và nằm trong bảng việc đội dùng hằng ngày.

Báo cáo sau sự cố là gì và vì sao không nên bỏ qua

Báo cáo sau sự cố là bản ghi về 1 sự cố, gồm tác động, việc đã làm để xử lý, nguyên nhân và các việc để ngăn nó lặp lại. Định nghĩa này theo sách SRE của Google (bản quyền 2017) và khớp với sổ tay của Atlassian.

Sửa xong chưa có nghĩa là hiểu xong. Theo Atlassian, quay lui thay đổi lỗi (rollback) khôi phục dịch vụ nhưng không cho biết cái gì hỏng và vì sao. Google viết rằng nếu không có quy trình học chính thức, sự cố có thể lặp lại không dứt.

Click Star đã có bài riêng về giám sát website, về sao lưu và khôi phục dữ liệu, và về tài liệu hóa dự án. Bài này nói phần sau sự cố.

Khi nào nên viết báo cáo và viết trong bao lâu

Hãy ghi ngưỡng ra giấy trước khi sự cố xảy ra, để lúc mệt không phải tranh luận có nên viết hay không.

Google nêu 5 dấu hiệu hay dùng làm ngưỡng: khách thấy lỗi hoặc chậm vượt mức nào đó, mất dữ liệu, kỹ sư trực phải can thiệp (như quay lui bản phát hành), thời gian xử lý vượt mức nào đó, và giám sát không phát hiện được lỗi. Chương sách không nêu số ngày.

Atlassian làm báo cáo cho sự cố mức nghiêm trọng 1 và 2, còn PagerDuty làm với mọi sự cố lớn (mức 2 và 1), kể cả báo động giả.

Về hạn, Atlassian (trang Incident Postmortem) khuyên họp rà soát trong 24 đến 48 giờ sau khi xử lý xong, không quá 5 ngày làm việc. PagerDuty đặt 3 ngày lịch cho mức 1 và 5 ngày làm việc cho mức 2 để hoàn tất báo cáo và họp.

Đó là chính sách riêng của từng công ty, không phải chuẩn chung.

Khung tham khảo của Click Star, không lấy từ nguồn ngoài: đội nhỏ viết báo cáo khi có 1 trong 4 dấu hiệu. Khách báo trước khi đội biết. Mất hoặc sai dữ liệu. Phải quay lui hoặc khôi phục từ bản sao lưu. Lỗi kéo dài quá mức tự ghi trong quy định nội bộ.

Không đổ lỗi: cách làm và vì sao có lợi

Không đổ lỗi nghĩa là tìm hiểu hệ thống đã cho phép sai sót xảy ra như thế nào, thay vì tìm ai sai. Theo Google, báo cáo kiểu này giả định mọi người đều có thiện chí, và nếu văn hóa là chỉ trích thì người ta không đưa vấn đề ra vì sợ bị phạt.

Ví dụ minh họa: nhân viên chạy lệnh cập nhật đúng giờ cao điểm. Bản đổ lỗi viết "bạn A bất cẩn". Bản không đổ lỗi hỏi: có quy định cấm cập nhật giờ cao điểm không, và có bước kiểm tra nào chặn lệnh đó không?

3 cách làm từ các tài liệu:

• Mở cuộc họp bằng việc nhắc đây là buổi không đổ lỗi, và gọi người theo vai trò như "kỹ sư trực" thay vì tên (Atlassian).
• Hỏi "cái gì" và "như thế nào" thay vì "ai" và "vì sao"; nếu hỏi "vì sao" thì hướng vào cách hệ thống được thiết kế (PagerDuty).
• Dựng dòng thời gian từ trước sự cố rồi đi tiếp, không đi ngược từ lúc sửa xong, để tránh nhìn lại bằng kết quả đã biết (PagerDuty).

Không đổ lỗi không có nghĩa là không ai chịu trách nhiệm. PagerDuty và Google đều ưu tiên 1 người phụ trách báo cáo, và PagerDuty nói người này không phải người gây ra sự cố.

Nguyên nhân: "5 lần hỏi vì sao" và giới hạn của nó

Nên hỏi "vì sao" nhiều lần đến khi chạm tới thứ có thể thay đổi, nhưng đừng tin chắc chỉ có 1 nguyên nhân gốc. Atlassian phân biệt nguyên nhân gần (trực tiếp gây sự cố) và nguyên nhân gốc (chỗ mà thay đổi sẽ ngăn cả loại sự cố đó).

Ví dụ minh họa với sự cố giả ở đầu bài:

• Vì sao trang đặt hàng treo? Vì bản cập nhật làm bảng đơn hàng bị khóa.
• Vì sao bản cập nhật chạy giờ cao điểm? Vì chưa có quy định về giờ triển khai.
• Vì sao gần 2 tiếng mới khôi phục? Vì cảnh báo chỉ kiểm tra trang chủ, khách gọi mới biết.
• Vì sao chỉ kiểm tra trang chủ? Vì chưa ai lập danh sách trang quan trọng.

Chuỗi dừng ở 4 câu vì đã chạm tới thứ sửa được. Nguyên nhân gần là bản cập nhật. Thứ cần đổi là quy định giờ triển khai và danh sách trang phải giám sát.

Các nguồn nhấn khác nhau. Atlassian bảo vệ 5 whys, nói con số 5 chỉ là cách gọi, và cho phép chuỗi thành cây nhiều yếu tố. PagerDuty không bàn trực tiếp về 5 whys, nhưng khuyên tìm các yếu tố góp phần thay vì 1 nguyên nhân gốc, và dẫn Richard Cook cho rằng gán 1 nguyên nhân gốc là sai về bản chất.

Bài của Cook nói về hệ thống phức tạp nói chung, có đề cập an toàn bệnh nhân. Việc áp dụng cho phần mềm là cách PagerDuty diễn giải.

Mẫu báo cáo 1 trang cho đội nhỏ

Báo cáo 1 trang đủ dùng nếu có 6 phần. Đây là khung tham khảo của Click Star, rút gọn từ mẫu của Google, Atlassian và PagerDuty, không phải mẫu chính thức của họ.

• Tóm tắt và tác động: lỗi gì, bao lâu, bao nhiêu khách hay đơn bị ảnh hưởng, bao nhiêu khách báo lỗi (PagerDuty).
• Dòng thời gian: giờ cụ thể kèm múi giờ như "14:12 giờ Việt Nam", không ghi "khoảng 14:00" (Atlassian), mỗi mốc kèm bằng chứng như đồ thị hay nhật ký (PagerDuty).
• Phát hiện và xử lý: ai hoặc hệ thống nào phát hiện, sau bao lâu, đã làm gì để khôi phục.
• Nguyên nhân và yếu tố góp phần: chuỗi "vì sao", tách nguyên nhân gần khỏi nguyên nhân sâu.
• Điều hiệu quả, điều chưa hiệu quả, điều may mắn: 3 câu hỏi này có trong cả Google và Atlassian.
• Việc cần làm: mỗi việc có 1 người, 1 hạn và đường dẫn đến công việc thật.

Viết việc cần làm để việc thật sự được làm

Khung của Click Star: mỗi việc cần 3 thứ, gồm hành động cụ thể, 1 người phụ trách và 1 hạn. Các nguồn nêu người phụ trách và mức ưu tiên, còn hạn do chính sách chung của đội. Theo SRE Workbook, với người dùng, báo cáo không có hành động tiếp theo cũng như không có báo cáo (lời Ben Treynor Sloss của Google).

Bài của John Lunney, Sue Lueder và Betsy Beyer trên tạp chí ;login: (USENIX, mùa xuân 2017) đề xuất 3 tiêu chí. Click Star đã mở bản PDF gốc và đối chiếu; PagerDuty và Atlassian cũng nêu lại.

• Hành động được: câu bắt đầu bằng động từ, cho ra kết quả hữu ích.
• Cụ thể: phạm vi hẹp, rõ cái gì có và không có trong việc này.
• Có giới hạn: nói rõ khi nào coi là xong.

Ví dụ trong bài gốc và tài liệu PagerDuty: "Điều tra giám sát cho tình huống này" nên viết thành "Thêm cảnh báo cho mọi trường hợp dịch vụ trả lỗi trên 1%".

Về hạn, Atlassian đặt 4 hoặc 8 tuần cho việc ưu tiên, tùy dịch vụ. PagerDuty nêu ví dụ chính sách của họ: việc ưu tiên cao để sự cố mức 1 không lặp lại làm trong 15 ngày, việc từ sự cố mức 2 làm trong 30 ngày.

PagerDuty còn khuyên mở việc trong công cụ quản lý công việc của đội, gắn nhãn mức nghiêm trọng và ngày, và chỉ mở những việc thật sự phải làm.

Chia sẻ báo cáo cho đội và cho khách

Google khuyên chia sẻ cho nhóm rộng nhất có thể học từ nó và rà soát từng báo cáo, vì báo cáo chưa được rà soát coi như chưa có. SRE Workbook gợi ý cân nhắc chia sẻ cả với khách để lấy lại niềm tin, còn Atlassian lưu ý đăng công khai không phù hợp trong mọi trường hợp.

PagerDuty mô tả bản gửi khách là bản rút gọn, đã lược thông tin nhạy cảm, gồm 3 phần: tóm tắt 2 đến 3 câu, chuyện gì xảy ra, và đang làm gì. PagerDuty cũng khuyên tránh chữ "sập hoàn toàn" (outage) trừ khi dịch vụ thật sự ngừng hẳn.

Đội nhỏ ở Việt Nam nên bắt đầu thế nào

Click Star không tìm thấy số đo nào cho Việt Nam về tần suất sự cố hay chi phí gián đoạn. Các nguồn đều từ công ty lớn có đội trực riêng, nên không nên sao chép nguyên.

Đánh giá của Click Star. Giá trị lớn nhất nằm ở việc đóng được các việc sau báo cáo, không ở văn bản đẹp. Với đội nhỏ, 1 trang viết trong vài ngày sau sự cố có ích hơn tài liệu dài viết sau 1 tháng, vì chi tiết còn nhớ.

Với 5 whys, hãy hỏi qua triệu chứng, hướng câu hỏi vào hệ thống thay vì vào người, và dừng khi có các yếu tố sửa được. Đây là nhận định, không phải kết quả đo.

Về lợi ích: Click Star làm dịch vụ website chuẩn SEO tải nhanh và phần mềm theo yêu cầu, nên quan tâm đến vận hành ổn định.

Lộ trình 4 tuần

Khung tham khảo của Click Star, không lấy từ nguồn ngoài:

• Tuần 1: ghi ngưỡng viết báo cáo vào quy định nội bộ, quy ước cách chọn 1 người phụ trách, tạo mẫu 1 trang.
• Tuần 2: thử mẫu với sự cố gần nhất, dựng dòng thời gian từ nhật ký, họp 30 phút không đổ lỗi.
• Tuần 3: viết việc cần làm theo 3 tiêu chí, đưa vào bảng việc kèm nhãn mức nghiêm trọng và ngày, đặt hạn.
• Tuần 4: rà việc quá hạn, quyết định việc nào không làm và ghi lý do, gửi bản tóm tắt cho cả đội.

Cách đo quy trình có hiệu quả không

Hãy đo việc đóng và việc lặp lại, không đo số báo cáo đã viết. Khung tham khảo của Click Star, các nguồn không nêu mức chuẩn:

• Tỷ lệ việc cần làm đóng đúng hạn.
• Số sự cố lặp lại cùng yếu tố góp phần.
• Thời gian phát hiện và thời gian xử lý, hai số mà Google dùng để xem xu hướng.

Điều chưa biết

• Chưa có số đo cho Việt Nam về tần suất sự cố website, chi phí gián đoạn hay mức áp dụng báo cáo sau sự cố.
• Google viết rằng văn hóa này giúp họ gặp ít sự cố hơn, nhưng chương sách không kèm số đo, và Click Star chưa thấy nghiên cứu độc lập đo mức giảm.
• Bài của John Allspaw về báo cáo không đổ lỗi (đăng ở Etsy) được Atlassian dẫn làm nền tảng. Công cụ của Click Star không mở được trang Etsy, nên bài không dùng nội dung đó.
• Các trang đã đọc không nêu hạn chuẩn cho đội nhỏ, và chưa có bằng chứng so sánh trực tiếp 5 whys với cách khác.

Những sai lầm thường gặp

1. Sửa xong rồi bỏ qua vì "đã biết nguyên nhân", dù người khác trong đội chưa biết.
2. Viết quá muộn, khi chi tiết đã quên.
3. Ghi "lỗi do nhân viên" làm nguyên nhân, thay vì hỏi vì sao hệ thống cho phép.
4. Viết việc mơ hồ như "cải thiện giám sát", không người, không hạn.
5. Dùng chữ "sập hoàn toàn" trong thư gửi khách khi dịch vụ chỉ suy giảm cục bộ.
6. Viết xong mà không ai đọc hay rà soát.