企業採購線上課程時，IT 或採購有時會問：
「你們有 SLA 嗎？可以保證 99.9% 可用嗎？」
很多課程業者看到「企業客戶」就想先答應：
「可以，我們保證系統穩定。」
但「穩定」不是可執行的合約條件。
如果沒有先定義什麼叫不可用、誰負責測量、第三方服務故障算不算、多久回覆才算達標，最後實際出問題時，雙方會用完全不同的方式解讀同一句承諾。
先分清楚：SLI、SLO、SLA 是三個不同層級
Google Site Reliability Engineering（SRE）的做法很適合拿來理解。
| 概念 | 意思 | 企業課程例子 |
|---|---|---|
| 服務水準指標（SLI） | 實際量到的服務表現 | 登入成功率、網站可用率、回應時間 |
| 服務水準目標（SLO） | 內部希望維持的目標 | 每月可用性目標 99.95% |
| 服務水準協議（SLA） | 對客戶的正式承諾與未達成後果 | 低於約定水準時提供服務點數 |
順序最好是：
先知道怎麼量 → 再設定內部目標 → 最後才決定哪些要寫進對外合約。
不要先簽一個數字，再回頭想網站到底能不能量得到。
企業課程的 SLA，不一定只談「網站有沒有開」
一套企業課程服務可能同時包含：
- 公開網站。
- 會員登入。
- 課程播放器。
- 作業與測驗。
- 企業管理員報表。
- 電子郵件通知。
- 直播或預約。
- 金流與訂單。
如果 SLA 只寫：
「系統保證 99.9% uptime。」
就會立刻產生問題：
- 首頁正常，但學員不能登入，算不算停機？
- 影片 CDN 故障，網站本身正常，算不算？
- 企業自己的防火牆擋住影片，算不算？
- 直播平台故障，是否包含在課程網站 SLA？
所以第一步不是填一個百分比，而是先寫「Covered Service」到底涵蓋哪些服務。
可用性要怎麼算？先把「不可用」定義清楚
Google Cloud 的正式 SLA 會定義每月可用率、停機期間、涵蓋服務與服務點數，而不是只放一個數字。
企業課程也可以先定義：
- 是以整個網站無法存取才算停機。
- 還是核心登入／課程播放失效也算。
- 由哪一個監控點測量。
- 統計期間是每月還是每季。
- 短暫單一請求錯誤是否算停機。
例如 99.9% 的月可用率，如果以 30 天計算，大約代表每月仍有約 43 分鐘的錯誤預算。
所以 99.9% 從來不等於「完全不會停機」。
不要輕易承諾 100% 可用
任何實際系統都可能遇到：
- 主機故障。
- 網路問題。
- DNS 異常。
- 軟體更新。
- 第三方影音服務故障。
- 企業自己的網路限制。
承諾 100% 的問題不是「看起來太有自信」，而是它幾乎沒有容錯空間。
正式企業合約應該根據實際架構、歷史數據與可控制範圍設定，而不是為了成交直接選最好看的數字。
第三方服務故障，要先寫責任邊界
課程網站通常不是所有元件都自己營運。
可能依賴：
- 主機商。
- CDN。
- 影音平台。
- 電子郵件（Email）寄送服務。
- 金流。
- 視訊會議平台。
Google Cloud 與 Cloudflare 的正式 SLA 都會列出排除條款，例如服務商合理控制範圍以外的因素、客戶端軟硬體或第三方系統造成的問題。
這不代表你可以一句「第三方問題一概不負責」就結束。
比較合理的是把責任拆成：
- 你能控制的：自己的網站設定、權限、程式、更新與客服回應。
- 你能管理但不能完全控制的：主機、CDN、影音等供應商。
- 企業自己控制的：公司網路、防火牆、裝置與內部帳號政策。
即使第三方故障不列入你的可用性計算，你仍可以承諾「發現後多久通知、多久更新狀態、供應商恢復後多久驗證」。
服務可用性和客服回覆時間，要分成兩張表
企業問「SLA」時，有時其實想問的是：
「出問題後多久有人理我？」
這和網站可用率不是同一件事。
可以分成：
平台可用性
- 網站是否可登入。
- 核心課程是否能存取。
- 如何計算停機。
支援時效
- 客服服務時段。
- 多久給第一次回覆。
- 重大事故多久通知。
- 後續多久更新一次狀態。
不要用「我們 2 小時內回覆」讓客戶誤以為「所有故障 2 小時內一定修好」。
回應時間、恢復時間、永久修復時間也要分開
| 時間 | 代表什麼 |
|---|---|
| 第一次回應 | 已收到問題並開始處理 |
| 服務恢復 | 先讓使用者可以繼續使用 |
| 永久修復 | 根因完成修正 |
例如某個外掛更新造成登入問題：
- 30 分鐘內確認事故。
- 先回退版本讓服務恢復。
- 隔天再完成根因修復與測試。
這不代表第一階段回應慢，也不代表永久修復一定要和恢復服務同一時間完成。
可以用嚴重度分級，不需要所有問題都同一時效
| 等級 | 例子 | 處理優先級 |
|---|---|---|
| P1 重大 | 全體無法登入、核心課程全面無法使用 | 立即處理 |
| P2 高 | 部分企業群組無法使用重要功能 | 高優先 |
| P3 一般 | 單一帳號、報表顯示或非核心錯誤 | 一般工作時段 |
| P4 請求 | 欄位調整、功能建議、一般操作問題 | 排程處理 |
如果所有問題都承諾「30 分鐘內解決」，最後不是成本爆炸，就是承諾失去可信度。
「回覆時效」最好承諾你真的控制得到的部分
客服第一次回覆時間通常是你比較能控制的。
但永久修復時間可能取決於：
- 問題複雜度。
- 第三方供應商。
- 企業 IT 配合。
- 資料修復。
- 需要測試的範圍。
因此比起保證「所有問題 4 小時內解決」，可以承諾：
- 重大事件多久首次回覆。
- 多久提供一次狀態更新。
- 服務恢復會以最高優先處理。
- 根因分析何時提供。
企業客服分工可以搭配 企業買線上課程，誰負責開通與客服？講師、HR、系統管理員怎麼分工。
計畫性維護要不要算停機？事前定義，不要臨時解釋
網站可能需要：
- 系統更新。
- 資料庫維護。
- 主機遷移。
- 大型安全更新。
如果計畫性維護不納入 SLA，就應定義：
- 提前多久通知。
- 通常安排在哪些時段。
- 一年或一月可有多少維護窗口。
- 緊急安全維護怎麼處理。
不要網站停了之後才告訴企業「這算維護，所以不算」。
企業自己的網路問題，如何避免變成雙方互相甩鍋？
可以建立基本診斷流程：
- 確認是否只有單一員工。
- 確認不同網路是否可使用。
- 確認企業防火牆或瀏覽器政策。
- 確認課程平台外部監控是否正常。
- 確認第三方影音或 CDN 狀態。
當雙方都用相同流程判斷，就比較不會變成「你們網站壞了」對上「是你們公司網路的問題」。
SLA 要不要有服務點數或補償？看合約規模與可承擔風險
大型雲端供應商常使用服務點數（Service Credit）作為未達 SLA 的補救方式，並設定申請期限、計算方式與最高上限。
企業課程也可以思考：
- 延長服務天數。
- 延長授權期限。
- 按受影響服務比例提供點數。
- 其他事前約定的補救。
但不要在沒有估算最壞情況前，就承諾無上限賠償。
涉及正式違約責任、損害賠償或責任限制時，應由合格法律專業依實際合約審查。
小型企業案一定要做正式 SLA 嗎？不一定
如果只是：
- 20 人。
- 一次性課程。
- 三個月方案。
- 沒有 IT 採購要求。
可能只需要清楚的「支援政策」：
- 服務時段。
- 客服入口。
- 一般回覆時間。
- 重大故障通知方式。
不一定需要簽一套企業級可用性 SLA。
當客戶規模、整合深度、企業 IT 要求與合約金額提高，再逐步加上正式 SLA，通常比較合理。
先畫一張依賴服務圖，SLA 才知道責任算到哪裡
企業課程通常不是一個單一系統。即使學員只看到一個網站，背後可能經過：
DNS → CDN → 主機 → WordPress／課程系統 → 資料庫 → 影音服務 → 電子郵件 → 企業網路
任何一層失效，都可能讓學員感覺「課程壞了」。
因此正式談 SLA 前，可以先做一張依賴表：
| 依賴 | 誰控制 | 你能承諾什麼 |
|---|---|---|
| 網站程式與權限 | 課程業者 | 監控、修正、回退與狀態更新 |
| 主機／CDN | 第三方供應商 | 供應商選擇、升級通報、恢復驗證 |
| 影音平台 | 第三方供應商 | 狀態確認、替代方案與通知 |
| 企業防火牆／裝置 | 企業 IT | 協助診斷，不能直接控制 |
這樣遇到事故時，不需要現場才爭論「到底算誰的」。
更重要的是，你可以看出哪些第三方服務對整體交付最關鍵。如果影音平台掛掉就讓所有核心課程無法使用，那它即使不是你營運，也仍然是你的關鍵依賴，應該有監控、替代方案與明確通報流程。
重大事故除了修復，也要約定怎麼溝通
企業客戶在意的不只是「什麼時候好」，也在意故障期間有沒有資訊。
重大事故流程可以分成：
- 確認：判定影響範圍與嚴重度。
- 初次通知：說明已知影響、目前正在處理什麼。
- 持續更新：固定節奏回報，不讓企業一直追問。
- 恢復通知：確認核心服務已恢復並完成基本驗證。
- 事後回顧：必要時提供原因、改善項目與預防措施。
事故尚未查清時，不要為了看起來專業就急著猜根因。第一封通知可以誠實寫「目前仍在調查」，等證據完整後再提供根因分析。
對大型企業案，可以事前定義哪些 P1 事故需要事後報告；一般單一帳號問題則不需要每次都寫完整事故報告。
正式 SLA 前，先確認你能不能量得到
如果要承諾平台可用率，至少要有：
- 外部監控。
- 事故紀錄。
- 可追溯時間。
- 服務範圍定義。
- 第三方狀態資料。
不能只靠：
「那天好像有人說網站打不開。」
也不要完全只用主機商的 uptime 數字，因為主機正常不代表登入、資料庫或課程播放一定正常。
企業課程 SLA 至少要寫清楚這 9 件事
- 涵蓋哪些服務。
- 可用性怎麼計算。
- 統計期間。
- 計畫性維護怎麼算。
- 第三方與客戶端問題如何界定。
- 事件嚴重度。
- 第一次回覆與狀態更新時效。
- 未達 SLA 的補救方式與上限。
- 客戶如何提出 SLA 申請。
只寫「99.9% uptime」但沒有這些定義，實際上仍然很難執行。
一張表決定：這個企業案需要哪一層服務承諾？
| 情境 | 建議 |
|---|---|
| 小型短期企業課 | 支援政策即可 |
| 多人年度方案 | 支援時效＋基本平台目標 |
| 深度 LMS／SSO 整合 | 明確事故與責任邊界 |
| 大型企業強制採購條款 | 評估正式 SLA |
| 任務關鍵培訓平台 | 更完整可用性、監控與補救條款 |
常見問題
企業客戶要求 99.9% SLA，一定要答應嗎？
不一定。先確認服務架構、歷史可用性、監控能力與第三方依賴，再判斷能否承諾。企業提出數字不代表供應商必須無條件接受。
99.9% 是不是代表幾乎不會停機？
它仍然包含一定的錯誤預算。以 30 天估算，99.9% 約有 43 分鐘未達可用的空間；實際計算仍要依 SLA 定義。
主機商有 99.99% SLA，我可以直接對客戶承諾 99.99% 嗎？
不建議直接照抄。你的服務還可能包含網站程式、資料庫、CDN、影音與其他依賴，整體服務可用性不等於單一主機的 SLA。
第三方影音平台故障，可以全部排除責任嗎？
可以在合約中合理界定非自身控制的第三方事件，但仍應定義通知、狀態更新與恢復後驗證等處理責任。正式法律責任應依實際合約審查。
客服 2 小時回覆，是不是代表 2 小時修好？
不是。第一次回覆、恢復服務與永久修復是不同指標，應分開定義。
企業課程一定要給服務點數嗎？
不一定。可以依合作規模設計延長服務、服務點數或其他補救方式。重點是事前約定，並確認最壞情況在可承擔範圍。
結論：SLA 不是讓企業安心的一句漂亮保證，而是可量、可執行的責任邊界
企業課程要不要提供 SLA，不該從「客戶要求什麼數字」開始，而應先確認哪些服務是核心、你能量到什麼、內部實際能維持什麼，以及哪些依賴不在你的直接控制下。
先建立 SLI 與 SLO，再決定哪些指標值得寫成對外 SLA；把可用性、客服回覆、服務恢復與永久修復分開；對第三方、計畫性維護與企業自身環境寫清楚邊界。
這樣 SLA 才能提高企業信任，而不是為了成交留下未來難以履行的無限承諾。
參考資料：
Google Site Reliability Engineering｜Service Level Objectives。
Google Cloud｜SLOs, SLIs, SLAs, oh my。
Google Cloud｜Compute Engine Service Level Agreement。
Google Cloud｜Cloud Storage Service Level Agreement。
Cloudflare｜Enterprise Service Level Agreement。