服务水平管理也需2.0

现在什么都进入了2.0时代，您的服务水平管理是不是也应该提升了?

从网上论坛，博客的普及，到社交网络平台的兴起，互联网把每个人都带入了社区化生活模式中，这就是所谓的Web 2.0at活时代。如果以Web 2.0作为一个分界线，以前是几家提供商对大众用户的单向传播，现在是各种区隔客户和多级服务商的全线互动。

在此发展过程中，服务品质的概念也经历着不断的变化，从网络通断，网络性能，服务器性能，应用性能，服务支持性能。我们看到服务品质(Qos)的衡量标准在不断细化，服务水平管理的思想细化到每一次用户请求的受理，每一个服务的变更以及各级系统的考核中。ITIL作为ITSM服务管理的指导丛书，对服务水平管理的政策和流程都给出了详细的建议。

服务水平管理与ITIL

ITIL V3问世已经有一年半的时间了。与历次升级相比，这次变化非常大。在新的ITIL指引中。融入了大量新的理念和观点，比如市场区隔，客户分析，服务战略，平衡供需等。为帮助实现服务的业务价值带来了很大启发，原本模糊的Value层次(ITSM成熟度)变得逐渐清晰。这种理念引导我们用更优化的战略资产管理进行服务价值链的重组，对细分市场进行差异化的服务营销，并且在服务设计，部署和运营中进行实现。

在内容方面，服务水平管理在第三版的变化不大；但是在结构方面，新版本将服务水平管理，容量管理和可用性管理等几个ITIL v2中的服务交付流程一起合并到了《服务设计分册》，旨在突出服务水平管理与服务目录紧密结合的诉求，提升服务水平的纬度。使协议和管理层次更加贴近业务服务。该分册还增加了服务商管理的相关部分，明确了对第三方的管理过程，结合服务水平管理的支持协议满足情况来优化对服务商的管理。

目前国内一线企业管理的实践探索及服务水平管理工作主要围绕如下几个重心开展，并不断进行优化和改进。

提升服务等级视角

准确度量服务目标

评估服务水平的满足程度

提升服务等级视角

2008年3至4月，ForresterConsulting就服务级别管理和应用性能对389位技术决策人员进行在线调查。

调查结果显示，高达68％的中国受访者通过联机仪表板提供实时的服务水平信息(而这一方式的占有比例在北美为39％，法国为65％，德国为52％，英国为48％)。可见，服务水平作为―种考核方式在中国的普及率已经非常高了。而实际上我们经常会听到类似下面的话：“你说什么?网络平均响应时间达到服务水平?可我在系统里查个订单可越来越慢!”

一位物流企业的IT负责人告诉我们，他们的应用开发和信息系统维护一直外包给一家国际IT服务公司。

该公司提供从采购、物资管理、仓库管理、到门店销售的一揽子服务方案，从服务设计到服务维护全部承包。他每天收到的运行质量报告非常多，涵盖了网络利用率、ERP系统的性能变化、各支持流程的工单处理量以及呼叫解决率等。所有指标基本上都运行良好，支持管理工作可谓井井有条。

但他总是感觉他们企业的服务水平定义还没有和各个业务部门的工作内容紧密联系起来。比如ERP应用，企业各地的财务分支在每个季度末是最忙的，而大量采购计划工作是在每个月的前几天进行。从系统层面来说，他们无法将各个部门的服务过程和服务交易分门别类地呈现出来，这导致无法评估各个业务交易的服务水平。

这位负责人及所在企业的问题在于，虽然以资源为导向的操作水平管理对于网管以及系统性能管理都是有用的，但是需要有一个以服务为导向的水平管理作为业务行为和系统活动的纽带，来帮助平衡对内部门和对外部门的IT供需，规范化服务组合的利用水平(Utility)，从而能从业务的角度持续改进服务资产。

在建设规划中，服务业务架构不难做到。但是在实际设计和实现中，还应该考虑到业务服务模型的灵活性，与OLA的结合，以及与可用性管理、容量管理、连续性管理、供应商管理等方面的结合和互动。比如从ERP或LDAP系统中保持部门和地区的同步，对新业务新功能的发现，对服务访问量、用户行为、用户访问模式的掌握，对业务影响分析模型的建立等，都是应该考虑的方面。

准确度量服务目标

“你测试给出的结果是50万个压力下端到端下载时间是4秒?可为什么总被客户投诉说慢，比如有的用户说需要15秒，而有的甚至等了30秒都没有任何显示?所有的系统指标都正常，我要一个能将这个时间压缩到8秒的方案，是改业务还是改程序?不要跟我提扩容的事，这半年来我们已经扩容三次 了!”

笔者在与某银行的业务开发部进行讨论的时候。该部门的管理人员向我们讲述了他们的困惑。

作为银行业务部门、开发部门和运维部门的枢纽，业务开发部门的主要职责是保障经过测试的应用系统能够顺利进入数据中心的日常维护管理体系。他们的应用系统开发商会根据业务部门的要求，每隔半年左右推出一个新的版本，其中包括20个以上的新功能。在交付测试过程中，他们面临的难题是很难预测新的交易流对现有系统的压力，而这会给生产的上线过程带来很大的压力。

稳定是运维部门上线新应用的最重要标准，他们只能依据现有系统监控进行KPI观测，发现关键系统中的指标变化(比如应用服务器的CPU负载、数据库系统吞吐量等)。

一旦发现新版本上线后关键系统指标出现异常就立刻回退，将新应用返回准生产系统进行针对性的测试。对于服务经理来说，因为无法准确地获知不同工作时间的用户交易性能变化，上线应用的服务目标只能根据压力测试结果和以往客户投诉的经验进行初步的评估。

笔者认为，如果在确定服务等级之前我们能从交易量、交易处理时间、服务器时间等各方面衡量用户端到端性能的变化，从而从业务的角度对新功能的用户体验进行定型，那么，我们就可以掌握新业务中的每一步用户行为的用户实际体验情况。有了这些基础数据之后，我们就可以结合服务周期模式、服务重要程度和服务容量规划，更客观地设定服务目标基线，更明智地确定服务等级协议。根据我们掌握的新服务和现有服务的用户行为和体验数据变化，我们也可以更精准地调配服务提供、优化策略服务。

评估服务水平的满足程度

“你提交的报告确实显示你们缩短了故障响应时间，可我的问题是到底有没有帮助我们解决故障?你们实施ITILt也快一年了吧?我承认IT部门的态度是好了不少，可问题解决不了，各业务部门的意见还是很大……”

服务品质的衡量标准是什么?很简单，就是快和稳定(语出某银行的数据中心主管)。所谓快，就是系统和团队的响应速度快，定位问题快，解决速度快；所谓稳定，就是少出事，不出事。快和稳定谁说了算?用户说了算。

在这个以客为尊的时代，Compuware认为必须从使用者的视角开始衡量，考察从客户端、公共网络到接入层、前台、中后台的全面系统。客户来自五湖四海、操作的习惯也大不相同。根据这些用户群的不同特点，服务设计和服务运行都应该考虑在一定的前提下进行服务等级细分。

比如事故发生时，根据影响的用户量、地区、交易类型和重要程度，自动确定事故的优先级。

在服务设计的持续改进方面，从客户端到中后台，性能问题出现在哪一个操作层面?如果我们针对用户交易路径进行了细分，这样就能进一步发现改进的机会，评估服务等级的优化目标，从而实现考察服务改进的持续性效果。

(阎韶华：康普科纬迅公司技术顾问)