实践：优化服务管理

更新时间：2025-01-08 工作计划版权反馈

【摘要】：可用性管理可用性管理实践的目的是确保服务交付承诺的可用性级别,以满足客户和用户的需求。容量和性能管理容量和性能管理实践的目的是确保服务达到约定和预期的绩效,以平衡成本效益的方式来满足当前和未来的需求。事件管理◆ 通过对事件管理实践的设计，组织为不同类型的事件适时地提供适当的管理以及对资

议程

◆ 本页无特定考点。

服务管理实践

●可用性管理

●业务分析

●容量和性能管理

●变更控制

●事件管理

●IT资产管理

●监控和事态管理

●问题管理

●发布管理

●服务目录管理

●服务配置管理

●服务连续性管理

●服务设计

●服务台

●服务级别管理

●服务请求管理

●服务验证和测试

◆ 服务管理实践虽然采用了ITIL 4中关于“实践”的理念，不再将流程作为所有服务管理的组合要素，但是在本章中，ITIL 4尽可能与ITIL以往版本中的流程与职能形成了兼容关系，基本上覆盖了以往所有的核心流程与职能所提及的内容。但不同于以往的是，ITIL不再为这些实践提供复杂的流程图，而是把这些可能形成流程图的“权力”交给了“价值链”。

◆ 在ITIL 4基础级中，有少数几个服务管理实践暂时不要求掌握，但这并不意味着工作实践就不会涉及，例如“服务目录管理”虽然不做重点掌握，但是“服务目录”这个文档应该是在服务管理中并非常重要常用的。

可用性管理

可用性管理实践的目的是确保服务交付承诺的可用性级别,以满足客户和用户的需求。

◆ 可用性取决于MTBF（平均故障间隔时间）和MTRS（平均故障后服务恢复时间）。

◆ 但很多组织仅仅根据MTBF和MTRS来计算可用性，这些数字很少能与客户的体验匹配，并且也不合适在大部分服务上应用，故而在ITIL 4中没有提出具体的计算方法。实际上量化可用性管理在不同的服务场景中可能有很大的诧异，例如桌面支持服务，消费者可能更关心的是“想用就用”的及时性，而并非连续可用的百分比。

◆ 可用性管理不同于后面提及的事件管理，是典型的保障性与计划性的管理实践，常见输出物便是《可用性计划》。

容量和性能管理

容量和性能管理实践的目的是确保服务达到约定和预期的绩效,以平衡成本效益的方式来满足当前和未来的需求。

性能衡量一个系统、个人、团队、实践或服务所取得或交付的成果

服务性能与在一个时间框架内的服务行为表现以及与在给定需求级别上完成服务操作所需的时间相关联服务容量是配置项或服务可以交付的最大吞吐量

◆ 容量和性能管理实践通常涉及服务性能及其所依赖的支撑型资源的性能。例如基础架构、应用程序和第三方服务。并且在不少组织中，人员也被纳入了容量和性能管理。

◆ 服务性能的好坏，决定了客户和用户对其所使用服务的满意度，服务停止往往是小概率事件，持续的性能不足却往往是常态，客户日积月累的不满意往往是最大的麻烦。

◆ 服务容量应该首先从业务分析开始，了解“削峰填谷”的平衡，“双十一”这样的短期高峰往往最需要卓越的容量管理之道。

变更控制

变更控制实践的目的是通过确保对风险进行适当评估、授权变更和管理变更计划来最大限度地增加成功的IT变更数量。

变更控制的范围由每个组织定义,它通常包括所有IT基础架构、应用程序、文档、流程、供应商关系以及可能直接或间接影响产品或服务的任何其他内容。

◆ 变更控制与组织级变革管理存在较大的区别。变更控制通常侧重于产品和服务的变化，组织级变更管理面向的是人员。

◆ 变更控制需要在进行有益变更以提供额外价值，与保护客户和用户免受变更所带来不利影响之间，找到平衡点。

◆ 在ITIL V2/V3/2011版本中，变更管理是一个流程，不过在多年实践中，变更的控制方法往往在不同的业务流程中，具有不同的路径、方法，很多场景下，大家对变更请求的称谓并不是唯一的“RFC”。

◆ 变更的定义是一级考点；作为ITIL实践之一：变更控制的相关概念和应用方法，是二级考点。

变更控制

变更是对任何可能对IT服务产生直接或间接影响的事物的添加、修改或删除。

◆ 标准变更、一般变更、紧急变更是三种类型的变更，每一种各有不同的管理方式。在实际应用中，往往变更的分类比这三类要复杂一些，但这三类代表了最主要的分类。

◆ 标准变更的执行往往是以服务请求的形式出现，而且标准变更一般需要一个标准的操作流程。

◆ 标准变更在不同行业中，往往有非常大的区别，例如“更换服务器”，这在传统架构中，肯定不能作为标准变更看待，而在类似许多互联网企业的云计算环境中，十万台以上的分布式服务器的更换，因为不造成业务的影响，且更换比较频繁，往往可以作为标准变更处理。

◆ 变更的定义是一级考点；作为ITIL实践之一：变更控制的相关概念和应用方法，这是二级考点。

变更控制

●授权变更的人或团体被称为变更授权者

√在敏捷组织中,去中心化的变更审批是一种常见的做法,使同行评审成为高效的变更审批方式

●变更计划用于帮助计划变更日程的沟通,避免冲突,实现有效的资源分配

◆ 变更计划在部署变更之后也是有价值的，因为这个计划中可能包含了事件管理、问题管理和改进计划所需要的信息。

◆ 变更的信息应该得到及时的传达，让人员在部署变更之前能做好充分准备。

◆ 变更的定义是一级考点；作为ITIL实践之一：变更控制的相关概念和应用方法，这是二级考点。

变更控制

◆ 变更控制实践同样涉及所有价值链活动，上表显示了变更控制实践对价值链的贡献。但可以看到，“改进”“设计和转换”“交付和支持”从变更控制实践中获得的收益更大一些，因为这几个环节最后必然要通过变更控制去实现最后的实施。

◆ 作为ITIL实践之一：变更控制的相关概念和应用方法，是二级考点。

事件管理

事件管理的目的是尽快恢复正常的服务运作,以尽量减少事件的负面影响。

事件是服务的计划外中断或者服务质量的降低。

●事件应记录在案

●事件应被管理,以达到约定的目标解决时间

●事件应区分优先级

◆ 事件管理实践的重要程度非常高，它可以对客户和用户的满意度，以及客户和用户对服务提供商的看法产生巨大的影响。

◆ 事件的记录和管理（包括跟踪），是为了确保其能在客户和用户的期望时间内解决。需要留意的是，期望时间常常会与服务供应商能完成的时间，或者服务供应商以为客户和用户所期望的时间存在不小的差距。

◆ 合理的优先级策略、升级策略、跟踪策略是事件管理中最常用的策略。

◆ 事件管理实践的目的，是一级考点；事件的定义是一级考点；作为ITIL实践之一：事件管理的相关概念和应用方法，是二级考点。

事件管理

◆ 通过对事件管理实践的设计，组织为不同类型的事件适时地提供适当的管理以及对资源进行适当的分配，目标是让影响较小的事件不消耗太多资源；对影响较大的事件能投入更多的资源。后者包括重大事件、信息安全事件等，通常由独立流程进行管理。

◆ 关于ITIL 4认为若要在事件管理中采用工具，关键在于将事件与其他内容关联是关键，而并非监控、自动处理这些技术内容。

◆ 作为ITIL实践之一：事件管理的相关概念和应用方法，是二级考点。

事件管理

事件可升级到支持团队进行解决,转派通常基于事件的类别。任何处理事件的人都应提供保证质量和及时的更新。事件管理需要在团队内部和团队之间进行高水平的协作。

◆ 高水平的协作基于各团队均了解事件管理流程，以及能理解他们能作出那些对提供服务的价值、结果、成本和风险有帮助的贡献。

◆ 事件经理这个角色在ITIL中一直占据了很高的位置，他的作用就是在事件处理中接受来自各方的升级，并积极协调团队和资源进行快速的事件解决或业务恢复。

◆ 作为ITIL实践之一：事件管理的相关概念和应用方法，是二级考点。

事件管理

一些组织使用一种叫做蜂群的技术来帮助管理事件。这涉及到许多不同的利益相关者最初一起工作,直到了解他们中哪些人需要和适合继续保留下来工作,哪些人可以去执行其他任务。

协同可以促进信息共享和学习,并有助于事件更有效地解决。

◆ 蜂群技术其实是一种管理技术，这也是在敏捷、DevOps等思想推进下的一种合作式方法。DevOps提倡跨职能团队共同办公，用“站会”去提高讨论问题的效率。不过这种方法在不同的文化组织里，遇到的挑战和难度是不一样的。

◆ 现在许多较大规模的组织，往往团队分散，部门间因为考核问题难免产生壁垒，反而一些创业型团队更容易形成协同文化。这是现在许多组织迈向数字化转型中一个重大挑战。

◆ 作为ITIL实践之一：事件管理的相关概念和应用方法，是二级考点。

事件管理

◆ 在价值链的每个活动中，都可能需要处理事件。但运营环境中所发生的事件，对用户影响最明显。

◆ 契动与获取/构建是和事件管理实践接触最多的，因为事件的来源大都经过“契动”这个环节，而事件的解决则很可能需要获取/构建进行实现。

◆ 作为ITIL实践之一：事件管理的相关概念和应用方法，是二级考点。

IT资产管理

IT资产管理实践的目的是规划和管理所有IT资产的全生命周期,以帮助组织。

◆ IT资产管理需要了解资产的状态，这样就能知道某类资产在服务提供中的状态变化，对资产的整体评估有很好的帮助。我们可以通过资产管理来调整采购的策略。

◆ IT资产管理有个很大的难点，就是资产来源非常多，进出管理混乱，经常无法第一时间了解到当前的资产现状，这样对资产的优化就无从着手，所以应该建立一个完备的资产管理流程。

◆ 资产的报废牵扯到信息安全的问题，不能忽略。

◆ IT资产管理实践的目的，是一级考点。

IT资产管理

IT资产是有助于交付IT产品或服务的任何有价值的组件。

◆ IT资产管理实践的范围通常包括所有软件、硬件、网络、云服务和客户端设备。有时还包括一些具有财务价值并且对IT服务有需求的非IT资产，例如建筑物或信息。甚至一些传统上视为“非IT资产”的设备，例如工业的运营技术（OT）（1），例如来自IoT（物联网）上的一部分设备。

◆ ITAM（IT资产管理）是资产管理的子实践，专用于管理IT设备和基础架构的生命周期。

◆ SAM（软件资产管理）是IT资产管理的一个方面，专门用于管理软件资产的获取、开发、发布、部署、维护和报废。

◆ IT资产的定义是一级考点。

（1）OT运营技术（Operational Technology），也翻译成“操作技术”。可以看成是对OT不同层次的理解，从宏观来看是“运营”，从微观来看可以理解成“操作”。其定义是用特定的硬件和软件，对物理设备如阀、泵等进行控制，从而导致物理过程与状态的变化。OT有一块极易被忽视的基石——工业知识的持续积累和传递。通过将人的隐性知识，转化为机器语言，从而成为一种可执行的知识体系。

监控和事态管理

监控和事态管理实践的目的是系统地观祭服务或服务组件,并记录和报告已确定为事态的某些改变。

这个实践对基础设施、服务、业务流程和信息安全事态进行识别和划分优先级,并对这些事态进行适当的响应,包括定义可能导致潜在事件的响应条件。

◆ 监控和事态管理实践管理着整个生命周期中的事态，从而防止、最小化或消除其对业务的负面影响。

◆ 该实践侧重于对具有潜在业务风险的重要CI的监控，对成熟的组织来说，大部分事件不会等到用户察觉到服务中断再提交上来，而是在组件的影响达到了一定阈值就会提出告警。

◆ 借助NPM和APM手段来进行业务视角的监控方式，已经在很多组织得到了实现。

◆ 监控和事态实践的目的，是一级考点。

◆ 事态的定义是一级考点。

问题管理

问题管理实践的目的是通过查明事件的实际和潜在原因,以及管理临时解决方案和已知错误,减少事件发生的可能性和影响。

◆ 每项有错误、缺陷或漏洞的服务都有可能导致事件，问题管理的目的不在于快速解决事件，而是如何通过对根本问题的发现与解决（或者提供临时解决方案）去规避事件的发生，或者事件发生后具有快速解决的能力。

◆ 在长期的经验中，将问题管理与知识管理做结合是一种广泛的方法。

◆ 我们常常因为中文中“问题”这个词而对问题管理感到困惑，其实我们要知道，所谓问题，就是未知的根本原因（Unknown Cause），而已知错误（Known Error）是已经分析过了但是还没有彻底解决的问题（Problem）。

◆ 问题管理实践的目的，是一级考点；问题和已知错误的定义是一级考点；作为ITIL实践之一：问题管理的相关概念和应用方法，是二级考点。

问题管理

◆ 在问题控制的环节，应考虑到所有的促成原因，包括导致事件发生的原因以及导致事件持续和影响的原因等。通过从所有四个维度去分析，将有助于形成良好的问题控制思考框架。

◆ 问题控制活动包括问题分析、记录变通方法和已知错误。

◆ 错误控制活动管理已知错误，这是初始分析已完成的问题；它通常意味着已经识别出有缺陷的部件。错误控制还包括识别可能导致实施解决方案的变更请求的潜在永久解决方案，但前提是在成本、风险和收益方面可以证明这一点。错误控制会定期重新评估尚未解决的已知错误的状态，包括对客户的总体影响、永久解决方案的可用性和成本以及解决方法的有效性。

◆ 作为ITIL实践之一：问题管理的相关概念和应用方法，是二级考点。

问题管理

临时解决方案是减少或消除尚未获得永久解决方案的事件或问题的影响的解决方案。一些临时解决方案降低了事件发生的可能性。 (www.xing528.com)

●临时解决方案要记录在问题记录中

●这可以在任何阶段完成,不需要等待分析完成

●如果在问题控制的早期记录了临时解决方案,则应在问题分析完成后对其进行审查和改进

◆ 问题与事件有关联，但是两者的管理方式不同。

◆ 事件对用户或流程有影响，必须尽快解决，以便正常的业务活动得以继续。

◆ 问题是事件的根源，需要进行调查和分析，以查明个中原因，制订临时解决方案（Workaround），并提出长期解决办法。这将减少未来事件的数量和影响。

◆ 作为ITIL实践之一：问题管理的相关概念和应用方法，是二级考点。

问题管理

◆ 问题管理与事件管理密切相关，两者的管理活动可能相互补充，也可能形成冲突。这需要在价值链上做好设计，达到平衡。

◆ 常见的疑惑是：问题应该什么时候被记录下来？谁负责记录？谁又负责解决或提供临时解决方案？因为问题管理属于“重要不紧急”，所以往往被搁置，被搁置的一个很大原因是没有明确问题负责人。

◆ 作为ITIL实践之一：问题管理的相关概念和应用方法，是二级考点。

问题管理

◆ 从ITIL V2以来，到ITIL V3/2011，问题管理通常侧重于在运营环境中的错误，所以在没有完全“提升”问题管理的“战略地位”前，问题管理和契动与获取/构建的关系最密切，这点和事件管理是类似的。相信比较早接触ITIL的学员，都会怀念ITIL V2时期服务支持的五个流程与一个职能：事件管理、问题管理、变更管理、发布管理、配置管理和服务台。不过随着数字化时代的到来，我们有理由相信这些流程或实践将承载新的历史使命——当然也包括问题管理。

◆ 作为ITIL实践之一：问题管理的相关概念和应用方法，是二级考点。

发布管理

发布管理实践的目的是使新的和已变更的服务和功能可供使用。

◆ 发布的定义是：可供使用的服务或者其他配置项，或者配置项集合的版本。和后面要提到的部署管理不同，发布管理更在意的不是技术行为，而是发布的策略。在高度频繁的发布场景中，传统的瀑布式发布（阶段性的，相对集中的）的模式，可能无法面对每天构建发布甚至每天构建发布多次的工作压力，这个时候，采用DevOps的方式是非常有必要的。

◆ 发布的不同策略与组织特征有很大关系，在线游戏类公司需要多次迭代发布，松耦合架构很重要，而对于有些制造业来说，大量的厂区具有相似的架构，那么自动化发布脚本则是这类行业的特点，但是对于业务系统非常复杂且稳定性要求极高的组织来说，更稳定的发布模式也是很有必要的。

◆ 发布管理实践的目的，是一级考点。

服务配置管理

服务配置管理实践的目的是确保有关服务的配置以及支持服务的配置项的准确和可靠的信息在需要时和在所需之处可用。

◆ 配置项的定义是：为了提供IT服务而需要管理的任何组件。配置管理所创造的价值虽然是间接的，但却能使其他实践有效果和有效率地工作。

◆ 配置项的关联关系设计比较难，这时候我们需要在初期建立一套配置模型，将配置项的种类、关系、属性通过文档方式梳理出来，与各个应用团队进行沟通，并思考配置管理系统（CMS）的“消费场景”。

◆ 服务配置管理实践的目的，是一级考点。

服务配置管理

配置项(CI)是需要管理的任何组件,以便提供IT服务。

◆ 服务配置管理收集和管理有关各种配置项的信息，通常包括硬件、软件、网络、建筑物、人员、供应商和文档。服务也可被视为配置项。

◆ CMS（配置管理系统）即用于支持服务配置管理的一组工具、数据和信息。

◆ IT管理者一直寻觅好用的CMS管理工具，自动发现是很多IT管理者梦寐以求的，但是自动发现不仅仅有技术问题，更有管理问题需要深究。

◆ 配置项的定义是一级考点。

服务连续性管理

服务连续性管理实践的目的是确保在发生灾难事件时,服务的可用性和性能保持在足够的水平。

本实践为建立组织的容灾能力提供了一个框架,能够产生有效的响应,来保障关键利益相关者的利益,以及组织的声誉、品牌和创造价值的活动。

灾难是一种突如其来的意外事件,对组织造成巨大的破坏或严重的损失。

◆ 当组织发生灾难——由正常响应和恢复实践均无法处理的服务中断或风险，则触发服务连续性管理流程。

◆ 每个组织都必须通过BIA（业务影响分析）来考虑和定义灾难的含义。

◆ 服务连续性管理与事件管理的区别在于，事件的严重等级不同。前者侧重于业务上认为是灾难的事件，后者负责处理不太重要的事件。但灾难、重大事件、事件之间的区别需要预先定义、获得同意并被记录，同时应有明确的阈值和触发条件。

◆ 业务连续性管理实践涉及所有价值链活动。

服务台

服务台实践的目的是获取和管理对事件修复和服务请求的响应需求,它是服务提供者向所有用户开放的服务入口点和单一联系点。

◆ 服务台为用户提供了报告问题、查询和请求的明确途径，并对其进行确认、分类、归属和操作。

◆ 单一联系点（SPOC）是服务管理多年来一个非常有效的方法，消费者非常不愿意自己的诉求被踢来踢去，在他们眼里，这就是推诿。“首问责任制”是一种多方管理中常用的策略。

◆ 服务台实践的目的，是一级考点；作为ITIL实践之一：服务台的相关概念和应用方法，是二级考点。

服务台

随着自动化程度的提高和技术债务的逐步消除,服务台的重点是为“人员和业务”提供支持,而不仅仅是动手处理那些简单的技术问题。

◆ 服务台已成为任何服务业务的重要组成部分。在很多年前，就有许多顾问对“业务服务台”和“IT服务台”融合的设想，但是真正让这个想法逐渐开始被认为可行的，是数字化时代的来临，终端用户已经越来越依赖于“系统给自己服务”，例如滴滴打车、饿了吗之类的数字化服务方式，以及网上银行等在线业务的普及，都让业务服务和IT服务逐渐融合。

◆ 无论服务台及其人员的效率如何，总会有一些问题需要升级，需要其他团队的支持。支持和开发团队需要与服务台密切合作，向用户和客户展示及提供“联系起来（joined up）”的方法。