本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 持續改善 彈性是[持續的過程](https://medium.com/the-cloud-architect/towards-continuous-resilience-3c7fbc5d232b)。在您的系統生命週期中，其操作的環境將會變更。為了確保您的系統保持彈性，您應該將架構整合到您的定期營運和架構審查中。您可能會發現第一次未識別的新故障模式，或者可能有一些新的或先前未考慮的緩解措施，您可以採取這些措施。彈性分析應該是反覆程序，而不是一次性練習。 您應該使用[混沌工程](https://aws.amazon.com/solutions/resilience/chaos-engineering/)或[遊戲日](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html)等程序以經驗方式測試緩解策略，以驗證它們是否如預期般運作。如果您沒有嚴格的測試機制，您將無法確信緩解措施將在需要時如預期般運作。在彈性分析期間，您可以判斷特定緩解措施已處理失敗模式，但也請務必測試這些假設。您應該測試現有的緩解措施和使用彈性分析架構建立的新緩解措施。 您也應該評估透過團隊回顧分析的表現。每個人是否都知道他們在分析期間正在處理什麼？ 您透過彈性分析找到的失敗模式數量是否符合團隊的期望？ 您能否識別您發現的所有故障模式的緩解措施？ 團隊認為程序有用嗎？ 您認為這是否會改善工作負載的彈性？ 當發生會影響工作負載可用性的真實故障事件時，請記錄特定故障模式、屬於故障一部分的元件，以及使用的緩解模式。讓此中繼資料可在事件後分析工具中搜尋，讓您可以判斷未來要專注的失敗模式和元件。在整個過程中，您可以吸引您的 AWS 客戶團隊和解決方案架構師。