【老万】半个互联网咋又崩了 - 深度反思 Cloudflare 事故
老万约 20 分钟》导言
2025年11月18日，互联网经历了一次近乎灾难性的震荡。作为承载全球约 20% 流量的核心服务商，Cloudflare 遭遇了长达数小时的服务中断。此次事故不仅导致包括 ChatGPT、X（原 Twitter）、Spotify、Canva 在内的众多顶级互联网服务访问困难，更直接干瘫了数以百万计依赖 Cloudflare 进行安全防护和内容分发的中小型网站。Cloudflare 公司自身市值也瞬间蒸发 18 亿美元。
这一事件并非由外部的高级网络攻击（如 DDoS 攻击）引发，而是源于 Cloudflare 内部的一次常规数据库配置变更。一个看似微不足道的错误让系统核心特征文件的大小超出了硬性规定的限制，触发了连锁反应并成功击穿多层防御机制，最终导致全球范围内的数字海啸。
事故背后折射出的深层问题远超代码层面，像是一次对现代科技企业急功近利文化的严厉拷问。在老万看来，Cloudflare 这次事故并非偶然，而是业界长期盛行的升职驱动开发、英雄文化和偏差正常化的必然结果。
在这份报告中，老万试图以详尽的细节还原事故全貌并深入探究事故的企业文化根源。我们将探讨为何拥有世界顶尖工程团队的科技巨头会跌入看似低级的技术陷阱，并结合软件可靠性工程的原则与近期行业类似事故（如 CrowdStrike 蓝屏事件），提出系统性的防御与整改方案，把“慢就是稳，稳就是快”的口号落实为切实可行的制度。
谁是老万
老万，人称《老万故事会》的老万，撰写微信公众号多年，码字之余在谷歌、微软、Pinterest 等互联网大厂码 bug，熟知行业黑话规范。他曾在谷歌广告部门管理超大规模分布式数据处理团队（超大的是数据规模，不是团队），又在 Pinterest 数据部门负责过核心服务的事故审查（职称为首席事后诸葛亮），熟读各种风格之事故报告，积累了 N 多大型系统的故障排查（参见故事片《完美风暴》）和灾后重建（参见电影《28天后》）经验。这篇文章仅代表老万的纸上谈兵，与谷歌公司意见无关。
》毫无征兆的数字海啸
2025年11月18日，协调世界时间（UTC）11:20。对于大多数身处西半球的互联网用户而言，这本该是一个忙碌的工作日的开始；而对于东半球的用户，这原本是一个平静的夜晚。然而，在 Cloudflare 分布于全球120多个国家的服务器里，一场无声的数字海啸正以光速席卷而来。
没有任何预警，全球范围内的网络流量监控指标瞬间出现了断崖式的异常。Cloudflare 的核心仪表盘——那个通常亮着绿色健康信号的屏幕——在几秒钟内被代表错误的红色警报淹没。
这场灾难并非局部地区的阵雨，而是一场覆盖全球的暴风雪。用户在尝试访问使用了 Cloudflare 内容分发网络（CDN）或安全防护服务的网站时，屏幕上弹出的不再是丰富多彩的内容，而是冷冰冰的 HTTP 500 内部服务器错误和那句令人绝望的“请几分钟后再试” 。
事故初期的混乱程度超出了许多资深工程师的想象。尽管 Cloudflare 的自动化监控系统在 UTC 11:32 捕捉到了异常并触发了紧急呼救，最初摆在工程师面前的拼图是破碎且极其误导的。
首先，故障表现出了一种诡异的“震荡”特征：服务并非彻底死透，而是在正常和失败之间打摆子。在用户看来，上一秒还在报错的网页，下一秒刷新可能就正常了，再刷新一次又陷入瘫痪。
其次，一个致命的巧合干扰了判断。就在故障发生的同时，Cloudflare 对外的状态页面——那个本该在危机时刻充当灯塔、向全球通报系统状况的网站——也无法访问。要知道，这个页面不依赖于任何 Cloudflare 服务，完全托管在 Cloudflare 的基础设施之外。这让 Cloudflare 团队误以为 Cloudflare 系统和状态页面同时遭受了黑客攻击。
更糟糕的是，当时的工程师团队正处于惊弓之鸟状态。近期，互联网上频发高流量的 Aisuru 分布式拒绝服务（DDoS）攻击。当海量的错误日志涌入、服务请求被大规模拒绝、关键系统出现过载，所有这一切都像极了一场精心策划的网络轰炸 。
在内部的加密聊天室里，气氛紧张到了极点。工程师们和公司联合创始人 Matthew Prince 的第一反应是：“我们被攻击了。”
这种误判导致了最初宝贵的几十分钟被用于排查并不存在的外部攻击源。防御团队试图寻找攻击流量的特征，却发现所谓的“攻击流量”似乎源自系统内部的崩溃。
在技术团队与幽灵般的故障搏斗时，现实世界的恐慌正在蔓延。那些还能访问的社交媒体成了用户发泄不满的广场。#CloudflareDown 的标签迅速冲上全球热搜。
金融市场的反应更是迅速而无情。随着故障持续时间的拉长，投资者对 Cloudflare 服务可靠性的信心开始动摇。Cloudflare的股价（股票代码：NET——你说有意思不？）在盘中应声下跌，跌幅一度接近 4%，大约 18 亿美元的市值在短短几小时内蒸发。这是市场对数字基础设施脆弱性投出的不信任票。
受影响的企业名单简直是一份全球互联网的名人录：从埃隆·马斯克拥有的社交平台 X，到改变了人工智能格局的 OpenAI；从流媒体巨头 Spotify，到设计平台 Canva。在美国的新泽西州，公共交通系统数字服务瘫痪，导致通勤者无法获取列车信息。在伦敦，依赖 Cloudflare WARP 服务的用户发现自己与互联网彻底断连。
讽刺的是，连此时此刻人们最需要的网络故障追踪网站 Downdetector 也未能幸免，因为它们同样依赖 Cloudflare 的服务来抵御流量洪峰。
Cloudflare 自己也震惊了。毕竟，上一次出现这么重大的事故还是上一次了（2019 年）。
根据 Cloudflare 的官方事后分析及第三方监控机构（如 Cisco ThousandEyes）的数据，我们可以精确还原这条灾难链的关键时间点（所有时间均为协调世界时 UTC）：
11:05 祸起萧墙Cloudflare 的工程师对 ClickHouse 数据库集群执行了权限变更操作。此操作旨在增强访问系统核心数据的安全性，却意外成为灾难的导火索。
11:28 故障显现 Cisco ThousandEyes 等外部监控系统开始侦测到全球范围内针对 Cloudflare 后端的连接超时和 HTTP 5xx 错误激增。Cloudflare 内部系统开始出现异常。
11:32 全面爆发 Cloudflare 的自动化测试套件检测到广泛的失败。此时，故障已扩散至全球数据中心，大量用户遭遇“500 内部服务器错误”。
12:00 雾里看花故障达到峰值。Cloudflare 的外部状态页面短暂下线，更加剧了恐慌。工程团队初步怀疑这是针对基础设施的大规模 DDoS 攻击。
13:05 初步缓解 团队决定实施止血措施，让分布式键值存储系统绕过核心代理系统。这一操作恢复了部分控制平面（control plane）和仪表盘的功能，但这只是权宜之计。
13:37 壮士断腕经过排查，团队排除了网络攻击的可能，确认问题源于一个错误的特征文件。团队开始回滚机器人管理系统的配置到上一个已知良好的版本。
然而，现实给了他们沉重一击：由于核心代理服务处于不断的崩溃和重启循环中，负责分发配置文件的内部通道也被堵塞了。正常的配置更新无法送达边缘节点，系统陷入了死锁。
为了减轻系统负载，Cloudflare 做出了一项艰难的决定：他们暂时禁用了伦敦的加密服务 WARP。这意味着试图通过 WARP 访问互联网的伦敦用户将直接面临连接失败。这种弃车保帅的战术为核心系统的恢复争取到了资源和时间。
有意思的是，1337 本身是个网络哏，象形英文单词 leet，而 leet 又是 elite（精英）一词的谐音，软件高手的意思。老万严重怀疑团队确认故障原因的时间实际略早，但是为了凑哏强行把时间记录为 13:37。
14:24 遏制扩散 工程师们强制停止了新的 Bot 管理配置文件的生成和传播，彻底切断了产生坏文件的源头。至此，部分地区的流量开始恢复正常。
14:30 注入解药 团队绕过常规的自动化流程，手动将一个已知正常的旧版本配置文件强行插入到分发队列中。随着这个健康的文件像解药一样被注入到全球网络的血管，由于文件体积恢复正常，Rust 进程不再崩溃，大部分网站恢复工作。
15:30 仪表恢复 虽然流量恢复，但由于积压了海量的登录请求，Cloudflare 的管理仪表盘经历了严重的拥堵。通过扩充控制平面的并发处理容量，仪表盘访问恢复正常。
17:06 尘埃落定 经过数小时的清理积压队列、重启剩余服务和密切监控，Cloudflare 正式宣布所有系统功能恢复正常。这场持续了近6个小时、波及全球的互联网浩劫终于画上了句号。
从 Cloudflare 公布的事后报告我们可以看到当天 5xx 错误 HTTP 状态代码的数量变化。你注意到前两个小时错误率像过山车一样的翻滚吗？
》Cloudflare 的蝴蝶扇动翅膀
为什么一个简单的数据库权限变更会让全球网络陷入瘫痪？回答这个问题需要深入 Cloudflare 的技术栈内部，理解数据、配置与代码之间的互动。
Cloudflare 大量使用 ClickHouse（一种高性能的列式数据库管理系统）来存储和处理海量的日志与配置数据。此前，全部数据库的查询都通过一个共享账户运行。为了提高分布式查询的安全性和可靠性，运维团队决定让查询以请求用户的身份运行。
这就像是一家银行决定升级金库的安保系统。以前，负责金库的员工可以用一把万能钥匙打开里面的所有保险箱。现在，银行决定一把钥匙开一把锁，给每个保险箱都配发专门的钥匙。这个初衷无疑是正确的，可以避免张三丰看到李四光的私密日记。
然而，正是这个出于好意的安全升级，成为了推倒多米诺骨牌的一阳指。
Cloudflare 有一个名为 Bot Management（机器人管理）的关键系统。它的职责是区分正常的人类用户和恶意的爬虫程序。为了保持对最新威胁的敏感度，该系统每 5 分钟会运行一条 SQL 查询语句，从 ClickHouse 数据库中读取最新的特征数据，生成一个配置文件，并分发给全球数千台边缘服务器上的代理软件。
问题就出在查询逻辑和新权限政策的相互作用上。
机器人管理系统的查询语句长这样：
SELECT name, typeFROM system.columnsWHERE table = 'http_requests_features';
请注意，这个查询没有按数据库名称进行过滤。
升级前，这一查询由共享账号运行。那个账号只有访问主数据库的权限，所以查询结果只包含主数据库的记录。
升级后，查询以初始用户的身份执行。而这一用户不但能访问主数据库，还能访问备份数据库。
画风开始变得诡异。查询结果中，每一条特征数据都出现了多份：除了来自主数据库的内容，又多了几份来自备份数据库的一模一样的数据。原本只有约 60 个特征的结果，瞬间膨胀成了包含大量重复项的、超过 200 个条目的列表。原来，系统自作聪明地把底层的备份数据也捞了出来，却没有在应用层做去重处理。
如果仅仅如此，也算不上太大的问题，无非就是系统做了一些不必要的重复工作而已，用户根本感受不到影响。
然而，福无双至祸不单行。当你在复杂系统中发现一个问题的时候，十之八九还有一个问题在前方等着你。
这个体积翻倍的胖版特征文件被生成后，被迅速推送到了 Cloudflare 位于全球各地的边缘节点。在那里，运行着负责处理核心流量的代理软件。
Cloudflare 的代理软件主要使用 Rust 语言编写。Rust 以其内存安全和高性能著称，是现代基础设施软件的宠儿。然而，安全的意思只是说系统不会出现无定义的行为（也就是说不会程序跑飞胡搞一气），和可靠性并非一回事。即使是用了最安全的语言，逻辑上的设计缺陷一样可以导致系统崩溃。
在这个案例中，Cloudflare 的代码里埋了两个致命的雷：
首先，工程师在编写这部分代码时，为了追求极致的性能，预设了一个特征数量的硬上限——200 个。在当时看来，实际使用的特征只有 60 个左右，预留 200 个的空间似乎极其宽裕、甚至有些浪费。这种静态的思维假定业务增长是渐进的、可控的，却忽略了配置错误可能导致的爆发式增长。
其次，代理软件完全忽略了对底层错误的处理。当 Rust 程序读取到的配置文件包含超过 200 个特征时，触发了边界检查错误。在 Rust 的标准实践中，遇到这种错误应该返回一个 Result::Err，由上层逻辑进行优雅处理（比如忽略新配置，继续使用旧配置）。然而，Cloudflare 的代码在这里使用了最最简单粗暴的 .unwrap() 方法：
解释一下：.unwrap() 的含义是“请相信我，这里绝对不会出错。如果错了，我愿赌服输，请直接让程序崩溃吧！”
这就好比汽车的刹车系统设计逻辑是：如果车速仪表盘显示的数值超过200，系统不是尝试刹车，而是直接引爆引擎，让整辆车瞬间解体。
于是，当发胖的配置文件被加载时，数万个负责转发全球流量的进程不约而同执行到了这一行代码，然后心照不宣地一齐崩溃。
解释了崩溃的原理，我们就能理解为什么故障初期表现为震荡了。
特征文件的生成并不是在一个中心化的单点完成的，而是依赖于一个分布式的 ClickHouse 集群。事发当时，数据库权限的变更正在集群的各个节点上逐步推进。
当生成特征文件的请求被路由到了已更新权限的数据库节点时，它会生成发胖的文件。这个胖文件被推送到边缘节点，导致代理软件崩溃，服务中断。
要是这一请求被路由到了尚未更新权限的数据库节点，它又会生成正常的文件。这个好文件被推送到边缘节点，等代理软件重启并成功加载特征文件，服务便会短暂恢复。
由于机器人管理系统每 5 分钟重新生成一次配置文件，全球网络就在这两种状态之间反复横跳。这种薛定谔的配置文件完美模拟了网络攻击时的流量波动特征，极大地干扰了故障排查团队的判断，使他们误以为是在对抗一个狡猾的攻击者，殊不知是在跟自己的影子作战。
》巨人也会跌倒
Cloudflare 的这次事故并非孤例，光杀一两个程序员祭天于事无补。如果我们放眼整个科技行业，会发现“配置变更引发瘫痪”已经成为一种流行病。
还记得 2024年7月导致全球 850 万台 Windows 设备蓝屏的 CrowdStrike 事故（参见拙文《如何写出万人唾骂的软件》）吗？两者有惊人的相似之处：
同样是配置文件内容出错（一个是体积膨胀，一个是逻辑错误）。
同样是跳过灰度发布瞬间分发。
同样是进程崩溃（一个崩的是应用程序，一个崩的是操作系统内核）。
不同的是，Cloudflare 比较幸运，依靠集中式回滚配置，在数小时内完成了系统恢复。而 CrowdStrike 更倒霉，因为机器进入了死机循环无法遥控修复，需要管理员物理接触每台终端设备手动维修，花了几天才恢复。
三大云服务厂商也同样无法幸免。
2025年6月12日，谷歌云发生了一起导致全球多项服务中断两个多小时的重大事故。起因是谷歌内部系统更新的配置文件缺少了一些关键字段，导致服务器在解析配置时抛出了空指针异常。
2025年10月20日，AWS 遭遇了更严重的长时间服务瘫痪，核心原因在于其对 DynamoDB 的一次技术更新中潜藏了错误，意外触发了内部 DNS 系统的竞争条件（Race Condition），导致应用程序无法正确解析服务器地址。这一底层配置错误迅速在核心区域 US-EAST-1 引发了连锁反应，致使包括 EC2、Lambda 和 SQS 在内的 113 项关键服务不可用，导致 Reddit、Snapchat、Roblox 等大量依赖 AWS 的知名平台在全球范围内宕机，数百万用户受到影响。
仅一周后，2025年10月29日，微软的 Azure 也爆发了全球性中断。此次事故的根源被确认为 Azure Front Door（其全球内容分发与流量路由服务）的一次错误配置变更。
根据 Cisco ThousandEyes 的《互联网报告》，配置错误导致的宕机比例正在逐年上升，甚至超过了硬件故障和黑客攻击。原因有二：
首先是系统复杂性爆炸。现代微服务和云架构拥有成千上万个参数，人脑无法完全掌握其交互逻辑。由于系统过于复杂，局部优化往往导致全局崩溃。比如 Cloudflare 数据库团队优化了权限管理，却意外击穿了应用层的假设边界。在微服务和分布式架构中，没有任何一个变更可以说是“隔离”的。
其次，自动化工具赋予了运维人员上帝权限。过去一个错误只能搞挂一台服务器，现在一个脚本错误能搞挂半个互联网 。要是阿基米德是程序员，他会说“给我一个管理员账户，我能干翻整个地球”。
比如，Cloudflare 拥有一个名为 Quicksilver 的分布式键值存储系统，用于在几秒钟内将配置变更同步到全球每一台服务器 。
这无疑是一把双刃剑。在防御攻击时，这允许 Cloudflare 瞬间在全球封杀一个新的恶意 IP，效率极高。然而，水能载舟，亦能煮粥。在本次事故中，Quicksilver 充当了错误的超级传播者。它高效地将那个有毒的配置文件同步到了全球。由于缺乏足够的中间缓冲或灰度发布机制，错误的配置得以在没有任何阻力的情况下瞬间摧毁全球网络。
》阳光下的罪恶
为何汇聚全球管理精英的互联网大厂不能避免重大事故一再发生？说到底，这是有毒的企业文化和人性弱点相互推动的结果。
晋升驱动开发的恶果
在现代科技企业的绩效评估体系中，工程师的职业发展往往与影响力直接挂钩。然而，影响力的定义通常被狭隘地解读为“可见的变化”。推出一个新功能、引入一种新技术，这些都是显而易见的、可量化的成就。相比之下，稳健型工程师所从事的工作——预防故障、优化现有代码、消除潜在隐患——本质上是在创造“非事件”（Non-event），难以量化。
一个系统运行良好时，没有人会注意到稳健型工程师的贡献。只有当系统崩溃时，人们才会意识到稳定的重要性。这种预防的悖论导致那些致力于基础工作的工程师在绩效评估中往往处于劣势。许多工程师因此产生了一种心态：傻子才去做对业务长期有利的基础工作，“良禽”应该投身那些能让晋升材料好看的枝桠。
与其谴责工程师的不负责任，不如想想什么样的制度才能激发员工的主人翁责任感，让他们主动做对公司最有利的事情。
英雄有毒
与稳健型工程师的边缘化相对应的，是企业对英雄文化的病态推崇。不难想象，在重大事故发生后，公司内部必然会动员大量员工进行紧急修复。这些在危难时刻挺身而出、通宵达旦恢复服务的工程师，往往会被视为公司的英雄，并在随后的全员大会上受到表彰。
然而，这种表彰机制隐含着一种危险的信号：制造问题（快速编写不稳健的代码）然后解决问题（通宵救火），比一开始就编写不出问题的代码更能获得职业回报。正所谓“有困难要上，没有困难创造困难也要上”。人的行为是环境的产物，英雄文化会助长一种短期主义的思维模式：“先上线再说，出了问题再修”。
在这种文化氛围中，如果一位稳健型工程师在项目初期提出：“我们需要花两天时间来移除这个硬性限制，并编写针对大文件的模糊测试”，他很可能会被产品经理或工程主管视为阻碍进度的理想主义者。他的声音会被淹没在“快速迭代”、“敏捷开发”的口号声中。最终，这个硬性限制被保留了下来，直到它引发了那场导致 18 亿美元市值蒸发的灾难。
资本的短视
管理层为何忽视基础工作？这不仅仅是技术认知的问题，更是经济学理性的结果。在季度资本主义（Quarterly Capitalism）的压力下，上市公司必须每个季度向华尔街展示增长故事。
对于 Cloudflare 这样的高增长科技公司而言，资源分配是一场零和博弈。投入到新功能（如AI服务、机器人管理）的资源，能直接带来营收增长和市场份额的扩张，从而推高股价。相反，投入到消除技术债务、重构老旧代码、优化配置管理的资源，其回报是隐性的、长期的，甚至是不可感知的。
从金融角度看，管理层实际上是对未来的风险应用了极高的贴现率（discount rate）。他们隐含的计算逻辑是：现在花费 100 个小时去修复一个“可能”在未来爆发的隐患，不如将这 100 个小时用于开发一个肯定能带来收入的新功能。这种逻辑在绝大多数时候是成立的，直到黑天鹅事件发生。
此次事故造成的巨额经济损失，以及对客户信任度的打击，在事后看来显然远远超过了修复那个硬性限制的成本（可能只需几小时的工程时间）。但在事故发生前，这个成本是不对称的：修复成本是确定的当前支出，而事故成本是概率性的未来可能支出。在短期利益驱动的决策模型中，概率性的未来风险总是会被系统性地低估。
偏差正常化带来飙升的风险
导致管理层忽视基础工作的另一个心理机制是“偏差正常化” （Normalization of Deviance）。这一概念由社会学家 Diane Vaughan 在分析“挑战者号”航天飞机灾难时提出，意指组织逐渐接受那些偏离安全标准的操作，仅仅因为之前没有发生过灾难性的后果。
在 Cloudflare 案例中，那个 200 条数据限制并非在一夜之间变得危险。随着业务的增长，特征文件的大小可能一直在缓慢增长。而每一次系统的成功运行，都强化了管理层和工程团队的错误信念：“这个系统是健壮的”，“这个限制不是问题”。
这种心理机制导致了风险阈值的不断提高。原本被视为临时的、不完美的解决方案，随着时间的推移变成了永久的、被默认接受的新常态。当稳健型工程师试图警示时，管理层会依据过去的“成功经验”来反驳：“我们一直这样干，从来没出过问题，为什么要现在花资源去改？”
这种现象在配置管理中尤为严重。配置文件的变更往往被视为“低风险”操作，不享受代码变更同等级别的测试和审查待遇。人们习惯了随意修改 SQL 查询或 YAML 文件，因为“这只是配置，不是代码”，直到这种改动触发了全新的代码路径，引发雪崩。事实上，上次 CrowdStrike 公司引发全网偏瘫也正是因为忽略了配置文件改动的风险。
》对毒文化的反击
要打破上述的文化恶性循环，企业不能仅仅停留在口号上的反思，必须将“慢就是稳，稳就是快”的哲学转化为具体的、强制性的制度设计。
错误预算的平衡术
重视稳定性，并不是说为了稳定可以不计代价。一切工程决策都是权衡利弊的结果。要是我们矫枉过正，因为管理层不重视基础工作就故意反其道而行之，该冒的险也不敢冒，就会错失商机，被竞争对手打得稀里哗啦。
如何在冒进和谨慎之间找好平衡？错误预算（Error Budget）是一个平衡速度与稳定性的有效工具。
谷歌在实践中总结出了一套行之有效的 SRE（站点可靠性工程）方法论，错误预算就是其中之一。它的核心思想是将“可靠性”量化为一种可消耗的资源。
简单地说，我们为每个系统分配一定的允许出故障的时间（如每季度宕机不超过 3 小时）。在此范围内，团队可以随意发布新功能。一旦超标，新功能发布立即冻结，团队必须转入打地基模式，专注于把系统搞扎实。
比如，如果我们的目标是可用性 99.9%，那么每季度可以容忍的故障时间就是 91*24*0.001 小时（大约 2 小时）。一旦因事故耗尽了预算，团队只能依制度停止所有新功能的发布。
这不仅仅是一个技术策略，更是一个政治策略。它赋予了稳健型工程师叫停业务扩张的尚方宝剑。当产品经理要求上线新功能时，SRE 团队可以依据错误预算耗尽的事实合规地拒绝，并要求整个工程团队转向技术债务的偿还和稳定性的巩固。这种机制迫使管理层必须关注基础工作，因为忽视基础工作将直接导致业务停滞。
从黑天鹅到灰犀牛
管理层往往忽视理论上的风险，但无法忽视看得见的失败。混沌工程（Chaos Engineering）通过在生产环境中主动注入故障，将潜在的“黑天鹅”转化为可控的“灰犀牛” 。
针对 Cloudflare 此次的配置错误，如果企业实施了完善的混沌工程，他们不应等待配置文件在生产环境中自然增长到崩溃，而应该在测试阶段就主动注入超大的、畸形的配置文件（模糊测试），观察系统的反应。
Netflix 公司开发了一个叫馄饨侯“混沌猴”（Chaos Monkey）的测试工具，用来随机杀掉生产环境中的服务器实例，考验系统的自愈能力。要是我们将这种破坏性测试集成到 CI/CD 流水线中，让脆弱的代码在上线前就崩溃，就可以迫使工程师在开发阶段就解决这些问题。这正是“慢就是稳”的体现。
正确的激励制度
最后，也是最难的一点，是改造公司的激励体系。企业必须打破“只有新功能才算影响力”的迷思，鼓励员工做正确的事。
比如，将系统的稳定性指标（如平均故障修复时间MTTR、平均故障间隔时间MTBF）直接纳入绩效考核，且权重不低于新功能发布。
还有，我们都见过有人快糙猛上线一个新系统，快速获得晋升然后拍拍屁股走人，把一个千疮百孔的项目留给同事维护。好的制度应该杜绝这种不公平现象，确保“自己的屁屁自己擦”。比如我们可以规定系统上线后必须原地维护 6 个月，稳定性达标后才算上线成功，在此之前离开项目的不得凭该项目升职。
又比如，为那些专注于系统优化、工具链建设、技术债务偿还的工程师们设立独立的晋升通道，确保他们不需要转型做管理或开发新产品也能获得认可。
结语
2025年11月18日 Cloudflare 的全球大瘫痪，表面上是一次配置管理的失误，实则是企业文化长期处于亚健康状态的一次急性发作。
要避免下一次灾难，Cloudflare 及所有科技企业必须认识到系统的可靠性不是靠“英雄”在深夜里抢修出来的，而是靠稳健者在日常工作中一点一滴打磨出来的。通过实施错误预算、混沌工程和正确的激励机制，企业可以将“慢就是稳，稳就是快”从一句空洞的口号转变为免受熵增侵蚀的坚固盾牌。我们无法杜绝所有错误，但我们可以设计出能够包容错误、在错误中生存的系统。
在这个高度互联的数字世界里，慢下来的勇气，比盲目裸奔的速度更值得赞赏。
～～～～～～～～～～
老万近期文章：
～～～～～～～～～～
关注老万故事会公众号：
码字不易，呕心沥血只是希望更多人看到。如果喜欢这篇文章，请不吝三连。谢谢！🙏