Share via

設計緊急回應策略的建議

  • 發行項

適用于此 Azure Well-Architected Framework 營運卓越檢查清單建議：

OE：08 開發有效的緊急作業實務。 請確定您的工作負載會跨基礎結構和程式碼發出有意義的健康情況訊號。 收集產生的資料，並用它來產生可採取動作的警示，以透過儀表板和查詢制定緊急回應。 清楚定義人為責任，例如通話輪替、事件管理、緊急資源存取，以及執行事後分析。

本指南說明設計緊急回應策略的建議。 工作負載生命週期過程中發生的一些問題非常重要，足以保證宣告它們很困難。 您可以實作嚴格控制且專注的程式和程式，讓小組可以遵循這些程式，以確保問題是以一般、有順序的方式處理。 如果小組未妥善準備，則自然地提高每個人的壓力等級，並可能導致混亂的環境。 為了協助將壓力和混淆降到最低、設計回應策略、與組織共用回應策略，以及執行一般緊急回應訓練。

主要設計策略

緊急回應策略應該是一組妥善定義的程式和程式。 每個程式和程式都應該有腳本，以確保每個步驟都會讓您的小組快速且安全地解決問題。 若要開發緊急回應策略，請考慮下列概觀：

  • 必要條件
    • 開發可檢視性平臺
    • 建立事件回應計劃
  • 事件階段
    • 偵測
    • Containment
    • 分級
  • 事件後階段
    • RCA) (根本原因分析
    • 事後調查
  • 進行中的活動
    • 緊急回應演練

下列各節提供每個階段的建議。

可檢視性

若要具備健全的緊急回應策略，您必須備妥健全的可檢視性平臺。 您的可檢視性平臺應該具有下列特性：

  • 整體監視：確保您從基礎結構和應用程式的觀點徹底監視您的工作負載。

  • 詳細資訊記錄：為元件啟用詳細資訊記錄，以協助您在分級問題時進行調查。 結構記錄，使其易於管理。 自動將記錄傳送至要準備進行分析的資料接收。

  • 實用的儀表板：建立健康情況模型型儀表板，專為整個組織中的每個小組量身打造。 不同的小組負責工作負載健康情況的不同層面。

  • 可採取動作的警示：建立適合您工作負載小組的警示。 避免不需要小組採取動作的警示。 這類警示太多可能會導致使用者忽略或封鎖警示通知。

  • 自動通知：確定適當的小組會自動收到需要對其採取動作的警示。 例如，您的第 1 層支援小組應該會收到所有警示的通知，而您的安全性工程師應該只取得安全性事件的警示。

如需詳細資訊，請參閱 設計和建立可檢視性架構的建議。

事件回應計畫

緊急回應策略的基礎是事件回應計畫。 就像災害復原計畫一樣，清楚且徹底地定義事件回應計畫的角色、責任和程式。 計畫應該是受版本控制的檔，受限於定期檢閱，以確保其為最新狀態。

清楚定義方案中的下列元件。

角色

識別事件回應管理員。 此人擁有從初始到補救到根本原因分析的事件。 事件回應管理員可確保遵循程式，並在回應小組執行其工作時通知適當的合作物件。

識別事後領導者。 此人員可確保事件解決之後，就會立即執行事後檢閱。 它們會產生報告，可協助您套用事件所產生的結果。

程式和程式

您的工作負載小組應該定義並瞭解緊急準則。 當小組判斷案例嚴重時，您可以宣告災害並起始災害復原計畫。 在較不嚴重的情況下，問題可能不符合災害的準則。 但您仍應該考慮此問題為緊急狀況，這需要起始緊急回應計畫。 緊急狀況可能是工作負載內部的問題，也可能是您工作負載相依性的問題。 即使外部使用者沒有基礎問題的可見度，支援小組也必須能夠判斷外部使用者所回報的問題是否符合緊急準則。

精確地定義通訊和呈報計畫。 根據收到的警示通知類型，請確定您的第 1 層支援可以輕鬆地連絡適當的小組，以呈報問題。 請確定他們知道哪一種通訊適用于內部和外部合作物件。 在通訊和呈報計畫中，包含通話排程和員工的清單。

在整體計畫中，包含內含專案和分級腳本。 Teams 會在執行其內含專案和分級函式時，遵循這些逐步程式。 包含定義事件關閉之專案的描述。

要包含的其他專案

記錄事件期間將用於內部通訊的所有標準工具，例如 Microsoft Teams，以及追蹤事件程序中的活動，例如票證工具或待辦專案規劃工具。

記錄您的緊急認證，否則稱為 急用帳戶。 包含說明其使用方式的逐步指南。

建立緊急回應演練指示，並在執行演練時保留 的記錄。

記載任何必要的法律或法規措施，例如通訊資料外泄。

事件偵測

當您有妥善設計的可觀察性平臺，可監視異常狀況並自動警示時，您可以快速偵測問題並判斷其嚴重性。 如果問題被視為緊急狀況，則可以起始方案。 在某些情況下，支援小組不會透過可檢視性平臺收到通知。 客戶可能會使用支援小組通訊途徑來回報支援的問題。 或者，他們可能會與他們定期合作的人員聯繫，例如帳戶主管或 VP。 無論支援小組如何收到通知，他們都應該一律遵循相同的步驟來驗證問題並判斷嚴重性。 與回應計畫的偏差可能會增加壓力和混淆。

Containment

問題補救的第一個步驟是包含保護其餘工作負載的問題。 內含專案策略取決於問題類型，但通常涉及從工作負載流程路徑移除受影響的元件。 例如，您可以關閉資源，或將其從網路路由路徑中移除。 系統管理員、工程師和資深開發人員應該共同合作，以設計內含專案策略。 內含專案應限制問題的彈射半徑，並維持處於降級狀態的工作負載功能，直到問題解決為止。 如果需要存取受影響的元件才能執行分級，請務必封鎖其對其餘工作負載的存取權。 您應該盡可能只透過與工作負載和其餘系統分開的路徑來存取元件。

分級

成功包含問題之後，您就可以開始分級工作。 您在分級期間遵循的步驟取決於問題類型。 工作負載支援特定區域的小組應該為與其小組相關的事件建立程式。 例如，安全性小組應該將安全性問題分級，而且應該遵循他們開發的腳本。 小組在經過分級工作時，請務必遵循定義完善的腳本。 這些腳本應該是包含復原程式的逐步程式，以復原不正確變更，或可能會導致其他問題。 使用現成的記錄匯總和分析工具，有效率地調查需要深入分析的問題。 問題解決之後，請遵循定義完善的程式，安全地將受影響的元件帶回工作負載流程路徑。

RCA 報告

服務等級協定 (SLA) 給您的客戶，可能會指出您必須在事件解決之後的特定時段內發出 RCA 報告。 事件擁有者應該建立 RCA 報告。 如果不可能，與事件擁有者密切合作的另一個人可以建立 RCA 報告。 此策略可確保事件的準確會計。 一般而言，組織具有已定義的 RCA 範本，其中包含如何呈現資訊的指導方針，以及可以或無法共用哪些類型的資訊。 如果您需要建立自己的範本和指導方針，請確定專案關係人已檢閱和核准。

事件事後檢閱

個人應該會導致無責任事後檢視。 在事後研討會中，每個人都會分享事件的結果。 參與事件回應的每個小組都應該由處理事件的個人代表。 這些人員應前往已備妥的會話，其中包含成功區域和可改善的區域範例。 此研討會不是指派事件或回應期間可能發生問題的責任者論壇。 事後討論領導者應該讓會話保持清楚的動作專案清單，這些動作專案著重于改善，例如：

  • 回應計畫的改善。 可能需要重新評估和重寫程式，以更妥善地擷取適當的動作。

  • 改善可檢視性平臺。 可能需要重新評估臨界值以攔截先前的特定事件種類，或可能需要實作新的監視來攔截未考慮的行為。

  • 工作負載的改善。 事件可能會公開工作負載中必須解決為永久補救的弱點。

考量事項

過度積極回應策略可能會導致誤報或不必要的呈報。

同樣地，積極實作自動調整或其他自我修復動作來回應臨界值缺口，可能會導致不必要的支出和管理負擔。 您可能不知道要針對警示和自動動作設定的確切閾值，例如調整。 在較低環境和生產環境中執行測試，以協助您判斷需求的正確閾值。

Azure 指導

Azure 監視器 是收集、分析及回應雲端和內部部署環境監視資料的完整解決方案。 它包含健全的警示平臺，您可以針對 自動通知和其他動作進行設定，例如自動調整和其他自我修復機制。

使用監視器來整合機器學習。 自動化並優化事件分級和主動措施。 如需詳細資訊，請參閱 監視器中的 AIOps 和機器學習。

Log Analytics 是內建在監視器中的強固分析工具。 您可以使用 Log Analytics 針對匯總的記錄執行查詢，並取得工作負載的相關見解。

Microsoft 提供 Azure 相關事件整備訓練。 如需詳細資訊，請參閱 Azure 事件整備 和 事件整備簡介。

營運卓越檢查清單

請參閱一組完整的建議。

營運卓越檢查清單