要做一个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计划（不知道是什么），它也需要对事故进行层次升级。

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

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

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

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

问题管理

对于某些问题，最好还是介入到问题管理流程，调查和解决事件的根本原因。

注意事故不会变成问题，问题是事故的底根本原因。

问题管理的目标

问题管理的目标就是找到事故的原因，删除或减少它的影响。所以我们需要：

• 管理所有问题的生命周期，从识别到去除。
• 理解并记录所有已知的错误/问题。
• 响应性最小化不利影响。
• 主动的防止类似事故的发生。

问题的定义

问题就是事故的根本原因。这个原因在问题记录被创建的时候通常是不被知道的。问题管理也要为以后寻找根本原因的调查负责。

问题管理的目标

• 防止问题发生，防止问题导致事故的发生。这是主动性的一面。
• 避免重复事故的发生。通过找到根本原因，并移除它就可以做到这点。
• 降低那种无法阻止发生事件的影响程度，提供变通的解决方案。这是体现更响应性的一面。

问题管理的范围

问题管理处于ITIL的服务运营和持续服务改进的阶段。它非常注重主动性，也是非常建议的；但是响应性也是非常必要的。

主动性和响应性以不同的方式被触发。

主动性：

• 主动性是基于改进的，我们在事故再次发生之前识别、解决和了解问题。
• 它是在现有的基础上实行的，而不是我们所做的单次的事情。我们是持续的来做这件事的。
• 在这里进行重大事故的审查
• 还需要关注运营日志，看看某些趋势是否会发生。
• 有时候可以和服务/配置项的相关人员做一些头脑风暴，获取一些想法，发现一些趋势。

响应性：

• 对于响应性来说，我们主要是解决引起事故的问题。
• 响应重复异常事件时就被触发了

问题管理的术语

• Workaround，变通方法/临时解决办法。它是当你还没找到完整的解决方案之前，一种减小/消除事故/问题影响的临时方法。
• 这些变通方法也会被记录，它们叫做已知错误记录或已知错误Known Errors。已知错误是那些记录了根本原因的问题并附带临时解决方案（Workaround）。
• 所以已知错误是被问题管理流程创建和管理的。它们被存放在KEDB（Known Errors Database）已知错误数据库里。记录里需要体现相关问题及其当前状态，以及根本原因的相关信息以及变通方法（Workaround）。注意并没有规定何时已知错误被记录，实际上已知错误可以在任何必要的时间被建立，即时问题的变通方法还不完整或根本原因没被完全理解的时候也可以建立已知错误记录。

问题管理流程

和事故管理一样，问题管理也有它的流程。虽然各个公司的流程肯定不同，但是它们通常是这样的：

首先是识别问题，有很多来源。

然后是问题的记录（logging）。

然后是分类，这个分类要和事故管理的分类一致。因为事故管理的处理人员需要和相关问题以及已知错误相匹配。

同样，也需要设定优先级。这里也有可能会做一些升级。

然后使用适当的分析技术和过程来帮助诊断问题。例如鱼骨图就很不错。

同样也可以咨询CMS来确认问题的影响程度，并隔离潜在原因。

我们将识别并提出解决方案。

然后把这个已知错误存到KEDB里。

一旦找到问题的解决方案，我们就开始实施这个解决方案。有时需要修改某个配置项，这就意味之你把变更管理给拉进来了。你创建一个RFC，一旦核准后，你就需要应用解决方案。

一旦为题解决了，就需要更新相关的记录，并关闭该问题。如果有相关的已知错误存在，那么你就需要更新它的信息。

如果有重大的问题，那么还需要做重大问题审查。例如，“什么地方做错了，什么地方做的正确，以后如何改进；是否有供应商介入，我们是如何跟进的”等等。

最后一点不要忘记：事故管理和问题管理是不一样的，但是它们是关联的。事故是症状，问题是原因。

服务请求履行（Request Fulfilment）

作为一个流程，服务请求履行是一组通用的活动，这些活动用来处理来自用户的服务请求。

所以，服务请求履行就是对来自用户的请求的全生命周期的管理。

服务请求履行的目标

它的目标就是我们如何来处理请求。

• 首先我们需要维护用户和客户的满意度。
• 处理请求要很高效。简单、方便。
• 为用户提供提出请求的通道。例如网站、电子邮件、文本、电话等等。
• 为用户提供信息。
• 来源并提供资源和组件。例如某人需要新的鼠标或显示器，我们就需要跟踪这个东西，然后交付它。再例如某个项目额外需要一个程序员，我们就应该与HR协作，“交付”一个程序员。
• 协助投诉、评论和赞美。应采取正式的政策制定如何响应投诉、评论和赞美并追踪下去。但是要记住这个正式的政策应该是在BRM（Business Relationship Management）里决定的，它属于Service Strategy（服务策略）的范畴。

与服务请求（service request）的不同

• 用户客户等的日常请求。服务请求是用户对信息或者建议的请求，他们会请求一些东西，都是一些标准变化。例如重置密码，某个服务的访问权。基本上就是用户、客户等的日常需求也可以在事故管理里处理.
• 但是需要其作为事故的一种特殊分类。
• 通常还是单独的处理流程
• 整个企业范围
• 提供独立于事故的记录类型，用于不同的流程和报告。

最后别忘了需要描述出事故、服务请求和变更请求的区别。

访问管理

我们有很多服务，我们需要确保需要使用服务的人拥有访问服务的权限，而无关人员应不具备访问权限。

访问管理的目标和目的

• 为用户提供权限，让其可以访问某个服务
• 执行信息安全策略。而这个信息安全策略信息安全管理流程里创建的，信息安全管理流程属于服务设计的范畴。
• 从这个策略里，你将会基于其内容管理服务的访问权。
• 这意味着你需要对授权访问服务、访问权变更、或限制访问等请求进行官方的回复。例如Windows里的Active Directory。
• 一旦你授予了访问权，你就需要监视对服务的访问，确保权限被正确的提供，并且没有被滥用。

访问管理的范围

范围内：

• 保护数据和知识产权的机密性，完整性和可用性。
• 确保授权用户被授予了访问服务的正确权限。
• 通常可以跨职能执行，但是最好是有单点接触或协调。通常是服务台或IT运营的职能。
• 包括使用RFID卡等物理设备授权人员进入某些房间或访问某些数据都属于访问管理的范畴

不在范围内：

• 决定谁有或没有权限。这点应该是在信息安全管理决定的。访问管理仅仅是允许访问。
• 确保数据或服务的可用性。这一点是可用性管理的专有角色。

访问管理的CIA

C：Confidentiality 保密性

I：Integrity 完整性

A：Availability 可用性

保密性这个原则要求数据和系统只能被授权的人员访问。没授权的人应该不能看也不能触碰到。

完整性是指数据和配置项只能被授权的人员修改。

可用性是个安全相关的内容，它是一种可以让IT服务或配置项在需要时可以执行其约定职能的能力。例如密码丢失后，不能重置，也不能找回，那么这从安全角度来讲就是影响了服务的可用性。

综上

事件管理是很多其他流程的输入，也是自动化的基础。

事故管理是处理我们提供的服务的中断或降级情况的。就是灭火。

问题管理，并不是事故管理的另一种形式，它的作用是寻找事故的根本原因。如果说事故管理是灭火的话，那么问题管理就是火后进去的纵火调查员等人，他们会寻找火灾发生的原因。

请求服务履行处理所有的服务请求。

访问管理就是确保适当的人拥有访问相关服务的权限，其余无关人员没有这些权限。

本文来自阿里云云栖社区，未经许可禁止转载。

​更多资讯，尽在云栖科技快讯~

来科技快讯看新闻鸭~

快点关注我认识我爱上我啊~~~