大多數組織將 SLO（服務等級目標）視為報告機制：月末確認他們是否符合可靠性承諾的儀表板。這是倒退的。在成熟的自主運維中，SLO 不是報告——它們是活躍的控制信號，實時控制系統行為。

當你的錯誤預算消耗太快時，系統自動限制部署。當金絲雀部署開始降低你的 SLO 時，它自動回滾。當容量壓力會在下一小時內將延遲推過 SLO 閾值時，自動擴展會在超過閾值之前啟動。SLO 不是你在月底檢查的東西；它是系統實時捍衛的東西。

這需要改變你對 SLO 的思考方式。它們不是抱負目標。它們是系統必須尊重的運維約束。

SLO 作為首要原則

在你可以使用 SLO 作為控制信號之前，你必須正確定義它們。「正確」意味著根植於商業現實，而不是技術時尚。

問自己：

  • 為什麼是這個 SLO？ 如果你的回答是「每個人都做 99.99%」，你沒有考慮過。你的回答應該是「如果我們下降低於 99.95%，我們的客戶會流失，所以那是我們的 SLO。」
  • 如果我們達不到呢？ 如果達不到你的 SLO 成本為 $0，那它不是 SLO。它是猜測。真正的 SLO 有商業後果。
  • 我們能可靠地達到嗎？ 如果你的 SLO 需要 99.99% 可用性，但你的資料庫只有 99.95% 可用，你無法符合你的 SLO。約束在上游。

根植於首要原則的 SLO——業務實際需要什麼，基礎設施實際支持什麼——是有效的控制迴圈 SLO。

SLO 驅動控制的架構

測量 SLO：從 Prometheus 到 Grafana

SLO 由 SLI（服務等級指標）定義——你測量的實際指標。對於網站服務：

SLI: (successful requests) / (total requests)
SLO: SLI ≥ 99.95% over rolling 30-day window

在 Prometheus 中：

slo:request_success_rate:30d =
  99.95% 的請求成功（根據滾動 30 天窗口）

error_budget:available = 約 2160 分鐘允許失敗

error_budget:consumed = 已使用多少預算

error_budget:burn_rate = 消耗速度有多快

Grafana 視覺化這個。健康的 SLO 儀表板顯示：

  • 當前合規百分比（綠色如果≥99.95%，黃色如果有危險，紅色如果違反）
  • 剩餘錯誤預算（以當前消耗速率達到限制前的天數）
  • 消耗速率（你消耗預算的速度有多快）
  • 趨勢（消耗速率在加速還是減速）

控制迴圈：從 SLO 到行動

一旦你實時測量 SLO，你將它們饋入控制迴圈。決策點查詢當前 SLO 狀態並做出決定：

  • 我們可以部署嗎？
  • 我們應該擴展嗎？
  • 我們正在明智地花費錯誤預算嗎？

這不是人類每次做出判斷。這是編碼到系統中的政策，每分鐘查詢 Prometheus 並根據現實做出決定。

常見陷阱

基於錯誤對齐的 SLO 進行過度自動化。 如果你的 SLO 設定錯誤，基於它自動化只會加速錯誤的決定。根據 99.99% SLO 的部署節流，當你的業務需要 99% 時，將阻止太多部署並傷害速度，而不是獲得安全。

沒有人工覆蓋。 一些情況需要人類判斷：「是的，我知道錯誤預算很緊，但這個部署對客户保留至關重要。」建立明確的覆蓋機制，使人類可以做出有意、記錄的決定。

忽視 SLO 漂移。 3 年前設定的 SLO 可能不反映當前的商業需求。每年審查它們。如果你的系統一直超額達成其 SLO，稍微降低它（對相同商業成果使用更少昂貴的基礎設施）。

成熟度飛躍

SLO 驅動的控制迴圈代表操作成熟度的顯著飛躍。它是在以下之間的區別：

  • 被動： 「出了問題，人類修復它」
  • 自主： 「系統根據可靠性承諾自主運行」

達到這一點的組織報告戲劇性的轉變：部署更快發生，可靠性保持一致，待命負載減少——不是因為問題被隱藏，而是因為系統防止它們發生。

系列中的下一個

控制迴圈需要信任自動化，這需要能夠安全地撤銷操作。下一層——不可變基礎設施——使安全修復成為可能。閱讀 Layer 3。

在 AIDARIS，我們幫助組織設計既可達成又有後果的 SLO，然後構建控制迴圈來捍衛它們。如果你不確定你的 SLO 是治理信號還是只是指標，讓我們討論。