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个阶段或叫生命周期：
战略阶段（Service Strategy)；
设计阶段（Service Design)；
转换阶段（Service Transition)；
运营阶段（Service Operation)；
改进阶段（Service Improvement)。
看下图：
以下所要介绍的就是左下角服务运营（Service Operation）阶段的5个管理流程。
事件管理
（Event Management）
作为IT服务的提供商，我们需要很好的理解和利用事件管理。
Event是有生命周期的，Event也需要在整个生命周期内被管理。这将是未来实现运维监控的基础。这是因为事件管理包括了所有诸如事件检测、事件分析、事件响应等等内容，这里所说的既包含普通的运维操作也包括警告和异常等，所以说它是自动化运维管理的基础。
在ITIL里事件（Event）指的是什么？
我们可以这样认为：“所有的信息都很重要”。
简单的说呢，事件就是对IT服务管理或其它配置项管理很重要/有意义的那些状态的改变，就是一些状态的改变，例如升高或者下降等。
例如硬盘使用率从35%升到了45%。
基本上，事件就是IT运维人员需要做一些处理，或者至少记录（日志）一下的东西。
警报（Alert）
警报是由事件管理流程创建并管理的。
事件可能会产生警告，警报就是某个状态达到阈值后发出的通知。例如状态的改变，或服务发生了一些失败（Failure）。
事件管理的目标
事件管理的目标都是很直接的：
检测所有对于配置项管理/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）
作为一个流程，服务请求履行是一组通用的活动，这些活动用来处理来自用户的服务请求。
所以，服务请求履行就是对来自用户的请求的全生命周期的管理。
服务请求履行的目标
它的目标就是我们如何来处理请求。
1、首先我们需维护用户和客户的满意度。
2、处理请求要很高效。简单、方便。
3、为用户提供提出请求的通道。例如网站、电子邮件、文本、电话等等。
4、为用户提供信息。
5、来源并提供资源和组件。例如某人需要新的鼠标或显示器，我们就需要跟踪这个东西，然后交付它。再例如某个项目额外需要一个程序员，我们就应该与HR协作，“交付”一个程序员。
6、协助投诉、评论和赞美。应采取正式的政策制定如何响应投诉、评论和赞美并追踪下去。但是要记住这个正式的政策应该是在BRM（Business Relationship Management）里决定的，它属于Service Strategy（服务策略）的范畴。
与服务请求（service request）的不同
用户客户等的日常请求。服务请求是用户对信息或者建议的请求，他们会请求一些东西，都是一些标准变化。例如重置密码，某个服务的访问权。
基本上就是用户、客户等的日常需求也可以在事故管理里处理.
但是需要其作为事故的一种特殊分类。
通常还是单独的处理流程
整个企业范围
提供独立于事故的记录类型，用于不同的流程和报告。
最后别忘了需要描述出事故、服务请求和变更请求的区别。
访问管理
我们有很多服务，我们需要确保需要使用服务的人拥有访问服务的权限，而无关人员应不具备访问权限。
访问管理的目标和目的
为用户提供权限，让其可以访问某个服务
执行信息安全策略。而这个信息安全策略信息安全管理流程里创建的，信息安全管理流程属于服务设计的范畴。
从这个策略里，你将会基于其内容管理服务的访问权。
这意味着你需要对授权访问服务、访问权变更、或限制访问等请求进行官方的回复。例如Windows里的Active Directory。
一旦授予访问权，就需要监视对服务的访问，确保权限被正确的提供，并且没有被滥用。
访问管理的范围
范围内：
保护数据和知识产权的机密性，完整性以及可用性。
确保授权用户被授予了访问服务的正确权限。
通常可以跨职能执行，但是最好是有单点接触或协调。通常是服务台或IT运营的职能。
包括使用RFID卡等物理设备授权人员进入某些房间或访问某些数据都属于访问管理的范畴
不在范围内：
决定谁有或没有权限。这点应该是在信息安全管理决定的。访问管理仅仅是允许访问。
确保数据或服务的可用性。这一点是可用性管理的专有角色。
访问管理的CIA
C：Confidentiality 保密性
I：Integrity 完整性
A：Availability 可用性
保密性原则要求数据和系统只能被授权的人员访问。没授权的人应该不能看也不能触碰到。
完整性指数据和配置项只能被授权人员修改。
可用性是个安全相关的内容，它是一种可以让IT服务或配置项在需要时可以执行其约定职能的能力。例如密码丢失后，不能重置，也不能找回，那么这从安全角度来讲就是影响了服务的可用性。
总 结
事件管理是很多其他流程的输入，也是自动化的基础。
事故管理是处理我们提供的服务的中断或降级情况的。就是灭火。
问题管理，并不是事故管理的另一种形式，它的作用是寻找事故的根本原因。如果说事故管理是灭火，那么问题管理就是火后进去的纵火调查员等人，他们会寻找火灾发生的原因。
请求服务履行处理所有的服务请求。
访问管理就是确保适当的人拥有访问相关服务的权限，其余无关人员没有这些权限
ITIL 2011 -- 服务运营的5个流程简介 (上)相关推荐
- ITIL运维服务管理的26个流程的密切关系说明
ITIL的核心包括4个职能.26个流程,具体如下. 4个职能:服务台.运营管理.应用管理.技术管理: 26个流程:战略管理.需求管理.服务组合管理.变更评估.设计协作管理.服务验证与测试.转换规划与支 ...
- ITIL的服务目录管理流程的关键知识
ITIL的服务目录管理内容并不多,但不容易理解.总体上而言是分业务服务目录.技术服务目录两个层次,其中技术服务目录又是为业务服务目录提供支撑.支持服务. 在设计自己的服务目录时,重点是先定义出服务,分 ...
- [ITIL] IT服务管理经典语录---刘亿舟
#亿舟语录#之 1: 信息化在给我们带来巨大的生产力提升的同时,也把我们引入到一个"唯技术论"的误区,即凡是遇到问题,首先想到的是如何从技术上加以解决.IT服务管理的 引入,开始逐 ...
- ITIL V3 服务转换篇 之 服务转换阶段的组织形式
一.服务转换的目标是 1.设定客户在使用新的或变更服务时的期望: 2.驱动业务变更项目或客户整合发布到业务流程和服务中: 3.减少估计中的变化,以及转换服务的实际绩效: 4. 减少已知错误和在将新的或 ...
- 软件测试外包到蚂蚁金服,2019蚂蚁金服面试经验(服务运营岗,测试开发工程师等)...
为了帮助职业圈网友能够及时了解蚂蚁金服的面试流程以及面试过程所涉及的面试问题,职业圈小编把2019最新蚂蚁金服面试经验编辑好,马上提供给大家,以便能够尽快帮助到有需要的人.文章中还为你提供蚂蚁金服面试 ...
- 乐视TV呼叫中心总监李霜：生态时代的服务运营之道
听闻乐视手机是两三个月前的事 儿,有天单位负责网管的同事很高兴地 说他新买了个手机,是乐视的.我一 向信赖他的专业度,就打听了一下这 款"跨界产品".他12345地介绍起来,从乐视 ...
- 首席新媒体黎想教程：可复用的社群运营，加直播流程！
2020年许多企业都被迫转型线上,甚至一直坚持只做传统线下的一些公司都为了能寻找新的机遇.不被时代所淘汰,开始接触线上,试图从线上开辟一条新的商业模式. 我们常规所说的一些线上平台,大致可以分为:网站 ...
- 运营活动系统的流程总结
运营活动系统的流程总结 下图是整个消息驱动的消费流程 Created with Raphaël 2.1.0开始从队列接收消息过滤消息按事件类型找出所有在线活动用消息遍历活动 下图是对每一条消息的处理流 ...
- 华为为什么计算机停止运行,华为云电脑干嘛用的-为什么停止服务运营-乖乖手游网...
就在刚才华为云电脑宣布将于8月15日正式停止服务运营,乍看到这个消息的时候可能许多网友们感到疑惑为什么华为要关停云电脑呢?此外华为云电脑是干什么用的呢?下面一起来看看吧! 华为云电脑为什么停止服务运营 ...
- 2、流程部署-上传到服务数据库,查看当前正在执行任务
流程部署-上传到服务数据库,正在执行任务 1.部署单个BPMN文件到服务 2.1次部署多个BPMN文件 3.流程定义信息查询 4.查询流程下正在跑的任务 5.删除流程部署信息 6.流程资源下载 1.部 ...
最新文章
- ngx_lua中的协程调度(三)
- oracle书写高质量sql,干货！SQL性能优化，书写高质量SQL语句
- Linux内核模块（二）
- Java数组的十大方法
- Python协程--迭代器
- ioc spring 上机案例_抛开Spring去理解IOC思想 - 原来IOC容器这么简单
- 用matlab绘制P三曲线,知道曲线方程 怎么用matlab绘制三维图 一定要给出程序 , matlab怎样画三维曲线...
- Windows程序设计--起步
- 平面变压器的设计（翻译）（1）
- Android知识体系导图
- 如何在html中插入乘积函数,excel乘法怎么保留两位小数
- Python-Excel报表自动化生成报表(二)
- win7命令设置自动关机
- XP系统计算机桌面图标不见,xp系统桌面计算机快捷图标不见了的设置方法
- Kubernetes Downward API 基本用法
- canvas绘图有锯齿毛边问题的解决
- CV项目肢体动作识别（三）内附完整代码和详细讲解
- 平板电脑 android系统升级,戴尔平板电脑Streak 10 Pro升级至安卓3.2 官方教程
- 什么是IO流？什么是IO流？
- 从VB来看-InsertionSort（VB插入排序）