真正有意義的可用性 SLA

可用性 SLA 看起來像一句承諾，實際運作起來卻更像一份退款政策。供應商很清楚這一點。客戶往往並不清楚，於是在簽下服務等級協議時以為自己買到了可用性，而真正買到的，只是萬一沒拿到時的一點折扣。

這不一定是筆糟糕的交易。它只是與大多數人以為自己在簽的那筆交易不同，而這個差別恰恰在系統停擺、有人追問合約究竟怎麼寫的那一刻顯現出來。

三個九聽起來接近完美，卻允許每月 43 分鐘的停機。 四個九允許四分鐘。如果你的業務吸收得了平日下午 43 分鐘的中斷，99.9% 就足夠了，不必為更高的數字付費。如果吸收不了，再多的九也幫不上忙，因為協議給你的是一筆抵用金，而不是阻止這次中斷。

可用性 SLA 用分鐘兌現的承諾

百分比把一個非常大的區間壓縮成看起來很小的差別。換算成時間寫出來，差距立刻一目了然。

由此可以得出兩點。從 99.9% 到 99.99% 這一步，把允許的停機時間壓到十分之一，而成本上漲通常遠不止十倍，因為它要求用冗餘消除每一個單點故障，連部署流程本身也不例外。這裡說的冗餘不是再加一台伺服器，而是把資料庫、網路路徑和身分驗證層全部做成雙份，並且把發布本身改成不會中斷服務的無停機部署。而任何達到或超過五個九的水準，都低於人類察覺異常並做出反應所需的時間，因此只能由無人介入、自動切換的系統來維持。

數字應該由一次中斷每小時真正讓你損失多少來決定，而不是由聽起來是否氣派來決定。把那一小時的損失額認真算一遍，多數公司會發現，它比升到上一檔所要多付的費用還要小。絕大多數業務系統，99.9% 已經足夠誠實地夠用。

服務抵用金不是賠償

幾乎每一份可用性 SLA 裡寫明的救濟方式，都是從未來費用中扣抵的抵用金，通常是月費的某個百分比，而且常常以當月帳單總額封頂。Google Cloud 的運算 SLA 就是一個有代表性的例子：只有抵用金、由客戶自行申報、而且有上限。

這意味著你能拿回來的上限，大致就是你為這段時間支付的金額，而對多數服務來說，這個數字遠低於一次中斷造成的損失。一個每月幾百英鎊的平台，無法補償一天的營業額損失，也沒有任何供應商會同意讓自己承擔這種條款。此外，抵用金往往只按出問題的那一項服務的費用計算，依賴它而被連帶拖停的其他系統所產生的損失，根本不進入計算。

抵用金通常還需要主動申請，而不是自動發放。你得自己發現違約、自己算出金額，並在有時短到三十天的窗口內提出申請。舉證責任完全落在你這一側：你得拿得出自己的監控紀錄，才能說明中斷確實發生過、從幾點持續到幾點。供應商沒有義務主動告訴你他們沒達標，絕大多數也確實不會主動說。

實際的結論是，不要再把抵用金當成保護。它只是一個訊號，說明供應商對自己給出的數字有多認真。真正保護你的是架構，以及我們在災難復原指南中談過的復原規劃。

真正起決定作用的條款

什麼才算停機。 只有完全無法使用，還是效能下降也算？一個三十秒才回應的服務實際上沒法用，但按多數定義仍算作可用。如果回應時間對你重要，就要把延遲門檻寫進定義裡。

由誰量測、怎麼量測。 幾乎總是供應商自己，用他們自己的監控，從他們自己的網路去量。那量的是他們的基礎架構，而不是你的體驗。談定量測點，同時無論如何都要自己跑一套獨立監控，因為你沒有觀測過的數字，你無從爭辯。

排除與例外。 計畫性維護通常被完全排除，也就是說供應商每月停機數小時也不算違約。要查清需要提前多久通知，以及有沒有上限。計畫維護一旦被全面排除，合約上寫的百分比和你實際能用的時間之間，差距會明顯拉開。此外，凡是歸因於你的設定、第三方或不可抗力的情況同樣被排除，而這幾類能吸收掉相當多的事故。

量測窗口。 按月是通行做法，也對你有利。按年量測則允許供應商發生一次長時間中斷卻依然達標，因為在 99.9% 之下，整整一天的停機仍在全年額度之內。

回應還是解決。 許多協議只承諾在某個時限內回應，對修復隻字未提。一小時回應加上不設期限的修復，是很常見的寫法，也遠比讀起來要弱。

與其爭數字，不如要這些

把力氣用在那些真正改變行為的條款上，而不是首頁那個數字。百分比在談判桌上很難挪動，而下面這幾項幾乎都談得下來，並且它們改變的是供應商在出事那天真正會做什麼。

計畫維護的上限，附帶提前通知和避開你尖峰時段的窗口。它對真實可用性的影響，往往超過百分比本身。

狀態透明，也就是一個公開的狀態頁，以及及時發布事故的承諾。一個願意公開自己故障的供應商，其實是在告訴你他們是怎麼做事的。

明確的升級路徑，寫明姓名或角色以及時間，這樣事故處理就不會從尋找該聯絡誰開始。

重大中斷後的事故報告，說明發生了什麼，以及因此改了什麼。這是供應商能給你的資訊量最大的一份文件，而不願意給這件事本身也很說明問題。

反覆失約時的解約權。 長期達不到水準，就應當允許你無違約金離開。這項權利比任何抵用金都值錢，因為它是唯一與損害相稱的救濟。

如果提供 SLA 的是你

給出一個你在最差的月份也守得住的數字，而不是平均月份的數字，並且在承諾之前自己先量一遍。合理的做法是先連續量幾個月，把其中最差的那個月拿出來看，再決定要不要把這個數字寫進合約。承諾了一個從未驗證過的數字的供應商，最後會在公開場合發現那個差距。

誠實地定義計畫維護，並守住那個時間窗。公開狀態頁。哪怕沒人要求，也把事故報告寫出來，因為留下來的客戶，正是那些相信你知道究竟發生了什麼的客戶。

各檔的定價，要按交付它們實際花掉的成本來算。四個九不是一個行銷部門的決定，而是冗餘的基礎架構、自動故障切換，以及一套不會把系統弄停的部署流程，這些都各自附帶帳單。其中大部分的維運基礎，都從我們的 CI/CD 管線指南開始。

Mecanik 在伺服器安全分析工作中，依可用性承諾建置並維運系統。值得作出的承諾，幾乎總是那個你在糟糕的一週裡也守得住的承諾。

常見問題

99.9% 的可用性允許多少停機時間？ 每年 8.76 小時，或者說每月 43.2 分鐘。提升到 99.99% 會把它壓到每年 52.6 分鐘、每月 4.32 分鐘，也就是十分之一；由於必須消除包括部署流程在內的每一個單點故障，交付成本通常遠超十倍。

服務抵用金算是對停機的真正賠償嗎？ 不算。抵用金通常是月費的一個百分比，並以當月帳單封頂，所以你最多拿回大致等於已付金額的錢，這遠低於一次中斷的通常代價。它們往往還需要在很短的窗口內主動申請，而供應商很少主動承認自己沒有達標。

看一份可用性 SLA 時應該檢查什麼？ 什麼算停機、效能下降是否計入，由誰量測、從哪裡量測，排除條款涵蓋了哪些情形，計畫維護有沒有上限和提前通知，量測窗口是按月還是按年，以及承諾的是回應還是解決。

量測窗口為什麼這麼重要？ 按月量測對客戶有利。按年量測則允許供應商發生一次長時間中斷卻仍然達標，因為在 99.9% 之下，整整一天的停機仍在全年額度之內。同樣一次故障，放在按月的協議裡就是直接違約。

比起更高的數字，更值得談的是什麼？ 計畫維護的上限並附帶避開尖峰時段的通知、及時發布事故的公開狀態頁、寫明姓名與時間的升級路徑、重大中斷後的書面事故報告，以及反覆失約時的解約權。最後一項是唯一與損害相稱的救濟。