SLA 是什麼?一看就懂的服務等級協議(台灣實務版)

SLA 是什麼?一看就懂的服務等級協議(台灣實務版)

▍SLA 是什麼?


SLA服務等級協議)是你與供應商之間,對「服務品質標準」做可量化承諾的文件。

來個超生活版——「學校便當外送的SLA」

想像你們班跟附近便當店說好一份「小約定」(就是 SLA):

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

一句話記:
SLA 就是「說清楚做什麼、多久做完、遇到狀況怎麼補救、沒做到怎麼賠」,讓大家放心、不吵架。

▍一份好用的 SLA 應該包含什麼

SLA 是什麼?一看就懂的服務等級協議(台灣實務版)


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

▎嚴重度分級(P1–P4)與回應/修復時限(參考值

SLA 是什麼?一看就懂的服務等級協議(台灣實務版)


P1(全站或核心交易中斷):15 分內回應、4 小時內恢復或提供繞過。
P2(主要功能受影響,有替代方案):1 小時回應、1 個工作日內修復。
P3(次要問題/效能退化):4 小時回應、5 個工作日內修復。
P4(諮詢/需求):1 個工作日回應,雙方排程。
撇步:把分級寫具體,例如「>5% 使用者無法結帳=P1」。

▎維護時窗、量測口徑、補償條款


維護應獨立公告並排除在可用性計算;量測以雙方同意的監控/報表為準;補償以服務抵用金優先、退費為備案。

▍擬定 SLA 的 7 個實務步驟(附檢核點)

SLA 是什麼?一看就懂的服務等級協議(台灣實務版)


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

▍常見踩雷與避免方法

SLA 是什麼?一看就懂的服務等級協議(台灣實務版)


(A)只談幾個 9,沒談怎麼測 → 先約定監控來源與計算方式。
(B)把維護算進可用性 → 應提前公告並排除計算。
(C)只寫回應、不寫修復 → 兩者需分開訂。
(D)沒有升級路徑 → 明確客服 → 值班電話 → 技術經理。
(E)補償寫太美、難兌現 → 以抵用金為主,退費保留重大事故。
(F)忽略客戶自改設定 → 條款列明排除責任。
(G)只看月度,不看 95 百分位延遲 → 同步納入延遲與錯誤率的 SLO。

▍比較表:SLA vs SLO/SLI/OLA、可用性 vs 停機

名稱定義(中文)用途/性質對象典型責任單位常見範例
SLA合約承諾+補償法定/商務約定,違反有補償或罰則對外(甲乙雙方)法務、業務、客戶成功、產品/工程共同背書月可用性 ≥ 99.9%;P1 事故 30 分鐘內回應;未達則提供帳單折抵
SLO對外或對內的服務目標可度量的服務水準目標,用於對齊期望與管控錯誤預算對外或對內產品、SRE30 天可用性 ≥ 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 結構化資料完整實作教學

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *