本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 階段 3：評估和測試 您已建置彈性基礎，但如何知道它實際運作？ 當您在競賽中證明產品市場適合度時，測試彈性可能聽起來很豪華。不過，有一種聰明的方法可以這樣做，而不會破壞您的功能開發。本章說明符合啟動速度的精簡實用測試。 從 開始[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)，並將其視為初始架構評估工具。它提供架構彈性基礎的實用基準檢閱。它透過檢查常見的組態模式和潛在的單點故障，協助您評估基本基礎設施設定是否符合您的復原目標。它可以標記明顯的差距，例如缺少多個可用區域組態或不完整的備份政策。Resilience Hub 補充，但不會取代深思熟慮的架構檢閱和關鍵路徑的目標測試。 若要驗證您記錄的復原目標，請在開發環境中的 [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 中排程每月還原測試。即使需要工程時間，它可能比發現備份在實際事件期間無法運作更便宜。讓它成為您一般開發週期的一部分，例如執行單元測試或程式碼檢閱。目標並非完美；您可以在需要時復原。 隨著您的新創公司成長，客戶開始更加依賴您，逐漸升級您的測試遊戲。當您部署新功能時，請在管道中包含基本彈性檢查。使用 嘗試簡單的混沌實驗[AWS Fault Injection Service](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)。從生產前環境中開始，從小開始。在考慮任何生產實驗之前，測試您的應用程式如何處理開發中的延遲 API 回應。隨著您的可信度增加， 會逐漸擴展這些測試，但一律會先在生產前進行驗證。對於新創公司而言，破壞生產環境中的實物具有足夠的風險，而不刻意這樣做。 金鑰是平衡。用於測試的每小時都是一個小時，而不是用於建置新功能。但是，一些策略測試可以防止失去客戶信任的中斷類型。使用 提供的自動化工具 AWS 來執行繁重工作，並專注於對您的客戶最重要的測試。這可協助您建立對應用程式彈性的信心，而不會拖慢創新速度。 下一章將探討如何在啟動擴展時發展此基礎。