2023年11月12日阿里云产品全面故障的启示

2023年11月12日，阿里云产品因为某些故障，全线都受到影响。是的，双十一的第二天，我的购物车还没清空，阿里云就不让我买了。云产品全面故障，影响之大一个大铁锅都装不下。之所以阿里云故障受到大家这么关注，一方面是阿里云投入多年技术领先，国内 IaaS 领导者，另外一方面是阿里云用户量大影响也大。

通过这几天网上满天飞的信息，大家肯定也大概了解了事情原委，我想结合自己的经验和教训，大致说五点。

对生产环境要心生敬畏

任何一次变更，无论是代码、配置、甚至是网络、ACL的变更都可能引发严重事故。线上的生产事故意味着企业营收实实在在的损失，更意味着用户对平台信任的丧失。钱可以慢慢赚，但是用户流失了就不是很快能回来的。

举个简单例子，如果你的存储不稳定，而我上面存的是数字货币。结果因为云存储导致我上面几百个数字货币找不到了，这样的损失用户能接受得了么？啥？几百个数字货币你就给我一个月语雀会员？这不是找打么。

甭说什么高性能，高并发，高可用，一铲子下去三高全完。

2015年5月27日16点40分，杭州市政建设工程施工过程中，一铲子下去杭州电信管道内四条大对数光缆中断，支付宝相关业务受到全面影响。至5月28日3点57分光缆陆续抢通，业务才逐步恢复。

虽然铲子很厉害，但是数据表明，生产环境的故障90%以上都是变更引起的，所以我们要对变更格外重视和小心。发版要审批，变更要评审，上线要灰度，有问题快速回滚，系统有监控，异常有告警......这都是必备的。没有一环又一环的系统保障，没人敢对淘某宝这样一个DAU超5亿的站点进行变更。

某年的正月初六，大家还在春节的欢乐喜庆的氛围中，公司 Gitlab 服务器告警，硬盘故障，挂掉硬盘一块。没到五分钟，告警电话再次打来，硬盘又挂掉一块。服务器只有四块硬盘，这下raid5 也不好使了。冰冷的心，颤抖的手，就问你小腿抖不抖。

好在我们做了主备，也做了冷备，且演练了多次。但还是用了一个多小时来恢复服务和验证数据。

对技术保障团队价值要有足够认知

还记得当初有个.NET开发的网站叫 360buy，每次促销都崩，以至于最后老板气不过，在微博上高喊给我加三倍服务器，促销延长3小时。对，你猜的没错，就是现在的 jd.com。现在京东的稳定性早已经今非昔比，双十一促销30天也不会崩，但这是这么多年真金白银堆起来的。

研发总是在短期被重视，在长期被忽视；套用一下，技术保障团队也是如此的尴尬，持续投入的公司很少，尤其是公司效益不佳、看不到 infra 价值的时候。

从公司角度来说，公司做新东西开展新业务，抢占市场，价值容易体现，每年带来多少营收很容易算出来，但是把钱投入到技术保障上，花费大效果还不明显。所以很多公司盘点业务的时候也不由自主地往业务发展上加码。

从员工角度来说，也会把业务放在前面，给予高优先级，花了多长时间出了多少活效果怎么样，毕竟这部分容易说清楚；同时也会降低技术保障类任务的优先级，甚至只有在OKR Review的时候才会去看一眼。系统保障这种事一般体现在OKR中，但时间是不会体现的，只排活不排时间。这部分做了和做好所需要投入的时间差异很大，所以很多员工从自身利益出发也会偷偷地【权衡」掉系统保障应该花的时间，把时间放在开发功能做业务上。就像练武一样，招式易学，内力不好练。

业务压力大，需求排得紧，这是事实；员工愿意做出活快，价值明显的工作，这也是事实。但是我们要意识到技术保障也很重要，否则也不可能总要求在我们的OKR中有体现。就像业界区分产品、研发、测试、运维、DBA、SCM、安全这些岗位都是有意义的，是从这么多年国内国外的实践中总结沉淀出来的经验，是用真金白银买来的教训。

系统稳定性想要做好，只能靠大量的细节来落地，这意味着的是大量的投入，持续大量的投入，甚至要把稳定性当成业务一样持续地投入。这就好比城市内涝治理，功夫在平时。

技术保障效果差的思考

很多稳定性的技术保障方案都是有的，但是就是做不好，归根结底是组织的问题，是认知的问题。

首先从领导层，尤其是远离技术团队的领导就会质疑我们真的需要那么多人去做技术保障工作么？真的会出故障么？你看去年我们裁了两SRE不也没出问题么，今年再裁俩。

出事咋办？找人救火，丧事喜办也不是没有。经常出现一种现象，修河堤的辛苦奔波狼狈不堪，抗洪救灾的升官发财。

很多人对技术保障认知不够深入。总觉得资金、人力和时间投入很大，但技术保障对业务的收入影响难以衡量。另外，技术保障团队的努力也容易被业务团队带来的收益掩盖。

平衡业务发展与技术保障建设

很多时候出故障的确不是技术问题，而是组织如何平衡业务发展和技术保障投入的问题。

技术保障就是投入，扎扎实实地做，持续扎扎实实地做。

叫醒一个装睡的人是很难的。曾经有一个人问我，公司现在1000人，有必要建立专门的研发效能团队么？我说，既然还没体现出这块的价值，那就没必要。

如果你还没意识到它的价值，让你做也做不好。只有自身意识到它的价值了，心里才会真的认可这件事。如果老板自身都没意识到它的价值，然后让团队去自证团队存在的价值，老板难，团队也难。安全团队的价值怎么体现？一年没有安全事故，安全团队的价值何在？没价值吧，裁俩。

对于技术保障团队，证伪容易，证真难。一个故障把你打回原型，想再化成人形又不知道要蛰伏多少年。

上云信心受损，多云部署+混合云部署诉求上升

上云带来的是便捷的运维和较低成本，但也引入了一些风险，尤其是单一使用一家云服务厂商的时候风险就会很大。其实Amazon AWS一样也出故障，不过这次阿里云挂的范围确实也大了点，影响了的公司也忒多了点。这么大的一个故障，上云信心多多少少都会受影响。

这次故障过后很多已经全面上云的企业会担心数据丢失，业务受损。所以经过这么一次「昂贵」的教训，估计很多企业会寻求多云部署和混合云部署。大家对对灾备的认知也会更深刻一些。

「前沿数控」公司，所有数据都在云硬盘上，结果因为云硬盘故障，导致公司的所有数据全部丢失，无法恢复，一夜回到解放前，也不知道官司现在结果如何了。

本文小结

稳定性或者说质量都是钱堆出来的，花的是清清楚楚的钱，省的是糊里糊涂的账。但是系统一旦出故障损失的钱却能算得清清楚楚。技术保障就是这样，骑车去酒吧，该省的省该花的花。该花的钱不花，系统就死给你看，服务一挂，业务立刻受损，而且损失的不仅仅是钱，更重要的是商业信誉和用户对你的信任。

阅读我的更多文章

阿里云香港节点全面故障给我们的启示

破局DevOps｜8大北极星指标指引研发效能方向

DevOps｜破除壁垒,重塑协作——业务闭环释放产研运巨大效能(中）

DevOps｜服务治理与服务保障实践指南

infra ｜ devops工具链基建建设评价标准