三、 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服务一片混沌的情况会在未来成为历史，它应该更具体透明、更量化、更易于控制的，未来你将不能再丢一个粗粗合同把客户数百万的预算吃下去了，起码客户需要知道到底你做了些什么，做到什么水准，作为服务商你可不太可未来一直把合同拿到就算完，做好做坏都得到按合同金额了，客户将会有更多的方法来控制合同的执行情况，服务将不再是一个黑盒子。