中国移动IT管理流程手册.docx

1、中国移动IT管理流程手册1 综述 51.1 本期目标 51.2 适用范围 61.3 主要内容 61.4 规范落实 71.5 持续改进 91.6 地市支持模式 111.7 相关术语 112 事件管理流程概要设计 162.1 流程目的 162.2 流程主要内容 162.3 与其他流程的关系 172.4 流程范围 172.5 流程执行原则 182.6 流程相关定义 192.7 流程概要设计 262.8 关键角色、职责定义 322.9 关键流程衡量指标 342.10 集团、省公司两级交互 352.11 省公司上报报表 352.12 实施指导 352.13 本期规范的主要变化 363 问题管理流程概要设

2、计 383.1 流程目的 383.2 流程主要内容 383.3 与其他流程的关系 393.4 流程范围 393.5 流程执行原则 393.6 流程相关定义 413.7 流程概要设计 433.8 关键角色、职责定义 453.9 关键流程衡量指标 463.10 集团、省公司两级交互 463.11 省公司上报报表 473.12 实施指导 473.13 本期规范的主要变化 474 配置管理流程概要设计 494.1 流程目的 494.2 流程主要内容 494.3 与其他流程的关系 504.4 流程范围 504.5 流程执行原则 504.6 流程相关定义 524.7 流程概要设计 574.8 关键角色、职

3、责定义 584.9 关键流程衡量指标 594.10 集团、省公司两级交互 594.11 省公司上报报表 604.12 实施指导 604.13 本期规范的主要变化 605 变更管理流程概要设计 625.1 流程目的 625.2 流程主要内容 625.3 与其他流程的关系 635.4 流程范围 635.5 流程执行原则 645.6 流程相关定义 665.7 流程概要设计 715.8 关键角色、职责定义 785.9 关键流程衡量指标 805.10 集团、省公司两级交互 815.11 省公司上报报表 815.12 实施指导 825.13 本期规范的主要变化 856 发布管理流程概要设计 866.1 流

4、程目的 866.2 流程主要内容 866.3 与其他流程的关系 886.4 流程范围 886.5 流程执行原则 886.6 流程相关定义 906.7 流程概要设计 936.8 关键角色、职责定义 986.9 关键流程衡量指标 996.10 集团、省公司两级交互 1006.11 省公司上报报表 1006.12 发布管理流程细化指导 1007 日常运维管理概要设计 1027.1 作业计划管理 1027.2 值班管理 1057.3 公告 1097.4 知识库 1117.5 机房出入管理（可选） 1148 附件A: CI属性设计 1188.1 硬件类CI 1188.2 系统软件类CI 1218.3 客

5、服设备类CI 1238.4 配套设施CI 1238.5 业务应用类CI 1238.6 文档类CI 1248.7 逻辑实体类CI 1258.8 安全设备类CI 1258.9 其他类CI 1269 附录B: CI关系对照表 12810 附录C: 厂商和集成商名称标准 13410.1 厂商名称标准 13410.2 集成商名称标准 13411 附录D: 省公司上报报表 13611.1 事件管理上报报表 13611.2 配置管理上报报表 14311.3 问题管理上报报表 14611.4 变更管理上报报表 14911.5 发布管理上报报表 1531 综述本规范是在一期中国移动业务支撑网运营管理系统规范和附

6、件一、业务支撑网网管规范-服务管理流程分册基础上，收集整理并总结各省一期建设、使用经验及需求，结合BOSS3.0规范、经营分析系统v2.0规范、中国移动萨班斯法案.业务支撑网.改造指导意见相关要求，参考ITIL 3.0、ISO20000最新进展情况，综合分析形成。本规范作为中国移动业务支撑网运营管理系统维护管理流程的统一核心版本，具有如下目的： 建立和健全基于ITIL的中国移动业务支撑网维护管理基本框架，提升运维管理效率。 对中国移动集团公司和各省公司业务支撑网的运行维护进行规范化、统一化管理。 指导各省业务支撑网维护管理细化流程的设计和业务支撑网运营管理系统的实施。1.1 本期目标服务管理应

7、在保障“两个巩固、两个加强”的基础上，实现“两个落实、两个引入、两个固化”的目标。 “两个巩固”是指巩固事件管理成果、巩固变更管理成果。一期各省运维工作成效比较显着的是针对IT基础架构的系统支持工作中处理故障告警的事件管理和设备变化的变更管理，本期应坚持和巩固这些成果。 “两个加强”是指加强配置管理工作、加强问题管理工作。 本规范总结一期配置管理和问题管理工作的经验，精简配置管理CI范围和属性数量，形成关键CI。各省应坚决落实角色职责和配置维护和审核任务，保证核心数据的准确性和有效性。 各省应明确问题管理目的、来源以及与事件管理的区别，坚决把问题管理工作落实到问题管理流程中。 “两个落实”是指

8、落实客户投诉管理工作、落实日常需求管理工作。 各省应建立和完善与客服投诉管理系统的接口，坚决把客户投诉处理工作纳入到事件管理流程和系统中去。 各省应把日常化业务需求的评估、实现、测试、培训、割接上线过程纳入到变更管理和发布管理流程中去。 “两个引入”是指引入日常运维管理，引入发布管理流程。 各省应按规范要求把机房值班，作业计划、机房进出等工作管理起来。 各省应利用发布管理流程管理系统测试、培训、部署、割接上线的过程。 “两个固化”是指固化角色职责映射、固化流程模型。 本规范根据各省实际情况对流程的角色职责进行了精简，提出了归并原则和建议，尽量避免同一流程中一人多角。各省应严格落实角色到人员岗位

9、的映射，固化落实人员岗位的职责。 各省应结合事件和变更流程规范，逐步把日常工作中频发任务进行归类和抽象，固化处理环节、人员和表单项，不断形成事件和变更流程模型。1.2 适用范围本规范适用于中国移动集团公司和各省公司的业务支撑系统维护管理工作，涉及BOSS(含客服)、经分和BOMC等系统的基础架构，以及业务应用的日常运维，包括日常值班、故障投诉处理、变更割接等维护业务过程的管理，不包括项目建设、软件开发等过程的管理。业务应用系统中日常化的需求申请、审批、实现、测试和上线过程的管理包括在本规范中。1.3 主要内容本规范包括对一期定义的事件管理、问题管理、配置管理和变更管理规范的优化和更新，同时增加

10、了日常运维管理和发布管理规范，并特别强调流程的实用性和持续改进过程。 日常运维管理包括值班管理、作业计划管理、机房进出管理和知识经验管理等内容，主要定义和规范日程进行的常规任务和工作。 事件管理记录和管理故障从发生到业务恢复的过程，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求。 问题管理记录和管理故障根源分析和解决的过程，包括事件处理在业务恢复后仍需进行深入分析的故障、日程维护中发现的尚未影响业务的故障、工作例会上对事件进行趋势分析确定的潜在故障。 配置管理数据库CMDB记录和维护IT基础架构和业务应用的配置项CI、相关属性信息和CI的相互

11、之间的关系。配置管理是对CMDB的规划、建立、维护和审核过程的管理，保证CMDB的完整性、实效性和权威性，为其它流程提供良好的支撑。 变更管理跟踪和记录变更评估、审批、实施和验证的过程，包括IT基础架构中设备、部件、板卡、配置的新增、变更和下线，也包括非项目性质、日常化业务需求的新增和变更。 发布管理跟踪和记录新系统测试、培训、部署、上线的过程，包括大版本测试上线发布和日常化需求变更的测试上线。这些服务流程的总体构架和互相之间的关系如下：图1. IT服务管理流程的关系1.4 规范落实本规范更加注重规范实用性和先进性的平衡，充分考虑流程角色与实际组织的映射、流程环节与实际工作的对应、ITIL术语

12、与各省习惯用语的翻译，在保证流程实用性的前提下借鉴ITIL3.0、ISO20000理念，保证规范的先进性。1.4.1 规范角色和实际岗位的映射综合各省业务支撑中心中各职能部门架构并进行抽象，与本规范相关的职能组织如下图所示： 系统支持：负责IT基础架构的支持维护。一般按照被管系统类型或范围进行分工，例如按照机房、网络、主机、数据库、安全分工负责； 业务支持：负责BOSS、经分等业务应用的支持维护，一般按照业务模块分工，例如按照计费、结算、营业、帐务分工负责； 机房值班：负责机房值班，接听值班报障电话，使用BOMC系统监控IT基础架构和业务应用。一般由专门人员或系统支持轮流值班； 投诉受理：负责

13、受理、处理和跟踪来自客服等部门的客户业务投诉； 设备和开发厂商：负责对所提供的设备或系统提供远程或现场支持。图2. IT服务管理角色与岗位的对应关系本规范各流程相关角色定义参见后续章节，与各省业务支撑中心典型的职能组织的对应关系如上图和下表所示。表1 IT服务管理角色与岗位的对应关系 职能部门规范流程机房值班投诉受理系统支持/业务支持部门领导/主管系统支持/业务支持专业管理人员设备和开发厂商事件管理流程服务台事件经理一线支持二线支持三线支持问题管理流程问题经理问题处理专家问题处理厂商变更管理流程变更经理、CAB成员变更请求者、变更主管、变更实施人员变更实施人员配置管理流程配置经理配置管理员发布

14、管理流程发布经理发布主管、发布实施人员、培训主管发布实施人员1.4.2 规范流程和实际工作的对应本规范各流程是遵照ITIL术语和分类方式组织的，与各省业务支撑中心日常负责的主要工作是相互对应的，如下图及下表所示：图3. IT服务管理流程与运维工作的对应关系表2 IT服务管理流程与运维工作的对应关系对应关系规范定义的流程目前实际工作说明规范与实际基本对应的事件管理系统故障处理客户投诉处理其中客户投诉处理在本规范中有明确、细致的定义变更管理发布管理系统变更过程需求实现过程本规范明确定义日常化的需求实现过程属于变更和发布管理流程日常运维日常运维包括值班、作业计划、机房进出、知识库等规范要求，实际工作

15、未全面开展的问题管理故障分析日常根源分析工作是故障处理的一部分，没有明确的确定、评估和知识经验积累配置管理没有基本的配置数据收集、维护和审核的业务过程实际在做,不属于规范范围的项目管理项目建设、管理和随工是各级员工的重要工作，但不在本规范范围内开发管理项目性质的大型软件开发中的需求管理和开发管理是业务支撑中项目管理和随工人员参与的重要工作，但不在本规范范围内1.5 持续改进各省运维管理体系需要不断调整和优化，以适应不断变化的实际环境。管理体系的规划、落实和改进优化遵循PDCA持续改进的质量控制原则，通过“计划、执行、检查和改进”的不断循环、螺旋上升的过程来持续提高运维管理体系的有效性。运维管理

16、水平的持续改进需要组织和流程的保障。组织上必须落实“流程负责人”角色，并赋予相应权限；流程上必须建立和落实日常化推广、落实、监督、检察制度和定期的流程改进优化制度。本规范为每个流程都定义了流程经理角色，建议各流程经理由各职能部门经理或负责人分别担任，负责流程及对应维护任务的落实和管理工作。本规范专门定义了流程负责人角色，建议由业务支撑中心主任授权专人专职担任事件、问题、变更、配置、发布和日常运维的流程负责人，对流程的科学性、实用性和落实情况负责。图4. IT服务管理各角色之间的对应关系如图所示，如果把运维管理体系比作一部法典，那么流程负责人就是立法者和监督者，流程经理是执法者，而各省业务支撑中

17、心专业技术人员是守法者。可见，流程负责人对保障服务体系的合理性和有效性是多么重要。流程负责人对IT服务管理流程的合理性、有效性和落实情况负责，从整体上把握流程的计划、实施、监督和持续改进，其主要职责为: 规划 有义务参加集团公司运维管理策略、规范制定工作； 负责运维管理规范在本省的角色映射、流程细化和流程模型固化。 实施 负责撰写、维护和更新各种模版、操作规范、操作指南、检查表等； 负责宣贯运维管理体系的角色职责、服务流程和考评体系了； 负责执行运维管理体系持续优化流程。 监督 保证流程运作达到预期目标，对流程结果负责； 负责监督流程落实和运行情况，及时发现和解决问题，保障流程活动的落实； 负

18、责监控流程绩效。 改进 负责组织召开流程运行情况分析例会，识别、分析流程改进需求，汇总、形成优化建议； 有义务参加集团公司流程优化研讨会，汇报、讨论和确定流程改进需求和优化方案。流程日常的推广、落实、监督、检查制度和定期的流程改进优化制度的落实由持续改进流程实现，流程负责人主导该流程的运行，管理层和各级员工有义务参与该项活动。持续改进流程建议每半年执行一次。持续改进流程如下图所示：图5. IT服务管理持续改进流程1.6 地市支持模式本规范面向用户包括总部、各省公司及地市公司业务支撑部门相关运行维护和管理人员。地市公司参与方式有如下几种，各省公司可以根据实际情况选择：图6. 地市支持模式 模式一

19、：本规范对地市运维工作不做强制要求。地市公司业务支撑人员作为本系统的客户，可以提出服务请求，得到业务支撑中心的服务。 模式二：省公司业务支撑运行维护工作涉及到地市公司的，地市公司业务支撑人员按照本规范要求执行；与省公司无关的本地运维维护工作不受规范约束。例如省公司统一的事件受理和处理、变更执行、发布测试、配置收集等工作，需要地市公司配合的，应把角色映射到地市公司，地市公司人员按需使用本系统。 模式三：地市业务支撑人员所有的运行维护工作均遵守本规范执行。例如：地市自己的日常运维、故障处理和设备维护等。地市业务支撑人员完全映射到本规范角色中并承担相应职责，每个地市业务支撑人员以独立帐户使用本系统。

20、1.7 相关术语 ITIL（IT Infrastructure Library ）是英国政府在1987年制定的有关IT服务管理的方法论，其核心是服务支持和服务交付10个核心流程，现已成为事实上的IT管理标准。ITIL可以提供针对个人的从业资格认证。 ITIL 3.02007年发布的ITIL最新版本，把IT管理从“服务”层面上升到“业务”层面，更加强调服务的规划、设计、建设、运维全过程的持续改进。图7. ITIL3.0框架 ISO20000国际标准组织ISO/IEC在2005年底发布的全球IT服务管理标准，包括服务实施、控制、发布、解决、关系管理5个域13个流程，强调持续改进过程。ISO2000

21、0可以提供针对企业或部门的国际标准认证。图8. ISO20000流程 运维职能（Operation Function）ITIL 3.0把运维职能部门概括为服务台、技术管理、应用管理和操作管理四类，对应于投诉热线受理、基础架构维护、业务应用维护和机房值班等职能分工。图9. IT运维职能分工 服务台（Service Desk）服务台提供用户和IT部门的唯一接口。目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。例如：值班组和投诉受理组往往充当服务台，省内或全国统一对内故障/业务受理电话往往是服务台成功建设的标志。 事件管理（ Incident Ma

22、nagement）ITIL流程之一，事件管理负责处理IT事件和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，是以解决表征现象为目的，而不在于查找根本原因。 问题管理（Problem Management）ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。 应急预案（Work-around）为迅速处理故障，快速恢复业务事先总结制定的临时处理措施。 配置管理（Configuration Management）ITIL 流程之一，配置管理负责描述，跟踪和

23、汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。 配置管理数据库（CMDB - Configuration Management Database）是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。 变更管理（Change Management）ITIL流程之一，变更管理通过控制和管理IT相关的变更， 使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。 变更申请单（RFC， Request For Change）变更请求的载体，

24、是贯穿变更过程，在客户与变更处理相关人员之间进行信息沟通的媒体。 变更窗口变更窗口是指定期将执行时间相近的变更，汇集在一个时间段内共同执行，这样可以减少因为中断业务、停机等对生产的影响。建议各省根据具体情况，制定固定的变更窗口。变更窗口只适用于标准变更。 流程模型（Process Model）ITIL3.0针对频发事件或变更提出的，预先建立固化处理过程的模型。例如板卡更换过程、口令复位流程等。流程模型中应包括处理的环节/步骤、每环节的负责人员、表单的预定于字段等。流程模型的不断建立、丰富和修正是流程落实和持续改进的重要内容。要建立新的流程模型，需要梳理日常实际工作流程，形成工作流程图；然后结合

25、规范映射角色，补充完善工作步骤，形成固化的流程模型。 发布管理（Release Management）ITIL流程之一， 发布管理通过规范的方法和流程，计划和监控新服务（包括软件和相关硬件）的部署和发布过程，提高上线成功率，降低可能的问题和风险。 最终软件配置库(DSL, Definitive Software Library）用于保存生产环境中所有所需软件的最终权威版本的介质或映像的物理或逻辑存储空间，例如保存软件光盘的存储柜或保存软件映像的文件服务器。在ITIL3.0中，DSL更新为DML(Definitive Media Library)图10. 最终软件配置库 持续改进（Continu

26、ous Service Improvement）服务管理体系的规划、落实和改进优化应遵循 “计划、执行、检查和改进”这样一个不断循环、螺旋上升的过程来持续提高监控管理体系的有效性，该过程符合PDCA持续改进的质量控制原则。图11. 流程持续改进 RACI模型（Responsible, Accountable, Consulted, Informed）ITIL 3.0明确提出的责任模型，描述组织/个人/角色在某项任务/活动中承担的不同责任。R(有义务)表示在活动中务承担义务，A(负责任)表示需要对活动的结果负责，C(提建议)表示可以对活动提供咨询意见，D(需知晓)表示需要了解活动情况。2 事件管

27、理流程概要设计2.1 流程目的事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括： 在成本允许的范围内尽快恢复IT服务- 快速响应服务请求（电话/Web/邮件等）- 用户在线获得帮助- 沟通事件解决的状态 - 和客户确认事件的解决 进行事件控制- 按规范记录事件- 就事件的优先级，影响度进行分类- 分析，诊断，必要时进行升级- 监视并结束事件- 进行定期服务流程回顾 提供IT管理信息- 人力资源利用情况- 故障处理情况- 支持效率2.2 流程主要内容事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容： 事件检测和记录 这个环节是事件管理流程

28、的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。该环节的关键是信息的准确性和完整性。 分类和初步支持对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。 调查和诊断 若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。 解决和恢复支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并

29、得到用户的确认。 优先级为紧急的事件（紧急事件）和事件升级对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。 结束事件当用户确认事件解决后，此时可结束该事件。2.3 与其他流程的关系 和问题管理流程的关系事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。 和配置管理流程的关系需要从配置管理数据库中查询

30、配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。 和变更管理流程的关系服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。 和知识库的关系事件得到解决后，解决的过程中所获得的经验以及相关解决方案可以进入知识库，作为知识保存，为后续的工作提供指导。2.4 流程范围事件管理范围包括与BOSS系统、经营分析系统、容灾系统和BOMC系统相关的所有IT生产环境所产生的申告、故障、告警、咨询和客户投诉。不包括： 尚处于开发或测试环境的系统和应用引发的事件2.5 流程执行原则2.5.1 常规原则 所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估 应该半年对流程进行回顾