ITIL 2011 服务管理与认证读书笔记——第六、七章【服务运营、持续服务改进】

一、服务运营
服务运营讲的是如何通过有效的工具、技术和既定的流程实施服务和运维管理,来为客户创造价值和收益。
为提高服务运营人员的工作效率和标准化日常操作,职能组织应采用和维护标准操作手册(Standard Operating Procedures, SOP).

1、基础知识
目的
服务运营,Service Operation,是按照同客户签订的SLAs协议,对终端用户实施服务,并且能够有效地管理相关应用和基础设施,确保高效地完成日常服务运营,从而保证客户和IT服务提供商双方的根本利益。
关键流程
  • 故障管理
  • 问题管理
  • 事件管理
  • 访问管理
  • 请求履行

2、事件管理流程 Event management
什么是事件(Event)?
  • 任何可被检测或者辨别的,配置项有意义的状态改变
  • 可能会对IT基础设施及其支持的IT服务有重大影响的通知。

事件的分类:
  • 信息
  • 告警
  • 异常

事件管理的目的:
  • 提供事件的检测和控制;
  • 通常是触发故障管理、问题管理和变更管理等其它流程的入口,如果判断一个事件为异常事件,往往会把该事件升级为一个故障或问题;
  • 存放在配置管理系统中的原始事件处理过程记录会成为服务报告和服务持续改进工作的输入;

事件管理的价值:
  • 建立尽早的告警和异常检测机制;
  • 通过与其它运营管理,如故障管理或问题管理,进行集成,以达到提高运维效率并降低系统宕机时间的目的。

事件管理流程包括以下活动:
  • 事件的发生;
  • 通知;
  • 监测;
  • 过滤;
  • 关联;
  • 响应选择;
  • 回顾;
  • 关闭;

事件管理的策略:
  • 事件信息只通知给相关事件的接收者;
  • 采用标准的事件定义和分类;
  • 强调自动化和集中化的事件管理;
  • 标准化事件处理和事件升级流程;
  • 所有事件都应被有效地采集和记录。

事件管理的绩效指标设计:
  • 重复事件的数量和比率;
  • 需要人工干预的事件数量和比率;
  • 导致故障或问题的事件数量和比率;
  • 引发容量或可用性问题的事件数量和比率。

3、故障管理,Incident Management
  • 故障,是指在IT服务中的一个非计划中断,或者IT服务本身服务性能的降低。
  • 故障管理的主要目的:
    • 是通过对故障生命周期的管理,尽快把故障所造成的非正常的服务恢复正常
    • 把故障对商业服务的影响最小化。
  • 故障管理的价值,是能够尽快监测和解决故障,降低业务中断时间,提高服务的可用性。将IT活动和业务优先级紧密关联,动态分配资源快速解决重大故障。
  • 故障是一种类型的事件,可被事件管理工具检测到,或者由用户联系服务台工作人员来通报任何故障。
  • 故障有类别和优先级,其中优先级别取决于故障的紧急程序和商业影响的大小:优先级=紧急*影响

故障处理的升级策略:
  • 横向升级至其它职能部门,如从服务台升级至二线、三线技术部门;
  • 纵向升级至部门管理层;
  • 每个部门都有横向、纵向两个升级方向。
  • 服务台的一线人员,或二线、三级人员采用相应的解决方案,处理故障后,应该由服务台一线人员及时地联系用户,在用户满意后,结束并关闭故障的处理。

故障管理流程的几个关键概念:
  • 故障管理流程关注快速地解决故障现象,而非查找故障背后的根本原因,所以故障管理更加强调故障解决的时效性。
  • 时间跨度的概念,是指故障处理各个阶段所限定的具体时间要求,例如故障响应时间、分派时间、受理时间、解决时间和关闭时间等。
  • 重大故障的概念,故障管理流程要求针对重大故障准备单独的流程、独立的团队、更短的时间和更高的优先级处理。
  • 故障处理模型,为了加快重复故障或类似故障的处理而定义的一些“标准”的故障处理模型。

故障管理流程包括哪些主要活动:
  • 故障的识别与记录,是故障管理流程的起点活动;
  • 故障分类分级与初步诊断,一线技术人员依据已有解决方案或个人经验对故障进行处理,或进行升级;
  • 调查与诊断,分析并提出解决方案;
  • 解决与恢复,尝试使用解决方案或变通方法来解决此故障,对虽然解决了故障却未找到根本原因的情况,需要创建问题单以进一步跟踪。对故障处理过程中的经验,需要形成可重用的知识,存入知识库中。
  • 故障关闭,在向用户确认后可关闭故障单,需要注意的是要保证故障单信息、分类和优先级信息的正确与完整,这对于日后制作服务报告有关键的影响。

故障管理流程的绩效指标设计:
  • 每类故障的平均成本
  • 重大故障的数量和比率
  • 未正确分派的故障的数量和比率
  • 未正确分类的故障数量和比率
  • 故障的平均解决时长
  • 错误分级的故障比率
  • 绕过服务台支持的故障比率

4、请求履行
服务请求,是来自用户向IT部门提出的各种需求的通用描述,包括IT信息的获取、访问权限申请或标准变更的请求等。
请求履行流程负责管理服务请求的整个生命周期:
  • 提供用户请求和接受服务的渠道,并有效地实施服务;
  • 为用户提供服务的信息和如何获取服务的具体步骤;
  • 回答用户的一般问询信息,解决用户的投诉和建议等服务请求。
请求履行的知识点:
  • 一般服务请求具有低风险、低成本和经常发生的特点,适用作为服务台工作的一部分。
  • 请求履行流程的主要服务内容就是处理服务请求的整个过程。
  • 很多服务请求还会有批准授权流程。
  • 请求履行的主要活动包括:
    • 菜单选择
    • 财务审批
    • 其他审批
    • 履行
    • 关闭
  • 请求履行的绩效指标设计:
    • 每类服务请求的平均成本
    • 服务协议时间内完成的服务请求的数量和比率
    • 妥当授权的服务请求的数量和比率
    • 由于不当服务请求所触发故障的数量

5、访问管理
访问管理的知识点:
  • 访问管理的目的,是提供给授权的用户访问服务和系统的权利,并阻止非授权用户的访问;
  • 访问管理的CIA安全要求,即机密性、完整性和可用性;
  • 访问管理的关键,是保证用户访问系统身份的唯一性,且以最小权限进行授权,对离职人员应及时清理授权信息;
  • 访问管理流程的活动包括:
    • 请求访问
    • 验证
    • 授予权限
    • 监视被授权用户身份状态的改变
    • 记录跟踪访问权限
    • 删除或限制权限
  • 访问管理通常是在请求履行的流程中去执行和实现的;
  • 访问管理的关键绩效指标设计:
    • 与访问管理相关的审计违背的数量
    • 服务协议时间内完成的访问请求处理的数量和比率
    • 由于不当访问请求处理所触发故障的数量

6、问题管理
什么是问题管理?
  • 是负责问题生命周期的管理
  • 是一个或多个故障的集合
  • 是未知的错误

问题管理的生命周期包括两个主要环节:
  • 问题控制环节
    • 对问题进行根源性分析
    • 把未知问题变成一个已知的错误,将known error记录到已知错误数据库里
    • 主要活动:对问题进行记录和分类-->问题诊断-->得到问题解决方案-->关闭问题
    • 当一时不能发现根源原因,可以采用变通方法(workaround)来降低或消除故障的影响
  • 错误控制环节
    • 要使用必要的操作或变更来消除引发故障的深层根源
    • 对错误进行评估,得出错误解决方案,并记录错误知识
    • 必要的话,发起一个变更请求(Request For Change),在执行变更后,关闭相关的变更、故障单和问题单

问题管理的目的:
  • 防止问题和故障的再发生
  • 最大限度减少不可避免的故障影响

问题管理模型:
ITIL 2011 服务管理与认证读书笔记——第六、七章【服务运营、持续服务改进】

问题管理的分类:
  • 被动问题管理,reactive
  • 主动问题管理,proactive

问题管理的范围:
  • 故障已恢复,但未能发现根源原因,需要继续通过问题管理达到深入分析原因,找到最终解决方案。这类情况可在故障解决后,生成一个问题单继续进行分析。
  • 由IT运维人员主动发现和创建的问题单。

问题管理流程包括的主要活动:
  • 问题检测与记录
  • 审核与分派
  • 分析与诊断
  • 技术升级,重点在于明确升级机制
  • 问题解决
  • 问题关闭

问题管理的绩效指标设计:
  • 在目标规定时间内成功解决的问题数量和比率
  • 各类型问题平均解决时长
  • 对问题类别一次性正确指派的比例
  • 对问题等级一次性正确指派的比例
  • 提交知识条目的数量
  • 问题由变更解决的比例

7、服务运营阶段中的关键职能模块
怎么区分职能Function与流程Process?
  • 流程,是为了完成一个指定的目标而设计的结构化的活动集合,包含了为保证可靠输出而需要的所有的角色、职责和流程控制点(check point)。
  • 职能,是一组人员的团队负责去完成一个或多个流程活动。

服务运营阶段包括的主要职能是
  • 服务台
  • 技术管理(技术架构管理)
  • IT运营管理
  • 应用管理

服务台的职责:
  • 收到并记录用户的所有呼入,包括服务请求、故障或投诉等,初步分类;
  • 评估和制定故障的优先级;
  • 提供故障处理的初步解决方案;
  • 监控处理过程,必要时进行升级;
  • 跟踪用户的满意度,在故障解决后关闭故障单;
  • 及时与用户进行沟通。

技术管理(偏重于团队,更像是技术人员管理)
  • 技术管理,就是确保IT服务提供商有权使用正确形式和级别的人力资源来管理目前的IT基础架构,从而完成客户的商业目标;
  • 技术管理,包括提供IT基础架构设计、部署实施、技术支持和管理的所有人员
  • 技术管理,是计划、执行和维护一个稳定的技术架构,并确保需要的资源和技术经验能被用来设计、创建和提高IT服务管理能力。

IT运营管理
  • 负责执行管理IT服务所需要的日常活动的一群人
  • 确定系统稳定性;
  • 监控并改进当前的服务质量;
  • 解决已经发生的所有IT运营故障。
  • IT运营管理包括两方面功能:
    • IT运营控制,设施层以上的事件监控和运营活动
    • 设施管理(偏重于设施),基础设施的管理

应用管理
  • 应用管理包括提供技术经验的应用设计、开发测试、发布部署与运维管理的所有人员
  • 应用管理关注的是软件应用。
  • 应用管理的目的是有效地识别应用软件的功能性和非功能性需求,来更好地支持客户的商业业务流程。
  • 应用管理,是从应用需求、设计、开发、发布、运营到持续改进的整个生命周期的管理。

事件-->Event
故障-->Incident


二、持续服务改进
什么是持续服务改进,Continual Service Improvement, CSI ?
  • 是通过对IT服务管理流程和IT服务本身全生命周期的不断改进,来持续保持服务对客户的价值
  • CSI包括以下方面:
    • 持续度量和改进IT服务提供商的服务能力。
    • 改进服务流程的有效性
    • 提高IT服务的效率以及成本效益
    • 提供对流程和服务的度量分析的指导
    • 提供在整个服务的生命周期内,对服务的各个阶段进行指导

服务改进计划,Service Improvement Plan:
IT服务提供商负责对服务进行持续改进,对服务管理的具体实践和方法进行改良,并撰写服务改进计划。
真正的持续服务改进,应该成为企业的一种理念或文化。

1、持续服务改进方法

ITIL 2011 服务管理与认证读书笔记——第六、七章【服务运营、持续服务改进】

服务持续改进方法:
  • What is the vision?
    • 了解商业目标,愿意,IT服务战略需要与之保持一致
  • Where are we now?
    • 现状的评估
  • Where do we want to be?
    • 对预期的理想目标建模
  • How do we get there?
    • 确定服务和流程的改进计划、项目
  • Did we get there?
    • 确定度量方法和指标,以确认是否达到了既定目标
确保服务改进的变更在企业中实施,保证服务的持续改进。

2、PDCA戴明环

ITIL 2011 服务管理与认证读书笔记——第六、七章【服务运营、持续服务改进】

戴明环,诠释了全面质量管理活动的全过程所应遵循的科学程序。PDCA循环就是按照P-D-C-A的顺序进行质量管理,并周而复始的进行下去。
  • Plan,计划,不仅包括目标,也包括实现目标所需要采取的措施;
  • Do,按计划去实施;
  • Check,按预期目标去检查工作结果,找出问题和原因;
  • Act,改进,针对发现的问题进行改进操作,将经验和教训的内容制定成参照标准,形成制度。

3、七步改进流程

ITIL 2011 服务管理与认证读书笔记——第六、七章【服务运营、持续服务改进】

第一步,识别改进战略,从战略愿景到商业需求、战略、战术目标、运营目标,对改进提出全方位的需求。设置应该度量的目标。回答你具体需要度量的是什么,而不要考虑当前的度量数据是否可得到。
第二步,定义什么是能够度量的,分析什么是所需要的,什么是可度量的,什么是与可度量的差距,并把差距分析报告给客户和IT管理层。为缩短这些差距,可以考虑启用新的工具或做一些客户化的操作。
第三步,收集数据,通过监控工具和手工处理来监控和采集预定义的度量数据,监控主要关注服务和流程、执行的效率和效果,收集的重点是能够体现当前IT服务质量的关键数据。
第四步,处理数据,把原始数据转称成需要的格式,如结构化报表。
第五步,分析数据,把数据和信息转换成能够影响企业或组织的知识,如分析数据的关系、发展趋势和例外条件是否被触发等。
第六步,呈现和使用信息,以容易理解的方式把获得的知识展示出来,并作为管理层用来做战略、战术和运营决策分析的参考依据。
第七步,实施矫正活动,用获得的知识来优化、提高和矫正当前的服务流程。

4、六西格玛质量管理标准
六西格玛采用了DMAIC系统方法对不能满足要求的过程进行改良:
  • D:定义
  • M:度量
  • A:分析
  • I:改善
  • C:控制
在DMAIC中的度量和分析阶段,经常使用Pareto分析方法来分析造成质量缺陷的主要原因。Pareto理论提示出质量的大部分缺陷经常是由于相对较少的原因造成的,80/20原则。
服务经理应该去找出这些主要的服务问题,并做出改善。
DMAIC的控制环节就是校验正确的行为,建立并执行控制计划,最终共享你的最佳实践和经验教训给相关的部门。

5、服务度量
服务度量的目的,是确保服务度量的目标和度量手段,符合业务持续的改进需求。
服务度量,是在充分理解业务流程的前提下,结合组织的战略目标和运营指标,来具体定义服务需要度量的内容和指标。

服务度量的价值:
  • 校验以前的决定是否正确,To Validate;
  • 指导行为去满足设定的目标,To Direct;
  • 由实际的证据去证明行为的正确性,To Justify;
  • 在适当的点进行干预和执行改进行为,To Intervene;

依据上述4点,定义出以下服务度量的框架:
ITIL 2011 服务管理与认证读书笔记——第六、七章【服务运营、持续服务改进】

持续服务改进按级别可分为三类:
  • 流程度量
  • 服务度量
  • 技术度量
即,分别在流程、服务和技术层面上去设置控制点,度量其有效性。通常会预定义一些KPI指标来指导度量。

ITIL平衡计分卡,Balanced Scorecard
  • 是对企业长期战略目标进行有效评估的综合方法;
  • 通过把组织的远景转变为一组四个视角组成的绩效指标架构,来评价组织的绩效:
    • 财务视角,Financial
    • 客户视角,Customer
    • 内部流程视角,Internal Business Processes
    • 学习与成长视角,Learning and Growth
  • 该平衡计分卡强调以下方面:
    • 内部流程的标准化
    • 运维人员的培训和解决问题的能力
    • 成本的可控和不要额外的浪费,
    • 客户的满意度的可视化度量

ITIL 2011 服务管理与认证读书笔记——第六、七章【服务运营、持续服务改进】


6、服务报告
服务报告,是IT服务提供商对服务质量数据的采集和监控工具。
生成的报表数据可以包括:
  • 每月的问题请求量,可以关注问题的分布数量和不同级别的问题的平均解决时长。
  • 变更请求量,需要关注那些紧急的变更请求,分析紧急的原因是什么。如果有失败的变更,需要关注变更失败的原因和有没有相应的失败恢复计划。变更回顾可以有效防止再次发生类似的失败。
  • 日常的内部审计请求量,记录了不同类型的审计数量和任何可能的被审计出来的漏洞。
  • 服务器性能
  • 数据库性能
  • 应用性能
  • 网络性能
  • 存储外设性能
  • 违背SLA协议量

服务报告模板:
  • 报告的目的
  • 报告概述
  • 本季度服务总体汇总
  • 下季度待完成任务
  • 服务绩效详细KPI
  • 重大故障回顾
  • 重大变更回顾
  • IT服务趋势分析
  • 客户满意度分析
  • 报告数据来源