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卡等物理设备授权人员进入某些房间或会见某些数据都属于会见治理的领域不在规模内：决议谁有或没有权限。

这点应该是在信息宁静治理决议的。会见治理仅仅是允许会见。

确保数据或服务的可用性。这一点是可用性治理的专有角色。

会见治理的CIAC：Confidentiality 保密性I：Integrity 完整性A：Availability 可用性 保密性原则要求数据和系统只能被授权的人员会见。没授权的人应该不能看也不能触遇到。

完整性指数据和设置项只能被授权人员修改。可用性是个宁静相关的内容，它是一种可以让IT服务或设置项在需要时可以执行其约定职能的能力。例如密码丢失后，不能重置，也不能找回，那么这从宁静角度来讲就是影响了服务的可用性。

总 结事件治理是许多其他流程的输入，也是自动化的基础。事故治理是处置惩罚我们提供的服务的中断或降级情况的。

就是灭火。问题治理，并不是事故治理的另一种形式，它的作用是寻找事故的基础原因。

如果说事故治理是灭火，那么问题治理就是火后进去的纵火观察员等人，他们会寻找火灾发生的原因。请求服务推行处置惩罚所有的服务请求。

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

本文来源：hth华体会最新网站-www.sz-hongqi.com