凌晨 2 點 10 分，警報響起。一名工程師推送了一項配置更改，檢出服務開始返回錯誤，值班主管在 40 分鐘後將其回滾。在審查會議上，第一個問題是「是誰推送的更改？」幾分鐘之內，討論就變成了某人在凌晨 02 點的判斷，沒有人追問為什麼這項更改在沒有進行早期測試的情況下就上線了，為什麼警報過了這麼久才發出，或者為什麼運行手冊已經過時。
這是一個範例場景，並非客戶案例。之所以容易理解，是因為這種情況確實存在：如果事件回顧只關注最後採取行動的人，最終只會得到一個看似合理的解釋，卻幾乎無法從中吸取任何教訓。
本指南面向工程經理和賦能負責人，旨在幫助他們提升分析事故證據和製定可測試改進方案的能力。內容涵蓋如何區分技能差距及其所處環境、如何設計實踐、如何進行事後總結以及如何衡量評估的有效性。
「無辜」究竟意味著什麼，又不意味著什麼。
谷歌的《網站可靠性工程》一書明確指出：要真正做到事後分析不追究責任，就必須專注於找出事件的促成原因，而不指責任何個人或團隊存在不良或不當行為。書中也闡述了背後的假設：所有相關人員都出於善意，並根據他們掌握的資訊做出了正確的決定。Google SRE 書籍，《事後文化：從失敗中學習》.)
無責並不意味著免責。同一章節要求事後分析最終形成行動方案，並明確優先順序和負責人。無責調查仍然需要追究責任，但責任的焦點從「誰造成了這件事」轉移到「誰將負責使系統更安全，以及何時完成」。如果你的審查忽略了後半部分，那隻會是一場愉快的對話，而不是學習的過程。
1. 辨識行為及其背景
首先要先明確你想改變的具體行為。 「我們的事故審查只關注最後採取行動的人」是可以觀察到的，而「我們的文化過於注重追究責任」則不是。
然後問自己，這是否真的是技能問題。訓練只能解決部分錶現不佳的原因。在著手任何工作之前，請先區分以下三種可能性：
- 一項缺失的技能。 審閱者不知道如何建立時間線，區分觸發因素和促成因素，或問“是什麼讓當時的這一行為看起來合理？”
- 激勵措施。 評論會影響績效討論，因此人們會調整自己的言論以保護自己。
- 權威梯度和過往反應。 上個季度提出問題卻被告知不要消極的初級工程師，即使訓練有素，也不會在這次會議上提出任何問題。
只有第一個問題是訓練問題，其他兩個問題是環境因素。如果你只訓練技能而不改變環境因素，人們就會練習一些在工作場所會受到懲罰的行為。把你目前對原因的看法當作一個假設，在正式啟動專案之前，先和工程師們聊聊，看看最近的評估文件，驗證一下你的假設。
2. 設定練習的操作條件
只有當工作場所能夠應對時，練習才能發揮作用。在任何人進行排練之前，請先與負責考核的人員達成以下共識：
- 已批准的職責。 誰負責協調，誰負責制定時間表，誰負責後續行動？明確角色分工，以免協調人擅自行使職權。
- 領導者如何看待民眾的訴求。 如果工程師說“部署工具讓我跳過了金絲雀測試階段”，主管接下來該怎麼做？事先決定好答案，例如：感謝工程師，將此記錄為促成因素，並指派一項行動。
- 主管的回應。 員工演練需要主管做出相對應的回應。如果你培訓工程師在績效評估中積極發言，但他們的經理仍然問“這是誰的錯？”，那麼培訓就失去了意義。
對管理者進行關於績效考核流程的簡短介紹，與對參與者進行訓練同等重要。應明確說明績效考核文件在績效管理中的用途（包括哪些用途以及不適用哪些用途）。
3. 設計以行為為基礎的學習之旅
卡內基美隆大學埃伯利中心關於學習目標的指導意見指出，目標、評估和教學策略應該彼此一致，這一點很有價值（埃伯利中心，學習目標）這是設計指導，而不是關於任何特定工具或結果的證據，但它是對該方案的一個很好的檢驗：如果目標是分析證據並達成可檢驗的改進方案，那麼僅憑回憶問題無法進行評估。
布魯姆分類法在這裡很有用，它可以用來描述任務的認知需求：分析、評估、創造。它描述了任務對人的要求，但並沒有解釋人們為什麼會做或不做，所以不要用它來診斷動機。
一個可行的旅程分為三個階段。
| 階段 | 學習者行動 | 交付 |
|---|---|---|
| 準備 | 請閱讀您的事件審查政策和簡短術語表（觸發因素、促成因素、緩解措施、行動項目）。簡要診斷檢查是必要的前提條件。 | 自主學習。複習檢查僅確認先決條件，不複習技能。 |
| 練習 | 分析一份已準備好的事故案例，並商定可測試的改進方案。需要給出有理有據的答复，而不是簡單的多項選擇題。 | 互動式或引導式個案練習，並對影響因素分析的品質和後續行動提供回饋。 |
| 審核和轉移 | 討論一個模稜兩可的選擇，然後完成一個新的案例或在監督下進行一次真實的複習。 | 即時輔導或非同步複習。在人們有時間將技能運用到工作中之後，檢查其應用效果。 |
案例要貼近實際，並請一位經驗豐富的工程師進行驗證。如果案例在技術上有錯誤，會讓審閱者對練習結果產生懷疑。
4. 演練情境並進行總結報告
以下是使用 02:10 場景進行練習的範例。證據包包含部署日誌、警告時間軸、分頁策略、拉取請求和運作手冊，所有內容均為虛構。
提示參與者。 “請解釋工程師當時為何力推這項變更。請列舉你所依據的證據。並告訴我們，在你確信之前，你還需要哪些信息或支持。”
一個站不住腳的回應是這樣的：「工程師應該檢查一下舞台搭建情況。」它只提到了一個人的名字，沒有提供任何依據，也沒有提出任何改進建議。
更強有力的回應應該是這樣的：「部署日誌顯示，由於工具中金絲雀部署步驟是可選的，因此變更直接發布了。該拉取請求有一位審核員，他在 20 分鐘的審核窗口期後批准了該變更。頁面在錯誤出現 18 分鐘後才加載，因為警報閾值設置為 5分鐘平均值。
注意它的優點所在。它運用證據，指出限制因素和不確定性，並最終提出可檢驗的行動方案。
現在進行總結報告。不要只打分，還要問：
- 證據支持什麼？你的假設是什麼？
- 團隊實際上有權採取哪些行動？
- 在下次正式評估中，什麼因素會讓你更容易重複這種行為？什麼因素會讓你更難重複這種行為？
第三個問題最為重要。它揭示了第二部分中提到的條件。如果三位參與者都說“我的經理會問是誰幹的”，那麼你就發現了一個培訓無法消除的限制因素。
5. 衡量行為和後續行動
關鍵問題在於，如何證明學習者能夠分析事故證據並達成可驗證的改善方案。以下是一個可供參考的評估標準。這只是一個建議，需要與經驗豐富的工程師共同調整，並非經過驗證的準備標準。
| 標準 | 可觀察的證據 | 0 | 1 | 2 |
|---|---|---|---|---|
| 任務執行 | 分析證據並同意改進方案；記錄所採取的行動及其背後的證據。 | 缺失或未得到支持 | 部分，但有相關遺漏 | 完整且符合既定標準 |
| 推理 | 解釋了限制條件、替代方案和不確定性；影響因素不僅限於最後一步行動。 | 缺失或未得到支持 | 部分，但有相關遺漏 | 完整且合理 |
| 邊界 | 使用經批准的程序；當資訊或權限不足時尋求協助 | 缺失或未得到支持 | 部分，但有相關遺漏 | 完整且合理 |
應單獨定義關鍵錯誤，例如，明確指出某個人是錯誤原因，或提出沒有負責人的行動。高總分絕不能掩蓋關鍵失誤。
就測量本身而言：
- 影響因素分析的品質。 將專案實施前後的評論進行比較，並由一位不知曉具體情況的人員，按照相同的評分標準進行評分。使用未公開的後續案例以及真實案例。
- 貫徹執行。 計算所有已提出的行動項中，已指定負責人、已測試且已完成的行動項所佔的比例。說明分母和時間範圍。
- 將觀察與過程變化結合。 認真參與一次真正的評審。之後檢查一下各項行動事項的落實。
報告數量需謹慎。如果專案結束後記錄的事故和險情數量增加，可能意味著安全狀況改善、信任度提高，或新的工具簡化了記錄流程。跌倒事件的發生也可能意味著問題減少或人們不願透露資訊。在將任何變更歸因於培訓之前，請先查看同期發生的具體情況，並避免聲稱存在未經測量的效果。
以上埃伯利指南闡述瞭如何進行協調一致，但並不能證明這種方法可以減少事故發生。請保留您自己的基準數據和後續數據，並將其視為本地證據。
即使技能提升後，哪些限制因素可能仍然存在？
對贊助商要坦誠相告：
- 審核文件仍可能作為績效決策的參考依據。
- 面臨交付壓力的團隊可能會忽略一些代價高昂但明智的做法。
- 跨隊行動可能會停滯不前，因為沒有人擁有邊界的控制權。
- 資深工程師可能仍然主導討論。
更完善的分析並不能消除這些問題。需要針對這些問題制定單獨的流程變更計畫。
將其應用於 AhaSlides
AhaSlides 支援自適應學習、互動式學習，並可在直播和自主學習之間靈活切換。在此過程中，可能包括自主學習的準備步驟、包含開放式問答提示的直播或引導式個案分析環節（確保每位參與者在小組討論前完成分析），以及會後的後續任務。具體的創作、評分和報告功能應在使用前通過演示驗證，並與您自己的案例進行比對。任何涉及人工智慧、模擬器或與您的事件管理工具整合的功能，在演示之前都應視為外部功能。
下一步： 請參考以上標準，並與一位資深工程師共同進行調整，然後建立您將要使用的案例。如果您想了解這種即時、自主學習的學習方式， 預約 AhaSlides 工作流程演示 一旦你擬定了個案和評分標準。
