| ITIL
V3 服务运营卷包含了在服务运营管理方面的实践。它对如何达到服务支持和交付的效果和效率，以确保客户与服务供应商的价值提供了指导。战略目标最终需要通过服
务运营来实现，因此，它是一种非常重要的能力。它对如何在设计、规模和服务水平变化的情况下，如何保持服务运营稳定性提供指导。服务运营有两种主要的控
制：被动的和主动的。该卷从组织详细的流程指南、方法和工具使用上描述了这两种控制。
服务运营的流程包括：
1.事件管理流程
2.事故管理流程
3.服务请求流程
4.问题管理流程
5.访问管理流程
服务运营的组织构成包括：
1.服务台
2.技术管理
3.运营管理
4.应用管理
服务运营有5个主要流程：
1.事件管理
2.事故管理
3.需求实现
4.问题管理
5.访问管理
6.事件管理
事件(Event)可被定义为 任何可察觉和可识别的，对 IT 基础设施管理或者
IT 服务造成影响和背离的重要现象。事件通常由 IT 服务、配置项或者监控工具产生。
事件管理流程的目标是为了确保正常运营而进行的对 IT 基础设施中发生的所有事件进行监控的流程，事件管理也负责对例外情况进行侦测并进行必要的升级。
有效的服务运营需要对IT 设施运行状态的及时掌控和任何对服务偏移的识别，这依赖于有效的监控管理系统。
事件管理流程用于需要被控制和可自动化的服务管理的各个方面。件管理的监控范围包括配置项，环境条件（如，机房烟火的监测）
，软许可和使用情况监控，安全及标准活动（如，对应用或对服务器操作行跟踪） 。
事件管理路程图
事故管理
事故 ( Incident ) 是指对一项IT服务或一项IT服 务质量减少的非计划中断。
事故管理流程的主要目标是根据服务级别协议的要求，在尽可能小地影响客户和用户业务的情况下尽可能快地将服务恢复到“正常状态”
。
事故管理流程图
事故管理流程：包括对服务引起中断或可能中断的事件的管理。这包括了用户通过服务台或通过从事件管理的监控工具直接提交的事故。事故由技术员工报告和记
录，但并不是所有的事件都是事故，许多的事件并不与中断相关，而仅是正常运营指标或一些简单的信息。尽管事故和服务请求都报告给服务台，但两者并不相同，
服务请求并不代表协议服务的中断，而是满足客户需要的方法，当然也可能是SLA中协议目标。
服务请求
该流程主要针对“服务请求”类事件，指的是IT 部门向用户提供的一系列不同种类的普通的需求，这些请求大部分可以分为几类，一类是低风险、经常发生且成
本低的微小变更；比如重置口令，对某个特殊的工作站进行额外软件安装的请求等；另一类为信息咨询请求。因为这些请求是经常发生、低风险，因而需要采取一个
单独的流程来进行管理，而不是混杂于正常的事件和变更管理流程，变成一种累赘和障碍。
请求实现流程的主要目标是：
1.对于某些预定义的申请和需求，为用户提供一个渠道来获得这些标 准服务；
2.为客户和用户提供服务请求管理流程服务和程序信息；
3.获得和交付请求的标准服务组件；
4.协助处理一般信息、抱怨或者投诉。
请求的实现需要首先了解请求的内容。一个典型的服务请求管理流程主要经历如下几个活动：
1.菜单选择:只提供菜单中列出的服务
2.财务审批:如果该服务请求的实现涉及到成本问题，则需要 走财务审批环节
3.其他审批:在某些特殊情况下，需要更进一步的审批，比如 业务审批；
1)请求实现:服务请求的满足取决于该请求的性质，某些简单的服务请求可能直接
2)由服务台一线支持人员执行，而其他的可能需要更进一步交给专家团队或者供
3)应商进来处理和满足。在某些 组织，可能需要组建专门的请求实现团队或者外包给第三方供应商；
4.请求关闭:用户的服务请求实现后，必须反馈给服务台来关 闭。服务台在关闭前可能发起客户回访和满意度调查并输出。
服务请求流程图
问题管理
问题：是一个或多个不知原因的事件。
问题管理流程的主要目标是预防问题和事故的再次发生，并将未能解决的事故的影响降低到最小。
事故管理关注解决事件的速度。
问题管理强调找事件出根源，定制解决方案预防再次发生。
问题管理与知识管理，以及诸如已知错误数据库等工具有着紧密联系
问题管理流程图
问题管理流程由两个主要类型的流程：
1.被动问题管理是服务运营通常执行部分
2.主动问题管理是由服务运营发起的，但通常是由服务改进驱动的
指标
下列指标应该用来判断问题管理有效性和效率：
一段期间问题总数量
1.百分比的问题，解决的SLA目标（及百分比是没有）
2.超出目标解决时间问题的数 目。（用百分比表示）
3.未关闭问题数量和发展趋势（静态，减少或增加）
4.处理问题的平均成本
5.问题的数目（打开和关闭和积压）
6.有多少已知错误添加到已知错误数据库（KEDB）
7.已知错误数据库（KEDB）准确程度的百分比
8.主要问题评价顺利完成的百分比，并列出明细分类：处理时间，影响的严重性，紧急度和优先级。
访问管理
访问管理流程 是授权 给合适的用户合理的使用服务，同时也限制未授权用户的访问。访问管理也被称为权限管理或者身份管理。
访问管理流程提供用户权力能够使用一项或一组服务。因而，它是对安全和可用性管理定义的政策和行动的执行。
访问管理流程是可用性和信息安全管理有效地执行。访问管理不是一个单独的职能，所有的技术和应用程序管理职能都应该执行该流程。为了能对访问管理的协调有
一个单一控制点，经常由运作管理或服务台来控制。访问管理也能由服务台的服务请求发起。
访问管理流程的主要活动如下：
1.访问请求
2.验证：
3.权限提供
4.监控身份状态
5.记录和跟踪访问
6.移除或限制权限
服务台(Service Desk)在用户支持方面扮演了重要的角色。一个成熟的服务台可作为其他IT
部门的前台，能够在无需联系专家的情况下处理一些客户询问。对于用户来说，服务台为他们提供了联系IT 部门的单一联系点，从而可以确保他们能找到合适的支持人员来帮助解决其问题或请求。换句话说，用户再也不需要不停地寻找能够解决其问题的支持人员。通常，
服务台也负责跟踪来自IT 部门内部的呼叫。
服务台目标
目标：尽快恢复用户正常服务
1.记录事件、服务请求、分配优先级
2.提供一线调查和诊断
3.解决事件、服务请求
4.向用户通报进展
5.关闭解决事件、服务请求及其他请求
6.开展用户满意度调查
7.更新CMS
服务台结构
服务台结构有多种选择。常见的方式包括：
1.集中式服务台：作为所有用户的单一联系点，可能还单独设立了一个服务台来处理用户在业务应用系统方面的问题。
2.本地式：服务台分布在多个地方。通常，将服务台划分为多个本地服务台将会导致更加难以管理。
3.虚拟式服务台：并没有实质性的位置，这是由于使用了通信技术。
这里具体讨论集中式服务台。集中式服务台是企业最实用最多的一种类型。
集中式服务台结构图
这种方式可以与运营组织的其他功能组织紧密结合使用以方便服务台和运营管理(生产、运营)之间的直接沟通，这里所指的生产(Production)包括网
络管理、计算机运营等。这种直接沟通可以保证在出现服务台不能立即解决错误的情况下仍然能够作出快速响应。
服务台角色
1.服务台经理
2.服务台主管
3.服务台支持
4.超级用户
服务台对技术要求
1.电话：
自动呼叫分配系统
电脑电话接口系统：自动从CMS记录中识别呼叫者和调用详细信息
VOPI：降低国际和远程用户通讯成本
统计软件：统计收到的号码、响应时间、呼叫处理率、呼叫失败率、平均话时间
2.支持工具
已知错误数据库
诊断脚本
网页自助界面
远程工具
3.ITSM工具的IT服务连续性计划
服务台设立时需要考虑的几个方面
1.客户服务的期望
2.业务需求，如预算，呼叫响应时间等
3.大小，相对年龄，设计和复杂的IT基础设施和服务目录 - 例如，事故数量和类型，定制的程度相比，标准的现成软件部署等
4.支持的客户和用户数量，及其他如有关的因素： 语言种类、技能水平
5.事件和服务请求类型（和适当的RFC种）：各类型呼叫所需的时间期限；内部或外部的专业知识要求
；事故、服务请求的数量和类型
6.满足需求所要提供的支持，包括： 时间范围、非工作时间支持、支持时区、现场支持、移动的时间与地点、工作时间模式、服务等级目标
7.服务台反应类型：电话； E-mail/fax/voice邮件/视频；物理席位；在线访问/控制
8.训练等级
9.现有技术的支持（如电话系统，远程支持工具等）
10.工作人员的现有技能水平
服务台人员所应具备的技能水平
关于所需的技能水平决定往往是由目标；解决时间；复杂性和业务的代价。一般来说，目标时间越短，成本更高，因为需要更多的资源。可以通过提供有效
的基础知识；诊断脚本和集成支持工具；培训和提高认识，使第一线解决率逐步增加。
服务台人员应具备以下技能：
1.人际技巧，如电话技巧，沟通技巧，积极倾听和客户服务培训。
2.商业意识：该组织的业务领域，驱动，结构，优先事项等具体知识
3.服务意识：对企业关键IT服务
4.技术认识（和更深入的技术培训到适当的水平，这取决于寻求解决问题的比率）
5.提供的支持程度而定，一些诊断技能
6.支持工具和技术
7.意识培训和新系统上线前培训
8.程序和流程
9.打字技能
服务台指标
应对服务台建立衡量指标来定期考核服务台的工作效率与质量如何正确的选择考核指标
指标包括：
一线解决率： 1)服务台第一次接触得到解决的比率
2)服务台一线单独解决比率
3)一线与二线联合解决的比率
1.一线解决事件平均时长
2.事件升级平均时长
3.服务台处理事件平均成本
服务台费用/受理数量计算受理成本。但不能反应不同类型事件受理的成本。可用于规划服务台总费用与总受理时间计算通话成本。
4.SLA或客户期望时间内解决事件比率
5.审查、关闭已解决呼叫的平均时长
6.日或周呼叫接通失败的数量与平均通话量来决定员工数量
总结与思考
问题:服务台受理数量上升，是工作存在不稳定性，还是服务台受到认可使用用户上升。在选择指标时不应单方面的去考虑问题。
关注：应关注服务台一线人员培训和流失的问题。
服务运营组织结构
1.服务台
2.技术管理
3.IT运营控制
4.应用管理
运营组织结构图
技术管理
技术管理：提供技术和IT基础设施管理的组织，部门或团队。
目标：帮助规划，实施和维持一个稳定的基础技术设施，以支持该组织的业务流程。
技术管理活动:
1.识别知识和经营管理IT设施和提供IT服务所需的专业知识
2.扩大服务设计细节，并操作评估新的技术完善服务
文档能力，用于培训及技术储备
制定培训方案
为客户、服务台和其他群体设计并提供培训
招聘、外包内部组织无法开发或无充足人员执行的技术管理活动
购买自身无法实现的技术
在服务设计阶段参与新的架构、技术的定义和设计
研究和制定解决方案用于扩大服务范围或加大IT操作自动化来降低成本提高IT服务水平
参与设计和建立新的服务及对服务的升级、整合、转移等工作
预测可用性及容量管理所要的数据
协助风险评估，确定关键业务及BIA
设计并测试IT服务的功能、性能、管理能力
参与供应商管理
定义和管理事件管理标准及工具
技术管理部门或团队是事故管理不可或缺的。为其提供二线支持
为问题管理提供资源。诊断解决问题
变更、发布、配置管理中需要依靠技术管理
技术管理还参与服务改进和完善
技术管理保管技术知识和专业技能，确保确保文件和系统式最新和最适用的
更新技术和服务的能力
协助IT财务管理。确定技术及人力资源成本
从事部分IT运营的业务活动
技术管理的指标
事件事故的响应时间和完成率
2 、3线解决事故的时间
解决 问题的数量
升级的数量和理由
实施和支持变更的数量
被检测到未授权变更数量
发布及实施成功的数量
安全问题发觉和解决的数量
对系统的容量规划进行预测
追踪投资方案
对业务中服务的贡献程度
关键业务交易的交易成本和可用性
服务台培训
记录到知识库中的问题解决方案
在SLA定义中用户输出质量的衡量
在他控制下安装和配置的组件
技术管理角色
技术经理/团队领导
技术分析师
技术操作
应用管理
负责管理整个生命周期的应用
作用：是技术知识和专业知识的保管人来管理应用程序。为ITSM提供实际的资源
应用管理原则
购买？ 还是自建？ 自建是外包开发还是自行开发？
考虑因素：
应用程序规模及工作量的预测
管理规范的要求
运营成本
报告或者集成到其他应用程序的数据访问需求
调查现有工具能满足何种程度上的功能需求，实现该功能需要做多少定制开发
预测定制开发成本
确定获得所需要的技能所需要的支持方案
安全性要求
政府要求
应用管理角色
1.应用经理
2.应用分析师
事件管理中各管理角色作用
服务台：通常不参与事件管理。除非有些事件是属于服务台工作范围内的。如监控业务与服务台合并
技术、应用管理：服务设计、服务转移、服务操作、若事件管理由服务台处理则应对其进行培训。
IT操作角色：工作被下放给IT操作时，由IT操作来执行事件管理中的工作。
事故管理中各管理角色作用
一线：服务台
二线：处理一些复杂事物，与服务台互补
三线：由内部技术团队或第三方组成
服务请求中各管理角色作用
最初由服务台和事件管理的员工处理。服务实现由服务运营团队或外部供应商实现
访问管理中各管理角色作用
服务台：使用访问请求服务这一手段。
在服务请求中，服务台验证请求是否被批准，用户是否合法。通过验证后将请求提交执行。
服务台能与客户沟通确保他们获得必要支持。服务台还能检测并报告访问情况。
技术、应用管理：服务设计、服务转移、服务操作、若事件管理由服务台处理则应对其进行培训。
IT操作角色：工作被下放给IT操作时，由IT操作来执行工作
对于IT运营来说IT服务的管理系统是必须的。
IT运营管理的技术总需求
自助：向用户提供自助服务相当有用，利用一些网页形式提供一个自助服务范围和服务要求的菜单并与后继流程连接
工作流：工作流程是对流程预先定义和控制。事先定义职责、活动、时间限制、升级路径、报警，然后自动管理
综合配置管理系统(CMS)：CMS可以控制组织的IT基础设施、组件、服务和任何CI项，关联相关属性，在一个集中的区域并相互储存和维护，关联事件，已知错误和变化记录。
发现/部署/许可证技术：自动发现或审计工具能写入或CMS数据，并且协助许可证管理。这些工具能被运行在网络任意位置并允许查询和恢复所有组件构成、关联、架构等相关资料。
使用过滤使数据可以延续审核和提取必要的数据。
布置新软件到目标区域，让补丁、工具等能分发给准确用户。
允许软件下载通过一个自助接口来完成。
远程控制：对服务台和其他支持团队有用，能帮助他们控制用户桌面来进行调查和设置设备。
诊断工具
报告
整合业务管理：将业务相关流程与IT服务管理相结合—业务服务管理。
各流程和功能对技术的要求如下
事件管理技术要求
多环境，对整个IT基础设施和服务组织检测和报警
低沉本，易于部署
使用标准的代理程序对日常环境，元件，系统进行监控
使用开放通用接口来接受任何标准事件的警报输入
所有事件集中在一个区域。
报警的症状和影响可以程序化来判断和处理。
允许操作者确认和升级警报
事故管理技术要求
CMS能自动的维护事故、服务请求、问题、已知错误和其他配置项之间的关联
CMS能协助确定优先级和协助调查，诊断
允许一个流程预先定义和自动控制内部团体的路径和外部EMIAL SMS接口
自动报警和升级能力，防止事故被忽视和拖延
事件管理工具接口公开，使事件能自动升级到事故
通过WEB界面，提供自助服务和服务请求
使用KEDB记录和查询诊断、解决的事件和问题。帮助加快事故处理
易用的报告设施以便生成事故指标和方便事故分析、有助于问题管理和可用性管理。
服务请求技术要求
集成ITSM技术是服务请求中必须的。使其能与事故或已发生事件相关联。
服务请求一般被定义为事故管理的一个子集。当组织将其单独处理时需要工具来处理。前台自助将允许用户通过网页提交需求，通过菜单选择流程。服务请求管理中对设施的管理与事件管理比较类似，预先定义服务请求工作流，优先级，自动升级，有效的报告。
问题管理技术要求
综合业务管理技术：ITSM集成工具需要区分事件和事故，单独的问题记录只对加快事故处理有帮助但不能将事故关联。问题记录功能能将问题记录与多个事故做匹配。
变更管理：问题管理与变更管理集成很重要。因此请求，事件，事故和问题记录可以与出现问题的变更请求关联。
综合配置管理：CMS允许问题记录与组件的影响，服务的影响和其他相关CIS项关联。
已知错误数据库：一个有效地KEDB的基本条件是能方便的存储和检索已知错误数据。一个良好的报表功能能减轻生成管理报告的工作量，使数据能自动被输入并允许提取事件、问题分析。
访问管理技术要求
人力资源技术：验证用户身份和追踪其状态
目录服务技术
在应用软件，中间件，操作系统和网络系统的访问管理功能。
变更管理系统
请求传递技术
服务台对技术要求
1.电话：
自动呼叫分配系统
电脑电话接口系统：自动从CMS记录中识别呼叫者和调用详细信息
VOPI：降低国际和远程用户通讯成本
统计软件：统计收到的号码、响应时间、呼叫处理率、呼叫失败率、平均话时间
2.支持工具
1)已知错误数据库
2)诊断脚本
3)网页自助界面
FAQ和解决方案
搜索功能
服务公告包括：服务事项、详情、恢复时间等
密码修改功能
软件补丁下载
通知系统
软件下载
4)远程工具
3.ITSM工具的IT服务连续性计划
当组织依赖ITSM工具时需要对其进行BIA 和风险分析并计划改进。以确保适当的IT连续性和恢复水平
|
