共用方式為


設計部署失敗緩解策略的建議

適用於此 Power Platform Well-Architected 卓越營運檢查清單建議:

OE:11 實施部署失敗緩解原則,該原則透過快速復原來解決意外的推出中期問題。 結合多種方法,例如復原、功能提用,或使用部署模式的本機功能。

本指南介紹設計標準化策略,以有效處理部署失敗的建議。 與其他工作負載問題一樣,部署失敗是工作負載生命週期中不可避免的一部分。 有了這種心態,您就可以透過精心設計、有意的策略來積極主動地處理部署失敗。 這樣的策略使您的工作負載團隊能夠有效地緩解失敗,並盡可能減少對使用者的影響。

缺乏這樣的計劃可能會導致對問題的混亂和潛在有害的回應,這可能會嚴重影響團隊和組織的凝聚力、客戶信任和財務。

關鍵設計原則

有時,儘管您的開發實務很成熟,但仍會出現部署問題。 使用安全的部署實務並營運強大的工作負載供應鏈可以幫助您最大限度地減少部署失敗的頻率。 您還需要設計一個標準化的策略來處理發生的失敗部署。

部署失敗緩解策略由五個主要階段組成:

  1. 偵測:要應對失敗的部署,您必須先偵測失敗。 偵測可以採取多種形式,例如失敗的煙霧測試、使用者報告或監控平台產生的警示。
  2. 決策:您必須決定針對特定失敗類型的最佳緩解策略是什麼。
  3. 緩解:您必須執行已確定的緩解措施。 緩解措施可以採取回退、回滾或前滾的形式。
  4. 溝通:根據緊急應變計畫的要求,在發現並解決問題時,必須讓利害關係人和受影響的使用者了解情況。
  5. 事後分析:無責事後分析為工作量團隊提供了機會來找出需要改進的領域並製定計劃來應用學習成果。

以下各節提供了針對各階段的詳細建議。

偵測

為了快速識別部署問題,您需要與部署相關的強大測試和監控實務。 為了幫助快速偵測異常,您可以使用應用程式效能管理工具並透過儀器記錄來補充您的工作負載監控和警示。

煙霧測試和其他品質測試應該在部署的每個階段進行。 一個部署群組中的成功測試不應影響後續群組中的測試決策。

您可以實施將使用者問題與部署階段相關聯的遙測。 然後,您可以快速識別特定使用者與哪個部署群組關聯。 此方法對於漸進式公開部署尤其重要,因為在部署中的任何指定點,您可能會在使用者群組中執行多個設定。

您應該準備好立即回應使用者報告的問題。 只要可行,當您擁有完整的支援團隊時,請在工作時間部署您的推出階段。 確保支援人員接受過如何升級部署問題以實現正確路由的訓練。 升級應與您的工作負載應急回應計劃保持一致。

決策

針對部署問題制定適當的緩解策略需要考慮以下因素:

  • 您使用的漸進式曝光模型的類型。 例如,您可以使用藍綠模型或金絲雀模型。 如果使用藍綠模型,回退比回滾更實用。 您可以輕鬆地將流量轉移回執行未更新設定的堆疊。 然後,您可以在有問題的環境中修復問題,並在適當的時間再次嘗試部署。

  • 您可以使用的繞過問題的方法。 範例包括使用功能標誌、環境變數,或可以開啟和關閉的任何其他類型的執行時間設定屬性。 有時,您可以透過關閉功能標誌或切換設定來輕鬆繞過問題。 在這種情況下,您也許能夠:

    • 繼續推出。
    • 避免回退。
    • 在修復有問題的程式碼時回滾。
  • 在程式碼中實施修復所需的工作量。 如果修復程式碼的努力程度較低,那麼透過實作修補程式來向前捲動是某些情況下的正確選擇。

  • 受影響工作負載的嚴重程度。 業務關鍵型工作負載應始終以並行方式部署,例如藍綠模型,以實現零停機部署。 因此,對於這些類型的工作負載,回退是更好的緩解策略。

緩解措施

以下是一些常見的緩解策略:

  • 復原:在復原情境中,您可以將更新的系統恢復到上次已知的良好設定狀態。

    整個工作量團隊對「最後一次正確的」含義達成共識非常重要。此運算式指的是部署開始之前工作負載的最後狀態,不一定是先前的應用程式版本。

    回滾可能很複雜,特別是當它涉及資料變更時。 結構描述變更可能會帶來回滾風險。 可能需要大量的規劃才能安全地實施它們。 通常建議採用附加方法更新結構描述。 舊記錄不應被新記錄所取代。 相反,較舊的記錄應棄用,並應與新記錄共存,直到可以安全地刪除已棄用的記錄為止。

  • 後援:在後援情境中,更新的系統將從生產流量路由中刪除。 所有流量都導向到未更新的堆疊。 這種低風險策略提供了一種方法,可讓您在解決程式碼的問題時不會造成進一步中斷。

    對於金絲雀部署,回退可能並不簡單,甚至不可能執行,這取決於您的基礎結構和應用程式設計。 如果您需要執行擴充功能來處理未更新的系統上的負載,請在回退之前執行該擴充。

  • 繞過有問題的功能:如果您可以使用功能標誌或其他類型的執行階段設定屬性來繞過該問題,那麼您可能會決定繼續推出是解決問題的正確策略。

    您應該清楚地了解繞過該功能的權衡考量,並且您應該能夠向利害關係人傳達該取捨。 利害關係人應核准前進計劃。 利害關係人需要確定在降級狀態下運作的可容忍時間長度。 他們還需要根據您對修復有問題程式碼並部署它所需的時間,來權衡這一決定。

  • 緊急部署 (修補程式):如果您可以在部署過程中解決問題,那麼修補程式可能是最實用的緩解策略。

    與任何其他程式碼一樣,修補程式需要經過安全部署實務。 但經過修復後,這個時間表就大大加快了。 您需要在整個環境中使用程式碼升級策略。 您還需要在所有品質關口處檢查修補程式代碼。 但您可能需要大幅縮短準備時間,並且可能需要修改測試以加速它們。 確保您可以在部署後儘快對更新的程式碼執行完整測試。 高度自動化品質保證測試有助於提高這些場景中的測試效率。

通訊

明確定義溝通責任非常重要,這有助於最大程度地減少事件期間的混亂。 這些職責應確定工作負載團隊如何與支援團隊、利害關係人和緊急應變團隊人員 (例如緊急應變經理) 合作。

標準化工作負載團隊提供狀態更新所遵循的節奏。 確保利害關係人了解此標準,以便他們知道何時需要更新。

如果工作負載團隊需要直接與使用者溝通,請明確適合共用的資訊類型和詳細程度。 也要向工作負載團隊傳達適用於這些案例的任何其他要求。

事後剖析

所有失敗的部署都應進行事後分析,沒有例外。 每一次失敗的部署都是一次學習的機會。 事後分析可以幫助您識別部署和開發過程中的弱點以及基礎結構中的錯誤設定。

事後分析永遠都不應該究責,好讓參與事件的個人在分享自己對可以改進方面的看法時感到安全。 事後領導者應該跟進實施已確定的改進計劃,並將這些計劃新增到工作量積壓中。

注意事項和一般建議

確保您的部署管線可以接受不同的版本做為參數,以便您可以輕鬆部署最後一次正確的設定。

回滾或前滾時保持管理平面和資料平面的一致性。 特定於資源和策略的金鑰、機密、資料庫狀態資料和設定都需要在範圍內並加以考慮。 例如,請注意最後一次已知良好部署中基礎結構擴充的設計。 確定在重新部署代碼時是否需要調整該設定。

優先考慮小而頻繁的變更,而不是不頻繁的大變更,以便新的部署和上次已知良好的部署之間的差異很小。

對持續整合和持續交付 (CI/CD) 管道執行失敗模式分析,以協助識別可能使緩解工作複雜化的問題。 與您的整體工作負載一樣,可以分析您的管道以識別在您嘗試指定的緩解類型時可能出現問題的區域。

明智地使用自動回滾功能:

  • 一些 CI/CD 工具 (例如 Azure DevOps) 具有內建的自動回滾功能。 如果此功能為您提供了有形的價值,請考慮使用它。
  • 僅在徹底、定期測試管線後,您才應採用自動回滾功能。 確保您的管線足夠成熟,可以在觸發自動回滾時引入額外的問題。
  • 您需要相信自動化僅部署必要的更改,並且僅在必要時觸發。 仔細設計觸發程序以滿足這些要求。

在回滾期間使用平台提供的功能。 例如,備份和時間點復原可以幫助儲存和資料復原。 或者,如果您使用虛擬機器來託管您的應用程式,將您的環境恢復到事件發生之前的檢查點會很有幫助。

經常測試整個部署失敗緩解策略。 與緊急應變計畫和災難復原計畫一樣,只有當您的團隊接受過相關培訓並定期進行實踐時,您的部署失敗計畫才能成功。 混沌工程和失敗注入測試可以成為測試部署緩解策略的有效技術。

Power Platform 簡易化

Power Platform 中的管線旨在透過將 ALM 自動化和持續整合和持續交付 (CI/CD) 功能引入服務中,為 Power Platform 和 Dynamics 365 客戶實現應用程式生命週期管理 (ALM) 的民主化。

適用於 Azure DevOps的 Microsoft Power Platform Build Tools 可用於自動執行與在 Power Platform 上建置的應用程式相關的常見建置和部署工作。

適用於 Power Platform 的 GitHub Actions 使開發人員能夠建立自動化的軟體開發生命週期工作流程。 借助 Microsoft Power Platform 的 GitHub 動作,您可以在存放庫中建立工作流程,用來組建、測試、打包、發佈及部署應用程式;執行自動化以及管理機器人和 Microsoft Power Platform 所建立的其他元件。

ALM Accelerator 是一個開源工具,由一組應用程式、指令碼和管線組成,旨在自動化持續整合/持續交付流程。

使用 Azure Pipelines 自動執行測試

使用 Power CAT Copilot Studio Kit 設定代理程式和測試。 透過針對 Copilot Studio API 執行單獨的測試 (Direct Line),可以根據預期結果評估代理程式回應。

解決方案中的環境變數會儲存參數索引鍵和值,然後將其作為其他應用程式物件的輸入。 將參數與取用物件分開可在同一環境中或將解決方案移轉到其他環境時變更值。

Power Platform 環境提供時間點還原功能,可協助您復原。

Power Platform 與 Application Insights 整合,後者是 Azure Monitor 生態系統的一部分。 使用此整合來:

  • 接收由 Dataverse 平台在 Application Insights 中擷取的診斷和效能遙測。 您可以訂閱以接收有關應用程式在 Dataverse 資料庫和模型導向應用程式中執行之作業的遙測。 此遙測提供的資訊可用於診斷和疑難排解與錯誤和效能相關的問題。

  • 連接畫布應用程式至 Application Insights 您可以使用這些分析來診斷問題並了解使用者對您的應用程式執行的動作。 您可以收集資訊,協助您推動更周延的商業決策並改善您的應用程式品質。

  • 設定 Power Automate 遙測流入 Application Insights;例如,監控雲端流程執行,並為雲端流程執行失敗建立警示。

  • 從您的 Microsoft Copilot Studio代理程式擷取遙測資料,以供在 Azure Application Insights 中使用。 您可以使用此遙測來監控發送和來自代理程式的記錄訊息和事件、使用者對話期間觸發的主題,以及可以從您的主題發送的自訂遙測事件。

卓越營運清單

請參閱完整的建議集。