这是头哥侃码的第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的梦幻之中，否则 企业的长远发展与坚定信念，迟早毁在你手上。
