ITIL 4 —IT服务管理实践精要

ITIL4，IT服务管理。服务管理的四个维度、服务价值体系的五个环节、服务价值链的六大活动及IT服务管理的七大指导原则，IT服务的配置管理、可用性管理、问题管理、事件管理等管理实践精要总结。

ITIL 4 实践精要

• ITIL的4567
  • 服务管理的四个维度
    • 通过对这四个维度中的每一个给子适当的关注，组织可以确保它的SVS保持平衡和有效。
    • 具体内容
      • 组织和人员(Organizationsandpeople)
      • 信息和技术(Information and technalogy)
        • 考虑了数据安全和隐私
      • 合作伙伴和供应商(Partners and suppliers)
      • 价值流和流程(Value streams and processes)
        • 每个价值流都必须针对特定场景而设计
        • 考量活动之间的协调情况
  • 服务价值体系（SYS）的五大环节
    • ITIL®服务价值链(the ITILeservice value chain)
      • SVS的核心要素
      • 可作为组织的运营模型
    • ITIL®实践(ITIL®practices)
    • ITIL@指导原则(ITIL®guiding principles)
    • 治理(Governance)
      • 意味着组织被指导和控制
      • 需考虑公正和透明
      • 如何实现治理
        • 评估：评估组织、其战略、投资组合以及与其他方的关系。
        • 指导：指导组织战略和政策的制定和实施
        • 监控：监控组织及其实践、产品和服务的性能。
    • 特续改进(Continual improvement）
      • 确保绩效持续满足期望的一项经常性组织活动
  • 服务价值链六大活动
    • • 规划（Plan）
    • • 改进（Improve）
      • 持续改进所有价值链活动中的所有产品和服务
    • • 参与（Engage）
    • • 设计和转换（Design and transition）
      • 确保产品和服务一直满足利益相关者的期望
    • • 获得/构建（Obtain/build）
      • 考虑管理服务在符合协定规范方面的重要性
    • • 交付和支持（Deliver and support）
      • 确保正在进行的服务活动满足用户预期
  • ITIL的七项指导原则
    • 关注价值
      • 组织所做的一切都需要直接或间接地映射到涉众的价值。
      • 对价值原则的关注包含许多视角，包括客户和用户的体验，
      • 应用此原则要考虑如下建议
        • 了解服务使用者如何使用每个服务
        • 鼓励所有员工注重价值
        • 在正常的运营活动和改进计划中注重价值
        • 在任何改进计划的每一步都要关注价值
    • 从现在开始 （始于足下）
      • 不要从零开始，在不考虑现有可用资源的情况下构建新东西。
      • 在当前的服务、流程、程序、项目和人员中，可能有大量内容可以用来创建所需的结果。
      • 应该直接调查和观察当前的状态，以确保充分了解它。
      • 应用此原则要考虑如下建议
        • 以顾客或期望的结果为出发点，尽可能客观地看待存在的事物
        • 当在当前状态下发现成功的实践或服务的示例时，确定是否以及如何复制或扩展这些实例以实现所需的状态
        • 运用你的风险管理技巧
        • 认识到有时当前状态中没有能重用的
    • 利用反馈的迭代式进展 （带反馈的迭代进度）
      • 不要试图一次做所有的事情。即使是巨大的计划也必须迭代地完成。
      • 通过将工作组织成可以及时执行和完成的更小的、可管理的部分，更容易对每项工作保持更清晰的关注。
      • 在每次迭代之前、期间和之后使用反馈将确保操作是集中的和适当的，即使环境应该改变。
      • 以时间限制、迭代的方式工作，反馈回路嵌入到流程中，允许：
        • •更大的灵活性
        • •更快地响应客户和业务需求
        • •早期发现和应对失败的能力。
        • • 质量的全面提高。
      • 应用此原则要考虑如下建议
        • 理解整体，但要一点一点做
        • 生态系统是不断变化的，所以反馈是必不可少的
        • 快并不意味着不完整
    • 协作并提高可见性
      • 跨界合作产生的结果具有更强的说服力，更切合目标，更有可能获得长期成功。
      • 实现目标需要信息、理解和信任。工作和结果应该是可见的，隐藏的议程应该避免，信息应该在最大程度上共享。
      • 工作的可见性不足会导致决策能力差，进而影响组织提高内部能力的能力
      • 应用此原则要考虑如下建议
        • 协作并不意味着共识
        • 以听众能听到的方式交流
        • 只能对可见数据进行决策
    • 整体地思考和工作
      • 没有任何服务或用于提供服务的元素是独立的。
        • 关注端到端的服务交付
      • 服务提供者和服务使用者所取得的结果将会受到影响，除非组织将服务作为一个整体而不仅仅是服务的一部分来工作。
      • 通过对信息、技术、组织、人员、实践、合作伙伴和协议的有效和高效的管理和动态集成， 将结果交付给内部和外部客户，所有这些都应该协调起来，以提供确定的价值。
      • 应用此原则要考虑如下建议
        • 认识到系统的复杂性
        • 协作是整体思考和工作的关键
          • 使用服务管理的四个维度来确保协调改进计划的所有方面
        • 在可能的情况下，在系统组件的需求和交互中寻找模式
        • 自动化可以促进整体工作
    • 保持简单和实用
      • 始终使用最少步骤完成目标
        • 仅在需要时增加控制和指标
      • 如果流程、服务、操作或度量没有提供任何价值，或者没有产生任何有用的结果，那么消除它。
      • 始终使用基于结果的思维来产生实际的解决方案，以交付结果。
      • 应用此原则要考虑如下建议
        • 确保价值
        • 简单是最高级的
        • 少做些事，但要做得更好
        • 尊重相关人员的时间
        • 更容易理解的则更容易接受
        • 简单是快速取胜的最佳途径
    • 优化和自动化
      • 优化意味着尽可能使某件事情变得有效和有用
      • 所有类型的资源，特别是人力资源，都应发挥其最佳作用。
      • 自动化通常是指使用技术，在有限或无人为干预的情况下，正确、一致地执行一个或一系列步骤。
      • 消除任何真正浪费的东西，用科技去实现它所能做到的一切。
        • 侧重于减少成本和人为错误
        • 人类干预应该只发生在真正有价值的地方。
      • 优化路径遵循以下高级步骤：
        • 1. 理解并同意所提出的优化存在的背景
        • 2. 评估所建议优化的当前状态
        • 3.商定本组织未来的状况和优先事项，注重简化和价值
        • 4. 确保适当水平的利益相关者参与和承诺
        • 5. 以迭代的方式执行改进
        • 6. 持续监控优化的影响
      • 应用此原则要考虑如下建议
        • 在自动化之前简化或优化
        • 定义度量标准
        • 在应用此指导原则时，请使用基原则
    • 问题：
      • 组织要求利益相关者审核所计划的变更。
        • 体现了协作并促进可见行的原则
      • ITIL指导原则用来做什么
        • 帮助组织制定好的决策
      • 原则相互作用
        • 除了指导原则外，还必须认识到它们相互影响、相互依赖。
        • 组织不应只使用其中的一两项原则，而应考虑每一项原则的相关性及其如何适用
        • 组织决策时，如何将七原则整合？
          • 评审各项指导原则以确定其与特定决策的相关程度
        • 并非所有的原则在每一种情况下都是至关重要的，但在每一种情况下都应加以审查，以确定它们的适当性。
• 服务目录管理
  • 实践目的
    • 提供关于所有服务和服务提供的一致信息的单一来源，并确保相关受众可以获得这些信息
  • 服务目录管理实践包括一系列与发行、编辑和维护服务和产品说明及其相关产品有关的活动。
  • 服务目录中的全部服务列表 可能不适用于所有客户和/或用户：
    • 用户视图：提供有关可请求的服务产品和配置详细信息的信息。
    • 客户视图：提供服务级别、财务和服务绩效数据。
    • IT到IT：客户视图 提供技术、安全和流程信息，以便在服务交付中使用。
  • 定义：请求目录
    • 服务目录的视图，提供用户现有和新服务的服务请求的详细信息。
  • 服务目录管理在价值链活动中的体现
    • 规划：服务目录实现策略和服务组合投资决策
    • 改进 ：服务目录描述，不断监控和评估需求模式
    • 参与：服务目录与客户和用户建立战略、战术和运营关系
    • 设计和转换 ：服务目录确保服务的实用性和保修方面都得到考虑和公布
    • 获取/构建 ：通过提供组件和服务采购的服务目录视图来支持此价值链活动
    • 交付和支持：服务目录提供了如何交付和支持服务的内容
• 服务级别管理
  • 实践目的
    • 为服务绩效设定明确的基于业务的目标，以便根据这些目标对服务的交付进行适当的评估、评价监控和管理。
  • 服务水平管理的技能和能力包括关系管理、业务联络、业务分析和商业/供应商管理。
  • 服务级别管理提供组织服务的端到端可见性
  • 如何实践
    • 与客户建立服务和目标服务级别的共享视图
    • 通过收集、分析、存储和报告已识别服务的相关指标，确保组织满足定义的服务级别
    • 执行服务评审以确保当前的服务集继续满足组织及其客户的需求
    • 捕获和报告服务问题，包括针对定义的服务级别的性能
  • 服务水平协议 （SLA）
    • 一直被用作从客户角度衡量服务性能的工具
    • 成功的SLA的一些关键要求
      • 它们必须与服务目录中定义的“服务〞相关。
      • 它们应该与定义的结果相关，而不仅仅是操作指标。
      • 它们应该反映出“协议〞，即服务提供者和服务消费者之间的约定和讨论。
      • 让所有利益相关者参与进来是很重要的，包括合作伙伴、赞助商、用户和客户。
      • 它们必须写得简单明了，便于各方理解和使用。
    • SLA架构
      • Service-based SLA（基于服务的SLA）
      • Customer-based SLA（基于客户的SLA）
      • Multi-level SLAs（多级SLA）
  • 服务级别管理涉及来自多个来源信息
    • 客户参与度
    • 客户反馈
      • 调查
      • 关键业务相关措施
    • 运营指标
    • 业务指标
  • 服务级别管理在价值链活动中的体现
    • 规划 ：支持产品和服务组合以及服务产品的规划
    • 改进 ：可以成为服务改进的驱动力
    • 参与：通过反馈确保与客户和用户的持续接触
    • 设计和转换 ：为设计和开发提供了输入
    • 获取/构建 ：提供组件和服务性能的目标
    • 交付和支持： 向运营和支持团队传达服务绩效目标
• 容量和性能管理
  • 实践目的
    • 是确保服务达到商定和预期的性能，以符合成本效益的方式满足当前和未来的需求
  • 定义：性能
    • 衡量一个系统、个人、团队、实践或服务所达到或交付的程度。
  • 能力和绩效管理实践包括以下活动
    • 服务性能和容量分析
      • 当前服务性能的研究和监控
      • 容量和性能建模
    • 服务性能和容量规划
      • 能力需求分析
      • 需求预测和资源规划
      • 绩效改进计划
  • 容量和性能管理在价值链活动中的体现
    • 规划：提供有关实际需求和性能的信息以支持战术和运营计划，
    • 改进 ：对所有级别的评估和改进至关重要
    • 参与：通过提供有关性能和容量的信息来支持期望管理
    • 设计和转换 ：有助于确保新服务和已更改服务的设计具有最佳性能、容量和可伸缩性
    • 获取/构建 ：有助于确保获得/构建的组件和服务满足组织的性能需求
    • 交付和支持 ：为服务和服务组件提供性能和容量目标、度量和度量以及报告目标和工具。
• 可用性管理
  • 实践目的
    • 是确保服务提供商定的可用性级别，以满足客户和用户的需求。
  • 定义：可用性
    • IT服务或其他配置项在需要时执行约定功能的能力。
  • 可用性管理活动包括：
    • 谈判并商定可实现的可用性目标
    • 设计能够提供所需可用性级别的基础架构和应用程序
    • 确保服务和组件能够收集度量可用性所需的数据
    • 监测、分析和报告可用性
    • 规划可用性的改进。
  • 服务的可用性取决于
    • 服务失败的频率以及故障后恢复的速度。
    • 通常表示为平均故障间隔时间(MTBF）和平均恢复服务时间(MTRS)
    • 可靠性（MTBF） =（协定服务时间-宕机时间） /宕机次数
    • 可维护性（MTRS） = 宕机时间/宕机次数
  • 可用性管理在价值链活动中的体现
    • 规划：在服务组合决策中，以及在为服务和实践设定目标和方向时，必须考虑规划
    • 改进： 在计划改进时要考虑改进
    • 参与 ：必须了解和掌握新服务和更改服务的可用性要求
    • 设计和转换 ：新的和更改的服务必须设计为满足可用性目标
    • 获取/构建 ：在构建组件或从第三方获取组件时，需要考虑获取/构建可用性。
    • 交付和支持：包括对可用性的度量和对可能影响实现可用性目标能力的事件的响应
• 服务配置管理
  • 实践目的
    • 是确保有关服务配置以及支持它们的Cl的准确可靠的信息在需要时和在需要时提供。
    • 这包括有关如何配置CIl以及它们之间的关系的信息。
  • 定义
    • 配置项
      • 为了提供IT服务而需要管理的任何组件。
      • 收集和管理关于各种CI信息，通常包括硬件、软件、网络、建筑物、人员、供应商和文档
    • 配置管理系统
      • 用于支持服务配置管理的一组工具、数据和信息。
  • 配置管理流程
    • 确定新的配置项，并将其添加到CMS中
    • 部署更改时更新配置数据
    • 验证配置记录是否正确
    • 审核应用程序和基础结构，以识别任何未记录的应用程序和基础结构。
  • 重要说明
    • 收集和维护配置信息所需的努力与信息所创造的价值相平衡
  • 示意图
  • 服务配置管理在价值链活动中的体现
    • 规划 ：用于计划新的或更改的服务。
    • 改进 ：应经过测量和持续改进
    • 参与 ：与一些利益相关者接触可能需要和使用配置信息
    • 设计和转换： 记录了资产如何协同工作以创建服务
    • 获取/构建 ：配置记录可在该价值链活动期间创建
    • 交付和支持 ：有关配置项的信息对于支持服务恢复至关重要
• 服务连续性管理
  • 实践目的
    • 是确保在发生灾难时服务的可用性和性能保持在足够的水平
  • 当服务中断或组织风险的规模大于组织处理正常响应和恢复实践的能力时，就会触发此实践
  • 定义
    • 恢复时间目标(RTO)：
      • 服务中断后可接受的最长时间段，在业务功能缺失严重影响组织之前
      • 表示必须恢复产品或活动或必须恢复资源的最长商定时间。
    • 恢复点目标（RPO)：
      • 必须将活动使用的信息恢复到该点，以使活动能够在恢复时运行。
    • 灾难恢复计划：
      • 与组织如何从灾难中恢复以及恢复到灾难前状态有关的一组明确定义的计划
      • 考虑到服务管理的四个领域。
    • 业务影响分析：
      • 服务连续性管理的一个关键活动，它识别VBF及其依赖关系。
  • 服务连续性管理在价值链活动中的体现
    • 规划：服务连续性管理支持通过组织当前连续性状态的相关信息以及规划和预测的工具和方法来建立初始风险偏好。
    • 改进 ：确保持续性计划、措施和机制得到持续监控和改进
    • 参与 ：支持与各种利益相关者的接触
    • 设计和转换： 确保产品和服务按照组织的连续性要求进行设计和测试。
    • 获取/构建 ：确保将连续性构建到组织的服务和组件中
    • 交付和支持 ：确保持续交付、操作和支持符合连续性要求和政策
• 变更控制
  • 实践目的
    • 是通过确保风险已被正确评估、授权继续进行变更以及管理变更时间表，最大限度地增加成功的IT变更数量
  • 定义：变更
    • 添加、修改或删除任何可能对服务产生直接或间接影响的内容。
    • 授权变更的个人或团体称为变更授权人
  • 变更类型
    • 标准变更
      • 是低风险、预先授权的变更，这些变更是很好理解和充分记录的
      • 并且可以在不需要额外授权的情况下实施。
    • 正常变更
      • 需要按照标准流程进行计划、评估和授权。
      • 也叫一般变更
        • 是通过手动或自动创建变更请求触发的变更
    • 紧急变更
      • 必须尽快实施
        • 没有充足的评估时间
  • 变更范围
    • 通常包括所有IT基础设施、应用程序、文档、流程、供应商关系 以及可能直接或间接影响产品或服务的任何其它内容
    • 组织变更管理管理人员方面的变更，以确保成功地实施了改进和组织转换活动。
    • 变更控制通常集中在产品和服务的变更上。
  • 对于标准变更的理解
    • 标准变更有可能作为服务请求来管理！
    • 什么时候需要针对标准变更执行充分的风险评估和授权
      • 创建标准变更程序时
    • 示例
      • 为响应服务请求而安装软件应用
  • 变更授权的正确方式
    • 变更日程中的变更均已经过预先授权，无需获得额外授权
    • 每一类变更和变更模型均要分配变更授权
  • 变更日程 （变更时间表）
    • 目的
      • 帮助管理正常变更
      • 变更时间表用于帮助计划变更、协助沟通、避免冲突和分配资源
    • 何时使用
      • 提供有关署变更的信息以帮助管理事件和问题
    • 紧急变更通常不会记录在变更日程中
  • 变更控制在价值链活动中的体现
    • 规划 ：对产品和服务组合、策略和实践的更改都需要一定程度的控制， 而变更控制实践就是用来提供这种控制的。
    • 改进 ：许多改进需要通过变更实施
    • 参与 ：与客户接洽，可能需要咨询或通知用户有关变更的信息
    • 设计和转换 ：许多变更都是由于新的或变更的服务而发起的
    • 获取/构建 ：对组件的获取/构建的变更遵从变更控制
    • 交付和支持 ：变更可能会对交付和支持产生影响
• 事件管理
  • 实践目的
    • 是通过尽快恢复正常服务操作，将事故的负面影响降至最低
  • 定义
    • 事件
      • 服务的意外中断，或服务质量的降低。
  • 如何实践
    • 组织应该设计他们的事件管理实践，为不同类型的事件提供适当的管理和资源分配
    • 处理事件的人员必须及时提供高质量的更新。
  • 诊断和解决事件
    • 有些事件将由用户自己通过自助解决
    • 有些事件将由服务台解决
    • 更复杂的事件通常会上报给支持团队解决。
    • 事件可以上报给供应商或合作伙伴
    • 最复杂的事件，以及所有重大事件，通常需要一个临时团队一起工作，以确定解决方案
    • 在某些极端情况下，可能会调用灾难恢复计划来解决事件
  • 事件管理在价值链活动中的体现
    • 改进 ：事件记录是改进活动的关键输入
    • 参与：事件对用户可见，重大事件对客户也可见
    • 设计和转换 ：确保测试环境中发生的事件得到及时和可控的解决。
    • 获取/构建 ：确保开发环境中发生的事件得到及时和可控的解决。
    • 交付和支持 ：价值链活动，包括解决事件和问题。
• 服务请求管理
  • 实践目的
    • 通过以有效且用户友好的方式处理所有预定义的、用户发起的服务请求来支持约定的服务质量
  • 定义
    • 服务请求
      • 用户或用户授权代表发出的一种请求，该请求发起已被同意作为服务交付的正常部分的服务操作
  • 应遵循的指导原则
    • 服务请求及其履行应尽可能标准化和自动化。
    • 应制定政策，规定哪些服务请求将在有限的甚至不需要额外批准的情况下得到满足，以便简化履行。
    • 用户对完成时间的期望应根据组织实际交付的内容进行明确设定。
    • 应确定并实施改进机会，以加快实现时间，并进一步利用自动化。
    • 策略和工作流程应该包含在文档中，用于记录和重定向作为服务请求提交的任何请求，但这些请求实际上应该作为事件或更改进行管理。
  • 服务请求管理在价值链活动中的体现
    • 改进 ：提供一个渠道，改善倡议，用户的赞扬和投诉
    • 参与 ：包括定期沟通以收集用户特定的需求、设定期望值并提供状态更新。
    • 设计和转换 ：标准变更可以作为服务请求启动和实现
    • 获取/构建：需要获得预先批准的服务组件
    • 交付和支持 ：对正常的服务提供做出了重大贡献。
• 问题管理
  • 实践目的
    • 是通过识别事件的实际和潜在原因、管理解决方案和已知错误，降低事故的可能性和影响
  • 定义
    • 问题
      • 一个或多个事件的原因或潜在原因。
    • 已知错误
      • 已分析但尚未解决的问题
    • 临时解决方法
      • 一种解决方案，可以减少或消除事件或问题的影响，而事件或问题还没有完全解决。
  • 问题解决的三个阶段
    • 问题识别
      • 问题控制
        • 错误控制
  • 问题管理在价值链活动中的体现
    • 改进 ：有效的问题管理提供了减少事件数量和无法预防的事件影响所需的理解。
    • 参与： 客户和用户可以看到对服务有重大影响的问题。
    • 设计和转换： 提供有助于改进测试和知识转移的信息。
    • 获取/构建 ：可识别产品缺陷
    • 交付和支持 ：防止事故重复发生，并支持及时解决事件