軟件支援 SLA（服務水平協議）是一份書面協議，訂明支援涵蓋哪些範圍、問題須在多長時間內處理，以及各方分別負責哪些部分。有了它，企業與支援團隊對「誰負責照顧這套系統」就有可以核對的共同標準。
SLA 涵蓋甚麼
一份實用的 SLA，除了回應時間，通常還會列明：
- 支援範圍：包括哪些應用程式、環境、整合和設備，以及哪些不在範圍內。
- 回應時間與修復時間：回應時間指多久內有人確認並開始跟進；修復（或解決）時間指多久內恢復服務或提供臨時解決方法。兩者是不同的目標，應按嚴重程度分別訂明。
- 服務時間：何時可以通報問題、團隊須在何時處理，以及公眾假期如何安排。
- 版本發布時段：計劃中的更改何時可以上線、如何事先通知，以及緊急修補與一般更新有何分別。
- 報告：報告包括哪些內容，例如已處理的事故、未完成的項目和重複出現的問題。
自訂系統的責任分界
自訂系統最容易因責任不清而拖延處理。建議在事故發生前，先寫下以下三個問題的答案：
- 程式碼誰擁有？確認誰持有原始碼庫、雲端帳戶、網域和軟件授權，以及誰有權批出存取權限。
- 誰可以更改正式環境？訂明由誰批准更改、誰負責部署，以及出現問題時如何還原。
- 第三方 API 故障由誰跟進？付款、訊息或地圖等服務，由其供應商負責。支援團隊可以偵測故障、通知用戶、執行事先議定的應變辦法，並向供應商報障，但通常無法承諾供應商何時修復。SLA 應清楚寫明這一點。
接手舊有系統前的交接清單
支援團隊接手承繼下來的系統前，至少應檢視以下項目：
- 原始碼、建置步驟，以及能否順利部署到測試環境
- 主機、網域、證書，以及由誰支付費用
- 管理員帳戶、密鑰和存取名單，包括已離職員工和過往的供應商
- 資料庫、備份，以及有否試過成功還原
- 第三方服務、API 金鑰和續期日期
- 現有文件、已知缺陷和過往的事故記錄
- 業務繁忙時段，以及對公司最重要的工作流程
在這個階段發現的缺口，比在系統故障時才發現容易處理。部分系統可能須先經過一段穩定期，SLA 的目標才切合實際。
SLA 如何配合監察和自動化測試
SLA 能否落實，取決於背後有沒有可靠的訊號。監察系統可用性、錯誤、備份和整合失敗，可以讓團隊比用戶更早發現問題；若與嚴重程度規則掛鈎，正確的警報就能觸發相應的跟進。自動化測試針對關鍵操作流程，可以檢查修補或新版本有沒有影響其他功能，令發布時段更安全、更短。兩者都不能取代支援流程，但都有助達成和量度回應及修復目標。
technine.io 在託管支援及 SLA頁面介紹了處理方式，包括如何檢視、界定、穩定系統，然後提供持續支援。
常見問題
有 SLA 就等於 24x7 支援嗎？
不是。服務時間是協議的一部分，可以只限辦公時間、延長時間，或只為指定的關鍵服務提供全日候命。應按系統故障對業務的影響和可承擔的預算來選擇，並確認非服務時間的通報如何處理。
緊急和一般問題如何區分？
透過有清楚定義的嚴重程度分級。例如系統無法使用，或令付款、出入受阻，屬於緊急；介面外觀瑕疵或報表格式調整，則屬一般。每個級別各有回應和修復目標，SLA 也應說明由誰判定級別，以及如何調整。
回應時間等於修復時間嗎？
不等於。快速回應只代表問題已獲確認並開始跟進。修復可能需時更長，特別是成因在第三方時，所以兩者應分開議定。