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