本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 持续改进 韧性是一个[持续的过程](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 客户团队和解决方案架构师保持沟通。