本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 韧性生命周期框架：持续提升韧性的方法
*Amazon Web Services*（[贡献者](contributors.md)）
*2023 年 10 月*（[文档历史记录](doc-history.md)）
如今的现代组织正面临着越来越多与韧性相关的挑战，尤其是在客户期望转向*始终在线、始终可用*的思维模式之际。远程团队与复杂的分布式应用程序相结合，再加上对频繁发布的需求不断增加。因此，组织及其应用程序需要比以往任何时候都更具韧性。
AWS 将弹性定义为应用程序抵御中断或从中恢复的能力，包括与基础架构、依赖服务、配置错误和临时网络问题相关的中断。（参见 W [ell-Architecte AWS d Framework 可靠性支柱文档中的弹性和可靠性组成部分](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/resiliency-and-the-components-of-reliability.html)。） 但是，为了达到所需的韧性水平，通常需要权衡取舍。需要评估运营复杂性、工程复杂性和成本并进行相应的调整。
基于与客户和内部团队多年的合作，开发 AWS 了一个可捕捉弹性学习和最佳实践的弹性生命周期框架。此框架概述了五个关键阶段，如下图所示。在每个阶段，您都可以使用策略、服务和机制来提升韧性状况。
本指南后文部分将介绍以下阶段：
+ [第一阶段：设定目标](stage-1.md)
+ [第二阶段：设计与实施](stage-2.md)
+ [第三阶段：评估与测试](stage-3.md)
+ [第四阶段：运营](stage-4.md)
+ [第五阶段：响应与学习](stage-5.md)
## 术语和定义
每个阶段的韧性概念应用于不同的层面，从单个组件到整个系统。实施这些概念需要明确定义几个术语：
+ *组件*是执行功能的元素，由软件和技术资源构成。组件的示例包括代码配置、网络等基础设施，甚至服务器、数据存储以及多重身份验证（MFA）设备等外部依赖关系。
+ *应用程序*是可提供商业价值的组件集合，如面向客户的网络店面或改进机器学习模型的后端流程。应用程序可能由单个 AWS 账户中的一部分组件组成，也可能是跨多个 AWS 账户 和区域的多个组件的集合。
+ *系统*是管理给定业务功能所需的应用程序、人员和流程的集合。它包括运行功能所需的应用程序；持续集成和持续交付（CI/CD）、可观测性、配置管理、事件响应和灾难恢复等运营流程；以及管理此类任务的运营人员。
+ *中断*是指阻止应用程序正常提供其业务功能的事件。
+ *损害*是指中断未得到缓解时对应用程序产生的影响。如果应用程序遭受一系列中断，则可能会造成损害。
## 持续韧性
韧性生命周期是一个持续的过程。即使在同一个组织中，应用程序团队在每个阶段的执行完整程度也可能会有所不同，具体视应用程序的要求而定。但是，每个阶段越完整，应用程序的韧性水平就越高。
您应该将弹性生命周期视为组织可以实施的标准流程。 AWS 故意将弹性生命周期建模为类似于软件开发生命周期 (SDLC)，目的是在开发和运行应用程序的同时，将规划、测试和学习纳入整个操作流程。 与许多敏捷开发流程一样，弹性生命周期可以在开发过程的每次迭代中重复。 我们建议您随着时间的推移，逐步深化生命周期每个阶段的实践。