自動產生的事故回應手冊

每個工程團隊都有相同的事故後續儀式。事故發生了。有人在 Slack 上快速寫了一份摘要。另一個人承諾更新手冊。排定了事後檢討會議。兩週後,手冊仍然沒有更新,事後檢討文件只完成一半,下次同樣的事故再次發生時,值班工程師又得從頭開始摸索。

問題不在於懶惰。而是在壓力大的事故之後撰寫文件是最後一件大家想做的事,而且還得跟下一個 sprint 的功能開發競爭時間。文件債不斷累積,直到手冊過時到沒有人相信它們。

事故回應工作流程

Engineering 入門包包含一個名為 Incident Response 的工作流程。它接收原始事故資料——時間軸、症狀、採取的行動、根本原因——並一次產生三個輸出。

1. 事故報告 — 結構化的事故後報告,包含:事故摘要、事件時間軸、影響評估(受影響使用者、持續時間、嚴重程度)、根本原因分析、促成因素,以及立即採取的行動。格式在所有事故中保持一致,這使得跨月份的報告可以進行模式識別。

2. 手冊更新 — AI 接收事故細節並產生相關手冊的新增內容或更新。如果事故揭露了新的故障模式,它會撰寫偵測步驟、診斷指令和補救程序。如果是已知的故障模式但有新的變化,它會更新現有章節。輸出是結構化的手冊就緒內容,而不是敘述性摘要。

3. 工程主管審查(核准關卡) — 在發布任何內容之前,工作流程會暫停以供審查。工程主管驗證時間軸的準確性,確認根本原因分析,並核准手冊的新增內容。這個關卡至關重要——AI 產生的手冊需要當時在場的人來確認程序是否正確。

4. 事後檢討產生 — 核准後,AI 產生完整的事後檢討文件:發生了什麼、為什麼發生、什麼阻礙了更快的解決,以及防止再次發生的行動項目。每個行動項目都有建議的負責人和優先順序。

為什麼事故文件的一致性很重要

當事故報告使用不同的格式時,你無法比較它們。除非每份報告都使用相同的嚴重程度等級和分類,否則你無法詢問「本季有多少 P1 事故是由資料庫問題引起的?」。除非每份報告都包含相同的時間欄位,否則你無法追蹤補救時間是否有所改善。

Incident Report recipe 強制執行一致的架構。每份報告都有相同的章節、相同的嚴重程度類別、相同的時間欄位。隨著時間推移,這成為一個你可以查詢的結構化資料集,而不只是一個文件資料夾。

工程師仍需做的事

工作流程需要準確的輸入。工程師提供:

• 發生了什麼 — 事件時間軸、觀察到的症狀、觸發的警報
• 他們做了什麼 — 採取的診斷步驟、執行的指令、應用的修復
• 什麼造成的 — 根本原因和促成因素

AI 不調查事故——它記錄事故。調查、除錯、修復——這是工程師的專業。AI 的工作是將該專業知識轉化為結構良好的文件,讓下一位值班工程師實際可以使用。

手冊更新在這裡特別有價值。一位剛花了兩個小時除錯生產問題的工程師確切知道下次要遵循哪些步驟。通常這些知識會留在他們的腦海中或 Slack 對話串中。工作流程將其捕捉在手冊章節中,包含具體指令和決策點。

Feature Launch 工作流程

Engineering 套件還包含一個 Feature Launch 工作流程,處理另一個文件缺口:發布溝通。

1. 從 commit 歷史和 PR 描述撰寫變更日誌條目
2. 產生適當詳細程度的面向使用者發布說明
3. 如果 endpoint 有變更,更新 API 文件
4. 將所有內容打包以供審查

而 Sprint Cycle 工作流程自動化規劃和回顧文件:從待辦事項產生 sprint 目標,為新功能建立文件計畫,並將回顧筆記結構化為可執行的改進。

完整的 Engineering 套件

Engineering 入門包在 Incident Response 之外還包含兩個額外的工作流程:

• Feature Launch — 一次完成發布說明、變更日誌和文件更新
• Sprint Cycle — 規劃、文件和回顧自動化

獨立的 recipe——技術規格撰寫器、API 文件產生器、程式碼審查回饋、架構決策記錄——可以單獨運作,或作為自訂工程工作流程的構建模組。