850 萬台電腦癱瘓的那一天——以及它教會我如何打造「不會故障」的軟體
當我坐在海得拉巴一家飯店大廳時，我的手機開始震動個不停。這不是平常零星的 Slack 通知——而是排山倒海而來。一位客戶整批 Windows 機器全都變成藍屏。接著又是另一位客戶。然後新聞爆出來了：機場停飛班機、醫院取消手術、銀行凍結交易。這一切只因為 CrowdStrike 推送的一個檔案更新，那檔案比你替午餐拍的照片還要小。
2024 年 7 月 19 日。那一天，大約有 850 萬台 Windows 系統同時墜入死亡藍屏。那一天最終讓全球經濟付出超過 100 億美元的損失。也是那一天，我開始執著於一個至今仍讓我夜不能寐的問題：為什麼我們要把人類史上最關鍵的系統，建立在一個能被組態設定檔摧毀的地基之上？
我經營 Veriprajna，一家 AI 顧問公司。我們打造我稱之為「深度 AI」的解決方案——這些系統與核心基礎設施整合，而不是當前市場上充斥的那些單薄的 ChatGPT 外殼。當 CrowdStrike 當機事件發生時，半個 AI 產業只是聳聳肩。「這是資安問題，」他們說。「不是我們的領域。」但我看到的卻不一樣。我看到的是同樣的架構脆弱性，正是它困擾著每一家急著把 AI 硬拴到自身營運上、卻完全不了解底層在發生什麼的企業。
當機事件過後，我花了好幾個月拆解根本原因分析、追蹤達美航空的訴訟案，並研究新興的形式化驗證研究。我所發現的，改變了我的團隊建構一切事物的方式。我在此撰寫了一份完整的互動式全面分析解讀，但這篇文章寫的是研究背後的故事——那些無法整齊放進白皮書裡的部分。
一個比 JPEG 還小的檔案，癱瘓了全球航空
以下是實際發生的經過，剝除了所有術語。
CrowdStrike 的 Falcon 資安平台運行在 Windows 核心（kernel）內部——那是作業系統最深、權限最高的一層。可以把它想成一艘船的機艙。如果甲板上出了問題，你可以修好它。但如果機艙裡出了問題，整艘船就會沉沒。
為了快速偵測新的威脅，CrowdStrike 建立了一套稱為「Rapid Response Content（快速回應內容）」的系統。他們不推送完整的軟體更新（那既緩慢又需要測試），而是推送小型組態設定檔——基本上就是一份份指令表，告訴資安引擎要尋找哪些模式。這很聰明。但正如我們所學到的，這也危險得令人膽寒。
就在那天早上，兩組新的指令集被部署出去，用於偵測某種特定類型的行程間通訊。這些指令引用了 21 個輸入參數。問題在哪？運行在每一個端點上的引擎——那段實際在核心中執行的程式碼——只認得 20 個參數。
雲端說「讀取 21 個欄位」。核心卻只知道 20 個。那個不匹配，讓 850 萬台電腦當機。
雲端的驗證器批准了這次更新，因為它對於範本的定義包含了 21 個欄位。它是在對照自己的預期進行檢查，而不是對照端點實際能處理的真實情況。當核心層級的解譯器試圖存取那第 21 個欄位時，它讀取到了配置記憶體邊界之外的地方。在核心空間裡，那不是一個可以復原的錯誤。那是一次即時當機。藍屏。重開機。再次當機。重開機。再次當機。一個無限的死亡迴圈。
我記得幾週後的一場晚餐上，我向一位非技術背景的投資人解釋這件事。他盯著我說：「所以你是在告訴我，沒有任何人測試過那個接收更新的東西是否真的能處理這個更新？」我點了點頭。他放下叉子。「那不是軟體 bug。那是失職。」
他沒說錯。而喬治亞州的一位法官，基本上也會同意他的看法。
為什麼 4 萬台伺服器必須靠人力逐一修復
這個故事中沒有得到足夠關注的部分，是復原——或者更準確地說，是遠端復原的不可能。
這裡有個殘酷的諷刺：CrowdStrike 代理程式正是那個從雲端接收指令的東西。「回復這個更新。」「套用這個修補。」但當機發生得太早，就在開機序列的極早期，以致代理程式從未初始化。原本應該負責接收救援訊號的軟體，正是導致溺水的元凶本身。
我的團隊開始把這稱為「死亡代理程式（Dead Agent）」問題。每一台受影響的機器都成了孤兒。它無法回報家中。它無法接收指令。唯一的修復方法，就是實際地把每台機器開機進入安全模式，導覽到 C:\Windows\System32\drivers\CrowdStrike\，然後手動刪除那個有問題的檔案。
對達美航空來說，那意味著要動手處理大約 4 萬台伺服器以及數千台工作站。全靠人力。一次一台。
我以前管理過 IT 復原作業，而那種規模的後勤幾乎難以想像。你需要實體接觸那些可能鎖在不同城市機房裡的機器。你需要懂得如何開機進入安全模式的技術人員——而在 BitLocker 加密的時代，這往往需要復原金鑰，而那些金鑰卻儲存在……其他同樣也當機了的伺服器上。這根本是一環套一環、無窮無盡。
達美的競爭對手——美國航空、聯合航空——在一到三天內就復原了。達美的中斷持續了 超過五天，並造成超過 7,000 個航班取消，以及 5.5 億美元的損失。差別在哪？達美的機組追蹤系統，也就是那套告訴航空公司飛行員與空服員身在何處、何時可以出勤的軟體，幾乎完全跑在 Windows 上。當那些伺服器死掉時，達美失去的不只是電腦。他們失去了得知自己員工身在何處的能力。
當一個軟體 bug 變成「重大過失」時，會發生什麼事？
故事在這裡從機房轉場到法庭，而我認為其中的影響真正足以改變整個產業。
達美控告了 CrowdStrike。單就這一點並不令人意外——企業在重大失誤後控告供應商是常有的事。真正令人意外的，是法官准許哪些主張得以繼續審理。
從歷史上看，軟體供應商一直受到自家合約的保護。埋藏在服務條款裡的，永遠有一條責任上限——通常限制在客戶為訂閱所支付的金額之內。這是個舒適的安排。你賣的軟體運行在客戶基礎設施的最深層，而如果它把一切都摧毀了，你的最大曝險也不過是十二個月的授權費。
2025 年 5 月，富爾頓郡高等法院的 Kelly Lee Ellerbe 法官拒絕駁回達美關於 重大過失，以及——這一項讓我猛然坐直了身子——電腦侵入（computer trespass）的主張。
重大過失的論點很直接：CrowdStrike 把更新同時推送給全部 850 萬台系統。沒有分階段部署。沒有金絲雀部署。沒有「我們先在 1% 的機器上試試看會怎樣」。達美的律師主張，這代表對已知風險的一種明知故犯的漠視。CrowdStrike 自己的事後報告承認，內容驗證器（Content Validator）存在一個邏輯錯誤，而內容解譯器（Content Interpreter）缺少執行期的邊界檢查。
但電腦侵入的主張，才是應該讓每一位正在讀這篇文章的 SaaS 供應商膽戰心驚的那一個。達美在他們的設定中 選擇了關閉自動更新。CrowdStrike 仍然透過核心層級的頻道檔案（channel file）機制強行推送了這次更新。法官裁定，關於電腦侵入的法定義務獨立於訂閱協議之外——這意味著合約中的責任上限並不適用。
當一家供應商蓋過你明確表達的偏好、硬把程式碼推進你的核心時，合約中的責任上限可能無法保護他們。這就是全新的法律現實。
自這項裁決以來，我和三位不同的資安長談過，而他們每一個人都說了同樣的話：「我們正在重寫我們的供應商協議。」對資安供應商自動更新無限信任的時代，已經結束了。
與 AI 產業之間令人不安的對照
現在來到我要直言不諱的地方，也是我在 AI 圈的某些同儕不會喜歡我接下來要說的話的地方。
AI 產業正建立在 CrowdStrike 所暴露出來的同樣脆弱的地基之上。我們只是做得更快，而且伴隨著更多的炒作。
當前的市場被我稱之為「LLM 外殼」的東西所主導——那些單薄的應用層，向 GPT-4 或 Claude 發出 API 呼叫，把回應包裝進一個漂亮的 UI 裡，然後就把它稱作 AI 產品。我見過一些公司的簡報，它們的整套技術架構字面上就是「我們把一段提示詞送給 OpenAI，然後把結果顯示出來」。它們的估值高達數千萬美元。
去年我在一場研討會上，一位創辦人自豪地展示了他們「由 AI 驅動的資安分析工具」。我問了一個簡單的問題：「如果 OpenAI 更改他們的 API、把價格漲 10 倍，或是當機六個小時，會發生什麼事？」他看著我，彷彿我問的是如果地心引力停止作用會怎樣。「那不會發生的，」他說。
它會發生。它總是會發生。CrowdStrike 當機事件證明了，即使是最受信任的基礎設施供應商，那些你把整套營運全押在他們身上的供應商，也可能推送一個壞掉的檔案，把一切都搞垮。
這就是為什麼我們圍繞著我稱之為「深度 AI」的理念打造 Veriprajna——而我想精確地說明我的意思，因為這個詞常被隨意濫用。
一套深度 AI 解決方案不會向單一的第三方供應商租借它的智慧。它使用混合式架構——專門化的小型語言模型、視覺語言模型、圖神經網路——在使用情境有此需求時，部署在客戶自己的基礎設施上。它在系統層級整合，而非 UI 層級。而關鍵在於，它運用 形式化驗證來為其行為提供數學上的保證，而不僅僅是機率性的最佳猜測。
這個差別很重要。一個 LLM 外殼給你的是一個通常會答對的聊天機器人。一套深度 AI 系統給你的，是一具針對它被設計來執行的特定任務、可被 證明 為正確的引擎。
我為什麼開始執著於形式化驗證
老實說：在 CrowdStrike 當機事件之前，我以為形式化驗證是一種學術上的奇聞。是研究人員發表論文寫寫、卻沒有人在正式環境中使用的東西。seL4 微核心——一個經過形式化驗證的作業系統核心——確實令人印象深刻，但看起來像是一次性的成就，需要數年博士等級的努力。
接著我第三次讀了 CrowdStrike 的根本原因分析，然後某個環節突然通了。
整場災難歸結於一個 語意落差。雲端驗證器相信範本有 21 個欄位。端點解譯器相信它有 20 個。同一套系統中的兩個元件，對現實抱持著彼此矛盾的信念，而沒有人察覺，因為當時並不存在一份共同的、數學上嚴謹的規格，能讓兩個元件都對照它進行驗證。
形式化驗證消除語意落差。它運用數學證明，來確保軟體——那個實際的實作——永遠滿足它的規格。不是「通常」。不是「在我們的測試中」。永遠。如果證明通過，軟體就不可能違反它的規格。就這麼絕對。
去年我的團隊花了好幾週實驗一套名為 VeCoGen 的框架，它結合大型語言模型與形式化驗證引擎，來自動產生經過驗證的 C 程式碼。LLM 提出候選的實作，而一個證明檢查器會在任何東西被部署之前，用數學方式確認其正確性。如果程式碼有一個 bug——即使是像陣列邊界上的差一錯誤（off-by-one）這種細微的問題——證明就會失敗，程式碼也會被拒絕。
我記得我們第一次在一個非平凡的範例上把它跑通的時候。我的首席工程師，原本對整件事都抱持懷疑態度，看著那份經過驗證的輸出說：「所以是 AI 寫出程式碼，還有那份證明程式碼正確的證明？」是的。而且那個證明檢查器是一個獨立、受信任的系統，它不在乎 AI 有多少信心——它只在乎數學上的真理。
我們正邁入一個時代，在其中 AI 生成的程式碼將優先於手工打造的程式碼——不是因為 AI 更聰明，而是因為 AI 能夠在產生實作的同時，一併產生那份數學證明。
Martin Kleppmann 最近做出了這個預測，而我認為他完全說對了。「證明檢查器」成了守門人。沒有證明，就不能部署。這與 CrowdStrike 的模式恰恰相反，在那個模式裡，驗證器本質上是在基於它自己的假設，對更新蓋橡皮圖章式地放行。
若想完整了解形式化驗證、預測式遙測與主權 AI 架構如何協同運作的技術解讀，請參閱我們的研究論文。
如果這套系統本可以自我修復呢？
關於 7 月 19 日，有一個細節始終縈繞在我心頭。當機發生在全球範圍，橫跨全部 850 萬個端點，因為當時並不存在任何自動化機制，能即時偵測到那個失敗模式並中止推送。
想想看這件事。數百萬台機器同時開始當機。遙測訊號其實都在那裡——越界的記憶體讀取、立即的核心恐慌（kernel panic）、開機迴圈。但沒有任何系統以能觸發自動斷路開關的方式，在監看那些訊號。
這正是 AI 驅動的遙測所要解決的問題。傳統監控依循靜態規則運作：「若 CPU 使用率超過 90% 就發出警報。」那就像設置一個只有在房子已經被火吞沒時才會響的煙霧偵測器。你需要的，是一套能在細微顆粒度上理解「正常」長什麼樣子、並能偵測到偏離最初數微秒的系統。
我們一直在打造研究界所稱的「AI 驅動遙測分析」，也就是 AITA 框架。這些框架運用非監督式機器學習——孤立森林（isolation forests）、自動編碼器（autoencoders）、基於密度的分群——來為系統元件建立行為基準線。近期研究的成果十分驚人：偵測異常的平均時間縮短了 35%、誤報減少了 40%，而異常偵測的準確度達到 97.5% 的精確率與 96.2% 的召回率。
在 CrowdStrike 的情境中，一套具備 AITA 能力的系統，會在更新被套用後最初的幾毫秒之內，就偵測到那個越界讀取是偏離基準線行為的異常。它本可以觸發一個本地的斷路開關——隔離那個有問題的驅動程式、回復到最後一個已知正常的組態——搶在當機連鎖擴散之前完成。不是在 850 萬台機器倒下之後。而是在第二台機器倒下之前。
我們談的不是科幻小說。我們談的是那些已經存在於研究中、並正邁向正式環境的系統。問題不在於企業是否會採用自我修復架構。而在於他們會在下一次全球連鎖崩潰發生之前，還是之後才採用。
你究竟該如何為這個未來而打造？
人們總是用某種版本的話問我：「好吧，我被說服了，這確實很重要。但我的公司沒辦法把一切從頭重建。我們該從哪裡開始？」
這是個合理的問題。以下是經過一年在這件事上摸索之後，我的思考落腳之處。
第一，稽核你的核心裡正在運行什麼。大多數企業根本不知道有多少第三方代理程式正運行在 Ring 0——也就是最深的權限層級。那些代理程式的每一個，都是一個潛在的 CrowdStrike 式風險。要求任何在核心層級運作的供應商，提供其分階段推送程序、雲端驗證器與端點解譯器之間的結構描述版本管理（schema versioning），以及開機迴圈模擬測試的證據。如果他們拿不出來，那就是關於他們工程嚴謹度的答案了。
第二，別再把 AI 當成一個 UI 層來對待。如果你的「AI 策略」是一堆全都依賴同樣那兩三家模型供應商的 LLM 外殼工具，那你就有了一種與 CrowdStrike 依賴問題如出一轍的集中度風險。開始為你最關鍵的工作流程，建立或取得能在你自己基礎設施上運行的專門化模型。這就是 AI 主權在實務上的意義——不是意識形態，而是營運上的韌性。
第三，把形式化驗證變成一項採購要求，而非一種研究上的憧憬。這些工具現在就存在了。VeCoGen 以及類似的框架，正讓大規模產生經過驗證的程式碼成為可能。對於任何安全關鍵的元件——任何會觸及核心、處理金融交易，或做出醫療決策的東西——都要求提供數學上的正確性證明，而不只是測試覆蓋率的百分比。
關於最後這一點，我曾和一位潛在客戶起過爭執。他說：「你是在要求我們放慢部署管線。」我說：「CrowdStrike 的部署管線非常快。它在幾分鐘內就把一個有問題的更新推送到了 850 萬台機器上。速度不是問題。沒有驗證的速度才是問題。」
他簽了合約。
改變一切的判例
以下是我認為科技圈大多數人在達美訴 CrowdStrike 一案中所忽略的部分。
重大過失的裁決，不只關乎一家航空公司和一家資安供應商。它正在確立一套針對自動軟體更新的全新 注意義務標準。當一位法官表示，在沒有分階段推送的情況下，把未經測試的程式碼推送到數百萬台機器上，可能構成重大過失時，那就適用於每一家在做同樣事情的供應商。當一位法官表示，蓋過客戶的更新偏好、把核心層級的程式碼推送進去，可能構成獨立於合約之外的電腦侵入時，那就為每一家具備自動更新機制的 SaaS 公司改寫了遊戲規則。
今日的「重大過失」，將成為明日的 基本期望。分階段推送、形式化驗證、執行期邊界檢查、自我修復的遙測——這些不再是競爭優勢了。它們是法院與監管機構將會要求的最低標準。
而以下這件事讓我興奮，即便它同時也讓我心生恐懼：AI 產業即將面對這同一場清算。此時此刻，大多數 AI 系統都是機率性地運作——它們「通常會答對」，而當它們答錯時，我們就聳聳肩，把它稱作幻覺。但隨著 AI 更深入地進入關鍵基礎設施——管理電網、核准醫療處置、執行金融交易——「通常會答對」所承載的法律份量，將等同於「我們在把更新推送到 850 萬台機器之前，沒有先測試它」。
CrowdStrike 當機事件那 100 億美元的代價，並不是一個 bug 的價格。它是一筆頭期款，付給的是我們建構與驗證軟體方式的一次全球升級。
那些理解這一點的公司——那些現在就投資於深度 AI、形式化驗證與主權架構的公司——將不只是躲過下一場大災難。它們將定義出那個標準，讓其他所有人在災難發生之後，手忙腳亂地追趕。
我知道自己想站在那道分界線的哪一邊。問題是，你會在下一個 7 月 19 日之前做出選擇，還是在那之後。
