設計部署失敗風險降低策略的建議
適用于此 Azure Well-Architected Framework Operational Excellence 檢查清單建議：
| OE：12 | 實作部署失敗風險降低策略，以解決快速復原的非預期中推出問題。 結合多種方法，例如復原、功能停用，或使用部署模式的原生功能。 |
|---|
本指南說明設計標準化策略以有效處理部署失敗的建議。 與其他工作負載問題一樣，部署失敗是工作負載生命週期的一部分。 透過這種思維，您可以透過妥善設計且刻意的策略來處理部署失敗，來主動進行。 這類策略可讓工作負載小組有效率地降低失敗，並盡可能降低對使用者的影響。
沒有這類計畫可能會導致問題的混亂和潛在有害回應，這可能會影響小組和組織關係、客戶信任和財務。
主要設計策略
有時候，儘管開發實務的成熟度，但部署問題仍會發生。 使用 安全的部署做法 並操作健全的 工作負載供應鏈 ，可協助您將失敗部署的頻率降到最低。 但是，您也需要設計標準化策略，以處理失敗的部署發生時。
當您使用漸進式揭露部署模型作為標準做法時：
- 在部署失敗時，您有適當的基礎，可將對客戶或內部使用者的影響降至最低。
- 您可以有效率地減輕問題。
部署失敗風險降低策略是由五個廣泛階段所組成：
偵測：若要回應失敗的部署，您必須先偵測失敗。 偵測可以採用數種形式，例如失敗的噴氣測試、使用者回報的問題，或監視平臺所產生的警示。
決策：您必須決定特定失敗類型的最佳風險降低策略。
風險降低：您可以執行已識別的風險降低動作。 緩和措施的形式可以是後援、復原、向前復原，或使用執行時間組態略過違規函式。
通訊：專案關係人與受影響的終端使用者必須知道您偵測到並視 緊急回應計畫需要處理問題時的狀態。
事後：無責任的事後檢定可為工作負載小組提供機會，以找出改進領域，並建立套用學習的計畫。
下列各節提供這些階段的詳細建議。 這些區段假設您在將變更部署至一或多個使用者或系統群組之後偵測到問題，但在您推出方案中更新所有群組之前。
偵測
若要快速找出部署的問題，您需要與部署相關的強固測試和 可觀察性做法 。 若要協助快速偵測異常，您可以採取下列步驟來補充工作負載監視和警示：
- 使用應用程式效能管理工具。
- 透過 檢測啟用記錄。
在推出的每個階段，應該進行噴氣測試和其他品質測試。 一個部署群組中的成功測試不應影響在後續群組中測試的決策。
您可以實作遙測，以將使用者問題與部署階段相互關聯。 然後，您可以快速識別特定使用者相關聯的推出群組。 這種方法對於漸進式揭露部署特別重要，因為您可能在部署中的任何指定時間點在使用者基底上執行多個組態。
您應該準備好立即回應使用者回報的問題。 只要可行，請在工作時間部署您的推出階段，當您有完整的支援小組可用時。 請確定支援人員已訓練如何呈報部署問題以取得適當的路由。 呈報應與您的工作負載 緊急回應計畫一致。
決策
決定特定部署問題的適當風險降低策略牽涉到考慮許多因素，包括：
您使用的漸進式曝光模型類型。 例如，您可以使用藍綠模型或 Canary 模型。
如果您使用藍綠模型，回溯比回復更實用。 您可以輕鬆地將流量移回執行未更新之設定的堆疊。 然後，您可以在有問題的環境中修正問題，並在適當的時間再試一次您的部署。
您處置的方法可略過問題。 範例包括使用功能旗標、環境變數，或任何您可以開啟和關閉的執行時間組態屬性其他類型的屬性。
有時候，您可以關閉功能旗標或切換設定，輕鬆地略過問題。 在此情況下，您可能能夠：
- 繼續進行推出。
- 避免回復。
- 修正違規程序代碼時復原。
在程式碼中實作修正所需的工作層級。
如果修正程式碼的工作量很低，實作熱修正是特定案例的正確選擇。
受影響工作負載的重要性層級。
業務關鍵性工作負載應該一律以並存方式部署，例如藍綠模型，以達到零停機時間部署。 因此，回復是這些工作負載類型較佳的風險降低策略。
工作負載使用的基礎結構類型，可變動或固定。
如果您的工作負載是設計成使用可變動的基礎結構，則向前復原可能很合理，因為它牽涉到就地更新基礎結構。 相反地，當您使用不可變的基礎結構時，回復或回復可能很合理。
無論您所做的選擇為何，都應該在決策制定程式中納入適當的核准，並在決策樹中加以編碼。
風險降低
復原：在復原案例中，您會將更新的系統還原為最後已知良好的設定狀態。
對於整個工作負載小組而言，請務必同意 最後已知良好的意義。 此運算式是指部署開始之前狀況良好之工作負載的最後一個狀態，這不一定是先前的應用程式版本。
回復可能很複雜，特別是與資料變更相關的情況。 架構變更可能會有風險地回復。 安全地實作它們可能需要相當多的規劃。 一般建議是架構更新的加法。 它們不應該取代變更-記錄不應取代為新記錄。 相反地，較舊的記錄應該已被取代，而且應該與新記錄共存，直到移除已被取代的記錄安全為止。
後援：在後援案例中，更新的系統會從生產流量路由中移除。 所有流量都會導向至未更新的堆疊。 這種低風險策略可讓您解決程式碼中的問題，而不會造成進一步的中斷。
使用 Canary 部署時，視您的基礎結構和應用程式設計而定，回溯可能並不簡單或甚至可能。 如果您需要執行調整以處理未更新之系統上的負載，請在回復之前執行該調整。
略過違規函式：如果您使用功能旗標或其他類型的執行時間組態屬性略過問題，您可能會決定繼續推出是給定問題的正確策略。
您應該清楚瞭解略過函式的取捨，而且您應該能夠與專案關係人溝通該取捨。 專案關係人應核准向前計畫。 專案關係人必須判斷可容忍的時間長度，才能處於降級狀態。 他們也需要根據您修正違規程序代碼並部署所需時間的估計來衡量該判斷。
緊急部署 (經常性修正) ：如果您可以在推出時解決問題，熱修正可能是最實用的風險降低策略。
就像任何其他程式碼一樣，經常性修正需要完成您的安全部署做法。 但是，使用熱修正，時間軸會大幅加速。 您必須在整個環境中使用程式碼升級策略。 您也需要在所有品質閘道檢查熱修正程式碼。 但您可能需要大幅縮短製作時間，而且您可能需要修改測試以加速測試。 請確定您可以在部署後儘快對更新的程式碼執行完整測試。 將品質保證測試自動化為高度，有助於在這些案例中有效測試。
取捨：
- 能夠回復通常表示您需要足夠的基礎結構容量，才能同時處理兩個版本的工作負載組態。 您的工作負載小組也必須能夠同時支援生產中的兩個版本。
- 能夠有效地復原可能牽涉到重構工作負載的元素。 例如，您可能需要分離函式或變更資料模型。
溝通
請務必清楚定義通訊責任，以協助將事件期間的混亂降到最低。 這些責任應該建立工作負載小組如何與支援小組、專案關係人及緊急回應小組人員互動，例如緊急回應管理員。
標準化工作負載小組針對提供狀態更新所遵循的步調。 請確定專案關係人知道此標準，讓他們知道何時需要更新。
如果工作負載小組需要直接與使用者通訊，請厘清適合與使用者共用的資訊類型和詳細資料層級。 也請與工作負載小組溝通適用于這些案例的任何其他需求。
事後調查
事後應該遵循所有失敗的部署，但不例外。 每個失敗的部署都是學習的機會。 事後描述可協助您識別部署和開發程式中的弱點。 您也可以識別基礎結構中的設定錯誤，以及其他許多可能性。
事後圖應一律為無責者，讓參與事件的個人在分享可改善專案的觀點時感到安全。 後續文章領導者應遵循計畫，以實作已識別的改進，並將這些計畫新增至工作負載待辦專案。
考慮和一般建議
請確定您的部署管線可以接受不同的版本做為參數，以便您可以輕鬆地部署最後已知良好的組態。
在復原或向前復原時，維持與管理和資料平面的一致性。 資源與原則專屬的金鑰、秘密、資料庫狀態資料和組態，都必須在範圍中並加以考慮。 例如，請注意在上次已知良好的部署中調整基礎結構的設計。 判斷您是否需要在重新部署程式碼時調整該組態。
偏好小型、頻繁的變更，而非頻繁、大型變更，讓新部署與最後已知良好的部署之間的差異很小。
在持續整合和持續傳遞 (CI/CD) 管線上執行 失敗模式分析 (FMA) ，以協助找出可能使風險降低問題複雜的問題。 就像整個工作負載一樣，您可以分析管線，以識別嘗試指定風險降低類型時可能會有問題的區域。
謹慎地使用自動化復原功能：
- Azure DevOps 之類的一些 CI/CD 工具具有內建的自動復原功能。 如果提供有形的價值給您，請考慮使用這項功能。
- 只有在徹底且定期地測試管線之後，才應該採用自動復原功能。 確定您的管線已成熟，足以在觸發自動回復時產生額外的問題。
- 您必須信任自動化只部署必要的變更，而且只有在需要時才觸發。 仔細設計觸發程式以符合這些需求。
在復原期間使用平臺提供的功能。 例如，備份和時間點還原有助於儲存體和資料復原。 或者，如果您使用虛擬機器 (VM) 來裝載應用程式，將環境還原到事件之前立即的檢查點會很有説明。
經常測試整個部署失敗風險降低策略。 就像緊急回應計畫和災害復原計畫一樣，只有在小組經過訓練並定期進行練習時，您的部署失敗計畫才會成功。 混亂工程和 錯誤插入測試 可以是測試部署風險降低策略的有效技術。
Azure 設施
Azure Pipelines 提供建置和發行服務，以支援應用程式的 CI/CD。
Azure Test Plans是以瀏覽器為基礎的測試管理解決方案，很容易使用。 此解決方案提供計劃性手動測試、使用者接受度測試和探勘測試所需的功能。 Azure Test Plans也可讓您收集項目關係人的意見反應。
Azure 監視器 是一個全方位的監視解決方案，可用來收集、分析和回應來自雲端和內部部署環境的監視資料。 監視包含健全的警示平臺。 您可以針對 自動通知和其他動作設定該系統，例如自動調整和其他自我修復機制。
Application Insights 是監視的延伸模組，可提供應用程式效能監視 (APM) 功能。
Azure Logic Apps 是雲端式平臺，可執行自動化工作流程，整合應用程式、資料、服務和系統。 您可以使用 Logic Apps 在對應用程式進行更新時建立新版本的應用程式。 Azure 會維護版本的歷程記錄，並可還原或升級任何先前的版本。
許多 Azure 資料庫服務提供時間點還原功能，可協助您在需要復原時：
Azure Chaos Studio 預覽 版是一項受控服務，使用混亂工程來協助您測量、瞭解及改善雲端應用程式和服務復原能力。
相關連結
營運卓越檢查清單
請參閱一組完整的建議。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應