850 万台电脑瘫痪的那一天：CrowdStrike 宕机事件教会我如何打造“不会崩溃”的软件
我当时正坐在海得拉巴一家酒店的大堂里，手机突然开始震动个不停。不是平常那种零星的 Slack 通知——而是铺天盖地的洪流。一家客户的整个 Windows 机器群全都蓝屏了。接着是另一家客户。然后新闻爆出：机场航班停飞，医院取消手术，银行冻结交易。而这一切，都源于 CrowdStrike 推送的一个更新文件，它比你随手拍的午餐照片还要小。
2024 年 7 月 19 日。那一天，大约 850 万台 Windows 系统 同时崩溃，陷入蓝屏死机。那一天最终给全球经济造成了超过 100 亿美元的损失。也正是那一天，我开始痴迷于一个至今仍让我夜不能寐的问题：为什么我们要把人类历史上最关键的系统，建立在一个配置文件就能摧毁的地基之上？
我经营着 Veriprajna，一家人工智能咨询公司。我们打造的是我所说的“深度 AI”解决方案——与核心基础设施深度集成的系统，而不是当下市场上泛滥的那种单薄的 ChatGPT 套壳。当 CrowdStrike 宕机事件发生时，AI 行业有一半的人只是耸耸肩。他们说：“这是安全问题，不归我们管。”但我看到的却不一样。我看到的是那种一模一样的架构脆弱性——它困扰着每一家急于把 AI 硬塞进自身运营、却完全不了解底层究竟发生了什么的企业。
宕机事件之后，我花了好几个月剖析根本原因分析报告、追踪达美航空的诉讼案，并研究形式化验证领域正在兴起的研究成果。我的发现改变了我们团队构建一切的方式。我在这里撰写了一份对完整分析的全面互动式拆解，但这篇文章讲的是研究背后的故事——那些无法整齐地塞进白皮书的部分。
一个比 JPEG 还小的文件，让全球航空业陷入瘫痪
下面就是真正发生的事情，去掉了那些行话。
CrowdStrike 的 Falcon 安全平台运行在 Windows 内核内部——那是操作系统最深、权限最高的一层。你可以把它想象成一艘船的机舱。如果甲板上出了问题，你还能修好。但如果机舱里出了问题，整艘船就会沉没。
为了快速检测新威胁，CrowdStrike 构建了一套名为“快速响应内容”（Rapid Response Content）的系统。他们不推送完整的软件更新（那样又慢又需要测试），而是推送小小的配置文件——本质上就是一张张指令表，告诉安全引擎要去寻找哪些模式。这很聪明。但正如我们后来所了解到的，它也危险得可怕。
那天早上，两套新的指令集被部署下去，用于检测一种特定类型的进程间通信。这些指令引用了 21 个输入参数。问题出在哪？运行在每个端点上的引擎——即在内核中实际执行的代码——只理解 20 个参数。
云端说“读取 21 个字段”。内核却只知道 20 个。正是这个不匹配，让 850 万台电脑崩溃了。
云端的验证器批准了这次更新，因为 它对该模板的定义包含 21 个字段。它是在对照自己的预期进行检查，而不是对照端点实际能处理什么的现实。当内核级解释器试图访问那第 21 个字段时，它读取到了已分配内存的边界之外。在内核空间里，这不是一个可恢复的错误。而是瞬间崩溃。蓝屏。重启。再崩溃。重启。再崩溃。一个无限的死亡循环。
几周后的一次晚餐上，我向一位没有技术背景的投资人解释这件事。他盯着我说：“所以你是在告诉我，居然没有人测试过接收更新的那个东西，到底能不能真正 处理这个更新？”我点了点头。他放下了叉子。“那不是软件 bug。那是玩忽职守。”
他没说错。而佐治亚州的一位法官，实质上也会同意他的看法。
为什么 4 万台服务器必须靠人工逐台修复
这个故事里没有得到足够关注的部分，是恢复过程——或者更确切地说，是远程恢复的不可能性。
这里有个残酷的讽刺：CrowdStrike 代理正是那个从云端接收命令的东西。“回滚这次更新。”“应用这个修复。”但崩溃发生在启动序列的极早阶段，代理根本还没来得及初始化。那个本应接收救援信号的软件，恰恰就是导致其“溺水”的元凶。
我的团队开始把这叫做“死代理”问题。每一台受影响的机器都成了孤儿。它无法回连总部。它无法接收指令。唯一的修复办法，就是逐台把机器物理启动进安全模式，导航到 C:\Windows\System32\drivers\CrowdStrike\ 目录，然后手动删除那个有问题的文件。
对达美航空来说，这意味着要逐一处理大约 4 万台服务器 以及数千台工作站。全靠人工。一台接一台。
我以前管理过 IT 恢复行动，那种规模的后勤工作几乎难以想象。你需要物理接触那些可能锁在不同城市服务器机房里的机器。你需要懂得如何启动进安全模式的技术人员——而在 BitLocker 加密盛行的时代，这往往需要恢复密钥，可这些密钥却存储在……其他同样崩溃了的服务器上。真是一环套一环，没完没了。
达美的竞争对手——美国航空、联合航空——在一到三天内就恢复了。达美的中断却持续了 五天以上，并造成了超过 7000 个航班被取消 以及 5.5 亿美元的损失。区别在哪？达美的机组追踪系统——那套告诉航空公司飞行员和空乘身在何处、何时可以待命的软件——几乎完全运行在 Windows 上。当那些服务器宕机时，达美失去的不只是电脑。他们失去了掌握自己员工在哪里的能力。
当一个软件 bug 变成“重大过失”时会发生什么？
故事在这里从服务器机房转向了法庭，而我认为这里的影响才真正具有改变整个行业的意义。
达美起诉了 CrowdStrike。这本身并不令人意外——公司在遭遇重大故障后起诉供应商是常有的事。真正令人意外的，是 法官允许哪些主张继续推进。
从历史上看，软件供应商一直受到自己合同的保护。深埋在服务条款里的，总有一条责任上限——通常限定在客户为订阅所支付的金额之内。这是一种舒服的安排。你卖出的软件运行在客户基础设施的最深层，而如果它摧毁了一切，你的最大风险敞口也不过是十二个月的许可费。
2025 年 5 月，富尔顿县高等法院的法官 Kelly Lee Ellerbe 拒绝驳回达美关于 重大过失 以及——正是这一条让我一下子坐直了身子——计算机侵入 的主张。
重大过失的论点很直白：CrowdStrike 把这次更新同时推送给了全部 850 万台系统。没有分阶段发布。没有金丝雀部署。没有“我们先在 1% 的机器上试一试，看看会发生什么”。达美的律师主张，这构成了对已知风险的有意漠视。CrowdStrike 自己的事后报告也承认，内容验证器存在一个逻辑错误，而内容解释器缺少运行时边界检查。
但计算机侵入这项主张，才是每一家读到这里的 SaaS 供应商都该感到恐惧的。达美已经在其设置中 选择退出了自动更新。CrowdStrike 却仍然通过内核级通道文件机制推送了这次更新。法官裁定，关于计算机侵入的法定义务独立于订阅协议——这意味着合同中的责任上限并不适用。
当一家供应商无视你明确表达的偏好，把代码强行推入你的内核时，合同里的责任上限可能保护不了他们。这就是全新的法律现实。
自这项裁决以来，我已经与三位不同的首席信息安全官（CISO）交谈过，他们每一个人都说了同样的话：“我们正在重写供应商协议。”对来自安全供应商的自动更新无限信任的时代，已经结束了。
与 AI 行业令人不安的相似之处
现在我要直言不讳了，而我在 AI 领域的一些同行，可能不会喜欢我接下来要说的话。
AI 行业正建立在 CrowdStrike 所暴露出的那种同样脆弱的地基之上。我们只不过做得更快，也炒作得更凶。
如今的市场，由我所说的“LLM 套壳”主导——那是些单薄的应用层，向 GPT-4 或 Claude 发起 API 调用，把响应包裹进一个漂亮的界面，然后就把它称作一款 AI 产品。我见过一些公司的路演材料，它们整个技术架构说白了就是“我们向 OpenAI 发送一个提示词，然后显示返回结果”。这些公司的估值高达数千万美元。
去年我在一场会议上，一位创始人自豪地演示了他们的“AI 驱动的安全分析工具”。我问了一个简单的问题：“如果 OpenAI 更改了他们的 API、把价格涨了 10 倍，或者宕机六个小时，会怎么样？”他看着我的样子，就好像我在问如果重力停止作用会怎么样一样。他说：“那不会发生。”
它会发生。它总会发生。CrowdStrike 宕机事件证明了，即便是最受信任的基础设施供应商——那些你把整个运营都押注其上的供应商——也可能推送一个坏文件，就让一切崩塌。
这正是我们围绕我所说的“深度 AI”来打造 Veriprajna 的原因——我想精确地说明我指的是什么，因为这个词经常被随意乱用。
深度 AI 解决方案不会向单一的第三方供应商租用它的智能。它采用混合架构——专用的小型语言模型、视觉语言模型、图神经网络——在用例需要时部署在客户自己的基础设施上。它在系统层面集成，而不是在界面层面。而且至关重要的是，它使用 形式化验证 来对其行为提供数学上的保证，而不仅仅是概率性的最佳猜测。
这个区别很重要。一个 LLM 套壳给你的是一个通常正确的聊天机器人。而一个深度 AI 系统给你的是一个引擎，它对于所设计执行的特定任务而言，是 可证明 正确的。
为什么我开始痴迷于形式化验证
老实说：在 CrowdStrike 宕机事件之前，我一直以为形式化验证只是一种学术上的猎奇。是研究人员发表论文、却没人在生产环境中使用的东西。seL4 微内核——一个经过形式化验证的操作系统内核——固然令人印象深刻，但看起来像是一次性的成就，需要多年博士级别的努力。
然后我第三次读了 CrowdStrike 的根本原因分析，某个念头一下子通了。
整场灾难归根结底，就在于一个 语义鸿沟。云端验证器认为模板有 21 个字段。端点解释器认为它有 20 个。同一个系统的两个组件，对现实持有相互矛盾的信念，而没有人发现这一点，因为并不存在一个共享的、数学上严谨的规范，让两个组件都对照它进行验证。
形式化验证消除了语义鸿沟。它使用数学证明来确保软件——即实际的实现——始终满足其规范。不是“通常”。不是“在我们的测试中”。始终。如果证明成立，软件就不可能违反其规范。就是这样。
去年我的团队花了好几周时间，试验一个名为 VeCoGen 的框架，它把大型语言模型与形式化验证引擎结合起来，自动生成经过验证的 C 代码。LLM 提出候选实现，而一个证明检查器会在任何东西被部署之前，从数学上确认其正确性。如果代码有 bug——哪怕是像数组边界上的差一错误这样细微的问题——证明也会失败，代码就会被拒绝。
我还记得我们第一次在一个不那么简单的例子上让它跑通的时候。我的首席工程师此前一直对整件事持怀疑态度，他看着那份经过验证的输出说：“所以是 AI 写代码，同时还写出证明代码正确的证明？”是的。而且证明检查器是一个独立的、可信的系统，它并不在意 AI 有多自信——它只在意数学上的真相。
我们正在进入这样一个时代：AI 生成的代码将比手工编写的代码更受青睐——不是因为 AI 更聪明，而是因为 AI 能够在给出实现的同时，一并生成数学证明。
Martin Kleppmann 最近做出了这个预测，我认为他说得完全正确。“证明检查器”成了守门人。没有证明，就不部署。这与 CrowdStrike 的模式恰恰相反——在那种模式里，验证器本质上是在基于自己的假设给更新盖章放行。
关于形式化验证、预测性遥测和主权 AI 架构如何协同工作的完整技术拆解，请参阅我们的研究论文。
如果系统本可以自我修复呢？
关于 7 月 19 日，有一个细节一直萦绕在我心头。崩溃在全球范围内、横跨全部 850 万个端点同时发生，是因为并不存在一种自动化机制，能实时检测到这种故障模式并叫停发布。
想想看。数百万台机器同时开始崩溃。遥测信号是存在的——越界内存读取、即时的内核崩溃、启动循环。但没有任何系统在以一种能触发自动断路开关的方式监视这些信号。
这正是 AI 驱动的遥测所要解决的问题。传统监控依靠静态规则运作：“如果 CPU 使用率超过 90% 就告警。”那就好比装了一个烟雾报警器，却要等到房子已经被大火吞没才响。你真正需要的，是一个能在细粒度层面理解“正常”是什么样子、并能检测到偏离最初那几微秒的系统。
我们一直在构建研究界所称的 AI 驱动遥测分析，即 AITA 框架。它们使用无监督机器学习——孤立森林、自动编码器、基于密度的聚类——为系统组件建立行为基线。近期研究的结果令人瞩目：异常检测的平均时间缩短了 35%、误报减少了 40%，异常检测准确率达到 97.5% 的精确率和 96.2% 的召回率。
在 CrowdStrike 的场景中，一个启用了 AITA 的系统本可以在更新被应用的最初几毫秒内，就检测到这次越界读取是对基线行为的偏离。它本可以触发一个本地断路开关——隔离出问题的驱动程序、回滚到上一个已知良好的配置——赶在崩溃级联蔓延之前。不是在 850 万台机器倒下之后。而是在 第二台机器倒下之前。
我们谈的不是科幻。我们谈的是那些已经存在于研究之中、正在走向生产的系统。问题不在于企业是否会采用自我修复架构。而在于它们是会在下一次全球级联之前采用，还是之后。
你到底该如何为这样的未来做准备？
人们总会用某种版本的说法问我：“好，我被说服了，这确实重要。但我的公司没法把一切都推倒重来。我们该从哪里开始？”
问得好。以下就是我在为此忙碌了一年之后所得出的想法。
第一，审计一下你的内核里正在运行什么。 大多数企业根本不知道有多少第三方代理正运行在 Ring 0——也就是权限最深的那一层。那些代理中的每一个，都是一个潜在的 CrowdStrike 式风险。要求任何运行在内核级别的供应商提供证据，证明其具备分阶段发布流程、在云端验证器与端点解释器之间的模式版本管理，以及启动循环模拟测试。如果他们提供不出来，那就是对他们工程严谨程度的答案。
第二，别再把 AI 当作一个界面层。 如果你的“AI 战略”是一堆 LLM 套壳工具，而它们全都依赖同样的那两三个模型供应商，那你就存在一种集中度风险，它正是 CrowdStrike 依赖问题的翻版。开始为你最关键的工作流构建或收购运行在你自己基础设施上的专用模型。这才是 AI 主权在实践中的含义——不是一种意识形态，而是运营层面的韧性。
第三，把形式化验证变成一项采购要求，而不是一个研究愿景。 这些工具如今已经存在。VeCoGen 及类似框架正让大规模生成经过验证的代码成为可能。对于任何安全关键组件——任何触及内核、处理金融交易或做出医疗决策的组件——都要求提供正确性的数学证明，而不只是测试覆盖率的百分比。
关于最后这一点，我曾和一位潜在客户争论过。他说：“你这是在要求我们放慢部署流水线。”我说：“CrowdStrike 的部署流水线可是非常快。它在几分钟内就把一个有问题的更新推送给了 850 万台机器。速度不是问题。没有验证的速度才是问题。”
他签了合同。
改变一切的判例
以下就是我认为科技界大多数人在 Delta 诉 CrowdStrike 案上所忽略的东西。
重大过失的裁决，不只是关乎一家航空公司和一家安全供应商。它正在为自动化软件更新确立一套全新的 注意义务标准。当一位法官表示，未经分阶段发布就把未经测试的代码推送给数百万台机器可能构成重大过失时，这适用于每一家做着同样事情的供应商。当一位法官表示，无视客户的更新偏好、把内核级代码强行推送出去，可能构成独立于合同的计算机侵入时，这就为每一家带有自动更新机制的 SaaS 公司改写了规则。
今天的“重大过失”，将会成为明天的 基准预期。分阶段发布、形式化验证、运行时边界检查、自我修复遥测——这些已经不再是竞争优势了。它们是法院和监管机构将会要求的最低标准。
而这里有一件既让我兴奋、又让我恐惧的事：AI 行业即将面对同样的清算。眼下，大多数 AI 系统以概率方式运作——它们“通常正确”，而当它们错了的时候，我们耸耸肩，把它称作一次幻觉。但随着 AI 更深地进入关键基础设施——管理电网、批准医疗方案、执行金融交易——“通常正确”所承载的法律分量，将与“我们在把更新推送给 850 万台机器之前没有测试它”别无二致。
CrowdStrike 宕机事件所付出的 100 亿美元代价，并不是一个 bug 的价钱。它是一次全球性升级的首付款——升级的是我们构建和验证软件的方式。
那些理解这一点的公司——那些现在就投资于深度 AI、形式化验证和主权架构的公司——不仅将避开下一场灾难。它们还将定义那个标准，而灾难发生之后，其他所有人都将手忙脚乱地去追赶。
我知道自己想站在那道分界线的哪一边。问题在于，你会在下一个 7 月 19 日之前做出选择，还是在那之后。
