Playbook viết postmortem blameless với AI hỗ trợ
Dùng AI để cấu trúc bản nháp postmortem, nhưng chỉ coi đó là trợ lý soạn thảo. Timeline, tác động, nguyên nhân đóng góp và action item phải dựa trên bằng chứng, được người phụ trách kiểm tra trước khi chia sẻ.
Một incident vừa được giảm thiểu: traffic đã được chuyển hướng, rollback hoàn tất, dịch vụ dần ổn định. Nhưng phần khó thường mới bắt đầu: dashboard, log, ticket và trao đổi trong lúc xử lý vẫn nằm rải rác ở nhiều nơi.
Nếu postmortem chỉ là timeline chắp vá, đội sẽ khó học được gì. Nếu nó biến thành tài liệu truy tìm người mắc lỗi, các vấn đề lại càng dễ bị che giấu.
AI có thể hỗ trợ gom thông tin và tạo bản nháp. Tuy vậy, giá trị của quy trình không nằm ở việc “để AI viết hộ”, mà ở chỗ buộc bản nháp phân biệt rõ:
điều đã có bằng chứng;
nhận định cần xác minh;
khoảng trống dữ liệu cần làm rõ.
Blameless: sửa điều kiện hệ thống, không quy kết cá nhân
Theo chương Postmortem Culture của Google SRE, postmortem là hồ sơ bằng văn bản về incident: tác động, các hành động giảm thiểu hoặc khắc phục, nguyên nhân gốc hoặc nguyên nhân đóng góp, và việc theo dõi để giảm khả năng hay mức độ tái diễn.
Với hệ thống lớn, phức tạp và phân tán, incident và outage là điều có thể xảy ra. Nếu không có quy trình học từ failure, cùng một dạng sự cố có thể lặp lại, phức tạp hơn hoặc lan rộng hơn.
Postmortem blameless không có nghĩa là bỏ qua các hành động đã diễn ra. Nó yêu cầu mô tả các hành động đó trong bối cảnh thông tin, công cụ và quy trình sẵn có tại thời điểm incident.
Thay vì viết:
“Kỹ sư triển khai cấu hình sai.”
“Đội ứng dụng kiểm tra không đủ.”
Hãy chuyển trọng tâm sang điều kiện có thể cải thiện:
“Thay đổi cấu hình đã đi qua quy trình hiện có mà chưa bị phát hiện.”
“Runbook chưa nêu rõ tín hiệu cần đối chiếu trước khi thay đổi.”
“Thông tin phục vụ chẩn đoán chưa đủ để xác định sớm phạm vi tác động.”
Google lưu ý rằng khi việc chỉ trích và làm xấu hổ cá nhân hoặc đội nhóm trở thành văn hóa, mọi người có thể ngại đưa vấn đề ra ánh sáng vì sợ bị phạt. Mục tiêu là tìm lý do có tính hệ thống khiến thông tin bị thiếu hoặc sai, từ đó xây dựng biện pháp phòng ngừa hiệu quả hơn.
Chuẩn bị gói bằng chứng trước khi nhờ AI viết nháp
Đừng bắt đầu bằng một yêu cầu mở như “phân tích root cause từ toàn bộ log”. Hãy chuẩn bị đầu vào có cấu trúc để người review có thể truy vết từng kết luận.
Một gói thông tin phù hợp có thể gồm:
Timeline có nguồn: thời điểm alert, thay đổi quan trọng, hành động giảm thiểu, cập nhật status page và thời điểm kết thúc incident.
Tác động đã đo: thời gian ở từng mức độ nghiêm trọng, tỷ lệ thông báo ngoài SLA, event bị mất hoặc không được nhận, số account/người dùng bị ảnh hưởng, ticket hỗ trợ liên quan — nếu các chỉ số này áp dụng.
Bằng chứng: link đến dashboard, log, ticket, bản ghi incident hoặc nguồn xác minh timestamp.
Người tham gia: Incident Commander, người ghi chép và các responder khác.
Điểm chưa rõ: chẳng hạn thời điểm contributing factor bắt đầu hoặc mối liên hệ giữa một thay đổi và sự cố chưa được xác nhận.
Chỉ đưa vào công cụ AI những dữ liệu được phép sử dụng theo quy định của tổ chức. Bản nháp phải giữ được link hoặc nguồn truy vết cho các thông tin quan trọng.
> Nguyên tắc: AI là trợ lý soạn thảo, không phải nhân chứng của incident. Một kết luận chỉ nên được chốt khi có bằng chứng để đối chiếu.
Bước 1: Xác định trigger postmortem từ trước
Google khuyến nghị xác định tiêu chí viết postmortem trước khi incident xảy ra. Các trigger phổ biến gồm:
Downtime hoặc suy giảm chất lượng mà người dùng có thể nhận thấy, vượt một ngưỡng đã định.
Mất dữ liệu dưới bất kỳ hình thức nào.
On-call phải can thiệp, chẳng hạn rollback hoặc chuyển hướng traffic.
Thời gian xử lý vượt ngưỡng.
Monitoring thất bại, khiến incident phải được phát hiện thủ công.
Ngoài các tiêu chí này, stakeholder cũng có thể yêu cầu postmortem cho một sự kiện.
Trong template của PagerDuty, buổi postmortem được khuyến nghị lên lịch trong vòng 5 ngày làm việc sau sự kiện. Đừng chờ hoàn thành tài liệu mới đặt lịch; mục tiêu là hoàn tất nội dung để review trong buổi họp.
Bước 2: Yêu cầu AI tạo bản nháp có cấu trúc
Dưới đây là mẫu prompt để tạo bản nháp. Đây là cấu trúc làm việc đề xuất, không thay thế việc review của đội incident.
text
Bạn là trợ lý soạn thảo postmortem cho đội SRE.
Mục tiêu: tạo bản nháp blameless dựa DUY NHẤT trên bằng chứng bên dưới.
Yêu cầu:
Không suy đoán.
Mọi kết luận không có nguồn phải gắn nhãn [CẦN XÁC MINH].
Không quy kết lỗi cho cá nhân hoặc đội nhóm.
Giữ nguyên timestamp, số liệu và link nguồn được cung cấp.
Phân biệt rõ sự kiện đã xác nhận, contributing factor và điểm chưa rõ.
Incident: <tên incident>
Khoảng thời gian: <bắt đầu - kết thúc, UTC>
Người phụ trách postmortem: <tên hoặc vai trò>
Bằng chứng timeline:
<timestamp UTC> | <sự kiện> | <link nguồn>
...
Tác động đã đo:
<metric> | <giá trị> | <nguồn>
...
Hành động giảm thiểu/khắc phục:
<hành động> | <thời điểm> | <kết quả quan sát> | <nguồn>
...
Hãy trả về:
Overview ngắn
What happened
Timeline theo UTC, giữ link nguồn
Contributing factors: đã xác nhận và [CẦN XÁC MINH]
Resolution: phân biệt giải pháp tạm thời và dài hạn nếu có bằng chứng
Impact: chỉ dùng số liệu được cung cấp
What went well / What didn't go so well
Danh sách khoảng trống bằng chứng cần làm rõ
Action item dự thảo, gắn với contributing factor tương ứng
Cấu trúc này giúp giảm rủi ro biến một tương quan trong timeline thành kết luận nhân quả. Ví dụ, rollback diễn ra trước khi dịch vụ phục hồi không tự động chứng minh rollout là nguyên nhân gốc.
Bước 3: Dùng AI rà soát ngôn ngữ đổ lỗi
Sau khi có bản nháp, hãy thực hiện một lượt rà soát riêng cho ngôn ngữ. Mục tiêu không phải làm nhẹ tác động, mà là chuyển từ kết luận về con người sang điều kiện hệ thống có thể cải thiện.
text
Rà soát các câu dưới đây theo nguyên tắc postmortem blameless.
Với mỗi câu:
chỉ ra ngôn ngữ quy kết cá nhân hoặc đội nhóm, nếu có;
viết lại theo điều kiện hệ thống và bằng chứng hiện có;
không che giấu hành động hoặc tác động;
gắn [CẦN XÁC MINH] nếu câu gốc không có bằng chứng.
Các câu cần rà soát:
<đoạn postmortem hoặc bullet>
Ví dụ đầu vào:
> “On-call rollback muộn nên người dùng bị ảnh hưởng lâu hơn.”
Nếu chưa có bằng chứng đầy đủ, bản viết lại có thể là:
> “Thời điểm xác nhận và thực hiện rollback cần được đối chiếu với timeline. Cần làm rõ liệu runbook, tín hiệu quan sát và thông tin về phạm vi tác động có hỗ trợ quyết định rollback kịp thời hay không.”
Cách viết này không bỏ qua câu hỏi về thời gian rollback. Nó chuyển câu hỏi từ “ai chậm?” sang “điều kiện nào khiến việc ra quyết định mất thời gian?”.
Bước 4: Biến phát hiện thành action item có thể theo dõi
Template PagerDuty yêu cầu action item được theo dõi bằng ticket. Các hạng mục có thể bao gồm:
Sửa lỗi hoặc điều kiện góp phần gây incident.
Công việc chuẩn bị giúp giảm tác động nếu sự cố lặp lại.
Các bước postmortem còn lại, như truyền thông nội bộ hoặc cập nhật status page.
Cải thiện quy trình phản ứng incident.
Trong playbook nội bộ, nên yêu cầu mỗi action item dự thảo trả lời được các câu hỏi sau:
Cần thay đổi cụ thể điều gì?
Ai hoặc vai trò nào sẽ phụ trách?
Ticket theo dõi là gì?
Điều kiện hoàn tất là gì?
Bằng chứng nào cho thấy việc thay đổi đã hoàn tất?
Action item này xử lý contributing factor nào?
Có phụ thuộc hoặc rủi ro nào cần nêu rõ không?
Mẫu prompt:
text
Chuyển các phát hiện sau thành action item có thể theo dõi.
Mỗi action item cần có:
thay đổi cụ thể;
owner hoặc vai trò phụ trách;
ticket theo dõi;
tiêu chí hoàn tất;
bằng chứng kiểm chứng;
contributing factor liên quan;
phụ thuộc hoặc rủi ro, nếu có.
Không tự tạo owner, deadline, số liệu hoặc công cụ chưa được cung cấp.
Nếu thiếu thông tin, ghi [CẦN BỔ SUNG].
Phát hiện:
<danh sách phát hiện>
Tránh các mục quá chung như “cải thiện monitoring” hoặc “viết runbook tốt hơn”. Nếu chưa thể xác định công việc cụ thể, hãy ghi đó là điểm cần làm rõ thay vì biến nó thành một cam kết mơ hồ.
Bước 5: Người phụ trách xác minh trước buổi review
Trước khi chia sẻ bản nháp, người phụ trách postmortem nên kiểm tra lần lượt:
Timeline: mỗi mốc quan trọng đã có timestamp và nguồn chưa?
Impact: số liệu đã khớp với nguồn vận hành chưa? Nếu chưa rõ, đã ghi là chưa xác nhận chưa?
Contributing factors: có nhận định nào bị trình bày như sự thật dù chưa có bằng chứng không?
Resolution: giải pháp tạm thời và thay đổi dài hạn đã được phân biệt chưa?
Action item: đã có ticket và đủ thông tin để theo dõi chưa?
Ngôn ngữ: còn câu nào quy kết, làm xấu hổ hoặc không xây dựng không?
PagerDuty cũng gợi ý phần How’d We Do? với hai câu hỏi đơn giản:
Điều gì đã diễn ra tốt?
Điều gì chưa diễn ra tốt?
Đây là phần hữu ích để ghi nhận điểm mạnh của quá trình phản ứng, đồng thời tạo đầu vào cho các cải tiến tiếp theo.
Checklist trước khi chốt
[ ] Postmortem được kích hoạt theo tiêu chí đã định nghĩa.
[ ] Buổi review được lên lịch trong vòng 5 ngày làm việc sau sự kiện.
[ ] Overview nêu ngắn gọn diễn biến và tác động.
[ ] Timeline có timestamp, ưu tiên dùng UTC, và nguồn đối chiếu.
[ ] Mọi số liệu tác động đều có nguồn.
[ ] Nhận định thiếu bằng chứng được gắn [CẦN XÁC MINH].
[ ] Workaround và giải pháp dài hạn được phân biệt rõ nếu có.
[ ] Action item được theo dõi bằng ticket và gắn với phát hiện cụ thể.
[ ] Bản cuối đã được người phụ trách kiểm tra trước khi chia sẻ.
Postmortem tốt không phải là bản văn nghe “hay” nhất. Nó là tài liệu giúp đội hiểu điều gì đã xảy ra, điều gì cần thay đổi và cách giảm khả năng hoặc mức độ tác động khi điều kiện tương tự quay lại.