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