作为合同中最主要的组成部分之一，服务等级协议（SLAs）列出了服务范围以及合约的主要条款，但是不是所有的SLAs都是对等和平衡的。仔细阅读最终商议的版本以及审查服务范围可以有效地帮助你取得一份能够保障你业务所需要的服务等级的合同。

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

　　关注主合约"包含服务等级协议

　　作为一份服务等级协议，我通常会先退一步，首先看附在主合约上的那些文件。确认你拥有所有的参考文件来审查。典型的SLA,作为主合约的一个组成部件，也会拥有同样必要的几部分：

　　1、SLA所覆盖的产品/服务的定义。这一部分通常是供应商的禁地因为这只是定义产品或服务。如果你连这个也无法认同，那可不是一个好兆头。

　　2、"可用的"这个字的定义很关键，还包括围绕在它周围的服务指标。

　　3、当SLA的条件无法满足后，供应商的响应和升级流程的描述。

　　4、当SLA条件无法满足后，整治流程的定义。

　　你或许可以想象到第二，第三和第四部分是通常需要修改的地方。这些细节通常都是在一开始让供应商获利的地方。比如，作为一个数据中心，一条网络带宽出现严重的数据包丢失可能会使你的应用无法使用，但是当协议中出现的"可用的"的参数依然满足时，你就没有足够的证据来提出赔款申请。

　　不幸的是，SLA的复杂程度依据所签约的不同类型的服务会产生很大的变化。在一个数据中心的合约中，一份SLA可能会包罗万象，从环境条件比如温度和湿度，到网络联通问题比如延时或可用性，以及甚至管理化/云服务牵涉到服务器、虚拟机、备份服务等。需要考虑如此众多的可能性，一份SLA的真正问题是从法律的角度来审查供应商的灵活性。假设会有几轮的反馈和变化，但是平衡一下合同金额和你的法律费用也是很重要的。

　　同时记住任何SLA的黄金准则，当已经到达赔款的时候：你永远不会得到比你付出的更多。如果在SLA之下有一个停机或者其他的可用性损失，这起故障事件永远也不会被标题为"损失".赔款永远也不会超过你每月支付的那个特定的服务。

　　面对服务等级协议的商榷

　　事实上，讨论的筹码是了解有竞争力的服务等级协议和在供应商选择的时候要货比三家。对于撰写SLA的供应商来说，一份SLA永远都是合理的，但是他们一般还是会来跟你确认条款是否合适。

　　千万不要掉入市场的陷阱。比如，某些供应商可能做出一个超乎寻常的声明如当没有达到预期SLA时，返还1,000,000%的服务费用，但是前提限制是你能够为此服务支付多少。如果你将这一条拿出来谈，不要期望会有任何有效的结果。但是一个供应商100%正常运行时间的保障 - 当出现故障而带有小额的赔款时 - 这就是你可以讨论的事情。

　　沟通SLA最有效的方式是充分了解供应商控制的领域。比如，一家供应商在转租数据中心空间，而你的要求是超出他们能力范围，有关于他们房东的。那如果期望供应商同意那些使他们业务开发责任或其他超过他们能力范围的条款，就显得很不靠谱。

　　你也许可以对供应商提供的服务提出一些要求做一些改变。比如，如果他们网络管理是外包给一家第三方供应商，而且你的要求是合理的，你的供应商可能可以和他们的服务供应商合作，做一些SLA的调整。

　　在一个服务等级协议中针对环境的可变因素

　　服务等级协议中讨论的最多的两个方面是关于可用性定义或除了信用赔偿过程的正常运行时间。

　　正常运行时间是针对产品或服务，你可以指定某些环境变量。对于数据中心来说，这一般就要从温度，湿度开始，一直到网络延时和应用特定的性能。

　　正常运行时间的商榷一般会包含实际度量和间隔，比如温度和时间。对于一个托管项目的SLA,交谈就会侧重于可接受的温度范围和时间间隔，如在成为一个故障事件之前所能接受的范围。

　　商榷是可行的，但是另外很重要的一点是需要确认你准备选择的供应商的诚实度。假设你承诺了一定量的电量负载，同时供应商同意维持一定量的温度阀值。一旦你在机柜中安装了设备导致出现热点，你有可能会碰到一种情况是当此热点温度导致一起宕机事故，供应商可能不用负责，因为这是由于客户自己出现的问题。

　　还要考虑到你作为用户的行为可能导致一起SLA事件。比如，假设你承诺每个机柜的电量负载为6kW.如果你将用电使用率超过80%的时候，有可能会被供应商归结为一起"不在SLA范围内"的事件因为客户的原因以及触发动作。我们见过讨论客户提醒和针对线路超过既定阀值而征收罚款的合同。我们还见过这样的情况，供应商具备拔硬件电源的权利，目的是将电源的消耗控制在80%的阀值以内。

　　另外一个争论的焦点是供应商用来计算赔款信用的方法。确保你理解他们的流程和条款，防止任何不开心的事情发生，比如赔款的一个附加条件等。有时，这些条款是可以一起商榷的，但是成功的因素很大程度上依赖于供应商。

　　监控和记录SLA的统计

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

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

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

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