谷歌云最近的一次中断表明，失败是不可避免的，影响出奇的广泛。企业必须有自己的复原力计划——并且必须定期测试这些计划。

　　最近在伦敦发生的谷歌云事件是那种应该迫使企业重新思考云弹性的真正含义的事件。谷歌表示，中断是由影响其欧洲西部2地区总部位于伦敦的数据中心的“电力事件”造成的。这个问题在当天早些时候就出现了，并影响了许多组织依赖的云服务，这些服务要么直接通过自己的部署，要么间接通过在谷歌云上运行的第三方平台。

　　使这一事件变得重要的不仅仅是云区存在问题。云基础设施和所有基础设施一样，可能而且会失败。真正的问题是依赖链的范围。银行、送货服务、电动自行车供应商、预算应用程序、通过国家卫生服务应用程序的一些预约服务以及法院视频链接系统都陷入了中断。这些服务可能看起来不相关，但实际上，它们可以共享相同的底层云提供商、区域基础设施、托管服务、网络、身份系统、API和运营依赖项。

　　谷歌后来表示，大多数受影响的工作负载的服务已经恢复，只有少数客户仍然受到影响。然而，损害已经造成了。这一事件表明，现代企业在多大程度上依赖于云平台，这些平台具有很高的能力，但不能免受失败。这也表明，企业通过迁移到超大规模扩展器，弹性不是自动获得的。弹性架构必须经过设计、资助、测试和拥有。

　　不要假设有复原力

　　许多企业仍然将公共云弹性视为提供商问题。他们假设，由于工作负载在主要云平台上运行，它具有固有的弹性。这是一个危险的假设。公共云提供商确实提供了令人印象深刻的弹性能力。它们提供多个区域、可用性区域、托管数据库、复制工具、负载平衡、对象存储耐用性、备份服务、监控和自动恢复选项。但这些是基石。它们不是完整的复原力策略。

　　提供商负责云平台的可靠性。企业对其应用程序如何使用该平台负责。这种区别经常被误解。如果应用程序部署在一个区域，依赖于一个托管数据库，使用一个身份路径，并且没有经过测试的故障转移过程，云提供商无法神奇地使该应用程序具有弹性。提供商可能会恢复底层基础设施，但企业仍然拥有应用程序架构和运营模式。

　　这就是许多云程序不足的地方。企业将应用程序迁移到公共云，并假定弹性对话已经完成。实际上，他们可能只将单点故障从自己的数据中心转移到其他人的区域基础设施。平台更好，但设计可能仍然很脆弱。

　　不断增长的依赖链

　　云弹性变得更加困难，因为企业系统现在相互深度互联。典型的现代应用程序是托管服务、API、身份平台、数据存储、消息队列、可观察性工具、部署管道、安全控制和第三方集成的集合。

　　这造成了隐藏的风险。企业可能认为它已经构建了一个弹性应用程序，因为计算跨多个区域运行。但数据库可能是区域性的。身份提供商可能不可用。DNS可能需要人工干预。第三方支付API可能会失败。事件发生期间，日志记录和监控可能会变暗。备份可能存在，但可能几个月内没有恢复。故障转移过程可能取决于不可用的人。

　　这是新的云弹性问题。故障很少只出现一个服务器、一个磁盘或一个网络设备。失败通常是依赖链。企业不仅需要了解应用程序运行的位置，还需要了解它们所依赖的操作。真正的弹性计划从实际层面的依赖性映射开始。哪些服务是区域、区域还是全球？哪些依赖于提供商控制平面？哪些第三方服务共享相同的云提供商或地区？哪些工作负载可以在降级模式下继续？哪些完全停止？

　　没有那张地图，企业就会猜测。

　　多云不是捷径

　　当公共云中断发生时，反射性反应通常是“我们需要多云”。有时候那是真的。通常，这是一种昂贵的分心。

　　多云可以减少对单个提供商的依赖，但它也会带来复杂性，从而使弹性变差。在两个云上运行相同的工作负载需要重复架构、数据复制、一致的安全策略、跨云网络、员工专业知识、治理、监控、部署自动化和事件响应流程。如果这些能力不成熟，多云就会变成分布式脆弱性。

　　更好的答案是特定于工作负载的弹性。并非每个系统都需要跨提供商进行主动部署。一些工作负载需要在一个提供商中的多区域架构。其他人需要主动-被动故障转移。有些需要强有力的备份和恢复。有些可以忍受几个小时的停机时间，但对业务的影响很小。

　　企业应按业务关键性对应用程序进行分类。面向客户的系统、收入平台、支付、物流、临床运营、身份服务和监管工作流程通常需要更强的复原力。内部报告、开发系统和低影响的工作量可能无法证明同样的投资是合理的。

　　测试和更多测试

　　一个没有经过测试的复原力计划只是一个理论。许多企业都有显示从未执行过的故障转移路径的架构图。他们有从未恢复过的备份。他们有依赖于过时步骤的恢复运行手册。它们的升级路径在文档中看起来不错，但在实际事件中失败。

　　测试是复原力成为现实的地方。企业应该进行受控故障练习。他们应该测试区域故障转移。他们应该从备份中恢复类似生产的数据。他们应该模拟托管服务、身份提供商、网络路径或第三方API的丢失。他们应该衡量实际的恢复时间，而不是依赖假设。

　　这些测试通常显示，系统最薄弱的部分是操作模式，而不是云平台。团队可能不知道谁可以批准故障转移。企业领导者可能不知道降级模式是什么样子的。工程师可能没有执行紧急更改的权限。监控可能无法显示客户的真实影响。沟通团队可能没有为客户或监管机构准备语言。

　　云弹性既是技术性的，也是组织性的。架构很重要，但决策权、运行手册、人员配置、沟通和实践也很重要。

　　成本必须明确

　　更好的复原力要花钱。多区域部署、复制数据库、额外的监控、流量管理、备份存储、测试环境和熟练的操作都增加了云支出。该成本不应该被隐藏或被视为浪费。将其与停机成本进行比较。一小时的停机费用是多少？如果客户无法访问资金、完成购买、安排预约、发运产品或使用核心服务，会发生什么情况？什么是监管风险？声誉的损害是什么？适用哪些合同处罚？存在哪些手动变通办法，它们可以扩展多长时间？

　　一旦你回答了这些问题，弹性投资就更容易证明是合理的。一些系统应该有昂贵的设计。其他人不会。但至少这个决定是经过深思熟虑的。最糟糕的结果是意外投资不足，关键业务系统的复原力很低，仅仅是因为没有人为风险定价。