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