ITIL 2011 -- 服务运营的5个流程简介 (上)

要做一个IT运维管理的项目，客户提到了ITIL（IT Infrastructure Library），所以谈需求之前我研究了一下ITIL，发现东西比较多，但是里面的服务运维部分是项目一期所需要的，那我就把我这部分的学习笔记贴一下。

ITSM，ITIL

有个术语叫做ITSM（IT Service Management）IT服务管理，简单的来说它就是指对企业IT系统的规划、研发、实施和运营的管理，我认为它就是一个概念。

而ITIL（IT Infrastructure Library）IT基础架构库，它就是适用于ITSM的一个框架，一套最佳实践。

ITIL®是英国AXELOS有限公司的注册商标。

我今天介绍的内容是基于ITIL 2011版本的。

ITIL分为5个阶段或叫生命周期：

1. 战略阶段（Service Strategy)；
2. 设计阶段（Service Design)；
3. 转换阶段（Service Transition)；
4. 运营阶段（Service Operation)；
5. 改进阶段（Service Improvement)；

看下图：

我要介绍的就是左下角服务运营（Service Operation）阶段的5个管理流程。而服务运营阶段的职能（Function），我在这里不介绍，因为我有的地方还不太清楚。

事件管理（Event Management）

作为IT服务的提供商，我们需要很好的理解和利用事件管理。

Event是有生命周期的，Event也需要在整个生命周期内被管理。这将是未来实现运维监控的基础。这是因为事件管理包括了所有诸如事件检测、事件分析、事件响应等等内容，这里所说的既包含普通的运维操作也包括警告和异常等，所以说它是自动化运维管理的基础。

在ITIL里事件（Event）指的是什么？

有时候可以这样认为：“所有的信息都很重要”。

简单的说呢，事件就是对IT服务管理或其它配置项管理很重要/有意义的那些状态的改变，就是一些状态的改变，例如升高或者下降等。

例如硬盘使用率从35%升到了45%。

基本上，事件就是IT运维人员需要做一些处理，或者至少记录（日志）一下的东西。

警报（Alert）

警报是由事件管理流程创建并管理的。

事件可能会产生警告，警报就是某个状态达到阈值后发出的通知。例如状态的改变，或服务发生了一些失败（Failure）。

例如，我在所有PC上部署了一个Windows启动时应自动运行的软件，部署后大部分的PC上都可以自动运行，但是有些PC上的软件无法自动运行。所以我让IT运维人员设置了警告，如果软件没有自动运行，这个警告就会被触发，同时也可以做一些应急处理工作。也可以给IT运维人员的电脑屏幕弹出警告信息。这些都属于事件管理的范围。

事件管理的目标

事件管理的目标都是很直接的：

• 检测所有对于配置项管理/IT服务有意义的状态的变化。
• 为事件决定具体的响应措施，并确定这些动作都和相应的职能组沟通过。
• 可以触发或提供切入点到其它运维管理流程。
• 提供比较实际效果和设计标准的比较方法。
• 为服务保障，报告和服务改进提供基础。

事件管理的范围

它支持任何需要被控制并可以自动化的服务管理，例如配置项、环境条件（例如烟火探测器）、软件许可的监控、入侵检测、服务器性能监测等等。

针对这里提到的监视（Monitoring），它的范围更广。而事件管理是被监控内容的一个子集，事件管理更关注于那些对提供服务和管理配置项有意义的事件。

事件的类型

从测试的角度来看，事件又分为三种类型，每一种类型对服务提供商又具有不同等级的重要性/意义：

• 信息性事件，就像趋势和分析等。例如xxx用户在周二使用了财务软件，电子邮件被阅读了，数据备份完毕等等类似的事件。
• 警告（Warning），就是早期的警告信息，它可以防止或最小化业务影响，或对用户的影响。例如服务器CPU的使用率距离阈值只有5%的距离了。
• 异常（Exception），意味着不好的事情已经发生了，并需要后续处理措施。例如CPU的使用率已经超过了阈值，DevOps在他们的电脑上安装了监控，所以他们可以进行后续处理。

警告和异常的区别？

这是服务商根据具体情况自己定的。

事故管理（Incident Management）

无论你在设计服务和支持服务中预先准备的有多好，但是我们毕竟是人，肯定会发生意外。

事故管理的目标

所以事故管理的目标就是：

• 修复服务的中断，尽快恢复服务运营
• 最小化对业务运营的不利影响

事故（Incident）的定义

事故（Incident）就是，IT服务计划外的中断，或IT服务质量的下降，或暂未对IT服务产生影响的失败配置项。

例如RAID里面一块损坏的硬盘，现在虽然可以正常运行，但是如果不把它换掉，那么未来总有一天会遇到麻烦。

事故管理的目标

• 确保使用了标准化的方法和过程，以保证效率。例如快速响应，报告，事故即时管理。
• 为业务和IT人员提高事故的透明度和沟通性。如果他们不知道事故，他们就无法进行响应。
• 通过使用专业方法来处理这些事故，将有助于增强企业对IT的业务认知。
• 将事件管理活动和优先事项与业务决策相结合，最终还是为业务选出最好的决策。
• 维护好IT服务的客户满意度。毕竟如果客户不高兴的话，那么就没有人会开心，即使服务的质量高于需求。

事故管理的范围

下面这些属于事故管理的范畴：

• 任何表明IT服务中断的事件（Event）。
• 任何可以造成IT服务中断的事件。例如之前提到的RAID中损坏的硬盘。

下面这些不属于事故管理的范畴：

• 信息新事件。例如，“数据库备份已完成，请呼叫服务台”，这完全没有必要。
• 服务请求。它是在请求完成管理和常规运维里处理的。
• 常规运维。就是计划内的服务。例如，已经预先通知客户周六晚8点至9点服务器停机维护等等。

如何处理事故

处理事故需要一个模型：这需要在处理事故前就设计好，就是一套预定义的步骤，这些步骤都是业务和IT人员同意的，它们可以用来处理特定类型的事故。

时间表

事故处理的步骤会涉及到谁来处理以及顺序问题。这就涉及到了时间表。

时间表可以表示特定事件应该发生的时间总量。

在事故管理里，时间表就表示了事故管理中每一个活动花费了多少时间来解决这个事故。

时间表需要遵循以下原则：

• 对于所有的事故处理阶段，我们必须共同协商同意所需的时间。
• 根据优先级和严重性的不同，时间也会不同。
• 必须是基于SLAs（我不知道这是什么东西）。
• 通常这些时间表应作为目标，支持每项服务的运营级别协议和基础合同，并确保内部和外部团队在同一面上。

事故的状态追踪

事故应该在全生命周期中被追踪。这有助于报告，事故升级，形成一个精确的精心安排的事件管理系统而不是杂乱无章的。

这个追踪的模型如下：

• 首先是打开（Open），在这里事故会被辨别，但是还未被分配到资源。
• 然后就是进行中（In Progress），事故处于被调查和解决的过程中。
• 然后是解决了（Resolved），提供了解决办法，但是还没有验证是否可以进行正常的服务运营，这需要到用户或业务那里调查满意度。
• 当用户满意了，这时就可以关闭（Close）了。这就说明用户或业务已经认同事故被解决了，并且NSO（不知道是啥）已经实现了。

重大事故 Major Incident

重大事故基本上时DEFCON 5，也就是所有事故分类里影响最大的那类。

实际上，因为重大事故太严重了，所以它经常会激活IT服务连续性计划。

重大事故会引起服务的长时间中断，通常也会造成经济上或用户满意度上的重大损失。

重大事故应该有单独的处理流程，和更短的时限。

重大事故还需要审查，以确保它被正确的处理。

事故管理的流程

每个企业和组织用于处理事故的管理流程肯定是不一样的，但是ITIL确实提供了一个比较标准的框架或者叫模板。

下面是这个“较为标准”的框架的流程图：

整个流程可能从事件管理、帮助网页、电话、或电子邮件等发起。

首先需要识别事故，识别的方法就有很多种了，也许通过打电话给服务台就能识别出来，也许需要事故管理。

在识别的时候，我们就需要判断这到底是不是事故。

如果确实是事故的话，那么就进入下一步“记录事故（logging）”。所有的事故必须被记录，包括日期时间等必须都有，这一点对问题管理和变更管理都很有用。

然后就是给事故分类，这将有助于过滤服务请求，并确保事故可以基于事故的原因正确地进行升级。例如，这是服务器环境事故还是网络环境的事故。此外，分类也有助于设置优先级。

下一步就是事故优先级的设定，优先级要综合考虑影响程度和紧急性。例如对业务的影响程度有多大，多久能够恢复等等。

这时，你就需要确定一下这个事故是不是一个重大事故了。如果是重大事故的话，就需要进入重大事故的处理流程了。

否则的话，就需要做一些事故诊断工作了。诊断脚本、事件模型和已知错误记录将在这个阶段对您有帮助。

如果你能识别出一个已知的错误记录，那么就有可能有一个解决办法可以让服务快速的恢复。

在初步诊断后，也就可以弄清楚服务台是否能把服务给恢复了。如果服务台没能在时间限内找到解决办法，那么可能就需要事故升级处理了。

这里有两种事故升级类型，一个是职能性升级，也就是把事故转交给拥有更高专业水平的某个技术团队。例如从1级技术转到3级技术等等。

还有一种是层次性升级，这时你的主管就会介入了。有人曾把这种事故叫做超过工资等级的事故，所以需要通知主管/老板，让他们授权支出。而有时则是让主管决定由哪些团队来处理这个事故，或激活IT SCM计划（不知道是什么），它也需要对事故进行层次升级。

大部分时候你会调查并得出一些事故的诊断。

如果发现处理办法了，那就来到下一步解决和恢复。在这可能需要一些测试，看看服务是否已经恢复到达成共识的程度了。

然后就可以返回到服务台来关闭事故。

服务台会给用户打电话，并且询问客户，“这个解决办法是否能够让您满意?” 一旦得到了肯定的回答，那么这个事故的处理流程就结束了。