SLO/SLA和指標

SLO/SLA和指標

1）術語和層次結構

SLI（服務級別指標）-可衡量的指標「用戶如何看待我們」：成功查詢的比例，p95潛伏率，數據新鮮度，成功處理的戰鬥的比例等。

SLO（服務級別目標）是監視間隔（28/30/90天）上的SLI目標值。示例： "99。9%的請求/付款在400毫秒≤完成。"

Error budget — 1 − SLO.在SLO 99下。9％的錯誤預算=0。1%的時間/請求。
SLA（協議）-具有法律意義的服務級別：包括SLO，測量，例外，賠償/罰款。

2）設計原則

癥狀>內部指標。SLI必須反映真實的用戶體驗。
少量關鍵SLI。每項服務有2-5項主要服務：成功，潛伏期，吞吐量/新鮮度，正確性。
覆蓋關鍵路徑。對於每個業務腳本（checkout、login、webhook、ETL下載）,均為自己的SLI/SLO集。
嚴格的「成功」語義。不是「代碼200」，而是「用戶按時收到響應，結果驗證」。
外部SLO和內部SLO的分離。內部-嚴格；外部SLA ≤在下面的1-2 9。

3） SLI目錄（參考）

3.1個API/在線服務

成功： 'SLI_success=1 −（5xx+timeout+business_error）/all_requests'

潛伏期： p95/p99 'http_server_duration_seconds'沿路由/方法/租戶

吞吐量： 「RPS」/限制/配額

正確性： 有效響應的比例（簽名、電路、不變量）

3.2 Webhooks/異步交付

交付： T秒和 N ≤中確認的事件百分比

客戶： 訂戶比例無長時間延誤（主訂戶）

3.3 數據/ETL/DWH

新鮮（freshness）： 'now − last_successful_ingest_ts'

完整性： 'ingested_rows/ expected_rows'

正確性： 經過質量檢查的記錄比例

Piplines： 截止日期前完成的喬布斯比例

3.4移動/客戶端SDK

客戶成功： 會議比例無致命錯誤

round-trip潛伏期： p95從查詢到渲染

快取熱門： 快取服務的比例（作為表現癥狀）

4）公式和目標示例

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99.95%在30天內→ error budget=0。50%的請求。

• `uptime = (obs_window − downtime) / obs_window`

• "SLO_latency=p95 （route="/pay"） ≤ 400 ms在7天的切片中，緩存預熱除外（1%）

• "SLO_freshness（dataset="orders"）在24小時內≤ 10 min'p99。

5）錯誤預算和變更管理

預算（B）：「B=1 − SLO」。
預算支出（burn）：實際錯誤與允許的比率。

• 超支（burn> 1） → fichfries,專註於可靠性。
• 在burn rate> X中,在短窗口中是事件和引腳。措施。
• 計劃：沖刺對可靠性的比例與過去的燃燒有關。

6） Alerting： 燃燒率和多窗口規則

想法：捕捉快速泄漏和緩慢漂移。

示例（SLO 99。9％，預算0。1%):

關鍵：「1小時預算的2%」（快速火災）。
警告：「6小時預算的5%」（爬行退化）。

• 快速事件的短窗口（一分鐘至一小時）。
• 趨勢的長窗口（6-24小時）。
• 潛伏期：p99>閾值≥5分鐘，帶有懸浮抑制以及與步道外胚層的關系。

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7）多範圍（multi-tenant）和細分

SLI/SLO按租戶/計劃/地區計算，否則中位數將「吸引」失敗。
統計意義的最小事件數（guard-rails）。

SLA的票價可能會有所不同（例如"Pro 99。9%, Free 99.5%»).

8）與可觀察性和跟蹤的關系

SLI度量標準是從直方圖/計數器到exemplars →過渡到「不良」軌跡。
Logi是原因的來源：時間限制，業務錯誤代碼，限制。

對於數據-鏈接到線程： 「哪個喬巴延遲了新鮮度量。」

9）合同和SLA

• SLI/測量方法/窗口定義。
• 例外（計劃工作，不可抗力）。
• 事件和通信程序（狀態頁面，RFO/RCA）。
• 賠償（服務信貸）和請求順序。
• 管轄權，有效期，審查條件。

• 永遠不要公開承諾SLO比架構和操作實踐所允許的更嚴格。
• 分離內部SLO和外部SLA。

10）成本和優先級

九個的價格沒有線性增長。«99.9% → 99.99％"=不同的體系結構類別（N+1，multizon，資產-資產）。
將SLO置於最有價值的用戶操作上。
控制遙測的成本：按類分解、配額、復制副本和存儲。

11）程序和報告

每周報告：按服務/租戶執行SLO，預算支出，最高原因，改進計劃。
發育後的RCA：與預算相關聯；我們的任務是解決根本原因。
Fichfries：包含/刪除標準。

12）模板（快速啟動）

12.1 SLO卡（示例）

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12.2 「SLO成熟度」表"

13）規則示例（片段）

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14）數據和ML SLO（功能）

端到端數據SLO： p99的新鮮度、p99的完整性、故障發生後的「重新設計」時間。
數據合同：預期的方案，數量，截止日期；違反→數據事件。
ML：地獄潛伏期的SLO，相機可用性的SLA，漂移監測（模型質量是一個單獨的主題，在SLA之外）。

15）與安全和隱私的整合

沒有PII/秘密的 SLI標誌；令牌/掩碼。
審核未更改日誌中的SLO/SLA更改和報告出版物。
對於監管途徑（付款/PII），是單獨的，更嚴格的SLO。

16）支票單

啟動服務/fichi之前

• SLI定義為「成功/潛在/吞吐量/新鮮度」。
• 設置了SLO和窗口；計算出錯誤預算。
• 設置了burn-rate alerta（短+長）。
• RED+exemplars →軌道；Runibook事件。
• 多方切口和重要性閾值。
• fichfriz和報告程序。

運營

• SLO/burn的每周報告，強硬計劃。
• 在體系結構/負載更改時重新評估SLO。
• 偶爾的「事件演習」和更新runibook。
• 控制遙測成本和SLI數量。

17) Runbook’и

Runbook： 快速增長p99/pay

1.Alert r 99>閾值→打開行車記錄板→通過exemplar進入步道。
2.查找狹窄的CLIENT/SERVER-span並比較區域/版本。
3.啟用降級（緩存/限制/後退）,通知依賴命令。
4.穩定後-RCA，優化問題，SLO測量更新。

Runbook： 每周預算支出>50%

1.冷凍菲奇，提高可靠性的優先級。
2.錯誤集群：路線/租戶/依存關系。
3.推出修復程序→確認趨勢恢復。
4.回顧和調整標量/閾值。

18) FAQ

Q： 需要多少個SLO?

答：關鍵用戶場景的最低限度：成功+潛伏。其他一切-根據需要。

Q： 什麼是最好的-按時間或按請求提供?

答：根據請求,是更定制的指標。對於網絡組件/infra，時間方便。

問：為什麼p95而不是平均水平？
答：中間隱藏尾巴；用戶感覺到p95/p99。

問：怎麼不把螺母扭得太厲害？
答：從現實的目標（歷史數據）開始，然後隨著成熟而收緊。

• 「可觀察性：邏輯，度量，跟蹤」
• 「分布式跟蹤」
• 「審核和不變日誌」
• 「網絡手冊交付保證」
• 「加密In Transit/At Rest」
• 「數據來源（Lineage）」