本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 第二阶段：设计与实施
在上一阶段，您设定了韧性目标。现在，在*设计与实施*阶段，您将尝试按照在上一阶段设定的目标来预测故障模式并确定设计选择。您还需要定义变更管理策略，并开发软件代码和基础设施配置。以下各节重点介绍在权衡取舍成本、复杂性和运营开销等因素时应考虑的 AWS 最佳实践。
## AWS Well-Architected 框架
在根据所需的韧性目标架构应用程序时，您需要评估多个因素，并对最优架构进行权衡取舍。要构建高韧性的应用程序，必须考虑设计、构建和部署、安全以及运营等方面。[AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 提供一组最佳实践、设计原则和架构模式，可帮助您在 AWS 上设计具有韧性的应用程序。AWS Well-Architected Framework 的六大支柱提供了设计和运行具有韧性、安全、高效、经济实惠且可持续系统的最佳实践。该框架提供了一种方法，可以根据最佳实践持续衡量架构，从而确定需要改进的方面。
以下是 AWS Well-Architected Framework 如何帮助您设计和实施满足韧性目标的应用程序的示例：
+ **可靠性支柱**：[可靠性支柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)强调构建即使在故障或中断期间也能正确持续运行的应用程序的重要性。例如，AWS Well-Architected Framework 建议您使用微服务架构来缩小和简化应用程序，这样就可以区分应用程序中不同组件的可用性需求。您还可以通过使用节流、指数回退重试、快速失效机制（卸除负载）、幂等性、持续工作、断路器和静态稳定性，找出构建应用程序最佳实践的详细说明。
+ **全面审查**：AWS Well-Architected Framework 鼓励根据最佳实践和设计原则对您的架构进行全面审查。它提供了一种持续衡量架构并识别改进领域的方法。
+ **风险管理**：AWS Well-Architected Framework 可帮助您识别和管理可能影响应用程序可靠性的风险。通过主动解决潜在的故障场景，您可以降低其发生的可能性或由此造成的损害。
+ **持续改进**：韧性是一个持续的过程，AWS Well-Architected Framework 强调持续改进。通过根据 AWS Well-Architected Framework 的指导定期审查和完善您的架构和流程，可以确保您的系统在面对不断变化的挑战和要求时保持韧性。
## 了解依赖关系
了解系统的依赖关系是实现韧性的关键。依赖关系包括应用程序内各组件之间的连接，以及与应用程序外部组件（例如第三方 API 和企业拥有的共享服务）的连接。了解这些连接可帮助您隔离和管理中断，因为一个组件受损可能会影响其他组件。这些知识可以帮助工程师评测损害的影响并进行相应的规划，确保资源得到有效利用。了解依赖关系可以帮助您制定替代策略和协调恢复过程。它还可以帮助您确定哪些情况可以将硬依赖关系替换为软依赖关系，以便在依赖关系受损时，您的应用程序可以继续履行其业务功能。依赖关系还会影响有关负载均衡和应用程序扩展的决策。对应用程序进行更改时，了解依赖关系至关重要，因为这可以帮助您确定潜在的风险和影响。这些知识可以帮助您创建稳定、具有韧性的应用程序，协助进行故障管理、影响评测、损害恢复、负载均衡、扩展和变更管理。您可以手动跟踪依赖关系，也可以使用工具和服务（例如 [AWS X-Ray](https://aws.amazon.com/xray/)）了解分布式应用程序的依赖关系。
## 灾难恢复策略
灾难恢复（DR）策略在构建和运行韧性应用程序中起着关键作用，其主要作用是确保业务连续性。该策略保证即使在灾难性事件期间，关键业务运营也能以尽可能少的损害持续下去，从而最大限度地减少停机时间和潜在的收入损失。DR 策略对于数据保护至关重要，因为其通常包含定期的数据备份和跨多个位置的数据复制，这有助于保护宝贵的业务信息，并有助于防止灾难期间发生完全丢失。此外，许多行业都受到策略的监管，要求企业制定 DR 策略，以保护敏感数据并确保灾难期间服务保持可用。通过确保最大限度地减少服务损害，DR 策略还可以提升客户信任和满意度。实施得当且经常练习的 DR 策略可以缩短灾难发生后的恢复时间，并有助于确保应用程序快速恢复在线状态。此外，灾难可能造成巨额成本，不仅包括由于停机时间造成的收入损失，还包括恢复应用程序和数据的费用。精心设计的 DR 策略有助于防范这些经济损失。
您选择的策略取决于应用程序的特定需求、RTO 和 RPO 以及您的预算。[AWS 弹性灾难恢复](https://aws.amazon.com/disaster-recovery/)是一项专门构建的韧性服务，可用于帮助为本地和基于云的应用程序实施 DR 策略。
有关更多信息，请参阅 AWS 网站上的 [Disaster Recovery of Workloads on AWS](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 和 [AWS Multi-Region Fundamentals](https://docs.aws.amazon.com/whitepapers/latest/aws-multi-region-fundamentals/aws-multi-region-fundamentals.html)。
## 定义 CI/CD 策略
应用程序受损的常见原因之一是代码或其他变更导致应用程序从之前的已知工作状态发生变化。如果您没有谨慎处理变更管理，则可能会导致频繁的损害。变更频率越高，产生影响的可能性越大。但是，降低变更频率会导致变更集更大，而由于变更集的复杂性较高，因此更有可能导致损害。持续集成和持续交付（CI/CD）实践旨在保持变更小而频繁（从而提高工作效率），同时通过自动化对每项变更进行高层级的检查。一些基本策略包括：
+ **完全自动化**：CI/CD 的基本概念是尽可能实现构建和部署流程的自动化。这包括构建、测试、部署甚至监控。自动化管线有助于减少人为错误的可能性，确保一致性，并使流程更加可靠和高效。
+ **测试驱动开发（TDD）**：在编写应用程序代码之前编写测试。这种做法可确保所有代码都有相关的测试，从而提高代码的可靠性和自动检查的质量。这些测试在 CI 管线中运行，以验证变更。
+ **频繁提交和集成**：鼓励开发人员频繁提交代码并经常进行集成。小而频繁的变更更易于测试和调试，从而降低出现重大问题的风险。自动化降低了每次提交和部署的成本，从而使频繁的集成变为可能。
+ **不可变基础设施**：将您的服务器和其他基础设施组件视为静态、不可变的实体。尽可能更换基础设施而不是对其进行修改，使用经过测试并通过管线部署的[代码](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)来构建新的基础设施。
+ **回滚机制**：如果出现问题，始终用一种简单、可靠且经常测试的方法来回滚更改。能够快速恢复到之前已知的良好状态对于部署安全至关重要。此功能可以是恢复到之前状态的简单按钮，也可以完全自动并通过告警启动。
+ **版本控制**：将所有应用程序代码、配置甚至基础设施作为代码保存在版本控制的存储库中。这种做法有助于确保您可以轻松跟踪变更并在需要时进行恢复。
+ **金丝雀部署和蓝绿部署**：首先将应用程序的新版本部署到基础设施的子集，或者维护两个环境（蓝/绿），使您能够在生产环境中验证变更的行为，并在必要时快速回滚。
CI/CD 不仅关乎工具，也关乎文化。创造一种重视自动化、测试和从故障中吸取教训的文化与实施正确的工具和流程同样重要。如果回滚能够快速完成且影响最小，则不应将其视为故障，而应视为一次学习经验。
## 开展 ORR
运营准备情况审查（ORR）有助于确定运营和程序方面的差距。在 Amazon，我们创建了 ORR，将数十年来运营大规模服务的经验提炼成精心策划的问题，并提供最佳实践指导。ORR 总结了以往的经验教训，并要求新团队确保在其应用中已考虑这些经验教训。ORR 可以提供故障模式或故障原因的列表，用于执行下文韧性模拟部分所述的韧性模拟活动。有关更多信息，请参阅 AWS Well-Architected Framework 网站上的 [Operational Readiness Reviews（ORR）](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)。
## 了解 AWS 故障隔离边界
AWS 提供多个故障隔离边界，以帮助您实现韧性目标。您可以使用这些边界，利用其提供的可预测的影响控制范围。您应该熟悉 AWS 服务如何利用这些边界进行设计，以便能够根据应用程序有意选择合适的依赖关系。要了解如何在应用程序中使用边界，请参阅 AWS 网站上的 [AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)****。
## 选择响应
系统可以通过多种方式对告警作出响应。有些告警可能需要运营团队作出响应，而另一些告警可能会触发应用程序内的自我修复机制。为了控制自动化成本或管理工程限制，您可决定将一些可以自动化的响应保留为手动操作。对告警响应类型的选择很可能基于实施响应的成本、告警的预期频率、告警的准确性以及根本不响应告警所造成的潜在业务损失等多个因素。
例如，当服务器进程崩溃时，操作系统可能会重新启动该进程，或者可能预调配新服务器并终止旧服务器，亦或可能会指示运营人员远程连接到该服务器并重新启动它。这些响应的结果相同，即重新启动应用程序服务器进程，但实施和维护成本各不相同。
**注意**
您可以选择多个响应，以采取深入的韧性方法。例如，在前面的场景中，应用程序团队可能会选择实施所有三种响应，每个响应之间设置时间延迟。如果故障服务器的进程指示器在 30 秒后仍处于告警状态，则团队可以假设操作系统未能重新启动应用程序服务器。因此，他们可能会创建一个自动扩缩组，用于创建新的虚拟服务器并恢复应用程序服务器进程。如果指示器在 300 秒后仍处于告警状态，则可能会向运营人员发送提醒，要求其连接到原始服务器并尝试恢复进程。
应用程序团队和业务部门选择的响应方式应反映出企业通过前期投入工程时间来抵消运营开销的风险偏好。您应该通过仔细考虑每个响应选项的限制和预期维护来选择一种响应：静态稳定性等架构模式、断路器等软件模式或操作程序。可能已存在一些标准响应可指导应用程序团队，因此您可以使用集中式架构功能管理的库和模式作为此考量的依据。
## 韧性模拟
韧性模拟记录了应用程序将如何响应不同的预期中断。 通过预测中断情况，您的团队可以实施可观测性、自动化控制和恢复流程，以缓解或防止出现中断时的损害。AWS 已使用[韧性分析框架](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)创建了开发韧性模型的指导。 该框架可以帮助您预测中断及其对应用程序的影响。 通过预测中断，您可以确定构建具有韧性且可靠的应用程序所需的缓解措施。我们建议您在应用程序生命周期的每次迭代中使用韧性分析框架更新韧性模型。 在每次迭代中使用此框架可以预测设计阶段的中断，并在生产部署前和部署后测试应用程序，从而有助于减少事故。使用此框架开发韧性模型可帮助您确保实现韧性目标。
## 安全失效
如果您无法避免中断，请安全失效。考虑使用默认的安全失效运行模式创建应用程序，在这种模式下，不会造成重大业务损失。数据库安全失效状态的一个例子是默认为只读操作，即不允许用户创建或更改任何数据。根据数据的敏感性，您甚至可能希望应用程序默认为关闭状态，甚至不执行只读查询。考虑一下应用程序应采用哪种安全失效状态，并在极端条件下默认采用这种运行模式。