许多个人消费者从未听说过服务级别协议 (SLA)，或者即使听说过，它也被隐藏在互联网或数字服务注册表单的细则中，未被注意到。 另一方面，相当多的高管和更高级别的业务管理人员知道 SLA 的含义以及为什么它对于从第三方提供商处获取各种技术服务的企业很重要。 你也应该。 事实上，如果您要购买技术服务，最好在签约前阅读服务级别协议。
服务级别协议本质上是一种书面协议，描述了客户对服务提供商的期望。 SLA 背后的理念是服务不同于消费品。 如果某人购买一件衣服、一个电器甚至汽车之类的东西，很容易解释他们会得到什么，但要准确解释客户从服务提供商那里得到什么就有点困难了。 SLA 通过阐明服务的精确卖点和价值来解决这个问题，从而帮助客户和供应商在达成交易时达成一致。 至少，这是这些文件的主要目标。
IT 市场中的 SLA
在过去几十年中，SLA 通常由提供宽带连接的互联网服务提供商 (ISP) 发布。 如今，云托管服务、软件即服务和其他“网络可交付成果”的迅速兴起，对复杂的 SLA 的需求越来越大，这些 SLA 阐明了服务何时可用、如何支持以及客户需要什么 有“权利”通过登录。 （在关于云定价的 5 件事中了解更多关于云托管的信息。）
SLA 中的通用条款
真正理解 SLA 所涉及的问题之一是，对于普通读者来说，处理这些文档中的一个是一项主要的苦差事。 许多 SLA 文档的法律术语和复杂的措辞可能迫使忙碌的读者忽略其中的大部分内容。 也就是说，有一些简单的约定是多种 SLA 文档的一部分。 最好的例子之一是正常运行时间条款。 正常运行时间和停机时间这两个短语通常用于描述在给定时间段内服务何时可用或不可用。
SLA 中的正常运行时间和停机时间也是一个很好的例子，说明这些文档的制作者需要如何尝试量化本质上无法量化的事物。 换句话说，由于存在如此多的未知因素，不可能准确知道系统可能会停机多少时间。 考虑到这一点，SLA 通常包含一个“最低”或“基准”，用于说明客户可以预期的正常运行时间，实际服务可能比协议中规定的更可用。 通过提供正常运行时间的估计，至少有一个基本的计划或协议，如果没有 SLA，没有人会知道对服务的期望。
协议的其他方面更容易，例如关于有多少数据将流经特定服务的规范，以实际千兆字节（或其他缩放测量）为单位。
大而复杂的 SLA
在普通 SLA 中可能很难找到具体的服务标识符（如正常运行时间和停机时间）的一个原因是这些文档的另一个主要部分通常涉及特定的协议和参数，用于针对协议提出投诉或“索赔”。 在这里，SLA 听起来很像保险文件。 与保险一样，SLA 可能具有各种“排除条款”，从而免除提供商的某些责任。 诸如“诚信”之类的表达也可用于描述客户或提供者的响应。 例如，在 Windows Azure 的 SLA 中，Microsoft 使用“服务信用”系统来补偿客户的“SLA 索赔”，声明：“服务信用是客户对任何违反此 SLA 的唯一和排他性补救措施。” 这个第一个也是重要的声明为客户如何与供应商就 SLA 的任何不可预见的问题进行谈判奠定了基础。 然后，供应商根据客户提交索赔的方式和时间，制定非常具体的规则和规定来分配这些服务积分。 所有这些都围绕着一个文件结构，就像法律文件一样，首先定义条款，然后将协议的重要方面嵌套在一系列带标签的小节中，并带有自己仔细列举的合同细节列表。
再举一个例子，看看 Google Apps (G Suite) 的 SLA。 谷歌也使用服务信用，协议的许多实际部分都是相似的，但一切都减少到一页，大细节在最上面。 SLA 在第一句话中设定了基准：“G Suite 涵盖的服务网络界面将在任何日历月的至少 99.9% 的时间内运行并可供客户使用……”
“无用的”SLA？ 当协议变得有争议时
虽然可读性可能会有所不同，但 SLA 的一些最大问题远远超出了它们的措辞方式，一些最极端的案例在引起专家批评家的注意后最终公之于众。 一个例子是对托管巨头 Amazon Web Services 及其 SLA 的关注。 有些人瞄准了AWS协议的要求。 在一个案例中，作家 Brandon Butler 引用了 Gartner 的 Lydia Leong，她指出 AWS 正在将需要多个可用区 (AZ) 的负担转移到客户身上。 Leong 还抨击了许多 SLA 的构建，称它们为“文字沙拉”。 这里的问题是，添加 AZ 或复制存储会增加成本，而且正如 Leong 指出的那样，额外用户责任的增加可能最终导致有效使用 SLA 的机会，用她的话说，“几乎为零”。
用户的观点
有关 SLA 条款的其他问题在用户论坛中提出，个人用户在其中讨论 SLA 条款及其含义。 在一个 Amazon S3 SLA 论坛中，用户讨论服务积分的文档要求，特别是某些类型的“错误日志记录”。 这就引出了另一个问题，即为什么亚马逊使用“综合”公式来计算正常运行时间，以及客户是否可以通过在短时间停机期间发送大量请求来“玩弄系统”来提高成功率。
除了围绕 SLA 具体要点的争议，一些用户想知道这些合同是否也会导致公司以不同方式获取服务和 IT 设置。 此 VMware 社区论坛中的一位用户似乎建议，一些企业可能会在 SLA 的指导下急于安装虚拟机设置，而忽略了寻求快速构建的关键支持工作。
上述所有讨论都说明了为什么仔细阅读服务级别协议并了解这些文档通常包含的内容而不是仅仅搁置此类文书工作是个好主意。 尽管许多 SLA 读起来不太好，但它们往往包含一些对服务用户非常重要的信息。 如果您要为这些服务付费，最好弄清楚您应该得到什么作为回报。
