在管理全球規模的分散式資料庫系統時，硬體損耗、分片狀態異常或配置錯誤是不可避免的日常現象。對於像 Stripe 這樣規模的企業而言，挑戰不在於如何修復單一問題，而是在於如何在大規模環境下，避免維運工程師因處理無數重複且複雜的故障而陷入疲憊。根據 Stripe 工程團隊在官方部落格分享的經驗，他們將資料庫事故恢復流程從傳統的硬編碼腳本，轉向基於圖論圖搜索與狀態機的自動化修復體系，顯著降低了人力干預的需求。
傳統修復體系的瓶頸與挑戰
在導入新系統之前，Stripe 使用的是一套基於插件且硬編碼的修復系統。這種設計將恢復流程寫死在固定的工作流中，但在面對複雜的現實環境時顯現出明顯的侷限性。首先，基礎設施的依賴關係非常脆弱，且經常出現多重故障併發的複雜情境，導致原有的線性修復路徑失效。其次，MongoDB 的分片佈局（Shard Layout）具有多樣性，針對特定佈局撰寫的邏輯無法通用於其他配置。
最嚴重的問題在於中間狀態的處理。當系統處於某個未定義的過渡狀態時，自動化流程往往會卡死，必須由工程師手動介入。數據顯示，在一個六個月的觀察期內，控制平面因分片配置錯誤觸發了 124 次告警，單節點故障且伴隨其他健康問題的案例則有 32 次。這些事故平均導致索引建立或計畫維護等關鍵操作被阻塞約一小時。
以圖論建模實現動態恢復
為了突破硬編碼的限制，Stripe 將其全球 MongoDB 基礎設施建模為一個圖（Graph）。在這個模型中，節點（Node）代表基礎設施的組成元件，邊（Edge）定義了元件之間的關係，而節點的屬性則描述了該元件目前的健康狀態或配置狀態。
這種建模方式將修復邏輯從固定的步驟中解耦。系統不再執行預設的 A 到 B 到 C 流程，而是透過圖遍歷（Graph Traversal）來尋找從「目前故障狀態」到「健康狀態」的有效恢復路徑。這意味著無論資料庫的分片佈局如何演進或變動，只要圖模型能正確反映當前狀態，系統就能動態計算出適合該環境的修復計畫。
從廣度優先搜索到 Dijkstra 算法的演進
在實現路徑尋找的過程中，Stripe 最初採用的是廣度優先搜索（Breadth-First Search, BFS），旨在找到最簡單的恢復路徑。然而，為了進一步優化，團隊隨後導入了 Dijkstra 算法。Dijkstra 算法是一種用於尋找加權圖中最短路徑的演算法，Stripe 利用它來優先選擇低成本的恢復方案，以減少不必要的基礎設施操作並確保正確性。
Dijkstra 算法的一個重要優勢在於，它會探索所有可達狀態的路徑，而非僅僅鎖定在最終目標狀態。這使得系統具備了「部分修復」的能力：當環境極其複雜，導致目前無法找到完全恢復到健康狀態的路徑時，算法能回傳一條通往「最接近健康狀態」或「配置錯誤最少狀態」的路徑，盡可能地緩解問題，而非完全失效。
狀態機與可組合規則的實務意義
除了圖搜索，Stripe 將修復操作定義為具有明確狀態轉移的可組合規則（Composable Rules）。這種設計將修復行為視為狀態機（State Machine）的轉移過程，而非僵硬的工作流。計畫器（Planner）可以根據基礎設施的即時演進，動態地將多個操作組合在一起。
這種模式的核心差異在於：傳統的運行手冊（Runbooks）是記錄已知故障的解決方案，而狀態機與圖搜索的組合則是讓系統去「發現」解決方案。對於管理複雜分散式系統的團隊來說，這提供了一種替代方案，不再需要隨著故障類型的增加而不斷累積繁瑣的維運手冊。
成效、限制與未來展望
這套自動化修復系統在實務上取得了顯著成效。它讓資料庫相關的分頁告警（Pager Alerts）減少了約 30%，每年減少約 200 次的人工干預，並消除了預計每年 12 天的分片不健康狀態。
目前該框架主要應用於故障恢復，但 Stripe 計畫將其擴展至更廣泛的領域，包括自動化拓撲結構變更、藍綠部署（Blue-Green Deployment，一種透過平行運行新舊版本來降低更新風險的部署策略），以及將計畫性維護與反應性修復進行統一編排。雖然這種方法大幅降低了維運壓力，但其成敗高度依賴於基礎設施圖模型的準確性以及狀態轉移規則的完備程度。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。