中国移动NGBOSS2BOMC(V3.0)运维管理中心分册

中国移动业务支撑网运营管理系统NGBOSS2-BOMC(v3.0)规范-运维管理中心分册中国移动通信企业标准QB-J-0XX-2010业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范运维管理中心分册版本号：1.0.0 目 录1.范围12.引用标准23.术语和定义34.符号和缩略语45.总体功能描述55.1功能定位55.2功能框架55.3功能演进76.事件管理流程96.1流程目的96.2流程主要内容96.3与其他流程的关系106.4流程范围116.5流程执行原则116.5.1常规原则116.5.2所有权原则126.5.3再分派原则126.5.4重复事件原则136.5.5关闭原则136.5.6升级原则136.6流程相关定义146.6.1事件信息项146.6.2事件性质156.6.3事件来源166.6.4所属系统类型166.6.5事件分类176.6.6事件优先级186.6.7事件响应时限和解决时限206.6.8事件影响度206.6.9事件状态216.6.10事件结束代码226.6.11事件解决人角色226.6.12处理是否超时226.6.13故障厂商236.7流程概要设计236.7.1紧急事件处理子流程266.7.2客户投诉处理子流程286.8关键角色、职责定义306.8.1事件经理316.8.2帮助台人员316.8.3一、二线支持人员316.8.4三线支持人员326.9关键流程衡量指标326.10集团、省公司两级交互336.10.1紧急事件上报336.10.2集团协查事件下发346.11省公司上报报表366.12实施指导366.12.1流程图、流程角色定义与映射366.12.2流程衡量指标和报表366.12.3事件信息项366.12.4流程相关定义366.13本期规范的主要变化387.问题管理流程397.1流程目的397.2流程主要内容397.3与其他流程的关系407.4流程范围407.5流程执行原则417.5.1常规原则417.5.2所有权原则417.5.3创建原则417.5.4退回和转派原则427.5.5重复问题原则427.5.6问题关闭原则427.5.7问题单重开原则427.6流程相关定义427.6.1问题信息项427.6.2问题来源447.6.3问题优先级447.6.4问题状态457.6.5所属系统类型457.6.6问题分类457.6.7问题结束代码457.7流程概要设计467.8关键角色、职责定义487.8.1问题经理487.8.2问题处理专家497.8.3问题处理厂商497.9关键流程衡量指标497.10集团、省公司两级交互507.11省公司上报报表507.12实施指导507.12.1流程图、流程角色定义与映射507.12.2流程衡量指标和报表517.12.3问题信息项517.12.4流程相关定义517.13本期规范的主要变化528.变更管理流程538.1流程目的538.2流程主要内容538.3与其他流程的关系548.4流程范围558.5流程执行原则568.5.1常规原则568.5.2所有权原则568.5.3流程关联原则568.5.4变更实施记录原则578.5.5变更分类执行原则578.5.6审批上报原则578.5.7变更通知原则588.5.8紧急变更处理原则588.5.9变更测试原则588.5.10变更文档控制原则588.6流程相关定义598.6.1变更信息项598.6.2变更来源608.6.3变更类型618.6.4变更是否中断业务618.6.5变更是否需要测试618.6.6风险等级628.6.7所属系统类型638.6.8变更分类638.6.9是否启动集团审批或备案648.6.10变更状态648.6.11回顾代码648.6.12变更结束代码658.6.13变更实施单信息项658.7流程概要设计668.7.1紧急变更子流程708.7.2变更实施过程728.8关键角色、职责定义738.8.1变更经理748.8.2变更请求者748.8.3变更主管748.8.4变更委员会CAB、紧急变更委员会ECAB758.8.5变更实施人员758.9关键流程衡量指标768.10集团、省公司两级交互768.10.1集团公司审批的交互768.10.2集团公司备案交互778.10.3割接类变更说明778.10.4外部变更说明788.10.5两级交互流程798.11省公司上报报表808.12实施指导808.12.1流程图、流程角色定义与映射808.12.2流程衡量指标和报表818.12.3变更信息项818.12.4变更实施单信息项818.12.5流程相关定义818.13需求管理流程828.13.1流程目的828.13.2流程主要内容828.13.3与其他流程的关系838.13.4流程范围838.13.5流程执行原则838.13.6流程概要设计838.13.7关键角色、职责定义868.13.8关键流程衡量指标868.13.9实施指导868.14本期规范的主要变化869.发布管理流程879.1流程目的879.2流程主要内容879.3与其他流程的关系899.4流程范围909.5流程执行原则909.5.1流程常规原则909.5.2流程关联原则909.5.3发布通知原则919.5.4DSL管理控制原则919.5.5软件版本的策略原则919.5.6发布集成测试与用户测试原则919.5.7发布拒绝原则929.5.8发布频率原则929.6流程相关定义929.6.1发布信息项929.6.2发布来源949.6.3发布类型949.6.4发布是否中断业务949.6.5是否需要系统测试949.6.6是否需要用户测试959.6.7系统测试结果959.6.8用户测试结果959.6.9发布状态959.6.10发布结束代码969.6.11发布工作单信息项969.6.12发布工作单状态979.6.13发布工作单关闭代码979.7流程概要设计979.7.1重大发布管理流程979.7.2日常发布管理流程1019.8关键角色、职责定义1039.8.1发布经理1039.8.2发布主管1039.8.3发布实施人1049.8.4培训主管1049.9关键流程衡量指标1059.10集团、省公司两级交互1059.11省公司上报报表1059.12实施指导1059.12.1流程图、流程角色定义与映射1059.12.2流程衡量指标和报表1069.12.3发布信息项1069.12.4发布工作单信息项1069.12.5流程相关定义1069.13本期规范的主要变化10710.配置管理流程10810.1流程目的10810.2流程主要内容10810.3与其他流程的关系10910.4流程范围10910.5流程执行原则11010.5.1常规原则11010.5.2所有权原则11010.5.3流程关联原则11010.5.4控制原则11110.5.5审核原则11210.6流程相关定义11210.7流程概要设计11210.8关键角色、职责定义11410.8.1配置经理11410.8.2配置管理员11410.9关键流程衡量指标11510.10集团、省公司两级交互11510.11省公司上报报表11610.12实施指导11610.12.1流程图、流程角色定义与映射11610.12.2流程衡量指标和报表11611.日常运维管理11711.1作业计划管理11711.1.1目的11711.1.2主要内容11711.1.3执行原则11811.1.4相关定义11811.1.5流程设计11911.1.6关键角色、职责定义12111.1.7关键流程衡量指标12211.1.8实施指导12211.2任务管理12311.2.1目的12311.2.2主要内容12311.2.3执行原则12411.2.4相关定义12411.2.5流程设计12511.2.6关键角色、职责定义12611.2.7关键流程衡量指标12711.3值班管理12711.3.1目的12711.3.2主要内容12811.3.3与其他流程的关系12811.3.4执行原则12911.3.5相关定义12911.3.6值班管理概要流程13011.3.7关键角色、职责定义13111.3.8关键流程衡量指标13211.4公告管理13211.4.1目的13211.4.2主要内容13211.4.3执行原则13311.4.4相关定义13311.4.5流程设计13311.4.6关键角色、职责定义13411.4.7集团、省公司两级交互13511.4.8关键流程衡量指标13611.5知识管理13611.5.1目的13611.5.2主要内容13611.5.3与其它流程的关系13711.5.4执行原则13711.5.5相关定义13811.5.6流程定义14011.5.7关键角色、职责定义14111.5.8关键流程衡量指标14211.6两级协作管理14211.6.1目的14211.6.2主要内容14211.6.3执行原则14311.6.4相关定义14311.6.5流程定义14411.6.6关键流程衡量指标14612.安全管理14812.1账号权限管理（4A写完后，放在本处）14812.2机房出入管理（可选）14812.2.1目的14812.2.2主要内容14812.2.3执行原则14912.2.4相关定义14912.2.5流程定义14912.2.6关键角色、职责定义15113.接口要求15313.1概述15313.2接口原则15413.3接口协议15414.附录: 省公司上报报表15614.1事件管理上报报表15614.1.1按业务系统和优先级分类统计报表15614.1.2按细分的业务系统和优先级对故障统计的报表15714.1.3按业务系统和影响度分类统计报表15814.1.4按细分的业务系统和影响度对故障统计的报表15914.1.5按业务系统和事件性质对事件处理效率统计报表16014.1.6按事件分类和优先级对故障统计报表16214.1.7按细分的业务系统统计故障造成的业务中断时长报表16414.1.8故障厂商统计16514.2配置管理上报报表16714.2.1配置项审核及变化状态报表16714.2.2配置项汇总报表16814.2.3按应用系统对小型机/PC服务器进行统计的报表16914.2.4按厂商对小型机/PC服务器进行统计的报表16914.2.5按应用系统对磁盘阵列进行统计的报表17014.2.6按厂商对磁盘阵列进行统计的报表17114.3问题管理上报报表17114.3.1按业务系统对新增问题进行统计的报表17114.3.2按问题分类对新增问题进行统计的报表17314.3.3按业务系统对关闭问题进行统计的报表17514.3.4按问题分类对关闭问题进行统计的报表17614.4变更管理上报报表17714.4.1按细分的业务系统对新增变更进行统计的报表17714.4.2按变更分类对新增变更进行统计的报表17914.4.3按细分的业务系统对关闭变更进行统计的报表18014.4.4按变更分类对关闭变更进行统计的报表18114.4.5各业务系统业务中断时间统计18214.5发布管理上报报表18314.5.1按发布所属系统类型统计新增发布数量18314.5.2按发布分类统计新增发布数量18414.5.3按发布所属系统类型统计关闭发布数量18514.5.4按发布分类统计关闭发布数量18614.5.5各业务系统业务中断时间统计18714.6日常运维管理报表18714.6.1按作业计划分类统计周期性维护作业工作量18714.6.2按任务分类统计任务工作量18814.6.3按日常运维管理分类统计工作量18814.6.4按知识分类统计知识量18915.编制历史19015.1版本信息19015.2更新时间190中国移动业务支撑网运营管理系统NGBOSS2-BOMC(v3.0)规范-运维管理中心分册1. 范围本规范作为中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范的组成部分，阐述了运维管理中心总体架构和建设目标，从体系结构、建设原则、管理范围等方面进行了规范性描述。本规范适用于中国移动业务支撑网运营管理系统的开发、设计和建设，供中国移动内部和厂商共同使用；是中国移动各省（直辖市、自治区）业务支撑网运营管理系统建设和软件开发的技术指导性文件。中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范由一本总册、7本分册组成，分别为：中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-总册中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-资源管理分册中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-指标管理分册中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-监控管理中心分册中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-业务管理中心分册中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-运维管理中心分册中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-运营分析中心分册中国移动业务支撑网运营管理系统NGBOSS2-BOMC(V3.0)规范-省部两级接口分册2. 引用标准1NGBOSS2-BOSS(V3.0)业务规范V1.0.02NGBOSS2-BOSS(V3.0)技术规范V1.0.03NGBOSS2-CRM(V3.0)业务规范V1.0.04NGBOSS2-CRM(V3.0)技术规范V1.0.05NGBOSS1-宽带P-BOSS(V1.0)业务规范V1.0.06NGBOSS1-宽带P-BOSS(V1.0)技术规范V1.0.07NGBOSS2-BASS(V3.0)业务规范V1.0.08NGBOSS2-BASS(V3.0)技术规范V1.0.09业务支撑系统运营管理指标体系（v1.2）10中国移动业务支撑网运营管理系统规范V2.0.03. 术语和定义表3-1 术语和定义名词解释资源运营管理系统所有管理对象，包括业务支撑网各系统的软硬件、应用、业务。概念来源于SID模型中的ManangedEntity。业务资源的一类，指运营商为客户提供的服务，也可以叫做业务服务。如：缴费、开户等。应用资源的一类，从系统的视角定义各系统模块提供的服务，也可以叫做应用服务。如：计费预处理、计费采集等。逻辑资源资源的一类，逻辑上客观存在的管理对象。如：文件系统、表等。物理资源资源的一类，物理上客观存在的管理对象。如：主机、系统软件等。业务过程业务过程是一组有关联的业务的组合，用来描述特定业务场景下一组业务的序列关系。故障指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的状态 如：系统宕机、进程僵死等。告警告警是指在资源出现故障或性能达到阈值时，监控系统或者资源本身对外发布的警示信息。预警预警是指除明确的故障告警以及性能告警以外，通过对性能数据分析，发现潜在的问题，提前产生的警示信息。指标采用量化的方式对一个对象进行测量评价的数据定义称为指标。指标包括故障指标、性能指标等。指标维度指标维度是指在用指标评价对象的时候，所引用的不同视角。指标类型对指标按评价要求进行的分类，如时长、效率、数量等。组织指以人为元素构成的实体，如：移动公司、业务支撑中心、各科室部门。可用性业务可用性是对业务是否可用表现的评价。业务水平业务水平管理是通过建立业务水平标准，从区域或渠道等维度评估业务办理效率。业务健康度业务健康度基于业务管理模型将业务可用性、业务水平，结合应用及平台资源使用情况通过计算实现对业务运营健康状态的综合评价。服务水平指业务支撑部门对外提供服务的性能和质量度量。能力管理指通过对业务支撑系统测量和记录系统容量、系统性能等服务信息来评估和预测系统和业务的未来需要。4. 符号和缩略语表4-1 缩略语缩写英文中文描述BOMCBusiness Operation Management Center业务支撑网运营管理系统BOSSBusiness Operation Support System中国移动定义和建设的业务运营支撑系统BASSBusiness Analyse Support System业务分析支撑系统CRMCustom Relationship Management客户关系管理PBOSSProduct Business Operation Support System产品运营支撑系统BAMBusiness Activity Monitor业务活动监控KPIKey Performance Indicator关键运行指标KQIKey Quality Indicator关键质量指标4AAccount、Authentication、Authorization and Audit帐号管理、授权管理、认证管理与审计管理ITILIT Infrastructure LibraryIT基础设施库，是英国国家电脑局开发的IT管理最佳实践文档CIConfiguration Item配置项CMDBConfiguration Management DatabaseITIL中定义的配置管理数据库SLAService Level Agreement服务级别协议SLMService Level Management服务水平管理SNMPSimple Network Management Protocol简单网络管理协议CORBACommon Object Request Broker Architecture 公共对象请求中介结构SMTPSimple Mail Transfer Protocol简单邮件传送协议FTPFile Transfer Protocol文件传输协议WAPWireless Application Protocol无线应用协议5. 总体功能描述5.1 功能定位运维管理中心作为本期BOMC系统四个功能中心之一，主要对业务支撑部门各运维流程进行管理，服务于包括运维人员、管理人员在内的业务支撑部门各级人员，通过事件、问题等ITIL标准流程以及日常运维、安全管理等内部流程的梳理实施，规范了业务操作、投诉处理、故障响应、系统升级和需求开发等部门日常运维工作，实现了运维工作的流程化、透明化、知识化，整体上提升了业务运作的质量和运维工作的效率。运维管理中心还通过运维报表等功能帮助改进流程、提高工作效率。图5-1 运维管理中心功能定位5.2 功能框架运维管理中心的功能框架如图所示：图5-2 运维管理中心框架n 事件管理记录和管理故障从发生到业务恢复的过程，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉。n 问题管理记录和管理故障根源分析和解决的过程，包括事件处理在业务恢复后仍需进行深入分析的故障、日程维护中发现的尚未影响业务的故障、工作例会上对事件进行趋势分析确定的潜在故障。n 变更管理跟踪和记录变更评估、审批、实施和验证的过程，包括IT基础架构中设备、部件、板卡、配置的新增、变更和下线。n 发布管理跟踪和记录新系统测试、培训、部署、上线的过程。n 配置管理数据库CMDB记录和维护IT基础架构和业务应用的配置项CI、相关属性信息和CI的相互之间的关系。配置管理是对CMDB的规划、建立、维护和审核过程的管理，保证CMDB的完整性、实效性和权威性，为其它流程提供良好的支撑。n 日常运维管理包括作业计划管理、任务管理、知识管理和两级协作管理等内容，主要定义和规范日程进行的常规任务和工作。n 安全管理包括账号权限管理和机房出入管理，规范4A账号申请变更的过程以及对出入机房人员的权限进行控制。这些服务流程的总体构架和互相之间的关系如下：图5-3 服务流程关系图5.3 功能演进以前期BOMC系统服务管理平台为基础进行扩展和细化，推动实现流程的电子化，强调流程的实用性和提升工作效率目标：n 加强实现流程的关联和互通，实现真正的闭环管理。n 新增需求管理流程，规范需求开发流程，促进各省建立、健全需求管理制度，明确需求管理相关岗位职责和组织架构，提高需求管理电子化水平。n 丰富维护作业管理流程：包括作业计划管理、任务管理、知识管理等其他维护作业需要的定制化流程。n 明确和优化发布流程和变更流程的应用。n 在各个流程中打通总部和省公司之间的交互通道，如全网公告、省公司与总部之间的一些协查单、调度单等交互功能。功能二期本期远期事件管理流程引入客户投诉处理流程强调闭环管理流程互通问题管理流程在流程处理中引入厂商强调闭环管理流程互通变更管理流程l 明确变更和发布的关系l 完善变更流程引入需求管理流程，明确变更和需求流程的关系流程互通发布管理流程引入发布管理流程明确变更和发布流程的关系流程互通日常维护管理流程引入日常维护管理引入集团公告、两级协作管理流程互通安全管理流程引入账号权限管理流程互通6. 事件管理流程6.1 流程目的事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括： n 在成本允许的范围内尽快恢复IT服务 快速响应服务请求（电话/WEB/邮件等） 用户在线获得帮助 沟通事件解决的状态 和客户确认事件的解决n 进行事件控制 按规范记录事件 就事件的优先级，影响度进行分类 分析，诊断，必要时进行升级 监视并结束事件 进行定期服务流程回顾n 提供IT管理信息 人力资源利用情况 故障处理情况 支持效率6.2 流程主要内容事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：n 事件检测和记录 这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。该环节的关键是信息的准确性和完整性。n 分类和初步支持对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。n 调查和诊断 若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。n 解决和恢复支持人员实施事件的解决方案，并将解决完毕的事件转回帮助台，由帮助台通知用户解决的结果，并得到用户的确认。n 优先级为紧急的事件（紧急事件）和事件升级对于紧急事件，帮助台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。n 结束事件当用户确认事件解决后，此时可结束该事件。6.3 与其他流程的关系n 和问题管理流程的关系事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后作为问题进行进一步的分析和处理。n 和配置管理流程的关系需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。n 和变更管理流程的关系帮助台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。n 和知识管理的关系事件得到解决后，解决的过程中所获得的经验以及相关解决方案可以进入知识库，作为知识保存，为后续的工作提供指导。6.4 流程范围事件管理范围包括与BOSS系统、BASS、P-BOSS和BOMC系统相关的所有IT生产环境所产生的申告、故障、告警、咨询和客户投诉。不包括：n 尚处于开发或测试环境的系统和应用引发的事件6.5 流程执行原则6.5.1 常规原则n 所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件n 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别n 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估n 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程6.5.2 所有权原则所有权原则用来确保每个事件在任何时段都有适当的人员负责，帮助台是事件的负责人。下表是事件管理中各角色在各环节中承担不同责任的RACI模型。帮助台人员(值班/投诉受理)事件经理(职能经理)一、 二线支持(员工)三线支持(厂商)检测和记录(detection and recording)AIR分类和支持(classification & initial support)ACR分析和诊断(investigation and diagnosis)RAR解决和恢复(resolution and recovery)RC/IAR事件关闭(Incident closure)AIR监控和沟通(ownership, monitoring, tracking & communication)AR/C/IIIRACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会6.5.3 再分派原则事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组，由组内的支持人员处理。事件单的重分派次数不应该超过5次。n 帮助台可以将事件单分配给一、二线支持n 一、二线支持可以将事件单重新分配给帮助台、其他一、二线支持人员和厂商人员n 现场厂商人员直接使用系统记录处理情况，没有条件使用系统的厂商，由一、二线支持代为记录6.5.4 重复事件原则重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。n 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台n 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标n 如果帮助台可以判断到重复事件，则由帮助台对重复事件标识，否则由一、二线支持人员负责重复事件的处理6.5.5 关闭原则由IT用户申报的事件单，关闭必须由帮助台完成。n 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。帮助台负责和IT用户再次确认事件的解决 由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理n 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单n 一、二线人员自行创建的事件单，本着“谁开单，谁负责关闭”的原则n 监控平台自动发送的事件单，第一次接收的维护人员负责关闭6.5.6 升级原则制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。n 优先级为紧急的事件，帮助台应立即派发到一、二线支持，由其再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层，由事件经理启动紧急事件处理流程n 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，帮助台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理n 帮助台应及时将不能解决的事件升级，若未及时升级，事件经理应及时介入，负责协调升级处理6.6 流程相关定义6.6.1 事件信息项事件单必须包含如下事件信息项，各省可以在此基础上扩充。表6-1 事件信息项序号信息项说明1事件ID事件单流水号（系统自动产生）2请求人信息事件申报人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）3登记时间在帮助台生成事件记录的时间（系统自动产生）4地点事件发生的地点 （手工填写）5事件发生时间针对故障：指的是业务中断的实际时间 （可能早于登记时间，需要手工填写）针对其它：缺省值等于登记时间6业务恢复时间针对故障的业务恢复实际时间（手工填写）7事件性质参见“事件性质”定义8事件来源参见“事件来源”定义9事件影响度参见“事件影响度”定义10事件优先级参见“事件优先级”定义11事件完成期限对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 （系统自动产生）12所属系统类型参见“所属系统类型”定义13事件分类参见“事件分类”定义14事件标题事件的简要描述（手工填写）15事件描述对于整个事件内容的详细描述（手工填写）16事件解决人事件的最终解决人（手工填写）17事件状态参见“事件状态”定义18分配对象被分配的技术支持组和人员（手工填写）19事件日志反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信息（系统自动产生）20解决方案事件解决方案的描述（手工填写）21融合计费中断时长造成融合计费业务计划外中断的时间长度(分钟，手工填写)22综合帐务中断时长造成综合帐务业务计划外中断的时间长度(分钟，手工填写)23客户服务中断时长造成客户服务业务计划外中断的时间长度(分钟，手工填写)24事件结束代码参见“事件结束代码”定义25重复事件标记标记为重复事件（手工填写）25处理是否超时参见“处理是否超时”定义（系统自动产生）26事件解决人角色参见“事件解决人角色”定义27实际开始时间记录事件状态到XX处理中的时间（系统自动产生）28实际完成时间记录事件已解决的时间（系统自动产生）29故障厂商参见资源管理分册厂商和集成商名称标准（手工填写）30关联配置项记录出现故障的配置项代码（手工填写）31关联的问题单号记录由事件引发问题时，关联的问题单号（手工填写）32关联的变更单号记录由事件引发变更时，关联的变更单号（手工填写）6.6.2 事件性质事件性质定义为如下五类事件：编号代码描述1客户投诉与业务支撑系统相关的用户投诉，如10086、营业厅等面向客户的业务受理部门转来的因支撑系统问题引发的客户投诉2系统故障指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障监控管理平台上报的影响系统正常使用的告警3业务可用性告警业务服务管理平台上报的用户体验和业务影响告警4平台告警监控平台自动产生的没有影响到系统正常使用的告警5服务咨询指对系统操作、业务流程等方面的求助和询问6.6.3 事件来源事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：编号代码描述1用户报告用户或地市维护人员通过电话/邮件/传真报告的事件，帮助台人员手工创建事件单2自助开单地市等IT用户通过帮助台自助系统直接提交的事件3自动转单通过CRM自动转发的事件4内部开单省公司业务支撑部门内部提交的事件5监控告警监控工具自动转发过来的事件6.6.4 所属系统类型定义业务系统。当事件发生时，应该由帮助台初步定位是哪个系统及子类出现问题，由一、二线进行进一步的明确。注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为“其他系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用“其他系统”表示。 业务系统子类BOSS系统产品管理服务开通综合采集融合控制融合计费综合帐务综合结算合作伙伴管理基础功能统计报表一级BOSS局数据管理与发布信息管理采集预处理其他CRM市场营销销售管理渠道管理客户服务客户管理资源管理产品管理系统管理其他P-BOSSBASSBOMC其他系统集团-直采业务系统6.6.5 事件分类事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。在制作统计报表时，可以通过和所属系统类型代码的结合来统计分析故障或申告。事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为“子类”，第三级分类，称之为“条目”。注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。类别子类条目系统硬件 小型机PC服务器路由器网络交换机磁盘阵列存储光纤交换机磁带库安全设备系统软件操作系统数据库中间件集群软件备份软件系统管理软件安全软件应用软件进程数据参数代码接口客服设备排队机CTI服务器CCSIVR服务器配套设施UPS空调其他6.6.6 事件优先级优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。编号优先级代码描述1紧急l BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省或至少包括一个关键地市l CRM的电话呼叫中心业务不可用，影响面为全省或至少包括一个关键地市l 因系统原因数据处理错误，导致大量用户投诉l 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告l 部分重要数据丢失，且无法全部恢复2高l BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为一个或多个非关键地市l BOSS系统中综合采集、融合计费、产品管理、资源管理、一级BOSS、营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表任一业务不可用，影响面为全省或至少包括一个关键地市l CRM的电话呼叫中心业务不可用，影响面为一个或多个非关键地市l CRM中互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析任一业务不可用，影响面为全省或至少包括一个关键地市l 经分系统的通用分析不可用，影响面为全省l BOMC系统的服务管理或监控管理不可用，影响面为全省l 用户在营业现场反应激烈l 监控管理平台严重告警3中l 一般性系统故障l 监控管理平台主要告警4低l 一般单个用户申告l 业务咨询l 监控管理平台一般告警当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的影响范围和用户报障描述来确定。系统 影响范围全省至少包括一个关键地市全省多个非关键地市一个非关键地市BOSS（任意一个模块）客户服务、客户管理、服务开通、综合帐务、订单管理紧急紧急高高综合采集、融合计费、产品管理、资源管理、一级BOSS高高营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表高高CRM（任意一个模块）电话呼叫中心紧急紧急高高互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析高高BASS通用分析高专题分析BOMC服务管理、监控管理高注：n 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加n 优先级映射表中空的字段，各省在细化流程中自行定义6.6.7 事件响应时限和解决时限在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制。一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念；也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理；如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果帮助台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间；解决时限指的是事件状态从“已登记”到“已解决”经过的时间；事件优先级对应的事件响应时限和解决时限参考下表（以下时间是247工作时间）：编号优先级代码响应时限要求解决时限要求1紧急30分钟4小时2高1小时8小时3中4小时48小时4低8小时96小时注：各省根据自己的业务需要可以修改优先级对应的响应时限和解决时限，但应该小于这个范围，并且定义的时候应该考虑事件影响度的定义。 6.6.8 事件影响度事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。定义事件影响度等级的因素有：n 是否影响了核心业务n 所影响的用户数n 服务失效的影响范围和时长事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。编号影响度代码事件性质描述1重大故障l 全省半数以上地市或关键地市的融合计费业务中断超过6小时l 全省半数以上地市或关键地市的营业、综合帐务、客服中任一业务中断超过3小时l 全省半数以上地市或关键地市的综合结算业务处理中断超过24小时l 半数以下地市全业务中断超过6小时申告l 对移动公司造成巨大损失产生严重后果和不良影响的l 来自新闻媒体、消费者协会、国家行政机关的反映或申告2严重故障l 全省半数以上地市或关键地市的融合计费业务中断大于10分钟、小于6小时l 全省半数以上地市或关键地市的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时l 全省半数以上地市或关键地市的综合结算业务处理中断大于2小时、小于24小时l 半数以下地市全业务中断大于10分钟、小于6小时申告l 局数据错误导致产生大量的错单l 涉及到高额问题的申告l 用户在营业现场反映激烈3一般故障l 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障申告l 不属于重大申告和严重申告的用户申述告警l 不影响系统的监控平台告警4无咨询 l 一般数据查询或者使用指导注：各省根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。6.6.9 事件状态事件状态代码表明事件所处的处理状态，事件状态如下：编号代码描述1已登记新开事件记录或事件已创建2分配到帮助台事件已分配给帮助台人员3分配到一线事件已分配到一线支持，一线还未响应4分配到二线事件已分配到二线支持，二线还未响应5分配到三线事件已分配到三线支持，三线还未响应6一线处理中一线支持人员已接手处理事件7二线处理中二线支持人员已接手处理事件8三线处理中三线支持人员（厂商）已接手处理事件9已解决事件已解决，支持人员联系用户验证事件是否获得解决10关闭事件已关闭6.6.10 事件结束代码事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：编号代码描述1成功解决事件获得成功解决2变通方法解决事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析3不成功事件没有获得解决（用户没有认可解决时使用）4消失事件自行消失5误报不属于业务支撑部门管理范围的事件6可忽略如通过其他系统接口或监控系统提交的垃圾信息，经确认属于无效信息6.6.11 事件解决人角色事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。编号代码描述1帮助台帮助台最终解决事件2一线一线支持最终解决事件3二线二线支持最终解决事件4三线三线支持最终解决事件6.6.12 处理是否超时每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。编号代码描述1未超时未超时2超时事件已超出规定的解决时限6.6.13 故障厂商用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的“应用软件”故障)。代码定义参见资源管理分册厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。6.7 流程概要设计事件管理概要设计流程图：图6-1事件管理概要流程事件管理概要设计流程说明：序号步骤名称责任人说明100.1事件记录和分类帮助台l 帮助台对来自用户和系统自动产生的事件进行详细记录，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求l 帮助台负责在接收到事件后进行分类转发，对申告/告警/咨询/故障类事件进行分类转发l 对于初步判断为紧急的事件马上升级到一/二线人员处理l 对于非业务支撑维护职责范围的事件转给其它相关