2022年12月18日，阿里云香港Region可用区C发生大规模服务中断事件。12月30日，阿里云管理层巨震，张建锋卸任阿里云智能总裁，一把手位置由张勇兼任，CTO同时换人。
虽然公开的信息中并未直接提及最近这次故障，但字里行间这个意思还是比较明显了，内部信提到：“对云计算而言，稳定和安全是对客户最基本的责任，我们要始终秉持敬畏之心，不辜负客户的信任和依托”。这次被称为阿里云史上最大故障的事件，引起的巨震超乎寻常。
我们再来看看阿里云要想防住这次故障，到底难不难。
官方公告的“问题分析和改进措施”中，前两条是关于机房的：“1、冷机系统故障恢复时间过长 2、现场处置不及时导致触发消防喷淋”。这个锅基本是第三方机房服务商的，可以怪罪机房为啥不做好故障处置演练，不过看起来确实是小概率事件，要想完全避免也有点勉为其难。这种问题十年一遇，遇上了也只能怪时运不济。
第三条是重点：“3、客户在香港地域新购ECS等管控操作失败...新扩容的ECS管控系统启动时依赖的中间件服务部署在可用区C机房，导致较长时间内无法扩容。ECS管控依赖的自定义镜像数据服务，依赖可用区C的单AZ冗余版本的OSS服务，导致客户新购实例后出现启动失败的现象。”这就属于架构上没做到位的问题了，原本设计上是具备多可用区容灾能力的，但实际方案没做到。这个很难做到吗？事后看似乎很简单，换成多区高可用版本的服务就可以了啊。难就难在这样的细节太多了，如果要一个一个梳理，靠人的执行力、责任心很难保证100%可靠。这样的问题也是在多活架构建设中经常容易出现的疏漏，魔鬼就是藏在这样的细节里，一不小心，就会酿成大错。
这里可以举一些有意思的例子。某厂有一次做拔网线的故障演练，半夜拔完好久了还不见有人起来处理，老板震怒，打电话叫工程师起来赶紧查，结果发现监控系统刚好被断网了，告警都没发出来。2021年7月B站服务中断数个小时，复盘中提到故障期间远程在家的员工无法登陆内网鉴权系统，因为跟业务用了同一套网关，救命的通道也被堵了。这样的例子公开报道的不多，但从经验上来看其实数不胜数，非常考验技术团队的细节掌控力。说“魔鬼总是暗藏在细节里”，一点都不夸张。
还有什么好办法？最有效的莫过于实测，就是真正在线上制造真实故障来验证实际容灾能力是否符合预期，属于广义的混沌工程范畴。头部的互联网公司技术团队一般会定期实施机房级别的故障实战演练，阿里还在云栖大会上演示过拔网线的效果，如果都做到位了按理说这样的问题应该可以被覆盖到。个人猜测，阿里云的体量太大了，这样的演练还是没覆盖到每个机房、每个产品；同时可能还有一个难言之隐，就是客户对云的可用性过度依赖，容不得有任何故障，特别是国内的客户，普遍不太理会SLA，你挂了就是不行，不论选在什么时间做这样的故障演练，即使影响程度在SLA范围之内，也难免引起用户吐槽和找麻烦，这样也会阻碍公有云厂商做这类工作的积极性。Google SRE宝典分享过一个经验，为了防止用户对底层服务的可用性有过高的不合理依赖，对于长时间未中断过的服务，会主动短时间停服刺激一下，确保上层有正确的容错处理，这也不失为一种合理的边界。
作为云的客户，还能相信公有云吗？要论实力，阿里云不可谓不强，这样的问题别家也难说没有，不论是换一个云厂商，还是建设自己的机房，都不能解决根本问题。最有效的方案，还是要做好多云多活，并且彻头彻尾做好切换方案，不留死角。即便不具备条件同时在多个云厂商上运行服务，也要尽量选用跨可用区高可用的产品，至少可以避免单个可用区故障之后长时间不可恢复的尴尬。当然这次阿里云的问题就出在了多可用区高可用表现不符合预期，相信经此一役，这个短板一定会得到有效补齐，友商应该也会关注和解决。
互联网巨头们每年都免不了出几次震动业界的大事故，服务可用性建设仍是一个世界性难题，工程师同仁们仍然任重道远，聪明人也得下笨工夫，别无他法。
网友评论