目前經濟形勢的大環境要求越來越多的公司松開韁繩，取而代之的是將公司的應用，設備——還有信任——交付在數據中心設施供應商的手里。曾經難以想象的外包服務正成為你公司必要生存的一部分。那你該如何在這些外包服務的協議中保護你自己呢?

作為合同中最主要的組成部分之一，服務等級協議(SLAs)列出了服務范圍以及合約的主要條款，但是不是所有的SLAs都是對等和平衡的。仔細閱讀最終商議的版本以及審查服務范圍可以有效地幫助你取得一份能夠保障你業務所需要的服務等級的合同。

Peter Sclafani已經與上百家客戶商議過SLAs，范圍從IPv6軟件即服務(SaaS)至托管服務。作為網絡自動化公司 6connect的***信息官，Sclafani經歷過審核SLA流程的甲乙雙方的角色，并從客戶或供應商的角度反反復復審查過上百個合同。

問題：“主合約”包含服務等級協議。作為客戶，你通常會關注哪里?

Peter Sclafani：作為一份服務等級協議，我通常會先退一步，首先看附在主合約上的那些文件。確認你擁有所有的參考文件來審查。典型的SLA，作為主合約的一個組成部件，也會擁有同樣必要的幾部分：

1、SLA所覆蓋的產品/服務的定義。這一部分通常是供應商的禁地因為這只是定義產品或服務。如果你連這個也無法認同，那可不是一個好兆頭。

2、“可用的”這個字的定義很關鍵，還包括圍繞在它周圍的服務指標。

3、當SLA的條件無法滿足后，供應商的響應和升級流程的描述。

4、當SLA條件無法滿足后，整治流程的定義。

你或許可以想象到第二，第三和第四部分是通常需要修改的地方。這些細節通常都是在一開始讓供應商獲利的地方。比如，作為一個數據中心，一條網絡帶寬出現嚴重的數據包丟失可能會使你的應用無法使用，但是當協議中出現的“可用的”的參數依然滿足時，你就沒有足夠的證據來提出賠款申請。

不幸的是，SLA的復雜程度依據所簽約的不同類型的服務會產生很大的變化。在一個數據中心的合約中，一份SLA可能會包羅萬象，從環境條件比如溫度和濕度，到網絡聯通問題比如延時或可用性，以及甚至管理化/云服務牽涉到服務器、虛擬機、備份服務等。需要考慮如此眾多的可能性，一份SLA的真正問題是從法律的角度來審查供應商的靈活性。假設會有幾輪的反饋和變化，但是平衡一下合同金額和你的法律費用也是很重要的。

同時記住任何SLA的黃金準則，當已經到達賠款的時候：你永遠不會得到比你付出的更多。如果在SLA之下有一個停機或者其他的可用性損失，這起故障事件永遠也不會被標題為“損失”。賠款永遠也不會超過你每月支付的那個特定的服務。

問題：在一個服務等級協議中，哪些針對環境的可變因素是最容易拿出來討論和商榷的?

Sclafani：服務等級協議中討論的最多的兩個方面是關于可用性定義或除了信用賠償過程的正常運行時間。

正常運行時間是針對產品或服務，你可以指定某些環境變量。對于數據中心來說，這一般就要從溫度，濕度開始，一直到網絡延時和應用特定的性能。

正常運行時間的商榷一般會包含實際度量和間隔，比如溫度和時間。對于一個托管項目的SLA，交談就會側重于可接受的溫度范圍和時間間隔，如在成為一個故障事件之前所能接受的范圍。

商榷是可行的，但是另外很重要的一點是需要確認你準備選擇的供應商的誠實度。假設你承諾了一定量的電量負載，同時供應商同意維持一定量的溫度閥值。一旦你在機柜中安裝了設備導致出現熱點，你有可能會碰到一種情況是當此熱點溫度導致一起宕機事故，供應商可能不用負責，因為這是由于客戶自己出現的問題。

還要考慮到你作為用戶的行為可能導致一起SLA事件。比如，假設你承諾每個機柜的電量負載為6kW。如果你將用電使用率超過80%的時候，有可能會被供應商歸結為一起“不在SLA范圍內”的事件因為客戶的原因以及觸發動作。我們見過討論客戶提醒和針對線路超過既定閥值而征收罰款的合同。我們還見過這樣的情況，供應商具備拔硬件電源的權利，目的是將電源的消耗控制在80%的閥值以內。

另外一個爭論的焦點是供應商用來計算賠款信用的方法。確保你理解他們的流程和條款，防止任何不開心的事情發生，比如賠款的一個附加條件等。有時，這些條款是可以一起商榷的，但是成功的因素很大程度上依賴于供應商。

問題：面對服務等級協議的商榷，一個潛在客戶需要學習哪些方面的知識?維護窗口和其他宕機的情況如何來處理?

Sclafani：事實上，討論的籌碼是了解有競爭力的服務等級協議和在供應商選擇的時候要貨比三家。對于撰寫SLA的供應商來說，一份SLA永遠都是合理的，但是他們一般還是會來跟你確認條款是否合適。

千萬不要掉入市場的陷阱。比如，某些供應商可能做出一個超乎尋常的聲明如當沒有達到預期SLA時，返還1,000,000%的服務費用，但是前提限制是你能夠為此服務支付多少。如果你將這一條拿出來談，不要期望會有任何有效的結果。但是一個供應商100%正常運行時間的保障 - 當出現故障而帶有小額的賠款時 - 這就是你可以討論的事情。

溝通SLA最有效的方式是充分了解供應商控制的領域。比如，一家供應商在轉租數據中心空間，而你的要求是超出他們能力范圍，有關于他們房東的。那如果期望供應商同意那些使他們業務開發責任或其他超過他們能力范圍的條款，就顯得很不靠譜。

你也許可以對供應商提供的服務提出一些要求做一些改變。比如，如果他們網絡管理是外包給一家第三方供應商，而且你的要求是合理的，你的供應商可能可以和他們的服務供應商合作，做一些SLA的調整。

當你考慮到第三方對于供應商SLA的影響，請關注維護窗口。計劃中宕機時間的必要性可能會導致一起停電事件，確保供應商不會提議賠款的要求。比如，如果一個網絡工程師搞砸了一個路由器配置。一些供應商有可能抓住不統一的維護窗口這一點來繞開他們的責任。如果你的SLA不包含維護窗口，你就有可能無追索權，但是仍然會有宕機時間。理論上，一個SLA應該應用于所有意識到的宕機時間，獨立于任何的維護窗口，緊急事件或者其他情況。

注意違反SLA后對合同誠信的影響。如果在一個時間段之內出現太多的停電或者一起停電事件超過了設立的時間段，在合同里應該注明一個可能性就是在沒有任何懲罰的條件下終止合同。比如，如果供應商在一個月中有3次停電，你應該將你的業務移到其他地方?；蛘呷绻闩龅揭淮伍L時間的停電，也應該有相對于的一條終止合同的條款。

問題：你是如何監控和記錄SLA的統計呢?如服務支持，問題升級，響應時間和服務支持人員的條款。

Sclafani：這些方面都是非常重要的，也同時展現了當出現問題后所發生事情的一些潛在問題?；诜眨盏燃墔f議和供應商的冗余程度，你也許可以擁有幾個不同的支持和升級的閥值。比如，如果你選的數據中心是一個完全冗余2N的基礎設施，你也許對于一個7x24的“電話隨叫隨到”的設施服務，以及工作時間駐場的服務會比較滿意。如果你的硬件是一套N+1的基礎設施，那你就有可能需要一個7x24的駐場服務的合同。

是否會有一個門戶讓你看到與供應商看到相同的SLA度量信息?是否會有一個工單系統或者儀表盤讓你看到你服務的狀態?理解服務支持和升級的流程對于作為一個客戶將期望現實化是很關鍵的，也使你認識到別人對你的期望。比如，你可能對于一個托管的機房有SLA是規定溫度，但是管理基礎設施的供應商可能不提供查看溫度數據的權限。你不得不部署你自己的監控和報警系統來確認真實的情況。這就變得很不現實或不可能的任務。

接著，必須要理解如何處理停電造成的賠償信用。當在一次停電事件中SLA被侵犯了，“真正停電時間段”——有關你潛在的賠償信用 - 可能在一定條件還未滿足的前提下無法啟動。曾經有過很多次，供應商要求故障工單的遞交時間，因為那是有時間記錄的。其他供應商有可能要求你給他們的售后服務致電或甚至在SLA賠償信用生效之前有一個***停電閥值。這些全都是在你簽署SLA之前所需要確認的關鍵點。甚至對一次停電的回應，你有可能不得不自己做一些監控來確認你供應商的報告。這種錯誤有可能是停電，溫度波動或甚至是關于帶寬95%的賬單。各種各樣的失誤在所難免。

SLA還包含一個條件，確保當供應商處理問題時候的響應等級。比如，一家供應商針對故障工單的響應SLA等級為1小時，可能對更高等級的響應SLA需要額外的費用。當跟蹤響應時，同樣重要的是確認這個時間是如何計算和跟蹤的。某些供應商會在自己的工單系統里使用自動回復來作為他們的“***次響應”。這是一個解決他們SLA需求的小花招。確保你理解他們的支持組織架構是如何工作的，這樣你的期望才能和他們的服務相對等。

人員配備的能力描述通常都會或多或少夸張一些，所以重點是響應速度。當我在一次故障事件發生的時候打電話給供應商的時候，我更希望能夠在***時間找到一個有運營經驗的人來幫助我。當我選擇供應商時，我通常希望了解一下他們服務支持人員的一些工作背景。

我通常會得到兩種回復。潛在的供應商的回復是比較透明的，如共享為我項目工作的一些服務人員的工作背景。我可能問這些服務人員問題并以此了解為我提供服務的服務支持人員的一些具體情況。另一種，我就會掉進一個完全的黑洞。供應商會告訴我“所有人都是超級有經驗的”，但是沒有額外具體描述。當提到運營工作經驗的例子，我可能得不到任何回應，可以想象這樣的支持團隊是沒有經驗的，而且會發生很多升級事件。

再次看一下你的預算，再決定供應商支持團隊的相對重要性。如果你自己擁有一支完善的運維團隊，那供應商那邊就算經驗少一些也不是什么大問題。如果你正試圖卸下你團隊的任務或者從供應商那里得到一些技術能力，那仔細查看供應商的服務支持人員則是一件重中之重的任務。

問題：哪種調查能夠在簽訂SLA協議之前，幫助潛在客戶來測試供應商的升級流程?

Sclafani：既然簽署SLA協議是客戶/供應商關系中重要的一環，除了“直接電話”之外就沒有更好的測試。你已經了解你團隊在過去碰到過怎樣的問題，所以在工作時間和非工作時間，作為一家客戶直接電話供應商的服務支持團隊。這才是最有效的方式來測驗誰來接聽，他們的升級流程是怎樣的，同樣可以至少獲知一起真正事件發生時的情況。同時，這也是一次很好的機會來與服務支持團隊進行交流，了解真實的他們是怎樣的。

我其他的建議是與此供應商現在的用戶進行交談他們目前為止的經驗和感受，***還能跟他們之前簽訂可是已解約的客戶進行交流。如果你看到的都是無視客戶感受或者服務等級不達標，那估計你所期望的SLA也無法達到，快去尋找下一家服務供應商吧。