关于ITIL中SLA的概念，知道的人很多，但真正洞悉其复杂与本质的人可能不多，网上也甚少看到这部份的深入资料，尤其是跟实际业务相关的就较少，多是一些空泛的居多。一直说想写针对ISO20000的13个流程分别写一篇评论与思考的文章，但工程比较大，只能象现在这样零零碎碎的写了，正好前段时间在项目过程中碰到对SLA的讨论，于是想把一块的想法记录下来，以供内外交流，注意以下内容只是基于个人对SLA的理解，我并不认为它是一个对SLA最好的解释与理解，只是基于目前这个阶段的认知而言，而是可行的也相对实际与合理。

    一、SLA的本质

    1.SLA的起源：

    ITIL的产生最重要的一个作用，是标准的作用，类似中国古代统一了语言与度量标准的做法类似，ITIL提供了一个大家可以共同交流的言语、提供了一个大家可以标准化的指导与改进的基础，让全世界的IT服务业者可以真正统一、标准起来，ITIL我个人认为最核心的概念之一就是SLA的引入，服务业一直是难以标准与度量的，一直依赖人类的感性为指标，这造成许多的交流、管理、商业、法律问题，SLA概念的清晰提出，将服务引向一个可量化、可控制、可评论、可管理、可改进的境界，服务不再模糊、不再只停留在非常内在的层面，服务亦可以生冷的进行管理与控制。

    事实上在传统行业，也有类似SLA的概念，只是没有人独立成一个概念，并围绕它建立一个管理体系，比如麦当劳的60秒取餐，快递公司的XX小时快递等等，亦或者一些政府单位承诺办理手续的时间等等，这些与SLA的概念是一致，不同的是应用与约束效用不同，同时在管理体系中扮演的重要性也不可同日而语。

    2.SLA的作用

    ITIL最具革新意义的创举是定义了SLA，并围绕着达成SLA设计了一整套管理体系，那么SLA到底有什么作用呢？SLA（Service Level Agreement）在中文中我们通常叫做服务级别协议，首先要聚集在“协议”二字上，它表示这是跟你客户达成一致的，具有法律约束作用，其次是“级别”二字，这表示你的服务到什么程度需要有量化指标出来，提到这个需要提到另一个概念“服务目录”

    当你想承包客户的IT服务时，首先要确定的，其实不是服务级别协议，而是服务目录，因为你首先要搞清楚，客户需要你做什么服务，这就需要你梳理你的服务内容即服务目录，在完美的情况下，你应该是清楚你自己可以做什么服务，才去面向市场的，即一个成熟的IT服务商，应该有自己的服务目录（类似菜单），然后找到客户，由客户点菜（选取一部份服务目录），最后就每一项服务需要达到的级别协商达成一致，这样才能进行商务报价，因为服务级别与成本是成正比的。所以正确的逻辑是首先确定做什么，然后确定做到什么地步。

    当SLA确定后，这份文件具备法律意义，它清晰IT服务商与客户的职责与服务内容，其一些免责与惩处条款，这会避免许多误会与纠纷，因为在实际的服务活动中，客户经常会理所当然的认为你就应该“干这事儿”，作为IT服务商也经常会签订了一个服务活动后，为了“客户满意度”就大包大揽的把活都干了，在实际的IT服务活动中，我相信大多数的运维服务公司为客户做的许多事情，是在报价中没有考虑到的，即我们的“服务溢出”了，最后核实成本时，又发现利润不高，但又无从提价，但是当服务目录与SLA真是弄清楚后，双方就有了一个很好的基础去改进服务，避免了许多灰色的地带，成本的控制（无论是客户方还是服务提供方）都会相当容易。

    确定了服务目录与服务级别协议后，IT服务商将根据服务级别、成本去配置相关的资源，组成服务团队，而SLA将是指导这些团队作业的最有力的依据，最后一个合同周期结束时，客户将根据合同的执行（SLA的达成）进行结算付款。

    事实上如果一个IT服务商管理相对比较成熟，业务量到达一定的规模时，还可以根据SLA与服务目录的历史信息，设计一个成本计算模型，这样在对于商务报价与日后的成本控制是非常有利的。

    3.SLA的可量化

   SLA的协定有一个很重要的关注点，即SLA的“可测量性”与“测量方法”，有一些运维服务商与客户协商一些复杂的指标，但这些指标在合同周期内是根本无法进行测量的，这种SLA的协定就丧失了意义，无法测量就意味着根本无法知道执行情况、无法计算执行结果，也无从改善与控制，这是一方面，另一方面，当我们确定了一些指标后，这些指标的计算方法与测量方法也是需要注意的，这些要与客户商定清楚，避免了有指标，但最后的测量方法双方不一致，导致最终的达成结果出现偏差而发生纠纷。

    二、SLA的组成要素

   下面我们将开始真正理解SLA的几个核心组成要素：

    1)服务目录：服务目录决定了你的SLA约束的服务范围，即服务商到底提供哪一些服务，只有客户“选择”了的服务目录，服务商才会报价与后续的响应，在服务目录之外的内容，将不受SLA的限制，这也意味着报价时是未考虑这些服务内容的，最后结算也是单独的，服务目录要利于阅读与理解，便于客户、服务商自身消化，不然在实际应用中是无法真正起到作用的，服务目录这一块以前写过一些内容，就不再多作介绍了。

    2)服务日历：服务日历决定了你的SLA约束的时间范围，即你为客户提供X*X的服务响应期，是7*24还是5*8，是否扣除一个周期内的法定假期，很多服务商有自己的公司日历，事实上，每一个服务型的项目存在着一个服务日历，服务日历与公司日历很多时候不是相同的，不同则意味着成本的增加与管理难题的增加，这需要进行在报价结算时综合考虑，因为它直接关系到人力的配备与排班，服务日历跟各种监视计划也有直接的关系，它还跟SLA的测量有关联关系。

    3)可用性：事实上每一个项目是一组服务的集合，比如桌面运维或IDC运维，亦或者是一个应用系统的运维，这些在实际的作业中，多数是以项目的形式管理与存在的，这同时也表示是一个服务集群，这里就需要定义每一个项目的可用性，说到可用性，通常的公式是：可用率=（AST-DT）/AST*100。AST（agreed service time）是指约定的服务时间即上面提到的服务日历，DT（Actual downtime during agreed service time）在约定服务时间内的停机时间。这个计算公式表面看起来简单但在实际的取值中是比较复杂的，因为AST需要考虑日历问题，需要把服务日历的所有时间段换算成小时甚至分钟，如果一个故障发生在5*8之外的时间，是不会考与计算的，同时每一个故障的发生与结束时间需要测量出，还有加上其它的因素，比如是不是这次故障是由服务商承担的，如果是客户非法违视操作，或者是第三方导致的，此时把故障时间纳入可用性计算显然是不合理的。事实上考虑到一个合同周期的长度，通常说的可用性达99%这实际是一个非常低的可用指标，如果是5*8的服务的话，99%的可用性意味着有208个小时的时间内服务是不可用的，在实际的服务过程中，单位用小时是过粗的，因为故障的发生一般是以分钟为单位的，有的行业甚至需要用秒为单位。加上用户群的问题，可用性的计算还需要更复杂才能真正发映真实的服务情况，一直以来有一个问题困扰着许多人，到底怎样的故障算是影响了可用性呢？比如一个应用系统，如果是全国范围内的应用而且用户群众多的话，发生了局部地区的用户无法使用部份模块了，这需要纳入可用性的计算吗？如果纳入的话，会让可用性无端的降低很多，而实际中并非如此，你会发现全国的服务不可用与部分地区的不可用造成的计算结果一样了，但实际的服务情况并非如此，这表示计算的模型要复杂，这个话题放在后面再进行说明。

    4)解决时间：解决时间是指当发生各种类型的事件时的完成处理时间要求，常态而言，事件分为咨询、请求、投诉、故障、新需求。这是事件的分类，另外事件需要进行分级，一般可分为五级或三级，这时需要定义每一个分类、级别的事件的解决时间要求（比如一级故障要求多少分钟解决），还需要定义哪个级别的事件影响可用性（比如一级故障二级故障都影响可用性），有一些事件分类象投诉与咨询可能是不会影响可用性的，常态而言新需求也是不影响可用性的（除非在商务报价之初就纳入新需求的约束考虑）。

    这里要特别需要强调一下可用性与解决时间的关系，这是一个相互钳制关联的，比如可用性定义了一年之中只能宕机20个小时，但是客户不会充许你在同一个时间里把20小时用完，解决时间里定义了宕机是一级故障，一级故障的解决时间是1小时，这样会强制把20个小时分散到全年之中，以减少对业务的冲击。当可用性与解决时间这两个核心指标定义了后，象按时解决率等等这些事实是用于服务管理的，基于服务商自身的管理而言的，站在客户方的立场而言有了这两个指标就足够约束服务商了。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。