關於設計緊急回應原則的建議
適用於此 Power Platform Well-Architected 卓越運營清單建議：
| OE：07 年 | 制定有效的應急作業實踐。 請確保工作負載發出有意義的健全狀況信號。 收集生成的數據並使用它來生成可操作的警報，這些警報通過控制面板和查詢來制定緊急回應。 明確定義人員職責，例如待命輪換、事件管理、緊急資源存取和執行事後剖析。 |
|---|
本指南會說明關於設計緊急回應原則的建議。 您的某些工作負載可能是任務關鍵型工作負載，在工作負載生命週期中出現的問題可能嚴重到需要宣佈它們為緊急情況。 您可以實施嚴格控制和集中的流程和程序，您的團隊可以遵循這些流程和程序，確保以冷靜、有序的方式處理問題。 緊急情況自然會提高每個人的壓力等級，如果您的團隊準備不足，可能會導致環境混亂。 為了協助將壓力和混亂減到最少，請設計回應原則，與您的組織共享回應原則，並定期執行應急回應培訓。
關鍵設計原則
緊急回應原則應該是一套明確定義的流程和程序。 每個流程和程式都應該有腳本，以確保每個步驟都能讓您的團隊快速安全地解決問題。 若要制定應急回應原則，請考慮以下概述：
- 先決條件
- 制定監控系統
- 建立事件回應計畫
- 事件階段
- 檢測和遏制
- 分級
- 後事件階段
- 根本原因分析 (RCA)
- 事後剖析
- 進行中的活動
- 緊急回覆演練
以下各節提供了針對其中每個階段的建議。
監控系統
要制定強大的應急回覆策略，您需要擁有強大的監控系統或可觀測性平臺。 您的可檢視性平台應具有以下特徵：
整體監控：確保從配置和應用程式的角度全面監控工作負載，如果工作負載的元件託管在雲中或內部部署中，則包括基礎設施監控。 確保監控策略涵蓋工作負載的所有元件。 例如，如果您的工作負載與 Azure 資源或內部部署系統交互，請在監控中包含這些元件。
詳細日誌記錄：為您的元件啟用詳細日誌記錄，以便在對問題進行分類時協助進行調查。 構建紀錄，使其易於管理。 自動將紀錄發送到資料接收器以準備分析。
有用的控制面板：根據您的運行狀況模型創建為組織中的每個團隊量身定製的控制面板。 不同的團隊負責工作負載健全狀況的不同方面。
可操作的警報：創建對工作負載團隊有用的警報。 避免不需要團隊執行動作的警報。 此類警報過多可能會導致人們忽略或阻止警報通知。
自動通知：確保相應的團隊自動接收需要他們採取行動的警報。 例如，您的 Tier 1 支援團隊應該收到所有警報的通知，而您的安全工程師應該只收到安全事件的警報。
有關更多資訊，請參閱 有關設計和創建監控框架的建議。
事件回應計畫
事件回應計畫是緊急回應原則的基礎。 與災難恢復計劃一樣，要清晰、徹底地定義回應事件的角色、職責和程式。 該計畫應是一個由版本控制的文件，需要定期進行檢閱，以確保它是最新的。
在您的計畫中明確定義以下元件。
角色
找出事件回應經理。 此人擁有從啟動到修正再到根本原因分析的事件。 事件回覆經理確保遵循流程，並在回覆團隊執行其工作時通知相關方。
確定事後分析領導者。 此人能確保在事件解決後立即進行事後分析。 他們會產生一份報告，協助您套用從事件中得出的結果。
流程和程序
您的工作負載團隊應定義並了解緊急情況標準。 當您的團隊確定案例嚴重時，您可以宣佈災害並啟動災害復原計畫。 在不太嚴重的情況下，問題可能不符合災難的標準，但您仍應將問題視為緊急情況，這需要啟動緊急回覆計劃。 緊急情況可能是工作負載內部的，例如應用程式代碼中的錯誤，也可能是工作負載依賴項問題的結果，例如 API 或資料庫不可用。 緊急情況也可能是由廠商中斷引起的 (例如和 Microsoft Entra 識別碼或 Power Platform 有關的問題)。 支援團隊必須能夠確定問題是否符合緊急標準，即使團隊無法瞭解潛在問題。
準確地定義通訊和上報計計畫。 根據他們收到的警報通知類型，確保您的 Tier 1 支援團隊成員可以輕鬆聯繫相應的團隊以解決上報的問題。
要包括的其他項目
記錄事件期間用於內部通信的所有標準工具，例如 Microsoft Teams，以及用於跟蹤事件過程中的活動，例如票證工具或積壓工作計劃工具。
記錄您的緊急憑證，也稱為破窗帳戶。 包括描述如何使用它們的逐步指南。
創建緊急回覆切入說明，並記錄何時進行演習。
記錄任何必要的法律或監管措施，例如傳達數據洩露。
事件檢測和遏制
當您有一個設計良好的監視系統，可監視異常並自動發出警報時，您可以快速偵測問題並確定其嚴重性。 如果問題被視為緊急情況，則可以啟動該計畫。 在某些情況下，支持團隊不會通過監控系統收到通知。 使用者可能會使用支援小組通訊途徑向支援人員報告問題。 或者，他們可能會聯繫經常合作的人或他們知道正在合作 Power Platform的人，例如您的 Power Platform 服務管理員或卓越中心團隊。 無論如何通知支援小處，他們都應始終遵循相同的步驟來驗證問題並確定嚴重性。 偏離回應計畫會增加壓力和混亂。
分級
問題修復的第一步是確定導致問題的工作負載元件。 在分類期間要遵循的步驟取決於問題的類型。 負責某個工作負載支援領域的團隊應為與其工作相關的事件創建程式。 例如，安全性團隊應分類安全性問題，並應遵循他們制定的指令碼。 團隊在進行分類工作時，遵循明確定義的指令碼非常重要。 這些腳本應該是分步說明，其中包括回滾過程，以撤消無效或可能導致其他問題的更改。 解決問題後，請按照定義完善的流程，安全地將受影響的元件帶回工作負載流程路徑。
根本原因分析報告
事件擁有者或與他們密切合作的人員應創建根本原因分析 (RCA) 報告。 此原則可確保事件的確切說明。 通常，組織有一個定義的 RCA 範本，其中包含如何呈現資訊以及哪些類型的資訊可以共用或不能共用的準則。 如果您需要創建自己的範本和指南，請確保利益相關者審查和批准它們。
事件事後分析
一個公正的人應該導向完善的事後分析。 在事後分析會議中，每個人都會分享他們從事件中的發現。 回覆，參與事件的每個團隊都應由處理事件的個人代表。 這些人應該準備好成功行動和可以改進的領域的範例來參加會議。 該會議不是為回覆期間可能出現的事件或問題分配責任的論壇。 事後分析負責人應在會議結束時，明確列出著重於改進的動作清單，例如：
- 改進回應計畫。 可能需要重新評估和重寫流程或程序，以在擷取適當的動作方面表現更佳。
- 改進監控系統。 可能需要重新評估閾值以更早發現特定類型的事件，或可能需要實施新的監控來找出未考慮的行為。
- 工作負載的改進。 該事件可能會暴露工作負載中的漏洞，必須將其作為永久修正來解決。
考量因素
您的應急回應原則應與您的整體Power Platform 支援原則緊密結合。 與您的 Power Platform 管理員和卓越中心團隊合作，討論可能已經定義的支持和緊急回覆選項和流程。
在定義支援流程和上報路徑時，請務必根據嚴重性對建構的解決方案進行分類。 這種做法允許您建立流程，確保關鍵應用程式具有必要的護欄來支援它們，同時不會扼殺生產力方案的創新或使您的事件回覆團隊不堪重負。 在定義支援模型時，還要考慮升級路徑。 解決方案可能一開始只需要生產力級別的支援，但功能或使用者群的增長需要更高級別的支援。 定義製作者如何要求更正式的支援，並將解決方案轉換至支援的環境。
Power Platform 便利
Power Platform 與 Application Insights 整合，後者是 Azure Monitor 生態系統的一部分。 使用此整合來：
接收由 Dataverse 平台在 Application Insights 中擷取的診斷和效能遙測。 您可以訂閱以接收有關應用程式在 Dataverse 資料庫和模型導向應用程式中執行之作業的遙測。 此遙測提供的資訊可用於診斷和疑難排解與錯誤和效能相關的問題。
連接畫布應用程式至 Application Insights 您可以使用這些分析來診斷問題並了解使用者對您的應用程式執行的動作。 您可以收集資訊，協助您推動更周延的商業決策並改善您的應用程式品質。
配置 Power Automate 要流入 的遙測數據 Application Insights;例如，監控雲端流程執行併為雲端流程運行失敗創建警報。
從 Copilot Microsoft Copilot Studio 捕獲遙測數據以在 Azure Application Insights 中使用。 您可以使用此遙測來監控發送到 Copilot 和從 Copilot 發送的記錄消息和事件、在使用者對話期間觸發的主題，以及可以從您的主題發送的自定義遙測事件。
Application Insights 是一個綜合解決方案，用於收集、分析和回應來自運端和內部部署環境的監視資料。 它包括一個強大的警報平台，讓您可以為自動通知和其他動作進行設定。
Power Platform自動化套件是一套工具，可加速電腦版 Power Automate 自動化專案的使用及支援。 套件提供工具，可協助您管理自動化專案並監控，以估計已儲存和投資回報 (ROI)。 Automation Kit 的一部分是 控制中心，它補充了現有的 Monitor 桌面流程 runs 功能。 控制中心的重點是一個流程協調檢視，供支援分析師和組織在必要時進行監視、採取動作和發出警報。