設計可靠性測試策略的建議
適用於以下 Azure Well-Architected Framework 可靠性檢查清單建議：
| RE：08 | 藉由套用混亂工程的原則來測試復原和可用性案例。 執行主動故障和模擬負載測試，以確保您的優雅降級實作和擴展策略有效。 |
|---|
本指南說明設計可靠性測試策略的建議，以驗證和優化工作負載的可靠性。 可靠性測試著重於工作負載的復原性和可用性，特別是您在設計解決方案時識別的重要流程。 本指南提供一般測試指引，以及針對錯誤插入和混亂工程的特定指引。
定義
| 術語 | 定義 |
|---|---|
| 可用性 | 應用程式工作負載以狀況良好狀態執行的時間量，而不需要長時間停機。 |
| 混亂工程 | 將應用程式和服務經受真實世界壓力和故障的做法。 混亂工程的目標是要建置和驗證對不可靠條件和遺漏相依性的復原能力。 |
| 錯誤插入 | 將錯誤引入系統以測試系統復原的動作。 |
| 復原能力 | 韌性的同義字。 |
| 彈性 | 應用程式工作負載抵抗和從故障模式中恢復的能力。 |
關鍵設計策略
測試可靠性準備
定期執行測試，以驗證現有的臨界值、目標和假設。 當您的工作負載發生重大變更時，請執行一般測試。 在測試和預備環境中執行大部分的測試。 對生產系統進行部分測試也很有幫助。 計劃主要測試環境與生產環境的一對一對應。
自動化測試，以協助確保一致的測試涵蓋範圍和重現性。 將一般測試工作自動化，並將其整合到您的建置程式中。 手動測試軟體很乏味且容易發生錯誤，但您可以進行手動探勘測試。 針對您需要開發自動化測試的情況，請使用手動測試來判斷要開發的測試範圍。
採用左移測試方法，於開發週期的早期階段進行韌性及可用性測試。
調整簡單的檔案格式，讓每個人都很容易瞭解每個一般測試的程序和結果。
與適當的團隊共用記錄的成果，例如營運團隊、技術領導、業務關係人，以及災難復原相關人員。 結果應通知可靠性目標的精簡，例如服務等級目標（SLO）、服務等級協定（SLA）、恢復時間目標（RTO）和恢復點目標（RPO）。
為您的備份建立定期測試流程。 將數據還原到隔離的系統，以協助確保備份有效且還原正常運作。
與您的災害復原專案關係人記錄和共用復原時間計量，以確保對復原的期望是適當的。
使用業界標準 部署測試程式，協助確保您擁有自動化、可預測且有效率的部署程式。
測試工作負載抵抗暫時性故障的能力。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
測試您的工作負載在面對負載模式的變化和使用量高峰時的應對能力。 使用此資訊可協助您測試 調整策略。 如需負載和壓力測試的相關信息，請參閱測試 的建議。
使用故障注入測試您的工作負載如何處理相依服務或其他依賴的失敗情況。
測試並驗證您的 自我修復和自我保護設計 如何回應故障。 測試自動化和手動復原作業。
測試您的 災害復原計劃，以回應重大失敗和其他重大事件。
測試工作負載正常降級的能力，並通過故障注入將元件故障的影響範圍降到最低。
善用計劃性與非計劃性中斷
當您的工作負載因為計劃性維護或非計劃性中斷而離線時，您有機會執行測試並改善您對工作負載的理解。 下列各節提供每個案例的建議。
計劃性維護
當您規劃更新或修補程式的維護期間時，可以測試與維護工作無關的元件和流程。 執行測試，而不會有意外地降低工作負載效能或完全使其離線的風險。 如果您在維護期間有足夠的時間，您也可以在維護工作完成之後測試與維護相關的元件和流程。
非計劃性中斷
使用每個中斷事件作為深入瞭解工作負載的機會，並遵循下列步驟，依優先順序排序來改善其復原能力：
讓客戶的工作負載重新上線。 若要這樣做，您可以針對問題執行因應措施、解決問題，或起始復原程式。
判斷中斷的根本原因，並加以解決。 如果您可以在調查中修正根本原因，請記錄根本原因和您修正它所採取的措施。 如果問題需要稍後採取額外的維護時間範圍，請徹底測試風險降低措施，以確保您的緩和措施可以處理預期的負載。 請確定您已設定足夠的監視功能，以涵蓋風險降低措施。
如果適用，請在工作負載中的所有元件中尋找可能受到類似問題影響的相同問題或設定弱點。 使用此機會主動解決這些組成要素。 請參閱您的事件歷程記錄，以偵測工作負載中類似問題的模式。
使用您的結果來改善測試策略。 藉由直接測試相同的失敗，確保您已成功解決根本原因和類似問題。
使用故障注入和混沌工程
錯誤注入測試遵循混擾工程的原則，強調工作負載在元件故障時的反應能力。 在生產階段前和生產環境中執行錯誤插入測試。 將測試套用至基礎結構和應用層。 套用您所學到的資訊 建議來執行失敗模式分析，以確保您只測試您排定優先順序的錯誤，以及您有解決錯誤的風險降低策略。 混亂工程的主要指導方針如下：
要主動。 不要等待失敗發生。 嘗試藉由進行混沌實驗來預測失敗，以便在問題影響生產環境前發現並修正。
擁抱失敗。 接受並學習系統中發生的失敗。 將失敗視為複雜系統的自然部分，並利用它們作為學習和改善系統可靠性的機會。
中斷系統。 刻意將錯誤或壓力插入您的系統中，以測試其復原能力。 模擬真實世界的失敗或中斷，以測試並改善工作負載的復原功能。
儘早識別並解決單一失敗點。 當您測試時，請參閱並更新您的 失敗模式分析，以驗證並解決檔中的錯誤。 套用可靠性方法，例如備援和分割，以提高工作負載的可用性，並將停機時間降到最低。
安裝護欄和順暢的緩和措施。 實作安全措施，例如斷路器模式或節流模式，以提高可用性。 實施優雅降級方式，以便在故障期間維持業務持續性。
最小化爆破半徑。 實作錯誤隔離策略，以協助確保即使發生失敗，其範圍也會受到限制。 系統會繼續運作，對您的客戶的影響最小。
增強免疫力。 使用混亂工程實驗來提高你的工作負載防止故障和從故障中復原的能力。
混亂工程是工作負載團隊文化中不可或缺的一部分和持續的實踐，而不是針對單一故障的短期戰術性應對。 設計混亂實驗時，請遵循此標準方法：
- 從假設開始。 每個實驗都應該有一個明確的目標，例如測試特定流程承受特定元件遺失的能力。
- 測量基準行為。 確保在進行實驗時，針對實驗中涉及的流程和元件，具有一致的可靠性和效能指標，以便與降級狀態進行比較。
- 插入錯誤或錯誤。 實驗應該刻意以可以快速復原的特定元件為目標，並且您應該對錯誤注入可能產生的影響有充份的預期，以協助控制實驗的影響範圍。
- 監控所產生的行為。 收集有關個別流程元件和實驗目標端對端流程行為的遙測，以正確瞭解錯誤的影響。 比較您收集的指標與基準指標，以便全面了解故障注入結果。
- 記錄過程與觀察。 保留實驗的詳細記錄會通知未來的工作負載設計決策，以確保您解決一段時間內所揭示的差距。
- 識別並處理結果。 規劃可新增至工作負載待辦清單作為改進的補救步驟。 請確保設計改進計劃根據與其他部署相同的流程，在非生產環境中進行檢閱和測試。
定期驗證您的程式、架構選擇和程序代碼，以快速偵測技術債務、整合新技術，並適應不斷變化的需求。
當您進行故障注入實驗時，您：
- 確認監視已就緒，並設定警示。
- 驗證指派直接負責的個人 （DRI） 以取得事件的擁有權的程式。
- 請確定您的檔案和調查程式是最新的。
整合下列建議和考慮，以優化您的混亂測試策略：
挑戰系統假設。 透過測試，您嘗試改善工作負載的復原能力和工作負載設計策略。 尋找機會，將錯誤注入您認為基於過去經驗可靠的元件和流程。 在新工作負載中，它們可能不可靠。
驗證變更，例如拓撲、平台和資源。 如果沒有進行徹底的測試，包括故障注入測試，在進行變更之後，您可能無法完整了解您的工作負載。 例如，您可能會不小心引進新的相依性，或以不立即明顯的方式中斷現有的相依性。
使用 SLA 緩衝區。 將混亂測試限制在SLA範圍內，以避免違反 SLA 和因中斷造成的潛在信譽或財務影響。 您的流程和元件復原目標有助於定義測試的範圍。
建立錯誤預算作為混沌工程和故障注入的投資。 您的錯誤預算是達成100%的 SLO 與達成所商定的 SLO 之間的差異。
如果實驗超出範圍，請停止實驗。 未知的結果是混亂實驗的預期結果。 努力在收集大量結果數據，並儘可能影響最少的生產用戶之間取得平衡。
與開發小組密切合作，以確保故意制造的故障的相關性。 使用過去的事件或問題作為指南。 檢查相依性，並在移除這些相依性時評估結果。
識別並記錄透過混亂測試揭示的工作負載中不同元件間尚未發現的相依性。
視需要調整復原計劃，以考慮在混亂測試期間探索到的相依性。
使用實驗和測試的結果作為新實驗和測試的基礎。 當發生非預期的行為時，新的測試可能會直接以這些行為為目標，並讓您有機會為其設計補救策略。
取捨：生產環境中的故障注入測試可能會造成干擾，而且可能會導致停機。 與利益相關者坦誠溝通這種可能性，並確保您已具備終止實驗並回復計劃，以快速扭轉任何可能引入的失敗。 若要防範生產系統中非預期的中斷，請確定您規劃足夠的 備援，且您的利益相關者瞭解成本取捨。
Azure 便利化
Azure Test Plans 是一種易於使用、瀏覽器型測試管理解決方案，可提供計劃手動測試、使用者驗收測試、探勘測試及收集專案關係人意見反應所需的所有功能。
Azure Chaos Studio 是一種受控服務，使用混亂工程來協助您測量、瞭解及改善雲端應用程式和服務復原能力。 Azure Chaos Studio 已於 Ignite 2023 正式運作，且有許多功能可協助您開始使用 Azure 基礎結構對應用程式進行錯誤插入和復原測試。
相關連結
可靠性檢查清單
請參閱一組完整的建議。