第 5 階段：回應和學習

您的應用程式如何回應破壞性事件會影響其可靠性。從經驗中學習，以及您的應用程式過去如何回應中斷，對於提高其可靠性也至關重要。 

「回應並學習」階段著重於您可以實作的實務，以便更好地回應應用程式中的顛覆性事件。它還包括幫助您從運營團隊和工程師的經驗中獲得最大程度的學習的實踐。

建立事件分析報告

當事件發生時，第一個行動是盡快防止對客戶和業務造成進一步的傷害。應用程序恢復後，下一步是了解發生了什麼並確定步驟以防止再次發生。此事件後分析通常會擷取為報告，記錄導致應用程式損害的一組事件，以及中斷對應用程式、客戶和業務的影響。這些報告成為有價值的學習成品，應該在整個企業中廣泛共享。

注意

在不指派任何責任的情況下執行事件分析至關重要。假設所有運營商都採取了最好的，最合適的行動方案給出了他們所擁有的信息。請勿在報告中使用運算子或工程師的名稱。引用人為錯誤作為損害的原因可能會導致團隊成員受到保護以保護自己，從而導致捕獲不正確或不完整的信息。

良好的事件分析報告 (例如 Amazon 錯誤校正 (COE) 程序中所記載的報告，遵循標準化的格式，並嘗試盡可能詳細地擷取導致應用程式受損的情況。該報告詳細說明了一系列時間戳記的事件，並捕獲定量數據（通常是監控儀表板中的指標和屏幕截圖），這些數據描述了時間線上應用程序的可衡量狀態。該報告應該捕獲採取行動的操作員和工程師的思想過程，以及導致他們得出結論的信息。該報告還應詳細說明不同指示器的性能，例如引發了哪些警報，這些警報是否準確反映了應用程序的狀態，事件與產生的警報之間的時間滯後，以及解決事件的時間。時間軸也會擷取已啟動的 Runbook 或自動化，以及它們如何協助應用程式重新取得有用的狀態。時間表的這些元素可協助您的團隊瞭解自動化和操作員回應的有效性，包括解決問題的速度，以及他們在緩解中斷時的效率。

這個歷史事件的詳細圖片是一個強大的教育工具。團隊應將這些報告存儲在可供整個企業使用的中央存儲庫中，以便其他人可以查看事件並從中學習。這可以提高團隊對生產中可能出錯的事情的直覺。

詳細的事故報告儲存庫也成為操作人員訓練材料的來源。團隊可以使用事件報告來激發桌面或現場比賽日的靈感，在這一天中，團隊可以獲得回放報告中捕獲的時間表的信息。操作員可以使用時間表中的部分資訊來逐步完成案例，並描述他們將採取的動作。然後，遊戲當天的主持人可以根據操作員的操作提供應用程序如何響應的指導。這樣可以開發操作員的故障排除技能，因此他們可以更輕鬆地預測問題並進行故障排除。

負責應用程式可靠性的集中式團隊應該在整個組織都可以存取的集中式程式庫中維護這些報告。該團隊還應負責維護報告模板和培訓團隊如何完成事件分析報告。可靠性團隊應定期檢閱報告，以偵測整個企業可透過軟體程式庫、架構模式或團隊程序變更來解決的趨勢。

進行操作審查

如第 4 階段：操作中所述，作業檢閱是檢閱最近發行的功能、事件和作業指標的機會。操作審查也是一個機會，可以與組織中更廣泛的工程社群分享功能發布和事件中的經驗。在作業檢閱期間，團隊會檢閱已復原的功能部署、發生的事件以及處理方式。這使整個組織的工程師有機會從他人的經驗中學習並提出問題。

向公司的工程社群開啟您的作業檢閱，以便他們深入瞭解執行業務的 IT 應用程式，以及可能遇到的問題類型。他們在為企業設計、實作和部署其他應用程式時，會隨身攜帶這些知識。

檢閱警示效能

如操作階段所討論的警示，可能會導致儀表板警示、建立工單、傳送電子郵件或分頁操作員。  一個應用程序將有許多警報配置為監視其操作的各個方面。隨著時間的推移，應該檢查這些警報的準確性和有效性，以提高警報的精確度，減少誤報，並合併重複的警報。

報警精度

警報應盡可能具體，以減少您必須花費在解釋或診斷導致警報的特定中斷時間。當警示因應應用程式損壞而引發時，接收並回應警示的操作員必須首先解釋警示所傳達的資訊。這些資訊可能是一個簡單的錯誤碼，可對應至復原程序之類的動作方案，或者可能包含應用程式記錄檔中的行，您必須檢閱這些行，以瞭解引發警示的原因。當您的團隊學習更有效地操作應用程序時，他們應該優化這些警報以使其盡可能清晰簡潔。

您無法預期應用程式的所有可能中斷，因此總會有一般警示需要操作員進行分析和診斷。您的團隊應該努力減少一般警報的次數，以縮短回應時間並縮短平均修復時間 (MTTR)。理想情況下，警報和自動化或人為執行的響應之間應該存在 one-to-one 關係。  

誤報

運營商不需要操作員採取任何操作，但在電子郵件，頁面或工單中產生警報的警報將隨著時間的推移忽略。  定期或作為事件分析的一部分，檢閱警示，以識別那些經常被忽略或不需要操作員採取任何動作的警示 (誤報)。  您應該努力刪除警報，或改善警報，以便向操作員發出可操作的警報。

假底片

在事件發生期間，設定為在事件期間發出警示的警示可能會失敗，這可能是因為事件會以非預期的方式影響應用程式。  作為事件分析的一部分，您應該查看應該提出但沒有提出的警報。您應該努力改善這些警報，以便更好地反映事件可能產生的條件。或者，您可能必須建立額外的警示，以對應至相同的中斷，但會因為中斷的不同徵狀而引發。

重複警報

損害應用程式的中斷可能會導致多種症狀，並可能導致多個警報。  您應該定期檢閱已發出的警示和警示，或作為事件分析的一部分。  如果操作員收到重複警示，請建立彙總警示，以將其合併為單一警示訊息。

進行指標審查

您的團隊應該收集與應用程式相關的操作指標，例如按每月嚴重性分類的事件數目、偵測事件的時間、識別原因的時間、修復的時間，以及建立的工單數量、傳送警示以及引發的頁面。至少每月檢閱這些指標，以瞭解營運人員的負擔、他們處理的 signal-to-noise 比例 (例如資訊警示與可採取動作的警示)，以及團隊是否正在改善其控制下操作應用程式的能力。使用此檢閱瞭解營運團隊可衡量方面的趨勢。徵求團隊對如何提高這些指標的想法。  

提供培訓和能力

很難捕獲導致事件或意外行為的應用程序及其環境的詳細描述。此外，建模應用程序的彈性以預測此類情況並不總是簡單的。您的組織應該投資訓練和支援材料，以供您的營運團隊和開發人員參與活動，例如復原力建模、事件分析、遊戲日和混沌工程實驗。這將提高團隊生成的報告的真實性以及他們捕獲的知識。這些團隊也將變得更有能力預測失敗，而無需依賴規模較小，更有經驗的工程師團隊，他們必須通過計劃的審查來提供他們的見解。

建立事件知識庫

事件報告是事件分析的標準輸出。您應該使用相同或類似的報表來記錄偵測到異常應用程式行為的案例，即使應用程式沒有受損也是如此。使用相同的標準化報告結構來捕捉混沌實驗和比賽日的結果。此報告代表應用程式及其環境的快照，可導致事件或其他非預期行為。您應該將這些標準化報告儲存在企業內所有工程師都可以存取的中央儲存庫中。  

然後，操作團隊和開發人員可以搜索此知識庫，以了解過去哪些情況中斷了應用程序，哪些類型的案例可能導致中斷，以及防止應用程序損害的原因。該知識庫成為提高營運團隊和開發人員技能的加速器，並使他們能夠分享他們的知識和經驗。此外，您還可以使用這些報告作為比賽日或混亂實驗的訓練材料或場景，以提高操作團隊的直覺性和故障排除中斷的能力。

注意

標準化的報告格式還為讀者提供了一種熟悉感，並幫助他們更快地找到所需的信息。

深入實施彈性

如前所述，進階組織將對警示實作多個回應。無法保證響應將是有效的，因此通過分層響應，應用程序將更好地裝備以優雅地失敗。我們建議您為每個指標實作至少兩個回應，以確保個別回應不會成為可能導致 DR 案例的單一失敗點。  這些層應該以串行順序創建，以便只有在先前的響應無效時才執行連續響應。您不應該對單個警報運行多個分層響應。請改用警示來指出回應是否失敗，如果是，則啟動下一個分層回應。