CIO实战剖析：13步设计出一个ITSM系统

这是我一直想写的内容，本来是希望把这个项目从立项到规划，到设计开发，到最后的实施应用的全部过程写成一个笔记，但工程浩大，就先把我们规划这款ITSM系统的想法写出来，里面会夹杂着我对这类系统的深入思考。

这种考虑一是基于对ITIL的理解，二是对软件实现的理解，三是运维管理的考量。内容不会十分具体，因为每一个部份基本都是一个模块，如果写得深入，就是一个详细的设计说明书了。下面逐步展开说明。

一、系统目标

系统目标是为了说明我们想开发一个怎样的系统，想利用这个系统做什么，达到怎样的目的。最简单的是，我们想打造一个运维平台，把我们在各个地区分布的运维服务团队，无论属于哪一个客户群的，无论是属于哪一种业务领域的(桌面、网络、系统、软件)，都统一纳入到一个相同的平台上。

他们要基于相同的制度，基于相同的流程，基于相同的理念，用统一术语与方式去服务客户。我们的一个优势是规模与平台资源，但如果我们的人员与业务无法整合到一起，这种优势就不复存在，反而可能成为一个负面原因。因为你没有了大船的承载能力，也没有小船的灵活转身能力。

运维服务业务有其特点，很难标准化，太容易受客户的影响而改变流程或制度。一旦你的团队分散、客户多，而且地理分散，光依靠发布ISO20000的体系文件，对人员做扎实的培训，就指望把大家的各种作业规范统一起来，不是说不可能，极难。运维服务数据极难分析与采集，一个显而易见的方式就是利用软件。

我们在打造自已的平台时，概括来说，有这么几个方面要求：

①设计要求：基于我们的运维服务业务特点，把我们的管理经验置入其中，同时纳入ISO20000的实施所得，就是我们的服务体系。还要参考REMEDY优缺点，这些是我们规划设计这系统的基础。

②范围要求：我们这个平台要能管理所有的运维对象(各种类型的项目)，同时要管理我们的运维资源(人)。运维对象可以具体到具体每一个CI及其备件，运维资源具体到每一个人的工时利用。其它像服务目录与SLA等，都要纳入管理。

③扩展要求：运维平台可以满足公司模式的发展需求，以及产品的发展，这里涉及具体的公司现状，就不多作说明了。

④质量要求：在应用质量上我们要超过REMEDY，注意是应用质量，不是指功能，功能上我们无意与REMEDY去一争长短。我们有信心只要一年实施时间，就完全可以超过REMEDY在公司的应用质量。

二、系统架构

我们使用的是B/S系统架构，这是为了方便地理分散的员工使用，也是考虑到日后全国的用户可能会登录系统进行部份作业，比如参与调查，或者开放论坛等。采用B/S的架构，负面的影响一是速度，二是界面表现力，但日后的升级维护比较方便，用户登录也很方便。是否成功，要等日后大规模应用时才能进一步验证。

开发平台是.NET2005 C#，数据库采用ORACLE 10G。另外我们在流程中(比如事件升级、派单)做了一些邮件通知与短信通知的功能，其它技术方面，倒没有太多值得说明的地方，也可以说技术并没有太多的亮点。

三、流程控制

在系统流程控制方面，放弃了采用工作流引擎的想法，一是不希望增加项目复杂度，二是硬性的流程事实上不现实。因为在运维服务活动中，单据的流转方式很难硬性定义，加上一人担负多个角色，去配工作流没有太多意义;同时我们主要是自用，运转起来后，去调整流程的可能性较低，那样工作流引擎存在意义就很低了。

所以我们在开发过程中，一旦有硬性的流程就写死在程序中，而单据的流转是由人确定的，可以不做限制进行单据的转派。不能指望软件去实现一切控制，有些控制点放在系统之外，往往会更好更省力。

软件只是一个汽车，你想它跑得更快更好，需要有一条道路去配合在一起，这条路就是你的管理制度。许多寄望软件实现的控制点，一旦没有考虑清楚，最后会带来许多麻烦。所以要有先松后紧的策略，逐步增加控制，而且要以制度为先。

四、服务台管理

事件管理与服务台管理是不同的概念，前者是一种流程，后者是一种职能，许多人没有搞清楚这两者的关系。事实上事件管理的许多操作是由服务台人员完成的，服务台本身并不存在流程(注意这是站在ITIL流程的层面)，服务台管理本身也是一个独立的学问。

这要根据每个组织的特点去考虑，在我们的情况中，有几名独立的热线人员作为服务窗口。对这些人员的话务管理是通过语音系统管理的，而这个语音系统与我们的ITSM系统是有接口的，真正的事件操作事实还是在事件管理中完成。

这里特别提一下，在我们的ITSM系统中，事实上是没有一个服务台管理模块的，我相信许多人没有真正理解服务台的含义。把热线与服务台划等号是有问题的，尤其是IT服务领域，一旦你包含比较多的软件项目，服务台就一定会发生变异。如果你的服务台人员只是起到一个转电话与派单的作用，那事实是一个语音菜单的功能，这样的服务台设立意义不大。

多数人以为服务台作用是单点受理以及快速响应，但这更多只是手段不是目的。服务台并不一定在物理上坐在一起，它可以是多种多样的，一定搞清楚服务台的目的是什么，它为什么而存在。IT服务不同于其它的行业，当用户打电话到携程与招商银行的的服务台时，跟打电话到一个IT服务商是不一样的。携程与招行的服务是“大众”与“标准”的，他们的服务台基本可以做到你电话过去就能响应，而IT服务商的服务台通常做不到，为什么？

因为你的服务更具“纵深”，所以对你的服务台提出了更高的要求，你让几个完全听不懂用户问题与需求所在的热线非常快地接到用户电话有用吗？响应的定义是什么?如果仅仅是接听了用户的请求，而不做任何反应，这叫响应吗？

我让一个电话录音机当热线，这算不算响应呢?如果你的热线是接转电话给工程师，经过热线转一下的意义何在？工程师仍然处于随时待命的状态，你的服务资源没有任何节省，而是在浪费，同时让用户重复问题，或者让热线转述问题，造成信息缺失。

当你的服务台没有起到服务台的作用时，你会发现一个有意思的现象：用户会绕过你的服务台，直接打电话到工程师。不要说这是用户的问题，这是你的问题，你没有把一个正确的路径给用户，用户会按最有效率的路径来走的(是不是类似我们走草坪的情形?人们不会喜欢90度的直角小径，会用斜线穿越草坪)。

IT服务业的服务台不同于传统行业，用传统行业呼叫中心的做法去设立IT服务业的服务台，一般是行不通的。尤其当你的业务领域复杂时，可能虚拟服务台是一个不错的选择，没有一定的硬性标准，要根据自已实际的业务需要来。一个真正好的服务台，可以节省你的服务资源，而且可以更快把客户请求结束掉。

五、事件管理

事件管理是创建、处理事件的模块，一个事件的生命周期全部会在此模块内。在设计时，需要考虑以下的信息：

①事件的类型：事件管理在我们规划中，是一个非常重要的窗口模块。事件类型我们分为了有故障、请求、咨询、新需求、投诉，基本上面向客户的事务都会在此发起，这种类型也是为了日后的统计分析。

②事件的分类：由于项目众多，考虑到横向统计的需要，我们要定义一个公用的事件分类，以便运维管理分析。我们分了硬件、软件、网络、数据库、接口、业务这几个大类，日后可能会进一步细化分类，以便做更深入的分析，但这个难度很大，需要时间的积累。

③事件的等级：最开始我们希望引入优先级(严重度与紧急度)，但发现这样定义非常困难，对指导工程师处理意义不大，还可能会误导信息，所以最后把事件硬切为5个等级。公司给出最粗的定义标准，然后由每个项目具体定义解释。这样每个工程师在作业时，就可以定义事件的等级。默认情况下，等级越高的事件，表示越严重，也表示要优先处理。虽然会相对粗放一些，但简单适用，而且我们的SLA是与此相关的。

④事件的状态：事件状态是为了表达事件单当前的处理状况，我们分了创建、分派中、处理中、等待中、解决、关闭。这样可以形成看板与统计。

⑤事件与CMDB的关联：CMDB的用处，在事件的应用就相当关键。事件发生时，要做一个关键动作，就是组件定位。需要搞清楚这个事件是发生在什么项目(CI)的什么地方(CI)，需要事件创建者做出定位;然后派单时，根据你的CI定位，带出相关的责任工程师，与事件与CI的关联，给你的运维分析带来丰富的信息。你CMDB所有的信息与事件的信息可以交叉统计分析，比如上面说的事件的分类有硬件，那我想知道桌面项目一年中，硬盘发生了多少故障?希捷品牌的硬盘发生了多少故障?客户对哪一款软件的咨询次数最多?这些信息依靠事件中的组件定位，可以轻而易举告诉你。

⑥事件与其它流程的接口：事件与变更、问题、知识库是存在接口的，事件处理过程中可以直接发起变更申请，也可以发起问题申请与知识库申请。需要说明的是事件与变更的接口，我们的事件是否关闭没有硬性判断与之关联的变更是否终结，而是从事件单方面流出信息，并没有把变更的处理情况与事件单关联，让这个流程分线程去作业处理。主要是担心做得太死，可能导致事件单关闭受阻。

⑦事件的时长与工作量：在任何一个事件的处理时，对于时间有二个概念，一是事件的时长，即一个事件的处理周期(从8：00创建到12：00解决，4小时)；一是事件花费的资源量，即工作量(4小时的时长中，工程师可能投入了2小时来处理)。时长是为了SLA的计算，后者是为了运维资源的分析。

⑧统计分析：事件报表的统计分析非常丰富，可以从CMDB的角度出发，去统计每一个项目、每一个设备的事件情况;还可以从客户的角度出发，统计某个客户组织或某个客户的事件情况;还可以从运维组织的角度出发，统计我们的一个服务团队或一个服务人员的事件情况;可以从事件本身的信息出发，根据事件的类型、分类、等级、状态、来源(电话、邮件、WEB)去统计，还可以统计SLA方面的数据。

六、问题管理

问题管理处理逻辑其实是类似事件的，它的许多信息是继承事件，比如等级与类型等。在规划问题管理时，要想清楚问题的分类等级等信息跟事件是什么关系，问题管理的大概作业界面有哪一些，在系统流程上有哪几个步骤，如何留下问题的处理时长与工作量等等。

还要想清楚问题与事件在程序处理上的区别，比如问题的创建后需要有一个审批的动作，问题不服从SLA，问题有知名错误的概念，这一部份的设计如果你的事件规划好后，问题管理是相对简单的，它的难不在于程序，而在于日后的应用。

问题的统计报表，基本上与事件的纬度类似。

七、变更管理

在ITIL中，变更与发布是两个独立的流程，我们把这个流程合并为一个。发布的控制在程序中可以实现的控制点是很少的，而且它与变更是如此紧密。在我理解中，变更的实施就是发布流程，即发布可以理解为是变更的一个子流程。发布不仅仅是针对软件的，硬件一样也会有发布的概念，比如将一台新设备布署到生产环境中。

对CMDB的控制，在业务层面全部需要通过变更来实现，CMDB精确度如何，很大程度上取决于变更的执行情况。我们考虑到一点，如果让CMDB的信息更新得到有效控制，当工程师在填写变更申请时，在界面上就提列出变更前后的具体信息;审批时，不光是审批变更的行为，更重要的是要审批变更的内容;如果审批通过，执行后，根据这些信息把CMDB做更新。这样可以相对减少没有约束的对CMDB更新的行为。

变更管理为什么而存在，在业务上起到什么作用?这些我觉得很多人没有想清楚，很多时候变成变更管理，主要目的是为了实现对CMDB的维护控制，这是对变更管理的曲解。这点上我也犯过这种毛病。

变更的主要目的是授权与控制对基础架构或其它服务的改变，这里说的更新是指现实的服务或物理上的基础架构，而不是系统中数据的更新。100条变更请求并不会都落入到CMDB的更新中，可能有5条是对SLA的变更，所以变更与CMDB不是划等号的。

当你的工程师对具体设备做维护时，事实上你已赋予他改变基础架构的权利了，如果他把生产环境中的CI做了改变，那他再走变更管理的意义是什么？是为了控制他对CMDB的更新吗，这种控制反而起到负作用;如果无法控制别人对生产环境的变更行为，或者你是默认授权的，最后给予一个通道让他直接维护CMDB，比如一名桌面工程师，在修电脑的过程中，把一台电脑的操作系统升级了，这时他要走变更管理流程吗？

　　我的回答是不应该，除非他不得到批准就不能对操作系统做升级，这时变更才具有意义，不然这种控制是完全负面的。如果这个工程师在修电脑的过程中，发现硬盘彻底坏掉了，需要更换硬盘，可能超出了他的权限范围(这也需要考虑到具体业务定义)，这时他不走变更流程根本无法得到硬盘，变更才具有一定意义。

但上述情况并不是最具代表性的，这样的业务情形最具有变更管理的代表性：要对一段网络做调整，但可能会影响到几个系统项目，这时需要发起变更申请，由涉及到的几个项目负责人与网络领域的主管一同做变更的评估。如果认为有方法对应，可以进行此次变更的话，需要制作一个变更的实施方案，安排人员实施调整操作。实施完成，把CMDB中的信息更新。

变更管理的统计报表，可以从发起源统计，可以从CMDB的角度发起统计，也可以从变更本身的信息进行统计，比如变更的状态、变更的分类、变更的人员等。

八、配置管理

配置管理模块，核心的就是CMDB，这一点我就不再毒品啰嗦了，把配置管理的流程层面的一些点再说明一下。

CMDB的审计：CMDB审计是需要规划好的，应该可以根据各种条件审计，比如根据某一类的组件，某一个项目的组件，还可以确定一定的数量进行审计(随机抽取)，也可以决定一定的比率(随机抽取)。审计的目的是为了检查CMDB的数据正确情况，找出问题并修正。

CMDB的锁定：CI在某些情况需要进锁定，比如变更时，比如审计时。为什么要这样呢?如果你对一个CI变更时，不锁定这个CI的信息，会发生几个地方同时对这个CI做信息更新，由于时间差，很可能把错误信息更新到CMDB中了;同时用户在变更过程中调用CI信息的话，也会发生误导。所以需要控制单线程对CI进行维护，在同一时间只能有一个对CI维护的动作进行。审计也是一样，如果你审计开始时，这个CI信息一直在动态变化，不锁定CI的话，审计无法进行，同时会审计出一个错误的结果。

配置管理的信息可以被许多模块调用，需要规划到CI查询的画面，然后置入到事件、问题、变更、操作等模块中。CMDB的人机界面相当关键，要尽可能方便调用、查询、操作。

九、操作管理

操作管理为了处理那些非事件、问题、变更等事务，比如机房巡检、定期的机器清洁、检修。操作管理可以创建作业，作业的来源有两种来源。一种是直接创建的，比如临时要对一台设备做检测;一种是根据周期性作业计划产生的，比如服务器每日要检查数据文件、表空间使用情况、JOB运行情况、操作系统日志。操作管理与能力管理中的监视计划存在许多联系。

操作管理有一种东西需要特别，就是服务日历。什么是服务日历呢，跟客户签订运维合同时，我们承诺我们的服务是8*5或16*7，这种承诺表示在这个时间期内，我们周期性的任务是与之相配的。比如我们上面说的服务器巡检，如果每4小时需要做一次，我们跟客户签的是一年8*5的合同的话，那么我们每周要做5*2次巡检，这个次数是事先定义好的。

每个项目的服务日历可能不同，这表示每个项目都可能存在一个服务日历。根据这个服务日历，我们在系统中制作出一个周期性的计划，系统根据服务日历与计划内容，每天提前生成出作业指令给工程师。计划上还定义了标准的工时要求与作业要求，工程师每天把这样指令做完，然后把相关的作业关闭，并留下相应的实际工时，这就是操作管理的核心。

操作管理主要功能点有制作计划、创建作业、作业处理、作业关闭、统计分析，功能界面是相对简单的，但这个模块可以把除事件、问题、变更之外的工程剩余活动有效管理起来，而且可以保证你的服务作业得到强制执行。它可以针对每一个批量计划做分析，分析执行如何，花费了多少服务资源。要注意的是操作管理与事件管理没有做程序接口，就是说如果工程师在巡检时发现故障，需要手工在事件管理创建事件，而不是自动去触发事件。

十、任务管理

任务管理的本意是为了管理我们的管理资源，这是针对我们公司自身的运维管理特点设计的。每年我们做许多管理改善的工作，做很多培训，开许多会议，我们一直想分析一下花在管理上的资源是多少，希望把管理工时与直接生产工时做一个比率分析。这是管理效率提升的非常重要的基础数据。

比如领导要求各个领域开展员工能力提升活动，在任务管理中，只需要部长生成一个任务，派给各个业务主管，任务中标明要求完成的时间点;每个业务主管接到这个任务，展开作业，作业过程的记录与工时会不断增加在这个父任务上，一直到完成审请关闭时;当每一个子任务都关闭时，父任务可以关闭，统计出花费的资源情况，任务可以多层分解，甚至可以分解到每一名员工身上。这可以加强任务的控制力度，也会控制管理人员过度使用资源。

任务管理更多是为了管理者的工作而设计的，这也是运维服务作业中最后一块没有被记录的话动。这样下来后，事件、问题、变更、操作、任务就构成了任何一个运维服务人员，无论他是领导还是一线员工的作业平台，只有监视所有的活动，其资源使用才被全部监视。

任务管理的报表有针对任务执行情况的，还有横向分析任务类型的，即任务的资源占用情况。如果数据积累足够多时，这种分析展开，会让我们非常吃惊，因为运维服务的大量资源是被无效使用的。这样运维服务管理才有改善的方向与具体指标。

十一、SLM管理

某种程度上，我们的ITSM系统并没有实现真正意义的SLM管理，系统中并不关心SLA制订出来前的过程，也没有把UC与OLA等纳入其中，我们只把制订出来的SLA设置在系统中，以实现监控与作业。所以以下说的是SLA的管理实现方式。

SLA在我们业务中分为故障解决率与Q指标，EUS(客户满意度)是另一个纬度的数据，不在此列。故障解决率是指在规定时间内完成事件处理的百分比，Q指标是持续运行时间。

具体谈一下我们的实现方式。前面说的服务日历是很重要的一个基础数据，没有它，SLA的计算全部会错。我们把事件分成了5个等级(SLA只适用于事件处理)，每一个项目都会针对每一个事件等级设置解决时间要求值(比如一级事件需要2小时，二级事件需要4小时，三级事件6小时，四级事件8小时，5级事件12小时)。

这里定义的时间值是与服务日历匹配的，比如服务日历定义5*8是指周一至周五的8：00-12：00，14：00-18：00。如果一个一级事件发生在周五的1 7：00，即便是第二周周一的8：30解决，也没有违反SLA(虽然现实中我们会马上处理，但SLA计算是如此)。

另外Q指标的定义是这样的，每一个项目要定义清楚到底哪一个事件等级会纳入Q指标的计算中，比如一级、二级事件的故障时间(从事件创建到事件解决)会纳入计算，三、四、五级的事件故障时间就不纳入计算，这样随时可以计算你当前的Q指标是多少。

SLA设置完成后，就会在事件中就用。当你把事件定位在一个项目时(CI)，你选择了事件等级，此时系统会调出事件解决的时间要求;当你创建完成时，系统开始倒计时。SLA的报表主要是针对故障解决率与Q指标的，只是统计的纬度是多样的。

十二、知识库管理

知识库管理考虑现实情况，我们没有做得太复杂，运维服务的知识有较强的时效性，更新较快。这里说的知识是针对故障处理方面的，并不是指员工的技能或知识培养方面，这与通常说的KM有不少区别。

运维过程中的知识非常具有针对性，所以没有把通用的知识纳入考虑，都是从项目的角度提出来。知识的创建有三个来源，事件生成、问题生成、手工创建。为了便于查找，我们的做法是以项目为纲，以分类为目，以关建字为辅，即最根本的分类是项目，然后是根本事件问题的分类，最后是用关键字，用这几个手段查找知识点，供工程师处理事件时调用查看。

无论知识是从事件或问题或手工创建，都会有一个审批的过程控制知识库的更新，还可以设置知识有效期限。另外，知识库的创建可以做一些统计与分析，看哪一个团队的知识复用较多，哪一种类型的知识较多。对于知识的利用，不建议纳入系统考虑，因为在软件中难以识别，靠点击意义不大。一个人打开知识看后，可能发现根本不是他想要的，或者他只是借鉴看一下，这时强迫按钮操作没有意义。

十三、调查管理

调查管理原本是希望改变以前手工发邮件采集满意度调查的做法，设计时，发现可以对象化，做得更灵活些。我们是这样考虑的：可以设计许多问卷，可能是针对客户满意度的，可能是为了调研我们的服务方式改进方向的，也可能是为了解服务产品化的潜在空间的。问卷设计好后，可以生成调查任务，一个问卷可以被无限调用，而调查结果是针对调查任务而不是针对问卷的。

调查可以直接发网址到客户邮箱(取自客户数据)，也可以直接把问卷发过去。如果是WEB采集数据，可以生成用户名与密码发到客户邮箱，用户登陆系统填写，也可以手工回收。但WEB是省力的，因为调研结果由系统自动生成。

有一些细节需要考虑，比如任务的开始与结束时间决定问卷填写开始与停止，是不是设置必填与可选，是翻页填写还是整页显示，甚至问卷的答案选项与分值设置，还要注意调研对象散与客户资料的集成(从某一个客户组织选择一定百分比)，还有CMDB(针对某一个系统或项目)的接口。

基本上把我们大的模块写完了，有些大杂烩，有些地方不够深入，也没有把一个ITSM系统每一个模块应该具备的元素提炼好，象一些绩效点没有成体系写出来。但上述许多设计仍然是国内公司一段时间内较难企及的，这里包含许多年来各种各样的思考，软件的、管理的、ITIL的，对运维业务本质的理解。从事这种系统开发的公司或个人能知道其中的价值。

来源：IT专家网论坛