設計部署失敗風險降低策略的建議
適用於此 Azure 架構完善的架構營運卓越檢查清單建議：
| OE：12 | 實作部署失敗風險降低策略，以解決快速復原的非預期中推出問題。 結合多種方法，例如復原、功能停用，或使用部署模式的原生功能。 |
|---|
本指南說明設計標準化策略以有效處理部署失敗的建議。 與其他工作負載問題一樣，部署失敗是工作負載生命週期的必然部分。 透過這種心態，您可以透過設計完善的刻意策略來處理部署失敗，來主動。 這類策略可讓工作負載小組有效率地降低失敗，並盡可能不影響終端使用者。
缺乏這類計劃可能會導致對問題的混亂和潛在有害反應，這可能會影響團隊和組織凝聚力、客戶信任和財務。
關鍵設計策略
有時候，儘管開發做法成熟，但部署問題還是會發生。 使用 安全部署做法 並操作健全 的工作負載供應鏈 ，可協助您將失敗部署的頻率降到最低。 但是，您也需要設計標準化的策略，以處理失敗的部署。
當您使用漸進式曝光部署模型作為標準做法時：
- 在部署失敗時，您有正確的基礎，將客戶或內部使用者的影響降到最低。
- 您可以有效率地減輕問題。
部署失敗風險降低策略是由五個廣泛的階段所組成：
偵測：若要回應失敗的部署，您必須先偵測失敗。 偵測可以採取數種形式，例如失敗的煙霧測試、用戶回報的問題，或監視平臺所產生的警示。
決策：您必須決定特定失敗類型的最佳風險降低策略。
風險降低：您執行已識別的風險降低動作。 風險降低的形式可以是後援、復原、向前復原，或使用運行時間設定來略過違規函式。
通訊：項目關係人和受影響的終端用戶必須知道您偵測到問題，並根據您的緊急回應計劃需要處理問題。
驗屍：無可指責的驗屍為工作負載小組提供機會，以找出改進的領域，並建立套用學習的計劃。
下列各節提供這些階段的詳細建議。 這些區段假設您在將變更部署至一或多個使用者或系統群組之後偵測到問題，但在您推出方案中更新所有群組之前。
設計失敗偵測機制
若要快速識別部署的問題，您需要與部署相關的強固測試和 可觀察性做法 。 若要協助快速偵測異常，您可以採取下列步驟來補充工作負載監視和警示：
- 使用應用程式效能管理工具。
- 透過 檢測啟用記錄。
煙霧測試和其他質量測試應該發生在推出的每個階段。 一個部署群組中的成功測試不應影響在後續群組中測試的決策。
您可以實作將用戶問題與部署階段相互關聯的遙測。 然後，您可以快速識別特定使用者相關聯的推出群組。 這種方法對於漸進式曝光部署來說特別重要，因為您可能會在部署中的任何指定時間點，跨使用者基底執行多個設定。
您應該已準備好立即回應使用者回報的問題。 每當可行時，當您有完整的支援小組可用時，請在工作時間部署您的首度發行階段。 請確定支持人員已訓練如何呈報部署問題以取得適當的路由。 呈報應與您的工作負載 緊急回應計劃一致。
決定風險降低策略
決定特定部署問題的適當風險降低策略牽涉到考慮許多因素，包括：
您使用的漸進式曝光模型類型。 例如，您可以使用藍色-綠色模型或 Canary 模型。
如果您使用藍綠模型，倒退比回復更實用。 您可以輕鬆地將流量移回執行未更新之設定的堆疊。 然後，您可以在有問題的環境中修正問題，並在適當的時間再次嘗試部署。
您有可用來略過問題的方法。 範例包括使用功能旗標、環境變數，或任何您可以開啟和關閉的其他類型的運行時間組態屬性。
有時候，您可以關閉功能旗標或切換設定，輕鬆地略過問題。 在此情況下，您可能能夠：
- 繼續進行首度發行。
- 避免回落。
- 修正違規程式代碼時回復。
在程式代碼中實作修正所需的工作層級。
如果修正程式代碼的努力層級很低，則實作經常性修正是特定案例的正確選擇。
受影響工作負載的嚴重性層級。
業務關鍵性工作負載應一律以並存方式部署，例如藍綠色模型，以達到零停機時間部署。 因此，回溯是這些工作負載類型較佳的風險降低策略。
工作負載使用的基礎結構類型，可變動或固定。
如果您的工作負載是設計來使用可變基礎結構，則向前復原可能會有意義，因為它牽涉到就地更新基礎結構。 相反地，當您使用不可變的基礎結構時，回復或回復可能會有意義。
無論您做出哪一個選擇，都應該在決策程式中納入適當的核准，並在判定樹中編纂它們。
實作風險降低策略
復原：在復原案例中，您會將更新的系統還原為最後已知良好的設定狀態。
對於整個工作負載小組而言，請務必同意最後已知良好的意義。 此表達式是指部署開始前狀況良好之工作負載的最後一個狀態，這不一定是先前的應用程式版本。
回復可能很複雜，特別是因為它與數據變更有關。 架構變更可能會造成復原風險。 安全地實作它們可能需要相當多的規劃。 一般建議，架構更新應加總。 它們不應該取代變更，記錄不應該取代為新的記錄。 相反地，較舊的記錄應該已被取代，而且應該與新記錄並存，直到移除已被取代的記錄是安全的。
後援：在後援案例中，更新的系統會從生產流量路由中移除。 所有流量都會導向至未更新的堆疊。 這種低風險策略可讓您解決程式代碼中的問題，而不會造成進一步的中斷。
使用 Canary 部署時，根據基礎結構和應用程式設計，回溯可能並不簡單甚至可能。 如果您需要執行調整以處理未更新之系統上的負載，請先執行該調整再回復。
略過冒犯函式：如果可以使用功能旗標或其他類型的運行時間組態屬性略過問題，您可能會決定繼續推出是給定問題的正確策略。
您應該清楚瞭解略過函式的取捨，而且您應該能夠與專案關係人溝通該取捨。 項目關係人應核准前進計劃。 項目關係人必須判斷可容忍以降級狀態運作的時間長度。 他們也需要根據修正違規程式碼並加以部署所需時間的估計來權衡該判斷。
緊急部署（經常性修正）：如果您可以在推出時解決問題，則經常性修正可能是最實用的緩和策略。
和任何其他程式代碼一樣，經常性修正需要完成您的安全部署做法。 但是，使用熱修正，時間軸會大幅加速。 您必須在整個環境中使用程式代碼升級策略。 您也需要檢查所有品質閘道的熱修正程式碼。 但您可能需要大幅縮短製作時間，而且您可能需要修改測試來加速測試。 請確定您可以在部署后儘快對更新的程式代碼執行完整測試。 將質量保證測試自動化到高度有助於在這些案例中有效地進行測試。
取捨：
- 能夠回復通常表示您需要足夠的基礎結構容量，才能同時處理兩個版本的工作負載組態。 您的工作負載小組也必須能夠同時支持生產中的兩個版本。
- 能夠有效地復原可能牽涉到重構工作負載的元素。 例如，您可能需要分離函式或變更數據模型。
在事件期間標準化狀態更新
請務必明確定義通訊責任，以協助將事件期間的混亂降到最低。 這些責任應建立工作負載小組如何與支援小組、項目關係人和緊急回應小組人員互動，例如緊急回應管理員。
標準化工作負載小組針對提供狀態更新所遵循的步調。 請確定項目關係人知道此標準，讓他們知道何時需要更新。
如果工作負載小組需要直接與用戶通訊，請釐清適合與用戶共用的信息類型和詳細數據層級。 也請與工作負載小組溝通適用於這些案例的任何其他需求。
進行事件事後分析
驗屍應該遵循所有失敗的部署，但無例外。 每個失敗的部署都是學習的機會。 驗屍可協助您找出部署和開發程式中的弱點。 您也可以識別基礎結構中的設定錯誤，以及其他許多可能性。
驗屍應該永遠是無罪的，這樣參與事件的個人在分享自己對可以改善什麼的看法時會感到安全。 驗屍主管應跟進計劃，以實作已識別的改進，並將這些計劃新增至工作負載待辦專案。
讓風險降低程序運作
請確定您的部署管線可以接受不同的版本做為參數，以便您可以輕鬆地部署最後一個已知良好的組態。
當您復原或向前復原時，維持與管理和數據平面的一致性。 資源與原則特有的密鑰、秘密、資料庫狀態數據和組態，都必須在範圍中並加以考慮。 例如，請注意在最後一個已知良好的部署中調整基礎結構規模的設計。 判斷您是否需要在重新部署程式代碼時調整該組態。
偏好小型、頻繁的變更，而不是不常發生的大型變更，讓新部署與最後一個已知良好的部署之間的差異很小。
在您的 持續整合和持續傳遞 （CI/CD） 管線上執行失敗模式分析 （FMA）， 以協助找出可能會使風險降低複雜的問題。 如同整體工作負載，您可以分析管線，以識別嘗試指定風險降低類型時可能會有問題的區域。
以巧妙方式使用自動化回復功能：
- 某些 CI/CD 工具，例如 Azure DevOps 具有內建的自動回復功能。 如果此功能提供有形值，請考慮使用此功能。
- 只有在徹底且定期地測試管線之後，才應該採用自動回復功能。 確定您的管線已足夠成熟，以在觸發自動回復時引入額外的問題。
- 您必須信任自動化只會部署必要的變更，而且只有在需要時才觸發。 請仔細設計觸發程式以符合這些需求。
在復原期間使用平臺提供的功能。 例如，備份和時間點還原有助於儲存和數據復原。 或者，如果您使用虛擬機（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 Preview 是一種受控服務，使用混亂工程來協助您測量、瞭解及改善雲端應用程式和服務復原能力。
相關連結
卓越營運檢查清單
請參閱一組完整的建議。