Meta 零通知斷電演習：Instantaneous PowerLoss Storm 測試體系與 Ouroboros 循環相依問題
Meta Engineering Blog · 2026-06-03
Meta 工程師 Raghu Prabhu 與 Richard Johnson 在 2026-06-03 發布文章，描述 Meta 如何建立「Instantaneous PowerLoss Storm」（即時斷電風暴）測試體系，驗證資料中心在零通知全站斷電後能夠自動恢復服務。文章揭露了控制面服務的循環相依問題（稱為「ouroboros risk」）及其解法。
原本的問題
傳統容錯設計假設服務可以優雅關閉（graceful shutdown）並在電力恢復後順序啟動。但即時斷電破壞此假設：所有服務同時失去電力，重啟時沒有先後順序保證。Meta 的容器調度系統 Twine 依賴 Scheduler、Allocator、Broker、Zelos 等控制面服務才能啟動容器，但這些控制面服務本身也是由 Twine 管理的容器——形成 ouroboros 死結：「需要 A 才能啟動 B，需要 B 才能啟動 A」。
另一個問題是 Boomerang 效應：電力恢復後，Power Loss Siren（PLS）廣播關機訊號，但這個訊號反過來停止了負責處理關機流程的 orchestrator 本身，導致關機流程無限卡住。
採用的方法
Meta 的解法分為三層：
- Twine recovery kit：建立一組最小化的 bootstrap 服務，在 Twine 控制面完全就緒前提供臨時調度能力，打破循環相依
- Belljar 測試：在 CI/CD pipeline 中注入模擬斷電條件，偵測任何新引入的啟動相依關係，防止 ouroboros 問題悄悄重現
- 關機訊號豁免：控制面服務被設定為忽略電源相關的關機訊號，避免 Boomerang 效應
實際效果
測試策略以漸進方式推進：預生產環境→影子（shadow）環境→最小生產環境→大型生產環境。定義可接受的風險邊界是設計的核心：允許暫時性服務錯誤與閾值內的機架失效，但不允許資料遺失、永久設施損壞或跨 region 影響。這個框架讓 Meta 得以在不暫停生產的前提下持續進行破壞性測試。
Linear 為何如此快速：瀏覽器端資料庫、MobX 細粒度訂閱與服務工作者預快取的完整技術解析
performance.dev · 2026-05-03
Dennis Brotzky 在 performance.dev 對 Linear（以高速著稱的專案管理 SaaS）進行完整的前端效能逆向分析，揭示其「瀏覽器優先資料庫」架構如何讓操作回應達到近乎即時的使用者感受。
採用的方法
Linear 最核心的設計決策是以 IndexedDB 為主要資料來源，伺服器為同步目標——而非傳統的「發請求、等回應、更新 UI」模式。所有操作以 Optimistic Update 方式先寫入本機 MobX store，再透過 WebSocket 非同步推送到伺服器；其他客戶端從 WebSocket 廣播接收 delta 增量更新。
狀態管理採用每屬性一個 MobX observable：更新 50 個 issue 的優先級只觸發 50 個 cell 重渲染，而非整個列表。命令面板（⌘K）搜尋的是本機 MobX 物件池，零網路延遲。
規格細節
- Bundle 策略：激進的路由級程式碼分割（數百個 chunk），只針對現代瀏覽器（esnext），移除 legacy polyfill
- Service Worker：登入時預快取約 1,200 個靜態資源，後續頁面載入幾乎全從快取提供
- Modulepreload：關鍵依賴路徑以
<link rel=modulepreload>平行預載，消除串行 fetch 瀑布流 - 認證假設：以 localStorage 存在為快樂路徑（happy path），立即渲染 UI，在背景非同步驗證 session 有效性
- 動畫原則：只動畫 composited 屬性（transform、opacity），持續時間控制在 100ms 以內，enter/exit 採用非對稱 timing
影響範圍
Linear 的架構代表了一類「local-first」應用的設計範式：資料常駐瀏覽器，網路只做同步。這種模式對離線能力與即時回應感有本質改善，但對資料衝突解析、多裝置同步一致性有更高要求。MobX 細粒度訂閱的模式也可在任何需要高密度互動表格（如 Airtable、Notion）的場景複用。