隨著雲端原生應用程式和服務變得更複雜，部署變更和新版本可能具有挑戰性。 中斷通常是因為部署或發行錯誤所造成。 但是，當應用程式開始接收實際流量時，也會 在部署之後發生錯誤，特別是在在高度分散式多租用戶雲端環境中執行的複雜工作負載中，以及由多個開發小組維護的錯誤。 這些環境需要更多復原量值，例如重試邏輯和自動調整，這通常很難在開發程式期間進行測試。
這就是為什麼 在與生產環境類似的環境中持續驗證很重要的原因，因此您可以在開發週期中儘早找到並修正任何問題或錯誤。 工作負載小組應該在開發程式初期進行測試（左移），並方便開發人員在接近生產環境的環境中進行測試。
任務關鍵性工作負載具有高可用性需求，目標分別為 3、4 或 59 個（99.9%、99.99%或 99.999%）。 請務必實作 嚴格的自動化測試 ，以達到這些目標。
持續驗證取決於每個工作負載和架構特性。 本文提供將 Azure 負載測試和 Azure Chaos Studio 準備和整合至一般開發週期的指南。
1 – 根據預期的閾值定義測試
持續測試是需要適當準備的複雜程式。 測試的內容和預期結果必須明確。
在 PE：06 - 效能測試的建議 和 RE：08 - 設計可靠性測試策略的建議中，Azure Well-Architected Framework 建議您從 識別主要案例、相依性、預期使用量、可用性、效能和延展性目標開始。
然後，您應該定義一組 可測量的臨界值 ，以量化關鍵案例的預期效能。
小提示
臨界值的範例包括預期的使用者登入數目、指定 API 的要求每秒要求數，以及背景進程的每秒作業。
您應該使用閾值 來開發應用程式的健康模型，以便在測試和生產環境中操作應用程式。
接著，利用這些值定義一個負載 測試 ，產生真實流量，以測試應用程式基線效能，並驗證預期的擴展操作。 在預生產環境中需要持續模擬使用者流量，因為如果沒有使用，很難發現執行時問題。
負載測試可確保對應用程式或基礎結構所做的變更不會造成問題，而且系統仍符合預期的效能和測試準則。 不符合測試準則的失敗測試回合表示您需要調整基準，或發生非預期的錯誤。
雖然自動化測試代表日常使用量， 但您應該定期執行手動負載測試 ，以確認系統如何回應非預期的尖峰。
持續驗證的第二部分是 故障注入 （混亂工程）。 此步驟會測試系統回應錯誤的方式，以驗證系統的復原能力。 此外，所有復原量值，例如重試邏輯、自動調整等，都會如預期般運作。
2 - 使用負載測試和 Chaos Studio 實作驗證
Microsoft Azure 提供這些受控服務來實作負載測試和混亂工程：
- Azure 負載測試 會在應用程式和服務上產生綜合用戶負載。
- Azure Chaos Studio 藉由有系統地將失敗插入應用程式元件和基礎結構，提供執行混亂實驗的能力。
您可以透過 Azure 入口網站部署和設定 Chaos Studio 和負載測試，但在持續驗證的內容中，您更重要的是要有 API 以 程式設計方式和自動化方式部署、設定及執行測試。 一起使用這兩個工具可讓您觀察系統對問題的反應，以及其自我癒合以響應基礎結構或應用程式失敗的能力。
下列影片展示整合至 Azure DevOps 的 Chaos 和負載測試的聯合實作：
如果您要開發任務關鍵性工作負載，請利用 Azure Well-Architected Framework 中提供的詳細指引。
其中一個選項是直接從端到端 (e2e) 管道中執行負載測試，以便啟動特定分支的個別開發環境。
![執行管線畫面，並勾選 [負載測試] 複選框。](images/deployment-testing-pipeline-start.png)
管線會自動執行負載測試，無論是否平行執行混沌實驗 （視選取項目而定）：
備註
在負載測試期間執行混亂實驗可能會導致延遲較高、回應時間較高，並暫時增加錯誤率。 在向外擴展操作或容錯移轉完成之前，與不進行混沌實驗的執行相比，預期會有較高的延遲和回應時間。
視是否啟用混亂測試及選擇實驗而定，基準定義可能會有所不同，因為錯誤承受度在「正常」狀態和「混亂」狀態可能會有所不同。
3 – 調整閾值並建立基準
最後，調整定期執行的 負載測試臨界值 ，以確認應用程式 （仍然） 提供預期的效能，而且不會產生任何錯誤。 為混亂測試設定一個單獨的基線，以允許錯誤率預期的尖峰和性能暫時的下降。 此活動是連續的，而且必須定期重複。 例如，在引進新功能之後，變更服務 SKU 和其他相關變更。
Azure 負載測試服務提供稱為 測試準則 的內建功能，可讓您指定測試需要通過的特定準則。 這項功能可用來實作不同的基準。
![測試準則畫面，其回應時間和錯誤準則標示為 [失敗]。](images/deployment-testing-test-criteria.png)
此功能可透過 Azure 入口網站、負載測試 API，以及作為 Azure 任務關鍵系統一部分開發的包裝腳本取得，提供傳遞 JSON 型基準定義的選項。
強烈建議 將這些測試直接整合到 CI/CD 管線中 ，並在功能開發初期執行。
總而言之，在任何複雜的分散式系統中，失敗是不可避免的，因此解決方案必須經過架構（並經過測試）來處理失敗。 Well-Architected Framework 任務關鍵工作負載指南和參考實作可協助您設計並運行高度可靠的應用程式，以從 Microsoft 的雲端服務獲得最大價值。
後續步驟
檢閱任務關鍵性工作負載的部署和測試設計區域。