教你如何谈判数据中心服务等级协议

目前经济形势的大环境要求越来越多的公司松开缰绳，取而代之的是将公司的应用，设备——还有信任——交付在数据中心设施供应商的手里。曾经难以想象的外包服务正成为你公司必要生存的一部分。那你该如何在这些外包服务的协议中保护你自己呢？

作为合同中最主要的组成部分之一，服务等级协议（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次停电，你应该将你的业务移到其他地方。或者如果你碰到一次长时间的停电，也应该有相对于的一条终止合同的条款。

问题：你是如何监控和记录SLA的统计呢？如服务支持，问题升级，响应时间和服务支持人员的条款。

Sclafani：这些方面都是非常重要的，也同时展现了当出现问题后所发生事情的一些潜在问题。基于服务，服务等级协议和供应商的冗余程度，你也许可以拥有几个不同的支持和升级的阀值。比如，如果你选的数据中心是一个完全冗余2N的基础设施，你也许对于一个7x24的“电话随叫随到”的设施服务，以及工作时间驻场的服务会比较满意。如果你的硬件是一套N+1的基础设施，那你就有可能需要一个7x24的驻场服务的合同。

是否会有一个门户让你看到与供应商看到相同的SLA度量信息？是否会有一个工单系统或者仪表盘让你看到你服务的状态？理解服务支持和升级的流程对于作为一个客户将期望现实化是很关键的，也使你认识到别人对你的期望。比如，你可能对于一个托管的机房有SLA是规定温度，但是管理基础设施的供应商可能不提供查看温度数据的权限。你不得不部署你自己的监控和报警系统来确认真实的情况。这就变得很不现实或不可能的任务。

接着，必须要理解如何处理停电造成的赔偿信用。当在一次停电事件中SLA被侵犯了，“真正停电时间段”——有关你潜在的赔偿信用 - 可能在一定条件还未满足的前提下无法启动。曾经有过很多次，供应商要求故障工单的递交时间，因为那是有时间记录的。其他供应商有可能要求你给他们的售后服务致电或甚至在SLA赔偿信用生效之前有一个最低停电阀值。这些全都是在你签署SLA之前所需要确认的关键点。甚至对一次停电的回应，你有可能不得不自己做一些监控来确认你供应商的报告。这种错误有可能是停电，温度波动或甚至是关于带宽95%的账单。各种各样的失误在所难免。

SLA还包含一个条件，确保当供应商处理问题时候的响应等级。比如，一家供应商针对故障工单的响应SLA等级为1小时，可能对更高等级的响应SLA需要额外的费用。当跟踪响应时，同样重要的是确认这个时间是如何计算和跟踪的。某些供应商会在自己的工单系统里使用自动回复来作为他们的“第一次响应”。这是一个解决他们SLA需求的小花招。确保你理解他们的支持组织架构是如何工作的，这样你的期望才能和他们的服务相对等。

人员配备的能力描述通常都会或多或少夸张一些，所以重点是响应速度。当我在一次故障事件发生的时候打电话给供应商的时候，我更希望能够在第一时间找到一个有运营经验的人来帮助我。当我选择供应商时，我通常希望了解一下他们服务支持人员的一些工作背景。

我通常会得到两种回复。潜在的供应商的回复是比较透明的，如共享为我项目工作的一些服务人员的工作背景。我可能问这些服务人员问题并以此了解为我提供服务的服务支持人员的一些具体情况。另一种，我就会掉进一个完全的黑洞。供应商会告诉我“所有人都是超级有经验的”，但是没有额外具体描述。当提到运营工作经验的例子，我可能得不到任何回应，可以想象这样的支持团队是没有经验的，而且会发生很多升级事件。

再次看一下你的预算，再决定供应商支持团队的相对重要性。如果你自己拥有一支完善的运维团队，那供应商那边就算经验少一些也不是什么大问题。如果你正试图卸下你团队的任务或者从供应商那里得到一些技术能力，那仔细查看供应商的服务支持人员则是一件重中之重的任务。

问题：哪种调查能够在签订SLA协议之前，帮助潜在客户来测试供应商的升级流程？

Sclafani：既然签署SLA协议是客户/供应商关系中重要的一环，除了“直接电话”之外就没有更好的测试。你已经了解你团队在过去碰到过怎样的问题，所以在工作时间和非工作时间，作为一家客户直接电话供应商的服务支持团队。这才是最有效的方式来测验谁来接听，他们的升级流程是怎样的，同样可以至少获知一起真正事件发生时的情况。同时，这也是一次很好的机会来与服务支持团队进行交流，了解真实的他们是怎样的。

我其他的建议是与此供应商现在的用户进行交谈他们目前为止的经验和感受，最好还能跟他们之前签订可是已解约的客户进行交流。如果你看到的都是无视客户感受或者服务等级不达标，那估计你所期望的SLA也无法达到，快去寻找下一家服务供应商吧。
 

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友