postmortem-writing

Tổng quan về skill postmortem-writing

postmortem-writing làm được gì

Skill postmortem-writing giúp agent tạo ra các bản postmortem sự cố có cấu trúc, không đổ lỗi, và bao quát những phần mà đội ngũ thường bỏ sót khi đang chịu áp lực: dòng thời gian rõ ràng, phân tích nguyên nhân gốc rễ, các yếu tố góp phần, mức độ ảnh hưởng và các hành động follow-up cụ thể. Skill này phù hợp cho việc viết báo cáo sau outage, suy giảm dịch vụ, sự cố suýt xảy ra nhưng có rủi ro cao, vấn đề dữ liệu hoặc các incident khác cần được rút kinh nghiệm ở cấp tổ chức thay vì chỉ viết một bản tóm tắt sơ sài.

Ai nên cài postmortem-writing

Skill này đặc biệt phù hợp với:

• đội SRE, DevOps, platform và incident response
• engineering manager cần chuẩn hóa báo cáo sự cố
• những người chịu trách nhiệm viết báo cáo nội bộ sau outage
• các team muốn chuyển từ retrospective nặng tính quy trách nhiệm sang tư duy hệ thống

Nếu công việc chính của bạn là biến ghi chú sự cố lộn xộn thành một bản postmortem dùng được, thì postmortem-writing nhắm trúng nhu cầu đó hơn nhiều so với một prompt viết lách chung chung.

Nhu cầu thực sự mà skill này giải quyết

Phần lớn người dùng không thực sự cần trợ giúp để “viết một tài liệu” theo nghĩa chung chung. Họ cần biến log, thread chat, cảnh báo và những mảnh ký ức rời rạc thành một báo cáo:

• giải thích rõ chuyện gì đã xảy ra bằng ngôn ngữ dễ hiểu
• giữ đúng trình tự thời gian
• tách bạch nguyên nhân gốc với các yếu tố góp phần
• tránh đổ lỗi cho cá nhân
• kết thúc bằng các hành động có thể theo dõi được

Đó chính là giá trị thực tế của postmortem-writing.

Điểm khác biệt giữa skill này và một prompt thông thường

Điểm khác biệt chính không nằm ở tự động hóa hào nhoáng. Nó nằm ở cấu trúc biên tập và kỷ luật review sự cố. Tài liệu gốc nhấn mạnh:

• cách đặt vấn đề theo hướng không đổ lỗi
• các tiêu chí kích hoạt rõ ràng để biết khi nào nên viết postmortem
• quy trình làm việc ưu tiên timeline trước
• phân tích nguyên nhân gốc thay vì chỉ mô tả triệu chứng bề mặt
• action item là đầu ra cuối cùng, không phải phần thêm vào cho có

Nhờ vậy, postmortem-writing skill đặc biệt hữu ích khi bạn cần sự nhất quán và cách diễn đạt an toàn hơn, chứ không chỉ là văn bản được trau chuốt.

Những điều cần biết trước khi áp dụng

Đây là skill thiên về tài liệu và hướng dẫn. Dấu hiệu từ repository cho thấy chỉ có SKILL.md, không có script hỗ trợ, schema hay file tham chiếu đi kèm. Nghĩa là postmortem-writing install khá đơn giản, nhưng chất lượng đầu ra sẽ phụ thuộc rất nhiều vào dữ liệu incident bạn cung cấp. Nếu bạn kỳ vọng skill này tự thu thập bằng chứng hoặc tự tạo ticket, thì bản thân nó không làm được việc đó.

Cách dùng skill postmortem-writing

Bối cảnh cài đặt postmortem-writing

Cài từ repository skill cha:

npx skills add https://github.com/wshobson/agents --skill postmortem-writing

Vì skill nằm tại plugins/incident-response/skills/postmortem-writing, nên thứ bạn đang cài là một lớp workflow và hướng dẫn viết báo cáo, không phải một nền tảng quản lý incident độc lập.

Hãy đọc file này trước

Bắt đầu với:

• SKILL.md

Skill này không có resources/, rules/ hay script hỗ trợ nào được lộ ra, nên cách đọc repository nhanh nhất là đọc SKILL.md từ đầu đến cuối. Điều này rất quan trọng vì giá trị cốt lõi ở đây nằm ở hướng dẫn quy trình và cách framing, không phải ở code.

Khi nào nên gọi postmortem-writing

Hãy dùng postmortem-writing usage khi bạn đã biết incident đó xứng đáng có một bản write-up chính thức, đặc biệt trong các trường hợp:

• incident mức SEV1 hoặc SEV2
• outage ảnh hưởng tới khách hàng lâu hơn một đợt chập chờn nhỏ
• mất dữ liệu hoặc sự cố bảo mật
• near-miss có khả năng leo thang thành sự cố nghiêm trọng
• lỗi mới, bất thường, hoặc cần operator can thiệp khác thường

Nếu sự kiện chỉ là lỗi nhỏ và không cần bài học hay remediation cụ thể, một ghi chú ngắn về incident có thể đã đủ.

Skill cần đầu vào gì

Skill này hoạt động tốt nhất khi bạn cung cấp tư liệu sự cố thô, thay vì chỉ nói “hãy viết một bản postmortem”. Những đầu vào hữu ích gồm:

• tóm tắt incident
• thời điểm bắt đầu và kết thúc
• ảnh hưởng tới khách hàng hoặc hệ thống
• timeline các sự kiện chính
• cách sự cố được phát hiện
• các bước giảm thiểu tác động
• nguyên nhân gốc nghi ngờ
• các yếu tố góp phần đã biết
• các câu hỏi còn bỏ ngỏ
• những hành động follow-up đã được bàn tới

Dòng thời gian của bạn càng chính xác, báo cáo cuối cùng càng đáng tin.

Biến một yêu cầu sơ sài thành prompt mạnh

Prompt yếu:

• “Write a postmortem for yesterday’s outage.”

Prompt mạnh:

• “Use the postmortem-writing skill to draft a blameless postmortem for a 47-minute API outage on 2025-02-10. Include a minute-by-minute timeline, impact summary, root cause, contributing factors, what detection missed, and action items grouped by prevention, detection, and response. Mark uncertainties clearly instead of inventing details.”

Vì sao cách này tốt hơn:

• xác định rõ phạm vi incident
• yêu cầu framing không đổ lỗi
• gọi tên những phần hay thiếu nhưng rất quan trọng
• cho phép giữ lại điểm chưa chắc chắn thay vì bịa ra cho trọn vẹn

Mẫu prompt thực tế

Bạn có thể dùng cấu trúc prompt như sau:

• Loại incident: outage, degradation, security event, data incident, near-miss
• Mức độ nghiêm trọng: cấp SEV hoặc tương đương
• Khung thời gian: bắt đầu, phát hiện, giảm thiểu, khôi phục
• Ảnh hưởng: người dùng, doanh thu, request, dữ liệu, vận hành nội bộ
• Bằng chứng: logs, alerts, chat notes, ticket excerpts
• Nguyên nhân nghi ngờ: cái gì hỏng và vì sao
• Yếu tố góp phần: tooling, process, load, config, staffing, dependencies
• Đầu ra mong muốn: executive summary, timeline, RCA, lessons learned, action items
• Ràng buộc giọng điệu: không đổ lỗi, bám sự kiện, không quy trách nhiệm đích danh cá nhân
• Điều chưa biết: liệt kê rõ ràng

Đây là cách nhanh nhất để cải thiện postmortem-writing for Report Writing.

Quy trình gợi ý cho incident thực tế

Một luồng làm việc hiệu quả là:

1. Thu thập dữ kiện thô từ ghi chú incident và bằng chứng hệ thống.
2. Nhờ skill tạo bản nháp có cấu trúc đầu tiên.
3. Rà lại timeline để sửa lỗi sai thứ tự.
4. Siết lại ranh giới giữa nguyên nhân gốc và các yếu tố góp phần.
5. Loại bỏ các cách diễn đạt mang tính đổ lỗi.
6. Nếu cần, bổ sung action item kèm owner và deadline ở ngoài bản nháp.
7. Dùng báo cáo cuối trong buổi họp postmortem.

Trình tự này bám sát cách các team thực sự viết sau incident: chốt dữ kiện trước, diễn giải sau, remediation để cuối.

Cách lấy timeline tốt hơn

Chất lượng timeline thường quyết định việc tài liệu có tạo cảm giác đáng tin hay không. Hãy đưa cho skill các bullet có timestamp như:

• 09:14 UTC: latency alert fired
• 09:16 UTC: on-call acknowledged
• 09:21 UTC: deploy rollback started
• 09:37 UTC: error rate returned to baseline

Nếu không có phần này, ngay cả một postmortem-writing guide tốt cũng khó tái dựng quan hệ nhân quả một cách đáng tin cậy.

Cách yêu cầu phân tích nguyên nhân gốc tốt hơn

Đừng chỉ hỏi “the root cause”. Hãy yêu cầu:

• nguyên nhân trực tiếp
• các yếu tố hệ thống sâu hơn
• vì sao các lớp bảo vệ thất bại
• vì sao việc phát hiện hoặc escalation bị chậm
• điều gì đã khiến lỗi này có thể xảy ra

Cách này giúp đầu ra không bị co lại thành kiểu “có một bản deploy lỗi xảy ra”, vốn thường quá nông để thực sự hữu ích.

Cách giữ bản write-up không đổ lỗi

Skill này đặt trọng tâm rõ ràng vào văn hóa không đổ lỗi. Hãy củng cố điều đó ngay trong prompt:

• yêu cầu tập trung vào điều kiện hệ thống, không phải lỗi cá nhân
• yêu cầu dùng ngôn ngữ trung tính
• yêu cầu tách hành động của con người ra khỏi bối cảnh tổ chức và kỹ thuật

Ví dụ, nên dùng:

• “The deployment process allowed an unsafe config change to reach production”
  thay vì:
• “An engineer pushed the wrong setting”

Skill này không cung cấp gì

postmortem-writing skill có vẻ không bao gồm:

• thu thập dữ liệu tự động
• trích xuất timeline incident từ công cụ
• đồng bộ ticket
• logic phân loại mức độ nghiêm trọng ngoài hướng dẫn chung
• template đặc thù cho từng tổ chức ngay khi cài xong

Hãy chủ động chuẩn bị ngữ cảnh của riêng bạn và điều chỉnh đầu ra sao cho khớp với chương trình quản lý incident trong tổ chức.

Câu hỏi thường gặp về skill postmortem-writing

postmortem-writing có tốt hơn một prompt LLM thông thường không?

Thường là có, nếu vấn đề chính của bạn là cấu trúc và tính kỷ luật. Một prompt thông thường vẫn có thể tạo postmortem, nhưng rất hay bỏ sót tiêu chí kích hoạt incident, framing không đổ lỗi, hoặc sự khác nhau giữa nguyên nhân gốc và các yếu tố góp phần. postmortem-writing cho agent một khuôn vận hành rõ ràng hơn.

Skill này có phù hợp cho người mới bắt đầu không?

Có. Skill này khá thân thiện với người mới vì thiên về hướng dẫn và không đòi hỏi tooling tùy biến. Tuy vậy, người mới vẫn phải cung cấp hồ sơ sự kiện dựa trên sự thật. Skill này nâng chất lượng viết và cấu trúc review, chứ không thay thế việc điều tra incident.

Khi nào không nên dùng postmortem-writing?

Bỏ qua nó khi:

• sự kiện đó không đủ lý do để làm một postmortem đầy đủ
• bạn cần một incident commander theo thời gian thực, không phải một công cụ viết báo cáo
• bạn còn thiếu các dữ kiện cơ bản và vẫn đang actively debugging
• tổ chức của bạn yêu cầu một template độc quyền quá chặt mà skill này không thể khớp nếu không chỉnh sửa sâu

postmortem-writing chỉ dùng cho outage kỹ thuật thôi sao?

Không. Nó phù hợp nhất với incident kỹ thuật, nhưng framework này cũng áp dụng tốt cho sự cố bảo mật, sai sót dữ liệu, lỗi vận hành và các near-miss nghiêm trọng, miễn là bạn có thể cung cấp timeline, mức độ ảnh hưởng và hành động khắc phục.

Tôi có thể dùng postmortem-writing để viết executive summary không?

Có, nhưng đừng dừng ở đó. Lãnh đạo thường chỉ cần bản tóm tắt ngắn, trong khi người trực tiếp xử lý cần timeline đầy đủ và kế hoạch hành động. Hãy yêu cầu skill tạo cả một summary súc tích lẫn báo cáo hoàn chỉnh.

Skill này có hỗ trợ phần action item không?

Có, theo hướng gián tiếp. Hướng dẫn nguồn nhấn mạnh các hành động follow-up phải đủ khả năng triển khai. Bạn sẽ có kết quả tốt hơn nếu yêu cầu nhóm action theo các hạng mục như prevention, detection, response và process improvement.

Cách cải thiện skill postmortem-writing

Hãy cho postmortem-writing bằng chứng tốt hơn, không chỉ là chỉ dẫn hay hơn

Đòn bẩy chất lượng lớn nhất là độ trung thực của đầu vào. Hãy dán vào:

• timestamp
• số liệu ảnh hưởng tới khách hàng
• tên alert
• các bước giảm thiểu tác động
• các điểm đã biết là chưa rõ

Bằng chứng giàu thông tin luôn hiệu quả hơn các meta-instruction cầu kỳ.

Tách dữ kiện khỏi diễn giải

Một lỗi rất hay gặp là trộn giả định vào timeline. Hãy cung cấp thành hai khối:

• dữ kiện đã xác nhận
• giả thuyết hoặc câu hỏi còn mở

Cách này giúp postmortem-writing usage giữ được độ chính xác mà vẫn nêu bật được phần chưa chắc chắn.

Gọi tên rõ những phần còn thiếu

Nếu bản nháp đầu tiên quá chung chung, hãy yêu cầu bổ sung theo đúng tên mục:

• “Add a ‘What went well’ section”
• “Separate contributing factors from root cause”
• “Rewrite action items so each is specific and testable”

Yêu cầu sửa cụ thể sẽ cải thiện kết quả nhanh hơn nhiều so với câu kiểu “make it better.”

Ngăn action item nông và mơ hồ

Những bản postmortem yếu thường kết thúc bằng các hành động mơ hồ như “improve monitoring.” Hãy yêu cầu skill biến từng action thành:

• cụ thể
• có thể giao cho người chịu trách nhiệm
• gắn với một failure mode rõ ràng
• đo được hoặc kiểm thử được

Ví dụ:

• “Add an alert for queue lag over 5 minutes in region us-east-1”
  tốt hơn:
• “Improve alerting”

Cảnh giác khi ngôn ngữ đổ lỗi quay trở lại

Ngay cả với một skill theo hướng không đổ lỗi, tư liệu nguồn từ chat hoặc ghi chú vẫn có thể mang giọng quy trách nhiệm nặng nề. Hãy rà lại những câu từ đang tập trung quá mức vào một cá nhân thay vì điều kiện hệ thống, động lực tổ chức, công cụ, lỗ hổng review hoặc bối cảnh vận hành.

Lặp theo hai lượt để có đầu ra chất lượng hơn

Một cách làm đáng tin cậy là:

1. lượt đầu để chốt cấu trúc sự kiện
2. lượt hai để đào sâu phân tích và hành động

Cách này tránh ép mô hình phải bịa ra lập luận trau chuốt khi timeline còn chưa ổn định.

Điều chỉnh đầu ra theo mức độ trưởng thành postmortem của team

Nếu team của bạn còn ở giai đoạn đầu, hãy yêu cầu postmortem-writing xuất định dạng đơn giản với timeline, impact, causes và actions. Nếu team đã trưởng thành hơn, hãy yêu cầu các phần sâu hơn như lỗ hổng detection, hiệu quả escalation, đánh đổi trong quá trình recovery và bài học mang tính hệ thống. Cùng một skill có thể hỗ trợ cả hai kiểu, nhưng chỉ khi bạn đặt rõ kỳ vọng về độ sâu.

Cải thiện kết quả viết báo cáo sau bản nháp đầu tiên

Để có kết quả postmortem-writing for Report Writing tốt hơn, hãy làm một vòng review cuối theo bốn câu hỏi:

• Một thành viên mới trong team có hiểu được chuyện gì đã xảy ra không?
• Timeline đã đủ chính xác để audit chưa?
• Phần phân tích đã giải thích được vì sao các lớp phòng vệ thất bại chưa?
• Các action đã đủ cụ thể để giảm khả năng tái diễn chưa?

Nếu có câu nào trả lời là không, hãy sửa prompt đúng vào khoảng trống đó thay vì chạy lại một cách mù quáng.