設計部署失敗緩解策略的建議
適用於此 Power Platform Well-Architected 卓越運營清單建議：
| OE：11 | 實施部署失敗緩解原則，該原則透過快速復原來解決意外的推出中期問題。 結合多種方法，例如復原、功能提用，或使用部署模式的本機功能。 |
|---|
本指南介紹設計標準化策略，以有效處理部署失敗的建議。 與其他工作負載問題一樣，部署失敗是工作負載生命週期中不可避免的一部分。 有了這種心態，您就可以透過精心設計、有意的策略來積極主動地處理部署失敗。 這種策略使您的工作負載團隊能夠有效地緩解故障，同時儘可能減少對用戶的影響。
缺乏這樣的計劃可能會導致對問題的混亂和潛在有害的回應，這可能會嚴重影響團隊和組織的凝聚力、客戶信任和財務。
關鍵設計原則
有時，儘管您的開發實務很成熟，但仍會出現部署問題。 使用安全的部署實務並營運強大的工作負載供應鏈可以幫助您最大限度地減少部署失敗的頻率。 您還需要設計一個標準化策略，以便在部署失敗時對其進行處理。
部署失敗緩解策略由五個主要階段組成：
- 檢測：要回應失敗的部署，您必須首先檢測失敗。 檢測可以採取多種形式，例如冒煙測試失敗、使用者報告或監控平臺生成的警報。
- 決策：您必須確定針對特定故障類型的最佳緩解策略。
- 緩解措施：您必須執行已確定的緩解措施。 緩解措施可以採取回退、回滾或前滾的形式。
- 溝通：根據緊急回覆計劃的要求，在您檢測和解決問題時，必須讓利益相關者和受影響的使用者了解狀態。
- 事後分析：無指責的事後分析為工作負載團隊提供了確定需要改進的領域並制定應用學習成果的計劃的機會。
以下各節提供了針對各階段的詳細建議。
偵測
要快速識別部署問題，您需要與部署相關的強大測試和監控實踐。 為了説明快速檢測異常，您可以通過使用應用程式性能管理工具並通過檢測進行日誌記錄來補充工作負載監控和警報。
煙霧測試和其他品質測試應該在部署的每個階段進行。 一個部署群組中的成功測試不應影響後續群組中的測試決策。
您可以實施將使用者問題與部署階段相關聯的遙測。 然後，您可以快速識別特定使用者與哪個部署群組關聯。 此方法對於漸進式公開部署尤其重要，因為在部署中的任何指定點，您可能會在使用者群組中執行多個設定。
您應該準備好立即回應使用者報告的問題。 只要可行，當您擁有完整的支援團隊時，請在工作時間部署您的推出階段。 確保支持人員接受培訓，瞭解如何上報部署問題以實現正確路由。 升級應與您的工作負載應急回應計劃保持一致。
決策
為部署問題確定適當的緩解策略涉及考慮以下因素：
您使用的漸進式曝光模型的類型。 例如，您可以使用藍綠模型或金絲雀模型。 如果使用藍綠模型，回退比回滾更實用。 您可以輕鬆地將流量轉移回執行未更新設定的堆疊。 然後，您可以在有問題的環境中修復問題，並在適當的時間再次嘗試部署。
您可以使用的繞過問題的方法。 範例包括使用功能標誌、環境變數，或可以開啟和關閉的任何其他類型的執行時間設定屬性。 有時，您可以透過關閉功能標誌或切換設定來輕鬆繞過問題。 在這種情況下，您也許能夠：
- 繼續推出。
- 避免回退。
- 在修復有問題的程式碼時回滾。
在程式碼中實施修復所需的工作量。 如果修復代碼的工作量較低，則在某些情況下，通過實施修補程式前滾是正確的選擇。
受影響工作負載的嚴重程度。 業務關鍵型工作負載應始終以並行方式部署，例如藍綠模型，以實現零停機部署。 因此，對於這些類型的工作負載，回退是更好的緩解策略。
緩解措施
以下是一些常見的緩解策略：
回滾：在回滾場景中，您還原將系統更新到上次已知的良好配置狀態。
對於整個工作負載團隊來說，就“last known good”的含義達成一致非常重要。此表達式是指在部署開始之前運行狀況良好的工作負載的最後狀態，這不一定是以前的應用程式版本。
回滾可能很複雜，特別是當它涉及資料變更時。 結構描述變更可能會帶來回滾風險。 可能需要大量的規劃才能安全地實施它們。 通常建議採用附加方法更新結構描述。 記錄不應替換為新記錄。 相反，較舊的記錄應棄用，並應與新記錄共存，直到可以安全地刪除已棄用的記錄為止。
Fallback：在回退方案中，更新的系統將從生產流量路由中刪除。 所有流量都導向到未更新的堆疊。 這種低風險策略提供了一種方法，可讓您在解決程式碼的問題時不會造成進一步中斷。
對於金絲雀部署，回退可能並不簡單，甚至不可能執行，這取決於您的基礎結構和應用程式設計。 如果您需要執行擴充功能來處理未更新的系統上的負載，請在回退之前執行該擴充。
繞過有問題的功能：如果可以通過使用功能標誌或其他類型的運行時配置屬性來繞過問題，則可能會決定繼續推出是解決問題的正確策略。
您應該清楚地了解繞過該功能的權衡考量，並且您應該能夠向利害關係人傳達該取捨。 利害關係人應核准前進計劃。 利害關係人需要確定在降級狀態下運作的可容忍時間長度。 他們還需要根據您對修復有問題程式碼並部署它所需的時間，來權衡這一決定。
緊急部署 (修補程式)：如果您可以在推出過程中解決問題，則修補程式可能是最實用的緩解策略。
與任何其他代碼一樣，修補程式需要遵循您的安全部署實踐。 但是通過熱修復，時程表會大大加快。 您需要在整個環境中使用程式碼升級策略。 您還需要在所有品質關卡中檢查修補程式碼。 但您可能需要大幅縮短準備時間，並且可能需要修改測試以加速它們。 確保您可以在部署後儘快對更新的程式碼執行完整測試。 高度自動化品質保證測試有助於提高這些場景中的測試效率。
通訊
明確定義溝通責任非常重要，這有助於最大程度地減少事件期間的混亂。 這些職責應確定工作負載團隊如何與支援團隊、利害關係人和緊急應變團隊人員 (例如緊急應變經理) 合作。
標準化工作負載團隊提供狀態更新所遵循的節奏。 確保利害關係人了解此標準，以便他們知道何時需要更新。
如果工作負載團隊需要直接與使用者通信，請闡明適合共用的信息類型和詳細程度。 也要向工作負載團隊傳達適用於這些案例的任何其他要求。
事後剖析
事後分析應無一例外地跟隨所有失敗的部署。 每一次失敗的部署都是一次學習的機會。 事後分析可以説明您識別部署和開發流程中的弱點以及基礎設施中的錯誤配置。
事後分析永遠都不應該究責，好讓參與事件的個人在分享自己對可以改進方面的看法時感到安全。 事後分析負責人應跟進實施已確定的改進的計劃，並將這些計劃添加到工作負載積壓工作中。
注意事項和一般建議
確保您的部署管線可以接受不同的版本做為參數，以便您可以輕鬆部署最後一次正確的設定。
回滾或前滾時保持管理平面和資料平面的一致性。 特定於資源和策略的金鑰、機密、資料庫狀態資料和設定都需要在範圍內並加以考慮。 例如，請注意最後一次已知良好部署中基礎結構擴充的設計。 確定在重新部署代碼時是否需要調整該設定。
首選小的、頻繁的更改，而不是不頻繁的大更改，這樣新的部署和上次已知的良好部署之間的差異就會很小。
對持續集成和持續交付 (CI/CD) 管道執行故障模式分析，以幫助識別可能使緩解工作複雜化的問題。 與整個工作負載一樣，可以分析您的管道，以確定在嘗試給定緩解類型時可能存在問題的區域。
明智地使用自動回滾功能：
- 一些 CI/CD 工具 (例如 Azure DevOps) 具有內建的自動回滾功能。 如果此功能為您提供了有形的價值，請考慮使用它。
- 僅在徹底、定期測試管線後，您才應採用自動回滾功能。 確保您的管線足夠成熟，可以在觸發自動回滾時引入額外的問題。
- 您需要相信自動化僅部署必要的更改，並且僅在必要時觸發。 仔細設計觸發程序以滿足這些要求。
在回滾期間使用平台提供的功能。 例如，備份和時間點還原可以幫助實現存儲和數據回滾。 或者，如果您使用虛擬機來託管應用程式，則將環境還原到事件發生前的檢查點可能會有所説明。
經常測試整個部署失敗緩解策略。 與緊急應變計畫和災難復原計畫一樣，只有當您的團隊接受過相關培訓並定期進行實踐時，您的部署失敗計畫才能成功。 混沌工程和故障注入測試 是測試部署緩解策略的有效技術。
Power Platform 簡易化
管道旨在通過 Power Platform 將 ALM 自動化以及持續集成和持續交付 (CI/CD) 功能引入服務，為 Power Platform Dynamics 365 客戶實現應用程式生命週期管理 (ALM) 的大眾化。
Microsoft Power Platform Build Tools for Azure DevOps 可用於自動執行與所構建 Power Platform應用程式相關的常見構建和部署任務。
GitHub Actions 使 Power Platform 開發人員能夠構建自動化的軟體開發生命週期工作流。 借助 Microsoft Power Platform 的 GitHub 動作，您可以在存放庫中建立工作流程，用來組建、測試、打包、發佈及部署應用程式；執行自動化以及管理機器人和 Microsoft Power Platform 所建立的其他元件。
ALM Accelerator 是一個開源工具，由一組應用程式、腳本和管道組成，旨在自動化持續集成/持續交付過程。
使用 Azure Pipelines 自動執行測試。
使用 Power CAT Copilot Studio Kit 配置 Copilot 和測試。 通過針對 Copilot Studio API（）Direct Line 運行單個測試，將根據預期結果評估 Copilot 回應。
解決方案 中的環境變數存儲參數鍵和值，然後用作其他應用程式對象的輸入。 將參數與取用物件分開可在同一環境中或將解決方案移轉到其他環境時變更值。
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 發送的記錄消息和事件、在使用者對話期間觸發的主題，以及可以從您的主題發送的自定義遙測事件。
卓越營運清單
請參閱完整的建議集。