20150618MONICAZHANG 续上
4.2.7可用性管理 在现有服务环境中,总体上看各个层面对可用性都有不同的关注,其中涵盖了要求、需求、想法和实践。ITIL培训 首先,某公司对可用性是有明确要求的。在信息化工作办公室发布的信息化同业对标指标体系中有明确的对可用性指标要求,如:服务器平均运行率、广域网络系统运行率及本地网络系统运行率等,并对每个指标有详细的描述和计算周期及方法的定义。 其次,从天津市电力公司业务部门角度来看,对可用性的需求一直很高,很多系统的关键业务功能都有7*24的服务运行要求。 另外,天津市电力公司科技信息部在可用性管理方面是有一定的想法和实践的。随着IT服务管理一期项目的建设和运行、以及服务管理二期项目的宣导,信息管理层充分认识到可用性指标的重要程度以及可用性管理流程的重要性。技术管理人员层面也意识到可用性(运行率)是一个重要的、并非独立的综合性指标,任何系统有问题都会影响到可用性的达标情况,机房环境等基础设施更显得尤为重要,各管理角色也在密切配合对IT服务的稳定运行提供着保障。ISO20000培训 根据对流程评估的九个纬度,下图量化地反映了现有流程状态以及经过本期项目后双方共同努力改进的目标。
图4‑38可用性管理评估与改进 根据上图,以下将总结和陈述对可用性管理流程各纬度的主要发现和改进建议:
表格4‑4可用性管理主要发现及改进建议 [p=15,null,center]纬度
| [p=15,null,center]主要发现
| [p=15,null,center]改进建议
| [p=15,null,left]基础条件
| ž有一定可用性管理活动,但没有形成可重复的管理机制 ž尚未形成文档化的管理流程和角色定义
| ž通过流程研讨,进行总体可用性管理流程定义,形成共识共知的可用性管理流程文档 ž在未来实践中,严格遵循定义流程进一步规范可用性管理活动ITSS培训
| ž对关键系统具备一定的弹性以保证可用性目标 ž管理上避免但实际操作中因为人力资源有限存在部分人员单点故障
| ž提高和巩固对关键系统的双机热备等弹性手段保证 ž明确业务部门的可用性需求,对不同服务区分不同的可用性目标,控制业务需求,优化投资方向
| [p=15,null,left]管理目的
| ž有指定的专人进行可用性的统计汇报工作,其职责并不明确覆盖到可用性的管理
| ž指定可用性流程经理,并授权全面负责设计、管理、协调可用性管理活动,全面关注天津市电力公司的服务可用性整体提高并组织各方对可用性管理流程持续改进和优化ITSS认证
| [p=15,null,left]流程能力
| ž对不同服务没有识别和区分关键业务功能(VitalBusinessFunction) ž对不同服务有共识但没有定义明确的服务时间 ž没有同业务部门约定和区分计划宕机时间和非计划宕机时间
| ž识别和区分关键业务功能,对于服务可用的标准与业务部门达成共识 ž服务时间是计算可用性的基础,必须明确定义出来,否则可用性无从计算和比较 ž为保证业务质量和增强业务功能,合理的计划宕机是必需的,但计划宕机的时间需与业务部门协商确定并记录
| ž科技信息部管理和控制IT预算,并参与业务系统需求分析和方案的建议
| ž保持并增强对这个环节的重视,更加明确这个阶段的审核控制方面,明确加入对可用性的分析和要求
| ž没有对服务进行明确定义和组件分析
| ž可用性是一个综合性的指标,受组成服务的各组件可用性影响,可用性组件分析是一个关键步骤,在项目中将以一个服务(如OA)为实例进行剖析
| ž有定期输出的可用性报告,运行率主要以手工计算 ž存在部分组件级的监控工具,如对机房环境和网络的监控 ž存在一定的数据积累,如ServiceDesk及管理人员记录的故障,如OA中断,这些数据是对不可用服务的有效计量来源 ž现有工具尚不足以形成全面的服务可用性采集、计算及监测
| ž需要综合网管为底层组件监控工具,并辅以对SLA监控的服务级监控手段,最终形成对可用性自底向上贯穿的发现、采集、处理计算及报告工具 ž监控工具的建设需要一定的资金、人力资源的配合以及在自身IT环境中的不断完善和调优,不是一蹴而就的过程ITSS考试
| ž受人力资源紧张等因素制约,有意识但没有足够的时间去进行主动的可用性趋势分析和主动可用性管理
| ž主动的可用性管理是可用性管理流程的一个重要方面,可以通过主动的管理来主动预防和避免服务不可用,提高服务可用性 ž流程的有效运转需要相应的资源赋能和驱动,内部和外部的资源都应被利用起来进行可用性的管理推动
| [p=15,null,left]内部支持
| ž流程内部各活动没有连贯并相互照应形成统一的可用性管理
| ž结合现有活动,梳理流程各环节的输入输出关系
| [p=15,null,left]流程产出
| ž有年度工作计划,但没有专门的可用性计划
| ž可用性计划是可用性管理流程的重要输出之一,在研讨中,将讨论并给出可用性计划的内容
| [p=15,null,left]质量控制
| ž可用性流程不完善,因此也没有形成严格的质量控制机制
| ž建立流程的KPI指标,持续优化改进 ž在可能的情况下,利用相关工具配合流程的实现
| [p=15,null,left]管理信息
| ž无规定的周期性的运行分析报告 ž有可用性报告,并以月为周期上报某公司
| ž运行分析报告是可用性分析和保障的重要依据,初步判断,可以利用外部资源进行获取,在设计阶段将进一步探讨 ž依照某公司要求,参照ITIL最佳实践,规范可用性报告ITSS认证
| [p=15,null,left]外部集成
| ž事件管理流程运行较好,对有效保证较好的可用性,缩短服务中断时间起到重要作用 ž配置管理范围过大,导致维护资源难以保证,数据更新无法保证,CMDB数据的价值无法释放 ž问题管理受人力资源和工作压力的限制 ž变更管理的范围过大,审批环节及流程效率不高 ž已经认识到可用性是服务级别的重要指标之一,但尚未形成服务级别管理 ž未有机制获得准确的容量规划战略及相关信息
| ž巩固事件管理流程,优化工具 ž梳理配置管理,协同完成对可用性的辅助作用 ž强化变更管理,提高对非授权变更的控制;提高变更审批效率,降低对可用性的影响 ž协同问题管理及主动的可用性管理,达到对可用性的主动提升 ž可用性管理需要和其他流程紧密配合,共同完成对服务可用性的设计、监控及保障;在咨询的设计阶段将详细讨论可用性管理流程及事件管理、配置管理、问题管理、变更管理、容量管理、服务级别管理等流程的关系及集成接口
| [p=15,null,left]客户界面
| ž某公司对标体系中有客户满意度的要求 ž已关注到客户的满意度,但尚未形成一个机制
| ž客户满意度调查应形成一个机制,但在企业文化下不拘泥于形式
|
4.2.6容量管理 在现有服务环境中,没有正式的容量管理流程,但具备一些容量管理流程所要求的活动。业务应用系统在不断改进,瓶颈通常在应用部分。新的系统建设时,系统容量主要依靠开发商预估。在机房环境和存储扩容等方面,有部分数据收集和数据分析。 当前天津市电力公司业务部门、IT部门管理层都意识到容量管理的重要性,但需要加强业务部门和IT维护部门的有效沟通。 以对流程评估的九个纬度为基准,下图量化地反映了现有流程状态以及经过本期项目后双方共同努力改进的目标。
图4‑39容量管理评估及改进建议 根据上图,以下将总结和陈述对容量管理流程各纬度的主要发现和改进建议:
表格4‑5容量管理主要发现及改进建议 [p=15,null,center]纬度
| [p=15,null,center]主要发现
| [p=15,null,center]改进建议
| 基础条件
| ž有一定容量管理活动,但没有形成可重复的管理机制 ž容量管理活动没有落实到具体的人员
| ž通过流程研讨,进行总体容量管理流程定义,形成共识共知的容量管理流程文档 ž在未来实践中,定义明确的人员职责进行容量管理活动ITSS培训
| 管理目的
| ž内部还没有正式进行容量管理规划以及预测未来的业务需求 ž没有明确的容量管理范围
| ž通过流程讨论,明确容量管理目的和意义,并在企业内部达成共识 ž在未来实践中,基于ITIL和用户实际,定义容量管理范围和容量管理活动
| 流程能力
| ž没有正式为容量管理活动制定相应的职责 ž对于新的服务会确定服务内容和容量,但主要依靠开发商预估 ž存在监控每个资源和服务的使用情况的基础性工作,没有进行服务性能和趋势分析
| ž在未来实践中,定义明确的人员职责进行容量管理活动 ž通过容量管理流程的建立,掌握应用评估方法,主动进行服务容量规划 ž通过容量数据库建立服务和资源的关联关系,加强资源和服务的数据收集,测量性能状况
| 内部支持
| ž存在资源分析活动,用以优化资源的使用
| ž未来实践中,根据容量管理范围,调整资源数据收集和分析范围 ž结合现有活动,梳理流程各环节的输入输出关系,加大内部支持力度
| 流程产出
| ž没有容量管理数据库 ž在机房环境和存储扩容等方面,有部分数据收集和数据分析 ž没有容量规划报告
| ž未来实践中,建设容量数据库 ž根据容量数据库要求,扩大容量数据收集范围,做到对新的工作负荷和资源需求进行预测 ž流程设计中,设计并规范化容量规划文档
| 质量控制
| ž容量管理流程不完善,因此也没有形成严格的质量控制机制
| ž建立流程的KPI指标,持续优化改进 ž在可能的情况下,利用相关工具配合流程的实现ISO20000培训
| 管理信息
| ž容量管理流程不完善,因此也没有形成严格的管理信息
| ž参照ITIL最佳实践,规范容量管理报告
| 外部集成
| ž事件管理流程运行较好,对有效积累IT运营状况,为容量规划提供必要的监控信息 ž配置管理范围过大,导致维护资源难以保证,数据更新无法保证,CMDB数据的价值无法释放 ž存在一些可用性管理活动,有定期输出的可用性报告 ž已经认识到可用性是服务级别的重要指标之一,尚未形成服务级别管理 ž具备一定的IT系统管理工具,但不能够完全满足容量管理信息收集的需要
| ž巩固事件管理流程,优化工具 ž梳理配置管理,协同完成对容量的辅助作用 ž容量管理需要和其他流程紧密配合,共同完成对服务可用性的设计、监控及保障;在咨询的设计阶段将详细讨论容量管理流程及事件管理、配置管理、服务级别管理等流程的关系及集成接口 ž加强IT系统管理工具的投入,优化和提升其功能,扩大其管理范围
| 客户界面
| ž某公司对标体系中有客户满意度的要求 ž已关注到客户的满意度,但尚未形成一个机制
| ž客户满意度调查应形成一个机制,但在企业文化下不拘泥于形式ITIL培训
|
本帖关键字:ITSSISO20000
|