第二阶段：设计与实施

本节讨论如何将您的韧性目标变为现实。您已经规划了哪些对您的业务最重要，现在是时候构建它了。如何在不减缓创新的前提下增强韧性？

可以将 AWS 托管服务视为弹性的捷径。与其花费宝贵的工程时间来维护基础架构，不如使用能为您处理冗余的服务。例如，考虑亚马逊简单存储服务 (Amazon S3) S ervice。它会自动将您的数据的多个副本存储在中 AWS 区域 以保持持久性。它不需要额外的密码或深夜的寻呼机任务。

你的核心应用程序组件呢？ 明智的选择可以成倍增加团队的影响力。考虑一下作为服务支柱的数据库。与其构建自己的复制系统，不如考虑使用自动处理故障转移的 Amazon Aurora。这些功能的成本可能会更高，但它们会将团队的注意力从维护基础架构转移到解决业务问题上。这笔费用可以通过更快的功能交付和避免中断期间的收入损失来抵消。

有时，初创公司需要构建自定义解决方案。这就是创新型初创公司的本质。当你这样做时，要保持简单但要聪明。使用 Elastic Load Balancing 和 Amazon EC2 Auto Scaling 群组将您的应用程序分布到多个可用区。设置 Auto Scaling 组的最小容量以处理您的基准流量，即使一个可用区出现故障。这无需复杂的架构模式即可抵御局部故障。随着您的初创公司的发展和客户对更高弹性的需求，您可以发展到更复杂的方法。

我们建议您将生产和开发环境分开 AWS 账户。当你快速移动时，混合它们很诱人，但是这个边界就是你的安全网。它可以防止善意的实验中断你的生产服务。可以把它当作你的 “快速行动，打破现状” 的发展文化的保险——在开发中打破局面，保持生产稳定。

如果您的应用程序依赖于第三方服务，请为其故障做好准备。当您的支付处理器出现问题时，您的系统能否优雅地处理问题？ 构建简单的断路器和备用选项。也许可以将这些交易排队而不是显示错误消息。即使不是完美无瑕，您的客户也会对您保持正常运行表示赞赏。

在构建时记录下来，但要保持实用性。专注于记录关键决策背后的原因，并创建简单的恢复手册。重要的是要在事件发生时做好准备。

你不是在为完美的韧性而建造；而是在为适当的韧性而建造。每花一小时过度设计弹性，就等于没有花在客户要求的功能上的一个小时。使用 AWS 托管服务作为基础，在最重要的位置添加有针对性的弹性，并创建清晰的路径来随着业务的增长扩大弹性。

下一章讨论如何在不消耗工程资源的情况下验证这些设计选择。对于初创公司来说，测试应该是一种合理的提升，也是对应用程序弹性的明智投资。