|
sulu06
发表于 2011-10-20 11:07:43
①事件的类型:事件管理在我们规划中,是一个非常重要的窗口模块。事件类型我们分为了有故障、请求、咨询、新需求、投诉,基本上面向客户的事务都会在此发起,这种类型也是为了日后的统计分析。
②事件的分类:由于项目众多,考虑到横向统计的需要,我们要定义一个公用的事件分类,以便运维管理分析。我们分了硬件、软件、网络、数据库、接口、业务这几个大类,日后可能会进一步细化分类,以便做更深入的分析,但这个难度很大,需要时间的积累。
③事件的等级:最开始我们希望引入优先级(严重度与紧急度),但发现这样定义非常困难,对指导工程师处理意义不大,还可能会误导信息,所以最后把事件硬切为5个等级。公司给出最粗的定义标准,然后由每个项目具体定义解释。这样每个工程师在作业时,就可以定义事件的等级。默认情况下,等级越高的事件,表示越严重,也表示要优先处理。虽然会相对粗放一些,但简单适用,而且我们的SLA是与此相关的。
④事件的状态:事件状态是为了表达事件单当前的处理状况,我们分了创建、分派中、处理中、等待中、解决、关闭。这样可以形成看板与统计。
⑤事件与CMDB的关联:CMDB的用处,在事件的应用就相当关键。事件发生时,要做一个关键动作,就是组件定位。需要搞清楚这个事件是发生在什么项目(CI)的什么地方(CI),需要事件创建者做出定位;然后派单时,根据你的CI定位,带出相关的责任工程师,与事件与CI的关联,给你的运维分析带来丰富的信息。你CMDB所有的信息与事件的信息可以交叉统计分析,比如上面说的事件的分类有硬件,那我想知道桌面项目一年中,硬盘发生了多少故障?希捷品牌的硬盘发生了多少故障?客户对哪一款软件的咨询次数最多?这些信息依靠事件中的组件定位,可以轻而易举告诉你。
⑥事件与其它流程的接口:事件与变更、问题、知识库是存在接口的,事件处理过程中可以直接发起变更申请,也可以发起问题申请与知识库申请。需要说明的是事件与变更的接口,我们的事件是否关闭没有硬性判断与之关联的变更是否终结,而是从事件单方面流出信息,并没有把变更的处理情况与事件单关联,让这个流程分线程去作业处理。主要是担心做得太死,可能导致事件单关闭受阻。
⑦事件的时长与工作量:在任何一个事件的处理时,对于时间有二个概念,一是事件的时长,即一个事件的处理周期(从8:00创建到12:00解决,4小时);一是事件花费的资源量,即工作量(4小时的时长中,工程师可能投入了2小时来处理)。时长是为了SLA的计算,后者是为了运维资源的分析。
⑧统计分析:事件报表的统计分析非常丰富,可以从CMDB的角度出发,去统计每一个项目、每一个设备的事件情况;还可以从客户的角度出发,统计某个客户组织或某个客户的事件情况;还可以从运维组织的角度出发,统计我们的一个服务团队或一个服务人员的事件情况;可以从事件本身的信息出发,根据事件的类型、分类、等级、状态、来源(电话、邮件、WEB)去统计,还可以统计SLA方面的数据。
|
|