【小编精选】ITIL流程总结
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
ITIL将工作分为两大类：Service Support和Service Delivery。Service Support针对的是一般系统的运作部分；Service Delivery是针对IT部门对客户提供信息服务时应有的工作程序。
Service Support：
终端用户提出事件的开始，其中可能有些是问题，则进入问题管理程序，如果找出原因以及解决步骤，则提出RFC进入变更管理程序，然后对修改的配置项进行分布。从事件，问题，RFC、变更管理到分布管理都是由CMDB串连起来的。
1． 事故管理
事故管理负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到服务级别协议所定义的服务级别。
2． 问题管理
当我们的事件在第一时间没得到及时解决，就进入问题管理程序。
问题管理的重要性：通常80%的服务品质下降都是因为20%的问题，所以专注与20%的问题解决可以大大的提升服务。
问题管理的目标：将 IT 基础设施内的错误引起的事故和问题对业务的负面影响减到最小，并防止与这些错误相关的事故再度发生。为了实现这个目标，“故障管理”力求找到引发事故的根源，然后才着手改善或纠正该情况。
问题管理流程具有被动和主动两个方面：
被动方面是作为对一个或多个事故的反应而解决问题。问题分析方法：
[*]定义问题；
[*]按个体、地点、时间以及范围大小描述问题；
[*]建立可能的原因；
[*]测试最有可能发生的原因；
[*]验证真正的原因。
主动“故障管理”是指通过趋势分析和定期的事件统计表，在事故发生前确定并解决问题和已知错误。
3． 变更管理：
变更管理流程的目标：确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响减到最小或将事件数减少，并因此改进公司的日常运作。
最常见的是终端用户提出的请求，其中有些是系统改进或增加功能的请求，有些是常规变更（如帮新进人员建立新的帐号），有的可能是系统出错，这在IT 中通常称为事件，如果是系统出错就要找出原因和解决步骤，才能进入到变更管理的第一步：RFC提出变更请求，变更请求应该包括（RFC编号、问题编号、那些配置项需要改变、变更的理由、如果不变更会造成的影响、变更人的联系方式）；变更管理员负责监督变更从提出到解决的整个过程记录进CMDB、对变更请求进行过滤；同时提交变更到公司指定的变更管理委员会批准。变更管理需要有准确的CMDB配置管理数据库，对变更进行分析。
4． 发布管理
发布管理是指对经过测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程。发布管理以前又称为软件控制与分发，它由变更管理流程控制。
5． 配置管理
在上边的变更管理中，我们提到当一个RFC进入变更程序的时，管理员和CAB需要有一个方法评估变更可能造成的影响，而评估需要的相关信息需要一个机制来提供，这个机制就是配置管理。
配置管理的目标是：
a.对公司内部的所有 IT 资产和配置及其服务作出说明
b.提供有关配置及其记录的准确信息以支持所有其他的“服务管理”流程
c.为“事故管理”、“故障管理”、“变更管理”和“发布管理”提供坚实的基础
d.对照基础设施验证配置记录并纠正任何异常情况
6． 服务台
Service Delivery：
1． 服务级别管理
服务级别管理是为签订服务级别协议（SLAs）而进行的计划、草拟、协商、监控和报告以及签订服务级别协议后对服务绩效的评价等一系列活动所组成的一个服务管理流程。服务级别管理旨在确保组织所需的IT服务质量在成本合理的范围内得以维持并逐渐提高。
2． IT服务财务管理
IT服务财务管理是负责预算和核算IT服务提供方提供IT服务所需的成本，并向客户收取相应服务费用的管理流程，它包括IT投资预算、IT服务成本核算和服务计费三个子流程，其目标是通过量化服务成本减少成本超支的风险、减少不必要的浪费、合理引导客户的行为，从而最终保证所提供的IT服务符合成本效益的原则。IT服务财务管理流程产生的预算和核算信息可以为服务级别管理、能力管理、IT服务持续性管理和变更管理等管理流程提供决策依据。
对于内部组织机构，目标应该是：
提供用于提供 IT 服务的 IT 资产和资源的有成本效益的职位。
在商业环境中，目标陈述可能要反映公司的利润和市场目标。
任何 IT 服务公司的目标都应该包括：
能够充分考虑在 IT 服务上的开销，并且知道这些开销都是为公司的客户交付服务的结果。
通过提供详尽的“对 IT 服务的变更”的业务案例来协助制定有关 IT 投资的管理决策。
3． IT服务持续性管理
IT服务持续性管理是指确保发生灾难后有足够的技术、财务和管理资源来确保IT服务持续性的管理流程。IT服务持续性管理关注的焦点是在发生服务故障后仍然能够提供预定级别的IT服务，从而支持组织的业务持续运作的能力。
4． 容量管理
容量管理的目的：确保以最有效和实时的方式提供目前以及未来因业务需求而增长的IT容量。
容量管理分三步走：
收集与容量有关的技术信息、SLA、业务规划、IT计划、业务的需求以及数量大小，和财务规划与预算；
容量管理是大多数 IT 部门一直面临的一个挑战，因为基础设施和服务需求每天都在发生变化。如果没有财务限制，“容量管理”就会很简单。但是，实际上财务限制以及合理利用旧系统中的投资这种需求将继续使容量管理成为一个挑战。
5． 可用性管理
管理可用性对于 IT 是一项非常重要的活动，因为错误计算或误解可用性可能会使企业遭受重大损失。例如，一个新的应用程序可能要求服务台支持从每天 16 小时每周 5 天扩展到每天 24 小时每周 7 天，这项服务的代价很高。
可用性管理流程的目标：优化 IT 基础设施的容量、服务和支持的公司，以便提供有成本效益且可使企业满足其业务目标的恒定的可用性级别。
可用性管理是通过分析用户和业务方的可用性需求并据以优化和设计IT基础架构的可用性，从而确保以合理的成本满足不断增长的可用性需求的管理流程。可用性管理是一个前瞻性的管理流程，它通过对业务和用户可用性需求的定位，使得IT服务的设计建立在真实需求的基础上，从而避免IT服务运作中采用了过度的可用性级别，节约了IT服务的运作成本。（转）
:lol 言简意赅，总结说明很清晰 谢谢分享~ 总结性的文章，还是不错的。
由于我日常的工作主要集中在Service Support这部分，如果能够把事故管理、问题管理、变更管理、发布管理、配置管理、服务台等相应的输入和输出添加进去，再把各个流程的考核点及评判标准写出来会更好一些。这样可以给相关人员做个参考，查漏补缺:lol
我有点懒就补充两个吧，嘿嘿。
1． 事故管理
输入就是通过电话、邮件、短信、监控告警、等渠道收到的故障信息；输出就是故障处理的最终结果是故障排除，还是转问题管理，还是误报等等。
考核标准有：事故响应时间，事故处理时间、事故解决率、事故单填写标准化程度、转问题管理率、转化知识率等
其实事故（我们这里叫做事件）单的填写应该也有相关的填写标准，需要详细准确的填写事故发生的时间，事故影响范围、获取信息的渠道，事故概要、事故详细信息、带时间戳的事故处理过程等等吧，比较多，大家可以再补充。
2、问题管理------这个基本和事故管理差不多，大家可以类比一下，
先发出来吧，工作了。
总结说明很清晰 谢谢分享 谢谢分享！
页:
[1]
2