SLA是什麼？IT支援SLA含義與簽約檢查清單

一句話版本： SLA（服務水平協議）是IT支援合約裡的一部分，寫明服務商要在多長時間內響應和解決問題、服務覆蓋哪些時段、如何計量和彙報，以及目標沒達到時怎麼辦。讀SLA要看數字和免責條款，不要看形容詞。

比較IT支援服務商時，SLA這一頁能把「我們響應很快」變成一句可以追究的承諾。它也是最常被一掃而過的一頁。本文說明這個詞的含義、一份像樣的IT支援SLA包含什麼、數字該怎麼讀，以及簽約前該核對哪些事項。

外部定義我們在2026年10月28日查閱過：維基百科「Service-level agreement」詞條、「Service-level objective」詞條和「Operational-level agreement」詞條（均於2026-10-28查證）。涉及博迅（Brocent）自身的數字，一律取自我們公開的SLA與服務優先級頁面，同日重新核對。

SLA是什麼意思？

SLA是服務商與客戶之間的書面協議，把服務的某些方面（如質素、可用性、責任）寫成合約條款。這是維基百科「Service-level agreement」詞條採用的含義（2026-10-28查證）。說得直白一點：服務商寫明自己會交付什麼，客戶寫明自己期望什麼，雙方再寫下怎麼衡量。

三個相關的詞常被混用，先分清楚：

SLA： 整份協議，涵蓋範圍、服務時段、目標、彙報、補救措施和責任。
SLO（服務水平目標）： SLA裡一個可衡量的目標，例如「嚴重事件15分鐘內首次響應」。維基百科「Service-level objective」詞條（2026-10-28查證）把SLO描述為某項服務水平的目標值或目標範圍，而SLA是包住它的整份協議。
SLI（服務水平指標）： 目標背後的計量方式，例如「工單登記到工程師回覆之間經過的分鐘數」。

在IT場景裡搜尋「SLA含義」的人，多半想知道後兩層：承諾了哪些數字，這些數字又是怎麼算出來的。下文就沿著這條線展開。

IT支援SLA到底包含哪些內容？

一份有用的IT支援SLA涵蓋七項內容。缺哪一項，就要求對方書面補上。

1. 範圍：哪些服務、哪些用戶

SLA應寫明支援什麼（手提電腦、伺服器、Microsoft 365、網絡、打印機、業務系統）和為誰支援（全體員工、指定辦公室、指定設備）。如果目標只寫「適用於IT支援」而沒有範圍，出了問題就可能爭論你的問題到底算不算在內。

2. 服務時段

目標只在服務時段內計時。常見的有工作時間覆蓋（例如週一至週五的營業時間，寫作8x5；每天具體幾小時因服務商而異）和全天候覆蓋（24×7）。請確認週五17:55登記的工單怎麼算，哪些公共假期不計入、按哪個城市的日曆，因為服務多個市場的服務商，使用的日曆可能和你的不同。

3. 優先級定義

優先級說明事件有多嚴重，也決定適用哪一組目標。定義應當基於業務影響，而不是誰喊得更大聲。我們的P1至P4優先級指南講解了四級模型，配套文章嚴重程度與優先級的區別說明影響度和緊急度如何合成一個級別。

4. 響應與解決目標

這是最醒目的數字，下一節專門展開。

5. 可用性承諾

對由服務商營運的服務、伺服器或雲平台，SLA可能承諾一個正常運行時間百分比。後文「可用性百分比對應多少停機時間」一節給出換算。

6. 免責條款與暫停計時條件

每份SLA都有。常見的有計劃內維護、服務商無法控制的事件、第三方服務的故障，以及等待客戶反饋的時間。寫得窄而清楚時它們是合理的；寫得寬泛時就是警示信號。

7. 彙報、檢討和補救措施

沒人計量的SLA只是宣傳小冊子。協議應寫明彙報什麼、多久一次、誰來檢討，以及未達標後怎麼辦。補救措施可以是服務抵扣、根因檢討、改善計劃，或者連續多次未達標後有權終止合約。

響應時間和解決時間有什麼區別？

這是最常見的誤解，也是讓客戶吃虧最多的一個。

響應時間： 服務商確認收到工單、並由合格人員開始處理的速度。它告訴你有人接手了。
解決時間： 問題真正被修復或已有臨時方案的時間。它告訴你什麼時候可以恢復工作。
為什麼兩者都要： 只有快速響應而沒有解決目標，承諾的是「會回覆」，不是「會修好」。只有解決目標而沒有響應目標，可能讓你在沉默中等到最後期限。

每個定義都要看計時的起點和終點。從工單登記起算，和從工程師接單起算，是兩回事；工程師回覆就停表，和你確認修復才停表，也是兩回事。

許多SLA還會把遠程支援和上門服務分開。博迅公佈的表格就把首次響應、遠程支援、上門和解決分成四列，各有各的目標。截至2026年10月28日，該表顯示P1和P2事件的首次響應為15分鐘，P3為30分鐘，P4和P5為60分鐘；P1至P5的解決目標依次為8、24、48、48和72個工作小時。頁面同時註明，目標取決於服務時段（8x5或24×7）和合約條款，讀任何類似的表都應該這樣讀。我們的管理型IT外判服務方案與按用戶收費也重申了嚴重事件15分鐘內首次響應的承諾。

可用性百分比對應多少停機時間？

可用性用服務在某一週期內正常運行的時間百分比來表示，百分比的細微差別折算成小時就很大。算法很簡單，拿到任何報價都可以自己算。

99%： 每年約87.6小時停機，30天的月份約7.2小時。
99.9%： 每年約8.76小時，30天的月份約43分鐘。
99.99%： 每年約52.6分鐘，30天的月份約4.3分鐘。

（以上按一年8,760小時折算，是我們自己的算術，不是任何廠商的聲明。）

然後問百分比背後藏著的問題：

計劃內維護算停機，還是排除在外？
按月、按季還是按年計算？年度平均值會掩蓋糟糕的一個月。
誰來計量，你能看到數據嗎？
百分比適用於整個平台，還是其中某個組件？

可用性百分比對服務商自己營運的基礎設施最有意義。對服務台來說，對應的是人們響應的速度和問題被修復的比例。

服務抵扣是什麼，夠用嗎？

服務抵扣是服務商未達標時，在今後帳單中扣減一部分費用。抵扣說明目標有後果，但應把它當作信號，而不是賠償。一筆抵扣很少等於一天停工的損失。

需要核對：

觸發條件： 哪些未達標會產生抵扣，需要客戶自己申請嗎？
金額： 是固定金額還是月費的百分比，有沒有上限？
連續未達標： 連續數次未達標後，你有沒有退出權？這往往比抵扣本身更有價值。
唯一補救： 接受抵扣後，是否就不能再提出其他索賠？

如果SLA完全沒有補救措施，目標就只是願望，不是承諾。問清楚服務商實際上在未達標時會做什麼，並要求看一份根因檢討的樣例。

SLA應該怎樣計量和彙報？

目標需要證據。一套靠譜的安排包括：

每一步都有時間戳的工單系統， 這樣響應和解決時間由記錄算出，而不是靠記憶。
定期報告， 通常按月，按優先級列出實際表現與各項目標的對比。
檢討會議或電話， 解釋未達標的原因，並記錄商定的行動。
能查看底層數據， 至少要有每個數字如何計算的明確定義。

博迅說明，管理型IT外判服務的客戶會收到書面報告，首頁展示了對照所簽SLA衡量指標的報告樣例。具體適用哪些報告取決於你的服務範圍。無論選擇哪家服務商，簽約前都應要求看一份真實的、已匿名處理的報告。拿不出來的服務商，多半沒有在計量。

有用的報告指標包括：達到響應目標的工單佔比、達到解決目標的工單佔比、平均解決時間，以及被重新打開的事件數量。時間類指標的定義請看我們的MTTR、MTBF與MTTA解讀；用戶問題在首次聯絡就得到解決的比例，請看首次呼叫解決率。

SLA不保證什麼？

SLA承諾的是速度和流程，它有邊界，依賴它之前要先了解。

它不能防止事件發生。 響應目標說的是出故障後多快有人開始處理。避免故障靠監控、補丁和良好的設計，這些應該寫在範圍裡，而不是目標裡。
它不保證每一次都在解決時間內修好。 有些故障取決於廠商、營運商或備件。寫得好的SLA會說明這類情況怎麼處理，例如先商定臨時方案和調整後的時間。
它代替不了合作關係。 一份全是綠燈的報告，旁邊的團隊仍可能解釋得很慢。用檢討會議去問規律，而不只是看總數。
它取決於你的工單被定為什麼級別。 如果每張工單都定為緊急，目標就失去意義；如果一張都不是，你等得比必要的更久。要約定由誰來定級，意見不一致時怎麼裁定。

舉個例子。假設週二上午10:00文件伺服器停止響應，辦公室裡沒人能打開共享文件。按四級模型，這是嚴重事件。首次響應的計時從工單登記開始。工程師在響應目標內確認並開始排查。如果原因是磁碟損壞，團隊可以在訂購替換件的同時，用副本或備份恢復服務，再把真正的修復另行記錄。寫得好的SLA把前者算作故障的解決，把後者算作後續工作，月報裡兩者都會體現。簽約前，請讓服務商用這樣的事件給你完整走一遍。

SLA與OLA、支撐合約是什麼關係？

你的SLA是和服務商簽的。服務商則可能依靠自己的內部團隊和外部供應商來兌現它。這些安排各有名稱。維基百科「Operational-level agreement」詞條（2026-10-28查證）把OLA（營運級別協議）描述為：規定內部各支援小組的職責和時限，以便達成SLA的協議。與外部供應商簽訂、用來支撐某項服務的合約，在ITIL術語裡叫支撐合約（underpinning contract）；這裡用我們自己的話來說明，因為2026年10月28日我們沒有取得ITIL術語表的原文。

你不需要閱讀服務商的OLA，但應該問它們是否存在，以及SLA目標相對於它們是否現實。15分鐘響應的承諾，只有在背後的團隊按該時段配置了人手時才可信。SLA、OLA與支撐合約一文說明這三者如何配合。