国内云厂商宕机事故频发，国外也这样吗？

这是头哥侃码的第305篇原创

周末和朋友闲聊，有位不嫌事大的“吃瓜大佬”，又提起与国内云厂商宕机的事来。

刚刚过去的4月某天，腾讯云愣是崩了 74 分钟（15:31 - 16:45），还波及全球 17 个区域与数十款服务。依赖云API提供产品能力的部分公有云服务，也因为云API的异常出现了无法使用的情况。

去年11月末，阿里云宕机的事冲上热搜，什么阿里云盘，什么淘宝，什么闲鱼……几乎全线产品受到影响。

这没过几天，这滴滴系统崩溃的事直接冲上了热搜，不仅让打工人直接打不到车，甚至连共享单车都扫不到，这一 “罢工” 就是好几天。

……

你们瞅瞅，这没完没了的故障，对企业不管是财务和声誉的损失都是巨大的，更有网友辣评到 “这是降本增效一刀切到了大动脉上”。

1

国内的公有云都是垃圾？那国外也这样吗？

去年，就在滴滴崩溃事件发生后不久，我曾在某社交网站上看到过这样一则评论。

“还是国外的云厂商牛逼，这些年我就没听到过国外云厂商宕机！我们和人家还是有差距啊！”

“你真是一条崇洋媚外的舔狗。”，这是我给这哥们留下的评语。

发泄完情绪之后，我还特地进行了搜索和整理，主要是为了证明任何一个公有云供应商，在发展的历史长河中，都遭遇了这样那样的宕机、故障。或因人为因素、或因雷电太凶、或因机房停电、或因光缆被挖、或因代码错输……这些问题的出现与解决，正好也是公有云服务不断优化与提升的过程。

这玩意是科学，不是跳大神。

咱们以全球公有云 “一哥” AWS 为例，近十年来可查询记录的宕机事故高达20次，咱们来看看最近的5次。

【2018年】

AWS网络故障，故障持续时间不详。

2018年3月，亚马逊Alexa智能家居出现了区域性失灵，用户在家中唤醒亚马逊Echo系列产品时，Alexa会让用户重试并报告找不到服务器。AWS数据中心硬件故障导致云服务影响，持续时间30分钟。

2018年5月31日，因北弗吉尼亚地区的数据中心出现硬件故障，AWS再次出现连接问题。在此事故中，AWS的核心EC2服务，Workspaces虚拟桌面服务以及Redshift数据仓库服务均受到影响。AWS管理控制台故障，故障持续近6小时。

2018年7月18日消息，亚马逊盛大的购物促销活动Prime Day遭遇了史上最大的尴尬，亚马逊网站和应用出现了重大技术故障，威胁到了其持续36个小时的销售盛宴。

与此同时，亚马逊核心产品AWS云服务也出现了中断。客户登录AWS管理控制台时，将收到一条带有狗图片的错误消息，消费者Prime Day在亚马逊网站上看到带有狗的图片类似，该故障持续了将近6小时。

AWS韩国服务器中断，故障时间持续一个多小时。

2018年11月23日亚马逊网络服务（AWS）的核心服务器在韩国全国发生中断，导致两个主要的加密货币在线交易平台停止运作。AWS是全球广泛使用的云服务之一，受到内部核心服务器故障的影响，导致主要的数字资产交易平台Upbit和Coinone戛然而止。据外媒报道，几个主要的电子商务中心在大约一个小时内也无法访问。

【2019年】

AWS北京区域因光纤被挖断中断新实例启用，故障时间持续不详。

2019年6月1日晚，AWS北京区域CN-NORTH-1地区的隔夜道路施工中有几处光缆被切断，导致可用区无法链接Internet，进而引发所有可用区中新的实例无法启动的故障，包括EC2 API启用故障。因而EC2 API在整个CN-North-1区域都不可用。

……

2

故障那么多，难道真的只是技术问题吗？

事实上，任何软件系统都难以避免故障的发生，无论是国内顶尖的BAT，还是国际巨头如Google、Amazon、FB、Twitter等，都无法完全杜绝故障。随着业务规模的扩大和系统复杂性的增加，问题和故障自然也会随之增多。

然而，这并不意味着我们应该对故障视而不见。相反，我们应该正视故障，将其视为技术和管理上的挑战。

故障并非表面现象，而是深层次技术和管理问题的反映。因此，作为负责人的目标不应该是消除故障，而是要通过设计更健壮的系统、完善故障隔离和快速恢复机制等措施，降低故障对业务的影响。

在接受故障现状的同时，团队负责人也应该拥抱风险，将注意力放在解决技术和管理问题上。比如说，人员技术是否过硬、自动化平台是否完善、线上敬畏意识是否足够等问题，都是导致故障频发的重要原因。

此外，团队负责人还需要关注可观测性建设和故障预案的完善程度。只有把问题定义清楚、找到根源，那才能真正降低故障对业务的影响。

说白了，很多人压根不明白什么是成本、什么是效率。

这降的是应该是系统的复杂度，这提的应该是系统的可观测性、服务间松耦合以及管理有效性等方面。

很可惜，国内的很多负责人，不仅在专业性上是个半吊子，而且还选错了路。

最后，我们应该认识到，开发和运维是密不可分的两个环节。

只有让专业素质过硬且具备高情商的管理者来领导团队，才能确保业务顺畅运行并降低故障发生概率。

总之，在面临系统故障时，为何难以迅速识别原因并恢复服务？

这背后的问题值得我们深入探究。是否因为监控体系尚不完善，导致告警繁多而使人员产生麻痹心理？是否因为问题定位效率低下，使得故障的根本原因迟迟无法确定？又或是因为故障隔离机制不够成熟，以及应急预案仅停留在纸面，无法有效执行？

必须承认，在故障处理过程中，开发和运维的角色各有侧重，互为补充。

开发团队专注于功能的实现与创新，而运维团队则负责确保系统的稳定与可靠。两者虽有交集，但专长领域各异。

因此，我们不能简单地将故障归咎于某一方，更不能以处罚作为解决问题的手段。

这种做法只会掩盖问题，使小问题累积成大问题，最终引发更大的故障。

3

透过现象看本质，再说点大道理

老实说，一个优秀的技术团队需要拥有既懂技术又擅长管理的领导者。

这样的领导者不仅能理解技术细节，还能洞察团队动态，制定合理的工作流程和运作机制。

在故障发生时，他们能够迅速作出判断，协调团队资源，有效应对挑战。

在这方面，AWS等海外企业设立的SRE（Site Reliability Engineer）岗位值得借鉴。SRE不仅具备深厚的运维经验，还具备开发背景。他们通过标准化、自动化、可扩展和高可用等手段解决运维问题。这一岗位的设置旨在打破开发与运维之间的隔阂，实现两者的紧密协作与高效沟通。

然而，要真正实现这一目标，公司决策者们应该要关注团队建设和专业素质的提升。

毕竟一个优秀的团队需要具备强大的心脏和高情商，能够应对各种挑战和压力。因为只有当一个系统的可观测性和故障预案的制定与执行背充分考虑与落实的时候，一群做事的愣头青们才能确保系统在面对故障时能够迅速恢复并保持稳定。

此外，我还呼吁大家要摒弃一些错误的观念。

比如，我经常听到一些团队管理者在那嚷嚷：“先让业务跑起来，故障概率很低，别担心”。其实这种心态是很可怕的，因为这只会让我们在面临故障时手忙脚乱，更可怕的是，这会导致你在系统设计之初就会先入为主的认为 “先跑，再说”。

于是，人性的懒惰被充分的激发了，什么故障预防，什么应对措施，在业务利益面前似乎都不再重要。

好了，咱就唠到这。

最后，我还是想对那些习惯于 “烧钱 + 圈地模式” 的大佬说几句。

在这个内卷且产能过剩的存量时代，技术团队应该更关注降本提效的真正内涵。在有限的时间和成本下，拼尽全力去降低系统的复杂度成本，提高系统的可观测性和松耦合程度。

别再每天沉浸在PPT的梦幻之中，否则企业的长远发展与坚定信念，迟早毁在你手上。