SLA、SLO和KPI可靠性

1）術語和區別

SLI（服務級別指標）-可測量的質量指標（例如,成功查詢的比例,p95潛伏期）。
SLO（服務級別目標）是每個時間窗口（例如"成功≥ 99的目標SLI值。在28天內達到9%"）。
預算錯誤（Error Budget）-SLO未完成的比例允許：'1 − SLO'。
SLA（服務級別協議）是帶有罰款/貸款（外部）的合同義務。
可靠性KPI-操作過程度量（MTTD/MTTA/MTTR/MTBF，％的自動聯網，過濾塗層等）。

2）如何選擇SLI（基於Golden Signals）

1.Latency是用於關鍵尾礦的p95/p99。
2.Traffic-RPS/RPM/消息流。
3.Errors是5xx/業務錯誤的份額（例如，不包括PSP過失的支付「決定」）。
4.飽和度-資源飽和度（CPU/RAM/IO/lag）。

• 與用戶體驗（user-perceived）相關。
• 技術上可用且測量穩定。
• 我們控制（可能的改進行動）。
• 收集成本低。

3）公式和示例

3.1個可用性（可用性）

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

示例：SLO 99。30天內9% →預算錯誤=0。1％，相當於43分鐘12秒。

3.2潛伏期

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3.3付款（業務級別）

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4）有缺陷的預算和burn-rate

預算錯誤-用於創新的燃油箱（發布、實驗）。

• 快速通道（1小時~的探測器），
• 慢頻道（~ 6-12小時/24小時的趨勢）。

• 如果burn-rate> 14。1小時4-SEV-1（讓我們吃一天的預算~ 100分鐘）。
• 如果burn-rate> 6在6小時內為SEV-2（快速降解）。

5）通過SLO進行處理（多窗口，多燃燒）

錯誤指示器：5xx或潛伏期違規的比例。

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6）跨域的SLI/SLO示例

6.1個API網關/邊緣

SLI-Errors： 5xx <0的響應比例。1% (28d).

SLI-Latency：p95 ≤ 250毫秒（每天）。
SLO: Availability ≥ 99.95%（季度）。

6.2付款

SLI-Cuccess： 成功付款（不包括客戶豁免）≥ 99。8% (28d).

SLI-Latency： 99%（一天）的授權≤ 2秒。

SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6.3個數據庫（PostgreSQL）

SLI-Lag：p95 ≤ 1秒（每天）復制差。

SLI錯誤： 查詢錯誤百分比≤ 0。05% (28d).

SLO： 群集可用性≥ 99。95%.

6.4隊列/流媒體（Kafka）

SLI-Lag：p95 ≤ N消息的消費者脫落（小時）。

SLI-Durability： 確認記錄≥ 99。99% (28d).

SLO： 經紀人的可用性≥ 99。9%.

7）可靠性過程的KPI

MTTD (Mean Time To Detect)

MTTA (…To Acknowledge)

MTTR (…To Restore)

MTBF (…Between Failures)

自動聯想事件的百分比

SLO覆蓋頂部交通路徑（目標≥ 95%）

擁有金絲雀舞臺的發行比例

使用錯誤的命令/犯規預算

8）如何現實地設置SLO

1.測量當前基本可靠性（3-4周）。
2.定義「敏感」用戶路徑（登錄、存款、遊戲）。
3.考慮每個偏差的成本（時間，金錢，聲譽）。
4.選擇一個雄心勃勃但可實現的目標（比基本目標提高10-30%）。
5.每季度審查一次。

• 立刻「五九」沒有理由。
• 通過用戶無法看到的度量標準（例如，與UX無關的CPU）進行SLO。
• 太多的SLO →噴塗焦點。

9） SLO和預算報告

• 每個SLO的執行：事實vs目標，趨勢，confidence。
• 錯誤消耗摘要：多少預算「燒毀」比誰,（發布/事件）。
• 退化的五大原因，CAPA計劃和任務狀態。
• 業務影響：轉換,ND,保留,LTV.

10）與發布政策的關系

錯誤預算<50% →免費版本。
50-80％→「謹慎模式」：只有低風險/金絲雀布局。

11） SLA（合同）-項目模板

負擔能力義務：例如99。9%/月。
例外（Force Majeure）：DDoS在合理控制之外，第三方提供商。

測量窗口和責任區： 指標來源,計算方法.

學分/罰款：等級表（例如，60-120分鐘不可用→ X%學分）。
上報和通知程序：時間表、渠道。

數據和隱私： 掩蔽,存儲,法律保留.

重復預防工作計劃（CAPA）在發生違規時。

12）測量工具

被動指標：Prometheus/Mimir/Thanos，出口商。
Logi： Loki/ELK用於計算業務層面的成功/錯誤。
合成：cron上的活性樣品（登錄/存款/遊戲）。
跟蹤：Tempo/Jaeger for「瓶頸」p99。
付款/財務：支付SLI的地面真相來源。

13）查詢示例（模板）

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14） FinOps和可靠性

最多9：添加「九」的成本呈指數增長。
收益曲線：收入增長/損失減少≥額外「9」成本的最佳狀態。
SLO組合：不同路徑的不同級別（關鍵支付「更昂貴」，報告「更便宜」）。

15）SLO/Alerts質量-支票清單

• SLI與UX和業務指標相關。
• 窗口和聚合是一致的（滾動28 d/季度）。
• Alerta多窗口,無翻轉,具有角色扮演路由。
• 文件：所有者，公式，來源，運行簿。
• SLO演示面板具有錯誤的預算和燃燒指標。
• 定期審查目標（季度）。
• 針對關鍵場景的合成測試。

16）實施計劃（4次叠代）

1.第一周：用戶路徑清單，SLI草案，基本行車記錄。
2.第2周：SLO正式化，預算計算，Alerta（快速/慢燒傷）。
3.第3周：與事件/發布過程集成，freeze規則。
4.第4周+：合同SLA，季度咆哮，「每人每人9」的泡沫模型。

17）迷你常見問題

每項服務是否需要一個SLO？
優於2-3鍵（成功+潛在）而不是數十個次要。

如果預算用盡，該怎麼辦？
凍結發布，專註於穩定和CAPA，消除實驗性幻想。

如何避免發布速度與可靠性之間的沖突?

計劃「按預算」發布,實施金絲雀布局和功能橫幅。

結果

可靠性不是由一組不同的指標驅動，而是由系統驅動：SLI → SLO →預算錯誤→燃燒→事件過程→ CAPA → SLA。標準化定義、數據源和報告,將目標帶入用戶體驗和經濟,並根據實際的ROI定期審查「九」級別。