SLA、OLA與UC的區別：三種協議各管什麼

Q: 在哪裡可以看到博迅的目標是怎麼設定的？

在SLA頁面，裡面列出了P1至P5的目標和兩種服務時段。如果想把你現有的協議與它對照，歡迎聯絡我們。 想把這些指標寫進合約，而不是停留在簡報上？ 博迅的管理型IT外判服務方案把 SLA 和按用戶的月費並排公開，覆蓋香港、新加坡、中國大陸和美國。查看方案與收費，或聯絡顧問。

一句話版本： SLA是服務商對客戶的承諾。OLA（營運級別協議）是服務商內部各團隊之間的承諾，讓SLA有可能兌現。UC（支撐合約）是與外部供應商簽的合約，作用相同。SLA裡的每一項目標，背後都應有一份速度不慢於它的OLA或UC。

向服務商購買IT支援時，你簽的是這三份協議中的一份：SLA。另外兩份藏在它的背後，看不到，卻決定了SLA上的數字是否現實。本文說明三者各是什麼、各方是誰、怎樣層層疊加，以及當你的IT支援是外判時，這幅圖意味著什麼。

外部定義我們在2026年10月28日查閱過：維基百科「Service-level agreement」詞條、「Operational-level agreement」詞條和「Service-level objective」詞條（均於2026-10-28查證）。「支撐合約」（underpinning contract）是ITIL的術語，我們當天沒有取得ITIL術語表的原文，因此下文對UC的說明是我們自己的白話解讀，不是引文。博迅（Brocent）的數字取自我們公開的SLA頁面。

SLA、OLA和UC有什麼區別？

最簡單的區分方法，是問每一份由誰來簽。

SLA（服務水平協議）： 服務商與客戶之間。它用客戶關心的語言寫明客戶可以期待什麼：響應、解決、服務時段、可用性、彙報。
OLA（營運級別協議）： 同一家服務商內部的團隊之間，例如服務台與網絡工程團隊。它寫明一個團隊對另一個團隊承諾做什麼、多快做到，好讓服務商守住SLA。
UC（支撐合約）： 服務商與外部供應商之間，例如營運商、軟件廠商或硬件維保公司。它寫明供應商對服務商承諾做什麼、多快做到，目的同樣是支撐SLA。

三者不是互相替代的選項，而是同一條鏈上的不同層，客戶只看得到最上面一層。

SLA是什麼，是寫給誰的？

維基百科「Service-level agreement」詞條（2026-10-28查證）把SLA描述為服務商與客戶之間的協議，通常是有約束力的合約，規定服務的某些方面，如服務質素、可用性和責任。詞條還提到，SLA通常包含服務水平目標，也就是針對正常運行時間、首次呼叫解決率等指標的可衡量目標。

SLA是寫給客戶看的。它回答的是「多快會有人接聽？」「什麼時候能修好？」「修不好我能得到什麼？」。我們的IT支援中的SLA是什麼詳細介紹了其內容，P1至P4優先級指南說明優先級如何決定目標。

同一詞條也提到，大型機構內部同樣會簽SLA，由一個部門做客戶、另一個部門做服務方。這種用法是成立的，但容易與OLA混淆，所以下文把SLA專指面向客戶的協議，把OLA專指服務商的內部協議。

OLA是什麼？

維基百科「Operational-level agreement」詞條（2026-10-28查證）把營運級別協議描述為：規定支撐SLA的各方相互依賴的關係。它寫明每個內部支援小組對其他小組的職責，包括交付服務的流程和時限。同一詞條還指出，OLA不能代替SLA，它的目的是讓多個支援團隊所做的支撐工作對齊，以交付約定的SLA。

在實踐中，OLA回答的是客戶從不過問、卻總能感受到的問題：

交接： 服務台修不好工單時，下一個團隊必須多快接手？
資訊： 工單轉出去之前必須寫明什麼，才能讓下一位工程師不必從頭開始？
時段： 哪個團隊負責哪些時段，夜間誰待命？
升級： 眼看要錯過期限時，誰會被呼叫？

沒有這些答案，SLA的目標就只是一個希望。詞條裡還有一個相關的觀點：如果支撐的OLA沒有事先建立，事後再回頭在各支援團隊之間補出協議，往往非常困難。我們的L1、L2、L3支援級別和升級矩陣兩篇文章，介紹了OLA通常要固化的交接和聯絡人。

這個名稱還有幾種變體：organizational-level、operating-level和operations-level agreement。詞條說它們含義相同。

支撐合約（UC）是什麼？

在ITIL術語裡，支撐合約是服務商與外部供應商之間的合約，目的是讓供應商的表現支撐服務商對客戶作出的承諾。（這是我們的解讀，參見上文關於來源的說明。）供應商可能是：

互聯網或專線營運商，
提供授權和支援的軟件廠商，
提供備件的硬件維保公司，
數據中心或雲平台的營運方。

UC是帶商業條款的真實合約，所以裡面往往也有它自己的SLA。區別在於雙方是誰：SLA的一方是最終客戶；UC裡服務商是客戶，外部公司是供應商。

三者怎樣配合？

從客戶往下畫出這條鏈：

客戶與服務商之間有SLA。
服務商的服務台與其工程團隊之間有OLA。
服務商與外部供應商之間有UC。

每一層都必須不慢於上一層的承諾。如果SLA寫明嚴重事件20分鐘內首次響應，那麼負責首次響應的團隊的OLA就必須讓20分鐘是可以做到的。如果SLA寫明營運商故障一小時內升級，那麼與營運商之間的UC就必須給服務商一條以這個速度聯絡到對方故障台的途徑。

檢驗的簡單辦法是做一份時間預算。取一項SLA目標，把其中包含的每一步列出來。以首次響應目標為例，步驟有：

工單到達，由系統登記。
服務台接起並判定優先級。
向客戶發出確認。

這三步合計允許的時間，必須落在SLA的數字之內。舉例說明（數字為演示算術而虛構，並非博迅的數字）：如果SLA承諾20分鐘首次響應，而內部協議允許服務台用30分鐘接起嚴重工單，那麼無論大家多努力，SLA都無法達成。算術先於人出了問題。

外判IT支援時，這幅圖是什麼樣子？

外判給這幅圖增加了兩樣東西，簽約前都值得問一問。

你自己的人也在鏈條裡

外判工程師在不知道帳號歸誰解鎖時，沒法處理帳號鎖定；沒有你的人事聯絡人批准，也沒法給新員工開通權限。這些都是客戶一側的依賴。好的協議會把它們列為客戶責任並附上時限，例如誰批准權限申請、多快批准。有的團隊會把這部分寫成IT、人事和行政之間的簡短內部協議，它在你這一側起的就是OLA的作用。如果客戶這邊的審批人響應慢，服務商的計時就應當如實說明，寫得好的暫停計時條款就能做到。

服務商的供應商也很重要

對於自己無法控制的部分，服務商的SLA最多只能和它的UC一樣強。問一問服務商怎樣處理營運商線路故障、軟件廠商平台故障或備件缺貨。誠實的答案通常是「我們會在SLA內響應並向供應商升級，並持續向您通報，但供應商的修復時間不在我們控制範圍內」。寫下來、並附上通報頻率，這是公道的回答。如果SLA對服務商根本修不了的東西也承諾了解決時間，那就有問題。

還要問服務商的目標與供應商的目標是否「背靠背」。如果服務商承諾專線四小時修復，而它與營運商的合約允許24小時，那麼這份風險要麼體現為未達標，要麼藏在免責條款的限制裡。

一個例子：辦公室斷網

這是演示用的場景，不是真實客戶。某小型辦公室在工作日上午斷網。

用戶報告斷網。辦公室與IT服務商之間的SLA寫明，影響業務的故障要在規定的分鐘數內首次響應。
服務台登記工單，確認原因在樓外，並按OLA轉給網絡團隊，OLA規定網絡團隊須多快接手。
網絡團隊依據UC聯絡營運商的故障台，UC規定了營運商的響應與修復時間。
服務商按約定間隔向客戶通報，直到營運商修好線路，然後關閉工單並記錄根因。

如果客戶問「是誰慢了？」，分層的協議讓答案很清楚。第一次回覆慢，是服務商的SLA問題；服務商內部交接慢，是OLA問題；營運商修復慢，是服務商要替客戶去管理的UC問題。沒有這些層次，答案就變成「大家都有份，又都沒有責任」。

對影響全公司的事件，請看我們關於重大事件管理流程的文章，其中講了溝通和角色。

SLA與SLO、KPI、合約有什麼區別？

這些術語有重疊，簡短對比一下。

SLA與SLO： SLO是SLA裡一個可衡量的目標。維基百科「Service-level objective」詞條（2026-10-28查證）指出，SLA是規定提供什麼服務、如何支援、時間、地點、費用、表現和各方責任的整份協議，而SLO是它具體的、可衡量的特徵。
SLA與KPI： KPI是團隊用來追蹤自身表現的任何指標。SLA目標則是服務商向客戶承諾過的KPI。
SLA與合約： SLA通常是合約裡的附件。合約管價格、期限、責任和終止。
OLA與SLA： OLA是內部的，用來支撐SLA，不能代替SLA。

如果你想了解SLA和OLA通常用哪些指標來衡量，請看我們的MTTR、MTBF與MTTA解讀和首次呼叫解決率。

買方和服務商常犯哪些錯誤？

把SLA當成全部。 單看SLA似乎很完整，但可靠與否，取決於它背後的OLA和UC。
對第三方故障承諾解決時間。 服務商可以承諾對供應商的故障響應並升級。自己無法控制的修復時間，應該放進免責條款，並配上通報規則。
OLA定得比SLA還慢。 算術先行崩潰，而被責備的是台前的人。
交接沒有負責人。 兩個團隊都以為對方在處理工單，時鐘在走，卻沒人幹活。OLA應寫明由誰在何時之前接手。
漏掉客戶一側的延誤。 如果客戶的審批人不在圖裡，服務商在等回覆時計時仍在走。公平的協議會明確處理這一點。
從不復審。 團隊會變、供應商會變，兩年前定的目標可能已經不合適。SLA變更時就應複審OLA和UC。
把內部SLA和OLA混為一談。 如果貴公司在各部門之間簽有內部SLA，就按它本來的名字叫，但不要指望它代替服務商自己的OLA。

應該向服務商問哪些OLA和UC的問題？

你不需要看服務商的內部文件，但可以問這些關於結果的問題：

SLA裡哪些目標依賴外部供應商，這些故障怎麼處理？
工單在各支援級別之間如何轉交，接手的最長時限是多少？
非工作時間誰待命，嚴重工單怎樣找到他們？
交接環節怎麼計量，會不會出現在發給我的報告裡？
供應商慢的時候你們怎麼做？有沒有帶具名聯絡人的升級路徑？
客戶一側的哪些事項會暫停計時，暫停時你們怎麼告訴我？
支撐我這份SLA的內部協議和供應商合約，多久複審一次？

能清楚回答這些問題的服務商，多半認真想過SLA背後的這條鏈。

博迅怎樣展示自己的SLA？

我們的SLA與服務優先級頁面公佈的是面向客戶的協議：五個優先級（P1至P5），每級的首次響應、遠程支援、上門和解決目標，兩種服務時段（8x5和24×7），以及影響度乘緊急度矩陣。截至2026年10月28日，表中P1和P2的首次響應為15分鐘，解決目標為P1 8個工作小時、P2 24個工作小時。頁面同時註明，數字取決於服務時段和合約條款。

該頁面講的是SLA。我們團隊之間的內部協議和供應商合約，不在我們公佈的範圍之內。你可以要求的，也是每位客戶都應該要求的，是SLA確實在被計量的證據：一份對照各項目標的實際表現月報。我們的管理型IT外判服務方案和24×7服務台支援說明服務如何交付，管理型IT外判服務方案與按用戶收費則把公佈的響應承諾與各檔套餐價格放在一起。