本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 階段 5：回應和學習
應用程式回應中斷事件的方式會影響其可靠性。從經驗中學習，以及您的應用程式在過去如何回應中斷，對於改善其可靠性也至關重要。
*回應和學習*階段著重於您可以實作的實務，以更好地回應應用程式中的中斷事件。它還包括協助您從營運團隊和工程師的經驗中提取最大學習量的實務。
## 建立事件分析報告
當事件發生時，第一個動作是盡快避免對客戶和業務造成進一步傷害。應用程式復原後，下一個步驟是了解發生的情況，並識別防止再次發生的步驟。此事件後分析通常會擷取為報告，記錄導致應用程式受損的一組事件，以及中斷對應用程式、客戶和業務的影響。這類報告會成為寶貴的學習成品，並且應該在整個企業中廣泛共用。
**注意**
執行事件分析而不指派任何責任至關重要。假設所有運算子都根據他們擁有的資訊採取最佳且最適當的行動。請勿在報告中使用操作員或工程師的名稱。將人為錯誤歸因於損害，可能會導致團隊成員受到保護，以保護自己，導致擷取不正確或不完整的資訊。
與 [Amazon Correction of Error (COE) 程序中](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.coe.en.html)記錄的良好事件分析報告一樣， 遵循標準化格式並嘗試盡可能詳細地擷取導致應用程式受損的條件。報告會詳細說明一系列時間戳記的事件，並擷取量化資料 （通常來自監控儀表板的指標和螢幕擷取畫面），以描述應用程式在時間軸上的可測量狀態。報告應擷取採取動作的操作員和工程師的思維程序，以及導致他們做出結論的資訊。報告也應詳細說明不同指標的效能，例如引發哪些警示、這些警示是否準確反映應用程式的狀態、事件與產生的警示之間的時間延遲，以及解決事件的時間。時間軸也會擷取已啟動的 Runbook 或自動化，以及它們如何協助應用程式恢復有用的狀態。時間表的這些元素可協助您的團隊了解自動化和運算子回應的有效性，包括他們解決問題的速度，以及他們在緩解中斷方面的效率。
這個歷史事件的詳細圖片是強大的教育工具。團隊應將這些報告存放在可供整個業務使用的中央儲存庫中，以便其他人可以檢閱事件並從中學習。這可以改善團隊在生產環境中可能出錯的直覺。
詳細事件報告的儲存庫也會成為操作員的訓練材料來源。團隊可以使用事件報告來啟發桌上或現場遊戲日，其中會提供團隊資訊，播放報告中擷取的時間軸。操作員可以使用時間軸中的部分資訊演練案例，並描述他們將採取的動作。然後，遊戲日的主持人可以提供有關應用程式如何根據操作員動作回應的指導。這可開發運算子的故障診斷技能，以便更輕鬆地預測和故障診斷問題。
負責應用程式可靠性的集中式團隊應將這些報告保存在整個組織可存取的集中式程式庫中。此團隊也應該負責維護報告範本，並訓練團隊如何完成事件分析報告。可靠性團隊應定期檢閱報告，以偵測可透過軟體程式庫、架構模式或團隊程序變更來解決的業務趨勢。
## 執行操作審查
如[階段 4：營運](stage-4.md)所述，營運審查是檢閱最新功能版本、事件和營運指標的機會。營運審查也是與您組織中更廣泛的工程社群分享功能版本和事件學習的機會。在營運審查期間，團隊會檢閱已復原的功能部署、發生的事件，以及它們的處理方式。這讓整個組織的工程師有機會從其他人的經驗中學習並提出問題。
向貴公司的工程社群開啟營運審查，以便他們可以進一步了解執行業務的 IT 應用程式，以及他們可能遇到的問題類型。他們會在為企業設計、實作和部署其他應用程式時，攜帶這些知識。
## 檢閱警示效能
如*操作*階段所述，警示可能會導致儀表板警示、建立票證、傳送電子郵件或分頁運算子。 應用程式將設定許多警示來監控其操作的各個層面。隨著時間的推移，應檢閱這些警示的準確性和有效性，以提高警示精確度、減少誤報，以及合併重複警示。
### 警示精確度
警示應盡可能具體，以減少您必須花費的時間來解釋或診斷造成警示的特定中斷。當警示因應用程式受損而引發時，接收和回應警示的運算子必須先解譯警示傳遞的資訊。資訊可能是映射到復原程序等動作過程的簡單錯誤代碼，也可能包含應用程式日誌中的行，您必須檢閱這些行來了解引發警示的原因。當您的團隊學習更有效地操作應用程式時，他們應該精簡這些警示，使其盡可能清晰簡潔。
您無法預測應用程式的所有可能中斷，因此一律會有需要操作員分析和診斷的一般警示。您的團隊應該努力減少一般警示的數量，以改善回應時間並縮短平均修復時間 (MTTR)。理想情況下，警示與自動化或人工執行的回應之間應該有one-to-one的關係。
### 誤報
如果警示不需要來自運算子的動作，但會產生提醒，因為隨著時間的推移，運算子會忽略電子郵件、頁面或票證。 定期或作為事件分析的一部分，檢閱警示以識別經常忽略或不需要運算子採取動作的警示 (*誤判*)。 您應該努力移除警示，或改善警示，以便向運算子發出可採取動作的警示。
### 偽陰性
在事件期間，設定為在事件期間提醒的警示可能會失敗，可能是因為事件以非預期的方式影響應用程式。 作為事件分析的一部分，您應該檢閱應該已提出但未提出的警示。您應該努力改善這些警示，以便更好地反映事件可能產生的條件。或者，您可能必須建立其他警示，以映射至相同的中斷，但是由不同的中斷症狀所引發。
### 重複提醒
影響應用程式的中斷可能會導致多個症狀，並可能導致多個警示。 定期或作為事件分析的一部分，您應該檢閱發出的警示和提醒。 如果操作員收到重複的警示，請建立彙總警示，將其合併為單一警示訊息。
## 執行指標檢閱
您的團隊應該收集與您應用程式相關的操作指標，例如每月的事件數量、偵測事件的時間、識別原因的時間、修復的時間，以及建立的票證數量、傳送的提醒，以及提出的頁面。至少每月檢閱這些指標一次，以了解營運人員的負擔、他們處理的signal-to-noise（例如資訊警示與可行的警示），以及團隊是否改善其在其控制下操作應用程式的能力。使用此檢閱來了解營運團隊可衡量層面的趨勢。向團隊詢問如何改善這些指標的想法。
## 提供訓練和啟用
很難擷取導致事件或意外行為的應用程式及其環境的詳細說明。此外，建立應用程式的彈性模型來預測這類案例並不總是簡單明瞭。您的組織應該投資訓練和啟用資料，讓您的營運團隊和開發人員參與彈性建模、事件分析、遊戲日和混沌工程實驗等活動。這將提高團隊所產生報告的逼真度，以及他們所擷取的知識。這些團隊也將更有能力預測失敗，而不需要依賴更小、經驗更豐富的工程師群組，他們必須透過排定的審查來提供洞見。
## 建立事件知識庫
事件報告是來自事件分析的標準輸出。您應該使用相同或類似的報告來記錄偵測到異常應用程式行為的案例，即使應用程式未受損。使用相同的標準化報告結構來擷取混沌實驗和遊戲日的結果。報告代表應用程式及其環境的快照，導致事件或其他意外行為。您應該將這些標準化報告存放在中央儲存庫，讓企業中的所有工程師都能存取。
然後，營運團隊和開發人員可以搜尋此知識庫，以了解過去中斷應用程式的情況、可能導致中斷的情況類型，以及防止應用程式受損的情況。此知識庫可加速提升營運團隊和開發人員的技能，並讓他們能夠分享其知識和經驗。此外，您可以使用報告做為遊戲日或混沌實驗的訓練材料或案例，以改善營運團隊的直覺和疑難排解中斷的能力。
**注意**
標準化的報告格式也為讀者提供熟悉感，並協助他們更快找到他們正在尋找的資訊。
## 深度實作彈性
如前所述，進階組織將對警示實作多個回應。我們無法保證回應會有效，因此透過分層回應，應用程式將更能夠正常地失敗。我們建議您為每個指標實作至少兩個回應，以確保個別回應不會成為可能導致 DR 案例的單一失敗點。 這些層應以序列順序建立，因此只有在先前的回應無效時才會執行連續的回應。您不應該對單一警示執行多個分層回應。反之，請使用警示來指出回應是否失敗，如果是，則啟動下一個分層回應。