不要再認為 SLA 會拯救你。 需要它來安撫並創造一種虛假的安全感。

不要再認為 SLA 會拯救你。 需要它來安撫並創造一種虛假的安全感。

SLA,也稱為“服務等級協定”,是客戶與服務提供者之間關於客戶將獲得的服務的保證協議。 也規定了因供應商過失造成停機的賠償等。 從本質上講,S​​LA 是一種憑證,資料中心或託管提供者可以藉助該憑證讓潛在客戶相信他會以一切可能的方式得到善待。 問題是您可以在 SLA 中編寫任何您想要的內容,並且本文檔中編寫的事件不會經常發生。 SLA 遠遠不是選擇資料中心的指南,您當然不應該依賴它。

我們都習慣於簽署某種施加某些義務的協議。 SLA 也不例外——通常是可以想像到的最不切實際的文檔。 唯一可能更無用的是在「商業機密」概念並不真正存在的司法管轄區中的保密協議。 但問題在於,SLA 並不能幫助客戶選擇合適的供應商,而只是蒙蔽了雙眼。

託管商最常在向公眾展示的 SLA 公共版本中寫入哪些內容? 嗯,第一行是託管商的“可靠性”一詞 - 通常是 98 到 99,999% 的數字。 事實上,這些數字只是行銷人員的美麗發明。 曾幾何時,當託管還很年輕且昂貴,雲端只是專家的夢想(以及每個人的寬頻存取)時,託管正常運行時間指標非常非常重要。 現在,當所有供應商都使用相同的設備、位於相同的骨幹網路並提供相同的服務包時,正常運行時間指標絕對不引人注目。

是否存在「正確」的 SLA?

當然,也有理想版本的SLA,但它們都是非標準文檔,由客戶和供應商手動註冊和締結。 此外,這種類型的 SLA 通常涉及某種合約工作而不是服務。

好的 SLA 應該包含哪些內容? 簡而言之,好的 SLA 是規範兩個實體之間關係的文檔,它使其中一方(客戶)能夠最大程度地控制流程。 也就是說,它在現實世界中是如何運作的:有一個文件描述全球互動過程並規範各方之間的關係。 它設定了界限、規則,本身就成為雙方都可以充分利用的影響力槓桿。 因此,由於正確的 SLA,客戶可以簡單地強迫承包商按照約定工作,並且它可以幫助承包商消除過度活躍的客戶的“需求”,而這些需求在合約中是不合理的。 它看起來像這樣:“我們的 SLA 是這樣說的,離開這裡,我們按照約定做一切。”

也就是說,「正確的 SLA」=「提供服務的適當合約」並提供對情況的控制。 但這只有在「平等」工作時才有可能。

網站上寫的和現實中等待的是兩件事

總的來說,我們將進一步討論的一切都是典型的行銷技巧和對注意力的考驗。

如果我們採用流行的國內託管商,那麼一個報價比另一個更好:25/8 支持,伺服器正常運行時間 99,9999999% 的時間,至少在俄羅斯有一堆自己的資料中心。 請記住有關資料中心的一點, 我們稍後再討論這個問題。 同時,我們來談談理想的容錯統計數據,以及當一個人的伺服器仍然陷入「0,0000001% 的故障」時所面臨的情況。

對於 98% 及以上的指標,任何下降都屬於統計錯誤邊緣的事件。 工作設備和連接要么存在,要么不存在。 您可以使用「可靠性」評級為 50%(根據其自己的 SLA)的主機多年而不會出現任何問題,或者您可以使用聲稱 99,99% 的主機每月「失敗」一次,持續幾天。

當跌倒的時刻確實到來時(我們提醒您,每個人都有跌倒的一天),那麼客戶就會面臨一個名為「支援」的內部公司機器,並且服務協議和 SLA 就會被曝光。 這是什麼意思:

  • 最有可能的是,在停機的前四個小時內,您將無法提供任何東西,儘管一些託管服務商從崩潰那一刻起就開始重新計算資費(賠償金)。
  • 如果伺服器長時間不可用,您可以提交重新計算費率的請求。
  • 前提是該問題是由於供應商的過失所造成的。
  • 如果您的問題是由第三方(在高速公路上)引起的,那麼似乎“沒有人應該責怪”,問題何時解決就看您的運氣了。

然而,重要的是要明白,您永遠無法接觸到工程團隊,大多數情況下您會被第一線支援人員攔住,他們在真正的工程師試圖解決問題時與您通訊。 聽起來很熟悉?

在這裡,許多人依賴 SLA,這似乎可以保護您免受此類情況的影響。 但事實上,公司很少超越自己文件的界限,或能夠以最小化自身成本的方式扭轉局面。 SLA 的首要任務是消除警惕,並讓人們相信,即使出現不可預見的情況,「一切都會好起來的」。 SLA 的第二個目的是傳達主要關鍵點並為服務提供者提供迴旋餘地,即能夠將故障歸因於供應商「不負責」的某些事情。

同時,大客戶其實根本不關心SLA 範圍內的補償。 「SLA補償」是在資費範圍內以設備停機時間比例退還資金,這永遠無法彌補潛在金錢和聲譽損失的1%。 在這種情況下,對客戶來說,盡快解決問題比某種「資費重新計算」更為重要。

「世界各地有許多資料中心」令人擔憂

我們將服務提供者擁有大量資料中心的情況單獨分類,因為除了上述明顯的通訊問題之外,還會出現不明顯的問題。 例如,您的服務提供者無權存取「他們的」資料中心。

在我們的上一篇文章中 我們寫了關於聯屬計劃的類型並提到了“白標”模型其本質就是打著自己的幌子倒賣他人的能力。 絕大多數聲稱在許多地區擁有「自己的資料中心」的現代託管服務商都是使用白標模式的經銷商。 也就是說,它們在物理上與瑞士、德國或荷蘭的條件資料中心無關。

這裡發生了極其有趣的碰撞。 您與服務提供者簽訂的 SLA 仍然有效且有效,但供應商無法以某種方式從根本上影響發生事故時的情況。 他自己依賴自己的供應商——資料中心,電源架是從資料中心購買並轉售的。

因此,如果您不僅看重合約和 SLA 中關於可靠性和服務的優美措辭,而且看重服務提供者快速解決問題的能力,那麼您應該直接與設施所有者合作。 事實上,這涉及到與資料中心的直接互動。

當許多 DC 實際上可以屬於一家公司時,我們為什麼不考慮其他選擇? 嗯,這樣的公司非常非常少。 可以是一、二、三個小型資料中心或一個大型資料中心。 但十幾個DC,其中一半在俄羅斯聯邦,第二個在歐洲,幾乎是不可能的。 這意味著經銷商公司的數量比您想像的要多得多。 這是一個簡單的例子:

不要再認為 SLA 會拯救你。 需要它來安撫並創造一種虛假的安全感。
估算 Google Cloud 服務資料中心的數量。 歐洲只有六個。 在倫敦、阿姆斯特丹、布魯塞爾、赫爾辛基、法蘭克福和蘇黎世。 也就是說,在所有主要高速公路點。 因為資料中心昂貴、複雜,而且是一個非常龐大的專案。 現在請記住莫斯科某個地方的託管公司,「在俄羅斯和歐洲擁有十幾個資料中心」。

當然,沒有好的供應商在白標計劃中擁有合作夥伴,但數量已經足夠了,而且他們提供最高水準的服務。 它們使得可以透過同一瀏覽器視窗同時租用歐盟和俄羅斯聯邦的容量,接受盧布付款,而不是外幣付款,等等。 但當 SLA 中描述的情況發生時,他們就成為與您完全相同的情況的人質。

這再次提醒我們,如果不了解供應商的組織結構和能力,SLA是沒有用的。

其結果是

伺服器崩潰總是令人不愉快的事件,它可能發生在任何地方的任何人身上。 問題是你想要對局勢有多大的控制力。 現在市場上沒有太多的直接容量供應商,如果我們談論大型參與者,那麼相對而言,他們在整個歐洲可以訪問的十幾個 DC 中只擁有莫斯科某個地方的一個。

在這裡,每個客戶都必須自己決定:我要立即選擇舒適還是花時間和精力在俄羅斯或歐洲可接受的位置尋找資料中心,在那裡我可以放置我的設備或購買容量。 對於第一種情況,目前市場上的標準解決方案是合適的。 第二,你將不得不出汗。

首先,需要確定服務賣方是否是設施/資料中心的直接所有者。 許多使用白標模式的經銷商會盡力掩飾自己的身份,在這種情況下,您需要尋找一些間接標誌。 例如,如果「他們的歐洲 DC」有一些與供應商公司名稱不同的特定名稱和標誌。 或者如果「合作夥伴」這個詞出現在某個地方。 95% 的情況下,合作夥伴 = 白標。

接下來,你需要熟悉公司本身的結構,或者更好的是親自看看設備。 在資料中心中,遊覽或至少在自己的網站或部落格上發表導覽文章的做法並不新鮮(我們寫過這樣的文章) 時間 и ),他們用照片和詳細描述談論他們的資料中心。

對於許多資料中心,您可以安排對辦公室的親自訪問以及對資料中心本身的短暫遊覽。 在那裡您可以評估有序程度,也許您將能夠與其中一位工程師進行交流。 很明顯,如果您需要一台 300 盧布/月的伺服器,那麼沒有人會帶您參觀生產,但如果您需要大量的容量,那麼銷售部門很可能會滿足您。 例如,我們進行此類遊覽。

無論如何,應該使用常識和業務需求。 例如,如果您需要分散式基礎設施(某些伺服器位於俄羅斯聯邦,其他伺服器位於歐盟),那麼使用與使用白標的歐洲 DC 建立合作夥伴關係的託管商的服務會更容易且更有利可圖模型。 如果您的整個基礎設施將集中在一個點,即一個資料中心,那麼值得花一些時間尋找供應商。

因為典型的 SLA 很可能不會幫助您。 但與設施所有者(而不是經銷商)合作將大大加快可能問題的解決速度。

來源: www.habr.com

添加評論