事件管理

    所谓事件是指可能会导致服务中断或服务质量下降的，不属于标准服务的事件。事件不仅包括了与软件和硬件有关的错误，还包括服务请求。

    事件管理不是找到引起系统异常的根本原因，而是尽快恢复系统业务功能，找到异常根本原因是问题管理流程的目的。

    事件管理的主要任务是及时识别并跟踪发生的事件；对事件进行分类并提供初步支持；对事件进行调查分析，识别引发事件的潜在原因；解决事件并恢复服务；跟踪和监督所有事件的解决过程，并随时进行沟通。因此，研究事件管理对解决目前IT运维中存在的服务问题具有重要的意义，事件管理的时效性将直接影响整个企业的IT服务质量和整体运营状况。

事件管理的关键点包括：

1、事件记录

事件管理记录详细的事件信息，如事件发生的时间、受事件影响的服务等。这样做的目的是便于确认事件的影响，问题管理可以根据这些信息查找事件原因，密切跟踪事件进展。通过系统监测工具在事件数据库中自动生成基本事件记录是理想的解决方案。相关配置项的表征、基本诊断数据以及信息，在诊断以及记录阶段都应该包括在事件记录中。

在大多数情况下，事件会由服务台进行记录，所有的事件都应该被迅速记录下来。要避免对同一事件进行重复记录的情况出现。因此在记录某一事件时，需要进行一项检查来确定是否已有相似的记录。

2、事件分类

事件分类的目的是为了确定事件的来源以便采取相应行动，尽可能快地恢复用户的正常工作，尽量避免或者减少事件IT服务质量的影响。一般来说，许多事件是重复出现的，因此，当某个事件再次出现时，只需要根据已有的经验和措施采取行动即可。当新的事件出现时，就有一个与其问题和知名错误（知识库）相匹配的过程，如果匹配成功就可直接用已有的方案将其解决，而不需要进一步调查，否则就要继续进行下面提到的其他几个步骤。

ITIL中通常都将事件采取三级分类机制：分类、子分类及项目。可以根据所报告的事件的故障情况，对事件进行分类（为事件指派类型）。根据事件的类型、状态、影响度、紧急度、优先级、SLA等来对其进行编码，由此向用户提供建议来解决或处理问题，哪怕这些建议仅仅是临时性的。

3、事件状态定义

事件状态反映了其在整个生命周期中的当前状态，有时候指其在事件工作流中的位置。任何人都应该意识到每个事件的状态以及它所代表的含义。通常情况下，事件状态的例子有：新建；已接收；已计划；已分配/已指派给专业人员；激活状态；已暂停；已解决；已终止。

4、事件级别定义

在确定事件的类别后，需要确定事件的优先级，以确保支持小组对问题予以足够的关注。决定事件级别的要素主要有三个，分别是影响度（Impact）、紧急度（Urgency）和处理优先级（Priority）。影响度是指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度；紧急度是在解决故障时，对用户或业务来说可接受的耽搁时间；优先级是根据影响度和紧急度决定了处理事件和问题的先后顺序，优先级通常用一个数字来表示，优先级=紧急度×影响度。

5、事件诊断处理

经过事件的查明和记录，对事件进行初步诊断后通过技术或管理手段快速恢复。事件管理的目标首先是快速解决问题，恢复业务的正常运作，而不是寻找问题的根本原因。对于未出现过的事件，一线人员无法解决，则尽快启动事件升级，目标依然是快速恢复系统和服务。过程中往往会采用变通的解决方案（Workaround）。对于事件发生的原因暂时无法找到，该事件需要升级为问题管理，通过问题管理的方式追踪问题发生的根本原因（Root Cause）直至问题被彻底解决，不再重复发生，这部分属于问题管理范畴。

6、事件升级机制

对于事件不能在规定的时间内由一线支持小组解决，那么更多的有经验的人员和有更高权限的人员将不得不参与进来，这就是升级。它可能发生在事件解决过程的任何时间和任何支持级别。升级分为职能升级和管理升级。

（1）职能升级：需要具有更多时间、专业技能或接入特权（技术机构）的人员来参与事件的解决。这种升级可能会超越部门界限而且可能会包括外部支持者。

（2）管理升级：当经授权的当前级别的机构不足以保证事件能及时、满意的得到解决时，需要更高级别的机构参与进来。

7、事件关闭

事件解决和恢复服务后，事件到达关闭阶段，这个阶段要跟用户确认事件解决是否成功。在事件解决后，要确保所有的事件信息都得到了更新并准确被记录；同时根据事件产生的根本原因对事件的分类进行调整；对于根本原因未找到的事件确认是否已经转入问题管理。在用户同意事件解决方案和方案执行的最终结果的基础上，该事件可以被关闭。

事件管理关键点的具体实例如下：

1、数据中心事件的分类

数据中心运维过程中发生的事件种类繁多，我们主要根据故障种类以及事件定级方法，对数据中心事件进行分类。从故障角度划分的事件包括：供配电系统事件、制冷系统事件、物理环境事件、物理安全事件、监控系统、网络故障、IT系统故障、自然灾害等；结合事件定级因素，将事件分为一级、二级、三级和四级等不同的等级。有的企业会划分为三级，有的企业会划分为五级。表1是事件分类的一个具体实例。可以参考下面的分类实例，根据自己的情况进行事件分类的定义和等级划分。在实际事件分类中，没有统一的强制标准，是由具体的业务和管理要求决定的。可以根据定级的标准，去枚举所属数据中心的具体分级事件的例子。 

表1 数据中心事件定级分类实例

一级事件举例：用户可以根据自身数据中心的情况，定义具体的事件场景，便于判断。

（1）供电系统：整套供电系统瘫痪（双路市电供电中断、UPS供电中断及发电机无法正常启动），导致电力中断。

（2）制冷系统：多台精密空调服务中断，导致温度、湿度超出SLA承诺阈值。

（3）物理环境：大面积的渗水漏水，导致客户机房出现严重安全隐患。

（4）物理安全：出现恐怖袭击或者有针对性的破坏而导致客户服务中断。

（5）自然灾害：数据中心无法提供保障数据中心正常运营能力的物理指标、地震、洪水、台风、战争等。

2、数据中心事件的升级

数据中心事件可以根据处理的不同情况，在不同的运维团队间进行升级，表2是数据中心事件升级定义的一个实例，读者可以参考下面的升级实例，根据自己的情况进行升级的定义和划分，在实际事件升级中，没有统一的强制标准，是由具体的业务和管理要求决定的。

表2 数据中心事件升级定义实例

对于超越一级事件的重大影响事件，如对客户业务产生重大影响，严重影响合约的履行，有重大法律和商务风险的事件，建议高级管理层的参与，公关媒体的参与，与客户一起做危机处理。

3、数据中心事件的记录

数据中心事件的各种相关信息都要被及时记录下来，一般都应该记录在后台系统里面，并且以工单的形式在各处理环节中进行传递。数据中心事件记录包括很多相关信息，表3是数据中心事件记录的一个实例，读者可以参考下面的事件记录实例根据自己的情况进行事件记录信息的定义和划分，在实际事件记录中，没有统一的强制标准，是由具体的业务和管理要求决定的。

表3 数据中心事件记录定义实例

四、数据中心问题管理（Problem Management)

    问题管理的目标是找出突发事件产生的根本原因，最小化由于IT基础架构错误引起的突发事件和问题的负面影响，防止与错误相关的突发事件的再次发生。通过实施主动问题管理，在事件发生之前发现问题并解决，从而减少事件发生的数量。

    问题是导致一个或多个事件的根本原因，而这些根本原因还没有诊断出来。事件管理强调在给用户和公司的正常业务活动带来最小影响的情况下，尽快恢复到SLA中定义的正常服务级别。采取任何可能的方法，包括一个临时解决方案（应急措施）来快速地解决事件，尽可能确保最好的服务质量和可用性。与事件管理强调速度不同，问题管理则注重诊断事件的根源，确定问题的根本原因，从而制定恰当的解决方案，从根本上解决问题，防止类似事件的再次发生。事件管理为了尽可能快地恢复服务，往往会采用临时解决方案，问题管理比起事件管理则会花费更长的时间。

问题管理的关键点包括：

    (1)问题的识别和记录。原则上，任何一个由未知原因引起的事件都与某个问题有关。问题的识别通常会发生在以下情况：在事件管理流程中没有问题或已知错误来匹配事件；通过分析发现该事件又再次发生了，或者发生了重大事件；事件不能与现有问题或已知错误相匹配；通过对IT基础设施的分析识别出导致事件的问题。

    问题记录和事件记录一样都被记录在配置管理数据库（Configuration Management Database,CMDB)中，问题记录会跟所有有关联的事件记录关联在一起。事件的解决方案以及临时解决方案的细节都应该被记录在问题记录中而不是事件记录中，以便它们可以用于将来有关联的事件中。

    (2)问题的诊断和处理。通过问题诊断成功获取问题的根本原因并找到解决途径后，该问题将转变为一个已知错误。问题调查除了与事件调查的目标不同外，其流程类似。事件调查的主要目的是为了恢复服务的正常运作，而问题管理则是为了确定问题的根源。

    在事件调查期间所采用的任何应急措施，都应该在问题调查阶段考虑，如果有必要的话，在问题记录中还要更新与已知错误、解决方案和应急措施相关的信息。

    一旦诊断出配置项中的故障，那么该问题状态被转变为已知错误，然后开始进行错误控制。当一个问题被诊断为一个程序错误而不是配置项故障时，记录应该被更新为正确的代码然后关闭该问题，通常这样的问题不会转化成已知错误。

  (3)问题的关闭。在满足问题关闭规则指定的条件之后，关闭问题，同时可将关联的所有事件一同关闭。

问题管理关键点的具体实例如下：

    (1)数据中心问题的定级。根据问题引发事件的程度，将问题定级为高风险问题和普通级问题；高风险问题是指问题不被解决，再度引发事件的可能性很大；普通级问题指问题不被解决，暂时不会引发事件。读者可以根据自己的情况进行问题定级的划分，在实际问题定级中，没有统一的强制标准，而是由具体的业务和管理要求决定。

    (2)数据中心问题的分类。数据中心问题分类有多种方式，可以按照问题所处的区域和类别来进行分类。下面是一个可以参考的问题分类方式：

    1)从业务角度分类。与事件分类相似，可参考数据中心事件分类。

    2)从管理或治理角度分类。可以根据不同企业的管理目标来分，如流程问     题、工具问题人员问题、供应商的问题及技术架构问题。

    3)管理角度还可以再细分。如人员问题中可以细分为人员执行力问题、人员技能问题、人员责任心问题及职责不清问题等。

      问题的分类不是固定的，而是在问题的生命周期内可能发生变化的，问题管理的核心就是将问题多维度、多视角深度剖析，找出管理上、架构上的“短板”，从根本上去解决，这样才可以使得问题管理真正在IT管理或数据中心管理中发挥作用。在数据中心的管理中，问题管理通常因为没有事件管理、变更管理那么直接影响服务的可用性而被忽视，使得遗留下来的问题没有被及时解决，也会导致事件的重复发生，从而降低系统和服务的整体可用性。

      为了更有效推进问题管理，建议：第一，形式很重要，可以将问题按照月度或者季度来跟踪和回顾，而不是作为每天的流程性工作；第二，问题经理人的选择非常重要，通常问题经理是具有丰富经验和行政级别的经理，才能调度资源和有迫切感来解决问题。如果是流程经理兼职问题经理，问题管理推行的难度和阻力将会很大。

五、数据中心变更管理(ChangeManagement)

数据中心的变更管理，是为在最短的中断时间内完成基础架构的任一方面的变更，而对其进行控制的服务管理过程。这里所指的变更，,是指在维护过程中对系统或服务所做的各种改变。包括增补、移除和其他修改。

变更管理的目的，是确保以受控的方式去评估、批准、实施和评审所有变更，确保标准方法和过程可以得到使用。阻止未授权的变更发生，使得变更风险可以降至最低，同时将变更相关突发事件的影响减到最小，并且确保所有变更都必须可跟踪和可追溯。

  变更管理的关键点包括：

  (1)变更请求(Request for Change, RFC)，变更发起的主要原因有解决事件、预防问题、升级部署、主动性改善以及业务需求。

  变更请求是指对一个或多个特定设备或系统实施变更的正式请求，说明了变更的内容及与变更有关的配置项。变更请求只是为了请求对基础架构进行变更的机制，它必须包括变更所需要的必要信息以便评审、批准和创建。由于并不是每一个修改请求都像变更一样处理，也致使变更可以分为标准变更和非标准变更两种。

变更请求包含的内容有：

①变更请求标识码和日期；

②变更请求的状态；

③变更项的描述，包括版本号；

④变更原因；

⑤提出变更请求的人员信息；

⑥变更优先级，影响以及成本,评估；

⑦风险评估和管理细节；

⑧变更顾问委员会(Change Advisory Board, CAB)的建议；

⑨变更授权人的签名，日期和时间；

⑩实施计划，用于详细说明如何变更；

⑪恢复计划,(Back-out planning),一旦变更管理的执行计划没有效果，就需要恢复计划来稳定企业的运作，减少经营风险。

(2)变更顾问委员会。变更委员会定期会合，对较大以上变更进行评估审核，并拟定相应计划，变更委员会应当从业务和技术两个角度充分评估变更的影响，变更委员会不能批准变更请求，只是给出相关意见。其成员是灵活的，这取决于变更请求，可以包括任何从商业和技术角度来看都能确保变更被充分评估的人员，可以包括:变更经理(主席和常任成员)、技术专家/顾问、客户经理和用户组代表、开发人员和供应商。

(3)变更种类。变更通常按照两种方式进行分类:一种是基于变更类型进行分类，该分类的方式类似于事件分类，用于区分变更的类型；另一种是基于变更的影响程度，来定义变更的级别，用以确认变更的审核矩阵。如重大变更、较大变更、一般变更和标准变更。根据变更的紧急程度，又分为计划性变更和紧急变更。

(4)变更审批。不同的变更有不同的审批流程和审核矩阵。对于重大的变更，需要CAB来审核。其中除了技术风险评估，还会涉及到财务和业务的评估。对于较大变更，可以是变更经理和变更相关部门负责人来审核确定。对于一般变更或者标准变更，则可以根据预先定义好的相关流程进行备案即可。变更的定级和授权对于变更是否可以在企业里被很好地执行非常相关。如果太多的变更需要走复杂的审批流程，管理成本大，流程效率低下，也会使得变更发起者不愿意走变更流程，导致变更风险无法被有效管控。

上述重大变更，可能需要经历三个部门的审批流程:

1)财务审批。确保变更成本在预算范围内，或者满足变更管理所设定的成本/优势需求。

2)技术审批。保证变更的可行性、合理性，变更的实现不会对IT服务产生过多的负面影响。

3)业务审批。确保业务经理同意建议的变更，同时变更对业务产生的影响能令他们]满意。

变更管理关键点的具体实例如下:

(1)数据中心变更的定级。根据变更风险,的高低，数据中心的典型变更级别分为重大变更、较大变更、一般变更及标准变更四个级别。变更定级方法见下表。用户可以根据自己的情况进行变更的定级划分，在实际变更定级中，没有统一的强制标准，而是由具体的业务和管理要求决定。

数据中心变更定级表

具体事例

(2)数据中心变更的分类。根据所要变更的基础架构的特点，数据中心变更可以分为物理环境类变更、基础设施类变更、IT设备类变更、施工类变更、IT系统类变更、网络线路类变更以及资产类变更几类。为了在实施中把中断业务或服务的时间减少到最小，要对变更请求进行审批，确定变更的优先级，再进行变更操作。不同类别的变更参照变更定级标准进行定级。读者可以根据自己的情况进行变更分类的划分，在实际变更分类中，没有统一的强制标准，而是由具体的业务和管理要求决定。

(3)数据中心变更审核要点。为了减少盲目的、随意的变更，数据中心的变更除了需要制定详尽的变更计划外，还要从多方面进行审核。数据中心变更的主要审核点包括：

①变更计划；

②变更风险；

③变更回退预案；

④变更窗口；

⑤变更前导时间；

⑥变更通知策略；

⑦变更影响；

⑧变更成功的标准；

⑨变更成本；

⑩变更投入产出。