週一早上九點，業務打不開系統，客戶的訂單進不來。你打電話給廠商，對方說：「我們已經收到，會盡快處理。」到了下午三點，系統還是不能用，再打過去，還是那句「工程師在處理了」。你翻出當初的維護合約，上面寫的是：「乙方應於接獲通知後，盡速協助處理。」盡速是多快？合約沒有寫。
我是熊董，台灣川輝科技創辦人。創業七年，經手超過 252 個案子、32 個以上產業，一年交付 2,000 萬以上的客製系統。系統上線之後壞了怎麼辦，是每一份維護合約最該寫清楚、卻最常寫得最模糊的地方。
SLA（Service Level Agreement，服務水準協議）白話說，就是把「系統壞了多久要處理好」寫成數字的約定。一份能保護你的 SLA 至少要有五樣東西：嚴重程度怎麼分級、由誰判斷；回應時間和修復時間分開寫；從什麼時候開始計時、假日算不算；暫時讓系統能用算不算修好；做不到的時候怎麼處理。可用率 99.9% 這種數字看起來很專業，但對每天在用的客製系統來說，分級加上修復時限，比一個可用率百分比更實用。沒有寫成數字的「盡速處理」，在合約上等於沒有承諾。
SLA 是什麼？一句話：把「盡快」換成數字
SLA 這個詞聽起來很技術，其實概念很簡單。你叫外送，平台告訴你預計 30 分鐘送到；你寄快遞，對方說隔日送達。這些都是一種服務水準的承諾：服務的人說好在多少時間內做到什麼事。
系統的 SLA 也是一樣。它回答的是三個問題：系統出事的時候，對方多久會有人回應？多久會把問題處理好？做不到的時候，怎麼辦？
沒有 SLA 的維護合約，就像沒有約定送達時間的快遞。東西總會送到，但什麼時候到，看對方心情、看對方忙不忙、看你是不是大客戶。平常沒差，真的急的時候就很痛。
反過來說，SLA 也保護願意好好做事的廠商。時限和分級寫清楚，對方知道哪些事要放下手邊工作立刻處理、哪些事可以排進下週，不會每一通電話都被當成十萬火急。雙方對「快」的定義一致，合作才走得長。
「回應」和「修好」是兩件事
這是 SLA 最常見的陷阱。很多合約寫「2 小時內回應」，老闆看了很安心，以為兩小時內系統就會恢復。實際上「回應」可能只是回你一封信說「已收到」，離修好還很遠。
下面這幾個名詞，是你在 SLA 裡一定會看到的，我用白話解釋，並寫出你要注意的地方。
| 名詞 | 白話意思 | 老闆要注意的地方 |
|---|---|---|
| 回應時間 | 多久內有人開始處理 | 「已收到」不算回應，要有人實際開始查 |
| 修復時間 | 多久內恢復正常使用 | 這才是你真正在意的數字，一定要寫 |
| 暫時處置 | 先讓系統能用，根本原因之後再修 | 要寫清楚暫時處置後，根本修復的期限 |
| 服務時段 | 計時算哪些時間 | 只算上班時間，週五晚上出事要等到週一 |
| 可用率 | 一段時間內系統能用的比例 | 要問怎麼量、排不排除預定的維護時段 |
| 嚴重程度分級 | 不同問題有不同時限 | 要寫誰判斷、有爭議時怎麼辦 |
其中「服務時段」最容易被忽略。同樣寫「4 小時內修復」，如果只算上班時間，週五下午五點出事，可能要到週一中午才算超時。你的生意如果週末也在跑，這一條一定要談。
可用率 99.9% 聽起來很厲害？先換算成分鐘
很多廠商會在提案裡寫「系統可用率 99.9%」。數字越多個 9，看起來越專業。你的直覺是對的，可用率越高確實越好。但先把它換算成你感受得到的單位。
一個月以 30 天計算，總共是 43,200 分鐘。可用率 99.9%，代表一個月最多可以停大約 43 分鐘；99.5% 是 216 分鐘，大約 3.6 小時；99% 是 432 分鐘，大約 7.2 小時。這只是算術，你自己按計算機就能驗證。
真正的問題在於，可用率是一個「平均數」。一個月停 40 分鐘，可以是分散在半夜的幾次小中斷，你根本沒感覺；也可以是剛好在月底結帳那天下午停 40 分鐘，整個財務部卡住。兩種情況的可用率一樣，對你的傷害完全不同。
而且還要問：可用率怎麼量？誰量？預定的維護時段排不排除？如果排除，廠商可以把很多停機都歸在「預定維護」裡，數字當然好看。
所以我的看法是：對大型雲端服務，可用率是合理的指標；對中小企業每天在用的客製系統，與其爭一個百分比，不如把嚴重程度分級和修復時限寫清楚。你在意的不是一個月平均停了幾分鐘，而是出事那一次，多久能恢復。
嚴重程度怎麼分？一張分級表就夠
SLA 的核心是分級。系統完全打不開，跟某個報表的欄位對不齊，不可能用同一個時限處理。分級的原則只有一個：看對營運的影響，不是看技術上難不難。
| 等級 | 判斷方式 | 常見例子 | 處理原則 |
|---|---|---|---|
| 一級：停擺 | 主要作業完全無法進行，沒有替代方案 | 系統打不開、無法開單或出貨、資料錯誤持續擴大 | 最短時限，不分時段處理 |
| 二級：嚴重 | 部分功能異常，有替代方案但很吃力 | 某一類單據開不出來、某個串接中斷 | 次短時限，暫時處置後再根本修復 |
| 三級：一般 | 不影響作業，但使用上不便 | 報表格式跑掉、某個查詢變慢 | 排入例行處理 |
| 四級：調整需求 | 系統沒壞，是想改 | 加欄位、改流程、新報表 | 不屬於 SLA，走維護範圍或另行開發 |
第四級特別重要。很多 SLA 的爭議，其實是把「想改」當成「壞了」。老闆覺得報表應該多一欄，打電話說系統有問題，廠商說這不是問題是新需求，兩邊都覺得對方不講理。把這一級明確寫出來，雙方都省事。
至於誰判斷等級，我建議寫成：由通報方先依分級表判定，雙方有不同意見時，先依較高等級處理，事後再檢討。這樣出事的當下不會浪費時間在吵這算幾級。
以川輝自己的維護來說，我們承諾的是：重大問題通報後 24 小時內修補，高風險問題 72 小時內處理。這兩個時限寫在維護條件裡，不是口頭說說。你的廠商時限不一定要跟我一樣，但一定要有數字。
合約裡的 SLA 條款要怎麼寫？逐條給你
下面這幾條，是一份維護合約裡 SLA 段落該有的內容。你可以直接拿去對照手上的合約，缺哪一條補哪一條。
- 分級定義：用上面那種表格寫，附例子，並寫明誰判斷、有爭議時怎麼辦。
- 通報管道：用什麼方式通報才算數，電話、表單、LINE 還是信件。口頭通報要不要補書面。
- 計時起點：從通報成立那一刻開始算，不是從工程師看到訊息開始算。
- 服務時段：每一級分別是全天候計時，還是只算上班時間。
- 回應與修復時限：每一級各寫兩個數字，回應時間和修復時間。
- 暫時處置的規則：先恢復使用算不算達成，根本原因要在多久內修好、要不要交說明。
- 排除條款：哪些情況不算在 SLA 裡，例如客戶自行修改造成的問題、第三方服務本身中斷、不可抗力。排除要具體，不能寫「其他非乙方可控制之因素」這種什麼都能塞的句子。
- 未達成的處理：做不到怎麼辦。可以是服務費折抵、可以是提高等級處理，比例和方式雙方約定，但要寫。
- 紀錄與報告：每次事件要有編號、時間軸和處理說明，每月或每季彙整一份。
第七條和第八條最常被省略。沒有排除條款，雙方會為了「這算不算你的責任」吵架；沒有未達成的處理，SLA 就只是一個願望。維護合約其他該寫的條款，例如範圍、原始碼、交接，可以對照系統維護合約要寫什麼那篇的 12 項。
出事那一天，你這邊也要準備好三件事
SLA 不只是對廠商的要求，也是對自己公司的要求。很多事件拖很久，不是廠商慢，而是公司內部沒人知道該怎麼通報、通報了也講不清楚。
第一，指定通報窗口。公司裡要有一到兩個人負責通報，其他人遇到問題先找他，不要十個人分別打給廠商，各講一個版本。窗口要知道分級表，能當下判斷這是幾級。
第二，通報時講清楚四件事：什麼時候開始的、哪個功能、影響多少人或多少單、畫面上出現什麼訊息。最好附上截圖。這四件事講清楚，對方的回應時間就能直接用在處理問題上，不用花在來回追問。
第三，事先想好停機時怎麼撐。系統停的那幾個小時，訂單怎麼接、貨怎麼出，要有一個暫代的做法，例如先用紙本或固定格式的表單記下來，恢復後再補登。這個暫代做法平常就要讓相關的人知道，不要出事當下才想。
事件處理完之後，要求對方給一份簡短說明：原因是什麼、怎麼修的、怎麼避免再發生。同樣的問題發生第二次，就該拿出來檢討，而不是每次都當作新的事件。
SLA 寫得再漂亮，做不到也沒用
講完怎麼寫，我要講一句很實際的話：SLA 是寫在紙上的，能不能做到，看的是對方背後有沒有撐得起這個承諾的條件。
你可以從三個地方看出真假。
第一，問他出事的時候是誰接。如果整個團隊只有一個人懂你的系統，那個人生病、出國、在處理別的客戶，SLA 寫多短都沒用。要問清楚有沒有第二個人能接手，系統文件夠不夠讓第二個人看懂。
第二，問他怎麼知道系統壞了。好的維護方會有監控，常常在你發現之前就已經在處理。只能等你打電話才知道的，修復時限自然會比較長。
第三，問他要你提供什麼。主機帳號、錯誤畫面、重現步驟，有些前提是你這邊要配合的。把這些事先講好，出事時才不會互相等。
這也是為什麼很多老闆在考慮自己養工程師還是簽維護約，其實是在比「誰撐得起 SLA」。只靠一位工程師的編制，請假或離職時就會出現空窗；這筆帳怎麼算，可以看自己養工程師還是簽維護約。維護費本身的計費邏輯，我在系統維護費怎麼算才合理拆過。川輝的維護月費 2 萬元起，依系統規模報價，維護期內書面功能清單內的介面、欄位、報表呈現調整不另收費，這也是我們能把分級寫清楚的前提：哪些是壞了、哪些是調整，在簽約時就說好。
常見問題
SLA 和保固有什麼不同？
保固是說系統交付後一段時間內，原本該做到卻沒做到的問題免費修；SLA 是說出了問題，多久內要處理好。保固回答「要不要收錢」，SLA 回答「多快」。兩者可以同時存在，合約裡最好分開寫。
中小企業的系統需要 SLA 嗎？還是大公司才需要？
只要系統停一天會影響出貨、收款或服務客人，就需要。SLA 不一定要寫得很複雜，一張分級表加上每級的回應和修復時限，就已經比「盡速處理」好很多。
廠商做不到 SLA，可以要求賠償嗎？
要看合約怎麼寫。合約有寫未達成的處理方式，例如服務費折抵，就可以依約主張；沒有寫的話，通常只能回到一般的違約爭議，曠日費時。所以重點是簽約時就把未達成的處理寫進去，其他簽約前該問的問題，可以參考簽 ERP 合約前一定要問的 12 個問題。
SLA 的時限寫越短越好嗎？
不一定。時限越短，對方要投入的人力和監控越多，費用自然越高。合理的做法是依影響分級：真正會讓營運停擺的一級問題時限要短，不影響作業的問題排入例行處理即可，錢花在你真正在意的地方。
「盡速處理」不是承諾，數字才是
講到底，SLA 不是一份法律文件裡的技術附件，它是你跟維護方事先講好「出事時誰該做什麼、多快做完」。分級寫清楚、回應和修復分開寫、計時和例外講明白，出事那天就不用吵，只要照著做。
如果你手上的維護合約只寫了「盡速處理」，或者你根本不確定系統出事時該打給誰，可以先看看系統維護與接手是怎麼約定的，再回頭檢查自己的合約缺了哪幾條。
