九．操作管理

　　操作管理为了处理那些非事件、问题、变更等事务，比如机房巡检、定期的机器清洁、检修。操作管理可以创建作业，作业的来源有两种来源。一种是直接创建的，比如临时要对一台设备做检测；一种是根据周期性作业计划产生的，比如服务器每日要检查数据文件、表空间使用情况、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指标的，只是统计的纬度是多样的。