SLA 服务等级协议

 

文本Tag： ITIL IT管理

【IT168 技术文章】     关于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个小时分散到全年之中，以减少对业务的冲击。当可用性 与解决时间这两个核心指标定义了后，象按时解决率等等这些事实是用于服务管理的，基于服务商自身的管理而言的，站在客户方的立场而言有了这两个指标就足够 约束服务商了。

内容导航

    三、 SLA的测量

    SLA经过设定后，就需要进行监控与测量，事实上对SLA的测量等于对事件的测量过程，不会涉及到其它的流程了。就可用性这个指标而言，只会与故障这一种 事件分类关联，而解决时间这一指标是横跨所有事件的。

    每一个事件从发生到解决的时长会与解决时间这一指标匹配，如果属于故障，再根据事件的等级与可用性的关系来匹配以确定每一个故障是否影响了可用性，而且要 判断影响了多少。这样需要涉及到的信息与计算量是比较巨大的，没有软件工具的支持很难实现，有了软件工具并考虑了上述的要素，是可以随时计算有多少事件的 解决时间违规的，也可以随时计算出当前的可用性是多少。在服务人员处理事件时，当创建的那一刻开始倒计时以约束加快处理进程，服务人员的接单需要考虑事件 等级与解决时间剩余。

    在计算过程中还需要考虑许多例外因素，比如要剔除因客户或第三方造成的等待时间，当服务商承诺，电脑出了问题8小时可以维修完成，但由于客户的原因一直联 系不到对方无法拿到电脑，造成解决时间违规，最后要对服务商进行金钱惩罚显然不合理。还要剔除责任归属是客户或第三方的事件，以合理公正的计算。

    SLA的测量是一个实时的行为，时间的要求非常高，这事实上会要求服务商的服务人员有一个非常明确的操作规程，不然SLA的计算与提取很容易失真，这些数 据事后是很难补上再计算的，尤其是有软件支持的情况下。SLA应该是一面镜子，让客户可以照清楚服务商，而服务商也可以确切的知道自已当前的服务能力，个 人觉得当前国内许多服务商的SLA的设定与结果其实经不起严格推敲的，这的确需要服务商有比较成熟的认识与管理水平。当每一个商务周期结束后，可以提取出 服务的绩效结果，一是供结算考评，二是分析以确定明年的服务绩效。

    四、 SLA的实施过程

    在一个没有导入ITIL的组织中，要实施SLM是一件比较难的事情，因为这需要客户方与服务商共同接受这种理念，同时这对服务商而言是一种压力，在大家没 有真正的理清这些内在的道理之前，服务商与客户方反而可能保持一种天然的生态融洽，不管这对客户还是服务商是否有利，起码以前客户不会意识到原来服务是如 何低下，服务商虽然有时会被客户的无理要求所打击，但绝大多数情况下，还是可以赢得下一个商务合同的，当这一切的混沌被打破时，就使得大家置于一个相对生 冷的环境，以当前国内的服务合同而言，关系往往是占据很重要的位置的，可能客户也暂时没有意识到需要如此严格透明的管理服务商，这时服务商去实施SLM 时，有时会有一种找抽的感觉。但SLM又是ITSM真正走向成熟的一个很重要的基础，这时需要组织的高层领导的强力支持才有可能走向现实，客户方与服务商 需要有很好的学习与沟通，甚至要做好有短期混乱的准备。

    实施SLM，从服务商的角度而言，最开始需要梳理的服务目录，然后才开始针对当前的每一个服务项目进行分析，与客户（业务方）讨论确定一个服务范围（服务 目录），再确定服务时间范围（服务日历），然后要根据业务的现实情况来一同确定可用性与解决时间，这个过程是一个相当痛苦的过程，尤其是在第一次实施讨论 时，在第一次时，建议与客户订一个粗的SLA，比如解决时间可以相对一刀切，这里特别需要注意的是要把关键业务活动找出来，以便于事件的定级，不然后续的 一切计算与统计全部会失真，服务人员也不知道如何将每一个事件定级而造成作业混乱。把这些商定清楚时，双方可以写入合同一同确认并生效。SLA生效后，需 要宣达到与此服务项目所有相关的作业人员，最好以会议的形式公布宣达。后续就进入正常的服务过程了，在每一个商务周期内，把SLA可以进一步分析与细化， 这样一个周期一个周期的改进循环，最后走向成熟。

    五、SLA的局限

    SLA有一个比较矛盾的地方，即可用性的定义，你如何理解与设定你的可用性，这是一个很困难的地方，小的说一台电脑，好象从表面而言，这台电脑用不了当然 会影响可用性，但实际情况上，电脑关非只处于0和1的状态，可能只是电脑的OFFICE中的EXCLE用不了，那这时客户报障到底算不算影响可用性呢？如 果算，那么AST（约定的服务时间）要如何取值呢。这还是从一个设备而言，如果是一分布式的应用系统，遍布全国的用户，这时这个问题就更复杂了，这里面我 发现应该是存在一个规律与道理的，即如果局部的服务受影响也会纳入可用性的计算时，那么AST一定需要把服务受点纳入考虑，比如上述的电脑，如果只是一个 EXCLE无法使用时也纳入可用性的计算，那么需要把这种EXCLE类型的服务也纳入AST的计算中，这样分子越大时，分母也应该随之增加，如此才能更接 近真实的情况。比如如果一个分布式的系统，服务日历是7*24。在全家有100个应用网点，当10个应用网点无法正常运行1个时，如果这种情况需要纳入可 用性计算，那么每一个应用网点都应该被考虑进AST中，即AST是7*24*100。其实核心的问题是到底哪一些算影响可用性，我们往往的答案时只要影响 了关键业务就算影响了可用性，但真正深入分析，这个回答往往不是很坚实的，因为现实中业务往往是互为一体的，系统的功能也是相辅相成的，说关键业务，事实 也是由许多一个个小的服务或功能点支撑的，常常会使我们面临一个问题就是，造成故障发生时，要么可用性的落点很多，要么根本没有落点，最终可用性不是很低 就是很高，没有真正的反映出实际的情况。这个问题从2006年的时候我就想求一个最终解，但现在只是变相找到一个解决方法，即把事件的等级与可用性影响关 联，这样便于制定指标与测量，但事实上仍然没有找到一个非常合理的模型出来，也有可能是“可用性”这一概念本身就是不合适的，需要用另外一种更合理更易于 分解的概念来代替才行。

    另外一个事实是，SLA最终的结果其实不是事实结果，因为当一个故障发生时,如果这故障是成规模性的影响的，还是以上面的分布式应用系统为例，此时如果你 的可用性设定得非常详细与具体（即把每一个网点都纳入AST考虑7*24*100），你很难知道到底在故障期间到底有多少网点受了影响，你的事件创建可能 只是一条，这时你的可用性事实上无形中拔高了。如果你的可用性设定得比较粗（7*24），这时不管你是否把这次故障时间纳入计算，你的可用性计算都会是错 的。

    SLA的内容暂时写这些了，实施SLM难度很大的根本原因在于，在这一个流程中集中了许多历来已久的问题，比如象服务目录的梳理与设计，这本身就是一个独 立的课题了，而SLM并不是一个服务商内部的流程，它需要与客户方做许多沟通与理念共识，它又关系于商业利益，在国内的客户基本上还成熟到有一个清晰的 SLA来约束服务商时，服务商反而超前一步了，这某种程度是一种好的趋势，我相信IT服务一片混沌的情况会在未来成为历史，它应该更具体透明、更量化、更 易于控制的，未来你将不能再丢一个粗粗合同把客户数百万的预算吃下去了，起码客户需要知道到底你做了些什么，做到什么水准，作为服务商你可不太可未来一直 把合同拿到就算完，做好做坏都得到按合同金额了，客户将会有更多的方法来控制合同的执行情况，服务将不再是一个黑盒子。

 

====================================================================================

Juniper app

 

服务水平协议(SLA)规定数据业务的可靠性和性能，主要用于帧中继和ATM网络中。作为向IP移植的第2层业务，尤其是VPN业务，服务供应商需 大力提供基于IP的SLA来赢得有利可图的IP VPN业务。Juniper网络ERX向服务供应商提供重要的功能，以在IP层可靠地传输并测量服务水平。

用户的需求很简单。他们想要可靠的业务和对合同业务的准确评估。尽管要求看起来非常简单，但在IP网络中满足这些要求是一种挑战。第一代IP解决方 案迫使服务供应商在数据吞吐量和数据测量标准之间做出选择，使他们不可能提供IP SLA。ERX下一代边缘路由器内置了IP SLA功能。利用其基于ASIC的速度，ERX能够保持线率数据吞吐量，同时收集确定服务水平是否符合要求所需的关键信息。利用强大的可靠性选项，ERX 可以尽可能延长正常运行时间--在服务供应商最需要的地方…网络边缘。

优势

ERX边缘路由器的强大功能使服务供应商第一次能够提供IP SLA，通过以下方法真正满足用户的各种需求：

• 支持企业用户，他们希望外包VPN网络，但仍旧需要控制和测量保证
• 支持批发合作伙伴，他们购买大量带宽和业务
• 解决过去性能/测量不可兼得的问题，并获得准确的统计数据和线速数据吞吐量
• 与操作有关的准确统计数据，不会造成管理网络和工具过载
• 一流的灵活的报告，可以为每位用户进行定制和显示
• 冗余选项，提供卓越的正常运行时间，并可以向重要用户提供
• 差分流量处理选项，即使在拥塞时也可保证高价用户的质量性能

技术概述

服务供应商网络的边缘是向用户提供所有IP业务的位置。两种主要的驱动因素确定了大多数网 络拓扑，它们对提供IP SLA来说很关键：

1. 用户通常有一个接入网络的进入点。这个进入点必须有很高的可靠性和冗余，以履行SLA正常运行时间保证值。  
2. 服务供应商趋向于在网络边缘设定超额预订，这对于在拥塞时划分业务优先级以及说明传输的业务极其重要。

ERX能够提供高度可靠的线速边缘路由器，使服务供应商能够满足这些特殊目标。

最大限度地延长业务正常运行时间

ERX向服务供应商提供甚至适应于"lights-out"设备的 高度冗余的运营商级平台。借助冗余的逻辑和电源、热插拨以及经济高效和创新的用户冗余特性，ERX可以向IP客户提供一致的理想正常运行时间。

真实统计数据

ERX能够收集精确到字节、数据包、接口和用户级的统计信息，使服务供应商能够制定详 细的和汇总报告。ERX使用高效的批量传输设备来上载统计数据，因此使服务供应商不会因统计数据轮询而造成本己繁忙的重要管理网络的超载。由于ERX基于 ASIC的强大功能，用户数据吞吐量可以保持在线速升平，即使启动了很细致的信息收集。

可定制的图形报告功能

Juniper网络性能管理器是为了满足当今服务供应商的高性能要求而开发的 一套集成的服务水平管理(SLM)软件工具。性能管理器的软件使服务供应商能够收集并管理多台设备中的网络数据，包括ERX。性能管理报告器可以生成基于 Web的定制报告，而性能管理库可以生成可直接使用的内容，如预先定义的报告和公式。

性能管理库管理器是一套性能管理工具包，向服务供应商提供功能强大的工具来提供差分业务。这可以通过把网络数据转换成网络智能实现，从 而实现融入到差分业务，如ATM、帧中继、LAN和WAN。性能管理库包括预先编译的设备MIB、技术指数、预先定义的性能标准、SLA标准和公式、嵌入 的预先定义报告等。

性能管理报告器实现报告的轻松定制，不仅仅向服务供应商运营商提供对服务水平信息的接入，而且向最终用户提供按需、基于Web的业务报 告。

Juniper网络性能管理器基于Proviso (Quallaby公司产品)。

通过路由选择协议实现自动故障切换

服务供应商长期以来一直使用路由选择协议来解决网络核心的冗余问 题。现在，服务供应商还可以在网络边缘使用这些协议。ERX全面支持BGP、OSPF、IS-IS和RIP，使服务供应商能够配置冗余路径，并自动绕过网 络故障。此外，服务供应商可以向用户推出双归和负载平衡等技术，以在网络中创建冗余因此也是可靠的上行链路。

此外，ERX在边缘的MPLS功能使服务供应商能够实现高度冗余和划分优先级的恢复，支持划分优先级的路径恢复，并把业务分配到优先级 路径中。

使用IP QoS的服务水平

ERX中强大的QoS特性使服务供应商能够向他们的用户提供差分业务。 ERX结合了精确的分类功能和灵活、高度可扩展的排队，而且支持基于DiffServ和MPLS的业务传输模式，设计用于确保服务供应商可以可靠地提供 （并测量）他们希望提供的差分业务。

特性

IP SLA的出现将使未做好准备的网络措手不及，允许预先行动的服务供应商支持线速统计数据收集和处理，并进行处理以在用户向IP VPN的移植中实现赢利。ERX是运营商级边缘路由器，设计用于提供在可靠业务传输和综合统计数据方面实现IP SLA所需的一切工具：线率性能、精确的统计数据测量、大量统计数据收集、高可靠性和强大的冗余特性，实现IP SLA所有所需的工具，包括现有的1:n用户线路备用，以及强大的QoS特性(实现差分业务处理)。此外，ERX的整个特性集向服务供应商提供他们需要的 IP业务灵活性、性能和经济效益：

• 一个边缘平台可以向专线、xDSL、固定无线和有线用户提供统一的IP业务。SLA可以在任何接入媒体上提供。  
• ERX基于ASIC的强大功能使所有统计数据能够以线速传输而不会对业务吞吐量产生影响。  
• ERX无可比拟的密度在一个机箱中最多可以支持4000条T1，在一个机柜中最多可以支持12,000条T1，从而优化POP空间和能 源利用，并使服务供应商能够实现极具竞争力的定价。  
• 100%的冗余特性，如面向用户的接口冗余，提供极具竞争力的SLA优势。

技术规范

软件规范

• MPLS - 使用BGP扩展支持RSVP、LDP、CR-LDP、VPN(RFC2547)
• DiffServ-TOS分类和标记
• BGP4、IS-IS、OSPF、RIP
• 1:n线路卡冗余
• 所有线路模块上的热插拨
• 无源的中板结构
• 冗余的分布式电源
• 冗余SRP