SLA 是什麼？SLA 是 Service Level Agreement 的縮寫，中文稱為服務水準協議，是服務提供者對客戶的服務承諾，寫明雙方責任、服務內容、預期的績效水準，以及問題回報、處理與終止的要求。放進網站與系統維護合約時，SLA 要回答四件事：服務要維持多穩定，也就是可用率目標；出問題後多快回應、多久恢復；資料能還原到哪個時間點；沒做到時怎麼補償。每一項都要有定義、量測方式與例外，才不會只是一句「穩定運作」。
SLA 的定義：一份有後果的服務承諾
美國國家標準與技術研究院（NIST）的詞彙表把 SLA 描述為服務提供者對一或多個客戶的承諾，涵蓋責任、服務類型、預期績效（例如可靠度、可接受的品質與回應時間），以及回報、解決與終止的要求。
Google 工程團隊撰寫的網站可靠性工程（SRE）一書則點出 SLA 和一般目標的差別：SLA 是與使用者之間明示或默示的契約，包含達成或未達成目標時的後果。廠商提案寫「我們會盡快處理」只是描述；合約寫明「嚴重問題在約定時限內回應，未達成時依附表抵免服務費」才是 SLA。它的用處是把維護品質變成雙方都能查核的紀錄。
SLA、SLO 與 SLI 差在哪
談服務水準常會看到三個縮寫，它們是從量測到承諾的三個層次：
| 名稱 | 意思 | 網站維護的例子 |
|---|---|---|
| SLI（服務水準指標） | 針對服務某一面向、經過仔細定義的量化指標 | 首頁正常回應的比例、表單送出成功的比例 |
| SLO（服務水準目標） | 以 SLI 衡量的目標值或範圍 | 內部訂定的可用率目標、回應時間上限 |
| SLA（服務水準協議） | 對客戶的契約，含達成或未達成目標的後果 | 未達目標時的服務費抵免、改善報告 |
SRE 書中的分辨方式是問「沒達到目標時會怎樣」，如果沒有明確的後果，幾乎可以確定它只是 SLO。企業端要看的，是寫進合約、有後果的那一份。
網站與系統維護 SLA 常見指標
- 可用率目標：量測週期內服務可以正常使用的時間比例，要寫明量測哪些網址或功能，例如首頁、會員登入、結帳或預約、對外 API。
- 回應時間：從問題回報到廠商開始處理的時限，依嚴重等級分開訂。
- 復原時間目標（RTO）：NIST 定義為系統元件可以停留在復原階段、而不對業務流程造成負面影響的整體時間長度，可用來約定重大故障後多久恢復服務。
- 復原點目標（RPO）：NIST 定義為中斷後資料必須還原到的時間點，它決定備份要多頻繁；每天異動的訂單、預約資料，和久久更新一次的形象頁面，可以容忍的資料遺失範圍並不相同。
- 安全更新時程：主程式、外掛與套件的例行更新頻率，以及重大漏洞公告時的處理方式。
- 報告內容：每期的可用率紀錄、事件清單、處理時間與備份還原測試結果。
指標不必全部採用，先挑出停擺時會影響營運的功能，再決定哪些寫進承諾。
可用率目標怎麼定義才不會各說各話
訂目標之前，要先把「什麼算停機」寫清楚。以 Google Workspace 官方 SLA 頁為例，停機依伺服器端的錯誤率判定，可用率按日曆月計算：當月總分鐘數扣掉停機分鐘數，再除以總分鐘數。網站維護合約可以照這個結構補齊：
- 停機的判定：整站無法連線才算，還是登入、結帳等關鍵功能失效也算；回應過慢是否列入。
- 量測方式：由哪一方的監控工具、多久檢查一次，紀錄不一致時以哪一份為準。SRE 書也提醒，只在伺服器端量測可能漏掉影響使用者的問題。
- 排定維護：事先通知的維護時段是否不計入，要提前多久通知。
- 相依服務：主機、雲端服務、金流或通訊平台故障時是否排除。維護廠商承諾的水準不宜高於底層服務自己的 SLA，否則難以落實。
嚴重等級與回應時限怎麼訂
同一份 SLA 裡，不同問題套用不同時限。網站與系統可以參考下表分級，實際時限依營運需求與預算議定：
| 等級 | 網站與系統的情境 | 處理原則 |
|---|---|---|
| 嚴重 | 全站無法連線、結帳或預約中斷、疑似遭入侵 | 全天候受理，先恢復或隔離，再追查原因 |
| 高 | 重要功能異常但有替代做法 | 服務時段內優先處理，提供暫時解法 |
| 中 | 個別頁面錯誤、特定瀏覽器版面跑位 | 排入一般處理順序 |
| 低 | 文字修改、操作諮詢、功能建議 | 依維護時數或另案報價 |
另外要寫明服務時段與國定假日怎麼算、時限從哪個回報時間點起算、等級由誰判定。涉及個資或資安事件時，依法需要通報的部分應依規定時限同步辦理，不能只看 SLA。
未達標時的補償與罰則怎麼寫
補償條款決定 SLA 有沒有約束力。以 Google Workspace 官方 SLA 頁為例，可以看到雲端服務的寫法：
- 補償形式是服務抵免，依帳單方式以延長服務天數或金額抵免提供，多寡依當月可用率分級。
- 客戶要在符合資格後的期限內開支援案件通知，逾期就喪失領取抵免的權利；單月抵免另有上限。
- 條款寫明，對於未達成 SLA 的情況，SLA 所列內容就是客戶全部且排他的救濟方式。
- 文件中明示排除的服務、Google Workspace Essentials Starter 版本，以及不可抗力、客戶或第三方設備造成的問題、客戶或使用者違反協議的行為，都不適用 SLA。
簽網站或系統維護合約時可以對照：抵免怎麼算、有沒有上限、由誰在多久內申請；多次未達標時能否要求改善計畫或終止合約；資料遺失等重大損害能否另外求償。這些條件沒寫清楚，出事時就容易各自解讀。
SLA 附件的寫法與簽約前檢查
SLA 可以寫成維護合約的附件，主約處理費用、權利與保密，附件依序寫：名詞定義（停機、事件、回應、恢復、排定維護）、服務範圍與責任分界（主機、網域、外部 API 由誰負責）、指標與目標、量測與報告、事件回報與升級、例外與排除、補償與終止、檢討週期。拿到廠商草案時，逐項確認：
- 是否只有「全年無休」「即時處理」這類形容詞，卻沒有定義。
- 回應時間和恢復時間是否分開寫。
- RPO 是否對應實際備份頻率，備份有沒有做過還原測試。
- 報告是否附可查證的紀錄，而不只是結論。
- 要求全天候處理時，廠商是否有對應的人力安排。
SRE 書也提醒不要只依目前的表現訂目標，可以從業務能接受的影響回推。整體資訊維運的委外選商，可參考資訊委外的服務範圍與合約重點；上線前的驗證方式則見系統測試的類型與驗收前檢查。
常見問題
SLA 一定要寫可用率嗎？
不一定。形象網站可能只需要回應時間與備份條款；有線上交易、預約或會員功能的網站，關鍵功能停擺會直接影響營運，就適合加上可用率目標，並寫清楚量測對象。
SLA 和保固期有什麼不同？
保固是針對交付成果本身的瑕疵，在約定期間內修正；SLA 則約定持續提供服務時的品質，例如可用率、回應與恢復時間。兩者可以並存，合約要寫清楚各自的範圍與期間。
主機商已經有 SLA，維護廠商還需要另外訂嗎？
需要分開看。主機商的 SLA 範圍以各自條款為準，若只涵蓋主機與網路，網站程式錯誤、外掛衝突或內容被竄改就不在範圍內。維護廠商的 SLA 處理應用程式層，兩份要對照，避免出事時互相推給對方。
小型企業的網站也需要 SLA 嗎？
條款可以精簡，但至少寫清楚回報管道、嚴重問題的回應時限、備份頻率與還原方式，以及報告內容，網站出問題時才知道該找誰、多久會有人處理。
SLA 簽了之後可以修改嗎？
可以，建議在合約中約定檢討週期與修訂程序。網站改版、新增結帳或預約功能時，原本的指標可能不再適用，雙方依報告紀錄討論後，以書面更新附件。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
簽維護合約前，先列出網站與系統中停擺會影響營運的功能，標出每項能接受的中斷時間與資料遺失範圍，再請廠商依同一份清單提出 SLA 與報價，比較時才有共同基準。
京采的網頁設計服務可以協助盤點網站與系統的關鍵功能，規劃主機、備份與監控架構，並把維護範圍、事件回報方式與報告內容寫成清楚的規劃。想討論現有網站的維護條款，歡迎與我們聯繫。
