云计算运维管理体系方案设计

1、 云计算运维管理体系方案设计目 录 TOC o 1-3 h z u HYPERLINK l _Toc6483129 第1章 运维体系 PAGEREF _Toc6483129 h 4 HYPERLINK l _Toc6483130 1.1 运维管理体系架构 PAGEREF _Toc6483130 h 4 HYPERLINK l _Toc6483131 1.2 运维管理体系实施方法论 PAGEREF _Toc6483131 h 6 HYPERLINK l _Toc6483132 1.3 运维管理体系设计示例 PAGEREF _Toc6483132 h 8 HYPERLINK l _Toc64831

2、33 第2章 云业务运维管理 PAGEREF _Toc6483133 h 35 HYPERLINK l _Toc6483134 2.1 云业务监控及分析 PAGEREF _Toc6483134 h 35 HYPERLINK l _Toc6483135 2.2 云业务故障定位及影响分析 PAGEREF _Toc6483135 h 37 HYPERLINK l _Toc6483136 2.3 统一应用资源管理 PAGEREF _Toc6483136 h 38 HYPERLINK l _Toc6483137 第3章 云基础设施运维管理 PAGEREF _Toc6483137 h 50 HYPERLI

3、NK l _Toc6483138 3.1 总体目标 PAGEREF _Toc6483138 h 51 HYPERLINK l _Toc6483139 3.2 概要设计 PAGEREF _Toc6483139 h 51 HYPERLINK l _Toc6483140 3.3 IT基础信息配置管理库设计与实施 PAGEREF _Toc6483140 h 52 HYPERLINK l _Toc6483141 3.4 资源监控及自动化 PAGEREF _Toc6483141 h 61 HYPERLINK l _Toc6483142 3.4.1 网络资源管理 PAGEREF _Toc6483142 h

4、61 HYPERLINK l _Toc6483143 3.4.2 服务器及存储自动化管理 PAGEREF _Toc6483143 h 64 HYPERLINK l _Toc6483144 3.4.3 虚拟化管理 PAGEREF _Toc6483144 h 73 HYPERLINK l _Toc6483145 3.4.4 可视化机房及机房动力环境管理 PAGEREF _Toc6483145 h 75 HYPERLINK l _Toc6483146 3.4.5 IP/MAC管理 PAGEREF _Toc6483146 h 81 HYPERLINK l _Toc6483147 3.4.6 拓扑管理及

5、可视化 PAGEREF _Toc6483147 h 83 HYPERLINK l _Toc6483148 3.4.7 告警及故障管理 PAGEREF _Toc6483148 h 85 HYPERLINK l _Toc6483149 3.4.8 智能容量分析及管理 PAGEREF _Toc6483149 h 87 HYPERLINK l _Toc6483150 3.4.9 性能管理 PAGEREF _Toc6483150 h 88 HYPERLINK l _Toc6483151 3.4.10 报表管理 PAGEREF _Toc6483151 h 89 HYPERLINK l _Toc648315

6、2 3.4.11 分级分权管理 PAGEREF _Toc6483152 h 89 HYPERLINK l _Toc6483153 3.5 运维流程管理 PAGEREF _Toc6483153 h 90 HYPERLINK l _Toc6483154 3.5.1 服务台 PAGEREF _Toc6483154 h 90 HYPERLINK l _Toc6483155 3.5.2 事件管理 PAGEREF _Toc6483155 h 91 HYPERLINK l _Toc6483156 3.5.3 问题管理 PAGEREF _Toc6483156 h 93 HYPERLINK l _Toc6483

7、157 3.5.4 变更管理 PAGEREF _Toc6483157 h 95 HYPERLINK l _Toc6483158 3.5.5 发布管理 PAGEREF _Toc6483158 h 97 HYPERLINK l _Toc6483159 3.5.6 知识库管理 PAGEREF _Toc6483159 h 99 HYPERLINK l _Toc6483160 3.5.7 流程自定义 PAGEREF _Toc6483160 h 99运维体系云平台构建完成之后，后期的运维管理是一项长期的工作，如何做好云的运维管理工作是每一个建设者必须考虑的问题。我们立求帮助数据中心建设树立面向业务服务的I

8、T服务管理理念，建立科学合理的绩效考核指标，由粗放管理向精细管理转变；实行集中统一的IT服务管理模式，由分散管理向集中管理转变；建立统一高效灵敏的运维服务管理平台，由无序服务向有序服务转变；建立规范标准的运维服务管理流程，由职能管理向流程管理转变；应用先进、实用、高效的运维服务管理工具，由被动管理向主动管理转变。具体而言，为数据中心制定科学有序的管理流程和规章制度，建立统一的运行维护、客户服务模式和规范，应用先进的技术工具，搭建统一高效的运维服务管理平台。运维管理体系架构针对本次数据中心运维管理体系的建立，我方提供基于“体系化”的思路协助信息管理中心建立一套行之有效的“持续改善机制”，从长远目

9、标来看，整套体系的建立面向数据中心的业务和服务提供，以服务为导向，建立创新性的数据中心运维服务管理体系，整套体系的建立涵盖组织管理、制度规范和技术支撑三个层面的内容：整体运维服务管理体系的建立，在基于面向数据中心整体业务和服务目标的基础上，确立IT为数据中心服务目标提供坚实支撑这一定位，重新梳理整体运维目标，将运维目标和组织的业务目标相融合，从而建立创新性的运维体系，使得IT部门的战略目标支撑于组织的战略目标、融合于组织的战略目标，提升IT部门的价值。整个IT运维运维服务体系主要分为组织管理、制度规范和技术支撑三个方面：组织管理层：确定和规范运维服务管理体系运行的管理方式以及与之相配套的人员岗

10、责安排、机构设置，将运维服务管理相关的全部活动进行统一的规划和决策，结束分散的管理模式，形成集中统一的运维管理机制，在集中统一的运维管理模式下，按照运维服务管理任务、服务目录等因素科学设置或调整运维组织机构、角色、岗位、合理配置运维服务管理各方面资源，达到人、技术、流程的有机融合。制度规范管理层：分别从管理和操作两个方面出发，建立在运维服务管理过程中各参与要素（人、技术、流程）的行为准则和工作程序（流程规范），从运维服务管理体系总体运行、流程执行和岗位职责建立考核体系，并依据服务目录的建立和SLA 的签订，实现运维服务的量化管理，约束、监督、提升服务质量，具体内容包含管理制度的制定、服务目录与

11、SLA的建立、管理流程的设计、评价考核体系的建立。技术支撑层：建立面向业务客户的运维服务请求响应窗口和面向技术支持人员的体系运行管理窗口，建立一套统一的负责运维服务管理流程、IT基础设施运行监控、云业务监控的综合运管理平台，建立包含事件管理、问题管理、配置管理、变更管理、SLA管理、知识库管理、流程管理和报表等功能的统一技术支撑平台。通过运维服务管理体系的建立，从组织、管理、技术支撑等方面充分梳理数据中心目前的运维管理模式，树立面向业务服务的IT服务管理理念，通过服务目录的确立、SLA的签订、考核指标的量化，建立科学、合理、可持续改进的运管理体系，由粗放式管理向精细管理转变；实现集中统一的运维

12、服务管理模式，由分散、混乱的管理管理向集中管理转变；建立统一高效的运维服务管理平台，由无序服务向有序服务转变；建立标准规范的运维服务管理流程，由职能管理向流程管理转变；应用先进、实用、有效的技术工具，由被动管理向主动管理转变。整套体系按照运维服务管理理论、方法和标准，结合数据中心目前运维管理实情和业务发展目标，遵循立足需求、统一规划、保障重点、分布实施、务实求效的原则，建立一套融合组织、制度、流程、人员、技术的运维服务管理体系，建立组织机构，制定规范制度、规范管理流程、明确职责分工、强化技术支撑，确保数据中心的正常、稳定、高效运行，实现高水平、高质量的运维服务，实现IT部门的价值转变和提升。运

13、维管理体系实施方法论运维服务管理平台是基于ITIL规范开发的，众所周知，ITIL是最佳实践的产物，ITIL是一个依据IT运营发展不断变化、反复调整的理论体系，ITIL是需要结合客户实际运营环境，并进行反复验证的。因此脱离实践的ITIL空想，往往很难在现实客户中获得成功。ITIL理论引导和咨询规划帮助客户进行宏观层面的规划和指引，但是终究需要依赖“人”去理解和贯彻执行，并经过反复验证，方能在此过程中总结“何为企业IT运营的最佳实践”。华三通信洞察客户在实施ITIL遇到的风险和困难，通过整合长期积累的行业客户实践ITIL的经验，总结出了华三实施方法。建议数据中心的运维服务管理平台的实施要以“PDC

14、A”为指导思想，建立运维服务管理体系的持续改进方法论和可执行方法。P：服务管理的策划，目的：策划服务管理的实施与交付。D：服务管理的实施，目的：实施服务管理目标和计划。C：服务管理的检查，目的：监视、测量并评审服务管理目标和计划完成情况。A：服务管理的持续改进，目的：改进服务交付和管理的效率和有效性。根据PDCA指导思想结合数据中心现状，我方将运维服务体系建设及平台实施划分为五个阶段：IT战略阶段、管理体系设计、整理数据模型、工具实施、运行与改进阶段。第一步是IT战略阶段IT战略阶段的任务是帮助管理层设定实施ITIL的整体战略，明确管理层对于运维服务管理的承诺。在IT战略阶段，通过现状评估、差

15、距分析、目标确立等活动，明确管理目标建设的优先等级。IT战略阶段的目标：通过现状评估全面了解IT运维服务管理流程和活动的成熟度，并以ITIL作为近期服务改进的目标，分析、评估运维服务管理现状以及与最佳实践的差距，同时提出改进建议。帮助企业运维部门全面认识现有运维服务管理水平，并作为项目下阶段规划与设计双方交流的基础。第二步管理体系设计：明确IT战略之后，需要对组织的管理体系进行梳理和改进。管理体系阶段主要包括以下内容：组织架构分析明确岗位职责规范管理制度运维流程设计考核体系第三步整理数据模型：数据模型阶段分为以下三个步骤：1.模型建立H3C 为客户提供基于长期实践经验得出的数据模型工具帮助客户

16、梳理流程及数据，并将流程及数据固化到系统中。2.数据采集基于前期阶段顾问咨询的成果，按照数据模型的标准格式，转换成可被统计、量化并被系统识别的数据。3.数据整理整理优化数据，通过手工流程检验数据的合理性和可操作性。第四步工具实施:工具实施阶段分为以下五个步骤：1.系统配置及部署完成运维管理产品的部署，管理资源、组织、人员、权限录入，监控告警策略设置，接口集成等。2.流程导入将已构建的运维管理流程导入到运维管理系统中，实现各个流程在系统平台中的落地。3.系统测试在测试环境中检验系统及数据的可操作性，并进行适当的调整。4.工具培训产品操作培训，确保使用人员熟练掌握工具，并可自行配置和调整。5.系统

17、上线运维管理系统正式部署上线，支持业务运行。第五步运行与改进：IT运营阶段将全新的H3C运维管理解决方案集成到数据中心IT架构中，并提供日常的运行、监视、维护和管理服务。该阶段包括以下内容：评估与改进：监视、评估H3C服务管理平台的运行情况。将信息反馈回评估小组，以进行持续改进。它包括：评估已交付的服务是否实现了预期价值；识别哪方面的要求发生了变化。运维服务管理体系的建立并不能只实施一次就实现所有运维服务管理建设的目标，它只是企业在建设符合ITIL规范的IT服务管理系统的诸多循环中的一次过程。配合以不断的项目回顾和持续改进，才能使得企业的IT服务管理不断的向设定的目标远景靠近。运维管理体系设计

18、示例需根据对数据中心现状调研与差距分析的结果，结合数据中心已有流程，针对ISO20000/ITIL要求，结合数据中心实际情况建设符合数据中心的IT服务管理体系。我们将为数据中心设计管理流程与策略（包括流程策略、流程图、流程活动描述、流程输入与输出、角色与职责、流程KPI等）、定义相关代码（如优先级的定义、升级定义、角色职责定义等）、制定相关模板（如事件记录单模板、事件请求单模板、重大事故报告模板）。本部分以事件管理、问题管理、变更&变更管理三个流程举例说明实施中的关键点，如：流程设计、角色划分、角色职责等。事件管理目的：规范事件与服务请求管理流程的相关策略及活动，确保事件与服务请求管理流程的执

19、行质量和执行有效性。术语和定义：事件和服务请求：事件和服务请求管理流程的目的是尽快解决事件或服务请求与恢复服务。事件和服务请求记录的信息决定了其它许多流程的效率。重大事件：影响度为一级和二级的事件为重大事件。影响度：表明事件对服务所产生的业务影响，它是事件的处理优先级的一个重要影响因素。临时措施：是解决事件的临时修复方法或技术，目的是使用替代措施暂时消除用户对服务的依赖和减少事件对用户的影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。通过临时措施，用户能够在没有中断的情况下继续使用服务。临时措施通常会使用户的工作方式发生变化，比如从使用另一台PC、使用早期版本的软件、或临时提供更多

20、的磁盘空间。角色职责：事件和服务请求经理：协调事件管理的日常操作确定和执行流程本身的变更鉴别流程执行过程中的例外和异常情况, 进行管理传达流程的新政策和更新的政策（Policy）确保流程标准和步骤得到遵循作出资源的承诺和分配鉴别和实施流程的改进建议创建和分派流程管理的报表对事件管理流程的负责人提出鉴别问题/改进的建议作为流程的集中联络点，负责与用户、服务供应商、管理层之间的沟通对于不遵守流程的情形进行受理 确保对于严重等级为1的事件进行事后回顾主持事件回顾会议 在需要的时候，按照升级政策的途径进行升级对不遵从事件管理流程的参与者作出通告 执行日常的流程管理出席会议并传达和协调有关事件和问题确保

21、日常操作中所采集信息的完整性管理所有事件管理的模板和报表准备和分析报表管理资源的分配确保每个事件都被分派给适当的人员，并在服务水平或其他服务协议规定的时间范围内进行受理 监控尚未关闭的事件故障单： 关联类似的事件、确定超时的事件、对于未在规定时间内受理的、并且分派错误的事件进行重新分配、负责受理事件受理员升级报告的事件、鉴别需要特别注意和需要升级的事件。事件和服务请求记录员：接受用户的联系 收集基本的联系信息收集用户的请求信息分析请求信息 创建或者更新事件和服务请求单 验证用户的基本信息，如有需要，更新用户的资料鉴别请求的种类 (例如：被动运维服务请求，应用提升类服务请求等)对不同的请求，收集

22、适当的信息初步评估请求的严重等级 请求的初步受理 确定适当的分派 (包括：在适用的情况下，对现有的问题或者是请求作出连接)若用户要求了解事件状态，则将事件的当前状况通知用户 更新和关闭事件和服务请求单事件和服务请求受理员：决定恢复服务所需要的必要条件，并启动适当的行动 ，这些行动包括：创建变通方法确定事件执行变通方法，如果可行执行解决方案，如果可行在流程工具平台更新事件的解决方法更新事件关闭的信息根据事件的严重等级提供有效的解决方案 安装/执行事件的永久解决方案确定可以作为知识库候选对象的事件如有需要，与第三方和其他小组人员协同合作角色映射事件管理流程中定义的角色对应的数据中心人员事件和服务请

23、求经理事件和服务请求事件记录员事件和服务请求事件受理员流程描述此流程描述为示例，实施中需要根据实际和ITIL最佳实践做出调整。流程图概览图事件和服务请求的识别与记录事件和服务请求的初步支持和分派事件和服务请求调查和诊断事件和服务请求解决和恢复事件和服务请求的关闭流程描述主要活动说明活动序号活动名称详细描述相关表单1事件和服务请求识别和记录鉴别用户验证用户信息（必要时进行更新）鉴别并记录事件和服务请求表现症状事件和服务请求单2事件和服务请求分派和初步支持鉴别所影响的部件和服务初判严重等级和类别等与已知的变通方法或解决方案进行匹配事件和服务请求的初步处理支持将无法解决的事件和服务请求分配给事件和服

24、务请求处理员，以获得进一步的分析解决事件和服务请求单3事件和服务请求调查与诊断查找相似的表现症状查找变通方法需要的话，准备进行根源分析，进入问题管理流程事件和服务请求单4事件和服务请求解决与恢复执行变通方法（需要的话使用变更管理流程）若成功，验证变通方法结果事件和服务请求单5事件和服务请求关闭目前集中由事件和服务请求经理统一关闭关闭时须与用户验证结果，征求用户同意关闭事件或服务请求根据知识库决定是否需要进行后续操作关闭事件和服务请求，设定适当的关闭代码事件和服务请求单流程间的关系相关数据事件分类：分类级别采用三级分类方式，即类别、子类、项目。优先级：事件或服务请求优先级也可理解为处理事件或服务

25、请求的优先顺序优先级由影响度和紧急度两个因素决定优先级在事件、服务请求的生命周期中是可以改变的。关于更改事件单或服务请求单优先级的原因和行为应该在事件单或服务请求单中记录。 优先级的准确评定需要不断地回顾事件、服务请求，从而优化事件、服务请求/问题的分类和设定准确的优先级。为了避免一线人员缺乏经验无法判断优先级。我们需要工程师在现有事件和服务请求分类的基础上，基于事件和服务请求优先级的设定原则，设置默认的优先级，并在将来的工作中逐步优化。影响度定义1极高关键业务系统的全局性故障基础架构的全局性故障2高关键业务系统和基础架构的局部故障普通应用系统的全局故障3-中普通应用系统的局部故障影响关键用户

26、或多个普通用户4低单点故障影响普通用户紧急度 定义1极高客户接受的可耽搁时间：2小时需解决2高客户接受的可耽搁时间：4小时需解决3-中客户接受的可耽搁时间：8小时需解决4-低客户接受的可耽搁时间：无时限规定优先级影响度极高高中低紧急度极高1113高1223中1334低1344请求来源：事件和服务请求来源描述电子邮件通过电子邮件收到一个请求; 电话通过电话收到一个请求; Web通过Web提交的请求; 巡检和监控通过巡捡和系统监控工具主动监控得到的请求; 内部通讯软件内部及时通讯服务方式：事件和服务请求服务方式 描述电话通过电话支持提供服务; 远程远程诊断和解决提供服务; 现场现场工程师现场处理服

27、务; 状态代码：事件和服务请求状态代码描述待处理一个事件或服务请求被记录或创建; 已分派一个事件或服务请求已被分派给二线支持人员或事件和服务请求经理； 处理中任何一个支持人员或第三方（供应商）接受了事件或服务请求并开始处理; 挂起事件或服务请求信息不完整，或在某些情况下阻止事件或服务请求处理员对事件或服务请求进行处理，等待的原因为： 需要客户提供更详细的信息不能联系到用户人员升级到供应商处理采购定单的批准不可抗拒力原因已完成为一个事件或服务请求找到解决方案或变通方法; 为一个事件或服务请求找到解决方案或变通方法; 已关闭事件或服务请求经用户确认已关闭 ; 考核指标：序号衡量指标指标计算说明1事

28、件或服务请求总数 数量：在事件单或服务请求单中根据以下条件过滤 1.【重复事件或服务请求标记】为空 2.【事件或服务请求发生时间】在统计周期内 2事件或服务请求关闭的数量/比率 数量 ：在事件或服务请求总数中过滤【事件或服务请求状态】关闭 比率：数量 / 事件或服务请求总数 100 % 3事件或服务请求成功关闭的数量/比率 数量：在事件或服务请求总数中过滤【事件或服务请求结束代码】成功解决or变通方法解决 比率：数量 / 事件或服务请求总数 100 % 4用户反馈超时关闭的数量/比率 数量：在事件或服务请求总数中过滤【事件或服务请求结束代码】反馈超时关闭比率：数量 / 事件或服务请求总数 10

29、0 % 5超时解决的事件或服务请求数量/比率 数量：在事件或服务请求总数中过滤【解决是否超时】超时and 【事件或服务请求结束代码】成功解决or变通方法解决 比率：数量/事件或服务请求总数 100 % 6超时分配的事件或服务请求数量/比率 数量：在事件或服务请求总数中过滤【分配是否超时】超时and 【事件或服务请求结束代码】成功解决or变通方法解决比率：数量/事件或服务请求总数 100 % 7服务台及时解决率 数量：在事件或服务请求总数中过滤所有【解决是否超时】未超时and【事件或服务请求解决人角色】服务台工程师 比率：数量 / 事件或服务请求总数 100 % 8二线及时解决率数量：在事件或服

30、务请求总数中过滤所有【解决是否超时】未超时and【事件或服务请求解决人角色】二线工程师 比率：数量 / 事件或服务请求总数 100 % 9平均解决时间完成的事件或服务请求：在事件或服务请求总数中过滤所有【事件或服务请求状态】已解决or 已关闭的事件或服务请求 平均解决时间：累加完成事件或服务请求的（【事件或服务请求解决时间】【事件或服务请求登记时间】）/ 完成的事件或服务请求数量 10服务台解决率数量：在事件或服务请求总数中过滤所有【事件或服务请求分配次数】0 比率：数量 / 事件或服务请求总数 100 % 11二线解决率数量：在事件或服务请求总数中过滤所有【事或服务请求件解决人角色】二线工程

31、师 比率：数量 / 事件或服务请求总数 100 % 12用户满意度数量：所有事件或服务请求记录中【用户满意度】分值总计 / 事件或服务请求总数 问题管理目的规范问题管理流程的相关策略及活动，确保问题管理流程的执行质量和执行有效性。术语和定义问题：表示引起一个或多个现存或潜在事件的深层根源。已知错误：是指问题经过诊断分析后找到其产生的根源后所处的状态(Known Errors)。问题管理：是负责管理问题所有生命周期的流程，包括诊断故障根本原因和确定这些问题解决办法的活动。还要确保通过合适的控制过程实施解决办法，特别是变更管理和发布管理。规避措施：是解决事件的临时修复方法或技术，目的是使用替代措施

32、暂时消除用户对服务的依赖和减少事件对用户的影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。通过规避措施，用户能够在没有中断的情况下继续使用服务。规避措施通常会使用户的工作方式发生变化，比如从使用另一台PC、使用早期版本的软件、或临时提供更多的磁盘空间。角色职责问题经理协调问题管理流程的日常操作 对问题的有效性进行判断确保问题分派给问题分析专家确保问题分析专家在其管辖范围内的可用性和能力问题实施结果的评审与确认 问题提交人记录问题基本信息并将其与相应事件、CI进行关联将问题归类，初步设定其优先级将问题提交给问题经理与问题经理共同确认问题实施结果 问题分析专家进行深入的问题分析，以找出

33、根本原因，并提供解决方案问题实施人实施问题解决方案，如有需要，提起变更 记录问题实施结果，提请问题经理确认角色映射问题管理流程中定义的角色对应的数据中心人员问题经理问题提交人问题分析专家问题实施人流程描述此流程描述为示例，实施中需要根据实际和ITIL最佳实践做出调整。流程图流程描述活动序号活动名称详细描述相关表单1.1拟似问题信息收集并初步分类收集相关事件信息关联事件和配置初步将问题进行分类事件和服务请求单；问题工单1.2问题单提交问题提交人将生成的工单流转到问题经理问题工单1.3是否为问题问题经理根据问题定义判定问题如果是则转入1.4，否则注明原因，关闭问题单 1.4确认问题单分类并排定优先

34、级问题经理对问题分类、优先级进行确认问题工单1.5问题单分派根据问题类别将问题工单分派给相应问题分析专家问题工单2.1调查并诊断根据知识库排查故障判定是否为已知问题根据相关联配置项、历史事件排查问题根本原因制定解决方案/规避措施问题工单2.2是否挂起无法找到解决方案则挂起解决方案无法实施则挂起需要供应商操作则挂起其他情况转入1.11问题工单2.3挂起由问题经理将问题工单挂起问题工单2.4评审会议定期召开会议评审目前挂起问题工单处理方式问题工单2.5是否关闭问题当评审会议上问题分析专家一致决定无需解决的问题关闭评审会议决定强制关闭其他情况转入1.62.6给出解决方案/规避措施问题分析专家给出问题

35、的相关解决方案或规避措施问题工单2.7评审并分派问题经理确认方案可行性分派给相关问题实施人问题工单2.8实施方案根据解决方案进行相关实施活动2.9是否需要变更判定实施活动是否触发变更流程，如果触发则进入变更流程，如果不触发则转入1.152.10解决问题变更流程关闭解决方案活动完成3.1评审对问题是否解决进行确认评审解决方案的有效性问题工单3.2问题是否解决最终判定问题是否解决，如解决则转入1.18，未解决则转入1.63.3更新知识库将问题原因、解决方案/规避措施作为知识库更新的输入问题工单3.4关闭问题单问题经理关闭问题单问题工单流程间的关系 相关数据问题分类分类级别采用三级分类方式，即类别、

36、子类、项目。优先级优先级由影响度和紧急度两个因素决定优先级在问题管理的生命周期中是可以改变的。关于更改问题单优先级的原因和行为应该由问题经理进行操作。 影响度定义1极高关键业务系统的全局性故障基础架构的全局性故障2高关键业务系统和基础架构的局部故障普通应用系统的全局故障3-中普通应用系统的局部故障影响关键用户或多个普通用户4低单点故障影响普通用户紧急度 定义1极高客户接受的可耽搁时间：X小时需解决2高客户接受的可耽搁时间：X小时需解决3-中客户接受的可耽搁时间：X小时需解决4-低客户接受的可耽搁时间：无事件限制优先级影响度极高高中低紧急度极高1113高1223中1334低1344请求来源事件生

37、成通过临时方案解决的单个故障 对于可以通过白名单解决的故障，如在每周内重复发生3次或以上，需要当前故障处理人提交至问题，以后类似现象均关联至同一问题单直至问题解决。 主动分析 如果类似的故障在每周内重复发生3次或以上（服务台负责） 某类故障数量连续三月呈逐渐攀升态势（事件经理负责） 日常运维工作中发现的系统隐患或需重视的异常已知的尚未解决的技术缺陷 运维人员根据经验和分析判断状态代码问题状态代码描述待提交问题单提交前的信息收集过程已审核一个问题已分配至分析专家 挂起找不到解决方案或临时措施找到解决方案，但现有条件无法实施;找到解决方案，但需要供应商接入待审核找到问题的根本原因，已提交解决方案、

38、临时解决方案、变更申请等待评审待实施方案评审通过并指定实施人，等待实施已实施问题经理确认问题解决有效性后关闭已关闭问题经理确认问题解决有效性后关闭考核指标序号衡量指标指标计算说明1问题总数 数量：在问题单中根据以下条件过滤 1.【重复问题标记】为空 2.【问题发生时间】在统计周期内 2问题成功关闭的数量/比率 数量 ：在问题单总数中过滤【问题状态】关闭 比率：数量 / 问题总数 100 % 3问题及时成功关闭的数量/比率 数量：在问题总数中过滤【问题结束代码】成功解决 比率：数量 / 问题总数 100 % 4根据优先级归类，统计已关闭问题单的数量/比率 数量：在问题总数中过滤【问题结束代码】关

39、闭and【问题类别代码】=数据中心类比率：数量 / 数据中心类问题总数 100 % 5根据优先级归类，统计超出规定目标时间且已关闭问题单的数量/比率 数量：在问题总数中过滤【问题结束代码】关闭and【问题类别代码】=数据中心类and【关闭是否超时】超时比率：数量 / 数据中心类问题总数 100 %6问题关闭的平均时间 完成的问题：在问题总数中过滤所有【问题请求状态】已关闭的问题 平均解决时间：累加完成的问题（【问题关闭时间】【问题登记时间】）/ 完成的问题数量 7问题成功关闭的平均时间完成的问题：在问题总数中过滤所有【问题请求状态】已关闭的问题 and【问题结束代码】成功解决平均解决时间：累加

40、完成的问题（【问题关闭时间】【问题登记时间】）/ 完成的问题数量 变更&发布管理目的规范变更&发布管理流程的相关策略及活动，确保变更管理&发布流程的执行质量和执行有效性。术语和定义术 语缩略词定 义变更Change变更（Change）是指对IT运行环境中的配置项所作的增加、修改或移除，这些配置项（CIs）包括主机、网络、软件、应用、环境及相关文档。变更记录指经过授权的变更（包括计划中的和已实施的）对哪些配置项产生影响以及怎样产生影响的详细信息的记录。比如优先权的分配情况、影响评估与授权的具体时间等等。变更请求RFC(Request For Change)变更请求（如对软件特征的变更请求）必须由

41、变更管理流程进行评估，同时将对基础设施做出一定的修改。变更顾问委员会CAB(Change Advisor Board)变更顾问委员会（Change Advisory Board）指一组在实施变更时能够为变更管理提供专业意见的人。变更顾问委员会为变更经理提供接受或拒绝有关变更的建议。为了防止出现紧急问题时来不及召集所有变更顾问委员会成员的情况出现，有时候也在变更顾问委员会中设立应急委员会（Emergency Committee）。最终软件库DSL(Definitive Software Library)最终软件库是一个存放和保管所有已批准的最终版本的软件配置的库，它是软件正本（原版拷贝）存放的物

42、理性仓库或逻辑性的存储空间。DSL在可以在物理上分布于多个地点。最终硬件库DHS(Definitive Hardware Store)最终硬件库中包含了硬件的备件和库存，这些备用组件和配件得到与它们在实际运作环境中的对应组件相同级别的维护，可用来替换或修复IT基础架构中相似的配置。有关这些配置构成的详细信息应该被记录在配置管理数据库（CMDB）中。发布Release测试后导入实际应用的新增的或变动的配置项集合，这些配置项经过测试后引入生产环境（Live environment）。发布和部署管理RDM(Release and deployment management)发布和部署管理旨在控制软件

43、的发布和部署。发布和部署管理确保正式交付的软件是经过测试了的正确版本。流程解释变更&发布和部署管理是指采用标准统一的方法和步骤来管理、控制所有对IT运行环境有影响的变更&发布和部署活动。通过执行变更&发布和部署流程，对所有操作进行正确评估和实施，从而维护IT运行环境的完整性，减少由于准备不当等原因出现的对IT环境造成的风险。角色职责角色主要职责变更&发布和部署管理流程负责人变更&发布和部署管理解决方案的负责人； 对于整个变更&发布和部署管理解决方案的结果承担责任，并且具有相应权限； 变更经理负责变更管理流程的监控； 负责协调相关的资源，保障所有变更按照预定流程顺利运作； 确定变更级别，组织变更

44、计划和排程。管理变更的日程安排。 变更实施完成之后的回顾和关闭变更审批者（CAB）负责对变更进行评估，并确定是否批准； 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批；变更/发布请求者负责记录与提交变更/发布单； 提交初步的变更方案和计划 初步评价变更的风险和影响，给变更请求设定适当的变更级别；变更实施者负责按照计划实施变更的内容（包括必要时的恢复步骤）； 负责按照实施计划在生产环境中实施具体的变更任务； 角色映射变更管理流程中定义的角色对应的数据中心人员流程负责人变更经理变更审批者变更/发布请求者变更/发布实施者流程图概览图变更启动和记录评估和审批计划和排程变更实施完成和关闭流程

45、间的关系相关数据变更分类：使用三级（CTI）分类来对变更进行分类：类别（Category）类别是CTI分类方法的最高层。它将被用作对变更进行分组的第一层。例如：硬件、系统软件、网络、应用软件、数据库。子类（Type）子类用来区分每个“系统”的基本组成模块。它将被用作对变更进行分组的第二层。例如：对类别“硬件”来说，可以分为服务器、打印机和监视器等“子类”。项目（Item）这个层次体系中第三层是项目。项目这一层能够获得更详细的信息和更准确的搜索。状态代码：草拟启动RFC的填写请求受理提交RFC，等待变更受理员对变更请求进行受理受理中变更受理员接受了变更请求，并进行相关的活动等待审批变更审批者/变

46、更经理对RFC请求审批已批准变更审批者/变更经理批准了该变更请求或有关的计划、任务计划中变更受理员负责制定有关计划，包括分阶段提交的变更计划、测试计划已分派当完成计划审批环节后，由受理员将变更进行计划排程，并分派给实施员实施中变更实施员按照任务、排程实施，包括：上线中,测试中,构建中,回退中,文档中,检测中已拒绝请求已经过评估但受到拒绝已完成变更实施结束（无论成功或者失败）已关闭变更完成关闭代码结束代码描 述成功变更成功实施完毕部分成功变更部分成功成功但有问题变更成功但有问题未成功变更实施失败取消在实施前取消了变更考核指标：序号 衡量指标 指标计算说明 1变更总数当前变更的总数，用于了解系统中

47、记录的变更数量。 2变更关闭的数量/比率当前变更处于“关闭”状态的数量以及占总变更数的比例，用于了解变更处理完毕的情况。3紧急变更的数量/比率当前变更类型为“紧急变更”的数量以及占总变更数的比例，用于了解变更类型的分布情况。4被拒绝的变更数量/比率当前变更中未通过审批的数量以及占总变更数的比例，用于了解变更的审批情况。5被退回变更请求单的数量/比率当前变更中曾被退回的变更数量以及占总变更数的比例，用于衡量变更请求人填写RFC的质量。6变更成功关闭的数量/比率成功完成实施的变更数量以及占关闭变更数的比例，用于衡量变更管理流程的有效性。7变更失败的数量/比率未成功实施的变更数量以及占关闭变更数的比

48、例，用于衡量变更管理流程的有效性。8附带方案的变更的数量/比率附带变更方案附件的变更记录数量及占变更总数的比例，用于衡量变更主管的方案设计工作。9各类型的发布数量在指定时间段内各类型发布的数量统计10各分类的发布数量在指定时间段内各分类发布的数量统计云业务运维管理根据业界最佳实践，一个好的云业务运维管理平台，必须具备如下关键特性：面向业务的智能监控、分析及管理云业务管理平台能够从业务的视角对相关的应用资源进行监控和管理，能够图形化展示各个业务系统当前的健康状态、繁忙程度、可用状态、业务告警，同时能够根据业务的异常情况智能地分析和定位问题的根源， 从而为IT管理者提供综合运维管理的总体视图。云应

49、用资源统一监控云业务管理平台可对部署在云环境中的各类应用资源进行统一管理，包含各类操作系统、数据库、中间件、web服务器、URL/URL序列、各类自定义脚本等。云业务监控及分析H3C BSM Dashboard通过业务卡片实时展示各个业务系统当前的健康状态、繁忙程度、可用状态、业务告警总览，体现了业务的构成。是为管理者提供综合运维管理的总体视图，可以全面整体了解业务系统运行情况。可以以业务为单元，向下纂取监控资源趋势分析，基于时间轴同步技术分析对比该业务系统相关的监控数据汇总。Dashboard是整体全面了解企业业务现状的入口。业务可用度业务最新的可用度，基于业务内各个应用/设备的基础监控数据

50、计算得出，表示业务可用程度，此得分越高业务可用性越高。计算业务的可用度时，根据单个应用/设备的可用性状况计算出此节点的可用度得分，通过加权方法层层计算，最后得出业务的可用性得分。每一级都可以调整权重。其中，各个节点分成核心元素和非核心元素，如果核心元素不可用，则整个业务都不可用。业务健康度业务最新的健康度得分，基于业务内各个应用/设备的基础监控数据计算得出，表示业务健康程度，此得分越高为越健康。计算业务健康度时，通过单个应用/设备的告警数目和最高告警级别计算出此节点的健康度得分，通过与繁忙度类似的加权方法层层计算，最后得出业务的健康度得分。每一级都可以调整权重。业务繁忙度业务最新的繁忙度得分，

51、基于业务内各个应用/设备的基础监控数据计算得出，表示业务运转的繁忙程度，此得分越高为越繁忙。计算业务繁忙度时，通过单个应用/设备的性能指标计算出此节点的繁忙度得分，向上计算出所属大类（服务主机、业务应用、网络设备）的繁忙度得分，最后计算出业务的繁忙度得分，上层得分是由底层同级得分加权计算得出。除了指标级的，其他任何一级都可以调整权重。业务模型业务建模基于数据模型，数据模型包含IT资源 、关系、权重。IT资源构成了数据模型的架构，他们通过关系进行关联；业务模型除了需要定义业务类以外，还需要定义该IT资源对业务的影响权重，定义业务类归属、名称、描述、数据类型等。通过数据模型，可以查询业务组件之间、

52、业务和平台之间以及平台资源之间的关系，为业务管理数据处理和呈现提供统一的定义。业务建模是业务可视化展示、业务分析的基础。云业务故障定位及影响分析基于业务的故障管理及分析通过可视化业务视图帮助客户从业务全局看业务的某个组成部分故障对整个业务的影响度。H3C BSM可以根据企业实际业务情况建立业务服务模型，通过统一的业务视图表现各IT功能组件间的关联性，以了解各IT功能组件对业务的影响，通过建立的跨部门的服务视图，减少故障解决的时间。通过建立服务依存关系映射，建立业务服务、应用平台和底层IT系统构架之间的映射关系，并把它们放到统一信息管理库中进行实时更新和维护，这样你就可以快速地评估IT问题对业务

53、的影响。它可以复杂的IT环境具体化，让你看到网络、系统、应用等IT元素的依存关系，为你提供一个真实而完整的IT视图。业务视图将实时数据采集紧密集成来提供一个动态、全面、可操作的实时业务模型视图，来展现基础架构和业务之间的影响关系。当出现影响服务的告警事件时，会映射到模型中的对象上。并根据报警级别、业务影响的程度呈现不同的颜色，当该告警事件清除后，可以自动恢复其受影响前的状态。通过此视图用户可以了解一个或多个业务的当前运行状况，以便IT人员对发生的告警事件进行根源问题分析，快速定位问题，并确定业务的影响范围。业务模型视图将具备以下基本功能：支持对业务视图的多角色、多角度查看功能。提供灵活的图形界

54、面展现方式，能以基本关系、连接关系、影响关系等不同视角呈现业务服务模型。支持对业务模型中的各类对象状态和告警事件联动呈现，当出现影响服务的告警事件时，模型中的对象可以根据其受影响的程度呈现不同的颜色，当该告警事件清除后，可以自动恢复其受影响前的状态。支持业务模型中对象与告警事件列表之间的关联功能，点击模型对象时可列出相应的告警事件。统一应用资源管理提供了强大的系统与应用监控管理能力，可以对不同的业务系统、应用进行远程监控和管理，从而充分满足用户对各种关键业务和数据中心的监控管理需求。应用监视能够监视各种应用程序和服务器，包括：Windows服务器、Unix服务器、Linux服务器、数据库、应用

55、服务器、Web服务器、邮件服务器、Web服务、LDAP服务等。Windows服务器包括：Windows XP、各版本的Windows Server。Unix服务器包括：AIX、FreeBSD、OpenBSD、Solaris、Mac OS、HP-UX。Linux服务器包括：Linux。数据库服务器包括：Oracle（10g/RAC/11g）、MySQL（5.x）、MS SQL Server（2000/2005/2008/2012）、Sybase（12.5及以上）、IBM DB2（10.x以上）。应用服务器包括：.Net服务器、JBoss服务器、Tomcat服务器、Weblogic、WebSphe

56、re、GlassFish、Oracle AS.Web服务器包括：Apache 服务器、IIS服务器、PHP。邮件服务器包括：Exchange 服务器（2003/2007）。中间件包含：office SharePoint、WebSphere MQ。Web服务包括：REST服务、SOAP服务。LDAP包括：Active Directory服务、通用LDAP。SAP监视文件系统监视等主机管理支持对多种主机操作系统的管理，提供业务主机整体负载情况的监测，包括CPU负载，内存与虚拟内存利用率，主机网络会话数量、源与目的及流量信息，各个物理网络接口流量信息，设备连续运行时间等；支持业务主机各文件系统的磁盘

57、空间大小、利用率、剩余空间、inode利用率，磁盘增长率的管理；提供业务主机上关键进程的运行状况及其对CPU和内存占用情况的管理等。支持的操作系统：Windows服务器包括：Windows XP、各版本的Windows Server。Unix服务器包括：AIX、FreeBSD、OpenBSD、Solaris、Mac OS、HP-UX。Linux服务器包括：Linux。例如勘探生产和管理需要关注linux服务器上各个进程的工作状态，包括java服务状态、java服务个数、ESB服务状态、ESB服务个数、monitor服务状态、monitor服务个数、EcmDownloadServer、EcmUp

58、loadServer、EcmPlunginVserver服务状态、CassandraDaemon影像内存服务状态、heartbeat服务状态、drbd服务状态等，当关注的进程关闭时系统可触发告警。并以短信、邮件等多种方式通知管理者。数据库管理支持对各种数据库的管理，提供各种数据库可用性和性能的整体监控，包括数据库连接信息、数据库明细、表空间, 数据库大小、缓存性能、内存、读、写、I/O状态、SQL 统计、锁等等。支持的数据库包括：Oracle（10g/RAC/11g）、MySQL（5.x）、MS SQL Server（2000/2005/2008/2012）、Sybase（12.5及以上）、I

59、BM DB2（10.x以上）。应用服务器管理可管理各类应用服务器，可检测应用服务器的会话性能、虚拟机内存、线程池、事务状态、JMS, 队列、负载度量、运行模式等等。支持的应用服务器包括：.Net服务器、JBoss服务器、Tomcat服务器、Weblogic、WebSphere、GlassFish、Oracle AS.Web服务器管理可管理各类web服务器，包括web服务器的可用性、响应时间、访问性能统计、页面传输性能、当前状态等支持的web服务器包括：Apache 服务器、IIS服务器、PHP。邮件服务器管理可管理邮件服务器，包括IMAP当前连接数、POP当前连接数、队列状态、子服务工作状态等

60、。支持邮件服务器包括：Microsoft Exchange：2003、2007、2011 中间件管理可管理各类中间件，可管理中间件工作状态、队列状态、活动请求等。支持WebSphere MQ、Office SharePoint等。文件系统管理IMC支持对文件及目录的管理。文件监视器信息名称、健康状况、IP地址、应用类型、文件位置、最后轮询时间、依赖拓扑文件统计文件大小、最后修改时间目录监视器信息名称、健康状况、IP地址、应用类型、目录位置、最后轮询时间、依赖拓扑目录统计目录大小目录增量目录增量其他应用资源管理IMC还可管理其他各类应用资源，包括LDAP、SAP、服务端口、DNS、web等。多种