你已經建立了完美的可觀測性。你可以看到系統中發生的一切。告警立即觸發。然後——告警觸發的時刻——人類必須思考。他們必須記住手冊。他們必須執行命令。他們必須等待它們完成。他們必須驗證修復有效。他們必須在星期二凌晨 3 點做這件事。

這是運維的等價物，有菜譜但每次都從零開始烹飪。運行手冊自動化消除了這種浪費。你的團隊見過的每個故障模式、每個記錄的恢復程序、每個「只需重新啟動服務」的事件——這些都應該自動化。

運行手冊自動化不是關於替換工程師。它關於消除已解決問題的認知負擔，使工程時間可用於未解決的問題。當同樣三個服務每週失敗一次，你有一個記錄的恢復程序時，人類永遠不應該再執行那個程序。

成熟度階段

大多數組織在這個頻譜的某個地方：

  • 階段 0：已記錄的知識。 運行手冊存在，散落在 wiki、Confluence 或人們的腦海中。執行是手動且不一致的。
  • 階段 1：告警關聯 + 文檔。 當已知故障發生時，告警包括運行手冊的鏈接。執行仍然是手動的。
  • 階段 2：半自動化。 運行手冊變成一鍵修復。點擊按鈕執行執行恢復的腳本。但決策是人類的：「我應該點擊這個按鈕嗎？」
  • 階段 3：條件自動化。 系統在條件安全時自動執行修復。它檢查服務是否已處於已知壞狀態、人類是否已在調查、自動擴展是否可能解決問題。
  • 階段 4：預測自動化。 系統預測故障即將發生並在用戶注意到之前進行修復。

大多數成熟的運維存在於階段 2-3。階段 4 需要超出本層範圍的 AIOps 成熟度。目標是達到階段 3：安全、可觀測且仍受人類監督的自動化。

自動化修復的架構

檢測層：可觀測性信號

這是 Layer 0（可觀測性）與 Layer 1 集成的地方。你的 Prometheus 告警規則偵測已知的故障模式。你的 Grafana 儀表板顯示系統的狀態。你的 Kibana 日誌提供上下文。

為自動化設計的良好告警看起來像這樣：

alert: HighMemoryUsageInAuthService
  expr: container_memory_usage_bytes{service="auth"} > 800000000
  for: 2m
  annotations:
    summary: "Auth 服務記憶體使用量關鍵"
    runbook: "https://wiki/auth-service-oom-recovery"
    auto_remediation: "restart_service"
    severity: "critical"

注意：它指定不僅是條件，還有補救行動。這是自動化的觸發器。

決策層：安全檢查

在執行任何自動化修復之前，你必須回答：這安全嗎？這需要條件邏輯：

If (HighMemoryUsageInAuthService is true)
  AND (no ongoing incident investigation for auth)
  AND (at least 2 replicas of auth service healthy)
  AND (error rate would not exceed SLO threshold if we restart)
THEN execute restart_service

注意警衛。在以下情況下重新啟動服務：

  • 工程師已在調查 → 破壞調查
  • 只有一個複本健康 → 創建單一故障點
  • 會導致錯誤率激增 → 在試圖恢復的同時違反 SLO

這些警衛不是稍後添加的。它們必須從一開始就設計到自動化中。

執行層：安全、可觀測的修復

當條件滿足時，系統執行修復。這可能是：

  • Kubernetes 原生： kubectl rollout restart deployment/auth 或 pod 驅逐
  • 基於 Ansible： 執行執行服務重啟、快取清除或資料庫連接重置的 playbook
  • 自定義自動化： 呼叫觸發應用程度修復的 webhook
  • 基礎設施級別： 終止不健康的節點、重新平衡負載、添加容量

無論機制如何，執行必須是：

  • 已追蹤。 每個自動化行動都用完整上下文記錄：觸發了什麼、檢查了什麼條件、執行了什麼、結果是什麼。
  • 已監控。 執行修復後，系統立即檢查：它有效嗎？Prometheus 指標和日誌應顯示達到了期望的狀態。
  • 可逆轉。 如果修復使事情變得更糟，應該自動回滾或標記為立即人工審查。

常見陷阱

沒有可觀測性的運行手冊自動化。 如果你看不到什麼失敗了，你無法安全地自動化恢復。對看不見的故障的自動化響應是猜測。昂貴、快速的猜測。

對自動化的盲目信任。 每個運行手冊自動化都應包含人工審查步驟：「我們應該做過這個嗎？」如果修復每週執行 1000 次，其中大多數決定是正確的。但其中 100 個可能是錯的。進行抽查。將反饋建立到流程中。

修復級聯。 一個自動化行動觸發另一個。然後又觸發另一個。在你知道之前，整個系統正在執行一系列自動化決定，沒有人類能夠預測。限制自動化深度：更喜歡簡單的單一行動修復，而不是複雜的決策樹。

前進的道路

運行手冊自動化位於可觀測性和可靠性的交叉點。使用完美的可觀測性（Layer 0），你知道什麼時候出現問題。使用運行手冊自動化（Layer 1），你可以立即修復它。

下一層——SLO 作為控制迴圈——進一步進行。系統根據可靠性承諾自動控制其自身的行為，而不是響應個別故障。但這需要一個有效的自動化基礎。

大多數團隊直接從「我們有儀表板」跳到「我們想要完全自主性」。然後他們發現在沒有穩定的自動化基礎的情況下建立的自主性只是自動化混亂。

系列中的下一個

一旦你的已知故障是自動化的，下一步是 SLO 作為控制迴圈：使用可靠性承諾來自動控制部署、擴展和資源分配。閱讀 Layer 2。

在 AIDARIS，我們幫助團隊設計安全、可觀測且可維護的運行手冊自動化。如果你為運行手冊質量而掙扎或想知道如何安全地擴展自動化，讓我們談談。