本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 部署前活动
<a name="post-deployment"></a>

韧性是一个持续的过程，在部署应用程序之后，必须继续评估应用程序的韧性。部署后活动（例如持续的韧性评估）的结果可能需要您重新评估并更新在韧性生命周期早期执行的一些韧性活动。

## 进行韧性评估
<a name="conducting-resilience-assessments"></a>

将应用程序部署到生产环境后，评估韧性不会停止。即使您有明确定义的自动化部署管线，有时也可能直接在生产环境中进行更改。此外，在部署前韧性验证中，可能还有一些因素尚未考虑在内。[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)提供了一个中心位置，可用于评测已部署的架构是否满足您定义的 RPO 和 RTO 需求。您可以使用此服务对应用程序的弹性进行按需评估，自动进行评估，甚至可以将其集成到您的 CI/CD 工具中，如 AWS 博客文章 “使用和[持续评估应用程序弹性](https://aws.amazon.com/blogs/architecture/continually-assessing-application-resilience-with-aws-resilience-hub-and-aws-codepipeline/)” 中所述。 AWS Resilience Hub AWS CodePipeline将这些评估自动化是一种最佳实践，因为它有助于确保您在生产中持续评估自己的韧性状况。

## DR 测试
<a name="dr-testing"></a>

在[第二阶段：设计与实施](stage-2.md)中，您制定了灾难恢复（DR）策略作为系统的一部分。在第四阶段，您应该测试 DR 程序，以确保您的团队为事件做好充分准备，并且您的程序按预期运行。您应定期测试所有 DR 程序（包括失效转移和失效自动恢复），并查看每项练习的结果，以确定是否以及如何更新系统的程序以获得最佳结果。在最初制定 DR 测试时，请提前安排好测试，并确保整个团队都了解预期结果、如何衡量结果，以及将使用哪种反馈机制根据结果更新程序。在您熟练运行计划的 DR 测试后，可以考虑运行无预告 DR 测试。真实的灾难不会按计划发生，因此您需要做好随时执行计划的准备。但是，无预告并不意味着计划外。主要利益相关者仍需要对事件进行规划，以确保进行适当的监控，并确保客户和关键应用程序不会受到不良影响。

## 偏差检测
<a name="drift-detection"></a>

即使采用了自动化和明确定义的程序，生产应用程序中的配置也可能发生意外的变更。要检测应用程序配置的变更，您应该有检测*偏差*的机制，后者是指与基准配置的偏差。要了解如何检测 AWS CloudFormation 堆栈中的偏差，请参阅文档中的[检测堆栈和资源的非托管配置更改](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)。 AWS CloudFormation 要检测应用程序 AWS 环境中的偏差，请参阅 AWS Control Tower 文档[AWS Control Tower中的检测和解决偏差](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html)。

## 综合测试
<a name="synthetic-testing"></a>

[综合测试](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)是创建可配置软件的过程，该软件按计划在生产环境 APIs 中运行，以模拟最终用户体验的方式测试您的应用程序。这些测试有时称为*金丝雀*，指的是该术语最初在煤炭开采中的使用。综合测试通常可以在应用程序出现中断时提供早期警告，即使损害是部分或间歇性的，这种情况通常称为[灰色故障](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)。

## 混沌工程
<a name="chaos-engineering"></a>

混沌工程是一个系统化的过程，它通过以风险可控的方式，故意让应用程序经历各种中断事件，密切监控其响应，并实施必要的改进。其目的是验证或挑战有关应用程序处理此类中断能力的假设。混沌工程并非任由这些事件随机发生，而是使工程师能够在受控的环境中编排实验，通常是在流量较低的时期，并提供随时可用的工程支持来有效缓解。

混沌工程首先要了解所考虑应用程序的正常运行条件（称为*稳态*）。在此基础上，您可以提出一个假设，详细说明在存在中断的情况下应用程序的成功行为。您可运行实验，其中涉及故意注入中断，包括但不限于网络延迟、服务器故障、硬盘驱动器错误以及外部依赖关系损害。然后，您可以分析实验结果，并根据经验教训增强应用程序的韧性。该实验是改善应用程序各个方面（包括其性能）的宝贵工具，可发现原本可能隐藏的潜在问题。此外，混沌工程有助于揭示可观测性和告警工具中的缺陷，并帮助您对其进行完善。它还有助于缩短恢复时间和提升运营技能。混沌工程加速了最佳实践的采用，培养了持续改进的心态。最终，它使团队能够通过定期练习和重复来构建和磨练其运营技能。

AWS 建议您在非生产环境中开始混沌工程工作。您可以使用 [AWS Fault Injection Service （AWS FIS）](https://aws.amazon.com/fis/)对通用故障以及 AWS特有的故障进行混沌工程实验。这项完全托管的服务包括停止状态告警和完全权限控制，因此您可以安全放心地轻松采用混沌工程。