▍SLA 是什麼?
SLA(服務等級協議)是你與供應商之間,對「服務品質標準」做可量化承諾的文件。
來個超生活版——「學校便當外送的SLA」

想像你們班跟附近便當店說好一份「小約定」(就是 SLA):
- 服務是什麼:每天中午 12:00 前,把 25 個便當送到 302 班。
- 如果出事要多久回你:少便當、送錯了,5 分鐘內要回訊說「我知道了,正在處理!」(回應時間)
- 什麼時候要修好:30 分鐘內補送到你們班(修復時間)
- 可以晚幾次:這個月上學 20 天,至少有 19 天要準時(不要常常遲到)
- 不算在遲到裡的情況:颱風停課或學校門口馬拉松封路,便當店不算違約(排除項目)
- 便當店保養時間:每週三晚上清洗煮飯機器,那時不接單(維護時窗)
- 怎麼算準時:導師用教室時鐘記錄,12:05 前都算準時(量測方式)
- 如果沒做到怎麼辦:每晚到一次,下次全班每人送一盒水果或折 10 元(補償)
- 誰負責:便當店老闆對接班導師(聯絡窗口)
一句話記:
SLA 就是「說清楚做什麼、多久做完、遇到狀況怎麼補救、沒做到怎麼賠」,讓大家放心、不吵架。
▍一份好用的 SLA 應該包含什麼

(1)服務範圍(含排除項目)。
(2)可用性門檻(例:月 99.9%)。
(3)回應/修復時限(依 P1–P4)。
(4)量測/稽核方式(監控來源、計算口徑)。
(5)補償(服務抵用金或退費,上限)。
(6)通報與升級機制。
(7)維護與變更管理(預告、避峰、回滾)。
(8)資安與備援(備份、RTO/RPO、多區多活)。
▎嚴重度分級(P1–P4)與回應/修復時限(參考值)

P1(全站或核心交易中斷):15 分內回應、4 小時內恢復或提供繞過。
P2(主要功能受影響,有替代方案):1 小時回應、1 個工作日內修復。
P3(次要問題/效能退化):4 小時回應、5 個工作日內修復。
P4(諮詢/需求):1 個工作日回應,雙方排程。
撇步:把分級寫具體,例如「>5% 使用者無法結帳=P1」。
▎維護時窗、量測口徑、補償條款
維護應獨立公告並排除在可用性計算;量測以雙方同意的監控/報表為準;補償以服務抵用金優先、退費為備案。
▍擬定 SLA 的 7 個實務步驟(附檢核點)

1 盤點關鍵旅程(註冊/登入/下單/付款)。
2 定義 SLI(可用性、延遲、錯誤率、客服回覆時間)。
3 設定 SLO(例:月 99.9%、P95 ≤ 400ms)。
4 寫入 SLA(補償機制、量測口徑、維護時窗)。
5 排班與升級(值班表、跨部門聯絡清單)。
6 演練回滾(模擬故障、演練切換、多環境驗證)。
7 季度檢討(錯誤預算用量、變更節奏、是否需調整 SLO)。
▍常見踩雷與避免方法

(A)只談幾個 9,沒談怎麼測 → 先約定監控來源與計算方式。
(B)把維護算進可用性 → 應提前公告並排除計算。
(C)只寫回應、不寫修復 → 兩者需分開訂。
(D)沒有升級路徑 → 明確客服 → 值班電話 → 技術經理。
(E)補償寫太美、難兌現 → 以抵用金為主,退費保留重大事故。
(F)忽略客戶自改設定 → 條款列明排除責任。
(G)只看月度,不看 95 百分位延遲 → 同步納入延遲與錯誤率的 SLO。
▍比較表:SLA vs SLO/SLI/OLA、可用性 vs 停機
名稱 | 定義(中文) | 用途/性質 | 對象 | 典型責任單位 | 常見範例 |
---|---|---|---|---|---|
SLA | 合約承諾+補償 | 法定/商務約定,違反有補償或罰則 | 對外(甲乙雙方) | 法務、業務、客戶成功、產品/工程共同背書 | 月可用性 ≥ 99.9%;P1 事故 30 分鐘內回應;未達則提供帳單折抵 |
SLO | 對外或對內的服務目標 | 可度量的服務水準目標,用於對齊期望與管控錯誤預算 | 對外或對內 | 產品、SRE | 30 天可用性 ≥ 99.95%;API P99 延遲 < 300ms;錯誤率 < 0.1% |
SLI | 量測指標 | 反映使用者體驗的客觀數據,SLO 與 SLA 的依據 | 對內(必要時對外揭露) | 數據分析、監控平台、SRE | 可用性=成功請求/總請求;P95 延遲;5xx 比例;丟包率 |
OLA | 組織內部服務協議 | 團隊間交付與回應時間的內部約定,無對外補償 | 對內(跨部門) | 各功能團隊、PMO/流程管理 | P1 事故 DBA 15 分鐘到位;安全審核 24 小時內完成;客服升級工程 ≤ 30 分鐘 |
▍誰適合哪種 SLA?(簡單/快速/最有效)
簡單:官網/內容站。可用性 99.5%~99.9%;固定維護時窗;客服 1 個工作日回覆。
快速:電商或 SaaS。可用性 99.9%;P1 15 分回應/4 小時恢復;每日備份(RTO 4h/RPO 24h)。
最有效:金流、醫療。可用性 99.99%+;多區多活、自動切換;重大改版有凍結期。
站內延伸:把穩定度與轉換率一起設計(內鏈:https://ez2.app/)。
▍台灣相關新聞影片
大型斷訊事件提醒:維護時窗、回應/修復時限與補償條款一定要事先講清楚,尤其牽涉醫療、救災等公眾利益更敏感。
影片參考:鏡新聞「全台大故障」報導
▍迷你 SLA 條款範本(可直接套用)
服務:網站代管與維運(含 SSL、自動備份)。
可用性:月 99.9%,以雙方同意的監控報表為準。
回應/修復:P1 15 分回應/4 小時恢復;P2 1 小時/1 天;P3 4 小時/5 天;P4 1 天/排程。
維護時窗:每週三 02:00–04:00(UTC+8),提前 48 小時公告。
備份/RTO/RPO:每日全備;RTO 4 小時;RPO 24 小時。
補償:未達 99.9%,每下降 0.1% 折抵當月月費 5%,上限 50%。
升級路徑:客服信箱 → 值班電話 → 技術經理。
(若要內部化,請把各角色名稱替換成你們實際職稱與聯絡人)
▍常見SLA的問題 FAQ
▍本文總結
一句話版:SLA 把服務品質「量化+合約化」,事故時有章可循、日常有指標可追。
行動建議:
1 先做 7 步驟盤點並寫出你們的初版 SLA;
2 與供應商對齊量測與補償;
3 季度用錯誤預算回看變更節奏;
4 高風險業務導入多區備援與演練。
你的 SLA 沒寫清楚,可能正是網站斷線、客戶流失的隱藏地雷!
Ez2.APP 提供 免費網站健檢,幫你檢查 SLA、備援與穩定性。別等事故發生才補救!
設計辦公室|台灣台南市北區文賢路572巷25號
💡想讓網站更好被Google找到?先從了解URL開始 →URL是什麼?為什麼跟網站設計超有關?
剛開始做SEO?你一定要懂什麼是「主題集群」→ 快來看新手教學篇
🤔 你知道Google為什麼特別嚴格看某些網站內容嗎?YMYL就是關鍵 →YMYL 在網路行銷是什麼鬼?
🚫 你以為外部連結才重要?其實內部連結才是SEO的長期王道 → 點這看策略解析
🛠 想讓你的FAQ出現在Google搜尋結果上?這篇手把手教你怎麼做 →FAQ Schema 結構化資料完整實作教學