【学习目标】

1.知识目标

熟悉服务运营流程与职能的概念与组成。

掌握事件管理、故障管理和问题管理的流程。

熟悉服务请求履行和访问管理的流程活动。

掌握服务台的概念。

2.技能目标

掌握服务台构建要素。

掌握事件管理、问题管理流程实施方法。

【认证考点】

能精通ITIL理念，对ITIL能提出改进意见并且推动实施。

能够总结经验，发现流程制度中不合理的地方，提出可行的改进建议。

能够对已发现的流程、制度问题提出改进优化方案，并实施使问题得到解决。

项目引导：“重庆神通网络服务公司”ITIL管理

【项目描述】

重庆神通网络服务公司是重庆一家为电信、移动和联通网络维护外包服务的公司。随着公司业务量增大，功能升级，在运营管理中引入IT服务管理（IT Service Management，ITSM ）项目建设，利用信息技术基础架构库（ITIL，Information Technology Infrastructure Library）管理流程实施信息服务和运营管理。

知识储备

1.1服务运营流程

1.1.1服务运营流程概述

服务运营主要描述IT服务运营管理方面的实践，确保达到服务支持和交付的目的，IT服务战略目标最终需要通过服务运营来实现。ITIL v3体系中服务运营包含了事件管理、故障管理、问题管理、访问管理、服务请求履行五项流程以及服务台、技术管理、应用管理、IT运营管理四项职能。服务运营的主要目标是，通过一系列日常活动和流程的协调执行，为客户和用户提供可管理的、达到既定的服务级别协议的服务。同时，服务运营还负责对提供和支持服务所需要的技术进行日常管理。服务运营是IT服务管理生命周期中负责日常运行维护的一个阶段。服务运营可以形象看做是一个“物业管理”的过程。这意味着服务运营应当更加关注日常运行活动和用于提供服务的基础架构。服务运营的流程与职能如图1-1-1所示。

1.1.2 事件管理

1.概述

事件(Event)可以被定义为任何状态的变化，这种状态的变化可能会对IT基础设施及其技术IT服务产生重大影响。因此，需要对事件进行规范的管理。通常，事件的监控主要是通过各种监控工具来实现的，这样的工具主要可被分为两类。

（1）主动监控工具。定时扫描配置项以确定它们的状态和可用性，并对任何意外情况产生一个警告，这个警报需要发送给适当的工具或团队以便采取行动。

（2）被动监控工具。检测和关联由配置项产生的运行警报或通知信息。

注意：事件监控过程中，一般的事件就记录在系统日志中，有些简单的告警会触发自动批处理（如发送SNMP trap、执行提示音乐等），再严重一些就可能以发送短信等方式提示管理员注意，比较严重的则会产生工单进行跟踪，特别严重的则会启动应急预案等。

事件管理的目标是提供检测、分辨事件并确定恰当的控制行动的能力。由此，事件管理是服务运营监视和控制的基础。另外，如果这些事件用程序化的方式交流运营信息（包括告警和异常），它们就将作为服务运营的基础自动传递给其他的运营管理活动，如在远程设备上执行脚本、提交批处理作业或者通过多设备增强性能来动态平衡服务需求等。

2.流程活动

事件管理的活动通常是包括事件的发生、通知、监测、事件的过滤、事件的重要性判断、事件的关联、触发器、响应选择和事件关闭等。图1-1-2是事件管理流程的总体流程概览，可以作为事件管理流程设计参考。

（1）事件发生

事件总是不断地发生的，但并不是所有的事件都需要监测和记录，在设计、开发、管理和支持IT服务和IT基础架构工作中的每个人员，都应该理解哪些类型的事件需要监测和记录。

（2）事件通知

大部分的配置项都设计了关于传递自身相关的特定信息的功能。当某特定条件出现时，配置项自动产生一个通知。大多数配置项遵照开放标准（如SNMP）产生事件通知。很多配置项都基于设计者的经验设置了用于产生一套标准的事件集，如当需要“运行”某配置项时，通过与“启用”这项活动相关事件的生成机制而产生某种类型的事件。

（3）事件监测

一旦事件通知产生，它将被运行在同一系统中的“代理”程序监测出来，或者直接传送到管理工具软件，这种管理工具软件能够读取和翻译事件的含义。

（4）事件过滤

事件过滤的目的是决定将事件传送到管理工具还是丢弃它。

（5）事件的重要性判断

通常，组织应当事先定义通知性消息、警告、异常三种事件类型的划分标准，并针对每一种情形定义明确的处理机制。在已经明确事件的划分标准的情况下，事件管理人员应对当前发生的事件做出判断。

（6）事件关联

对于警告性事件，需要将其与其他警告或者异常进行关联，以进一步判断该警告的严重程度。

（7）触发器

如果事件关联识别出一个事件，这时就需要进行响应了。用于启动这个响应的机制就是触发器。

（8）响应选择

在流程的这一环节，有大量响应措施可供选择，有一点需要重点注意的就是响应选项可能是多种选择的复合。可用的选项有事件记录、自动响应、告警后人工干预、判断属于故障、问题还是变更、发起变更申请RFC、打开故障记录、打开并连接到问题记录和特殊类型的故障。

3.事件管理流程设计

有效的事件管理不是在服务投入运营的时候才设计的。既然事件管理是监视服务的性能和可用性的基础，准确的监视目标和机制应该在可用性管理和容量管理流程中（服务设计阶段）进行说明和批准。

然而，这并不意味着事件管理是由不十分相干的系统开发人员来完成，然后就与被监控的系统一起发布到运营管理中，也不意味着一旦设计并得到批准，事件管理流程就稳定了。日常运行活动将定义其他的事件、优先级、告警和其他改进，这些都将通过持续改进流程反馈回服务战略和服务设计中。

（1）规范

规范定义了对配置项的监视内容及其影响的处理方式。规范中的一部分包含了一组需要制定的决策，另一部分则是执行这些决策的设计机制。

需要制定的决策包括：

• 需要监视什么？
• 需要进行哪类监视（例如主动或被动，性能或输出）？
• 何时生成事件？
• 需要在事件中传递哪类信息？
• 谁需要该信息？
• 需要设计的机制包括：
• 事件如何生成？
• 配置项的标准特性中是否已经具备事件生成机制？如果是，哪些将被使用？是否足够？还需要定制以包含更多信息吗？
• 哪些数据将用于构成事件记录？
• 事件是自动生成还是必须由CI轮询？
• 事件的记录和存储位置？
• 如何收集补充数据？

（2）错误消息

错误消息功能对所有组件都是十分重要的。尤其重要的是所有软件应用设计都应支持事件管理。这可能包括提供有意义的错误消息和代码，明确标明具体的故障点和最可能的原因。在这种情况下，新应用的测试应该包括对事件的生成是否准确进行测试。

（3）事件监测和告警机制

出色的事件管理流程还要包括设计和安装工具，用于过滤、关联和升级事件。关联引擎特别需要与规则和标准组合在一起，这些规则和标准能确定某类事件的重要性和响应行动。事件监测和告警机制的设计包括：

• 通过事件管理流程进行管理的所有业务流程及相关业务知识；
• 各配置项支持的服务级别管理要求；
• 配置项的支持责任人；
• 配置项正常和异常运行情况；
• 了解同类事件(有关同一配置项或多种类似配置项)的重要性；
• 有效支持配置项的所有信息；
• 有助于诊断配置项问题的信息；
• 熟悉故障优先级和分类代码，以便创建故障记录；
• 了解所有与受影响配置项互相依赖的配置项；
• 来自厂商或历史经验的已知错误。

1.1.3 故障管理

1.概述

故障管理包括中断或可能中断服务的任何故障，它可能是用户直接报告的故障，也可能是通过服务台提交或者通过事件管理与故障管理之间的工具接口而创建的故障。故障管理的目标是尽可能快地恢复到正常的服务运营，将故障对业务运营的负面影响减小到最低，并确保达到最好的服务质量和可用性水平。除了用户报告以及事件管理流程升级故障之外，故障还可能由技术人员报告和记录。因此，并不是所有的事件都会升级为故障进行处理，同时，也并不是所有的故障都是来自事件管理流程。事件一般主要是指由监控系统所产生的通知性或告警性信息，而故障的来源除了监控系统告警产生之外，还包括用户以及IT人员报告的故障。

2.故障处理模型

故障是指非计划内的IT服务中断，或者是IT服务质量下降。如果一个配置项出现故障而不影响业务，我们也视之为一个故障，比如磁盘镜像中的一块磁盘失效。在故障管理流程中，很多故障并不是全新的，而是一些重复的或者类似的故障。因此，定义一些“标准”的故障处理模型是很有意义的。

故障处理模型应包括以下内容：

• 处理故障应遵循的步骤；
• 这些步骤应遵循的时间顺序和相互依赖关系；
• 故障处理过程中的职责，即谁应该做什么；
• 活动完成的时间表和阈值；
• 升级程序，即应该联系谁以及何时进行升级；
• 任何必要的证据保留活动（尤其是有关安全或容量相关的故障）。

总而言之，故障处理模型就是一种预定义的、经过批准的标准操作步骤，采用该标准步骤可以处理特定故障类型。通过工具软件可以对这些故障处理模型进行管理，这样可以确保“标准”的故障在预定的时标内按照预定的路径进行处理。

重大故障的处理需要单独的、时间更短的和紧急度更高的处理程序。何谓“重大故障”需要事先进行明确的定义，或者将重大故障的直接映射到整体的故障优先级矩阵中，即通过该优先级映射矩阵确认的重大故障就可以通过“重大故障”子流程进行处理。

3.故障管理流程

故障管理流程是IT运维管理中使用频率最高的流程。明确定义故障管理过程的主要活动、形成标准的故障处理模型并将该故障处理模型整合到故障管理软件平台是目前实践中最常见的做法。图1-1-3展示了一个标准的故障管理流程。

（1）故障识别和记录

故障管理流程遵循的基本原则是“没有记录就无法统一跟踪和监控”。因此，确保所有的故障请求都按照统一的模板和规范进行记录是实现统一跟踪和控制的前提。因此，针对整个故障处理生命周期的所有相关信息都应该详细记录，这样既有助于服务台将故障快速地转移给其他支持人员进行处理，又能够保留完整的历史记录。基于以上预定的管理目标，可以设定详细的故障记录单的属性字段。

（2）分类、优先级和初步诊断

故障受理记录后，需要对故障进行分类、划分优先级并提供初步的诊断和支持。故障分类，初步记录的部分工作应该包括划分适当的故障分类代码。这对后续分析故障类型和发生频率非常重要，该方法也可用于问题管理、供应商管理和其他IT服务管理活动中。

记录故障的另一个重要方面就是确定和分配一个适当的优先级代码。优先级通常通过考虑故障的紧急度和影响度来确定。影响度通常是表示为受影响的用户数量。在某些情况下，单一用户的服务中断也可能对业务产生重大影响——这取决于受影响的用户所从事的业务以及用户的关键度级别。

初步诊断，服务台人员在受理故障请求后，应根据现有的故障信息展开初步诊断和支持。如果用户通过电话方式报告故障，诊断工作通常在此时就开始进行，努力发现故障的全部症状，准确判断出现的问题以及如何纠正它。正是在这个阶段，诊断脚本和已知错误信息才会发挥重要作用，能够帮助尽快做出准确诊断。

如果可能，当用户在线时服务台坐席人员就应该解决这个故障，如果成功地解决，则可以现场关闭该故障。如果服务台坐席人员不能在用户在线时解决故障，但服务台坐席人员认为有可能在规定的时间内无须其他的支持小组协助下能够解决这个故障，则坐席人员应告知用户将要进行的工作，并向用户提供故障编号，然后尝试寻找解决方案。

故障升级，指在某一级支持人员无法在规定的时间内完成故障解决时，应当采取故障转移或者向上汇报以争取资源的方式确保故障得到进一步的解决。故障升级的形式包括职能性升级和管理性升级两种。

（3）调查与诊断

在一些用户请求中，用户只是查询某个信息，则服务台应能非常快地响应并解决该服务请求。但如果报告一项故障或者错误，则这种故障的处理通常需要进行专业的调查和诊断。参与到故障处理的每个支持组都将调查和诊断问题所在，所有这些活动（包括为了解决和重现此故障的任何活动的细节）都应该记录到故障记录中，以便所有活动的完整的历史记录得到全面的维护。

（4）解决与恢复

发现潜在的解决方案后，要进行测试和应用。采取哪些行动、牵涉到哪些人，不同的故障其解决和恢复活动可能有所不同。不管采取什么行动、由谁进行，故障记录必须按照所有相关信息和细节进行更新，以便维护完整的历史记录。在故障处理完成以后，故障处理小组应该将故障反馈给服务台进行关闭。通常故障的解决方式可以采用解决方案或临时方案来恢复服务，或者发起变更请求的方式来解决故障。

（5）故障关闭

在故障解决和恢复行动完成后，服务台应向用户核实确认故障是否已被完全解决，并了解用户对本次故障解决过程的满意程度。故障的关闭动作通常是由服务台来完成，但是根据实际需要有的时候也可以采用自动关闭或者由用户来关闭的方式来关闭故障。

1.1.4 服务请求履行

1.概述

“服务请求”是对用户向IT部门提出的各种需求的通用描述。这些需求中有很多实际上是一些微型的变更（比如申请修改密码、申请安装附加的应用软件和申请重新部署桌面设备的某些配件），具有低风险、经常发生、低成本等特点。有些甚至仅仅只是查询一些信息。由于服务请求的数量较大、风险较低，且服务请求的实施过程相对简单，因此针对服务请求制定独立的流程进行处理。

2.任务目标

服务请求履行的目的是：

• 为用户提供请求和接受服务的渠道，这些服务流程是预定义的、预授权的；
• 为用户和客户提供关于服务可用性和获取服务程序的信息；
• 提供标准服务的组成部分，比如许可证和软件介质；
• 帮助处理一般信息、抱怨和评价(注释、评论、评价、意见反馈等)。

服务请求履行过程中受理用户所提出的所有服务请求，具体包括以下几种类型：

• 标准变更请求；
• 信息查询请求；
• 投诉和抱怨；
• 意见反馈。

3. 流程活动

服务请求履行流程主要包括以下几项主要的活动。

（1）菜单选择

服务请求履行为自助式服务提供了很好的机会，用户可以通过使用服务管理工具自己生成服务请求。

（2）财务审批

在处理服务请求时，一个重要的步骤是财务审批。不管商务上如何安排，多数服务请求都需要某种形式的费用。服务请求履行的费用项目必须首先设立。对于“标准服务”可以采用固定价格方式，这种服务请求的预先批准，可以作为组织整体年度财务管理的一部分。

（3）其他审批

在有些情况下，可能需要进一步的审批，比如必须遵从某些法规或更广泛的业务审批。服务请求必须能够定义和检查所需要的审批环节。

（4）履行

实际上，如何履行服务请求要视服务请求本身而定。有些简单的请求可以由服务台作为一线支持来完成，而其他的请求就需要转交给专家小组或供应商来处理，再或者是一些组织有专业的履行小组或外包部分服务请求履行活动给第三方服务商。不管由谁来负责履行服务请求，服务台应该监视和跟进进度并及时通知用户。

（5）关闭

服务请求的处理过程也必须进行闭环控制。因此，当服务请求处理完成时，必须返回服务台进行确认，服务台将检查用户对处理结果是否满意，服务台根据客户满意情况决定是否应关闭该服务请求。

1.1.5 问题管理

1.概述

有效地实施故障管理和服务请求履行流程，能够将IT组织的IT服务从“无序的被动维护”提升至“有序的被动维护”，但仍然没有实现“预防性的主动维护”，整个团队还只是在认真而忙碌地做着“正确的事”。要想实现主动式维护，并且确保整个团队在“正确地做事”，还必须在“治标”的基础上进行“治本”。问题管理的引入，可以有效地实现这个目标。问题管理的主要目标是预防问题的产生及由此引发的故障，消除重复出现的故障，并对不能预防的故障尽量降低其对业务的影响。问题管理针对所有的IT服务要素进行问题识别、根源分析、错误评估和解决方案制定。一般而言， 我们可以认为问题管理的范围是故障管理、服务请求履行、变更管理、配置管理等流程的管理范围的集合，也就是说，凡是有可能对IT服务的质量产生潜在影响的因素都可以纳入问题管理的范围。

2.问题管理

问题管理是负责对问题进行全生命周期管理的流程，包括识别问题、查找问题根源、评估错误和制定问题解决方案等主要活动。在实际工作中，很多人经常将“故障”与“问题”这两个概念混淆。事实上，故障和问题之间虽然有很紧密的联系，但这两个概念是完全不同的。故障和问题是看待同一件“事情”的两个不同的视角。故障是从“治标”的角度对“事情”进行处理，确保“当前的”业务影响最小化；而问题则是从“治本”的角度对“事情”进行处理，确保“长远的”业务影响最小化。如针对服务器宕机这件事情，故障管理首先要考虑的是通过何种方式确保服务恢复，而问题管理则需要考虑服务器为什么会宕机，其根本原因是什么，用何种方法可以从根本上防止此类故障再次发生。

3.已知错误数据库

已知错误数据库（KEDB，Known Error Database）是用来保存故障和问题的症状细节以及临时方案和解决方案等信息的问题管理数据库。通过利用该数据库，可以确保故障再次发生时通过采用现成的临时方案或者解决方案而快速解决故障。

4.流程活动

在ITILv3的知识体系中，问题管理主要由以下两部分组成：

• 被动问题管理，通常作为服务运营的一部分来处理；
• 主动问题管理，在服务运营中启动，但通常在CSI流程中推动。

被动或者主动问题管理是就问题识别环节而言的，对于识别后的问题，需要采取一套标准的流程进行处理，这个标准的问题处理流程被称之为“问题处理模型”，如图1-1-4显示了问题管理通用流程框架。

（1）问题识别和记录

问题识别和记录（创建问题单）是问题管理流程得以有效启动的前提。因此，问题的识别和记录对于问题管理流程来说是至关重要的。通常来说，问题经理是所有问题的所有者，但这并不意味着所有的问题都必须由问题经理来识别和记录。

（2）问题分类和优先级

与故障管理一样，我们同样需要对问题进行分类并划定其优先级。就分类来说，建议在问题管理中采用与故障管理相同或类似的分类体系和分类编码。

就优先级的划分来说，问题管理与故障管理的优先级矩阵是不一样的。故障管理是看点，而问题管理是看面。有时候，一个很紧急的故障可能会享受很高的优先级，但其背后对应的问题却未必有很高的优先级。总体上来说，故障优先级的划定更多地考虑紧急度，而问题优先级的确定更多地考虑影响度。但有一点是相同的， 那就是，问题管理也可以通过事先定义一个优先级映射矩阵来明确问题优先级的划分。

（3）问题调查和诊断

需要进行调查以诊断问题的根本原因，调查的速度和性质会随问题的影响度和紧急度而有所不同。配置管理系统（CMS，Configuration Management System）可以帮助确定影响程度并帮助查明和诊断故障的确切部位。如果该问题曾经出现过，还要访问KEDB并使用问题匹配技术查找解决方案。

（4）找到替代措施并创建已知错误记录

有时候，虽然问题的根源原因已经十分明了，但出于技术、成本、时机等方面的考虑，可能不得不采用临时性的替代方案来解决由该问题引发的故障。但是，继续寻找永久性解决方案的工作是很重要的。如果问题的根本原因已经查明，且找到了临时性的替代方案，则问题的状态应转为“已知错误”或另外创建一条“已知错误”记录。

（5）问题解决

问题的解决方案分为两种情形一种是无需提交变更请求，则只需要根据组织的业务要求，综合考虑技术、成本、业务、时机等因素实施选定的解决方案以彻底消除问题。另外一种情形，如果问题的解决方案涉及对IT基础架构的变更，则应根据组织确定的变更管理政策提出变更请求。此时，解决方案的实施被纳入了变更管理的控制。

（6）问题关闭

当问题解决方案实施完成并通过实施评审之后，问题记录可以被关闭。在关闭问题记录之前，必须确保所有的文档记录被更新，相关替代方案或解决方案被提交至知识库。

（7）重大问题回顾

对于重大问题，在问题关闭一段时间后，应当进行评审和回顾。重大问题回顾应当重点考虑以下事项：

• 哪些事情做对了；
• 哪些事情做错了；
• 什么事情将来可以做得更好；
• 如何防止再次发生；
• 是否存在第三方责任，是否需要采取后续的行动。

这种评审可以作为员工培训和意识教育的一部分，任何经验教训都可以记录到适当的过程、工作指引、诊断脚本和已知错误记录中。问题经理应该推动这些工作并记录所同意采取的行动内容。

1.1.6 访问管理

1.概述

在服务请求履行、故障管理、变更管理、发布与部署管理、安全管理等流程中，都不可避免地涉及对相关系统、数据的访问权限问题。为了确保信息安全和其他流程的有效、顺畅运作，将组织中与权限申请和授权相关的操作整合成一个规范、正式的流程是非常必要的。服务运营模块中的访问管理流程恰好体现了这一意图。

访问管理的目标是为用户使用一项或一组服务进行授权，它是在信息安全管理和可用性管理中制定的策略和行动的具体执行。

访问管理是可用性管理和信息安全管理在确保服务开通和权限控制方面的具体执行，可支持组织有效管理数据和知识产权，以确保其管理机密性、可用性和完整性。访问管理只是确保用户有权限使用某一项或多项服务，但不能保证该服务在所有规定时间内均是可用的，这需要可用性管理的支持。访问管理流程通常由技术管理和应用管理职能执行，通常并不设立专门的岗位或职能，但可能在IT运营管理或服务台中设立一个控制协调点。访问管理通常由请求履行流程触发，有关权限申请的请求也是作为一种服务请求统一由服务台负责受理。

2.流程活动

虽然权限申请者最终被允许获取的权限各有不同，不同的授权事项其授权者也各不相司，但是定义统一的权限处理模型却是可能的。

一个标准的访问（权限）管理流程包括以下六项主要的活动。

（1）请求访问

在IT服务管理中，访问权限可以通过以下多种机制进行申请：

• 标准请求：通常由人力资源部门在员工入职、提拔、调动或离职时提出；
• 变更请求：实施变更过程中涉及的权限申请均由变更请求触发权限申请请求；
• 通过服务请求履行系统提交的服务请求（权限请求）；
• 执行预授权脚本或选项（比如在需要时从测试服务器上下载一个应用）。

权限申请的规则通常作为服务目录的一部分记录在文档中。

（2）验证

访问管理需要对每个访问IT服务的请求进行验证，这种验证主要侧重于以下两个方面，第一请求访问的用户身份真实准确，第二服务请求合法。针对第一种验证，往往由用户提供用户名、口令或其他身份验证信息。依照组织的安全策略，用户名和口令通常可以作为一个用户的合法证明。

针对第二种验证，除了验证身份信息外，还需要进行如下几方面的验证：

• 人力资源部门确认员工的入职、转岗、晋升和离职；
• 相关经理（在流程中定义的）的授权；
• 符合公司定义的信息安全政策。

（3）授予权限

访问管理本身并不对所有的访问权限做出决定，访问管理主要负责执行在服务战略和服务设计期间定义的策略和规则。一旦用户被验证通过，访问管理就可以为用户提供所申请服务的权限。

（4）监视身份状态

当用户被授予某项服务的使用权限后，访问管理需要及时监控用户的身份状态，并及时调整其权限。权限管理工具应该能够支持用户身份变化而导致的权限调整。

（5）记录和跟踪访问权限

访问管理不仅负责响应访问请求，而且还要负责保证这些权限被适当地（合法地）使用。因此，访问管理需要保留用户使用服务期间的登录记录并跟踪访问权限的使用情况，确保用户的使用权限不被滥用。

（6）删除或限制权限

在用户的使用权限到期或者组织做出决定需要终止或者限制某个用户的使用权限时，访问管理负责删除或限制该用户的使用权限。

项目实施

以“重庆神通网络服务公司”ITIL项目实施为例讲解ITIL实施环节相关的重点流程的建设和实施方案，加深对不同ITIL服务运营流程和职能概念的理解和实践体验。

需要完成的任务：

（1）理解ITIL项目服务运营职能中服务台的实施要素。

（2）理解ITIL项目服务运营流程中事件管理、问题管理的实施要素。

1.2 任务：“重庆神通网络服务有限公司”ITIL项目方案

1.2.1 案例背景

重庆神通网络服务公司是一家主营通信网络建设和维护的公司，主营业务是为电信、移动和联通等公司提供网络建设、维护的外包服务，同时也为其他企业提供网络和网站建设等服务。公司有员工500人左右，分为综合办公室、财务管理部、网络建设部、网络开发部、客户服务部、市场部等部门组成。公司的业务高度依赖于IT，公司设置维护支撑小组，直接面向客户的窗口部门。各个维护支撑小组分布在不同的部门中，每个维护支撑组负责其中一个或多个系统的维护及技术支撑，目前全职和兼职从事该项工作的人数达到180人左右。

ITIL项目实施之前，公司运营流程管理存在以下问题。

随着公司业务的不断壮大与发展，客户服务请求事件数量的不断增多，给公司IT维护支撑小组部门带来了极大工作量，由于缺乏明确的角色定义和职责划分，一旦发生事故，IT维护支撑小组内部人员不是像“救火队员”一样四处去“灭火”，就是对事故处理责任进行相互推托，造成事故处理效率非常低。同时，公司IT部门还缺乏良好的运营绩效考核机制，组织上评价IT部门及人员的工作绩效缺少准确参照依据。公司应用工具固化ITIL服务管理流程，实现流程自动化，从而达到快速提升整体服务能力的目标要求。本节重点介绍部分ITIL服务运营流程和职能的建设改造内容。

通过以上几个流程的整合，提高IT Service的服务水平，降低系统的运营成本。客服响应流程、内部故障发现及处理流程和紧急故障排查及系统恢复流程、日常工作及服务流程，这几个流程是根据实际情况，遵循ITIL标准实施的整合。

1.2.2 服务台构建实践

服务台作为一项职能，它的建立可以实现信息流集中统一控制。

在构建服务台时先明确以下三点。

（1）服务台接受客户信息的方式。有电话、邮件、Web、工具平台、QQ、微信等方式。确定服务台接受信息的来源是将来确定服务台服务方式和控制服务质量的源头之举，在实际工作中应根据公司的工作习惯灵活选择。

（2）确定服务台在公司内部位置。有运维层、IT部门层和公司层三种选择，根据神通公司的业务性质选择IT部门层的服务台，对外是信息化工作窗口，对内是工作调度指挥中心。

（3）确定服务的提供方式，有远程指导或现场服务的选择。

服务台人员素质采用混合式，非技能型+技能型混合构建。为了规范服务台运作流程，建立服务台人员行为规范，从人员的工作时间、仪表、着装、办公秩序、语言等多维度要求。根据服务需求呼叫规律合理配置服务台人员，并规范工作时间、交接班制度以及职责划分。为了提高服务台电话接听质量和增强电话服务质量的稳定性，编写服务台电话接听规范是非常有必要的，通常来说，要求非技能型服务台90%的用语应该来源于电话接听规范，技能型服务台除了事件排查询问内容外，其他用语均应出自电话接听规范。表1-1提供了一份公司电话接听规范的示例。服务台根据工作内容需要填写相应的服务报告单。

1.2.3 事件管理实践

服务台搭建好了以后，具备了相应的人员和设备工具，要想保证它能高效的运作就需要做好事件管理流程。事件管理流程中如何解决派单，如何去快速解决事件从而降低对业务的影响呢？这就需要从提高工作效率和过程管控着手了。

1.时效控制

（1）如何快速记录

在事件管理中要实现快速的事件记录就需要编制一个简单又信息完备的事件记录单。表1-2是公司编制的IT运维事件表示例。

为保证事件单的填写既快捷又准确，需要遵循以下基本原则：

“能做选择题，就不做填空题；能做填空题不做论述题；实在万不得已要做论述题的，也应当明确填写要素和规范”。

除此之外，编制事件单还需要注意以下内容：

• 确定编码规则，便于统计和查找；
• 根据管理需要确定需要的填写内容；
• 根据实际工作情况确定相关填写人员；
• 确定关键的时间点，例如:转接时间、响应时间、解决时间、完成时间等；
• 确定保存时效。

编制一个有效的事件单可以大大提高记录的速度，但真正要提高记录速度需要的是运维工具平台的应用和配置管理数据的配合，做到用户电话一响，服务台人员可以看到相关的用户信息和以往的维护记录。

（2）如何快速分派

快速分派记录的相关服务请求是接下来保证工作效率的关键，需要根据事件分类表中界定的事件类别与对应支持小组之间的映射关系确定派单对象。表1-3提供了一份事件分类表的示例。

2.升级管理

按照ITIL理论，事件管理中的升级分为职能性升级和结构性升级。它们实际上是互为补充的关系。职能性升级是指由于当前支持人员或小组的技术水平不够而需要升级至其他技能水平更高的人员或小组的升级方式。结构性升级是指需要更高权限级别的管理人员介入从而确保更充足的资源的升级方式。升级政策的目的是，对于不同优先级的事件或问题，确保分配到合适的资源来解决问题。为了达到这个目的，需要定义事件升级的时间框架。当达到某个时间点时，如事件还未解决，将触发相应的事件升级路径。表1-4提供了一份事件升级时间框架的示例。

3.事件处理时限

在时间管理中，通常对不同级别的事件，需要约定相应的处理时限。表1-5提供了一份公司事件分类处理时限表示例。

此表中需详细描述重大事件的表现形式，并明确各环节的处理时间和相关通知时间。

1.2.4 问题管理实践

1.问题管理流程构建模式

问题管理流程构建应该根据IT组织规模大小区别设计，通常确定一个IT组织的问题管理流程的模式应该从以下几个因素来考虑：

• IT组织运维人员数量；
• IT基础架构的数量；
• IT基础架构的稳定性（质量以及保修范围等）；
• 重复事件的数量。

根据神通公司IT运维规模人数，采用小规模组织问题管理构建模式。这种问题管理模式适用于小型的IT组织，主要做法是，每个月（或根据实际情况调整为周或季度）召开一次运行工作例会（通常和每个月的例行工作会议结合，不需要单独召开）。会议前要求每个专业领域的负责人（通常每个组织中都会有某一方面的资深人员，可能没有具体职位，但在他负责的领域是组织中的权威）根据每个月的工作记录（这个记录可以包括事件记录、工作日志等）来汇总他负责领域的重要性为前三位的问题，并将这些问题在会议上讨论确定后在下一个工作周期中作为计划性工作去调查处理，并找到根本的解决方案，然后推动实施。依此类推，循序渐进，实际上这就体现了ITIL的核心理念持续更新，持续改善。这种做法在小型的IT组织中非常有效，而且能起到立竿见影的效果。

2.流程实施细节

确定了问题管理的构建模式之后，还应注意以下流程实施的细节。

（1）日健康检查

通过每日检查、分析业务应用系统的运行情况和趋势，主动发现问题以预防重大事件的发生和消除系统潜在隐患。

（2）问题管理或应用服务人员

• 负责对业务应用系统(或指定关键系统)进行每日健康检查和分析，编写并发布健康检查报告；
• 负责对健康检查发现的问题进行持续跟踪处理，向组内成员和其他相关人员汇报问题解决的进展，记录健康检查问题跟踪表。

（3）问题经理或应用服务负责人

• 负责不断完善健康检查方法；
• 关注健康检查发现的所有问题及其解决进展。

通过定期的健康检查来实现问题分析和主动问题预防。明确问题管理角色与职责，定期开展问题管理报告例会。

3.主动问题管理

通过从整体上对已出现的和可能出现的问题的分析，我们可以确立哪个或哪类问题是“真正”需要重点关注和优先解决的。比如，当有些故障出现次数多但影响不大，而有些故障出现次数少但影响巨大且解决这类故障能带来更好的效益时，显然应该优先解决后者。因此，我们可以考虑给每个故障一个“影响指数”，指数大小根据以下几点确定：

• 故障出现次数；
• 受影响的客户数；
• 解决故障所需时间和成本；
• 业务损失。

确定关键问题后，故障管理小组就采取行动解决故障或预防其发生，这些行动包括：

• 提交变更请求（RFC）；
• 提交有关测试、规程、培训和文档方面的反馈信息；
• 进行客户教育和培训；
• 教育和培训服务支持人员；
• 确保问题管理 和故障管理规程得到遵守；
• 改进流程和程序。

主动问题管理的采用的具体手段包括：

• 巡检发现；
• 工作日志分析；
• 事件管理数据分析；
• 运行会议讨论；
• 配置管理数据分析；
• 用户回访反馈分析。

4.知识管理

IT服务部门不仅需要在事件快速匹配、事件快速恢复等方面能够得到及时、有效的指导，而且对于疑难杂症也希望能够得到及时、高质量的技术支持。而后者取决于问题转化为已知错误，已知错误转化为已知方案的速度和已有的知识积累。可以说，建立问题知识库，更像是给了问题管理一把剖析问题的利刃。

（1）构建知识库原则

知识库通常分为两大部分，一部分是面向运维人员的知识库，形式以SOP模板为主，这部分是知识库的主体；另一部分是面向用户的知识库，主要是为信息部IT用户提供基本的IT知识介绍，建议其形式以Flash动画和视频介绍为主。

事件管理和问题管理中发现的所有解决方案和应急措施都应当通过知识管理进入知识库。

知识条目的来源为知识编写人的主动提交和用户根据实际工作需要提出的知识条目需求。知识条目的编写统一由知识编写人完成，其审核则由知识管理员和知识编写人共同完成。

用户在使用知识条目后，需要对知识条目进行评价。知识管理员则需定期根据知识条目的使用评价情况对知识条目进行相应的维护。

每月应对知识条目进行评审，并产生相应的报表，以改进知识管理流程。对长期未使用的知识条目应做出冻结或休眠处理。

（2）知识库条目的录入及维护

为便于后期的查询和维护，所有知识条目的录入及维护必须遵循以下基本原则：

• 所有编写的知识条目格式要按照SOP模板统一记录和查询；
• 知识条目的框架结构初期定为半年修订次，成熟后每3~5年修订次；
• 由知识管理员维护知识条目的分类，需保证知识条目的分类统一，查询方式统一。

本章小结

本章主要介绍了ITIL服务运营流程和职能的概念和设计流程。文中通过重庆神通网络服务有限公司ITSM的建设项目方案，重点介绍服务台、事件管理、问题管理的实施要素和方法，以加深读者对ITIL中涉及的核心流程和职能的理解。

本章习题

一、单项选择题

1.发生一个严重事故，指派的解决小组不能在约定时间内解决这个事故，事故管理经理被召集。（ ）升级形式可以描述上面的事件发生顺序？

A.正式升级

B.功能性升级

C.结构性升级

D.运作升级

2.（ ）事故应该被服务台记录？

A.仅记录未解决事故

B.仅来自真诚的客户

C.除简单的询问之外的所有事故

D.所有事故

3.下列（ ）项说法不正确？

A.当一个主要事故发生时，可能会涉及到问题管理

B.服务台对问题的监控贯穿它的整个生命周期

C.问题管理负责管理问题的决议

D.问题管理负责错误控制。

4.问题管理如何支持服务台的行动？（ ）

A.问题管理为服务台解决严重事故

B.问题管理研究所有服务台解决的事故

C.问题管理减轻服务台向用户传达决议的压力

D.问题管理使服务台可以利用已知错误的信息

5.事故数据的趋势分析表明超过30%的事故有规律地重复发生。下列（ ）项行动最有助于削减有规律重复发生事故的比率？

A.一份向董事会解释问题管理重要性的陈述

B.执行问题管理流程

C.选择-种合适的工具更准确地记录所有事故

D.给客户介绍专一的服务台号码，这样客户知道和谁联系

6.一个用户向服务台投诉，当使用一个特殊的应用程序时，一个错误频繁出现，引起网络连接中断。ITIL的（ ）项流程负责跟踪这个导致错误的原因。

A.可用性管理

B.事故管理

C.问题管理

D.发布管理

7.（ ）是主动问题管理的范围？

A.处理变更请求

B.履行趋势分析并识别潜在的事故和问题

C.跟踪调查所有的事故和中断

D.最小化因变更IT环境导致的服务中断

8.一位最终用户的个人电脑崩溃了，这不是他第一次碰到他的电脑出现这样的问题，它在三个月前也崩溃过。用户向服务台报告了这个情况。请问这里发生了什么？（ ）

A.一个事故

B.一个已知错误

C.一个问题

D.一个变更请求

9.一位计算机操作人员注意到他的全部磁盘空间马上就要用完了。这种情况必须报告给ITIL的（ ）个流程？

A.可用性管理

B.能力管理

C.变更管理

D.事故管理

10.下列（ ）项是问题管理流程中最后的活动？

A.将任何与变更请求相关的提交给变更管理。

B.记录问题

C.完成所有问题管理活动，结束问题记录

D.开始回顾问题及其影响

参考文献

1 陈宏峰、刘亿舟主编. 中国IT服务管理指南——理论篇M，北京：北京大学出版社，2019.1

2 Jan van Bon 主编，章斌译. 基于ITIL服务管理基础篇M，北京：清华大学出版社，2007.8

3 程栋、刘亿舟主编. 中国IT服务管理指南——实践篇M，北京：北京大学出版社，2019.1