2025年趨勢QA三週年1｜數十億美元的代價：BLP專案如何化危機為轉機？｜貢獻

面對2024年震驚全球的 CrowdStrike 大規模藍屏事件，我推動 BLP 專案實踐「自動防禦」。藉由分級測試與自動化測試抓出多項嚴重的 Bug，守住產品品質；在技術攻堅上，我運用 WinDBG 深入 Kernel 層級，成功排除驅動程式 Bug；同時透過「預判性資訊打包」優化台加跨國協作，大幅降低溝通成本。

快速文章連結：

  1. 2025年趨勢QA三週年1｜數十億美元的代價：BLP專案如何化危機為轉機？｜貢獻


一、三周年貢獻（2025/1 ~ 2025/12）

  1. 2025-01-15 Windows Server 2025
  2. 2025-01-xx 差點讓驗證停擺：自動化測試框架網路不穩
  3. 2025-03-12 The dsa_scan command now includes a scanLargeFile option for managing larger files.
  4. 2025-04-16 PowerPoint sometimes crashed when the system was waking up from hibernate. 
  5. 2025-04-xx Anti exploit
  6. 2025-06-xx 從數十億美元的教訓到自動防禦：BSoD Loop Prevention (BLP) 專案大幅降低系統崩潰的營運風險
  7. 2025-07-xx quarantined files API
  8. 2025-10-xx AMPPL AMSP
  9. 2025-11-03 帶新人


（一）從數十億美元的教訓到自動防禦：BSoD Loop Prevention (BLP) 專案大幅降低系統崩潰的營運風險

1. 2024 年震驚全球的 CrowdStrike 大規模藍屏當機（BSoD）事件

BSoD Loop Prevention (BLP) 專案的誕生，源於 2024 年震驚全球的 CrowdStrike 大規模藍屏當機（BSoD）事件。

2024 年 7 月 19 日，美國網路安全公司 CrowdStrike 發布了一次異常更新，導致全球大量執行 Windows 系統的電腦在更新後立即崩潰，陷入無限重啟循環（Boot Loop）。微軟初步估計受影響裝置約 850 萬台，造成的經濟損失高達數十億美元，CrowdStrike 的市值也在兩週內蒸發了約 36%（約 300 億美元）。

此次事件的災難性在於「修復過程」極度依賴人工。由於異常更新導致系統一開機即崩潰，維運人員無法進行遠端修復，必須逐一親臨現場登入機器，進入安全模式並手動刪除有問題的驅動程式（Driver）檔案。

CrowdStrike 在後續的根本原因分析（RCA）報告中提出了三大改善方針：

  1. 分階段部署：不再全球同步推送，改採從小範圍測試逐步擴大。
  2. 強化測試機制：加強內容更新的邏輯測試與錯誤處理，而非僅針對傳感器（Sensor）程式碼。
  3. 客戶控制權：允許客戶自定義更新時程，取消強制自動更新。

2. BSoD Loop Prevention (BLP)專案

事實上，CrowdStrike 提出的改善機制，在趨勢科技內部早有類似實踐。我們產品會經歷 Development > Integration > Dogfood > Bearfood > Production 等層層驗證，確保最新版本抵達客戶端前已在內部環境測試 2-3 週。

儘管如此，CrowdStrike 事件讓我們意識到，阻斷 BSoD 循環是遠端修復的關鍵。BLP 專案應運而生：此功能允許使用者設定閾值，當系統發生N次 BSoD 後，將停止載入特定的驅動程式，從而避免第N+1次崩潰，為遠端修復爭取空間。

3. BLP 專案開發挑戰與 Bug 排查

BLP 是 2025 年 DSA Q2 的重點專案。考量到主要客戶群的差異（A1 以 Desktop 為主，DSA 以 Server 為主），我們採取先在 2025年1月發布於A1，再於2025年7月推向 DSA 的策略。

在 AMSP 整合階段，儘管 BLP 功能在 A1 上已通過驗證，但在 DSA 的整合測試中，我們仍發現了 5 個 AMSP 整合問題與 3 個驅動程式問題。這導致原定 1 個月的驗證期延長至 2.5 個月。其中最棘手的問題包括：

  1. 路徑問題：驅動程式在比對 Windows 系統路徑時因「大小寫敏感（Case-sensitive）」導致 AM 無法啟動。此嚴重故障在分階段部署初期被成功攔截。
  2. 邏輯缺陷：包含在特定操作下 E-driver 的失敗計數無法清除，以及關閉 BLP 後 U-driver 計數未重置的問題。
  3. 檔案類型誤判：新的模組在舊版 OS 會將 PE 檔案誤認為 non-PE 檔案，RD 耗時一個月才完成底層流程改寫。

這次擷取驅動程式 Bug 的 log 極具挑戰，因為 BLP 涉及 BSoD 過程，一般的 User Mode Log 往往因系統崩潰來不及寫入硬碟。最終我們動用了 WinDBG Live Debug 進行 Kernel Debugging，才成功錄製到關鍵的 DSoD 資料。

4. 優化專案策略與跨國協作

在本次專案中，我採取了以下策略來提升測試效率：

  1. 自動化測試優先：優先執行功能與效能自動化測試，確保新功能不影響既有的系統穩定性。
  2. 深挖設計文件：透過閱讀 RD 的設計細節，找出潛在的邊界案例（Edge Cases）並轉化為測試案例。
  3. Log 導向驗證：觀察 Code Change 中新增的 Log 節點，協助 QA 快速理解流程並精準定位錯誤。
  4. 分級測試與問題清單：依照功能分項目，再依項目分基礎（P1）與進階（P2），先廣測廣再深測，先測基礎再測進階。優先解決阻礙發布的 P1 Bug，並透過 Issue List 向主管清晰匯報進度與瓶頸。

針對與加拿大團隊的跨國非同步協作，我的策略是：

  1. 預判性資訊打包：提供 Log 時預先回答 RD 可能提出的疑問，減少因時差造成的溝通往返。
  2. 把握黃金重疊時間：利用台加雙方重疊的 1-2 小時進行決策與交接，而非進行收 Log 等作業。

5. 未來改進方向

針對本次排查 Log 的痛點，未來我計畫在以下面向進行優化：

  1. 精準判斷 Bug 層級：若遇系統當機，直接啟動 Kernel Debugging 或分析 Full Memory Dump，跳過無效的 User Mode 日誌擷取。
  2. 優化測試環境配置：將本次建立 VMware 與 WinDBG Kernel Debugging 環境的經驗標準化，縮短環境建置時間。
  3. 深化調試技能：持續精進 WinDBG 指令，提升對 Module 加載與 Stack 分析的熟練度。


相關文章

  1. 跨科仔準備與分析中山資工所的過程
  2. 從生科轉資工的初期過程｜十個問答
  3. 生科轉資工1：一年表現狀況
  4. 生科轉資工2：二年表現狀況1
  5. 生科轉資工2：二年表現狀況2
  6. 最長共同近乎波動子序列問題 1
  7. 最長共同近乎波動子序列問題 2
  8. 生科轉資工3：入職趨勢一週年1
  9. 生科轉資工3：入職趨勢一週年2
  10. 生科轉資工4：2024入職趨勢二週年1｜貢獻
  11. 生科轉資工4：2024入職趨勢二週年2｜貢獻
  12. 生科轉資工4：2024入職趨勢二週年3｜成長與展望
  13. 2025年趨勢QA三週年1｜數十億美元的代價：BLP專案如何化危機為轉機？｜貢獻


縮寫名詞解釋

  1. A1 (Apex One)：友隊維護的防毒產品
  2. AM (Anti-Malware)：反惡意軟體
  3. BLP (BSoD Loop Prevention )
  4. DSA (Deep Security Agent)：我們團隊維護的防毒產品
  5. QA (Quality Assurance)：測試工作
  6. RCA (Root Cause Analysis)：根本原因分析
  7. RD (Research and Development)：開發工作

參考資料

留言

張貼留言