HP 可用性容量管理评估报告

平安保险（集团）股份有限公司
信息管理中心
可用性和容量管理评估报告
EPCIS Auto
HP Services
在本文档中的任何部分需要向第三方公开之前，必须得到平安保险集团公司的书面批准。
_______________________
版权
_______________________
2007 年惠普公司版权所有
保留所有权利
本文档引用了惠普公司已注册商标的产品和服务
此处提到的其它产品名称可能是其各自公司的商标和/或注册商标
本文档使用的第三方商标的所有权已经确认
_______________
文档信息
服务名称: 可用性和容量管理评估
作者: Joshua Brusse ITSM Principal
Kingshuk Ghosh Senior ITSM Consultant
Ruidan Chen Senior ITSM Consultant
Qun Zhang Senior ITSM Consultant
Yuping Huan Project Manager
文档修订版本信息
Date Revision Status Comment

October 1, 2007 X0.1 Draft First Draft by Joshua Brusse
目录
1 简介................................................................................................. ...............4
1.1 背景 ............................................................................... .........................5
1.2 参与人员................................................................................................. ...5
1.3 信息管理中心组织架构...................................................................... ...........6
2 要点综述................................................................................................... .......8
3 建议汇总................................................................................................. .......10
3.1 总体............................................................................................ ............10
3.2 容量管理: 需求管理（Demand Management）..........................................11
3.3 容量管理: 性能管理................................................................. ..................12
3.4 容量管理: 应用容量评估 (Application) Sizing.............................................13
3.5 可用性管理：需求收集................................................................... ............14
3.6 可用性管理：设计和实施.................................................................... ........15
3.7 可用性管理：管理和改进.................................................................... ........16
3.8 支持流程.............................................................................................. ....17
4 下一步工作 .................................................................. ...............................19
5 详细差距分析及发现..................................................................... ...................20
6 IT 治理.......................................................................................................... .21
服务管理体系..................................................................... ...........................21
业务关系管理..................................................................... ...........................24
服务规划.................................................................................................... ...25
7 技术............................................................................................... ...............27
物理环境.................................................................................................... ...27
服务器、存储平台和操作系统........................................... ...............................30
应用和数据库..................................................................... ...........................35
网络 40
8 服务交付................................................................................................. .......43
服务级别管理..................................................................... ...........................43
财务管理.................................................................................................... ...47
可用性管理.................................................................... ...............................48
服务持续性管理...................................................................... .......................56
容量管理.................................................................................................... ...58
9 服务支持................................................................................................. .......69
服务台和事件管理....................................................................... ...................69
问题管理.................................................................................................... ...70
操作监控.................................................................................................... ...71
配置管理.................................................................................................... ...73
变更管理.................................................................................................... ...75
发布和测试管理...................................................................... .......................77
Appendix A 流程成熟度定义.............................................. ................................79
HP Services
Availability and Capacity
Assessment
1 简介
本报告陈述了惠普公司在2007年9月12 日至2007年9月18 日为中国平安保险（集团）股份有限公司（以
下简称“平安保险”）信息管理中心提供的可用性和容量管理评估的结果。本次评估主要针对EPCIS Auto
应用系统。
惠普公司对平安保险信息管理中心的可用性和容量管理实践和技术进行了深入的评估，提出并汇总了差距
分析，指出为提供高质量、可靠的IT 服务进行可用性和容量管理潜在的风险。报告中的发现可以作为服务
改进措施的基础，以提高平安保险的IT 服务质量、效率和成效。
本报告通过以下几个方面描述此次评估的结果:
 要点综述：概述描述评估中的主要发现
 建议汇总：着手改进的薄弱之处的建议，可以作为服务持续改进计划的起点
 详细差距分析及发现：每个领域的详细评估，参考最佳实践标识出优势和劣势并以可用于规划改
进的格式提供了建议的最佳实践
惠普从容量管理和可用性管理的以下方面进行了评估:
1. 容量管理
a. 需求管理
b. 性能管理
c. 应用选型及建模
d. 相关支持流程
2. 可用性管理
a. 可用性需求
b. 可用性设计和实施
c. 可用性管理和提高
d. 相关支持流程
评估着眼于可用性和容量管理的各纬度，涵盖影响端到端服务的人员、流程和技术。
评估标准基于惠普公司在设计和支持企业级关键业务解决方案的广泛经验，并结合业界和厂商的最佳实践，
例如OGC ITIL，BS15000/ISO 20000 和HP 公司的ITSM参考模型。
本次可用性和容量管理评估的关注点如下：
公司名称中国平安保险（集团）股份有限公司
IT 组织信息管理中心
评估的IT 服务 EPCIS Auto
地点中国深圳
数据收集时间 2007 年 9 月 12 日至 2007 年 9 月 18 日
Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Commercial in Confidence Template – V2.3.1 Page 4 of 79
HP Services
Assessment
1.1 背景
平安保险的目标是成为以保险、银行、资产管理为核心，国际领先的综合金融服务集团之一，持续地获得
稳定的利润增长，向股东提供稳定回报。随着业务持续快速地发展，IT 成为业务支持的核心竞争力，业务
对 IT 服务无疑会提出更高的要求。
在过去的几年中，平安保险信息管理中心参照ITIL最佳实践，实施了多个标准的服务管理流程，IT管理层
和员工致力于不断提供服务质量，但随着业务对IT服务提出更高的可用性要求，需要更好的容量预测来支
持业务的发展。
目前平安保险信息管理中心缺乏一套可重复和可管理的方法来计划、实施和管理可用性，也缺乏一个成熟
的方法论来进行容量管理，例如，需求管理、容量预测、应用选型和建模等。这也是信息管理中心决定实
施可用性和容量管理的原因，同时改进其他相关流程和方法，建立完整和成熟的工作模式。
作为服务交付的两个主要流程，可用性和容量管理的实施涉及流程、技术和人员等各方面的因素，为确保
其稳步、成功进行，惠普建议分为两个阶段，本期为评估阶段，以下是实施可用性和容量管理的业务驱动
因素和本期评估的目的。
业务驱动
•应用和基础架构存在可用性和容量相关问题
•针对新应用或已有应用变更的实施缺乏科学的容量预测
•没有正规的可用性和容量管理的方法
第一阶段的目标
本期可用性和容量管理评估的目的是：
• 提高对实施可用性和容量管理流程存在的优势、弱点和风险的认识和理解
• 帮助识别 IT 组织在实施可用性和容量管理时，可增强以降低的风险的领域，并指出这些领域的重要程
度
• 识别改进实施可用性，容量管理及相关的流程执行质量的机会
达到以下目的：
o 通过评估以确定：
•现有 IT 服务管理流程对可用性管理和容量管理支持的成熟度及流程自动化情况
•平安保险 IT 是否满足业界标准，是否有基础迈向下一阶段而成功实施可用性和容量管理
•差距是什么
•帮助平安保险了解如何弥补这些差距，为着手改进提供坚实的基础或基线，为第二阶段实施可用性和容量
管理提供重要输入
3. 确定实施可用性和容量管理的方法，开发第二阶段的工作说明书
1.2 参与人员
在此次评估中，不仅惠普公司采取了大量的投入，同时，中国平安保险（集团）股份有限公司信息管理中
心及业务部门的许多经理和员工也投入了大量的时间、精力。惠普公司对他们表现出的合作态度和坦率精
神表示衷心的感谢。

HP Services
Assessment
中国平安保险（集团）股份有限公司惠普公司

和丽华产险业务部 Joshua Brusse
马晓强系统开发一部/核心技术组 Dickens
陈亚殊系统运营一部/产险应用服务组 Kingshuk Ghosh
许小斌基础架构管理部/机房设施组张群
王青平基础架构管理部/系统管理组陈瑞丹
王大海基础架构管理部/系统管理组宦渝平
李飚基础架构管理部/系统管理组徐戟
张献锦基础架构管理部/网络及安全实施组
刘珊基础架构管理部/中间件组
萧青基础架构管理部/数据库管理组
田岗基础架构管理部/工具组
邹芳基础架构管理部/备份容灾组
任晓东基础架构管理部/流程质量组
韩立峰基础架构管理部/系统管理组
赵春雷基础架构管理部/产险事件响应组
卢阁基础架构管理部/中间件组
李毅系统运营一部/公共平台应用服务组
朱红燕系统运营一部
赵永辉规划支持部/软件架构组
黄宇应用开发支持部/产险测试组
赵明应用开发支持部/产险测试组
王琴规划支持部
刘悦规划支持部/变更统筹组
1.3 信息管理中心组织架构
下图是中国平安保险（集团）股份有限公司信息管理中心的组织架构图，用以说明参与本次调研的人员和
来自的部门。

HP Services
Assessment

HP Services
Assessment
2 要点综述
平安保险 IT 部门正式采用了基于 ITIL 的 IT 服务管理方法论，而且被 CIO 宣导和深化到公司的高级管理层。
较早地引入并实践了 ITIL，并且已经实施了部分业界认可的技术和方法。
关于可用性和容量管理的策略已经存在。IT 组织意识到需要面向服务文化，变革成为一个 IT 服务提供组织。

这意味着需要建立一套正规的、可重复的可用性管理及相关支持流程（包括容量管理）的方法，并能被 IT
各部门和业务实际应用。
通过本次评估发现了以下方面，这些方面会对实施有效的可用性和容量管理带来负面影响，包括：
• 没有结构化的和可管理的客户关系管理
• 没有服务目录，用来定义 IT 提供给业务部门的‘IT 服务’，或业务部门提供给他们的客户、需要 IT 支
持的‘服务’
• 没有清晰记录业务活动模式（Patterns of Business Activities）和 User Profiles，缺乏从业务的角
度准确地进行容量预测
• 服务规划没有被集成为服务上线的一部分
• 存在初始的 IT 财务管理流程
针对每一个潜在不足之处，后面章节提供了相关建议，涵盖以下方面：
• 建立正式的业务关系管理
• 通过服务级别管理，并实施一个试点的服务级别协议（SLA），建立明确的服务质量衡量目标
• 建立组合管理（Portfolio Management）－包括服务目录管理（Service Catalogue），用来跟踪
不同 SLA 之间的优先级管理和正式运行情况，并有助于识别其他 ITSM 流程对业务的优先级和影响度
评估。
• 建立服务规划（作为服务上线的一部分），确保业务和 IT 紧密结合
• 改善财务管理，结合业务预测和 IT 需求，有助于容量预测和可用性管理，计算容量问题和服务不可用
的有形及无形影响，这样可以更好地基于优先级进行资源分配
根据 HP 多年 IT 服务管理方面的实践经验，我们认为，成功的实施可用性和容量管理前提条件是：支持流
程的成熟度必须达到或相当于 CMMI 的 3 级，其中包括集成的工具可以支撑成熟的流程自动化。在服务设
计、服务上线和服务运营领域，成熟的流程管理能确保更好地进行可用性设计、执行和管理，同时也可确
保更好的方法论用以（应用）选型和性能管理。
平安保险 IT 已经有了一个良好的开端，具备和实施了一些服务设计，服务上线，服务运营所必要的流程和
策略，但是成熟度尚需提升。针对目前已实施的支持流程的发现如下：
• 与其他流程相比，变更管理比较成熟。但是，在不同部门使用各自流程的情况下，应用和基础架构团
队的沟通不是很正规
• 发布管理应当在平安保险 IT 内部得到更好地集成整合
• 配置管理在基础架构管理部被较好地建立和维护，但 CMDB 的信息不能提供端到端的服务树视图，这
是有效地实施可用性和容量管理的关键因素之一，因此建议建立一个集成的、统一的配置管理系统。

HP Services
Assessment
• 问题管理应当改善并更加主动，它将会对系统和服务的可靠性起到积极作用，并能进行更准确的系统
停机分析（System Outage Analysis）。
• 应当改善供应商管理，针对容量和可用性管理，与供应商的关系应当建立并很好的管理和保障（利用
合同或协议）。
技术是支持流程自动化的重要组成部分之一，平安保险 IT 需要一套集成的服务管理工具来支持所有的流程。
它必须能记录事件、问题和变更、并与服务的配置项关联，同时，如上所述，工具必须能提供完整的服务
树，和服务树中各个组件的历史记录。评估中关于技术方面的发现如下：
• 平安保险 IT 已经具备必要的工具来监控性能。已经获得了许多信息，但缺乏如何关联和诠释收集到的
信息的方法。
• 在压力测试、负载测试及预测方面存在某些局限，评估发现，测试环境与生产环境不是完全一样，两
个环境之间的映射比对关系也较弱，这可能会导致不准确的结论和决策。
• 技术领域，比如服务器、存储、网络、数据库和系统等管理得很好，但是不同专业间的交互应当更积
极、充分。
以上是评估的要点综述，更详细的报告参见详细差距分析。惠普建议采用正式的服务改进计划来改善下一
章中提出的建议，并采用正式的项目管理方法来管理产生的各个项目。能力管理需要建立起来，包括定义
角色、职责、技能、经验和责任等，确保改善能够很好地执行和深化。

HP Services
Assessment
3 建议汇总
3.1 总体
1 确保采用一个管理组织变革的方法，并涵盖能力管理
W 协助人员进行文化变革非常重要，变革的曲线包括认知、了解、采用、制度
hy: 化和内在化，本次评估后选择进行所有的改进工作都应当依此进行变革管理。
能力管理包括正式的角色、职责、技能、经验和责任，以确保所有改进都深
入并扎根内部，保证平安保险 IT 有合适的人做正确的事。作为能力管理的一
部分，责任必须和每年的个人绩效评审和报酬挂钩，以激励手段来确保改进
顺利地在内部深化。

HP Services
Assessment
3.2 容量管理: 需求管理（Demand Management）

1 业务部门必须与 IT 部门更紧密合作，提供详细的业务活动模式（ Pattern of
business activity）和 User Profiles。
这意味着，不同业务干系人，包括业务和 IT 服务的客户和用户需要被识别出来，并建
立 IT 与这些干系人的关系，以了解业务的用户类型、行为习惯、以及他们实际使用的
业务活动。
W 管理容量是业务和 IT 共同的责任。业务部门必须参与到容量规划中，并与 IT 部门一起
hy: 进行容量的细节工作。当前业务部门仅提供了整体增长量的数字，而更细粒度的预测
细节也是需要提供的，因为这一层次组成了业务活动模式。因而，业务部门必须和 IT
紧密合作以提供：
•来自所有使用平安保险 IT 服务用户的工作负载模式（User Workload）报告和趋势
•比目前更细粒度的业务活动模式的预测。业务部门应当给 IT 部门提供当前的业务活
动模式以及这些活动模式的相关预测
2 IT 和业务应当建立组合管理（Portfolio Management），其中涵盖 IT 服务
目录
W IT 服务目录提供了一种对业务和 IT 部门之间期望和理解的基础，同时，也很
hy: 重要的是了解业务流程、业务服务和支持业务的 IT 服务，这有助于容量和服
务级别管理，同时也是更好合作和相互支持的动力。
3 IT 应当和业务部门一起记录所有的关键业务功能（VBF，Vital Business
Functions），然后基于它们对业务的重要性定出优先级。
W 了解关键业务功能和对业务的优先级，当发生临时容量缺乏时，这是进行容量交付的
hy: 优先顺序的基础。

HP Services
Assessment
3.3 容量管理: 性能管理

1 建立一个跨专业的团队进行容量管理
W 平安保险 IT 已具备必要的工具用以监控性能。但问题是缺少一个团队理解每一类监控
hy: 到的指标，并整合来自不同技术领域的结果，导致很难将所需的业务容量转化为资源
容量。也许一个技术组缺少对其他技术领域的知识，但平安保险 IT 要提升到一个新的
高度，必须发展这种能力。因此建议建立一个具备合适能力的、跨专业的容量管理小
组。（这个团队是虚拟的还是日常的？人员要求的技能是否非常高？）已解答
2 建立初始的性能和用户负载之间的关系
W 单独资源的性能监控主要用于问题诊断和扩容前的辅助决策，但不能用作对容量的主
hy: 动预测。为了进行主动的容量预测，需要一个对比参数，这个对比参数就是用户负载
（User Workload）。
分析 web server access log 帮助容量管理团队理解每个时间段的用户访问量，每个
时间段的交易量，热点交易和较少进行的交易等。
可以使用回归分析方法，建立用户工作负载和资源利用的关联关系。把这些信息传递
给业务部门可以帮助他们回顾过去的统计，对未来的用户工作负载进行更准确的容量
预测，用户负载的预测能够被应用到资源使用模型中，以得到不同资源的容量预测。

HP Services
Assessment
3.4 容量管理: 应用容量评估 (Application) Sizing

1 确保一个合适的环境用于应用容量评估
W 压力测试可以降低服务的容量风险。每个服务每年（每一年最好要多于一次），当所
hy: 有主要功能变化之后或当有交易记录有重大偏离时，应当执行压力测试和优化工作，
并使之成为用户接受测试（UAT，User Acceptance Testing）的一部分。在非生产
环境进行的压力测试，应当与生产环境之间建立相应的关联关系。
目前的Staging环境与生产环境没有适当的关联关系，意味着从容量预测的角度，在
压力测试上付出的投入是无效的，同时也增加了生产环境中服务的风险，平安保险IT
应当选择确保有足够的容量选型（Sizing）的Staging环境，或者征得业务部门的同
意，在适当的停机时间内在生产环境进行压力测试。

HP Services
Assessment
3.5 可用性管理：需求收集
1 对可用性管理需求的收集应当更结构化和可重复（通过服务级别管理）
W 可用性管理需求收集应当更结构化和可重复。IT 组织一定要参与到业务中，理解服务/
hy: 系统中断对业务的有形和无形的影响。IT 需要有能力根据可用性交付来决定成本，从
而保证业务和 IT 可以基于业务需求和业务预算来讨论可用性需求。
2 IT 和业务应当建立组合管理（Portfolio Management），涵盖 IT 服务目录
W IT 服务目录提供了一种对业务和 IT 部门之间期望和理解的基础，同时，也很
hy: 重要的是了解业务流程、业务服务和支持业务的 IT 服务，这有助于可用性和
服务级别管理，同时也是更好合作和相互支持的动力。
3 IT 应当和业务部门一起记录所有的关键业务功能（VBF，Vital Business
Functions），然后基于它们对业务的重要性定出优先级。
W 了解关键业务功能和对业务的优先级，当进行预算时，这是进行可用性交付的优先顺
hy: 序的基础。同时也有助于实施可用性管理的方法，如组件失效影响分析（CFIA）、故
障树分析（FTA）、以及风险管理。
4 建立对可用性指标的认知
W 业务部门需理解可用性百分比所表达的含义。如果不能充分理解和认可，会导致 IT 所
hy: 做的努力与业务的期望不符。可以从“99.92%的可用性意味着什么”的讨论入手，
逐步解决业务部门和 IT 对可用性的认知，这有利于进行可用性的其他方面的讨论，如
业务时间与可用性级别的关系，什么时段可以进行计划宕机，响应时间是否作为可用
性衡量指标，以及从客户感知角度的服务不可用等。

HP Services
Assessment
3.6 可用性管理：设计和实施
1 改进供应商管理
W 供应商管理（对内外部的供应商）应当就位，以助于了解可维护性和可服务性的成熟
hy: 度。为保证按照 SLA 的承诺交付可用性，内外部两种供应商都需要被管理，以确保他
们各自的交付部分可以支撑 SLA。
2 需要采用下列的工具，以提高可用性管理方法的效率：如故障树分析（Fault
Tree Analysis），组件失效影响分析（ Component Failure Impact
Analysis），风险评估（Risk Assessment and Management Method）
W 故障树分析（Fault Tree Analysis），组件失效影响分析（Component Failure
hy: Impact Analysis）和风险评估（Risk Assessment and Management
Method）对于设计正确的可用性级别是很重要的。IT 部门需要知道对于一个服务，
哪个组件是关键的，是否有单点故障以及是否有薄弱环节，从而清楚需要做什么工作
以确保组件和服务的可用性。这就意味着一个全面集成的配置管理数据库（CMDB）
可以有效地提供服务视图，及相关 User Profile 和业务活动模式（PBA）。

HP Services
Assessment
3.7 可用性管理：管理和改进
1 需要采用下列的工具，以提高可用性管理方法的效率：如故障树分析（Fault
Tree Analysis），组件失效影响分析（ Component Failure Impact
Analysis），风险评估（RAMM），事件生命周期衡量方法（ILMM）和系统
停机分析（ SOA）
W FTA、CFIA、RAMM、ILMM 和 SOA 对保证正常水平的可用性非常重要。这需要知道
hy: 哪些组件是关键的，是否存在单点故障，是否容易遭受攻击，帮助我们理解为了保证
组件和相应服务的可用性，哪些是需要做的。并且也需要知道事件打开了多长时间和
如何去解决。其他的有关变更、发布和问题管理的 KPI 报告也需要不断的进行 SOA 分
析；这些都意味着需要一个全面集成的 CMDB 来提供一个和事件、问题、变更、发布
相关联的服务视图。

HP Services
Assessment
3.8 支持流程
1 设计和实施服务级别管理流程，并将其与容量和可用性管理紧密集成
W 服务级别管理是保证容量管理策略执行效率和效果的关键支撑流程，因为它可以建立
hy: 一个执行需求管理的平台。如果没有服务级别管理，容量管理将不能有效地管理客户
需求和用户满意度。因此，设计和实施服务级别管理流程并将其与容量管理集成是至
关重要的。
服务级别管理是保证可用性管理策略执行效率和效果的关键支撑流程，因为它可以建
立一个执行需求管理、可维护性（OLA 可覆盖）、可服务性（UC 可覆盖）的平台。如
果没有服务级别管理，容量管理将不能有效地管理客户需求和用户满意度。因此，设
计和实施服务级别管理流程，并将其与可用性管理集成是至关重要的。
2 建立整个 IT 组织层面的变更管理流程，并使其与 PMO 紧密配合
W 建立整个 IT 组织层面的变更管理流程是另外一个需要重点改善和提高的方面。变更实
hy: 施时可以将几个部门集成在一起，消除目前孤立的变更管理方式，从而保证各个项目
可以和服务管理（如服务设计和服务上线）紧密的结合起来（这需要和项目管理办公
室 PMO 的紧密配合）。
需要这样做的原因是：可以保证所有生产环境变更引发的容量需求对整个 IT 层面是可
见可控，而不是分散在各个部门。这将更容易在整个 IT 层面来统一管理变更和降低非
计划停机的风险。
3 改进发布管理流程
W 平安保险 IT 的发布管理需要更加成熟，在发布实施过程中集成各部门，消除孤立的发
hy: 布管理方法，这样才能给容量管理提供相对稳定的环境，以获取更准确的数据点来分
析系统的性能和更好的容量预测；为了保证更稳定、更高可用性的系统或者减少非计
划停机的风险，必须使得不同系统的发布能进行很好的协调并制定发布策略，保证发
布到生产环境的次数是合适的。
4 确保对 IT 组织和服务中关于可用性及容量管理的风险能够被正式地识别和管理
W 平安保险 IT 应当通过以下方式，保证对 IT 组织和服务中关于可用性及容量管理的风险
hy: 能够被正式地识别和管理：
•保证风险和影响的评估通过变更和发布管理得以执行；
•改善问题管理，使得容量和可用性的问题能够被有效的分析和解决
5 建立财务管理
W 财务管理对容量和可用性管理都有重要的影响。预算影响资源采购的决策；要建立差
hy: 异化的成本分摊，必须知道成本计算方法；要了解容量短缺和不可用引起的有形和无
形的影响，财务管理必须要进行相应成本计算。因此：
•财务计划至少每年都要生成一次，并应当结合业务预测、IT 容量需求和可以支持整个 IT 服务管
理的执行
•成本模型应该被引入，以计算出容量及可用性问题导致的服务不可用带来的实际影响
•成本分摊应该可以在未来根据可用性需求，逐步改变用户的行为模式。
6 确保有一组集成的 IT 服务管理工具
W 虽然这一点放在最后，但也许是最重要的一点：确保有一组集成的 IT 服务管理工具能
hy: 够有效的共享数据和集成流程。可用性管理的能力依赖于其他内部和外部供应商流程
的成熟度。流程成熟度依赖于流程的自动化：这包含一个集成的 CMDB，提供一个端

HP Services
Assessment
3.8 支持流程
到端的服务树视图，包含所有配置项和服务资产的支持信息

HP Services
Assessment
4 下一步工作
一般来说，对服务交付的改进应通过一个服务改进计划（SIP，Service Improvement Programme）进
行。该计划需要斟酌本报告第三章中的建议，并对其进行优先级及进度的排序。关于在服务改进计划中如
何利用本报告，下列主要步骤可供参考：
• 平安保险管理层和技术专家对本报告的审阅
• 指定负责改进的一名总体项目经理
• 组织一次研讨会，业务及 IT 代表共同参与，以：
o 讨论报告指出的问题，及其对业务的影响和成本
o 达成解决方案的优先级
• 确保所有受影响的团队和部门都积极参与
上述工作确定之后，平安保险将结果反馈给惠普公司。基于平安保险的决策，惠普公司将主持一
次 SIP 研讨会，主要会议内容包括：
• 运用已接受的建议，总结和最佳实践标准，产生总体改进计划
• 识别和指定每个改进领域中的参与人员，及每个领域的一个负责人
• 改进的设计和执行
• 衡量和报告机制的设计和执行，以确保真正实现了业务收益
之后可以启动服务改进计划 SIP。在 SIP 的执行周期中，平安保险需要：

• 定期回顾计划和改进活动；
• 识别其他需要改进的领域和机会，以确保改进的完整性
在进行一些长期改进时，很重要的是要不断尝试寻找一些“速赢点（quick wins）”，它可以在改进周期
中优先进行，从而维系士气，并容易获得受影响方的支持。
如上所述，惠普将参与 SIP 的规划工作；如果需要，惠普可以协助进行第三章中提到的服务改进活动。

HP Services
Assessment
5 详细差距分析及发现
下面章节描述了惠普公司为平安保险信息管理中心进行的IT 服务管理评估的详细结果，并以EPCIS-Auto服
务为参考依据。
每节的开始部分简要介绍作为评估基准的业界最佳实践，接下来是评估概述，随后的详细差距分析
提供了图表，每行包括如下信息：
 具体标准的编号
 每个最佳实践评估标准的描述
 惠普公司针对每个标准的评估发现
 表示惠普公司评估等级（见表 1）的图形符号
 表明对达到服务可用性的相对重要性的权值
表 1 -详细差距分析中等级的图形符号义
 健全的实践，近乎全面
 可接受的实践，但须进行某些改进
不完善的实践或可能缺少功能。可能对可用性产生负面影响，建议进行
! 改进
!! 较差的实践或缺少重要功能。可能严重影响可用性，建议进行改进
已计划
健全的计划，可能行之有效，而且涉及到所需的大部分领域

已计划
可接受的计划，但难于实施，缺少某些功能或资源不充分

已计划
计划可能很差，有可能无效，或缺少重要的功能
!
已计划
计划可能很差，没有明确存在的问题，缺少问题或问题无效
!!
不适用标准不适用于此服务和/或业务
未评估现场评估期间，未对规范标准进行评估

HP Services
Assessment
6 IT 治理
服务管理体系
6.1.1 最佳实践简介
取决于业务需求的IT 策略应就位，并作为IT 管理决策的基础。应建立一整套符合业界标准的IT 服务管理
流程，包括合适的服务方针政策、服务计划和相应的支撑文档，以确保IT 部门工作的持续提升。
6.1.2 评估发现概述
存在关于可用性和容量管理的战略。根据平安保险 CIO 罗总的策略，IT 组织需要面向服务文化，变革成为
一个 IT 服务提供组织。这意味着需要建立一套正规的、可重复的可用性及相关支持流程（包括容量管理）
的方法，并能被 IT 各部门包括业务所应用。平安保险已经准备好进行必要、可取的流程及现状变革。
平安保险 IT 组织已经具有服务支持和服务运维的流程和方针政策，但其成熟度仍有待提高；目前有很少或
成熟度很低的服务交付流程，如服务级别管理，容量管理和可用性管理。
平安保险 IT 组织正在进一步利用业界最佳实践（如 ITIL）和 ISO20000 标准建立服务管理体系，并获取和

建立适当的工具来协同管理，然而相关数据需要更好地整合。
目前没有正式记录的服务组合策略和服务目录；针对提供的不同服务，没有明确 IT 和业务之间的职责。

HP Services
Assessment
6.1.3 详细差距分析
服务管理体系标准 HP 评估等级权重
IT 策略
1 IT 战略包含服务管理的 • 已按照 ITIL 标准建立服务支持流程，如事件、高
方法论（如IT基础架构问题、变更、配置、发布管理流程等

知识库-ITIL、微软营运 • IT 战略包括 ITIL 方法论，并计划按照
架构-MOF、COBIT、 ISO20000 建立服务管理体系，在未来通过
惠普IT 服务管理参考模 ISO20000 认证
型-ITSM）。
2 有进行IT 服务管理所需 • 已采用以下工具：
要的工具，并可以有效  基础架构管理部使用 HP OVSD 管理四个
! 低
的共享数据和对流程进服务支持流程，事件、问题、变更和配置
行集成。管理等
 IT 用户使用自主开发的工具 ITSM Portal
提交事件，IT 人员使用该工具进行事件管
理
 有各种监控和问题诊断工具
 这些工具之间在部分点上有集成，数据共
享只体现在‘记录’级别－只是为了服务
支持流程，对服务交付流程的支持不够。
• CMDB 由基础架构管理部维护，整个 IT 部门
都可查看，但 CMDB 中的属性没有完全使用，
有些属性为空白，部分应用的 CI 信息不是最
新的

HP Services
Assessment
服务管理体系标准 HP 评估等级权重
IT 服务目录
3 • 目前没有 IT 服务目录
服务级别管理流程维护
• 没有服务级别管理流程和服务级别协议
! 高
了全面的 IT 服务目录，
并正式地被业务部门所 •
认可。 •
运营部门内部设定了可用性的服务级别目标，
已实行了一年，这些目标没有与业务正式达
成一致，业务也不很理解和关心 IT 定义的可
用性目标，目前这些内容不足以管理服务级
别协议
4 • 没有服务目录
有服务目录、或其他文
• 没有正规的机制或流程使得 IT 从业务获得业
! 高
档标示了业务流程、IT
服务和应用之间的关系，务数据
并用于支持容量和可用• 业务流程和业务活动没有按正规方式文档化，没
性管理。有将业务流程和相应活动转化为可用于容量预测、
计划和监控的业务活动模式（PBA）
• 存在业务流程与业务活动、IT 组件之间的对应关
系，但这些比较分散，信息也不能保证是最新的
• 用户数和交易量以日志的形式保存在 EPCIS-
AUTO 的日志文件中，但这些信息没有整理成一
定格式的报告。目前业务部门认为只需要交易的
总数就够了，不需要按不同用户区分交易量(陈
亚殊) （已解答）
• 业务部门认为有保存和维护 IT 用户与 IT 服务对
照关系表
5 关键的 IT 服务与业务达• 有应用系统清单（EPCIS-AUTO, EPCIS-RMS,
! 中
成一致并文档化。 ELS-NBS 等），没有详细到流程活动级别，定
义及区分了关键系统与非关键系统，但和业务部
门没有协议（陈亚殊：是否 IT 服务经理有和用户
达成一致？）需要朱 mm 确认
• 对重要系统而言，IT 根据经验知道重要子系统
（VBF）及非重要子系统
风险管理
6 正式识别和管理了 IT 组• 没有集中化的风险清单（具体涵义是什么？），
! 中
织和 IT 服务的风险。从业务角度看，风险分析只是按个案处理，从 IT
角度看，但重大事件或相关问题发生后会识别和
关注风险，IT 会将风险通知业务部门
• 通过了 ISO17799 认证，从信息安全的角度分析
过风险

HP Services
Assessment
业务关系管理
业务关系管理用于主动征询业务需求，并采取主动的方式找到能够提升IT 对业务的价值，和减少成本的机
会。客户满意度应该被定期了解并解决发现的问题。
在本领域所提到的业务是指包含IT 管理在内的所有公司实体或组织，这里所提到的用户是指所有使用
服务的人，包括最终用户和公司内部的业务部门。
6.1.5 评估概述
通过访谈了解到平安保险 IT 部门努力做到业务要求的所有需求，没有太多证据说明 IT 部门正尝试积极地与
业务部门建立合作伙伴关系，从而导致这方面没有改善。IT 部门全力保证系统运行正常。目前，与业务部
门的关系主要体现在业务部门在应用系统开发初期收集需求时和后期的 UAT 测试阶段的介入，没有发现与
业务部门建立长期的关系。
业务关系管理标准 HP 评估等级权重
业务关系管理
1 明确IT 基础架构和IT 服 • 没有正式的业务关系管理流程
务对应的不同业务对象 • 每个业务系列有应用系统组（是否指运营
! 高
（包括最终客户和用的应用服务组？）负责收集业务需求，并
户），并且和这些业务与 IT 开发部门沟通协商这些需求，主要集
对象建立起不同层次的中在功能需求方面（名称有误，需修正）
关系。 • IT 监察委员会负责监督服务质量并跟踪后
续行动
• 没有专人或小组负责服务级别协议的协商
2 IT 管理团队和高层业务 • CIO 与业务部门高层举行定期例会，确保高
经理有例行的讨论会， IT 全面了解业务需求

以便保证业务对IT 的需
求被广泛理解。

HP Services
Assessment
服务规划
服务规划主要针对一个(IT)新服务、新的服务部署工作的引入或对已有服务的重大改变和调整工作。
该工作应该由专人或一个小组根据文档化的流程进行有效管理。此工作需要使用的项目管理方法论及相关
工具，同时项目计划将受制于变更控制流程的要求。服务规划的范围涉及完整的端到端服务架构，包括实
现它所需要的设计、技术和流程环节，乃至针对实施人员和最终用户的相关培训工作。服务相关的文档和
配置管理数据必须根据上线流程的要求及时更新，这样才能被其他相关流程所使用和参考。服务规划还必
须有确保服务的可操作性以及订制客户验收测试方法的内容。在服务上线的完成阶段实施回顾总结工作也
是必不可少的。
6.1.8 评估概述
在平安保险没有发现服务规划功能。IT 部门在这方面采用一种片面的方法，保证系统运行可用，尽最大效
率预防系统宕机。虽然 IT 部门的动机也是正确的，但它不能弥补服务规划的欠缺。IT 部门更多的关注了“
让灯一直亮着”这样的短期利益，但长期来看，当业务需求增加、IT 部门被要求投入更少，产出更多时，
现有的方式将不适合。IT 将不得不被业务需要触发而开始开发服务、管理服务，这需要大量的规划和建设。
目前，这方面没有被组织关注。如果希望容量和可用性管理在平安保险 IT 得到很好地应用，服务规划是必
不可少的。因此，容量和可用性管理最好从服务规划开始入手。
服务规划标准 HP 评估等级权重
总体服务规划流程
1 采用正式的项目管理方 • 采用 CMMI 管理项目开发高
法来管理一个服务或一 • 在公司层面没有正式的项目管理方法，但

个服务实例的引入和撤有些项目经理具有 PMP 或其他项目管理
销、现有服务的重大变认证。
更或其他重要的、影响
开发的服务工作。
2 项目管理要与服务管理 • 没有正式的流程了解端到端的服务负载
的其他方面紧密集成， • 开发部门在需求收集阶段收集业务量和响
! 中
如可用性和容量管理。应时间等需求，但这些用于开发阶段的生
产系统性能评估
• 基于设计说明书在 Staging 环境执行压力
测试
• 没有正规的方法执行可用性和容量管理的
分析，每个小组根据经验或类比的方法估
算容量（如与已有类似的系统做比较），
也使用简单的公式进行计算
• 没有正规的渠道收集业务预测数据，IT 不
清楚职责和应该介入的人员

HP Services
Assessment
服务规划标准 HP 评估等级权重
项目启动
3 每个项目的范围包括性 • 新开发的系统和重大变更的系统会执行压中
能和压力的测试。力和性能测试

• 测试部门根据设计阶段的标准，在
Staging 环境进行压力测试
• 没有对比关系或公式能够从 Staging 的测
试结果来预测生产系统的性能

HP Services
Assessment
7 技术
物理环境
提供服务的IT 基础架构设备应置于合适的环境中。该环境能够保障系统持续运行，并阻止未经授权的访问。
一般情况下，这需要配备一个专用、安全的计算机室，由一个人或一个小组进行总体管理。关键环境控制
系统包括：火灾探测与灭火；电源与配电；加热、通风及空调，可为所放置的设备提供一个一致、安全、
适宜的环境，并有足够的冗余能力应付单点故障、满足预期容量发展。成熟的运营实践、突发事件管理、
问题管理及变更管理流程将投入使用，同时还将签订相应的合同及服务级别协议，以确保环境设施得以妥
善地维护。
7.1.2 评估概述
数据中心位于深圳观澜，于 2005 年投入使用，并在上海建有灾备中心。
通过与数据中心项目经理的访谈，平安保险数据中心设施管理完善，会适当的对空调，网络，地板承载，
电力，备份发电机等进行定期检查。数据中心遵循变更管理的严格规定，确保所有进入数据中心的系统根
据规定进行严格的检查。设备的购置会超过预期的计划，因此数据中心的容量会比原计划提前满载，DC
组已经知道这种情况并会提前计划。
物理环境标准 HP 评估等级权重
物理环境的配置和文档
1 关键业务所使用的服务 • 可以确保有足够的空间安放关键设备中
器、存储设备和核心网

络组件放置在专门的机
房内。
2 确认地板的承载量没有 • 满足，通过日常的检查使地板承载容量维中
超过。护在负荷以下

电力供应和传输
3 在可能的情况下，配备 • 数据中心相应岗位负责配备备用发电装置中
有备用发电装置为关键为空调，网络及其他关键设备供电

设备（包括空调、网络
等）供电。
4 有足够的电源供应以满 • 电源需求可以满足，预计可以使用到基本的
足当前的需求，包括对 2009 年

配置有双冗余电源的设
备的供电。
5 每个设备组件对应的电 • 满足低
源要求都有文档记录。


HP Services
Assessment
物理环境标准 HP 评估等级权重
空调
6 当一般的、可预测的失 • 满足中
败发生时，温湿度将被

维护在可接受的限制范
围内。
7 检查确认设备产生的热 • 满足中
量没有超过空调设备的

容量。
物理环境的变更管理
8 总体 IT 变更管理流程用 • 通过变更管理有效地管理生产环境的变更中
于管理生产环境的变更。

9 任何小组实施的变更都 • 满足，所有变更需要经过数据中心负责人中
应该咨询后勤/机房的管的审批

理者以确保变更被正确
评估。
10 有文档化的流程控制新 • 满足中
的服务器和存储设备的

安装，包括评估机房空
间需求、热量输出、电
源需求等。
物理环境的事件监控
11 有统一的建筑物（大楼） • 满足，有机房管理系统 BMS Low
管理系统，监控所有的

环境情况。
物理环境的支持
12 在机房设施部门和 IT 部 • 信息管理中心负责数据中心的管理中
门之间有一份正式协议。 • 新的数据中心按照 99.999％的可用性建

设，DC 组承诺的机房可用性目标为
99.95%
13 记录环境数据的历史信 • 数据中心投入使用后的监控告警的历史记低
息并进行趋势分析，以录完整保留在 BMS 系统中，用来做趋势

支持容量管理和事件管分析，以支持容量管理和事件管理
理。
14 机房环境有相应的生产 • 对新投入使用的数据中心，DC team 有中
能力（容量）计划，包

容量计划，并且每年审核
括：电源、空调和机房 • 当前的数据中心有足够的容量，最初设计
空间需求。该计划预留数据中心时预计在 10 年中每年增长
了足够的时间段，以购 10％. 但实际增长更快（大约 20％每年），
买或构建需要的设施。
数据中心容量可能会不足。
• 预计在 2009 年数据中心的电源供应紧张，
2010 年会出现空调制冷不够用。DC 组
已经开始计划

HP Services
Assessment

HP Services
Assessment
服务器、存储平台和操作系统
服务器、存储平台和操作系统的设计、配置和安装应达到到较高的标准，并能实现服务级别协议中做出的
承诺。根据厂商的定义，配置应有效，而且单点故障应不至影响服务级别协议。所有的软件和固件都有适
当的使用许可证。文档应准确无误，并将定期维护。根据安全策略的规定，启用安全特性，同时采用适合
的备份策略，防止数据丢失。必须使用标准的软件构造流程。成熟的运营实践、突发事件管理、问题管理
及变更管理流程将投入使用，同时还将签订相应的合同及服务级别协议，以确保软、硬件设施得以妥善维
护
7.1.5 评估概述
服务器、存储和操作系统的管理策略和实践总体上满足要求，制定了基于 N-Tier 架构的标准架构设计策略，
N-Tier 架构由 Web 服务器、应用服务器，数据库服务器和后援系统组成。系统之间保持互连并利于扩展以
满足未来业务增长的需要。N-Tier 架构允许应用层级扩充，支持负载均衡和故障切换。EPCIS Auto 系统
支持容错，但该系统还需要连接其他后援系统，目前不是所有的后援系统都有冗余设计，因此存在部分的
单点故障。使用了一些最新技术保证冗余和容错可以与系统集成，数据库使用 RAC 来保证数据库的故障切
换。某些系统的缺陷（例如，部分后援系统的单点故障）已和业务部门沟通，业务部门了解了系统的某些
技术限制。IT 使用变更管理和适当的审批流程来保证操作是经过授权和控制的。
目前有测试环境（staging），但没有在生产和测试环境之间总结建立一个比例缩放关系。因此，测试环
境作为功能测试是完全没有问题的，但压力测试的结果不能与生产环境产生很好的关联关系。

HP Services
Assessment
服务器、存储设备和
HP 评估等级权重
系统软件标准
服务器存储设备和系统
软件设计和配置
1 服务器硬件已经被配置， • 满足，基础架构定义了这些标准高
拥有足够的冗余、失败

恢复能力度量标准，以
满足可用性和性能要求；
例如，冗余电源、双网
卡、多处理器、在服务
器间的 IP 失败恢复（迁
移）。
2 存储设备已经被配置， • 存储设备已经被配置，拥有足够的冗余、高
拥有足够的冗余、失败失败恢复能力度量标准

恢复能力度量标准，以
满足可用性和性能要求；
例如，适当的 RAID 技
术、Hot Spares、双
控制器以及双电源。
3 系统软件已经使用了适 • 满足。平安保险要求一个可扩充平台以满高
当的措施和恢复技术进足业务增长需要，目前的 N-tier 架构提供

行配置，以满足可用性集群技术和负载均衡
和性能的要求；如，集
群、网络负载均衡，或
自动服务重启。
4 系统和存储设备间的连 • 满足。N-Tier 架构支持冗余和故障切换。中
接，以及存储设备间的 IT 架构设计遵循标准架构，并由规划部门

互连都有足够级别的冗进行审核
余设计，以满足可用性
的要求；例如：多路径
和不同路由（物理走线
不同）。
5 任何设计限制都充分沟 • 重要系统设计上的已知限制已经和业务部中
通过，并被业务部门所

门沟通过
接受；例如，特定的单 • 连接后援系统和合作伙伴有一些单点故障
点失败或性能瓶颈。存在
服务器存储系统软件实
施
6 对整个系统上线运行或 • 有正式的上线和下线系统的流程管理中
撤销，应当严格遵循相

关工作步骤执行。

HP Services
Assessment
系统软件标准
服务器存储系统软件文
档
7 记录了关键系统组件的 • 关键系统组件的使用情况被记录并维护。中
使用情况，并维护这些但 PCI 端口，内存插槽等信息没有记录在

记录；例如，现被使用 CMDB，这些记录保存在个人手上
的交换端口数量、可用
于磁盘、内存扩充的插
槽情况等。
8 使用许可证信息都被合 • 没有评估未评估中
适地记录，并且在需要
时可用。
服务器存储系统软件变
更管理
9 总体的 IT 变更管理流程 • 满足中
被用于管理生产环境中

的硬件变更。
10 • 用于测试变更的 Staging 环境也用来测试
一个富有代表性的测试
性能，但测试环境和生产环境不一致，不
! 低
环境可用于测试变更。
能完全代表生产环境（很难得出
staging 和生产环境的准确对比关系）

HP Services
Assessment
系统软件标准
性能和容量
11 监控性能，分析历史趋 • 被动方式的性能监控和趋势分析，主要为高
势，保证在服务受影响

了进行故障和问题分析
之前发现问题、采取行 • 因为有许多服务器需要管理，收集的信息
动。没有和用户需求（User Demand）建立
关联
12 基于历史趋势，定期执 • 有月度的性能分析报告和优化建议中
行性能优化。

• 性能优化是按照个案处理的
13 定期评审文件系统的存 • 未评估未评估中
储要求。
14 系统的性能稳定在可接 • 系统的性能稳定在可接受的限度 ! 中
受的限度，峰值很少。 • 很多应用使用 EPCIS 数据库，例如 EPCI-
auto, autoclaim,epcis-upc, epcis-
claimioc, epcis-maq, epcis-laas,
rateset 等等。
• EPCI-auto 应用没有特定的数据库
• EPCIS 的 DB 服务器（HP 8420）配置有
32 个 CPU 和 96GB 内存，只有一个
oracle 实例，在业务高峰期时可能会有性
能问题
15 对于可能会影响实现服 • 可以快速检测并标识系统性能问题，这是高
务级别需求的性能问题，

事件管理的一部分。虽然没有和服务等级
能被快速地检测并标识关联，但可以关联到事件管理的优先级
出来。 • 有专门的重大故障处理流程
16 使用合适的系统性能监 • 使用合适的系统性能监视和基本的分析工基本的
视和分析工具，并且各

具，如 OVPM
成员会使用。 • IT 员工有能力使用并可以开发脚本
事件监控
17 可快速侦测和标示影响 • 有工具可以检测和标示影响服务的系统或高
服务的系统软件故障或组件故障，标示系统性能下降的能力不是

性能问题。很突出，管理系统故障是合适的
18 阈值和事件被定期评估，
• 没有正式的流程回顾和调整阀值的设置， ! 中
针对反馈也采取行动，
每个小组负责关注自己的范围的监控需要
以保证监控的合理性。

HP Services
Assessment
系统软件标准
例行维护
19 适当的时间间隔，检查低
文件系统的碎片、一致
• Tier1 负责根据日常工作指引检查文件系 
统，将异常汇报到 server team
性和可用空间，当有需
要时采取行动。 • 使用 OVO 每 5 分钟监控一次文件系统
20 确定了系统进行定期维 • IT 部门已定义了维护窗口，并得到业务部中
护的机制。这些维护时

门的批准
间段已经得到了业务部 • 维护窗口的时间是每天 23：00－1：
门的批准，用于实施例 00am（系统宕机维护必须提出申请和批
如固件升级和定期组件准，维护时间不计入可用时间）
更换 , ，软件或 patch • 例如：星期一和星期三窗口用于维护
升级，系统调优等工作。

HP Services
Assessment
应用和数据库
应用程序和数据库软件管理能够实现服务级别协议中的承诺，安装和配置应达到很高的标准。配置应当合
理有效，根据厂商的要求进行并得到相应的确认，单点故障不应影响服务级别协议。应用程序和数据库应
根据 IT 安全策略启用相应的安全机制，运用日志／检查点等手段以确保数据的一致性，制定合适的备份策
略防止数据丢失。应用程序和数据库文档应准确无误，及时维护。成熟的运营实践、突发事件管理以及问
题管理流程投入使用，应用程序和数据库软件，以及数据库数据的变更应纳入变更管理流程。为确保应用
程序和数据库软件得到正确的维护，需要签定正式的合同和服务级别协议
7.1.8 评估概述
生产环境的应用和数据库都有充分的设置和监控，从运营角度来看，平安保险 IT 的应用和数据库已经满足
标准。但由于没有建立服务级别协议（SLA），这些内容没有整合在一起，无法提供一个完整的服务视图。
例如，当出现性能瓶颈、故障切换时的交易丢失等情况时，可能不会正式通知业务部门。测试环境和生产
环境的性能容量对比关系没有建立。生产系统的变更较为频繁（每月 2 次的版本发布和不定的紧急版本发
布），生产环境不断变化导致容量分析和预估的困难。Web server access log 保存了足够的性能数据，
但缺少足够的分析来提供容量管理中需要的用户模式数据和用户响应。通过对这些日志中的数据挖掘，应
该可以反映出可能的业务峰值时间点和在该时间点的性能，并与后端系统（DB）的日志相匹配，来预测性
能的趋势。
在数据库优化方面，TOP SQL 会报告给开发部门，由开发部门分析和优化 SQL 语句来提高系统性能。由
于缺乏从整体服务的角度进行性能的分析，当月末交易量非常高的时候，DB 和应用团队会继续面临性能问
题。另外一个对性能分析产生影响的是系统环境非常复杂（例如，Web 服务器共享运行了多个支持其他应
用的 Web 实例，应用服务器集群中的 APP server 也同时共享运行了多个实例），在这种环境下，由于实
例相互之间的影响而进行性能分析是非常困难的。
EPCIS Auto 应用没有建立归档策略，意味着已经积累了超过 2 年的数据，这会造成潜在的性能延迟，使
查询越来越慢。目前应用和数据库的监控主要用于基本的运行维护，保障服务的正常运行。但平安保险 IT
关心未来容量需求的分析方法，而不仅仅在于保障服务等级。

HP Services
Assessment
应用和数据库标准 HP 评估等级权重
应用和数据库及其配置
1 为满足可用性和性能的 • 应用系统是基于 J2EE 架构高
要求，应用程序和数据

• 应用和数据库根据可用性和性能的需要进
库软件使用了相应的配行配置，应用使用集群技术保证故障切换
置措施和恢复技术；例和负载均衡，Web 服务器使用 F5 做负载
如，使用日志文件、数均衡，数据库使用 ORACLE RAC 技术
据库复制、负载均衡和
服务自动重启。
2 应用程序和数据库中任 • 应用程序和数据库中任何已知的设计限制 ! 中
何已知的设计限制已经已经在设计阶段和业务部门沟通并被认可，
和业务部门沟通并被认在 UAT 测试阶段，用户代表参与测试案例
可；例如，许可证不够编写和在投入生产之前负责签署版本
特定的单点故障、性能 • 由于没有和业务部门签署正式的 SLA，对
瓶颈和恢复时丢失交易。性能瓶颈和切换时丢失交易不会有正式地
达成一致意见
应用和数据库的文档
3 有文档清晰的记录服务 • 服务组件关系和依赖保存在 OVSD 中
组件之间的连接关系和

CMDB，但并不详细
依赖关系。 • 开发了一些 Web 视图来展现组件之间的
关系，各个小组都可以使用

HP Services
Assessment
应用和数据库的变更管
理
4 总体的 IT 变更管理流程 • 存在 2 个流程（发布和变更）可以覆盖生低
用于管理生产环境中应

产环境的全部变更
用程序，数据库软件或 • 基础架构发起的变更（服务器、DB、中
数据的变更。间件）遵循 ITIL 的变更管理流程
• 软件变更遵循 CMMI 软件变更管理和版本
管理流程（系统运营部根据 ITIL 实践制定
了版本管理流程）。在软件版本发布到生
产环境时，如果需要基础架构部门准备环
境时，运营部门会提交服务请求到基础架
构部。
5 具有代表性的测试环境 • 有测试环境（Staging 环境）用于测试变 ! 中
用于测试变更。更，Staging 环境完全支持功能性测试，
但容量和性能和生产环境有差异，会导致
一些问题。
6 对应用程序或应用程序 • 对于新版本或大版本变更，有正式的应用 ! 中
相关的基础架构的变更测试流程，包含回归测试和性能测试，使
测试能够保证服务级别用一些自动的测试脚本，压力测试使用
在变更后得到满足；例 LoadRunner
如：适当的回归测试、 • 对是否进行压力测试和性能测试没有严格
压力测试、性能测试，的要求
使用自动的测试脚本。
• 一些大的变更上线后，会使用一些自动执
行的脚本测试应用的可用性
• 对新系统和重大变更的系统进行性能和压
力测试

HP Services
Assessment
应用和数据库的性能和
容量
7 [Database]
监控性能，分析历史趋 ! 高
势，保证在服务受影响 • DB 组监控和分析数据库性能，报告那些
之前发现问题、采取行消耗数据库资源的 TOP SQL，用于发现
动。问题，降低风险
• DB 组使用 APM 工具和 OVO 监控数据库，
APM 采集的数据可以有效地作为异常分析
（监控 CPU, IO calls, wait state 等）
• 有时新版本上线和紧急版本上线会引发数
据库性能问题
[Application]
• Web server access logs 保存这些信息
（date、time、交易时间、用户名、JSP
URL 和 Session id 等）
• Web 日志里的信息可用来分析用户需求
模式，但这些数据没有经过解析作为分析
报告使用
8 按照数据库或应用程序 • 没有正式的流程用于定期的性能优化，也 ! 中
供应商的建议，执行例没有正式的流程用于执行厂家的建议
行的性能优化。 • 目前观察到的数据库优化只是 TOP
SQL，逻辑读写、物理读写等
9 定期评审应用程序和数 • DB 组定期评审表空间的需求中
据库的存储要求。

• DB 组每月维护和监控表空间
10 应用程序和数据库性能
• 月底可能会引起应用和数据库性能问题， ! 中
稳定在可接受的限度内，
因此，高峰是周期性的（经过分析）。共
很少出现可能对正常服
享基础设施模型对性能分析比较困难
务形成威胁的峰值。
11 可以快速检测并定位应 • 有监控工具可以快速检测和定位程序和数 ! 高
用程序和数据库不满足据库问题。但由于没有建立专门的以服务
服务级别要求的性能问为中心的容量分析团队，问题的解决和修
题。正不是很容易，目前的性能分析是孤立的
12 有认可的、合适的归档 Planned 低
策略，并被主动地执行。 • 目前没有归档策略，但已在计划中

13 定义了用户合适的存储 • 没有用户存储定额定义和监控管理 ! 低
定额并对其进行监控管 • 由于没有 SLA，所以没有正式的需求管理
理，确保足够的资源满策略（例如，某个服务需要关闭以确保另
足服务级别的要求。一个服务有更高的级别，没有正式的机制
与业务沟通）

HP Services
Assessment
14 有合适的系统性能监控 • 有合适的系统性能监控和分析工具，相关中
和分析工具，相关人员

人员能够熟练使用（Web access log,
能够熟练使用。开发的脚本，APM for oracle, APM for
J2EE 也即将投入使用）
• 员工可以熟练使用并根据监控要求开发额
外的脚本
应用和数据库的事件监
控
15 监控应用程序和数据库 • 监控应用程序和数据库软件，能够快速检高
软件，能够快速检测出

测出应用程序和数据库软件故障或服务性
应用程序和数据库软件能的下降。
故障或服务性能的下降。
16 阈值和事件被定期评估， • 没有正式的流程回顾和调整阀值的设置， ! 中
采取相应跟进措施，以每个小组关注自身范围的监控需要
保证监控的合理性。

HP Services
Assessment
网络
包含系统间连接、局域网及 WAN 组件在内的网络的设计和安装应达到较高的标准，并能实现服务级别协议
中做出的承诺。根据厂商的定义，配置应有效，而且单点故障应不至影响服务级别协议。文档应准确无误，
并定期维护。成熟的运营实践、突发事件管理、问题管理及变更管理流程将投入使用，同时还将签订相应
的合同及服务级别协议，以确保网络得以妥善维护。
7.1.11 评估概述
网络组负责局域网和广域网的管理。局域网适当的冗余设计保证故障切换。有两个独立的电信服务商提供
WAN 链路租用。平安保险 IT 和电信服务商签订了合适的服务级别协议，并保证一条 WAN 链路断时，可以
自动切换到另一条 WAN 链路。WAN 的设计可以支持 99.97%的可用率目标。使用 OVSD CMDB 存储网
络信息，网络监控使用 SolarWinds，可以充分监控性能阀值。事件监控使用 OVO 和 NNM，并与运维管
理相集成。

HP Services
Assessment
网络标准 HP 评估等级权重
网络的设计和配置
1 局域网设备（如路由器、 • 平安保险 IT 的高可用架构（HA）同样应高
交换机）的配置，拥有

用于网络架构的设计，局域网设备的配置，
足够的冗余、失败恢复拥有足够的冗余、故障恢复能力，以满足
能力，以满足可用性和可用性和性能要求
性能要求；例如，配置
了冗余电源、多路由模
块、双网卡等。
2 广域网设备的配置，拥 • 分别有 2 个电信服务提供商提供 WAN 双高
有足够的冗余、失败恢

重链路
复能力，以满足可用性 • 广域网设备的配置，拥有足够的冗余、故
和性能要求；例如，配障恢复能力，以满足可用性和性能要求
置了冗余电源、多路由
模块、双网卡等。
3 路由器和交换机间的连 • 没有专门评估中
接、互连都有足够级别

的冗余设计，以满足可
用性的要求；例如：使
用了多路径，以及线缆
被分散分布
（diversely
routed）（避免单点故
障）。
4 任何设计限制都充分沟中
通过，并被业务部门所 • 单点故障的分析方法是基于维护人员的经

接受；例如，特定的单验
点失败或网络瓶颈。
网络的变更管理
5 总体的 IT 变更管理流程 • 满足，有足够的变更管理流程用于管理网中
被用于管理生产环境中

络中的变更
的硬件变更。
6 一个富有代表性的测试 • 没有评估未评估低
环境可用于测试变更。

HP Services
Assessment
网络标准 HP 评估等级权重
网络的性能和容量
7 维护反映组件使用率的 • 网络设备的属性存放在 CMDB 中
记录；例如，已被使用

• 网络组使用 SolarWinds 监控网络设备，
的交换机端口数。一些详细的参数是用这个工具管理和收集
的
8 监控性能，分析历史趋 • 每周和每月都会进行性能监控和历史趋势中
势，保证在服务受影响

分析
之前发现问题、采取行 • 网络组每周和每月提供分析报告(如网络带
动。宽使用率分析)，并提供改进建议和相应的
必要措施
9 网络带宽的需求被定期 • 网络组每年做 IT 预算时会评估网络带宽的中
评估。

需求
• 新服务投入使用时，网络组会收集带宽需
求和评估
• 对已有的服务，当出现异常峰值时，网络
组会进行分析并采取必要的措施
10 网络性能通常在可接受 • 网络性能通常在可接受的限度中
的限度，只有很少的可

• 网络组设置了带宽利用率到 70％时发出
能影响总体性能的峰值告警，Tier1 和 Tier2 负责日常的监控，
出现。 Tier1 负责 24×7 的监控
11 对于可能会影响实现服高
务级别需求的性能问题，
• 网络组设置了相适应的阀值监控，可以快 
速检测并标识网络的性能问题，但没有和
能被快速地检测并标识
SLA 关联（目前没有 SLA）
出来。
12 有合适的系统性能监控 • 平安使用 NNM 和 Solarwinds 监控和分高
和分析工具，相关人员

析网络，相关人员可以熟练使用
能够熟练使用。
网络的事件监控
13 可快速侦测和识别影响 • 平安使用 NNM 和 Solarwinds 监控和分高
服务质量的网络组件故

析网络设备
障。 • 故障处理遵循事件管理流程。网络的冗余
设计保证网络的可用性
14 事件监控被集成在总体 • 事件监控集成在 OVO 系统低
操作管理系统中。

15 阈值和事件被定期评估， • 没有评估未评估中
针对反馈也采取行动，
以保证存在合适的监控。

HP Services
Assessment
8 服务交付
服务级别管理
服务级别管理流程负责确保可实现的服务级别与业务目标相一致，并确保能够始终如一地实现。使用明文
规定的流程，由一个人或一个小组进行管理，即可实现卓有成效的服务级别管理。与业务共同协商可实现
的、成本合理、可测量的服务要求和目标，并将这些要求和目标记录在服务级别协议中。负责执行服务级
别协议的各方都将参与该协议的讨论、签订。内部与外部服务级别协议中的可维护性要求是服务目标制定
的依据。定期对服务目标进行监控，并开展任何必须的改进活动。服务级别应将持续不断地实现，而且应
制定流程定期获得客户反馈。使用管理报告，以便确定服务级别管理流程中需要改进的方面
8.1.2 评估概述
针对 EPCIS AUTO 服务，平安保险 IT 部门与业务部门没有正式的服务级别协议，但 IT 部门的运维流程
（服务支持流程如事件管理、变更管理等）已经非常标准化。因此，事件的解决率、解决时间等都有统计
并报告给业务部门，然而这些属于‘被动报告’。IT 部门还没有采取更主动的方法控制服务。从组织的角
度，这意味着因为没有与业务部门的充分沟通，IT 部门分配了很多资源进行运营，但不晓得这些是否都可
以直接带给业务好处。IT 服务监督委员会负责服务质量的管理，处理客户的问题和投诉并负责跟进，这是
很好的实践但仍属于被动行为。因为没有与业务紧密联合起来，IT 部门尚仍处于被动工作模式，没有主动
模式来摆脱这种循环并真正成为业务可信赖的信息顾问。
目前对事件、变更等的统计都有月报和例会，IT 部门设定了可用性目标并知会业务部门，但没有分析可用
性的级别有益与否，因此，在可用性管理方面，平安保险 IT 可能会对业务的需求承诺过高或过低，IT 内部
各部门虽然有可用性承诺但没有转换为 OLA，在满足容量需求的能力方面 IT 尚停留在花费更多的成本来满
足需求，并没有适当的容量分析和预测工具。评估发现，目前的报告、趋势分析和信息等是严格按照 IT 各
领域生成的，使用对象也是 IT 部门。然而客户应该参与从而确保服务是满足他们需求的，并且客户可以使
用这些报告来预测系统的运行情况。

HP Services
Assessment

HP Services
Assessment
服务级别管理标准 HP 评估等级权重
整体服务级别管理流程
1 服务由服务级别协议 • 与业务部门没有签订关于 EPCIS-AUTO 的
（SLA）定义。可能包服务级别协议
!! 基本的
括一般性的服务产品， • 与业务的主要交流是开发部门在需求收集
或客户特定的服务级别阶段进行的，这些需求用于性能和可用性
协议（SLA）。的目的，但没有定期再进行回顾
• 系统运营部门设定可用性目标，但这不是
基于与业务的协议的
2 • 平安没有实施服务级别管理流程，目前的
IT 部门、业务代表和其
一些协议是基于 IT 和面向 IT（运营）的
! 高
他受影响的各方应当评
估和认可服务级别协议 • 基于 IT 对业务需求的理解，IT 每月向业务
（SLA）。提供服务报告，这些服务报告中包含了关
键系统的可用性以及其他服务支持的指标，
如按照优先级定义的在规定时间内解决的
事件比例等
• IT 监督委员会负责客户的服务质量并跟进
改进情况
3 • 因为缺乏适当的 SLA，所以没有定义 SLA
服务级别协议（SLA）
变更的管理，但对影响生产环境的变更定
! 高
中关于负载、性能或可
用性需求的变更按照变义了变更窗口
更管理流程执行。 •
• IT 与业务每月举行例会，提供服务支持统
计数据。在生产运行期间业务不太可能提
供负载的变化
4 操作级别协约（OLA） • IT 内部各部门不存在 OLA，但系统运营部
存放于所有的内部支持和基础架构管理部对信息管理中心承诺了
! 中
小组，并被评估，以保可用性目标
证服务级别协议SLA） • 基础架构部各小组定义了可用性目标并用
的要求可以满足。于考核；系统运营部同样定义了可用性目
标并用于考核，但部门之间并没有相互承
诺
5 • 性能和可用性需求定义在需求说明文档中
（在开发阶段），应用系统基于这个说明
! 中
中说明了负载、性能和
可用性需求如何衡量，书开发并在测试阶段验证，在系统投产后
并确定了数据的来源。的阶段，系统被监控，与开发相关的问题
会继续解决
• 系统运营部自行设定可用性目标并知会业
务部门，这个目标用于 IT 自己的管理
• 负载需求没有从服务的角度进行处理
6 •
服务级别协议（SLA） IT 部门可能有富余的容量能满足容量目标， ! 中
中所有关于负载、性能系统都是冗余的以满足可用性目标，但缺
和可用性的需求都是可乏足够的规划以确保符合服务级别协议
以达到的。（SLA）或定义的服务级别
7 • 不存在服务级别协议（SLA）。运营部
门向业务部门提供统计报告
! 基本的
的衡量和报告按认可的
方式执行。

HP Services
Assessment
服务级别管理标准 HP 评估等级权重
单个服务的服务级别协
议内容。
8 服务级别协议（SLA） • 服务可用的小时数是基于 IT 与业务的沟通基本的
包括服务可用的小时数。的

9 服务级别协议（SLA）中
包括服务支持时间。
• 服务支持时间是明确并一致认可的 
10 •
服务级别协议（SLA）服务恢复时间是基于 IT 服务连续性管理的 ! 低
包括服务恢复时间。目标，RTO 和 RPO
11 •
服务级别协议（SLA）服务可用性目标由 IT 运营部门定义，不能 ! 中
包括可用性目标。真实的反映业务部门对可用性目标的要求
12 • 负载没有被业务和 IT 定义或跟踪
• 性能在开发阶段定义但投产后没有再进行
! 中
包括负载、性能和可扩
展性需求。回顾
• 可扩展性通过 N-Tie 的架构管理
13 •
服务级别协议（SLA）应急安排可能在服务连续性管理中已经定 ! 中
包括应急安排。义
14 服务级别协议（SLA）
• 业务和 IT 定义了例行维护停机时间段，但 ! 中
包括需要的例行维护停
没有正式的记录在服务级别协议中
机时间段。
15 服务级别协议（SLA） • 虽然没有正式的服务级别协议中
包括在非例行维护窗口（SLA），IT 和业务对非例行维护窗口停

停机的申请流程。机有共识，并有相应的规定进行处理。但
这个活动没有文档化下来，会有一定随意
性
16 • 报告的频度主要是与服务支持流程部分
（如事件管理）相关，这样不足以管理 IT
! 中
中应当正式定义报告的
要求和频度，并包括趋和业务之间的关系
势数据。 • 业务部门没有回顾趋势数据，IT 也没有回
顾端到端服务的趋势数据（从业务活动的
角度）（能否更详细的解释端对端服务的
趋势数据的具体涵义？）（解释：比如：
可用性在未来一个月、或三个月是否不能
达到可用性目标）
17 •
服务级别协议（SLA）时限内事件解决率达到 90%，但这仅是好 ! 基本的
中要求能达到。的服务级别协议的一小部分内容

HP Services
Assessment
财务管理
财务管理流程负责对 IT 资产和提供 IT 服务过程中使用的财务资源进行经济、高效的管理。使用明文规
定的流程，由一个人或一个小组进行管理，即可实现卓有成效的财务管理。有效的财务管理将包括编制预
算、进行 IT 成本核算以及收费（如适合）等主要活动。管理报告将投入使用，以便回顾财务管理流程，
提
高其效率。
8.1.5 评估概述
惠普对平安保险 IT 预算做了很简短的评估，主要了解在预算周期中关于容量预算的流程。目前各技术条线
和开发部门对下一年的预算进行估算，这些估算是技术驱动的，并且大量的估计基于个人的能力，容量增
长的预算没有相关联的文档或依据以说明是为了改善某服务的。
财务管理标准 HP 评估等级权重
整体财务管理流程
1 财务计划由业务预测和 • 未评估 IT 财务管理，但得到以下的输入
IT 容量需求组成，并支  IT 预算根据项目需求每年收集一次
! 高
持总体IT 服务管理  IT 规划部门要求 IT 部门填写并交付各自

ITSM）的实施。这样的的预算要求，如 DB/SERVER 的需求基于
财务计划至少一年产生对照已有系统的规模估算，这些估算多基
一次，并得到审批。于个人或专家的意见
 增加的花费由业务部门承担
2 财务管理与配置管理、 • 未评估未评估低
容量管理、服务级别管
理相结合。
单个IT 服务的财务管理
3 使用清晰的业务术语说 • 虽然未做足够的评估，惠普相信这些信息
明提供每个IT服务所需是宏观的（未详细到每个用户或每笔交易
! 中
的费用，如每个用户的的程度）
成本，每笔交易的成本，
每个客户的花费等。

HP Services
Assessment
可用性管理
可用性管理负责提供业务要求的、并且在服务级别协议中规定的可用性级别。可用性管理与业务紧密配合，
从而确保制定相应的可用性目标，并了解相应的宕机成本。这样一来，即可经济、高效地控制所有可用性
风险，而无论这些风险来自基本的 IT 技术还是面向人员的流程与程序。
使用明文规定的流程，由一个人或一个小组进行管理，即可实现卓有成效的可用性管理。与业务共同协商
可实现的、成本合理、可测量的服务要求和目标，并将这些要求和目标记录在服务级别协议中。识别组成
服务的逻辑和物理组件，并在解决方案中设计并制定相应的对策，以此控制可能带来的可用性风险，确保
能实现可用性目标。内部与外部服务级别协议中的可维护性要求是可用性目标制定的依据。定期对服务目
标进行监控，并开展任何必须的改进活动。将可用性管理与变更管理集成在一起，从而确保能在变更时考
虑到对可用性的影响。采用管理报告，以便确定可用性管理流程中需要改进的方面。
8.1.8 评估概述
惠普了解到平安保险 IT 部门为关键系统确定了可用性目标，IT 部门回顾服务组件的可用性，如网络、服务
器、数据库、应用服务器等，并确定关键服务的可用性，这些信息会与业务部门沟通，最近一年以来 IT 向
业务汇报可用性的数据，优先级最高的重大事件作为服务可用性计算的依据，计划停机时间不记入可用性
计算中。
有与业务讨论确定最小的性能、负载或不同类型用户能访问系统的用户数量等。没有正式的流程评估关于
可用性管理的风险，可用性管理的效率和效果，以及识别可能需要改进的方面。没有与业务部门就宕机的
成本或影响进行分析或记录，因此 IT 可能不了解业务的实际要求，IT 只是根据自己对可用性的认识提供服
务。服务的逻辑组件没有完整的识别和记录，这些信息能为服务提供全面的可用性计划。
平安保险 IT 为服务设定了一系列维护窗口，但不是所有的维护窗口都被使用，当使用维护窗口时，客户会
得到通知，这些计划停机时间将不会计算入可用性中。
IT 内部不同技术领域组自己设定自己的目标并监控这些目标（比如，网络组、应用服务器组、数据库组、
服务器组等）。这些对监控 OLA 标准和考核最为适合，但是，惠普评估团队认为没有建立一个服务可用性
队伍就不能有效地解决业务的可用性需求。（不准确）

HP Services
Assessment

HP Services
Assessment
可用性管理标准 HP 评估等级权重
整体可用性管理流程
1 可用性管理有正式规定 • 平安公司 IT 部门正式定义了可用性管理低
的方针和目标。 
的规定和目标，并已执行了一年多
2 可用性管理有文档化的
流程，并涉及了主要的
• 目前平安公司没有正式的可用性管理流程 !! 中
管理活动。
3 可用性管理有详细的工
作程序或工作规范。
• 目前没有可用性管理有详细的工作程序或 ! 低
工作规范
• 但运营部门做了许多关于可用性的监控、
计算和报告工作，但有些工作不正规
4 对每个服务而言，有专
人负责可用性管理，并
• 没有专人负责每个服务的可用性（还处于 ! 中
初始阶段），这些工作被分布在系统运营
被授权开展此项工作。部和基础架构管理部的每个小组中（这个
专人是指的什么？）这个不准确，像陈亚
殊就是负责 PECIS-AUTO 的可用性的。
5 向业务部门提供例行报 • 为每个分公司提供服务月报，如产险服务高
告，说明每个服务的可 
月报等
用性指标参数、目标和
• 服务报告中包括可用性指标（可用率百分
趋势。
比），但没有可用性的趋势数据（趋势数
据指的是什么？）
6 IT 服务可用性的衡量方
式取决于可用性定义中
• IT 部门使用最高优先级事件来计算服务的 ! 中
不可用，计划停机时间不记入可用性计算，
的相关参数。这是目前的衡量方法
• 平安公司 IT 也使用另外的可用性监控方
法（如采用每隔几分钟去访问应用），但
这不用做可用性计算，只用作监控目的
（这块内容希望做电话沟通）这个不准确
7 可用性目标能够不断达 • 目前 EPCIS-AUTO 系统没有出现重大故基本的
到。 
障，基本达到 IT 定义的可用性目标
8 可用性管理流程是和其 • 与服务支持流程有部分的联系，但没有适 Planned 低
他服务管理流程集成的；
例如，变更管理要求评
当地管理服务交付流程 
• 没有定义正式的可用性管理流程
估变更对IT 服务可用性
的影响，而服务级别管 • 基础架构管理部门正在准备修改变更管理
理要求提供可用性报告。流程，以在变更完成后执行‘可用性验证
’活动

HP Services
Assessment
9 流程本身会关注并记录
总体可用性管理流程执
• 没有正式的可用性管理流程，因此没有可 !! 低
用性计划
行的情况；例如，风险
分析是否及时完成，需
要多大投入，以及可用
性预测的准确度。这
些数据用于评估流程的
有效性和成效性，并标
示需要改进的方面。
业务需求
10 每个服务的可用性目标 • 业务和 IT 对总体的服务时间有共识（如 ! 高
已经正式被业务部门认 24X7, 8X5），
可，并且定期评审。 • 具体服务的可用性目标是 IT 自己确定的，
没有正式与业务达成一致
• IT 部门虽然也记录了事件平均修复时间和
平均故障间隔时间，但业务不太需要这些
数据（这块内容希望做电话沟通）不准确
11 可用性目标被书面记录 • 没有 SLA，因此业务和 IT 之间没有记录 !! 低
在一份或多份服务级别可用性目标
协议（SLA）。 • IT 记录了以前的可用性达标情况
12 可用性目标包括定义服 • 服务月报中记录了重大事件数量，基础架 ! 中
务可用所需要达到的指构可用性百分比、关键应用可用性百分比
标要求，比如最低性等
能、负载、可访问的用
户数量和类型等。
13 可用性目标包括对计划 • 计划和非计划停机有明确的区分，计划停中
和非计划停机的区分。 
机不记入可用性计算
• 计划停机提前通知并得到同意
14 可用性目标包括业务部 • 在客户的需求说明书中定义了每个服务的中
门对服务提供的时间的 
服务时间要求，但因为没有 SLA 和可用
要求：如24×365 或周性计划，导致从服务的角度不能及时更新
一到周五，早8到晚6点。和处理这些信息
15 可用性目标应包括对可 • IT 内部每月进行可用性衡量，但这些未文中
用性进行衡量的时间段 
档化并与业务部门达成一致
的定义，例如，过去三
• 平安 IT 目前进行月度和年度可用性衡量
个月可用性目标达到
99.99%。
16 系统中断的成本损失或 • IT 员工有宕机成本的概念，但未正式分析中
影响已经被分析和文档 
或记录
化，并用于定义可用性
的需求。

HP Services
Assessment
主动性可用性管理
17 确定了提供IT 服务所
需的逻辑组件，并且文 • 没有对提供每个 IT 服务进行详细的逻辑
! 高
档化（应包括人员和流组件分析，每个服务的可用性分析基于个
程、硬件、软件或其它人的知识和经验
技术和共享的环境基础 • 针对 EPCIS-AUTO 系统，有简单的三层
设施）。架构文档，用于说明系统的主要组件
18 为每个关键性服务执行
了正式的风险分析。
• IT 与业务部门没有针对每个关键服务进行 ! 低
过正式的风险分析，只在 IT 服务持续性
项目中对所有系统做过总体层面的分析
• 未讨论过风险及应对计划，风险评估仅仅
是非正式的按个案处理（比如，当某些事
件发生后会提出风险
19 可用性风险，如单故障
点或关键性人物，已经
• 平安保险的应用按照标准的 J2EE 架构设 ! 中
计，以减少单点故障，保证系统的高可用。
被标示出来，并文档在系统级别有标准的双供电、网络冗余，
化。 SAN 冗余等
• 单点故障分析保存在非正式的方式（如邮
件）里，没有正规的分析方法
• IT 认为目前系统没有单点故障（这块需要
确认），但同时认可这基于个人的判断，
没有系统的分析计划、检查清单或方法
20 对于已标识出的可用性
风险采取相应的措施或
• 没有正式的服务改进流程来主动识别和确 ! 中
定可用性风险以改善可用性
制定相应的计划。
• 如果指出风险，会采取措施管理风险（比
如，系统运营部曾经识别出 EPCIS-
AUTO 的两个单点故障并已解决，DB 组
会分析并指出 TOP SQL 进行改善）
21 通过可用性计划来文档
化可用性管理机制，并
• 没有可用性计划或类似的文档用于管理和 ! 中
提高可用性
用于管理可用性的提高。
• 存在一些非正式的可用性改善的规定和实
该计划定期评估，至少
践
一年一次。
22 针对可用性要求，在外
部供应商的合同中定义
• 目前没有端到端的可用性管理框架，系统 ! 中
运营会将要求提交给基础架构管理部，由
有相应的服务能力的要基础架构管理部负责与外部供应商沟通
求。

HP Services
Assessment
23 系统配置、服务设计和
营运管理能够满足可用
• 基础架构和系统运营致力于从各自所管辖 ! 中
的方面进行改善（比如，网络、服务器、
性目标。 DB、应用等）；没有专门的小组从服务
方面关注可用性，没有从服务的角度定义
可用性目标（这个组的定义是什么？能否
详细描述一下？）可用性目标没有和业务
沟通，关注计算，没有关注整体服务的改
进。
24 有效的利用各种技术和 • 平安保险 IT 已采取一些基础性工作以减中
机会来减少计划宕机时 
少计划宕机时间
间：如，使用克隆技术
• 针对每次维护，计划宕机都与客户达成一
来减少备份带来的宕机
致，但没有一年总的计划宕机时间的限制
时间，利用集群切换技
术实施固件升级。
25 可能的情况下，采用建
模或其它分析流程来验 • IT 每个小组都有能力管理自己的技术领域， !! 低
证可用性目标是否能够因此没有建立整体服务模式或使用分析流
达到。程来验证可用性。鉴于是按照标准架构设
计的，一般不再做切换测试
被动性可用性管理
26 从用户的感受监控可用 • 从被动管理角度来说，监控小组确保能立低
性，以确保能立刻采取 
刻采取行动，以恢复服务的组件
措施保护和恢复服务。
27 能够提前发现无法达到 • 平安保险 IT 计算可用性，并按照不同级中
的可用性目标（或可能 
别分类信息（如正常、告警、关键等），
无法达到的目标），以使用这些技术可以提前发现无法达到的可
采取相应的改进措施进用性目标
行挽救。
28 当可用性目标可能无法
达到时，采取行动保护
• 由于缺乏服务级别协议，虽然了解目标有 ! 高
不能达到的危险，但因为没有正式的流程，
服务；例如，冻结一切没有人尝试与 IT 或业务协商变通方法
变更，或指定一个资深
• 业务驱动的变更从来不会被冻结或管控，
技术人员“值守”系统。
即使一些特殊时间，比如节假日（没有明
确的机制保证可用性）（不准确，应该描
述为：可能）
29 当服务的可用性目标没 • 当可用性不达标时，会进行根本原因分析中
有达到，或将未达到时， 
和识别
采取行动解决根本性的
问题。
30 服务中的每个逻辑组件 • 每个组有各自的组件的可用性计算方法和中
的可用性被衡量和记录。 
工具，但组件指标没有集成起来统一利用
31 在IT 部门内部对逻辑 • 基础架构各小组月报中显示了组件的可用中
组件的可用性进行评估， 
性，并分为三个级别：正常、告警、关键。
并采取行动解决问题。对警告和关键会采取措施解决问题

HP Services
Assessment
8.1.10 技术发现点
可用性管理技术发现点等级权重
发现点 1 – 定义关键业务功能 ! 高
从服务连续性角度，目前将整个 IT 系统定义为‘关键系统’或‘非关键系统
’，没有详细定义到更深一层的级别。如，针对 EPCIS-AUTO 系统，该系统
属于‘关键系统’，那么它的业务活动（录单、核保、批改、询价、查询等）
都被认为是关键业务功能（VBF）。
IT 没有充分的与业务部门交流以了解哪些活动是真正关键的活动（比如，在
哪个时间段，依赖用户的重要程度等）。这样做可以更好地提高满意度并理
解业务需求。
发现点 2 – 业务不理解可用性指标 ! 中
评估发现业务不理解使用通常的百分比表示可用性（如 99.92%等）。业务
不能充分理解和认可会导致 IT 所做的努力与业务的期望不符。
发现点 3 – 监控服务的运行
 中
IT 使用脚本和工具能够探测并发现 IT 服务是否运行正常，但是，IT 选择这些

工具用作内部使用，而不是为了展示给业务部门，以验证服务是否运行正常。
惠普认为这些工具可以更好的利用于可用性监控和衡量。
发现点 4 – 分析提供可用性的成本 ! 中
没有足够的文档定义了提供可用性的成本或停机成本。没有这些信息，将很
难估计花费的时间是否值得。
发现点 5 – 用服务树分析可用性 ! 中
CMDB 能显示基础架构组件（application、middleware、DB、server 等）
的关系，但平安 IT 没有服务树的架构（如，组成服务的逻辑组件关系和组成
逻辑组件的物理组件关系）。这导致很难知道服务的所有组件之间的关系，
以及如何提供服务的可用性。
发现点 6 – 纪录风险、影响和差距 ! 中
没有文档化的风险清单、风险分析和风险应对计划（能否举例详细说明一
下？），各组件的影响以及对服务的影响，已知差距，单点故障等，导致没
有正规的决策信息基础，这使得被指派管理可用性的人员很难开展工作。
发现点 7 – 不清楚业务需要的可用性 ! 中
IT 在没有太多交互的情况下，对业务部门想要什么进行了一些假设，业务需
要的可用性不清楚，而 IT 提供尽可能好的可用性并提供报告给业务部门。由
于真实的可用性需求不清楚，很难说 IT 是否提供了高于或低于业务需求的可
用性目标。
发现点 8 – 使用事件来衡量可用性
 中

HP Services
Assessment
可用性管理技术发现点等级权重
IT 的事件记录有两个字段用于可用性计算:
 重大事件
 是否影响可用性
如果这两个字段都选择（由事件经理确认），那么这些事件被认为是服务中
断，并被记入可用性计算。这个方法很好并且有效，但可能会因为有时间重
叠以及数据因为记录的真实准确性和实际情况产生的误差。

HP Services
Assessment
服务持续性管理
服务连续性管理流程负责确保在出现重大故障或灾难时，能够根据服务级别协议持续提供服务。服务
连续性管理可与可用性管理流程紧密配合，从而确保正确处理所有的服务可用性风险。在这方面，可用性
管理的重点是，处理预期的“正常业务”的可用性风险，而不是由服务连续性管理处理的更极端的意外事
件。使用明文规定的流程，由一个人或一个小组进行管理，即可实现卓有成效的服务连续性管理。此流程
涉及服务交付的各个方面，这些方面将形成整个业务连续性规划流程的一部分。将制定旨在明确服务恢复
优先级、要采取的步骤、角色和职责等的应急计划。定期测试这些计划和服务持续性管理将与变更管理配
合来确保他们符合技术和业务开发的最新需要
8.1.12 评估概述
IT 将 IT 服务持续性管理作为单独的流程进行管理，以确保业务的连续性。但是，IT 服务的持续性定义在相
对高的层面，没有深入到各系统的可用性标准方面。IT 服务持续性流程负责适当管理灾难恢复中的风险、
应对措施或应急方案，这与可用性管理所要求的系统级可用性不同。变更管理控制变更的执行，确保无论
生产系统发生任何变更都会变更相应的容灾环境。
服务持续性标准 HP 评估等级权重
整体服务持续管理流程
1 服务持续性管理和可用 • 服务持续性管理相对可用性管理成熟，但中
性管理共同定位服务提 
风险没有汇总。目前是从服务持续性的角
供的风险，确保这些风度管理大部分风险
险被相关各方认可并有
合适的对策或应急计划。
2 服务持续性管理与变更
管理和容量管理集成，
• 通过变更管理和发布管理确保相应的 DR ! 中
环境的变更
以确保当IT 服务或基
• 对重大变更，会评估对 DR 环境的影响
础架构发生变化后，应
急计划的合理、有效， • 对容灾环境的容量有规划，但因为没有建
以满足服务级别协议的立容量管理流程，后续相关的容量活动不
要求。是很多
3 变更流程包括每个变更 • 变更管理会评估对 DR 环境和 IT 服务持续高

中对服务持续性的影响 
性的影响
评估。

HP Services
Assessment
服务持续性标准 HP 评估等级权重
服务持续性计划
4 计划包括在服务恢复期 • 有独立的容灾中心，包括用于 IT 服务持高
间提供一个合适的机房 
续性的机房设备
设施以供使用。
5 计划涵盖了恢复和运行 • 未评估该项，但已实施持续性管理流程中
IT 服务所需的人员，设 
备，基础设施，支持服
务的安排，并确保他们
在需要的时间和地点可
以投入使用。

HP Services
Assessment
容量管理
容量管理流程负责通过经济、高效的方式，提供充足的IT 服务能力，从而满足当前服务级别协议和未
来的业务需求。有效的容量管理应当使用明文规定的流程，由一个人或一个小组进行管理。该流程涵盖端
到端服务的所有方面，具体包括环境、硬件、系统软件、应用程序与数据库、网络及 IT 服务管理流程的
实施能力。在服务级别协议中，应当包括可实现的性能和容量目标，并定期对其进行监控和记录。定期分
析记录的数据，并借助变更管理流程，开展所有改进活动。应该针对不同类别的用户、交易量或服务建立
负载表或其他容量衡量标准，并结合趋势分析和业务计划，主动管理未来容量要求。使用容量管理报告的
方式进行容量管理流程的效率和有效性的评定。
8.1.15 评估概述
IT 部门进行了足够的 IT 技术监控。有不同的团队，如 Linux，Unix，middleware, DB，网络、DC 等，
但针对 EPCIS-AUTO 服务，没有一个服务容量团队负责汇总来自不同技术团队的信息，并从整体进行全面
地分析，这是需要关注到的。性能数据的信息收集相对独立，分散到各个团队。不存在容量管理流程和相
关的规定，没有记录也不正规。另外一个关键的障碍是没有服务级别管理流程，这意味着容量和可用性管
理流程没有正确的框架与业务结合。
业务部门在软件开发周期的初始阶段提出容量需求，但是，当应用系统开发和服务运行在生产环境过程中，
业务部门较少与 IT 部门就容量进行沟通。IT 在近阶段可以没有一个容量管理团队，但是，成立一个跨部门
的团队是必需的。N-Tier 系统架构因为在需要时可以扩展或缩减服务，在一定程度上降低了某些容量和性
能方面的风险。
IT 每年做一次预算，各个部门负责各自下年度的需求预测；容量预算非常技术化，并且不是基于 IT 提供的
服务来做。目前没有服务容量计划。服务容量计划可以用于分析所提供的服务，并根据相应的方法总结出
服务是否需要升级（例如，容量增加的需求可能不需要转换为技术需求，而可能是改变策略）。
如上面所述，监控数据和 web server access log 都相当完整，可以结合起来用于为容量需求和预测提供
非常有价值的信息，遗憾的是，web server access log 没有系统地进行分析，找出每种用户类型有多少
用户在什么时间段进行了多少交易，根据这些数据，我们可以了解业务活动模式，以及相应的用户需求和
资源利用情况。
IT 也需要团队中的一些人员学习容量管理知识，这些技能可以从外部获得或指定负责人帮助提高。

HP Services
Assessment

HP Services
Assessment
容量管理标准 HP 评估等级权重
整体容量管理流程
1 正式定义了容量管理政
策方针、目标。
• 没有正式的容量管理流程方针和目标 !! 低
2 有文档化的容量管理流
程，包含主要的管理活
• 没有容量管理文档 !! 中
动。
3 有详细的容量管理工作
指南和步骤。
• 业务容量是基于估算的，不存在服务容量， ! 低
资源容量包括一些活动（可以转化为工作
指南）
4 有专人负责容量管理，
并被授权开展此项工作。
• 没有专人负责全面的容量管理，不同 IT ! 高
团队负责管理自己负责的组件（如，服务
器、网络、应用等）
• 本次评估项目启动时指派了容量经理
5 容量管理涵盖对IT 共 • 资源管理团队有适当的监控和异常处理流高
享的基础架构组件的管 
程。数据中心会计算和管理数据中心的容
理。量
6 容量管理和服务级别管
理紧密相关，确保容量、
• 没有服务级别管理，因此不存在与容量管 ! 高
理的结合。服务级别只在需求收集阶段定
资源能够满足每项义：
服务的服务级别要求。
 用户数
 高峰时段并发用户数
 响应时间
7 容量管理需要和服务持
续性管理相协调，以保
• 变更管理确保新的变更会考虑服务的持续 ! 低
性和分析 DR 环境的容量需求，但缺乏服
证容量/资源可以满足务级别管理使得这样做不可能达到很好的
业务持续性计划所涉及效果
的要求。
8 容量管理和变更管理、
以及业务关系流程紧密
• 不存在容量管理流程 ! 中
• 变更管理提供被动的机制来处理容量管理
相关，以保证容量计划
（如，重大变更会检查对容量和性能的影
能随着服务及其基础架
响），值得肯定，但这不足以满足容量管
构的不断发展而调整更
理的要求
新。
9 IT 共享基础架构组件
（例如，服务台、空调、
• 目前有足够的容量，但这可能因为有额外 ! 基本的
的容量，而不是由于精确的预测（所以不
网络的带宽）的容量是保证未来也是足够的）
充足的，能够满足认可
的服务级别要求。
10 当前各项服务的容量/资
源能力能够满足服务级
• 确保当前的容量满足要求，但不是基于服 ! 高
务级别的需求
别的需要。
• 选择使用 N-Tier 的系统架构减少了一些
容量的风险
• 以年为周期对容量（宏观）和可用性进行
预测

HP Services
Assessment
11 流程本身会关注并记录
有关总体容量管理流程
• 没有正式的容量管理流程 !! 低
执行状况的数据；例
如，为解决容量问题而
紧急采购设备的次数，
对照容量计划，实际的
容量储备。这些数据用
于评估容量管理流程的
效率和成效，以便于找
到改进和提高方面。

HP Services
Assessment
容量计划
12 已经制订了容量计划， • 预算计划（每年一次）收集资源容量需求， ! 高
并能反映当前的服务级与服务级别协议无关
别协议（SLA）和将来 • 没有正式的机制每年收集业务的预测（今
的业务需求。年已经在收集，钟总休假前就在做），制
定了一些表格让业务填写，会发给我们看
是那些内容
13 容量计划应得到业务部 • 系统需求收集时与业务部门就容量达成一 ! 低
门的正式认可的，且至致
少一年评估一次。 • 很少讨论系统负载特性（这块我觉得应该
有，能否说明是怎么得出的结论？）
14 存在容量计划，既涵盖 • 预算计划中包括了服务器、网络、中间件、高
共享的基础架构（如：

DC 等的容量（多数是共享的基础架构组
数据中心等），也涉及件）
了每个单独的 IT 服务。
15 有统一的，经过整合好
的容量计划，涵盖共享
• 有预算计划，其中包括基础架构组件的容 ! 中
量，没有针对单项服务的计划
的基础架构（数据中
心等）和每个单独的IT
服务。
16 容量计划涉及了中期和 • 在预算阶段计划下一年度的容量中
长期的容量、能力发展 
规划。
17 容量计划考虑了预期业
务增长所对应增加的工
• 业务预测没有提到负载特征（如用户数， ! 高
高峰期间并发用户数、响应时间等）
作负载和吞吐量。
• 具有性能管理
• 没有容量计划记录业务预测，并将所有数
据整合在一起，进行分析和报告；相反，
数据分散在各处
18 了解、获得新项目及业
务发展的情况以便于及
• 业务部门提供‘总保单增长量’。没有提 ! 中
供足够详细的数据，如增长最多的交易类
时制订高效的容量计划。型，导致无法进行有效的计划
• IT 内部各小组努力调整优化各自管理的组
件（如线程数、服务器内存、数据库连接
池等），但缺少人员从全局来看
• 政府的政策变化可能导致业务量增大并可
能引发潜在的交易量突升
19 针对每项服务上由不同
类型的用户或业务交易
• 业务交易的类型在开发阶段收集，在随后 ! 中
的开发中没有分解到各容量组件
产生的工作负载，以及
相应的资源需求已经被 • 由于没有跟踪用户的行为，业务部门不清
细化分类和标识。楚谁在使用系统和使用多长时间，只知道
交易的结果，而不知道交易的特征

HP Services
Assessment
20 容量计划考虑到了每个 • 有年度的预算计划考虑到组件的需求，考中
关键支持组件预期的利 
虑到更换交货时间
用率以及这些组件升级
或替换时所需要的订货
到交货的时间。
21 在必要时使用容量规划
建模工具。
• 重大功能变更时使用 LoadRunner 做压 ! 中
力测试，以验证系统性能
• 没有使用容量建模工具
• 压力测试在 Staging 环境中进行，
Staging 环境的容量比生产环境低，没有
相应的比例对照公式
22 负责制订容量计划的人
员有必要的技能，并能
• 没有容量计划，没有合适的方法建立容量 !! 中
计划
使用所需要的工具。
• 有压力测试和监控工具，但缺乏方法执行
容量预测
23 在容量计划中描述的行
动被严格执行。
• 预算计划中说明了下一年的组件升级，多 ! 高
数都按计划执行，但没有系统地说明容量
方面行动的计划
24 实施容量计划时会涉及 • 组件升级按照变更管理执行（仅在资源级低
使用变更管理流程和项 
别）
目管理。
25 容量规划工作会和财务
管理、业务整合和IT 策
• 预算计划与财务管理相关，但这是比较宏 ! 高
观的层面，不能很好的支持容量需求
略相协调。
• 业务与 IT 战略的结合没有评估
• 基于访谈了解到，IT 内部自行完成大部分
规划
26 在IT 管理的例行报告 • 生成了资源容量级的报告，有收集趋势数中
中有关于当前的容量状 
据，但没有详细的诠释或分析
况、趋势以及和容量计
• 数据中心的容量管理显示了数据中心的空
划的差异等内容。
间、存储、CPU 的使用率
27 当发现容量现状偏离计 • 采用的方法多数属于被动方式，并且在时中
划后，及时采取行动解 
间发生后采取行动，某些情况下会生成问
决问题。题记录以解决相关问题

HP Services
Assessment
监控
28 采用适当的工具对每个 •
服务端到端工作负载、
监控软件可以监控单独的组件，并进行异 ! 中
常处理
吞吐量监控；例如，每
• 端到端服务的负载、性能可以从 web
个小时执行多少笔交易。
server 的 Access log 中收集，这些数据
已经存在但没有很好的利用，并缺乏处理
方法
29 采用适当的方法对每个
服务或交易的端到端的
• 性能和响应时间可以在 Access log 中获 ! 中
取，这些 Access log 可以提供端到端服
性能或响应时间进行监务的性能和响应时间
控；例如，每个交易需
• 这些数据目前没有采集，因为没有相应的
花费多长时间。
需求
30 使用适当的工具监控所 • 使用 OpenView，Solarwinds, APM, 高
有共享资源的使用率， 
BMS (for Data Centre) 和其他自己开
如电源、局域网发的工具监控各种组件的使用率
（LAN）带宽。
31 使用适当的工具监控每 • 使用 OpenView，Solarwinds, APM, 中
个服务的组件（如服务 
BMS (for Data Centre) 和其他自己开
器和存储设备）的使用发的工具监控各种组件的使用率
率。
32 当监控值偏离预期范围 • 监控工具设置了告警中
时，及时产生告警。 
• 各小组负责设定阀值处理告警
33 基于服务级别和容量计 • 已有足够的告警阀值设定，但是没有正式中
划的要求，设定适当的 
的定期评估这些阀值。
监控阈值并对所设阈值
• 各小组负责自己的阀值设定（如 DB 负责
定期检查、评估。
设定连接池，线程，数据库表空间等）
34 当服务可能不能正常运 • 监控系统会将基础架构组件的事件转发到中
行或服务级别要求可能 
OVSD 中，应用的告警会由 Tier1 负责录
不能满足时，会作为事入
件进行报告、记录。
35 将收集到的数据进行整 • 数据收集分散在 IT 的各部门，数据保存低
理、保存，以便于将来 
着但没有按方法统一整理，以从服务角度
进行容量计划时参考。用于支持容量计划
36 容量监控和事件管理流 • 容量监控是组件监控的一部分，已与事件低
程及日常操作维护紧密 
管理和日常操作维护集成
集成。

HP Services
Assessment
性能调优
37 性能数据收集和分析工 • 使用工具（如 APM, OpenView 和内部中
具被适当地运用于每个 
开发的工具）收集了合适的性能数据
IT 服务的组件的分析工
作中。
38 对所有的IT 服务和组
件按适当的时间频度进
• 日常的性能分析限于资源层面的分析，没 ! 中
有进行服务层面的分析，因此优化是分散
行例行性能分析，从而的，没有体现出相互的关系
能及时发现需要优化的
领域。
39 运用适当的工具和流程 • 运用适当的工具进行监控和性能调优，但中
实施性能调优工作。 
没有正式的流程或标准管理性能调优，多
数视具体情况而定
• 定期做数据库的调优，识别 TOP SQL 并
提交到开发进行优化，其他小组的调优根
据具体情况而定
40 所有的性能调优操作都 • 对生产环境的变更遵循变更管理流程低
通过变更管理。 
• 需要对生产环境调优（或参数修改时）时
发起变更请求

HP Services
Assessment
被动性容量管理
41 需要时，有合适的人员 • 执行性能数据收集和分析的人员有合适和中
进行性能数据收集、分 
正确的权限访问工具
析和解决性能问题，并
• 有些整合的数据存放在 ITSM portal 上可
有权使用相关工具和需
以浏览
要的信息。
42 IT 管理团队和业务管理
团队针对需求和资源管
• IT 和业务没有达成共识 ! 中
• 对于需求的优先级没有正式的文档记录
理的优先级已事先达成
共识，因此当发生被动
式性能管理时，他们对
解决问题的优先级有统
一的认识。
43 为了保证满足服务级别
要求，需要进行需求管
• 还没有很成熟的需求管理，业务需求驱动 ! 中
IT，与业务还没有建立主动的方式再分配
理并采取相应的行动；或管理需求
例如，改变工作时间、
• 某些情况下，IT 和业务会共同管理一些
限制用户登录、改变批
IT 需求
处理的优先级。
• 当因为性能问题或交易量大的情况下，IT
会与业务沟通关闭某些作业或调整运行时
间
44 按照认可的业务优先级
调整和分配资源；例如
• IT 和业务对业务流程和活动的优先级有共 ! 中
识，但没有正式的文档记录下来，视具体
在服务器之间调整情况而定
CPU，或帮助台值班人
员的轮班安排。
45 在进行被动式性能管理 • 文档化工作较少，已有足够的工具进行被中
时，所有文档化的、经 
动的性能管理
测试的工具和流程都完
备。
8.1.17 技术发现点
容量管理技术发现点等级权重
发现点 1 – 业务与 IT 关于容量的沟通渠道  中
每个业务系列有一个应用系统组，作为与 IT 开发部门的唯一的接口，这是功
能需求沟通的正式渠道，这个渠道有利于讨论容量相关的标准和服务提供，
但目前没有充分地利用，将来可以改善这个渠道的利用。（名称错误）
发现点 2 – 没有正式的流程去了解负载特性 !
IT 开发部门在需求分析阶段，收集系统的用户数、高峰时段并发用户数、服
务窗口和响应时间。但这些信息没有定期再评估，IT 也没有从业务得到更详
细的负载特性信息。

HP Services
Assessment
发现点 3 – 单个资源监控已经实现，但缺乏如何将这些数据整合在一起的知
识
!
IT 每个部门都在执行对组件的监控和分析（如服务器、网络、数据库等），
因为这关系到各自管理的领域和考核。但没有一个服务的团队负责整合所有
这些监控数据，并尝试做些有意义的工作。因此，已经有足够的信息可以查
看，但没有整合在一起进行分析。因为没有人关注用户需求（User
Demand），这些在做的工作与用户需求无直接关系。
发现点 4 –在 Staging 环境的进行的压力测试无法对比到生产环境 !
因为生产系统总是运行着并且不可能在生产环境执行压力测试，目前压力测
试在 Staging 环境执行。Staging 环境对执行功能性测试是非常好的地方，
但是执行压力测试最重要的方面是假设 Staging 系统和生产系统之间有一个
理想的对应关系，如果这种关系没有定义，那么将很难理解在 Staging 环境
执行的测试是否与生产环境有任何联系。
发现点 5 –业务部门不知道了解用户行为模式（User profile）和使用的必
要性
!
IT 从没有要求业务提供系统使用率的预测数据，IT 会得到交易增长的总数。
缺乏服务级别协议，IT 不能从业务获取适当的数据，Web Server access
log 包含了这些数据，但是因为没有需求，这些信息没有很好的挖掘利用，
缺乏这些信息导致 IT 处于不利的地位，因为他们只是简单的检查过去的监控
数据，而没有与用户的行为模式联系起来。
发现点 6 – 缺乏需求管理（Demand Management） !
与业务部门没有服务级别协议，IT 在管理容量方面处于不利地位，IT 只能尽
量做好并不断订购更多的硬件和增加容量，短期来看，这不成为问题，但长
远来看，IT 会发现需要管理庞大数量的服务器。惠普认为平安保险 IT 长远需
要主动地管理客户需求。
发现点 7 – 没有容量预测和验证的周期
容量预测没有记录。没有记录和分析系统曾经的使用峰值和性能下降，这些
信息可以提供数据了解资源的使用，并提供一定程度的预测能力，忽视这些
信息将导致 IT 不能有效地利用数据进行分析。
发现点 8 – 数据收集分散在各处，没有相互关联
每个层面的数据都被采集：web server access log，应用服务器、数据库
等，但这些数据相互间没有关联，也没有与服务器/应用性能、用户交易量等
相互关联，每个技术领域小组都有很多数据，但随着时间的流逝，这些数据
并没有被有效利用。
发现点 9 –没有专门的容量管理小组与运营各部门协作
在正确的环境里，不同技术领域的监控小组应该是为容量管理团队提供支持。
容量管理团队负责从服务的角度管理性能，评估技术小组提供的分析，进行
综合分析从而执行服务容量分析和预测，同时提出更高的监控需求并交回给
各技术小组。容量管理团队与业务、技术部门紧密协作，但目前没有容量管
理团队与服务级别管理、技术管理协同工作。
发现点 10 – 发布管理和频繁的变更会影响容量管理

HP Services
Assessment
容量管理要求在生产环境监控、分析，并在生产环境执行压力和负载测试。
对生产环境的发布数量如果非常频繁，将会影响容量管理，因为功能变更后
收集的数据可能会不同，为了确保监控信息和分析的准确性，容量管理团队
应当与发布管理协同工作，在收集数据和执行分析期间减少发布的数量。

HP Services
Assessment
9 服务支持
服务台和事件管理
突发事件管理负责高效地处理影响服务的突发事件,并按照服务级别协议的约定及时恢复服务.使用明文规定
的流程,由一个人或一个小组,即可实现高效的突发事件管理. 应为最终用户和其他相关方提供一明确的机制，
以便其报告突发事件。在突发事件管理系统中，将正式确定所有这些突发事件的优先级和类别，并记录在
案。在企业内部和外部签订合适的合同与服务级别协议，以确保获得必要的技能，解决突发事件和疑难问
题升级。定期监控突发事件记录的状态，并随时更新反馈给发起方。突发事件记录在发起方同意关闭前将
仍为打开状态。管理报告和趋势分析将投入使用，以便持续改进突发事件管理流程。
IT 组织内的服务台功能提供了用户与 IT 服务管理组织及流程之间的单点联系。相应的责任将包括突发事
件管理、用户查询与变更请求的处理以及沟通影响服务的事件。用户互动的整个生命周期将得到有效记录、
管理，而管理报告和趋势分析将投入使用，以便持续改进服务台功能。
9.1.2 评估概述
服务台和事件管理的评估主要是关注与容量和可用性管理相关的方面，基于这个目标，我们并没有对整个
事件管理流程进行详细的评估。目前的事件管理包含了关于容量、性能和可用性事件的监控，所有的事件
都会被记录和跟踪。运营部门对事件管理流程执行的很好。
服务台和事件管理标
HP 评估权重
准等级
人员
1 IT 人员注意到与服务可 • IT 人员注意到与服务可用性和容量、性能中
用性和容量相关的异常

相关的异常情况时会提交事件登记，并解
情况时会提交事件登记。决
单次事件处理流程
2 所有要求进一步调查或 • 告警和监控事件也是事件管理流程的一部高
采取行动的事件被记录

分，会纪录在事件管理系统中并进行调查
在事件管理系统中；例 • 部分 IT 人员观察到的事件只记录维护日
如，一个偶然的、并未志上，没有记录在事件管理系统中
实际影响服务的网络问
题。

HP Services
Assessment
问题管理
问题管理主要负责进行主动式和被动式的问题处理。从被动式角度看，问题管理通过提供专业诊断技术和
替代解决方法，为突发事件管理流程提供了帮助；从主动式角度看，问题管理找到问题的根本原因，重点
是防止问题的发生。卓有成效的问题管理通过明文规定的流程，由一个人或一个小组实现。拥有合适技能
的员工能够使用必要的文档和工具来准确诊断和解决问题。对于具有重大影响或多个突发事件均表现出相
同现象的所有突发事件，将进行根本原因分析，并实施相应的补救措施。维护有已知错误的数据库，并应
用于突发事件管理流程。采用定期的管理报告和趋势分析来确定问题管理和事件管理流程中可以改进的部
分。
9.1.5 评估概述
相比运维和事件管理，问题管理相对弱一些。问题管理的活动分散在不同部门，还没有形成 IT 组织层面的
整体问题管理流程。问题发生时，系统运营部会进行根本原因的分析，判断缺陷原因后，与开发部门及基
础架构沟通继续下一步工作。结合容量、性能和可用性管理的设计和实施，问题管理流程还有一定提升空
间。
问题管理标准 HP 评估等级权重
总体问题管理流程
1 问题管理有正式定义的 • 基础架构部门有正式定义的问题管理流程，
策略和目标。但问题管理流程没有被严格的遵守和执行
• 系统运营部对问题根本原因的分析，但没
有正式定义的问题流程。经过分析，如果 ! 低
是开发的问题，会提交到开发部门进行解
决（这块 PIR 的流程即问题管理流程，有
正式的定义？）不准确

HP Services
Assessment
操作监控
为达到服务级别协议中定义的服务级别，需要进行高效、适当的运营介入。进行这种介入时，须及时执行
计划和非计划任务。通常情况下，使用明文规定的一套运营步骤或指南，由训练有素且经验丰富的员工实
施，即可有效进行这类介入，这套工作步骤或指南涉及到计划和非计划活动。将制定运营标准，从而当引
入新的服务时，提供指南，并且 IT 运营部门将参与运营验收。适当的情况下，采用自动化的工具，并制定
相应的工作步骤或规范，从而确保成功完成手动和自动进行的任务。定期回顾运营标准和工作规范，以确
保其适宜、有效。
9.1.8 评估概述
IT 部门对系统设置了必要的工具、流程和工作指引，帮助事件的检测、监控和管理。重要事件的通知和后
续行动已记录在操作手册上。对事件做了分类和优先级的划分，大约有 90％的事件可以在规定的时限内解
决。各技术组负责各自监控的阀值管理，没有正式规定需要定期回顾这些阀值，监控的设置由工具组完成。
虽然对各个组件和资源的监控是足够的，但缺少有效的服务监控。
操作监控标准 HP 评估等级权重
事件检测
1 存在对事件的监测和管 • 有工具可以检测和管理影响性能和可用性中
理的总体设计。该设计

的事件，例如 OVO，APM for
定义了进行适当地监控、 Oracle，APM for J2EE，APM for J2EE
管理所需使用的工具。 (due in Oct’07), Web server Access
Log, Weblogic Access Log,
Solarwinds for Network, 等
2 事件已被分类,并设定优 • 所有事件已被分类，并设定优先级，以便中
先级,以便能在要求的时

能在要求的时间内采取合适的行动
间内采取合适的行动。
3 对于任何要求进一步调中
查或可能影响服务提供
• 对于任何要求进一步调查或可能影响服务 
提供的事件都被记录
的事件都被记录。
4 事件能在适当的时间段 • 对事件做了分类和优先级的划分，大约有 High
内被检测出来，并采取

90％的事件可以在规定的时限内解决
行动解决，以便保证满
足服务级别的要求。
5 对事件检测和监控的变 • 监控阀值的变化不会经常发生，如果有变中
更需要批准、测试和记

化，会严格遵循变更管理。只有大的变更
录。才会作监控方面的测试

HP Services
Assessment
操作监控标准 HP 评估等级权重
操作支持
6 • 各个组负责定义阀值来触发相应的事件中
有专人负责标识触发事 
件的阀值和条件。 • 工具组负责在监控产品上部属
7 为所有的服务定义了合 • 对各个监控的资源（服务器、网络、数据 ! 中
适的阈值和触发条件。库等）定义了阀值，但没有对服务进行监
控
8 当接到事件通知后，针 • 重要事件的通知和后续行动已记录在操作中
对每个事件要采取的行

手册上
动都要进行记录和文档
化。
9 阀值和事件被定期评审, • 很少定期回顾和审核阀值的设置。每个组 ! 中
对反馈采取行动,以保证的工作是孤立的，基于每个领域的最佳经
所有的服务都被合适的验来设置阀值，没有从整体服务的角度来
监控考虑。
• 所以资源的监控是足够的，但对服务的监
控很难说是足够的

HP Services
Assessment
配置管理
配置管理主要负责识别确认并记录与 IT 服务交付相关的所有组件信息，并运用准确的配置和关系信息，对
其他 IT 管理流程提供支持。有效的配置管理是通过使用明文规定的流程，并由指定一个人或一个组织进行
管理。确定配置和关系信息的标准定义，对每个与服务交付有关的组件，记录配置和关系信息。配置管理
将对每个与服务交付有关的组件进行标准的配置定义并对它们之间的关系进行说明。访问配置信息应该非
常容易；物理组件也会进行明确标记。定期审计，以便验证记录的信息的准确性以及如果发现不符之处应
采取的措施加以更正。配置管理报告将被用于确定配置管理流程中需要改进的方面。
9.1.11 评估概述
基础架构管理部门有非常详细的 CMDB 记录。CMDB 数据量很大，但有些信息缺失（很多属性是空的）。
在 CMDB 上所做的工作给我们留下了深刻的印象（但也有一些需要提高的地方，例如，不需要的属性不
应该保留在 CMDB 里）。配置管理和变更管理已集成，CMDB 里包含了一些基本信息（CPU 数量，内存
大小等），但缺少一些可以用来作容量和性能管理的数据。
配置管理标准 HP 评估权重
总体配置管理流程
1 配置管理有文档化的流 • 基础架构管理部有正式的配置管理流程低
程，包含主要的管理活

• 对于自己开发的软件，有软件版本控制软
动。件管理软件的生产发布
2 当 IT 服务组件部分发生 • 当变更完成后，各个组的 CI Owner 通过高

变更时，配置记录被更 OVSD 的工作单来更新配置信息
新。 • CMDB 主要包含的是基础架构的组件，应
用和服务的组件也应该在 CMDB 中记录
和维护
• CMDB 记录了很多属性，但只维护了一小
部分（没有使用的属性应该去掉）
3 配置数据被变更管理使 • 配置数据可用于参考，但不足以用于可用 ! 低
用，以便确定变更对相性和性能的变更影响分析
关组件和服务的影响。 • 运营还会提供专门定制的表格来分析变更
对相关服务的影响
4 有流程对设备的上线和 • 满足中
下线进行控制和管理。

5 有流程对软件使用许可 • 使用 EXCEL 管理软件许可证未评估基本的
证进行控制和管理。 • 没有评估软件许可证的控制流程

HP Services
Assessment
配置管理标准 HP 评估权重
配置管理数据
6 系统组件之间的关系被 • 系统组件之间的关系被清晰地标示中
清晰地标示。 • 但 CMDB 中有很多属性没有使用，这部

分以后可以优化
7 配置管理工作涉及所有 • 配置管理涉及所有与服务提供或实施相关中
与服务提供或实施相关的技术组件，包括服务器、存储设备和网

的技术组件，包括服务络设备的软件和硬件
器、存储设备、客户端 • 但没有包含客户端设备，这部分由 CA 的
设备和网络设备的软件软件来管理
和硬件。
8 配置管理工作涉及用户、 • 文档也作为 CI 的一类
! 低
IT 员工、流程文档、服 • 配置管理涉及用户、IT 员工和建筑物
务级别协议（SLA）、 • 没有 SLA
建筑物和所有其它的 IT
服务组件。

HP Services
Assessment
变更管理
变更管理主要负责通过高效、可控制的方式，对生产及其运营环境实施变更，无论这些变更是由于日常维
护、解决问题还是业务改进所导致。有效的变更管理可以满足变更的需求，而同时还能最大限度地降低相
关的固有风险，为此，应当使用明文规定的流程，由一个人或一个小组进行管理，并包含服务提供的所有
方面。通常情况下，由业务和 IT 服务管理部门的代表组成的变更咨询委员会 (CAB) 正式确定所有变更的
优先级并授权变更。变更管理将监督变更测试，确保包括相应的撤消计划，同时应制定紧急变更管理流程，
包括事后的变更授权和文档。管理报告和趋势分析将投入使用，以便持续改进变更管理流程。
9.1.14 评估概述
基础架构的变更和应用系统开发由不同的变更管理流程控制。基础架构管理部使用基于 ITIL 最佳实践的
OVSD 工具，开发部遵循 CMMI 方法论管理版本变更。在实际运用中，对生产系统的变更由上述变更管理
流程控制，每个变更都会作影响和资源的评估，对容量的影响评估基于个人的经验。
变更管理标准 HP 评估权重
总体变更管理流程
1 有统一的变更管理流程， • 信息管理中心有两个变更管理流程，相互高
涵盖生产、服务和支持

之间有某些交互
基础架构中的所有变更 • 基础架构管理部的变更管理覆盖了生产系
（包括设备、环境和网统中的所有硬件和软件配置的变更
络）。
• 应用系统的变更按照 CMMI 软件变更流程
和基于 ITIL 自行建立的发布管理流程执行
• 当软件版本需要发布到生产环境时，系统
运营部会提交服务请求到基础架构管理部，
基础架构管理部负责环境的准备
2 业务需求、服务实施内 • 没有 SLA ! 低
容和服务级别协议
• 没有统一的变更管理覆盖业务需求、服务
（SLA）的变更是由变
更管理流程控制的。交付和 SLA 的变更
人员
3 变更咨询委员会是根据 • OVSD 只是管理由基础架构的变更，如服中
服务范围组成的；例如

务器、网络、数据库等。
包括业务、IT 管理和技 • 基础架构部使用 OVSD 的 CAB 审批功能，
术成员。虽然业务部门的审批没有体现，但会与业
务部门沟通并得到同意
• 变更咨询委员会是根据服务范围组成的；
例如包括业务、IT 管理和技术成员。

HP Services
Assessment
变更管理标准 HP 评估权重
单次变更管理
4 对每个变更请求要进行 • 每个变更请求都会进行影响和资源的评估高
影响和资源的评估。要

• 对于应用的变更，系统运营部门会提供一
考虑对 IT 服务和支持性个专门定制的表格来分析变更对相关服务
IT 基础架构，以及共享的影响，不过这项工作是最近才开始进行
该基础架构的其他服务的。
的影响。
5 考虑变更对容量和性能 • 对于新的服务或已有系统的重大变更，会低
的影响。

考虑对容量和性能的影响
• 其它的一些变更，对于变更影响的分析是
基于经验
6 考虑变更对客户端配置 • 应用都是基于 J2EE 架构，对客户端的影未评估低
和容量的影响。响很小
7 考虑变更对可用性和服 • 变更管理流程要求变更的影响评估包括中
务持续性（容灾）的影

DR 环境，因此变更对可用性和服务持续
响。性有考虑
8 有测试环境，作为生产 • 有测试环境，但测试环境无法代表生产环 ! 高
环境的代表。境，相互之间缺乏对应的缩放比例关系
9 根据变更种类，按照认 • 对于新系统或已有系统的重大变更，测试高
可的衡量标准，进行合

会包含性能测试、压力测试、切换测试
适的测试，包括系统、 • 对于程序缺陷或小的变更，不会作性能测
功能、集成、性能、安试，以功能测试为主
全、可用性和操作测试。
10 在任何服务或 IT 基础架 • 变更实施完成后，会做一些测试保障系统中
构的变更实施完成后，

的可用性，但不一定是标准的测试集
使用标准的测试集，以
便保证应用程序功能的
正确。

HP Services
Assessment
发布和测试管理
发布管理与测试流程负责控制将硬件与软件版本发布到正式的测试与生产环境中，它与配置管理和变更管
理配合，确保发布得到了相应的授权和记录。为了实现有效的发布管理，需要文档化的流程，并由一个人
或一个小组进行管理。该发布管理将控制以下各项的发布：系统软件和硬件、应用程序与数据库软件、客
户机桌面版本，以及所有相关的脚本和配置文件。授权软件库 (DSL) 用于对合法保留且无病毒的软件原版
拷贝进行保存和控制。在进行主要版本发布时，该流程将与项目管理密切配合。定期审计，确保遵守授权
软件库和软件发布的步骤。利用产生的管理报告，确定发布管理流程中需要改进的方面。
9.1.17 评估概述
发布管理的效果主要由容量、性能和可用性管理来检验。使用 Staging 环境作为压力测试环境，但
Staging 环境的配置和生产系统有差异，相互之间没有科学的对比关系或映射换算方法，也缺少相关知识
来根据 Staging 环境的数据预测生产环境的最终容量。工具方面，管理环境中使用 Clear Quest 作为版本
发布管理系统，Clear Case 管理软件代码，Loadrunner 和 Winrunner 作为测试工具。

HP Services
Assessment
发布管理和测试标准 HP 评估权重
构建和测试
1 每个 IT 服务有一个合适
• 使用 Staging 环境作为压力测试环境， ! 中
的测试环境。文档良好，
Staging 环境的配置和生产系统有差异，
并确保在测试开始之前，
缺少相关的知识来得出两个环境之间的对
现有测试环境可以被恢
比关系或映射换算方法
复。
2 所有的发布组件在部署 • 所有的发布组件在部署到生产系统之前都基本的
到生产系统之前都要经

要经过综合测试
过综合测试。 • 对于新的系统或重大的变更，会做压力和
性能测试
3
发布测试包括 IT 运营、
• 发布测试没有包含操作和监控测试（这块 ! 低
指什么？）翻译的问题
互操作能力和监控等的
测试。 • Release testing doesn’t include the
testing of operational monitoring
4 使用自动化的工具和测 • 使用 Clear Quest 作为版本发布管理系统，中
试套件，包括合适的测

Clear Case 管理软件代码，Loadrunner
试数据。和 Winrunner 作为测试工具
5 发布测试环境和将要使 • 架构是一致的，但服务器的配置和数量要 ! 中
用的生产环境足够相似。小于生产系统。
• 缺少对比换算公式反映 staging 环境和生
产环境的性能

HP Services
Assessment
Appendix A 流程成熟度定义
本报告的评估发现基于正式的实施方法论和评分机制，在每个评估领域提供了流程成熟度的量化评
估。本报告的成熟度级别基于ITIL 流程成熟度框架：
无/初始
在这个阶段，IT部门可能对流程有所了解，但没有或几乎没有流程管理活动。即使有，这些活动也不会在
IT部门层面受到重视，也没有相关的资源投入和侧重。这一级也可以描述为一种特别的，混乱的情形。
例如：流程完全是被动的，角色和职责定义非常松散。
可重复
在这个阶段，IT部门认可流程的价值，并且在运营过程中投入了少量的资源，对流程有一定的重视和侧重。
通常在这个阶段，流程的具体活动是不协调的，不规则的，没有明确的方向，关注点主要在流程的有效性
上。
例如：没有清晰的目标，主要是被动性流程，活动通常不相关，不同的流程工具之间没有联系。
已定义
在这个阶段，IT部门认可流程的价值，并且流程全部文档化。但流程的角色和作用在IT运作的整体层面还
没有达成正式的一致，还没有被广泛地接受和认可。在这个阶段，流程有了明确的负责人，有了正式的目
的、目标和相应的资源保障。在关注流程有效性的同时，也关注流程的执行效率。流程执行的报告和结果
被适当地保存下来以供未来参考。
例如：依据文档执行日常活动，增加了主动性活动，对角色和职责达成共识并归档，定期地收集流程相关
的数据。
已管理
在这个阶段，流程在整个IT部门被全面认可和接受。IT是以服务为主的IT。有了建立在整个公司业务目的
和目标基础之上的明确的IT流程目标。流程被全面地定义、管理并且是主动性的。流程之间的接口和依赖
关系也被明确的定义下来。
例如：对告警集中的、持续的监控，单一的集成化工具和数据库。
已优化
在这个阶段，流程在整个IT部门被全面认可和接受。流程的战略目的和目标和整个组织的业务战略和IT目
标很好地整合在一起。每个与流程相关的人已经把流程做为制度化的日常活动的一部分。做为整体流程的
一部分，组织建立了独立的持续性流程改进体系。
例如：IT开始驱动一些业务层面的决策，整体IT工具体系通过优化能为业务流程的绩效提供数据
流程成熟度等级可以做为每年可用性评估的参考标准，以量化IT 部门做出的改进。


HP 可用性容量管理评估报告

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HP 可用性容量管理评估报告

Uploaded by

Copyright:

Available Formats

平安保险（集团）股份有限公司

Date Revision Status Comment

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

中国平 安保险 （集团 ）股份 有限公 司 惠普公 司

马晓强 系统开发一部/核心技术组 Dickens

陈亚殊 系统运营一部/产险应用服务组 Kingshuk Ghosh

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

关于可用性和容量管理的策略已经存在。IT 组织意识到需要面向服务文化，变革成为一个 IT 服务提供组织。

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

3.2 容量管理: 需求管理（Demand Management）

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

3.3 容量管理: 性能管理

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

3.4 容量管理: 应用容量评估 (Application) Sizing

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

之后可以启动服务改进计划 SIP。 在 SIP 的执行周期中，平安保险需要：

如上所述，惠普将参与 SIP 的规划工作；如果需要，惠普可以协助进行第三章中提到的服务改进活动。

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

平安保险 IT 组织正在进一步利用业界最佳实践（如 ITIL）和 ISO20000 标准建立服务管理体系，并获取和

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

持总体IT 服务管理  IT 规划部门要求 IT 部门填写并交付各自

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程 成熟度 定义

IT 使用脚本和工具能够探测并发现 IT 服务是否运行正常，但是，IT 选择这些

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

中国平安保险（集团）股份有限公司惠普公司

马晓强系统开发一部/核心技术组 Dickens

陈亚殊系统运营一部/产险应用服务组 Kingshuk Ghosh

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

之后可以启动服务改进计划 SIP。在 SIP 的执行周期中，平安保险需要：

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

3 变更流程包括每个变更 • 变更管理会评估对 DR 环境和 IT 服务持续高

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义

Ping An Insurance Company V0.1 - 15th Sept. 2007 流程成熟度定义