設計緊急回應策略的建議
適用於此 Azure 架構完善的架構營運卓越檢查清單建議：
| OE：08 | 制定有效的應急行動實踐。 確定您的工作負載會在基礎結構和程式代碼之間發出有意義的健康情況訊號。 收集產生的數據，並用它來產生可採取動作的警示，以透過儀錶板和查詢制定緊急回應。 明確定義人力責任，例如隨叫用輪替、事件管理、緊急資源存取，以及執行驗屍。 |
|---|
本指南說明設計緊急回應策略的建議。 工作負載生命週期中出現的一些問題非常重要，足以保證宣告為緊急情況。 您可以實作嚴格控制且專注的程式和程式，讓小組可以遵循，以確保以平靜、有序的方式處理問題。 突發事件自然會提高每個人的壓力水準，如果您的團隊準備不充分，可能會導致混亂的環境。 為了協助將壓力和混淆降至最低，請設計回應策略、與您的組織共享回應策略，以及執行定期的緊急響應訓練。
關鍵設計策略
緊急回應策略應該是一組有條不紊、妥善定義的程序和程式。 每個程式和程式都應該有腳本，以確保每個步驟都會讓您的小組快速且安全地解決問題。 若要開發緊急回應策略，請考慮下列概觀：
- 必要條件
- 開發可觀察性平臺
- 建立事件回應計劃
- 事件階段
- 偵測
- Containment
- 分級
- 事件後階段
- 根本原因分析 （RCA）
- 事後調查
- 進行中活動
- 緊急響應演練
下列各節提供每個階段的建議。
若要有健全的緊急回應策略，您必須備妥健全的可觀察性平臺。 您的可觀察性平台應該具有下列特性：
整體監視：請務必從基礎結構和應用程式的觀點徹底監視工作負載。
詳細信息記錄：為元件啟用詳細信息記錄，以協助您在分級問題時進行調查。 結構記錄，使其易於管理。 自動將記錄傳送至要準備進行分析的數據接收。
實用的儀錶板：建立健康情況模型型儀錶板，專為貴組織中的每個小組量身打造。 不同的小組負責工作負載健康情況的不同層面。
可採取動作的警示：建立適用於工作負載小組的警示。 避免不需要小組採取動作的警示。 這類警示太多可能會導致人們忽略或封鎖警示通知。
自動通知：確定適當的小組會自動接收需要其動作的警示。 例如，您的第 1 層支援小組應該收到所有警示的通知，而您的安全性工程師應該只取得安全性事件的警示。
如需詳細資訊，請參閱 設計及建立可觀察性架構的建議。
建立事件回應計劃
應急策略的基礎是事件回應計劃。 如同災害復原計劃，清楚且徹底地定義事件響應計劃的角色、責任和程式。 計劃應該是版本控制的檔，其受限於定期檢閱，以確保其為最新狀態。
在方案中清楚定義下列元件。
角色
識別事件回應管理員。 此人擁有從起始到補救到根本原因分析的事件。 事件回應管理員可確保遵循程式，並在回應小組執行其工作時通知適當的合作物件。
識別驗屍領導者。 此人員可確保事件解決後不久就會執行驗屍。 他們會產生報告，協助您套用事件的結果。
進程和程式
您的工作負載小組應該定義並了解緊急準則。 當小組判斷案例嚴重時，您可以宣告災害並起始災害復原計劃。 在較不嚴重的情況下，問題可能不符合災害的準則。 但您仍然應該考慮這個問題，這是需要啟動緊急反應計劃的緊急狀態。 緊急情況可能是您工作負載內部的問題，或可能是工作負載相依性發生問題的結果。 即使外部使用者無法查看基礎問題，支援小組也必須能夠判斷外部使用者所回報的問題是否符合緊急準則。
精確地定義通訊和呈報計劃。 根據他們收到的警示通知類型，請確定您的第 1 層支援可以輕鬆地連絡適當的小組，以呈報問題。 請確定他們知道哪一種通訊類型適用於內部和外部合作物件。 在溝通和呈報方案中，包括隨選排程和員工清單。
在整體計劃中，包括內含專案和分級腳本。 Teams 會在執行內含專案和分級函式時，遵循這些逐步程式。 包含定義事件關閉之專案的描述。
要包含的其他專案
記錄事件期間將用於內部通訊的所有標準工具，例如 Microsoft Teams，以及追蹤事件過程中的活動，例如票證工具或待辦項目規劃工具。
記錄您的緊急認證，否則稱為 斷層帳戶。 包含描述其使用方式的逐步指南。
建立緊急響應演練指示，並在執行演練時保留 的記錄。
記錄任何必要的法律或法規措施，例如通訊數據外洩。
根據可觀察性觸發程式採取行動
當您有一個設計完善的可觀察性平臺，可監視異常並自動對其發出警示時，您可以快速偵測問題並判斷其嚴重性。 如果問題被視為緊急狀況，則可以啟動計劃。 在某些情況下，支援小組不會透過可觀察性平臺收到通知。 客戶可能會使用支援小組溝通途徑回報支持的問題。 或者，他們可能會與他們經常合作的人員聯繫，例如帳戶主管或 VP。 無論支援小組如何收到通知，他們都應該一律遵循相同的步驟來驗證問題並判斷嚴重性。 偏離回應計劃可能會增加壓力和混淆。
定義內含專案程式
問題補救的第一個步驟是包含保護其餘工作負載的問題。 內含專案策略取決於問題類型，但通常牽涉到從工作負載流程路徑移除受影響的元件。 例如，您可能會關閉資源，或從網路路由路徑中移除資源。 系統管理員、工程師和資深開發人員應共同設計內含專案策略。 內含專案應限制問題的爆破半徑，並維持處於降級狀態的工作負載功能，直到問題解決為止。 如果受影響的元件需要存取才能執行分級，請務必封鎖其對其餘工作負載的存取。 盡可能多地，您應該只透過與工作負載和其餘系統分開的路徑來存取元件。
定義分級程式
成功包含問題之後，您就可以開始分級工作。 您在分級期間遵循的步驟取決於問題類型。 工作負載支援特定區域的小組應該為與其小組相關的事件建立程式。 例如，安全性小組應該分類安全性問題，而且應該遵循其開發的腳本。 小組在經過分級工作時，請務必遵循定義完善的腳本。 這些腳本應該是包含復原程式的逐步程式，以復原無效的變更，或可能導致其他問題。 使用現成的記錄匯總和分析工具，有效率地調查需要深入分析的問題。 問題解決之後，請遵循定義完善的程式，安全地將受影響的元件帶回工作負載流程路徑。
產生 RCA 事件報告
客戶的服務等級協定（SLA）可能會決定您必須在事件解決後的一段時間內發出 RCA 報告。 事件擁有者應該建立 RCA 報告。 如果不可能，與事件擁有者密切合作的另一個人可以建立 RCA 報告。 此策略可確保事件的準確報告。 一般而言，組織具有已定義的 RCA 範本，其中包含如何呈現資訊的指導方針，以及哪些類型的資訊可以或無法共用。 如果您需要建立自己的範本和指導方針，請確定項目關係人已檢閱和核准它們。
保存事件事後分析
一個公正的個人應該領導無可指責的驗屍。 在驗屍會議中，每個人都分享了事件的結果。 參與事件回應的每個小組都應該由處理事件的個人代表。 這些人員應來到會議，並備妥成功區域和可改進的區域範例。 會議不是指派事件責任的論壇，也不是在響應期間可能發生的問題。 驗屍主管應該將會議保留清楚的動作專案清單，以專注於改進，例如：
回應計劃的改善。 程式或程式可能需要重新評估並重寫，才能更妥善地擷取適當的動作。
改善可觀察性平臺。 可能需要重新評估閾值以攔截先前的特定事件類型，或可能需要實作新的監視，以攔截未考慮的行為。
工作負載的改善。 此事件可能會公開工作負載中必須作為永久補救的弱點。
考量
過於積極的回應策略可能會導致誤報或不必要的呈報。
同樣地，積極實作自動調整或其他自我修復動作以響應臨界值缺口，可能會導致不必要的支出和管理負擔。 您可能不知道要針對警示和自動動作設定的確切閾值，例如調整。 在較低環境和生產環境中執行測試，以協助您判斷需求的正確閾值。
Azure 便利化
Azure 監視器 是收集、分析及回應來自雲端和內部部署環境之監視數據的完整解決方案。 它包含強固的警示平臺，您可以針對 自動通知和其他動作進行設定，例如自動調整和其他自我修復機制。
使用監視器整合機器學習服務。 自動化並優化事件分級和主動措施。 如需詳細資訊，請參閱 監視中的 AIOps 和機器學習。
Log Analytics 是內建在監視器中的強固分析工具。 您可以使用Log Analytics對匯總記錄執行查詢，並取得工作負載的相關見解。
Microsoft提供 Azure 相關事件整備訓練。 如需詳細資訊，請參閱 Azure 事件整備和事件整備簡介。
相關連結
卓越營運檢查清單
請參閱一組完整的建議。