雲端主機 SLA 是什麼？可用性百分比、停機補償與簽約前要看的條款

SLA（服務水準協議）是業者對服務可用性的承諾，但它不等於「保證不會停機」：它通常只承諾一個月的可用性百分比，未達標時給予服務抵用金，而不是賠償你的營業損失，而且有許多排除條款。因此重要系統不能只靠 SLA，還必須自己做備援與備份。簽約前要看可用性的計算方式、排除項目、補償方式與申請流程。

一、可用性百分比換算成停機時間

可用性常以「幾個 9」表示。以 30 天的月份為例，總分鐘數為 30 × 24 × 60 = 43,200 分鐘：

這張表是算式的結果：允許停機分鐘 = 43,200 × (1 − 可用性)。例如 99.9% 為 43,200 × 0.001 = 43.2 分鐘。看起來都很高，但 99.9% 與 99% 的差距是十倍。要選哪個層級，取決於一小時停機對你的業務損失有多大。

二、SLA 的常見限制

1. 只涵蓋特定服務與配置：例如單台主機與跨多個可用區部署的 SLA 數字不同，有些服務要求使用特定架構才適用。
2. 排除條款：計畫性維護、使用者設定錯誤、超過配額、不可抗力、第三方問題等通常被排除。
3. 以月計算：短時間的多次中斷可能加總後仍達標。
4. 需要主動申請：多數業者要求你在期限內提出申請並附上證據，不會自動補償。
5. 補償有上限：通常是當月該服務費用的一定百分比，並以服務抵用金形式發放。
6. 不包含間接損失：營業損失、資料損失、商譽損失通常不在補償範圍內。

三、示意計算

假設某服務月費 3,000 元（示意數字），SLA 規定可用性低於 99.9% 補償 10%、低於 99% 補償 30%。若當月實際可用性為 99.5%，則落在補償 10% 的區間，補償金額為 3,000 × 10% = 300 元的抵用金。但如果這次停機讓你的電商少賣了 50,000 元的商品，這 50,000 元不會被補償。這個差距，就是為什麼要靠架構設計而不是靠 SLA 保護業務。

四、簽約前要確認的條款

1. SLA 的可用性定義與計算方式。
2. 排除項目清單。
3. 補償方式、上限與申請期限。
4. 維護通知機制與時間。
5. 資料備份的責任歸屬：是業者負責還是你自己負責？
6. 資料所在地與是否可以移轉。
7. 終止合約與資料返還條款。
8. 資安事件通報義務。
9. 責任上限條款。
10. 合約準據法與管轄法院。

涉及金融業、醫療與政府標案時，主管機關可能要求特定的委外合約條款與稽核權，請先確認法規與採購文件要求，必要時請法務或律師審閱。

五、用架構彌補 SLA 不足

• 多可用區部署：把服務分散在不同可用區，並使用負載平衡器。
• 自動復原：設定健康檢查與自動重啟或替換。
• 資料備份與異地備份：定期備份並演練還原，見儲存、快照與備份費用。
• 災難復原計畫：訂出還原時間目標與還原點目標，寫成文件並演練。
• 監控與告警：用外部監控服務，不要只依賴業者的狀態頁面。
• 降級方案：當某功能故障時，仍能提供核心功能。

備援會增加費用，要用雲端主機每月費用試算估算多台主機與跨區流量，與停機損失比較後再決定等級。

六、發生停機時怎麼做

1. 確認是業者問題還是自己的設定問題，查看業者的服務狀態頁面。
2. 記錄停機開始與結束時間、影響範圍與截圖。
3. 啟動內部應變流程，通知相關人員與客戶。
4. 事後依 SLA 的申請流程提交補償申請，注意期限。
5. 做事後檢討，評估是否要調整架構與業者。

七、本地業者與國際大廠的 SLA

本地業者可能提供客製化的 SLA 與支援層級，例如專人窗口與電話支援；國際大廠的 SLA 則較為標準化。不論哪一種，都請以書面條款為準，不要僅憑口頭承諾。如果業務非常依賴服務連續性，可以考慮雙業者或雙地區備援。

八、依業務損失決定可用性目標

選擇 SLA 與備援等級時，可以用簡單的算式把停機損失換算成金額，再與備援成本比較。

示意計算（數字純屬舉例）：假設網站每小時平均帶來 2,000 元的營收，一年預期有 8 小時的非計畫停機，損失約為 2,000 × 8 = 16,000 元。如果多可用區備援每年要增加 30,000 元，單看直接營收並不划算；但若停機還會造成客戶流失、品牌受損或違約金，實際損失就可能高很多。反過來，一個每小時損失高達 50,000 元的系統，一年停機 8 小時就是 400,000 元，投資備援顯然合理。

重點是把「可接受的停機時間」與「可接受的資料遺失」寫下來，和相關人員達成共識，再依此設計架構與選擇服務等級。很多糾紛都來自事前沒有討論過這兩件事。

九、定期演練與文件

備援設計只有在實際演練過的情況下才可靠。建議每年至少做一次災難復原演練：模擬主要主機或可用區故障，測量實際的還原時間，並與目標比較。演練的結果要記錄，包含遇到的問題與改善措施。同時維護一份簡單的緊急聯絡與應變文件，內容包括：誰是決策者、如何聯絡業者客服、備份在哪裡、還原步驟、對外溝通的範本。文件要放在即使主系統故障也能存取的地方，例如另一個服務或離線副本，否則真的出事時反而打不開。

十、解讀業者狀態頁面與事後報告

多數大型業者會提供服務狀態頁面，記錄目前與歷史的事件。遇到服務異常時，先查看狀態頁面，確認是否為業者端的問題，這可以節省排查自己系統的時間。但要注意，狀態頁面不一定涵蓋所有受影響的客戶與區域，你的實際狀況仍要以自己的監控為準。

重大事件之後，業者有時會發布事後報告，說明原因、影響範圍與改善措施。閱讀這些報告可以幫助你了解業者的可靠度與透明度，也能啟發你的架構設計，例如哪些依賴是單點故障。如果你的業務非常重視可靠度，在選擇業者時可以把「是否公開事後報告」與「過去的處理態度」列入評估。

十一、簽約與審閱的實務建議

審閱合約時，建議列出一張「重要條款對照表」，包含可用性承諾、補償方式、排除項目、資料處理與返還、責任上限、終止條件與準據法。同一張表可以放進不同業者的資訊進行比較，一眼就看出差異。若條款不明確，應請業者以書面說明。對於金額較大或影響營運的合約，請法務或律師審閱。

另外，業者通常有權單方面更新服務條款與 SLA，並以公告或電子郵件通知。建議指定專人接收這些通知，並在重大變更時評估是否影響你的業務與風險。把合約與條款的更新紀錄保存起來，日後發生爭議時，可以證明當時適用的是哪一版本。

常見問題

99.9% 和 99.99% 差多少？

每月允許停機時間從約 43 分鐘降到約 4 分鐘，但通常價格與架構複雜度也會提高。要用業務損失來判斷是否值得。

業者停機會自動補償嗎？

通常不會，需要你提出申請並在期限內附上證據。

資料遺失業者要負責嗎？

多數合約把資料備份責任交給使用者，並限制業者的賠償責任。請閱讀責任上限條款，並自行做好備份。

參考來源

• 數位發展部 — 資通安全與政府雲端相關資訊
• 金融監督管理委員會 — 金融機構委外與雲端規範
• Amazon Web Services — 各服務 SLA 文件
• Google Cloud — 服務水準協議文件