警政系統維運委外的 SLA，關鍵不在「99.9%」這個數字，而在每一條承諾旁邊有沒有寫清楚三件事：怎麼量、誰來量、沒達到怎麼辦。多數維運標案的服務水準條款只有兩三行——「系統稼動率應達 99.9% 以上」「故障應儘速修復」——上線第一年通常相安無事，因為廠商還在，人也還記得。問題會在第二年出現：窗口換人、案件量長大、某天下午檢舉平台送不了件，雙方翻出合約才發現，那幾行字沒有辦法用來判斷誰該做什麼。
稼動率 99.9% 換算成每月可中斷幾分鐘、高可用架構要寫進哪些量測點，我們在民眾檢舉平台連假爆量怎麼撐已經寫過，這篇不重述；規格書階段罰則條文要分成哪三類，見科技執法標案規格書怎麼寫。這篇專講維運期的服務水準條款本身——回應時效怎麼分級、扣款級距怎麼訂、量測爭議怎麼在簽約前就擋掉。
為什麼「稼動率 99.9%」一句話不算 SLA？
因為它只有承諾值，缺了另外兩格。一條可執行的服務水準條款，每一項都要成對出現三個欄位：承諾值、量測方法、未達標的處理。少了量測方法，履約期間雙方會用不同的算法得到不同的數字；少了未達標的處理，條文就只是一句期待。
另一個常見的缺口是只訂了可用性，沒訂其他三類。稼動率是結果指標，它告訴你系統倒過幾分鐘，卻管不到「倒下去之後多久有人接手」。維運期真正會被追問的，是下面這四類：
| 類別 | 要承諾什麼 | 最常被漏掉的欄位 |
|---|---|---|
| 可用性 | 月稼動率、計畫性維護的時段與上限 | 從哪一個位置量、連續幾次探測失敗才起算中斷 |
| 事件回應 | 依嚴重度分級的回應、暫時恢復與結案時效 | 嚴重度由誰認定、認定有爭議時怎麼處理 |
| 例行維運 | 備份與還原演練頻率、資安更新時效、憑證續期、監控報表 | 演練要留什麼紀錄、報表送給誰、多久送一次 |
| 支援窗口 | 服務時段、通報管道、問題升級路徑 | 聯絡人異動的通知義務與生效時間 |
這四類寫齊了，SLA 才是一份可以拿來對帳的文件。只寫可用性的合約，等於把其餘三類全部交給廠商的自由心證。
回應時效怎麼分級？先用「業務影響」定義嚴重度
分級的第一個原則：嚴重度用業務影響定義，不要用技術現象定義。寫「伺服器當機」一定會有爭議——資料庫慢到民眾送件逾時、案件卡在複核佇列出不去，這兩種情況都不算「當機」，但承辦人一樣做不了事。改成用業務影響描述，判定就不需要吵技術細節。
| 級別 | 用業務影響這樣寫 | 確認回應 | 暫時恢復 | 結案報告 |
|---|---|---|---|---|
| P1 嚴重 | 無法收件或無法入案，機關作業全面中斷 | 30 分鐘 | 4 小時 | 5 個工作日 |
| P2 高 | 主要功能受損但有替代做法，例如批次匯出失敗 | 2 小時 | 1 個工作日 | 10 個工作日 |
| P3 中 | 單一功能異常，不影響當日作業進度 | 1 個工作日 | 5 個工作日 | — |
| P4 低 | 諮詢、設定調整、改善建議 | 2 個工作日 | 依雙方議定 | — |
上表的數字是常見的起草基準，不是標準答案，實際級距要看系統的業務性質調整。真正要留意的是欄位設計本身，以下四點比數字重要：
1. 回應、暫時恢復、根因排除要分開計時
「4 小時內修復」這種寫法會讓廠商在複雜故障上必然違約，也會逼他們用重開機草草了事。正確的拆法是三段：確認回應（有人接手並回報初步研判）、暫時恢復（讓業務能繼續走，容許繞道做法）、結案報告（根因、修正措施與預防作為）。分開寫，廠商才會先讓業務活過來，再回頭處理根因。
2. 計時起點要綁在「有紀錄的通報」上
以工單系統或指定通報專線留下紀錄的時間為計時起點，不是以承辦人口頭告知為準。同時要寫明暫停計時的條件——例如需要機關端提供測試帳號或開放存取，而聯繫不到窗口的期間不計入。沒有暫停條款，廠商會在這一點上反覆爭執；有了暫停條款，就要一併規定廠商必須留下聯繫紀錄。
3. 服務時段要分層定義，不要一句話帶過
把時段拆成「約定服務時段」（例如上班日的上班時間）與「延伸時段」（其餘時間），再規定哪些級別適用哪一種：P1 不分時段計時，P2 以下在延伸時段可以順延至次一服務時段起算。這樣寫，機關拿到的是真正需要的保障，廠商也不必為了低嚴重度事件在深夜備人力——那份人力成本最後還是會回到報價裡。
4. 「到場時效」只在有現場端設備時才寫
路口設備、機房實體主機這類需要有人動手的項目，才有必要訂到場時效，而且要寫明到場地點與交通時間的計算方式。純軟體或託管在機房的系統要求人員到場，實務上沒有意義，只會讓廠商把交通與待命成本灌進報價。該訂的是遠端處理啟動時效，不是到場時效。
扣款條款怎麼訂才有拘束力，又不會嚇跑投標廠商
扣款的目的是讓廠商把資源留在這個案子上，不是懲罰。訂得太輕沒有作用，訂得太重會直接反映在投標價，或是根本沒有廠商投。實務上有四個原則：
- 基數用「當月維運費」，不要用契約總價。以總價千分之幾計算的違約金，是為逾期交付設計的；對已經完成建置、只剩維運的廠商，那個數字幾乎沒有感覺。改用當月維運費當基數，級距才咬得住。
- 要有起扣點、級距與單月上限。常見訂法是月稼動率未達承諾值即扣減當月維運費的固定比例（例如 5%），每再低 0.1% 加扣一段，並訂出單月扣減上限（例如當月維運費的 20% 到 30%）。上限不是保護廠商，而是避免投標時把最壞情況整包灌進報價。
- 回應時效按次扣。稼動率是月結的，回應時效是逐件的，兩者要分開計算：逾時一次扣一個固定金額或固定比例，並訂單月次數上限，避免單一次大規模事件產生的連鎖工單把扣款推到不合理的程度。
- 扣款不等於損害賠償。扣款屬於價金調整，賠償是另一回事。兩者要分開條文，並寫明扣款不影響機關依法請求損害賠償的權利，否則會出現「扣完就結案」的主張。
比級距更重要的是連續未達標的處理。只有扣款、沒有退場機制的條款，等於允許廠商把扣款當成營運成本吸收。建議明訂連續三個月未達標、或一年內累計六次未達標時，機關得終止契約並啟動退場交接——退場條款本身要寫哪些內容（原始碼、資料庫與案件資料的交付格式、期限與協助義務），在規格書那篇已經列過。
免計事由不寫，扣款條款容易被認定不合理
三類情形要明文排除，而且每一類都要附程序條件，否則就會變成廠商的免責通道：計畫性維護（需提前一定工作日數書面通知、限定在低載時段、單月累計時數設上限；未依程序通知的維護一律計入中斷）、機關端因素與不可抗力（機關端網路、電力、機房環境，或機關自行變更設定所造成的中斷）、第三方介接異常（跨機關資料交換或電信線路的對端故障）。第三類要特別加一句：計為第三方事件，但廠商仍負有通報、追蹤與協助復原的義務。少了這句，對端一出事就沒有人負責推進。
稼動率由誰量、怎麼量？把爭議擋在對帳之前
同一個月，廠商的監控報表寫 99.95%，機關的感受卻是「上週三整個下午送不了件」。這種落差大多不是有人說謊，而是兩邊量的根本不是同一件事。合約要先把四件事定死：
- 量測點在哪裡。從機關內部網路量，還是從外部網際網路量？民眾使用的檢舉平台要從外部量才有意義，因為使用者遇到的問題可能出在對外線路；只給內部承辦使用的入案後台，從內網量才貼近實際。
- 探測頻率與判定規則。每一分鐘或每五分鐘探測一次、連續幾次失敗才起算中斷、恢復後連續幾次成功才算結束。這條沒寫，同一次瞬斷可以被算成 0 分鐘，也可以被算成 5 分鐘。
- 什麼才算「可用」。首頁回應 HTTP 200 不代表系統能用。建議至少加一個關鍵交易的探測，例如登入後讀取案件清單，並約定回應時間超過一定秒數即視同不可用。
- 以誰的資料為準。指定單一依據並寫進條文，廠商自有監控作為輔助佐證。兩份資料並列而沒有主從，等於把爭議留到事後。
接著規定月報要有哪些欄位：事件清單（發生與恢復時間戳、影響範圍、嚴重度）、當月稼動率的計算過程（分母是幾分鐘、扣除了哪些免計時段）、每一件事件的回應時效達標與否、以及扣款試算。報表要附計算過程，不能只給一個結論數字。這些量法應該在驗收當天就固定下來，驗收現場能驗到什麼程度、不能驗什麼，見科技執法系統驗收怎麼驗。
最後補一條申覆期限：機關對月報有疑義時，應於收到報表後一定工作日數內提出（例如 10 個工作日），逾期視為確認；爭議處理期間不影響其他無爭議款項的撥付。有了期限，對帳才不會一直往後拖；沒有期限，年底結算時翻出半年前的事件，雙方都找不到人證。
SLA 條文送出前的 8 項檢查
把草稿送出去之前，照下面八題自問一遍。每一題都能指到具體條次，這份 SLA 才算可執行：
- 每一項承諾是否都配了量測方法與未達標的處理方式？
- 嚴重度是用業務影響寫的，而不是用技術現象寫的嗎？
- 確認回應、暫時恢復、結案報告三個時間是否分開寫？計時起點綁在哪一份紀錄？
- 約定服務時段與延伸時段的計時規則，是否依嚴重度分別規定？
- 扣款基數是當月維運費嗎？起扣點、級距與單月上限都有嗎？
- 是否訂了連續未達標的解約門檻，並銜接到退場交接條款？
- 計畫性維護、機關端因素、第三方介接三類免計事由是否都寫了程序條件？
- 量測點、探測頻率、判定規則、以誰的資料為準，四項是否都指定？
另外提醒一個順序問題：SLA 不是等到要簽維運合約才寫。它的骨架應該在招標規格書階段就定好，因為回應時效與扣款級距會直接影響廠商的人力配置與報價；等決標後才談，機關的籌碼只剩下不簽約。系統上線前的準確率門檻、人工複核比例怎麼訂，則屬於另一組指標，見AI 影像辨識誤判率多少才能上線。
瑪尼國際成立於 2004 年，深耕系統開發與維運逾 20 年，以協力廠商身分參與全台多個縣市警察局交通隊的入案系統建置與維運，也長期承接政府單位與企業的網站代管。上面這些欄位不是法律意見，而是維運現場真正會被追問的項目——SLA 寫得夠具體，出事時雙方討論的是怎麼修好，而不是該不該算在誰頭上。科技執法系統的建置、入案與後續維運如果由同一個團隊負責，這條責任界線本來就會少掉一層，這也是一條龍服務在長期維運上最實際的價值。
常見問題
Q：警政系統維運 SLA 要訂哪些項目？
至少四類：可用性（月稼動率與計畫性維護時段）、事件回應（依嚴重度分級的回應、暫時恢復與結案時效）、例行維運（備份與還原演練頻率、資安更新時效、憑證續期、監控報表）、支援窗口（服務時段、通報管道、升級路徑與聯絡人異動的通知義務）。每一項都要同時寫出承諾值、量測方法與未達標的處理方式三個欄位。只寫承諾值、沒有量測方法與後果的條文，在履約期間幾乎沒有拘束力，出事時只能各說各話。
Q：SLA 稼動率未達標的扣款怎麼訂才合理？
四個原則：一、扣款基數用當月維運費，不要用契約總價，否則對已完成建置的廠商沒有實質作用；二、訂出起扣點、級距與單月扣減上限，上限不是保護廠商，而是避免廠商把最壞情況灌進投標價；三、回應時效逾時按次扣減，並訂單月次數上限；四、扣款屬於價金調整，與損害賠償要分開條文，並寫明扣款不影響機關依法請求賠償的權利。另外要訂連續未達標的解約門檻，例如連續三個月未達標或一年內累計六次，否則廠商可以把扣款當成成本吸收。
Q：維運 SLA 的稼動率要以誰的監測資料為準？
合約要指定單一依據：建議以機關端或雙方同意的第三方外部監測為準，廠商自有監控作為輔助佐證。同時要寫明量測點是從機關內部網路還是從外部網際網路量、探測頻率是每一分鐘還是每五分鐘、連續幾次探測失敗才起算中斷、恢復後連續幾次成功才算結束，以及免計時段的定義。這幾項沒有寫清楚，同一個月雙方會算出差距很大的兩個數字，爭議會落在對帳而不是修復。