我在一家小型開發公司工作，他們越來越多地被要求根據特定配置為我們的產品製定正式的 SLA。
從開發的角度來看，我對此感到滿意，但是，如果從硬體/平台的角度來看這些目標不現實，那麼我說我們將從軟體的角度實現特定的目標是沒有意義的——客戶只關心整體系統可用性。
從平台的角度我該看什麼？什麼樣的指標和水平？
另外，有哪些陷阱（例如，從軟體角度來看，我永遠不會承諾修復時間 - 我不知道我是否需要重寫整個產品來糾正某些問題，所以說我們可以修復它5 天可能是不可能的- 從硬體/作業系統/平台的角度來看，我應該避免承諾什麼）？
答案1
我在這個領域擁有豐富的經驗；我為幾家財富五強公司做了很多工作，這些公司像 ISP 一樣經營資料中心，經營各個需要託管和支援服務的公司部門。
他們通常有兩個指標，稱為 SLA（服務等級協定）和 OLA（操作等級協定）。
SLA 透過所使用的硬體類型來滿足。在談論 SLA 時，我們使用等級來描述它們。 SLA-1 是零停機時間，SLA-2 是長達 1 小時的停機時間，SLA-3 是 8 小時，等等...透過使用冗餘設備來滿足 SLA。在一家公司，我們使用大量 Cisco 來建立高可用性（Cisco CSM 和 GSS 設備）。當談論SLA等級時，我們通常談論HA（高可用性）和DR（災難復原）。在公司擁有多個資料中心的情況下，HA組件通常是每個資料中心的屬性，而DR是跨資料中心的屬性；兩者均以 RPO（恢復點目標）和 RTO（恢復時間目標）來衡量，以表示 SLA 等級。
從真正的基本術語來看，OLA 是某人（人類）對需要手動幹預/糾正措施的事件做出反應的速度。 OLA 通常也是根據反應時間來衡量的；他們使用相同的 RTO/RPO 目標。我諮詢的一家公司使用 6 個等級作為 OLA 指標。這裡的前 3 個等級是這樣的一個範例：
OLA-1：RTO 0 < 2 小時 OLA-2：RTO >= 2 且 <= 4 小時 OLA-3：RTO >= 24 小時且 <= 30 天，如果不是資料中心故障，如果直流故障 > 30 天。
驅動 OLA 和 SLA 指標的因素稱為 CIA 評級。 CIA = 機密性、完整性和可用性。應用程式的資料應由為該應用程式付費的業務部門進行分類。 CIA 將協助推動 OLA 和 SLA 的製定。 CIA 等級的每個部分都有一個從 1 到 3 的數字。 CIA 評級為 3-3-3 是您可以達到的最低評級。因此，3-3-3 的 CIA 評級通常對應 6 級的 SLA 和 OLA 級別，其中 SLA-6 和 OLA-6 是保證的最低（最長回應時間）。
如何獲得 CIA 評級通常相當於計算如果資料被盜（機密性）、受到損害（完整性）或系統停機（可用性），企業將損失多少錢。因此，如果機密資料被盜，一家將損失 1000 萬美元的公司的 C 評級可能為 1，或者如果資料遺失並不嚴重，只會讓公司損失 1,000 美元，那麼您的 C 評級可能為 3 。
我諮詢過的大公司通常都是這樣處理這類事情的。
答案2
我會很慢地承諾解決硬體問題的時間，就像軟體問題一樣。您永遠不知道什麼時候會等待供應商修復某些內容中的嚴重錯誤。就 SLA 等級而言，我發現它們往往採用「有人將在 X 小時內解決您的問題」的形式。當然，這取決於他們支付的金額，但根據我的經驗，1 到 8 小時之間似乎很正常。
答案3
如果您被要求提供 SLA 來修復安裝了您的軟體的硬體問題，答案是否定的。您可以承諾回應時間，但如果不控制整個硬體/作業系統/軟體堆疊，您就無法承諾解決時間。
也許您的客戶以一種尷尬的方式告訴您，他們確實需要為您的產品提供託管服務？這樣他們就可以避免他們擔心的任何內部問題，並且只給你一張支票。
答案4
簽訂 SLA 時需要考慮的一件事是，SLA 本身絕對沒有任何意義，必須與未履行 SLA 時的處罰一起遵守。
例如，我們的 ISP 為我們提供了 100% 的網路 SLA，但我們能收回的最大金額是我們每月的帳單，這非常低，因為現在頻寬很便宜，遠不及我們在網路故障時損失的金額。
此外，合約中通常寫的是人們對問題做出反應的速度，而不是實際上需要多長時間來解決問題。因此，如果他們讓你承諾較短的回應時間，只需安排一名實習生值夜班，為你洗牌，直到你醒來，然後就可以了。
根據我的經驗，所有這些 SLA 業務實際上意義非常非常小（如果有的話）。