经济危机后的ITIL V3实施之年

申请免费试用、咨询电话：400-8352-114

ITIL在国内已经有几年历史了，今年我们的水平是怎样的，我分享一下自己的体验和心得。第二谈一下面对今天的挑战和机遇，如何用六西格玛这种传统的进行质量管理的体系进行优化。最后分享一下服务管理的间断实践。

首先看进行时，我的体验是自动化已经进入普及阶段，我所接触的客户，中大规模的客户已经采用了各种各样的自动化管理工具进行系统监控和维护，服务概念已经深入人心，很多机构或多或少采取流程化的概念进行日常运维管理，在有些机构里已经有专门服务部门，IT服务经理负责对IT服务和业务部门的沟通，所以自动化和服务理念已经深入人心。但还是面临这样的问题，这两点是我在和客户聊天的时候告诉我的，一方面服务水平，很多单位有了服务水平，但是问题是说业务部门会有疑问，你说你达标了，我的系统下一个订单还是慢，你定的是什么服务水平？再一种问题是说我们有了ITIL，甚至有些单位采用自动化的服务台工具来辅助自己ITIL的流程，当建立这个流程之后，在IT部门、业务部门建立了共同沟通的一点，但还会有问题，这是一位CIO告诉我的，这是他们业务领导对他们的评价，首先你们的报告显示出你们缩短了故障相应时间，KPI减少了，但我的问题是你们故障解决了没有？你们ITIL实施一年多之后态度好了不少，但如果问题解决不了，业务部门的意见还是很大。我不知道在座各位，无论是ITIL的实践者、提供服务的人还是您是最终用，大家有没有遇到类似的疑问？

举个例子，如果你的平均响应时间，有人很快，举个例子，是10分钟，有人一分钟响应，有人半小时响应，很可能半小时响应的是六成，平均值是达标的，但是客户可能是不满意的，因为他赶上态度好、能力强的人才会响应快，大部分对他的服务是不好的。

下面举个例子，这是在国内实施的真实案例，谈ITIL实施和IT服务实施的时候，更多关注流程的质量控制改造，大家可能觉得您的单位已经实施了 ITIL，其中涉及流程、人员已经太多头疼的事情了，我们听说做六西格玛也是这套，会不会更头疼，给我ITIL之后又给了我六西格玛，实施起来会不会很虚。在这个客户系六西格玛实施、持续改进包括两方面，一个是流程持续改进，据个运维层的例子，让大家看到六西格玛在IT服务中的应用并非不可触及。我这里看D、M、A 三个部分，第一要解决的问题，定义应用的性能提高，这句话不是定义，这句话无法执行，所以细化，第一要定义CTQ，关键交易是什么，哪个交易对你的整个应用里访问量最大，对客户影响最多。他们告诉我们是登录流程。

然后第二定义问题是怎么衡量这个登录流程，用户体验，我们不靠流量、交易量、点击率。当有一个人点登录的键的时候，到看到界面是多长时间，他们定义5秒钟。第三定义应用流程，就是登录过程中会有哪些相关交易、执行哪些具体的框架、哪些GSP会调用，十分具体。这是定义。测量两个角度，一个是测量用户体验，采用了相应技术手段，帮助他感知用户体验。最直接的方法是问卷调查，问卷调查是成本比较高的方式，这里我们用了一个工具的方法。

第二是测量支持这个交易的相关资源的服务。第三步是分析结果，第一你要知道故障根源，然后提供一系列解决方案，要选择其中一个最佳解决方案。提高的过程，在测的阶段我们找到了根源了，然后采取最佳解决方案解决了。当有缺陷重复出现的时候，就要考虑如何改进，我们提的建议是除了改进服务流程、支撑系统之外，我们建议在建立负载测试，这不是我们国内通常说的压力测试，模拟交易量、虚拟用户，不是这样的。

当你把压力加上去，看到后面所有的网络的变化、应用服务器的变化、数据库的变化，每各里面如何运行的，采用相应检测手段，国内已经有丰富的检测手段，部署在上面进行持续改进，最后是控制，体现在三个方面，一个是主动监控，第二是有关服务水平和用户管理的告警管理方式，今天如果客户体验不好才是真正的告警，才让您的小组真正投入运行。而且正因为知道了用户体验的感觉不一样，才会知道什么事情对业务影响最大，投入最大的应急度。最后一点控制是把交易监控和分析纳入变更控制，当系统有变更的时候要考虑影响。

控制过程中发现有两个告警，是基于客户响应时间的，他们定义5秒，时间低了，一个是 6.98，一个是6.56，影响用户是71个，是71K用户，这是查询。另外一个交易4007.08，这是更关键的交易，我为什么提这点，大家学过ITIL，是不是记得在事件管理里，平时怎么定，都是预定好的，什么事件影响力大的。只有有了真实用户感知工具之后，这才是基于用户体验的。

在ITSM的要点，以客为尊，第二是80/20原则，第三是确定关系，大家看下面这张图，这是业务影响分析和服务建模的过程，要把交易和支撑它的子交易以及硬件网络做一个影射，这是我们说的业务服务管理内容，这是流程图。最后是持续改进，对IT人员是天天都见的。最后做一个总结，传统的IT服务管理里，从底层监控开始，先部署一些监控工具，然后做ITIL、Service，然后做BIZ，服务影响、服务等级管理。但基于这样的概念，很容易得出一个结论，所有问题都是资源问题，一年统计下来，应用相应时间慢，什么原因？CPU利用率过高，扩CPU吧、升级机器吧。

建议大家从业务角度出发，看运维、每一个故障、服务流程改进，最后才是体系架构，因为通常上，统计表明，大部分影响您的性能和可用性问题都在应用上，其次在流程上，客户抱怨很多都是升级资源，时常不解决问题。以业务为核心

第一我们定义有什么关键应用，如何定义质量状况、影响多少用户、这些用户体验差了多少。这是帕拉多图，资源角度看可以、部门角度看可以，可以从地理位置看，这样知道哪的问题最突出，解决哪的问题。这是六西格玛实际应用历史机的案例，这是封装好的软件产品，加上相应的实施方法论，可以短期内实施效益最大化。（CIO时代网）