API 可用率怎麼算？看懂 SLA、成功率與故障期間的計費

API Reliability and Uptime: SLA, Success Rate and Billing on Failure

成功率的三種算法與陷阱

錯誤算法①：全部請求算分母——你的程式 bug 會拉低服務商分數。錯誤算法②：只算成功——故障被掩蓋。正確：分母 = 抵達上游的請求，剔除 client 類錯誤（參數問題）；分子 = 服務端成功完成。

另一個陷阱：樣本不足時報 0%。凌晨無流量顯示「可用率 0%」是嚇人又失真的——正確做法是回「無樣本」。

故障期間的計費政策

這是最能看出服務商誠信的地方。政策應該是：上游故障的失敗請求（401/403/500/逾時等）不計費、0 token 記錄在案；你的程式參數錯誤（400）也不該被收費。OlithmRouter 的錯誤分類體系區分 client／billing／upstream，帳務上故障請求 0 費用。

怎麼監控自己的依賴

不要只靠服務商的儀表板：①在程式端記錄每次呼叫的 request_id 與延遲；②對照服務商日誌；③設置簡單的 synthetic 探測（每分鐘一個小請求）建立自己的 SLA 歷史。故障發生時，你手上要有雙方數據。

恢復速度比故障頻率更重要

服務一定會偶爾故障，差異在 MTTR（平均恢復時間）：有自動換家的服務商，單上游故障時你完全無感；沒有的話每次故障都是一次事故。OlithmRouter 的多上游＋冷卻設計，讓多數上游級故障對使用者透明。

常見問題

99%+ 可用率代表什麼？

代表按剔除口徑統計的穩定分組成功率長期在 99% 以上；具體定義以服務商公開說明為準。

故障期間我損失的時間能賠嗎？

技術上故障請求不計費已是標準做法；現金賠償要看服務條款。更重要的是選有自動換家的服務商，從源頭減少可感知故障。

怎麼區分是我的問題還是服務商的？

看錯誤分類與 request_id：client 類（參數、餘額）是你側；upstream 類（401/403/5xx/逾時）是服務端。OlithmRouter 日誌明確標注分類。

可用率資料能匯出嗎？

OlithmRouter 控制台提供成功率統計與日誌篩選匯出，可作為你的 SLA 對帳依據。

相關文章