我理解的ITIL——《指南》心得
一、ITIL概述
说到ITSM，还得从企业信息化开始讲起。
在企业的信息化过程中，必然需要提供大量相关的硬件和软件设施，我们把这个叫做IT基础架构。
而随着企业的飞速信息化，IT基础架构越来越庞大，越来越难以管理和维护。在稍微大点的公司，尤其是信息技术公司，你会看到技术人员疲于奔命的到处“救火”。
面临这个尴尬的现实，英国CCTA（也就是现在英国商务部OGC。大概是这样的，因为看书的时候觉着象CCTV，所以记住了），整出了ITIL的原型。
之前说过，ITSM是一个行业，一个领域，ITIL是这个行业其中的一个标准（还有同样以流程为中心，在ITIL基础上开发的BS1500，以安全为中心的BS7799，面向审计的COBIT）。
二、ITIL各流程详述
ITIL最初由约40本书构成，每本书描述一个流程，也就是说差不多有40个流程（老外真夸张）。
《指南》只谈了ITIL的十个核心流程，一个管理职能。分别是：
一项管理职能：服务台。
十个核心流程：
服务支持类：配置，变更，发布，事故，问题
服务提供类：服务级别，持续性，财务，能力，可用性。
服务台（Service Desk）：
一个“前台”（一个集中和专职的服务联络点），这个“前台”可以在不需要联系特定技术人员的情况下处理大量客户请求。
配置管理：
该流程提供了IT基础架构的配置情况。
书中定义：指由识别和确认系统的配置项，记录和报告配置项状态和变更请求，检验配置项正确性和完整性等活动构成的服务管理流程。
1.配置管理中最基本的信息单元是配置项（Configuration Items,CIs）。软件，硬件，各种文档都是CI。
2.CI都存在配置管理数据库中（CMDB）。注意：CI和CI间关系都存在CMDB中。
3.与资产管理的区别：资产管理只记录资产资产的购置时间，价格，折旧信息及所处位置等信息。
变更管理：
企业业务的变化导致IT基础架构的变化，自然IT服务也得变更。
书中定义：指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务管理流程。当问题管理通过调查和分析发现问题产生的根本原因，但不能制定恰当的解决方案从根本上予以解决时，问题管理需要向变更管理提交变更请求，从而通过实施必要的变更以从根本上消除问题的根源。
1.需组建变更咨询委员会（CAB）。
CAB由变更经理，客户，用户经理，用户群代表，应用开发人员，维护人员，有关专家和技术顾问等人员组成。
2.CAB的职责：
a.负责对问题管理流程提交的变更请求进行评审，决定是否批准实施变更请求。
b.为变更经理（Change Manager）评估实施某项变更可能产生的影响和确定变更的优先级提供意见。
发布管理：
将经测试无误的软硬件版本发布到目的变更点，并保证相应的服务级别。
发布管理负责计划和实施IT服务的变更，并描述变更的各个方面。
1.类型有：Delta Release（增量发布）,Full Release（全发布）,Package Release（包发布，《指南》的解释是说包发布是指将一组软件配置项以包的形式一起导入实际运作环境的发布方式）。
2.发布管理的运作中涉及到三个库：
最终软件库（DSL，Definitive Software Library）：存放所有已批准的最终版本的软件配置的数据库。
最终硬件库（DHS, Definitive Hardware Store）：为备用硬件而设置的一个区域（安全存储）。这里面的组件在恢复重大事故时临时用到，用完应将其归回到最终硬件库。
CMDB：为发布管理提供信息，由发布管理更新。
事故管理：
使IT系统尽快恢复到服务级别协议所定义的服务级别，同时记录事故以便为其它流程提供支持，尽可能小的影响客户和用户业务。（强调事故恢复速度）
1.事故（Incident）：引起或者有可能引起服务中断和服务质量下降的不符合IT服务标准操作的活动。
包括软硬件故障，服务请求（如，状态查询，重置口令，数据库导出等）。
2.多个事故要同时处理时，需确定事故处理的优先级。
3.事故升级（Incident Escalation）：一线支持（服务台）无法解决就升级到二线（管理部门），三线（软件开发人员），四线（提供商）。
问题管理：
通过调查和分析IT基础架构的薄弱环节，查明事故产生的潜在原因，并制定解决事故的方案和防止事故再次发生的措施，将由于问题和事故对业务产生的负面影响减小到最低的服务管理流程。（强调找出事故产生的根源，从而制定解决方案和预防措施）
1.问题：在未查明事故产生原因前，事故对应的潜在原因叫做“问题”。
2.知名错误（Known Errors）：找到事故产生的根本原因后，问题就成为知名错误。
服务级别管理：
服务级别管理（SLM）是为签订服务级别协议（SLAs）而进行的计划，草拟，协商，监控和报告，以及签订服务级别协议后对服务品质的评价等活动组成的一个服务管理流程。
1.服务级别协议体系：
三个协议（服务级别协议，运作级别协议，支持合同）四方关系（IT服务提供方，客户，内部供应商，外部第三方供应商）。
a.服务级别协议。IT服务提供方与客户
b.运作级别协议。IT服务提供方与内部供应商
c.支持合同。IT服务提供方与第三方供应商
IT服务持续性管理：
确保IT基础架构和IT服务在发生灾难后能在限定时间（这个时间应该是写在服务级别协议中的）内恢复。
持续性管理（IT Service Continuity Management，ITSCM）是负责预防灾难，增强IT基础架构的恢复能力和容错能力的流程，确保组织在发生灾难后有足够的技术，财务和管理资源来确保IT服务的持续性动作。
1.灾难（Disaster）：
严重影响系统运行甚至导致系统停止运行的外来事故，如地震，水火灾，失窃，恐怖袭击，网络恶意攻击，大范围停电等。
2.与业务持续性管理区别：
业务持续性管理侧重将风险到合理水平，在业务中断后进行业务流程的恢复。
IT服务持续性管理侧重IT基础架构的技术方面。
3.与事故管理，问题管理的区别：
IT服务持续性管理关注对组织业务动作可能产生重大影响的灾难性事故。
财务管理：
财务管理（financial Management for IT Services）是负责对IT服务运作过程中所涉及的所有资源进行货币化管理的流程。包括预算编制，IT核算和服务计费3个子流程。
能力管理：
根据组织当前及未来业务需求以合理的成本为IT服务运作配备所需IT资源。
能力管理(Capacity Management，通过也被称为容量管理，在IT服务管理中应译为能力管理)
1.与容量管理的区别：
容量管理是传统的IT和网络管理中的概念，考察对象是存储空间，设备性能。
a.能力管理是容量管理的延伸。
b.能力管理不仅要考虑存储空间，设备性能，还注重IT基础架构整体服务能力对业务需求的支持。
c.能力管理并不追求设备的高容量和高性能，而是结合业务需求和IT成本确定有效的能力需求，从而设计出合理的服务能力。
2.能力管理主要解决3个问题：
a.维持现有IT服务能力的成本对于业务需求而言是否合理
b.现有IT服务能力是否能满足目前及将来的客户需求
c.现有的IT服务能力是否发挥了最佳效能
3.能力管理的3个子流程：
业务能力管理：关注组织未来业务对IT服务的需求，以确保这种未来需求在制定能力计划时得到充分考虑。
服务能力管理：关注现有IT服务品质能否达到服务级别协议中所定级别目标。
资源能力管理：关注IT基础架构中每个组件的能力和使用情况，确保IT基础架构的能力足以实现服务级别目标。
可用性管理：
可用性管理是设计，实施，监控，评价和报告IT服务的可用性，以确保持续地满足业务的可用性需求的服务管理流程。
1.可用性（Availability）：
指一个组件或一种服务在设定的某个时刻或某段时间内发挥其应有功能的能力。通常以可用率来表示。
2.可用率：在约定的服务时段内，客户实际能够使用的服务的时间比例
3.与可用性相关的3性：
可靠性：IT基础架构无间断动作的能力
可维护性：IT基础架构在出现故障后能够被迅速恢复的能力
安全性：与某项服务相关的数据的保密性，完整性和可用性
三、实施
实施ITIL采用PDCA实施法（戴明环在这里又被借用了）。
计划（Plan）：根据客户的要求以及相关政策和规定，确定目标和实现目标所需流程，以实现期望的结果。
实施（Do）：实施在计划阶段所确定的流程。
检查（Check）：根据有关政策，目标和要求监控和评审所实施的流程并报告结果。
改进（Act）采取措施以不断提升绩效。
附：
ITIL框架：
六个模块：业务管理，服务管理，IT基础架构管理，安全管理，IT服务管理的规划与实施，应用管理。
注：文中的《指南》指《中国IT服务管理指南》
说到ITSM，还得从企业信息化开始讲起。
在企业的信息化过程中，必然需要提供大量相关的硬件和软件设施，我们把这个叫做IT基础架构。
而随着企业的飞速信息化，IT基础架构越来越庞大，越来越难以管理和维护。在稍微大点的公司，尤其是信息技术公司，你会看到技术人员疲于奔命的到处“救火”。
面临这个尴尬的现实，英国CCTA（也就是现在英国商务部OGC。大概是这样的，因为看书的时候觉着象CCTV，所以记住了），整出了ITIL的原型。
之前说过，ITSM是一个行业，一个领域，ITIL是这个行业其中的一个标准（还有同样以流程为中心，在ITIL基础上开发的BS1500，以安全为中心的BS7799，面向审计的COBIT）。
二、ITIL各流程详述
ITIL最初由约40本书构成，每本书描述一个流程，也就是说差不多有40个流程（老外真夸张）。
《指南》只谈了ITIL的十个核心流程，一个管理职能。分别是：
一项管理职能：服务台。
十个核心流程：
服务支持类：配置，变更，发布，事故，问题
服务提供类：服务级别，持续性，财务，能力，可用性。
服务台（Service Desk）：
一个“前台”（一个集中和专职的服务联络点），这个“前台”可以在不需要联系特定技术人员的情况下处理大量客户请求。
配置管理：
该流程提供了IT基础架构的配置情况。
书中定义：指由识别和确认系统的配置项，记录和报告配置项状态和变更请求，检验配置项正确性和完整性等活动构成的服务管理流程。
1.配置管理中最基本的信息单元是配置项（Configuration Items,CIs）。软件，硬件，各种文档都是CI。
2.CI都存在配置管理数据库中（CMDB）。注意：CI和CI间关系都存在CMDB中。
3.与资产管理的区别：资产管理只记录资产资产的购置时间，价格，折旧信息及所处位置等信息。
变更管理：
企业业务的变化导致IT基础架构的变化，自然IT服务也得变更。
书中定义：指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务管理流程。当问题管理通过调查和分析发现问题产生的根本原因，但不能制定恰当的解决方案从根本上予以解决时，问题管理需要向变更管理提交变更请求，从而通过实施必要的变更以从根本上消除问题的根源。
1.需组建变更咨询委员会（CAB）。
CAB由变更经理，客户，用户经理，用户群代表，应用开发人员，维护人员，有关专家和技术顾问等人员组成。
2.CAB的职责：
a.负责对问题管理流程提交的变更请求进行评审，决定是否批准实施变更请求。
b.为变更经理（Change Manager）评估实施某项变更可能产生的影响和确定变更的优先级提供意见。
发布管理：
将经测试无误的软硬件版本发布到目的变更点，并保证相应的服务级别。
发布管理负责计划和实施IT服务的变更，并描述变更的各个方面。
1.类型有：Delta Release（增量发布）,Full Release（全发布）,Package Release（包发布，《指南》的解释是说包发布是指将一组软件配置项以包的形式一起导入实际运作环境的发布方式）。
2.发布管理的运作中涉及到三个库：
最终软件库（DSL，Definitive Software Library）：存放所有已批准的最终版本的软件配置的数据库。
最终硬件库（DHS, Definitive Hardware Store）：为备用硬件而设置的一个区域（安全存储）。这里面的组件在恢复重大事故时临时用到，用完应将其归回到最终硬件库。
CMDB：为发布管理提供信息，由发布管理更新。
事故管理：
使IT系统尽快恢复到服务级别协议所定义的服务级别，同时记录事故以便为其它流程提供支持，尽可能小的影响客户和用户业务。（强调事故恢复速度）
1.事故（Incident）：引起或者有可能引起服务中断和服务质量下降的不符合IT服务标准操作的活动。
包括软硬件故障，服务请求（如，状态查询，重置口令，数据库导出等）。
2.多个事故要同时处理时，需确定事故处理的优先级。
3.事故升级（Incident Escalation）：一线支持（服务台）无法解决就升级到二线（管理部门），三线（软件开发人员），四线（提供商）。
问题管理：
通过调查和分析IT基础架构的薄弱环节，查明事故产生的潜在原因，并制定解决事故的方案和防止事故再次发生的措施，将由于问题和事故对业务产生的负面影响减小到最低的服务管理流程。（强调找出事故产生的根源，从而制定解决方案和预防措施）
1.问题：在未查明事故产生原因前，事故对应的潜在原因叫做“问题”。
2.知名错误（Known Errors）：找到事故产生的根本原因后，问题就成为知名错误。
服务级别管理：
服务级别管理（SLM）是为签订服务级别协议（SLAs）而进行的计划，草拟，协商，监控和报告，以及签订服务级别协议后对服务品质的评价等活动组成的一个服务管理流程。
1.服务级别协议体系：
三个协议（服务级别协议，运作级别协议，支持合同）四方关系（IT服务提供方，客户，内部供应商，外部第三方供应商）。
a.服务级别协议。IT服务提供方与客户
b.运作级别协议。IT服务提供方与内部供应商
c.支持合同。IT服务提供方与第三方供应商
IT服务持续性管理：
确保IT基础架构和IT服务在发生灾难后能在限定时间（这个时间应该是写在服务级别协议中的）内恢复。
持续性管理（IT Service Continuity Management，ITSCM）是负责预防灾难，增强IT基础架构的恢复能力和容错能力的流程，确保组织在发生灾难后有足够的技术，财务和管理资源来确保IT服务的持续性动作。
1.灾难（Disaster）：
严重影响系统运行甚至导致系统停止运行的外来事故，如地震，水火灾，失窃，恐怖袭击，网络恶意攻击，大范围停电等。
2.与业务持续性管理区别：
业务持续性管理侧重将风险到合理水平，在业务中断后进行业务流程的恢复。
IT服务持续性管理侧重IT基础架构的技术方面。
3.与事故管理，问题管理的区别：
IT服务持续性管理关注对组织业务动作可能产生重大影响的灾难性事故。
财务管理：
财务管理（financial Management for IT Services）是负责对IT服务运作过程中所涉及的所有资源进行货币化管理的流程。包括预算编制，IT核算和服务计费3个子流程。
能力管理：
根据组织当前及未来业务需求以合理的成本为IT服务运作配备所需IT资源。
能力管理(Capacity Management，通过也被称为容量管理，在IT服务管理中应译为能力管理)
1.与容量管理的区别：
容量管理是传统的IT和网络管理中的概念，考察对象是存储空间，设备性能。
a.能力管理是容量管理的延伸。
b.能力管理不仅要考虑存储空间，设备性能，还注重IT基础架构整体服务能力对业务需求的支持。
c.能力管理并不追求设备的高容量和高性能，而是结合业务需求和IT成本确定有效的能力需求，从而设计出合理的服务能力。
2.能力管理主要解决3个问题：
a.维持现有IT服务能力的成本对于业务需求而言是否合理
b.现有IT服务能力是否能满足目前及将来的客户需求
c.现有的IT服务能力是否发挥了最佳效能
3.能力管理的3个子流程：
业务能力管理：关注组织未来业务对IT服务的需求，以确保这种未来需求在制定能力计划时得到充分考虑。
服务能力管理：关注现有IT服务品质能否达到服务级别协议中所定级别目标。
资源能力管理：关注IT基础架构中每个组件的能力和使用情况，确保IT基础架构的能力足以实现服务级别目标。
可用性管理：
可用性管理是设计，实施，监控，评价和报告IT服务的可用性，以确保持续地满足业务的可用性需求的服务管理流程。
1.可用性（Availability）：
指一个组件或一种服务在设定的某个时刻或某段时间内发挥其应有功能的能力。通常以可用率来表示。
2.可用率：在约定的服务时段内，客户实际能够使用的服务的时间比例
3.与可用性相关的3性：
可靠性：IT基础架构无间断动作的能力
可维护性：IT基础架构在出现故障后能够被迅速恢复的能力
安全性：与某项服务相关的数据的保密性，完整性和可用性
三、实施
实施ITIL采用PDCA实施法（戴明环在这里又被借用了）。
计划（Plan）：根据客户的要求以及相关政策和规定，确定目标和实现目标所需流程，以实现期望的结果。
实施（Do）：实施在计划阶段所确定的流程。
检查（Check）：根据有关政策，目标和要求监控和评审所实施的流程并报告结果。
改进（Act）采取措施以不断提升绩效。
附：
ITIL框架：
六个模块：业务管理，服务管理，IT基础架构管理，安全管理，IT服务管理的规划与实施，应用管理。
注：文中的《指南》指《中国IT服务管理指南》
