設計可靠性測試原則的建議
適用於此 Power Platform Well-Architected 可靠性檢查表建議：
| 回復：06 | 透過在測試和實際執行環境中套用混沌工程原則來測試韌性和可用性案例。 透過執行使用中故障和類比負載測試以使用測試來確保正常降級執行原則有效。 |
|---|
本指南介紹設計可靠性測試策略以驗證和最佳化工作負載可靠性的建議。 可靠性測試重點在於工作負載的彈性和可用性，特別是您在設計解決方案時確定的關鍵流程。 本指南提供一般測試指南以及特定於故障注入和混沌工程的指南。
定義
| 詞彙 | 定義 |
|---|---|
| 可用工時 | 應用程式工作負載在沒有明顯停機的情況下以健康狀態執行的時間量。 |
| 混沌工程 | 讓應用程式和服務承受現實世界壓力和故障的做法。 混沌工程的目標是建構和驗證對不可靠條件和缺失依賴項的復原能力。 |
| 故障注入 | 向系統引入錯誤以測試系統彈性的行為。 |
| 可恢復性 | 彈性的同義詞。 |
| 復原 | 應用程式工作負載承受故障模式並從中恢復的能力。 |
關鍵設計原則
測試對於確保您的工作負載滿足其可靠性目標並能夠妥善處理故障至關重要。 故障注入是一種故意將故障或壓力引入系統以模擬真實場景的測試。 透過使用故障注入和混沌工程技術，您可以在問題影響生產環境之前主動發現並修復問題。 本部分提供有關工作負載的測試、故障注入和混沌工程的一般指導。
一般測試指南
定期執行測試以驗證現有閾值、目標和假設。 當工作負載發生重大變化時，請定期進行測試。 在測試和暫存環境中執行大部分測試。 針對生產系統執行測試子集也是有益的。
自動化測試有助於確保一致的測試覆蓋率和可重複性。 自動執行常見測試任務並將其整合到您的組建程序中。 手動測試軟體既繁瑣又容易出錯，但您可以進行手動探索性測試。 對於需要開發自動化測試的情況，請使用手動測試來確定要開發的測試的範圍。
採用左移測試方法在開發週期的早期執行彈性和可用性測試。
採用簡單的文件格式，讓每個人都能輕鬆理解每次常規測試的過程和結果。
與適當的團隊 (例如營運團隊、技術領導層、業務利害關係人和災難復原利害關係人) 共享記錄的結果。 結果應為可靠性目標的細化提供資訊，例如服務等級目標 (SLO)、服務等級協定 (SLA)、復原時間目標 (RTO) 和復原點目標 (RPO)。
為您的備份建立定期測試節奏。 將資料還原到隔離的系統，以協助確保備份有效且恢復正常運作。
記錄並與災難復原利害關係人分享復原時間指標，以確保對復原的期望是適當的。
使用業界標準的部署測試流程來幫助確保您擁有自動化、可預測且有效率的部署流程。
測試您的工作負載承受瞬時故障的能力。 如需相關資訊，請參閱處理瞬態故障的建議。
透過使用故障注入來測試您的工作負載如何處理依賴服務或其他依賴項中的故障。
測試您的災難復原計劃以回應災難性故障和其他重大事件。
透過使用故障注入來測試工作負載正常降級的能力並最大限度地減少元件故障的影響範圍。
利用計劃內和計劃外的停電
當您的工作負載因計劃維護或計劃外停機而離線時，您有一個獨特的機會來執行測試並加深對工作負載的了解。 以下部分提供了針對每種情況的建議。
已計劃的維護
當您規劃了更新或修補程式的維護時段時，您可以測試維護工作中不涉及的元件和流程。 執行測試時不會出現工作負載意外降低或完全離線的潛在風險。 如果您在維護時段內有足夠的時間，您也可以在維護工作完成後測試維護中涉及的元件和流程。
計畫外停電
將每次中斷事件做為一個機會，詳細了解您的工作負載並透過執行以下步驟 (按優先順序排序) 來提高其彈性：
為您的使用者恢復線上工作負載。 您可能需要針對問題執行解決方法、解決問題或啟動復原程序。
確定中斷的根本原因並解決它。 如果您可以在調查過程中解決根本原因，請記錄根本原因以及您為解決問題而採取的措施。 如果問題需要稍後進行另一個維護時段，請確保您的緩解措施可以通過全面測試來處理預期的負載。 確保您已設定足夠的監控來覆蓋您的緩解措施。
如果適用，請在工作負載中的所有元件中尋找相同的問題或可能受類似問題影響的配置弱點。 利用這個機會主動解決這些問題。 查閱您的事件歷史記錄以偵測工作負載中類似問題的模式。
使用您的發現來改進您的測試策略。 透過直接測試相同的故障，確保您已成功解決根本原因和類似問題。
故障注入與混沌工程指導
故障注入測試遵循混沌工程的原則，強調工作負載對元件故障做出反應的能力。 在預生產和生產環境中執行故障注入測試。 應用您從執行故障模式分析中學到的資訊，以確保您僅測試您確定優先順序的故障，並且您擁有解決故障的緩解策略。
混沌工程的關鍵準則是：
主動。 不要等到失敗發生才採取行動。 嘗試透過進行混沌實驗來預測故障，以便在問題影響生產環境之前發現並修復問題。
擁抱失敗。 接受系統中發生的故障並從中學習。 將故障視為複雜系統的自然組成部分，並將其視為學習和提高系統可靠性的機會。
打破系統。 故意向您的系統注入故障或壓力以測試其彈性。 模擬現實世界的故障或中斷，以測試和提高工作負載的復原能力。
增強免疫力。 使用混沌工程實驗來提高工作負載預防故障和從故障中恢復的能力。
混沌工程是工作負載團隊文化的一個組成部分，是一種持續的實踐，而不是針對單次中斷的短期戰術努力。 設計混沌實驗時請遵循以下標準方法：
從一個假設開始。 每個實驗都應該有一個明確的目標，例如測試流程承受特定元件損失的能力。
測量基線行為。 確保實驗中涉及的流程和元件具有一致的可靠性和效能指標，以便與執行實驗時的降級狀態進行比較。
注入一個或多個故障。 實驗應該有意識地針對可以快速恢復的特定元件，並且您應該對故障注入將導致的效果有一個明智的預期，以幫助控制實驗的爆炸半徑。
監視由此產生的行為。 收集有關實驗目標的各個流分量和端對端流行為的遙測資料，以正確了解故障的影響。 將您收集的指標與基準指標進行比較，以全面了解故障注入結果。
記錄過程和觀察結果。 保留實驗的詳細記錄將為未來有關工作負載設計的決策提供資訊，確保您解決隨著時間的推移而發現的差距。
識別結果並採取行動。 規劃可做為改進添加到工作負載待辦事項的補救步驟。 確保按照與其他部署相同的流程在非生產環境中審查和測試設計改進計劃。
定期驗證您的流程、架構選擇和程式碼，以快速偵測技術債、整合新技術並適應不斷變化的需求。
執行故障注入實驗時，您可以：
確認監控已到位並已設定警報。
驗證您指定直接負責人 (DRI) 負責事件的流程。
確保您的文件和調查流程是最新的。
整合以下建議和注意事項來最佳化您的混沌測試策略：
挑戰系統假設。 透過測試，您可以嘗試提高工作負載的彈性和工作負載設計策略。 尋找機會將故障注入到您根據過去的經驗認為可靠的元件和流程中。 它們在您的新工作負載中可能不可靠。
驗證更改。 如果沒有徹底的測試 (包括故障注入測試)，您可能無法完整了解變更後的工作負載。 例如，您可能會引入並未立即顯現的新依賴項。
使用 SLA 緩衝區。 限制混沌測試以保持在 SLA 範圍內，並避免中斷造成的潛在不利影響。 您的流程和元件復原目標有助於定義測試範圍。
建立錯誤預算做為對混亂和故障注入的投資。 您的錯誤預算是實現 100% 的 SLO 與實現商定的 SLO 之間的差異。
如果超出範圍，請停止實驗。 未知結果是混沌實驗的預期結果。 努力在收集大量結果資料和影響盡可能少的生產使用者之間取得平衡。
與開發團隊密切合作，確保注入故障的相關性。 使用過去的事件或問題做為指引。 檢查依賴關係並在刪除這些依賴關係後評估結果。
識別並記錄工作負載中不同元件之間先前未發現的依賴關係，這些依賴關係是透過混沌測試揭示的。
根據需要調整復原計劃，以考慮混沌測試期間發現的依賴關係。
使用實驗和測試的結果做為新實驗和測試的基礎。 當出現意外行為時，新的測試可能會直接針對這些行為，並讓您有機會為其設計補救策略。
權衡：生產中的故障注入測試可能會造成中斷，並可能導致停機。 就這種可能性向利害關係人保持透明，並確保您有適當的保障措施來終止實驗和回滾計劃，以快速扭轉您引入的故障。
Power Platform 簡易化
您可以使用 static results in Power Automate 返回固定結果來測試您的工作負載。
Power Apps 測試引擎（預覽版） 是一個 Power Platform CLI 元件，可用於在其中 Power Apps測試獨立畫布應用。
Azure Test Plans 是一種易於使用、基於瀏覽器的測試管理解決方案，它提供計劃內手動測試、使用者驗收測試、探索性測試和從利益幹系人收集反饋所需的所有功能。
如果您的工作負載包括 Azure 資源，可以使用 Azure Chaos Studio，這是一項託管服務，它使用混沌工程來幫助您衡量、了解和提高雲端應用程式和服務的彈性。
如果您的工作負載包括 Microsoft Copilot Studio copilot，則可以使用 Power CAT Copilot Studio Kit 配置 copilot 和測試。 通過針對 Copilot Studio API（）Direct Line 運行單個測試，將根據預期結果評估 Copilot 回應。
可靠性檢查清單
請參閱完整的建議集。