磨人認為 SLA（服務水準協議）的價值在於兩件事：問題怎麼分級，以及約定沒有達成時有什麼後果。回應與修復的時限依專案的系統、使用者與預算約定，寫進合約，因此本文不提供任何時限數字。以下整理 SLA 值得寫進去的項目，以及每一項為什麼要寫。
SLA 與 SLO 的差別在於未達成時有沒有後果
Google 的《Site Reliability Engineering》在服務水準目標一章區分指標（SLI）、目標（SLO）與協議（SLA）：SLA 是與使用者之間明示或默示的合約，內容包含達成或未達成 SLO 的後果，最容易辨認的後果是退費或罰款（Jones 等，2017）。判斷方式是看 SLO 沒達成時會發生什麼事，沒有明確後果的，幾乎就是 SLO。
- 一項服務目標例如某項功能的可用程度
- 查看未達成時的後果條款
- 條款載明未達成時的後果，例如退費或罰款屬於 SLA
- 沒有明確後果幾乎就是 SLO只是努力的方向，沒有可執行的約定
依 Google《Site Reliability Engineering》的區分。後果的具體內容與時限依專案約定。
合約若只列出目標值，沒有寫未達成時的處理，條款就只是雙方的期待，沒有可執行的內容。該章同時建議目標不要照目前的表現來訂，條文保持簡單，並避免「永遠可用」這類絕對說法。
同一頁也說明，SRE 通常不參與制定 SLA，因為 SLA 與商業和產品決策緊密相關。放到公部門採購，後果與範圍需要業務單位與採購單位共同決定，開發團隊的角色是說明可行的做法與限制。
問題依影響範圍分級，處理順序隨之決定
磨人處理回報時，先判斷問題的影響範圍，再排處理順序。下表是寫進合約時可採用的分級結構，各級的回應與修復時限依專案約定填入，本文不給數字。
| 優先順序 | 影響範圍 | 處理方式 |
|---|---|---|
| 最高 | 全站無法使用，或資料內容發生錯誤 | 優先處理，時限依專案約定 |
| 次高 | 部分功能異常，但有替代操作可以完成工作 | 排在最高優先之後處理，時限依專案約定 |
| 排入更新 | 介面文字調整與非急迫需求 | 納入下次更新處理 |
分級也用在判斷通知的性質。網站改版之後，使用者留存的舊連結仍會被訪問，搜尋引擎管理工具因此會寄來找不到頁面的通知。這類通知多半來自歷史舊連結，開錯網址本來就會回應找不到，不需要即時處理；頁面重新導向類的通知同樣先不處理。專案團隊透過固定的溝通管道轉來詢問時，磨人把分級的判斷與原因寫在同一則回覆，專案團隊接受後暫不動作。
系統發生問題時，磨人會安排人力即刻處理。事後的通報、分級、修復與報告流程，見系統異常時的處理流程。
錯誤修正與新需求在報價單上分成兩欄
磨人建議報價單在簽約前就把工作分成兩欄：錯誤修正指合約內的功能不能正常運作，新需求指超出合約範圍的項目，另行報價。兩欄的定義對照合約範圍與驗收項目，簽約前由雙方確認。簽約前的其餘查核項目，可參考軟體外包廠商的評估表與簽約前查核項目。
說明報價單的做法。各級處理的時限依專案約定。
分開之後，每一筆回報進來都可以先歸類：錯誤修正進入上一節的分級，新需求先報價，由機關決定是否納入。超出約定範圍的機會，磨人以主動提案與 POC 的方式向專案團隊說明，再由機關決定，做法見約定範圍之外的 POC。
維護公告、備份與資料歸屬為什麼要寫進去
以下幾項不屬於問題的回應與修復，卻決定機關能否安排人力、能否還原資料、能否更換廠商。磨人建議在合約中逐項寫明，頻率與時限依專案約定。
- 預定維護的事前公告：寫明公告的對象與管道。維護會讓服務暫停或變更，機關需要事先通知使用者，並避開活動期間。
- 資安事件的通知時限：寫明廠商通知機關的時限與內容。機關有自己的法定通報時限，下一節說明。
- 資料備份的固定頻率：寫明頻率與涵蓋的資料範圍。有了頻率，才知道最壞的情況下會損失多少資料。
- 合約終止後的資料匯出：寫明資料歸屬於機關，終止時可完整匯出。換廠商時，接手方才拿得到完整的資料。
資料匯出與交接相連，接手方需要完整資料與系統說明，才能延續既有功能。設計標與工程標之間的知識延續，見從設計標到工程標的系統知識延續；維護公告與週期檢查的日常做法，見上線後的例行維運。這幾項都是 SLA 值得寫進去的項目，是否納入、寫到什麼程度，依專案約定。
公部門的法定通報時限由機關負責
公務機關知悉資通安全事件後，須在法規規定的時限內，至主管機關指定的系統平臺通報，數位發展部資通安全署的資安法常見問題引述了這項規定（數位發展部資通安全署，2026）。通報的責任在機關，廠商在 SLA 中的資安事件通知時限，目的是讓機關在法定時限內拿到足夠的資料。條文與事件等級的細節，以法規系統的現行規定為準。
機關自身的應辦事項依責任等級而定。依資通安全責任等級分級辦法，機關分為 A 至 E 級，同時符合多個等級時取最高級，各級依辦法附表執行應辦事項。簽約前先確認機關的等級，再把需要廠商配合的應辦事項列入 SLA。
主管單位安排的例行檢查，是另一種期限的來源：期限由主管單位規定，廠商配合修正並留下紀錄。以每月的例行主機掃描為例，期限由主管單位規定，磨人依期限修正並回覆處理說明，專案團隊再回報主管單位。
SLA 中與這類期限相關的條款，寫的是廠商接到報告後的處理流程與回覆方式，期限本身依主管單位的規定。報告拿到之後的修補優先序與複測，見弱點掃描報告拿到之後的處理；回覆與紀錄如何留存為交付證據，見公部門專案的交付與維運證據。
合約條款與合作關係互相補充
Goo 等人對南韓 IT 主管做的問卷研究，結果支持正式合約與關係治理互補：結構完整的 SLA 對關係規範、和諧的衝突解決與相互依賴有顯著的正向影響，SLA 除了衡量供應商績效，也有助於雙方夥伴關係的發展（Goo 等，2009）。同一研究也發現，SLA 中的「變更」特性可能削弱信任與承諾，較像關係治理的替代。
變更因此是 SLA 中需要用心寫的一項。磨人建議把變更的提出方式與報價方式寫明，也就是前一節報價單上的兩欄。合約條款與關係治理如何分工，見長期委外合作的兩條線：合約條款與關係治理。
磨人配合教育部專案，從設計標承接到工程標，長期維運的合作情形可見戶外教育資源平臺的案例。
不適合直接套用數字的情況
以下情境直接引用其餘系統或業界的數字，容易訂出不合用的條款。
- 尚未上線的系統：沒有使用紀錄可參考，條款先寫分級與處理流程，目標值留待上線後依實際使用情形再約定。
- 低流量的服務：以比例計算的指標容易受少數幾次異常影響，目標值要依實際使用量另訂。
- 只運作一段期間的活動網站：條款依階段拆開寫，活動期間的重點是處理順序與人力安排，資料保存與匯出放在活動結束後。
SLA 的目標值依單一系統的使用情境與使用者需要約定，不照目前的表現反推，也不搬用其餘系統的數字。
開始前要準備什麼
磨人的長期維運與平台建置在討論 SLA 時，建議先備妥下列資料，條款的時限與後果再依專案約定。
- 系統中使用者最依賴的功能，以及這些功能停擺時的影響範圍。
- 合約內的功能範圍與驗收項目，作為區分錯誤修正與新需求的依據。
- 機關的資通安全責任等級，以及應辦事項中需要廠商配合的部分。
- 主管單位已規定的檢查項目，以及修正期限的來源。
- 資料的歸屬、終止時的匯出格式與接手對象。
- 預定維護的可能時段，以及由誰向使用者公告。
備妥資料後，可以說明系統現況與合約條件，磨人會依此提出適合該專案的 SLA 項目，不預先套用固定的時限數字。
