IT 部门事件管理模式建立分析

　　1、研究背景和意义 IT 服务的最佳理论实践是 ITIL，ITIL 已经成为了解 IT 服务最简单直接的一套方法论。IT 服务管理简称为：ITSM。ITIL 为 ITSM 提供了专业术语和流程指导，告诉我们应该怎么去做 IT 服务，而 ITSM 是落地的 IT 服务，不停的在流程中被使用。ITSM 是已经存在的且以 ITIL 为指导更趋向合理的一套 IT 服务管理。 两者的关系可以汇总为 ITIL 是标准，是为 ITSM 提供流 程和准则的， ITSM 是实 践过程中依据标准而落地执行的服务提供。 这两者都是科技发展 到一定阶段的信息化产物，是 IT 以服务的形式体现的一套标准和规范。 IT 服务管理的难点就在于管理的无序和被动，无法透明化或可视化，技术人员的服务意识差，效率低且 IT 人员的成本高；IT 服务的风险也是很大的，诸如：云计算的兴起让云中心服务的中断变成业务的灾难。 核心应用系统错综复杂经常中断，难于管理，经常是事后救火，此种情况导致的业务损失难以弥补或估算，错综复杂的信息系统故障难于定位，相应管理跟踪和处理，一不小心就成了企业随时爆炸的火药桶和负担。在这种情况下对 IT 服务管理中事件的管理作为最为关键的一环就显得尤为重要。 2、事件管理的概念 ITIL 中 IT 的服务管理包含服务台管理、事件管理、问题管理、变更管理、配置管理、发布管理、服务级别管理等。事件管理作为 IT 服务管理中重要的一环，几乎所有的公司都对事件管理做了管理规定。有些公司还沿用老的叫法只把最为重大的事件单独做管理规范，称为故障管理。其他非重要级别的、例行事件类型称其为服务请求管理。也有公司沿用 ITIL 管理叫做事件管理。但事件管理有一个共性在于以快速解决表象为目的，而不在于查找根本原因。因此时效性成为其评价标准。 2.1 事件管理流程的定义

　　什么是事件管理呢？ITIL 中定义的事件管理流程是 ITIL 主要流程之一，它的主要目标是尽快解决日常工作环境中出现的事件，保持 IT 服务的稳定性，监控事件的发展，并在事 件得到解决之后将其关闭。

　　事件往往是表面的问题，如果出现普遍的事件时，比如：无法获得 IP 地址、收发不了邮件，要调查下根因，这时就上升为问题管理。如果批量的出现此类事件可升级事件级别。按照重大事件的优先级进行事件管理流程管控。但无论普通还是重大的事件根因的排查都在 问题管理流程中。

　　2.2 事件升级 这里还需要指出升级的概念，升级的目的在于需要时获得公司额外的资源支持，以达到服务级别目标或客户期望的活动。任何服务管理流程内部都可以升级，但升级常常与事件管理、问题管理和有关客户投诉的管理有关联。主要有两种类型的升级：技术升级和管理升级。 管理升级容易理解，即通知更多高级管理人员，也就是邀请他们参与更加疑难问题的排查。 技术升级是指将事件、问题或变更转给具有更高技术的人员或是组织，以便进行疑难问题的快速跟进解决。 2.3 事件定义优先级

　　事件的优先级是根据影响度和紧急度共同设定的。影响度是对业务流程影响的一种测量，影响度通常基于服务受到的影响来判断影响度的高中低。即上述表格中影响度按照服务影响高就是 1，其次依次为 2、3。 事件的紧急度是测量事件、问题或变更持续多少时间会对业务产生重大的影响。比如，如果事件年度才会影响业务，因此紧急度的判定最重要的是时长，所以可能会出现影响度高的事件紧急度可能为低。而优先级正是结合了影响度和紧急度按照上述表 1 二维表格中标记的数字，定义了优先级。 优先级是用于确定事件、问题或变更的相对重要程度的一个判定标准。用它来确定采取 行动所需的时间。服务级别另外有相关专业标准结合判断。这里需要结合服务级别就是通常 所说的 SLA 来进行优先级的判定。 由于本文重点在于说明事件管理，这里可将服务级别分为高、中、低三类；例如 SLA 中规定：优先级为 1 的事件必须 4 小时内解决。那解决方案就需要控制在 4 小时内。那这个事件的影响度和紧急度根据其标准都是高才对。对业务有重大影响的事件，重大事件将导致重要业务的中断。一般来说事件优先级为 1 级的事件默认定义为重大事件。若是重大事件就需要按照重大事件流程管理方案来进行此类事件管理。本文的重点也是此类事件的管理辨析。 3 事件管理 3.1 事件管理的主要角色和职责

　　3.2 事件管理流程 一般事件管理流程分为：识别记录阶段、调查诊断阶段以及解决关闭阶段。这些具体的流程在 ITIL 体系中讲解的非常细致。

　　记录在案：所有已识别的事件都要被记录，不论事件大小均第一事件被记录是事件管理的第一要务。解决时效并不会因为记录而耽搁，反而会因为记录有据可查；若因情况紧急无法及时记录时，可进行事后补单，但补单时间不得超过一定时效（比如 12 小时等规定）；

　　：事件管理的角色一定要清晰，从事件发生到解决涉及的角色必须明确分工且在日常工作中能正常流转；

　　：事件的首次响应应对应到真实的团队，可以为服务台人员，也可以由类服务台一线人员，无论是哪类人员均应记录并初步支持且负责跟踪事件处理的整个过程直至事件解决；

　　：事件升级一定要依据情况判断执行，不可将事件延误解决时效，以免引起更大事件。

　　4 事件管理模式 4.1 三种管理模式阐述 本文重点在于讲解三种重大事件的管理模式：统管模式、自管模式以及联动管理模式；

　　是指公司设定专门的事件管理团队，针对所有的事件都进行从头到尾的管理，即从报障到解决事件都需要事件管理团队跟进管理，亲历亲为；

　　是指公司未设定专门的事件管理团队，由每个业务条线对应的 IT 团队自行针对此类 IT 服务进行管理。该 事件管理的对象是该条业务线对应的 IT， 每类事件都由该条线的 IT 自行管理；

　　是指公司设定了专门的事件管理规范和流程，且针对事件和流程中的角色做了明确定义，业务条线的 IT 依据流程提供服务，在遇到难以解决或是流程不畅的情况反馈至该标准化团队进行更新改进，再次推广。

　　4.2 事件管理在实际工作中的应用 一般公司都设置了事件管理团队（或故障管理团队），该团队的职责主要在于制定事件管理规范（制度、流程和角色分工设定）以及对事件管理不断改进和完善。该团队仅作为监督团队，对流程负责，不对具体事件的解决负责。即前面内容 3 中事件管理的主要角色和职责的描述和事件管理具体如何做是该团队要着力的点。 按照上述模式的分类，其中实行统管模式的公司，设置了专门的事件管理团队。但该团队针对事件不仅负责事件管理规范制定，还参与具体的事件处置工作。这就被人们称为：“既当裁判员又当运动员”。 在 IT 服务流程的事件管理中，该流程的裁判员就是该事件管理团队，那该团队应承担的就是管理规范的制定和跟进事件的发展并总结经验，分享经验，并非真实参与协调解决事件管理。可在统管模式的事件管理情况中是该团队针对事件管理的规范做了标准化规定履行了规则制定者（裁判员）的职责外，又在协调解决事件中变成了该流程中的事件处置者（运动员），这样就违背了公平性和公正性原则。既然能制定规则，就应该置身规则之外，让建立了业务条线中 IT 队伍中的事件管理角色的团队进行故障的处置才是妥当的。 模式二中属于只有事件管理的角色，没有综合指导和标准化团队来落地规 范。这里不再展开描述。我们重点在分析第三种模式：联动管理模式。

　　该模式是规则制定者和规则运用者一起发力的。专门的事件管理团队针对规范和流程落地做好基础服务，而事件管理的解决处置有专门的业务条线 IT 人员 根据管理团队的标准来做事件管理的相关工作。在该具体事件解决过程中遵循管 理规范和制定的准则来展开事件管理工作，不仅能更快的解决事件且能联动该条线上的资源对该事件进行处置，也能体现主人翁意识。在该事件管理过程中，承担该事件管理角色的应该是生产线上的运维人员，此类人员是 IT 服务提供的代表，且与用户粘合度高，对生产系统负责。事件管理作为 ITIL 标准中的一项， 生产运维作为事件管理角色中的一环必不可少。只有发挥这类生产运维人员的事件管理主动性才能把事件管理做好，而非出现问题全由统管模式中的事件规则制定者来对该业务系统发号施令，令该条线的研发和运维都茫然，且对该团队还需要 再次因该事件场景而去磨合，从而使该条线的运维人员闲置或是失去对生产问题的粘合度。

　　再者由于在事件管理中，该条线中的生产运维是清晰了解表象的，会在后续的问题管理流程中排查根因中发挥更积极的作用。整体来说，联动管理模式下，各条线中生产运维和研发伙伴才是真正做事件管理的正确人员，能充分调用资源和职责清晰的做好排障第一时间复生产。

　　最后由于此类 IT 服务是闭环效果的，从事件管理到问题排查，再到定位问题，转变更上线该问题是整体一套流程，此流程中 IT 服务提供者是一拨人，而非前后不一致的人员。针对事件复盘可邀请第三方主持，为公正起见（从发生到解决事件标准化团队并未真正的参与才是作为公正方参与的人选，而事件解决若采用统管模式来由该团队沟通解决的，那在复盘中该团队不能作为中立方-试想该团队都作为运动员上场参与踢球了，为何还能作为裁判来主持局面呢?）