SLO SLI SLA 區別是什麼：用一份公開可用率資料把錯誤預算算一遍
SLO SLI SLA 區別，一句話說：SLI 是你實際測出來的數（比如“成功請求佔比”），SLO 是你給自己定的目標（比如“30 天內成功率不低於 99.9%”），SLA 是寫進合同、達不到要承擔後果的承諾。三者是“測量、目標、承諾”的關係，SLA 通常比 SLO 寬鬆，SLO 又建立在一個口徑明確的 SLI 上。
下面拿一份公開的逐小時請求計數，把 SLI 的口徑、統計視窗和錯誤預算實際算一遍。同一份 48 小時資料，按請求加權和按小時平均算出來差了將近 9 個百分點。
SLI、SLO、SLA 各自是什麼？
| 是什麼 | 誰來定 | 例子 | 沒達到會怎樣 | |
|---|---|---|---|---|
| SLI（服務等級指標） | 一個可測量的比例或數值 | 工程團隊 | 成功請求數 / 有效請求數 | 只是一個數，沒有後果 |
| SLO（服務等級目標） | SLI 在某個視窗內要達到的目標 | 工程與產品一起定 | 滾動 30 天成功率 ≥ 99.5% | 內部動作：凍結髮布、優先修穩定性 |
| SLA（服務等級協議） | 對外的書面承諾 | 商務與法務 | 月可用率低於某值按約定補償 | 合同後果 |
幾個容易混的地方：
- SLI 必須有分子、分母和過濾條件。“可用率 99%”不算 SLI，“過去 30 天，狀態碼非 5xx 的請求 / 全部請求”才算。
- SLO 一定帶視窗。沒有視窗的目標沒法判斷是否達標。
- 不是每個服務都有 SLA。很多服務只公開狀態頁和歷史可用率，沒有合同承諾。讀狀態頁的方法可以看怎麼看 OpenAI 狀態頁和 Claude 狀態頁。
用來演示的資料從哪來？
AGI Plan 在 https://agiplan.dev/api/status/requests?month=YYYY-MM 公開逐小時、逐能力組的成功和失敗計數，不需要登入，預設返回 CSV，加 format=json 返回 JSON。AGI Plan 是 cdnping 的商業合作方，這裡只把它當作一份口徑公開的樣本資料，不涉及 AGI Plan 的任何服務條款。cdnping 的 /status/agiplan 頁面會映象展示這份資料。
它的口徑寫得很清楚：
可用率 = 成功 /（成功 + 因平臺自身原因失敗），只有 5xx 算平臺失敗。
也就是說，4xx（包括 401 鑑權失敗、429 限流）不進分母。這個選擇本身就是 SLI 設計裡最常被爭論的一點，後面會單獨說。
下文所有數字來自 cdnping 在 2026-10-17 18:05（北京時間）對這個介面取的一次快照。cdnping 從 2026-10-17 才開始採集，這只是一個時間點的樣本，不是長期統計。
視窗長短會把可用率改變多少？
快照裡每個能力組有 1 天、7 天、30 天三個視窗的可用率：
| 能力組 | 1 天 | 7 天 | 30 天 | 30 天請求數 |
|---|---|---|---|---|
| fast（高速輕量） | 77.35% | 81.76% | 81.73% | 44,729 |
| frontier（前沿推理） | 99.76% | 94.22% | 94.41% | 33,729 |
| domestic（國產旗艦） | 98.00% | 98.23% | 98.01% | 9,436 |
| balanced（均衡通用） | 100% | 94.77% | 94.98% | 3,625 |
幾點觀察：
- 短視窗波動大。balanced 組 1 天是 100%，30 天是 94.98%；如果你只看“今天”，會得出完全不同的判斷。frontier 組也是一樣，1 天 99.76%，7 天只有 94.22%。
- 視窗太長會稀釋近期問題。fast 組 1 天 77.35% 比 30 天低 4 個多百分點，但 30 天的數字看起來“還行”，掩蓋了眼下的狀況。
- 請求量小的組更敏感。balanced 組 30 天只有 3,625 個請求，幾十個失敗就能讓百分比明顯移動。
這就是為什麼 SLO 一般用滾動 28 天或 30 天做“是否達標”的判斷，同時用 1 小時、6 小時這樣的短視窗做告警。兩種視窗回答的是不同的問題。
口徑不同，同一份資料能差多少？
快照裡還有 48 個逐小時桶（北京時間 10 月 15 日 19 時前後到 10 月 17 日 18 時前後），是各組合計的成功和失敗數。48 小時合計成功 13,963 次、失敗 2,177 次。用三種常見演算法算一遍：
| 演算法 | 計算方式 | 結果 |
|---|---|---|
| 按請求加權 | 總成功 / 總請求 | 86.51% |
| 按小時平均 | 每小時算一個比例，再取平均 | 95.17% |
| 按“好小時”計 | 成功率 ≥ 99% 的小時數 / 總小時數 | 26 / 48 = 54.2% |
差異主要來自 10 月 16 日 14 時到 16 時這兩個小時：共 2,718 個請求，失敗 1,599 個，單小時成功率分別是 47.91% 和 34.16%。這兩個小時恰好是白天高峰，請求多，所以在“按請求加權”裡分量很重；而“按小時平均”把它們和凌晨只有 2 個請求的小時同等對待，結果就被拉高了。
去掉這兩個小時，剩下 46 小時按請求加權是 95.69%。另外，前 24 小時是 83.42%，後 24 小時是 94.95%，同一個 48 小時視窗切成兩半也會講出兩個故事。
選哪種演算法，取決於你想回答什麼：
- 按請求加權：反映使用者實際碰到失敗的機率，大多數 API 服務應該用它。
- 按時間（好分鐘/好小時）：適合請求量很低、或者更關心“服務能不能用”而不是“多少請求失敗”的場景。
- 按小時平均：最好別用，它會讓低流量時段替高峰時段“稀釋”問題。
4xx 和 429 該不該算失敗？
這份資料裡沒有 4xx 的計數，所以沒法算出“把 429 計入失敗後可用率是多少”，這裡只講判斷方法：
| 狀態 | 常見原因 | 建議 |
|---|---|---|
| 5xx | 服務端或上游故障 | 計入失敗 |
| 超時、連線重置 | 網路或服務端 | 計入失敗，但要區分是不是你自己網路的問題 |
| 429 限流 | 超過配額，或平臺過載時主動限流 | 看原因：使用者自己超額不計；平臺過載觸發的應計入 |
| 401/403 | 金鑰錯誤、許可權不足 | 一般不計 |
| 400 | 請求格式錯誤 | 不計 |
關鍵是把口徑寫下來，並且在對比兩個服務時確認口徑一致。一家把 429 算失敗、另一家不算，直接比百分比沒有意義。自己做探測時的口徑問題，自己測 AI API 的可用率裡有更細的說明；同一個模型在不同推理供應商上的差異，可以參考同一模型換個 OpenRouter 供應商，可用率能差多少。
幾個 9 對應多少停機時間？
按時間口徑換算，30 天按 43,200 分鐘算：
| 可用率 | 每週 | 每 30 天 | 每年（365 天） |
|---|---|---|---|
| 99% | 100.8 分鐘 | 7.2 小時 | 87.6 小時 |
| 99.5% | 50.4 分鐘 | 3.6 小時 | 43.8 小時 |
| 99.9% | 10.08 分鐘 | 43.2 分鐘 | 8.76 小時 |
| 99.95% | 5.04 分鐘 | 21.6 分鐘 | 4.38 小時 |
| 99.99% | 1.01 分鐘 | 4.32 分鐘 | 52.6 分鐘 |
| 99.999% | 6.05 秒 | 25.9 秒 | 5.26 分鐘 |
如果你的 SLI 是按請求算的，就把“分鐘”換成“請求數”：允許失敗數 = 視窗內總請求 ×（1 − SLO）。
錯誤預算怎麼算？
錯誤預算就是 SLO 允許你失敗的那部分。以 frontier 組為例，30 天 33,729 個請求：
- 假設 SLO 定為 99%，預算是 33,729 × 1% ≈ 337 個失敗請求。
- 按 30 天可用率 94.41% 反推，實際失敗約 1,887 個，大約是預算的 5.6 倍。
- 假設 SLO 定為 95%，預算約 1,686 個，實際仍略超。
再看 domestic 組：9,436 個請求，30 天可用率 98.01%，反推失敗約 188 個。在 98% 的目標下預算約 189 個，剛好貼著線；在 99% 的目標下預算約 94 個，已經用掉兩倍。
同一組資料，目標定在哪裡，結論就完全不同。所以 SLO 不應該拍腦袋定成“99.9%”，而應該先看過去一段時間的實際 SLI，再決定。
還有一個常用的概念是消耗速率（burn rate）：實際失敗比例 ÷ 預算比例。SLO 是 99% 時，某小時失敗率 10%，消耗速率就是 10，意思是照這個速度，30 天的預算 3 天就會用完。10 月 16 日 14 時那一小時失敗率約 52%，相對 99% 的 SLO 消耗速率約 52，一小時就用掉了 30 天預算的 7% 左右。告警通常按消耗速率設，而不是按某個固定百分比。
動手：用公開介面自己算一遍
- 下載當月資料，先看錶頭和欄位：
curl -s 'https://agiplan.dev/api/status/requests?month=2026-10' -o req.csv
head -3 req.csv
- 確認哪一列是時間、能力組、成功數、失敗數。下面的命令假設成功數在第 3 列、失敗數在第 4 列，並且有一行表頭，請按實際表頭調整列號：
# 按請求加權的整體可用率
awk -F, 'NR>1 {ok+=$3; f+=$4} END {printf "ok=%d failed=%d sli=%.4f\n", ok, f, ok/(ok+f)}' req.csv
# 成功率 >= 99% 的“好小時”佔比（按行計，每行一個小時 × 能力組）
awk -F, 'NR>1 && ($3+$4)>0 {n++; if ($3/($3+$4) >= 0.99) g++} END {printf "good=%d/%d\n", g, n}' req.csv
- 把兩個結果對比一下，再試著去掉某個能力組、或者只看工作時間，觀察數字怎麼變。
自己的服務也可以照這個流程走：先匯出逐小時的成功、失敗計數，再算。
小團隊怎麼給 AI 應用定第一版 SLO？
一份可以照著走的檢查表：
- 選一個使用者能感知的 SLI。AI 應用最常見的是“呼叫上游模型的請求中，非 5xx 且未超時的比例”。延遲可以另起一個 SLI，例如“首 token 時間低於 N 秒的請求比例”。
- 寫清過濾條件。4xx 計不計、429 怎麼區分、客戶端主動取消算不算，全部寫進文件。
- 先測兩到四周再定目標。用實際 SLI 的水平作為起點，目標定在略高於現狀的位置，而不是先寫 99.9% 再發現永遠達不到。
- 考慮上游。如果你依賴的模型 API 自己只有某個水平，你的 SLO 很難比它更高，除非做了重試或多供應商切換。上游狀態可以在 API 狀態 和 掛了嗎 檢視，故障記錄可以參考 AI 服務故障盤點：2026 年 9–10 月。
- 按消耗速率定兩檔告警，每檔配一長一短兩個視窗，兩個視窗都超閾值才觸發，減少誤報。Google SRE Workbook 針對 30 天 99.9% 的 SLO 給過一組參考值：1 小時和 5 分鐘視窗的消耗速率都超過 14.4 時立即通知；6 小時和 30 分鐘視窗都超過 6 時也通知。數值按自己的 SLO 和流量調整。
- 約定預算用完後的動作。例如暫停非緊急上線、優先處理穩定性問題。沒有動作的 SLO 只是一個看板數字。
探測指令碼、告警配置這些具體實現，可以接著看 AI 應用可用性監控怎麼做。cdnping 自己的探測方式和口徑寫在 資料方法 頁面。
讀別人的可用率數字時先問哪幾個問題？
- 分子分母是什麼，4xx、429、超時怎麼算？
- 視窗是 1 天、7 天還是 30 天，是自然月還是滾動？
- 按請求加權還是按時間算？
- 是服務端統計的真實請求，還是外部探測？外部探測是固定間隔的抽樣（例如 cdnping 的 API 狀態每 5 分鐘探測一次），和真實請求的結果不能直接比。
- 能不能拿到原始計數自己復算？
評估第三方 API 服務時，這幾條可以和AI API 中轉站怎麼選：8 項檢查一起用。
