前言：為什麼多數企業簽了 SLA 卻沒有保障
很多企業與 IT 維運廠商簽約時，注意力都放在「月費多少」，對服務水準協議（SLA, Service Level Agreement）的條款只快速掃過。結果出事的時候才發現：合約承諾的是「2 小時內回應」，不是「2 小時內修好」；伺服器停機 6 小時，但因為起因是「第三方軟體問題」而不計入違約；想終止合約，卻發現沒有任何未達標的退場條款。
SLA 不是廠商給的保證書，而是雙方對「什麼叫做服務做到位」的共同定義。這篇文章從甲方（企業）的角度，把一份合理的 IT 維運 SLA 該有的條款逐項拆解，最後附上簽約前的檢核清單。
若您還在評估「該不該找維運廠商」，建議先看 IT 人員自建 vs 維運合約的完整比較；預算怎麼抓，可參考 IT 維運合約成本解析。本篇假設您已決定簽約，聚焦在條款怎麼訂。
一、回應時間 vs 修復時間：多數糾紛的源頭
SLA 裡最重要、也最常被混淆的兩個概念：
| 名詞 | 定義 | 常見承諾寫法 |
|---|---|---|
| 回應時間（Response Time） | 廠商確認收到問題、開始處理的時間 | 「30 分鐘內回覆」「2 小時內到場」 |
| 修復時間（Resolution Time） | 問題實際解決、服務恢復的時間 | 「4 小時內恢復」「次一工作日修復」 |
關鍵認知：絕大多數維運合約只承諾回應時間，不承諾修復時間。這不是廠商偷懶——修復時間受故障原因、備品供應、原廠支援等變數影響，負責任的廠商不會亂承諾一個做不到的修復時間。但這也代表：
- 如果合約只寫「快速回應」而沒有任何時間數字，等於沒有 SLA
- 對於「不能停」的關鍵系統，光靠回應時間承諾不夠，要搭配高可用架構（備援、備機）把「修復時間長」的風險用架構吃掉，而不是用條款轉嫁
- 合理的合約會對「重大事故」給出修復目標（例如「重大事故 8 小時內恢復或提供暫行方案」），並定義暫行方案（workaround）也算階段性達標
二、事故分級與回應承諾怎麼訂
一份可執行的 SLA 必須先定義事故等級，再對每級給承諾。台灣中小企業常見的三級制：
| 等級 | 定義範例 | 合理回應承諾 | 處理方式 |
|---|---|---|---|
| P1 重大 | 全公司無法作業（伺服器當機、網路全斷、勒索事件） | 30 分鐘內回應、2-4 小時內到場或遠端介入 | 全力處理直到恢復，事後附根因報告 |
| P2 影響 | 部分部門或關鍵功能受影響（郵件收發異常、某系統變慢） | 2-4 小時內回應 | 當日或次一工作日處理 |
| P3 一般 | 單一使用者問題、諮詢、小調整 | 次一工作日回應 | 排程處理 |
訂條款時的三個實務重點：
- 分級要有客觀判準。「重大」「一般」由誰認定？合理做法是合約列出具體情境範例（如上表），有爭議時以「受影響人數與業務衝擊」判斷，避免每次都吵。
- 服務時段要寫清楚。5×8（工作日上班時間）與 7×24 的成本差距很大。多數中小企業的合理配置是：P1 事故 7×24 通報管道 + 5×8 常規服務，而不是全部拉到 7×24。
- 到場與遠端要分開承諾。遠端介入可以很快，到場受地理限制——這也是為什麼在地廠商對台中企業有實質意義，詳見我們在 IT 監控與告警實務 提到的「監控＋在地回應」組合。
三、可用率承諾怎麼讀
「可用率 99.9%」聽起來很安心，但要看懂三件事：
換算成停機時間：
| 可用率 | 每月容許停機 | 每年容許停機 |
|---|---|---|
| 99% | 約 7.2 小時 | 約 3.65 天 |
| 99.5% | 約 3.6 小時 | 約 1.83 天 |
| 99.9% | 約 43 分鐘 | 約 8.8 小時 |
| 99.95% | 約 22 分鐘 | 約 4.4 小時 |
計算基礎：是否扣除「計畫性維護窗口」？合理的合約會扣除（事先通知的維護不算停機），但維護窗口本身要有限制（例如每月最多一次、需 3 個工作日前通知、安排在非營業時間）。
量測與舉證：可用率由誰量、用什麼量？如果廠商說了算，數字沒有意義。合理做法是以監控系統的數據為準——這也是為什麼成熟的維運服務一定包含監控建置，雙方看同一份儀表板，達標與否一翻兩瞪眼。
坦白說：對多數中小企業，與其在合約上追逐 99.95%，不如把預算花在讓單點故障消失（備援防火牆、UPS、異地備份）。可用率是架構做出來的，不是條款寫出來的。
四、涵蓋範圍與除外條款：合約的真正邊界
SLA 數字再漂亮，範圍寫錯就是白紙。逐項確認：
涵蓋範圍檢核：
- 設備清單：哪些伺服器、網路設備、端點在合約內？新增設備怎麼計價？
- 軟體層：作業系統更新、防毒管理、備份作業是否包含？應用系統（ERP、進銷存）通常另計，界線在哪？
- 雲端服務：Microsoft 365、雲端主機的管理是否在範圍內？
- 資安事件：勒索軟體事件的應變是否包含？重建工時怎麼算？
常見的除外條款（合理 vs 過寬）：
| 除外項目 | 合理性 |
|---|---|
| 天災、斷電等不可抗力 | 合理，業界慣例 |
| 客戶未經通知自行變更設定導致的問題 | 合理，但「變更」定義要清楚 |
| 第三方服務中斷（ISP、雲端服務商） | 合理，但廠商應負通報與協調責任 |
| 「軟體問題」一律除外 | 過寬——OS 與基礎軟體的維護本應是維運核心 |
| 超過 N 年的老舊設備 | 灰色地帶——合理做法是「盡力服務但不承諾 SLA」，並在年度檢討提汰換建議 |
五、罰則、服務抵扣與退場條款
未達標的後果，常見三種設計，強度由低到高：
- 根因報告與改善計畫（基本要求）：任何 P1 事故後，廠商應在約定天數內提交事故報告——發生什麼、為什麼、如何避免重演。這比罰錢更能改善服務品質。
- 服務抵扣（Service Credit）：未達標月份折抵部分月費（常見 5%-20%）。重點是自動適用，不要設計成「需甲方主動申請」。
- 終止權：連續 N 個月或一年內累計 M 次未達標，甲方可無條件提前終止且不付違約金。這是最有力的條款——它讓廠商知道，服務不好客戶走得掉。
同時要注意你自己的退場成本：合約期多長？提前終止的違約金怎麼算？終止時廠商是否有義務完成交接（文件、帳號、設定移交）？交接義務沒寫進合約，換廠商時會非常痛苦——完整的交接清單見 IT 交接完整清單。
六、定期檢討：讓合約活著
簽完就鎖進抽屜的 SLA 是死的。合理的節奏：
- 月報：事故統計、處理時效達成率、監控摘要。好的廠商會主動給，不用催——這也是挑選維運廠商時的重要判準
- 季度檢討會：回顧達成率、討論反覆發生的問題、調整分級或範圍
- 年度總檢：設備健康狀況、汰換建議、隔年預算規劃。合約範圍隨公司成長調整（人數、設備、新系統）
檢討會不是形式——它是把「被動修東西」升級成「主動管理 IT」的槓桿。如果廠商一年到頭只有出事才出現，代表你買到的是修理服務，不是維運服務。
七、簽約前檢核清單
最後，把全文收斂成一份可以直接帶去談約的清單：
- ☐ 事故分級有客觀定義與情境範例
- ☐ 每個等級都有明確的回應時間數字（不是「儘速」）
- ☐ 重大事故有修復目標或暫行方案承諾
- ☐ 服務時段明確（5×8 / 7×24，P1 是否有 24 小時通報管道）
- ☐ 涵蓋設備與軟體清單具體，新增計價方式明確
- ☐ 除外條款逐條讀過，沒有「軟體問題一律除外」這類過寬條款
- ☐ 可用率有計算基礎與量測依據（監控數據雙方可見）
- ☐ P1 事故後有根因報告義務
- ☐ 有服務抵扣或累計未達標的終止權
- ☐ 終止時的交接義務寫進合約
- ☐ 有固定的檢討機制（至少季度）
- ☐ 合約期與提前終止條件可接受
這 12 項全部打勾，才算簽到一份「有保障」的維運合約。其中任何一項廠商不願意談，本身就是重要的訊號。