我们的生活里，充满了很多理所当然的事情：只要网上下单，过几天想要的东西就会出现在楼下快递柜；饭点一到，按动几下手机很快会有热气腾腾的饭菜送上门；喜欢玩游戏？下班了往家里沙发上一躺，就能放松大脑半个小时……假如这一切忽然消失，世界会变成怎样？

恰好《万神殿》第二季出来了，开场的第一幕就给我留下了深刻的印象：由于云上虚拟空间的上载智能间相互争斗，全球相继宣布关闭了互联网。世界回到了没有网络的时代，宵禁重启，没有快递，世人纷纷走出门抗议，要求回到正常的生活，也就是拥有网络的世界……

这和我们的生活何其相似，现阶段云计算在我们的生活中已经无处不在。云对于普通民众来说就像“水电煤”一般的存在，如果云上出了问题且无法及时止损，那么问题蔓延扩散，就像核爆一般产生连锁反应，关键业务宕机……届时的世界将会是何等黑暗，简直不堪设想。

前几天云计算行业发生的另一件事，恰恰就让我产生了这种感觉：年度购物节刚过，某云厂商就出了P0级别事故，伴随着其关键业务系统办公SaaS、云盘产品全线崩了的消息跳上热搜，网购软件崩掉，外卖软件无法下单，仓储小哥接不到单子，停车场无法抬杆入场、超市不能结账……甚至想玩个网游都不行，因为系统发不出验证码！

这是什么程度的云系统故障？

在互联网高度发达的今天，这个处境相当于全球“被迫断电3小时”，如果只是几分钟，或许能用“网卡了”解释，而当持续时间是几个小时、漫长到让人开始产生烦躁的情绪时， “喜提热搜”可能是大众能选择发泄不满情绪的最佳渠道了。

后根据该厂公告表示，其包含全线产品均受到影响，而受影响的地域从爆炸半径来看，可以说扩展到了全球。

那么问题来了，明明是分布式系统，为何1个宕了，全球都“连坐”？

虽说没有不出故障的云，但爆炸半径如此之广，到底因何而起？

云系统故障发生原因：

事故发生3日后，该厂商发给客户的公告说明了此次事件发生的原因，与访问密钥服务异常有关。该公告称：“访问密钥服务在读取白名单数据时出现读取异常，因处理读取异常的代码存在逻辑缺陷，生成了一份不完整白名单，导致不在此白名单中的有效请求失败，影响云产品控制台及管控 API 服务出现异常，同时部分依赖密钥服务的产品因不完整的白名单出现部分服务运行异常。”

密钥服务是一个重要的底层服务，用于创建、管理和控制用户的密码、密钥。该服务是整个云系统的基石，大家如果对云服务比较熟悉，应该知道每一家服务商都有类似的服务， 当然密钥服务存在的必要性自然毋庸置疑，但系统应该如何保障它持续生效？

云服务过程中为了保障可用性，一个常见的设计是使用“冗余配置”，也就是同时做多个备份、一旦遇到故障，立刻启用备份，把影响时间降到最低。但对于密钥这种涉及全球所有业务、体量超大的服务而言，冗余设计会造成无法接受的资源损耗，因而只能以分布式设计作隔离处理。我们尚未得知为何该云服务商没有使用分布式设计，导致“一项服务失效、全球皆受影响”，但该事故的发生可以说明，当前的系统架构存在设计隐患，服务的稳定性不足。

对云厂商有哪些启示？

云上发生故障在所难免，不管是6个9的可用性还是4个9的可用性，问题发生后最重要的是反思问题，避免大规模P0灾难再次发生，或者说在发生时，能够将损失最小化，将爆炸半径缩减到最小范围，归根到底，云上韧性，还是一个重大议题。毕竟，不发生则已，一发生，就有人要被迫“毕业”。

那么如何提升云厂商的韧性？我们或许可以看看目前云服务界的“一哥”亚马逊云科技是怎么做的。

多层级保护机制，获得更高容错能力：以亚马逊云科技为例，该厂拥有全球最多的覆盖245个国家，每个国家的数据中心覆盖是第一层级。接下来是32个区域，102个可用区。其中，每个区域都由一个地理区域内多个相互隔离同时物理上分隔的可用区组成，且每个区域都设计为3个以上的可用区，每个可用区都有独立的电力、冷却和物理安全性，彼此之间通过冗余的超低延迟网络进行互联。通过将应用部署在多个可用区或区域，用户能获得更高的容错能力。

故障隔离结构，物理隔离以及纵向隔离：将故障控制在已有故障域且可预测的范围内。例如，亚马逊云科技将其隔离结构分为：可用区 (AZ)、区域（Region）、控制平面和数据平面这三层。每个区域级服务都部署了专用的基础设施和服务堆栈，且互相隔离，在跨区域调用时也有足够的隔离机制。同时，每种服务的控制平面和数据平面都在不同的范围内进行隔离，即控制面的失败不影响数据面的运行，且不会扩散到相邻范围。这样，故障发生时的爆炸半径就可以限制在可控范围内。

静态稳定设计，故障发生业务仍可流程运行：静态稳定设计也是云厂商保障基础业务正常运行的表现，当依赖项发生故障或不可用时，期间系统无需进行更改就可以依然可以保持继续正常运行，在数据平面对资源的访问一旦配置，就不依赖于控制平面，因此不会受到任何控制平面失效的影响。换句话说，即使创建、修改或删除资源的能力受损，现有资源仍然可用。

使用单元架构和随机分片，把故障限制在最小范围：船只“损害管制”的重要策略之一就是把水密舱空间做切割，使其成为多个大小受限且彼此隔离的单元。云厂商同样可以用这个策略，通过把服务划分成多个单元、辅以采取随机而非连续方式进行存储，把故障颗粒度限制在某个范围尺度以内。

使用更具韧性的运维解决方案，建立完善的容灾与备份机制：分布式系统的工作负载架构必须能够预防与减少故障，符合静态稳定性的实践，并具备隔离机制，能检测故障并自动加以修复或转移。如亚马逊云科技的Well-Architect框架，包含自动从故障中恢复，测试恢复过程，横向扩展等特征，能够构建韧性系统最佳实践。此外，云厂商还需要建立完善的容灾与备份机制，如以冷备份、实时异步、实时等方式，同步/异步双向复制业务数据，满足多种不同 RPO/RTO ，保障应用和数据高可靠运行。

提升系统透明度，做好事先灰度测试：提供一系列预警工具与机制，主动对故障进行预防和检测，通过向客户发送有关服务事件、计划变更和账户的通知，提高操作门槛的同时降低风险，且不会限制服务的敏捷性。原生、应用程序性能监控（APM）个开源解决方案，具有全栈可观测行，客户可籍此了解整个技术栈中发生的情况，通过收集、关联、聚合和分析遥测数据，深入了解系统的行为、性能和运行状况，结合人工智能和机器学习，更快地检测、调查和修复问题。

1961年，美国科学家约翰·麦卡锡提出，算力应该像水电资源一样随用随取，这个愿景造就了后来的云服务。在云计算、云服务高度发达的今天，确实全球有成千上万的人因此获益，我们的生活也随之迈入全新的科技时代。然而我们也必须时刻警惕由于云服务宕机等故障造成的灾难，时刻铭记唯有保障云服务的韧性，让云为我所用，才能真正实现云服务的初心。