先分清楚 SLA、SLO 與 SLI 的用途
SLA 是對客戶或業務單位的承諾，通常包含服務範圍、量測方式、排除條件、通報時限與未達標時的處理方式。SLO 是團隊用來經營服務的內部目標，應比外部承諾保留一些安全空間。SLI 則是實際量測結果，例如成功請求比例、關鍵流程完成率、延遲分位數、資料新鮮度或排程準時率。
三者不能混成一個可用性數字。若 SLA 直接等於 SLO，團隊只要遇到短暫異常就可能碰到合約邊界，也沒有空間處理監控誤差、供應商事故或部署風險。反過來，若 SLO 遠高於業務需求，架構成本、待命壓力與變更摩擦會持續上升，卻不一定帶來相應價值。
從使用者旅程定義「好」與「壞」
先列出真正影響營運的旅程，而不是從現有監控指標倒推目標。企業 AI 助理可能需要關注登入、權限判斷、檢索、模型回應與來源引用；LINE、ERP 或 CRM 整合則可能更在意訊息是否被接收、資料是否正確寫入，以及失敗後能否安全重送。主機仍在線，不代表使用者能完成工作。
每一項 SLI 都應寫成可重現的判定規則。常見形式是「符合條件的良好事件數除以所有有效事件數」。分母是否排除客戶輸入錯誤、計畫維護、測試流量或上游服務故障，必須事先定義；不能等事故發生後才調整口徑。
- 可用性：請求是否在服務邊界內成功完成，而不只是程序是否存活。
- 延遲：使用分位數觀察大多數與尾端體驗，避免平均值掩蓋少數嚴重延遲。
- 正確性：資料同步、權限與交易結果是否符合業務規則。
- 新鮮度：報表、向量索引或 IoT 資料距離來源更新有多久。
- 完整流程：以合成交易或端到端追蹤確認使用者能完成關鍵任務。
用業務影響決定目標，而不是複製業界數字
設定 SLO 時，先問服務中斷會造成什麼：只是延後內部查詢、阻塞現場作業，還是讓訂單、付款或客戶溝通停止？接著評估可接受的復原時間、資料遺失風險、服務時段、使用者所在地，以及是否存在人工替代流程。全天候對外交易與僅在辦公時段使用的內部知識搜尋，不應套用相同目標。
還要檢查架構是否有能力支持承諾。單區部署、人工復原、共用資料庫、第三方 API 限制或沒有重送機制，都會形成可靠度上限。若目標超過目前能力，應明確列出所需投資，例如多區容錯、佇列緩衝、冪等設計、容量餘裕、演練與待命制度，再由業務決定成本是否合理。
建議依使用者旅程與重要性分級，不要讓整套系統只有一個總體 SLO。登入、查詢、寫入、批次同步與後台報表可以有不同指標與量測窗口；但層級不宜過多，否則儀表板與事故判斷會變得難以維護。
讓錯誤預算成為變更決策工具
錯誤預算 是量測窗口內允許出現的不良事件量，概念上等於全部有效事件乘上「一減 SLO」。它不是鼓勵製造故障，而是把可靠度與交付速度放在同一個決策框架中。仍有充足預算時，團隊可以承擔合理的發布與實驗風險；預算快速消耗時，就應降低變更頻率並優先處理可靠度。
預算政策必須在事故前寫好，否則容易變成臨時爭論。政策應說明誰判定預算狀態、多久檢查一次、哪些事件計入，以及耗盡後哪些工作會暫停。對 AI 系統而言，也要區分平台故障、模型供應商失敗、內容安全阻擋與回答品質問題；它們需要不同的 SLI 和處置方式。
- 預算健康時，維持正常發布節奏並持續驗證監控與回復能力。
- 消耗速度異常時，限制高風險變更，檢查近期發布、容量與依賴服務。
- 預算接近耗盡時，優先修復重複性故障，補上自動回復與降級機制。
- 預算耗盡時，暫停非必要功能發布；緊急安全修補與可靠度改善仍應允許。
把目標接進監控、事故與治理流程
SLO 文件至少要包含服務擁有者、使用者旅程、SLI 查詢、資料來源、量測窗口、時區、排除條件、依賴服務與檢視週期。儀表板應同時呈現目前達成狀態、錯誤預算剩餘量與消耗速度。告警則應以使用者影響和預算消耗為主，避免只因短暫資源波動就喚醒待命人員。
定期檢討時，不只問「有沒有達標」，還要看指標是否反映真實體驗、故障是否集中在特定租戶或流程、排除條件是否過寬，以及目標是否仍符合業務需求。SLA 的調整通常需要商務與法務參與；SLO 則應由產品、工程與維運共同管理。若系統橫跨雲端、AI、LINE 與企業核心系統，整合團隊的價值在於協助釐清端到端責任邊界，而不只是替每個元件各自做一張可用性報表。