1、集团公司IT服务管理规范及日常运维流程手册编 制： 审 核： 批 准： 版 本 号: ESZAQDGF001 编 制： 审 核： 批 准： 版 本 号: 目 录IT服务管理流程分册11文档说明111.1编制说明111.2适用范围111.3规范文档111.4起草单位111.5解释权111.6版权112建立IT服务管理流程体系的必要性123IT服务管理流程框架143.1IT服务管理流程框架的整体思路14流程框架设计指导思想14流程框架整体设计思路143.2基本概念16IT服务和IT服务管理16IT客户和IT用户17IT服务战略资产17其他相关人183.3集团的IT服务目录18系统服务目录19专业技2、术服务目录203.4IT服务管理核心流程分析22服务保障类流程221.电话接听与服务请求过程分析232. 事件处理过程分析243. 系统优化过程分析24需求分析和项目建设类流程分析26日常运维类流程30IT服务管理流程框架概念视图323.5IT服务管理流程框架0级视图333.6IT服务管理流程框架1级视图341级视图341级视图说明341级流程负责人角色说明383.7IT服务管理流程框架2级视图393.8流程图设计规范39原则39流程图的图例说明404本次规范发布流程说明414.1流程主要关系说明411.由IT用户事件触发的流程之间关系412.由IT客户业务需求触发的流程之间关系423.IT日3、常运维管理与其它流程的关系：日常运维发现事件，启动事件管理流程。发布管理新增IT服务，启动日常运维管理，增加相应IT服务的作业计划。424.2电信一点收费需求实现场景说明42业务及功能描述42需求实现场景描述445服务台475.1定义475.2目标和范围475.3服务台类型475.4集团的IT服务台类型485.5服务台主要职能495.6与服务流程的关系505.7关键衡量指标506服务请求管理流程526.1流程定义526.2流程目标526.3流程执行原则52一般原则52升级原则53审批原则53关闭原则536.4与其它流程的关系546.5流程说明55服务请求556.6关键控制点586.7主要相关数4、据说明59服务请求信息项59用户请求提交渠道59请求类别60请求状态60请求结束代码616.8关键衡量指标616.9角色及职责说明627接入管理流程637.1流程定义637.2流程目标637.3流程执行原则63一般原则63权限分配原则64审批原则64关闭原则64稽核原则657.4与其它流程的关系657.5流程说明66接入变更流程66权限稽核流程697.6关键控制点717.7主要相关数据说明72接入变更申请单72请求来源72申请单状态73结束代码73权限稽核单74稽核结果74稽核单状态747.8关键衡量指标757.9角色及职责说明75服务台75技术和应用管理人员76接入经理76归口部门审批人765、8事件管理流程768.1流程定义768.2流程目标778.3流程执行原则77一般原则77事件处理/升级原则78重复事件原则78事件关闭原则798.4与其它流程的关系798.5流程说明80事件管理80紧急事件管理868.6关键控制点898.7主要相关数据说明90事件信息项90事件来源92用户事件提交渠道93所属系统类型94事件分类96事件优先级99事件响应时限和解决时限100事件影响度101事件状态103事件结束代码1048.8关键衡量指标1058.9角色及职责说明106事件经理106服务台人员106二线支持人员107三线支持人员1079问题管理流程1079.1流程定义1079.2流程目标1086、9.3流程执行原则108一般原则108创建原则108重复问题原则108问题关闭与回顾原则1099.3.5与其他流程的关系1099.4流程说明110一级流程110二级流程1129.5关键控制点1149.6主要相关数据说明115问题信息项115问题来源117问题优先级118问题状态119所属系统类型120问题分类122问题结束代码1259.7关键衡量指标1269.8角色及职责说明12710知识管理流程12810.1流程定义12810.2流程目标12810.3流程执行原则128知识创建原则128知识库维护12810.4与其它流程的关系12910.5流程说明130二级流程13010.6关键控制点1327、10.7主要相关数据说明13410.8关键流程衡量指标13510.9角色及职责说明13611需求管理流程13711.1流程定义13711.2流程目标13711.3流程执行原则137一般原则137评审原则13811.4与其它流程的关系13811.5流程说明140一级流程140二级流程143流程泳道图14411.6关键控制点14811.7主要相关数据说明149需求申请单149需求处理状态150优先级150需求分类150需求来源151需求结束代码151需求重要程度15111.8流程相关指标15111.9角色及职责说明152需求提出人152需求归口管理人152需求联系人152需求分析人员153需求经理8、15312变更管理流程15312.1流程定义15312.2流程目标15412.3流程执行原则154一般原则154变更分类执行原则155变更审批原则155变更通知原则155紧急变更处理原则155变更测试原则156变更文档控制原则15612.4与其它流程的关系15712.5流程说明158一级流程158二级流程160泳道图16212.6关键管控点17012.7主要相关数据说明171变更信息项171变更来源172变更分类172所属系统类型173变更重要等级173变更状态173变更是否中断业务174回顾代码174变更结束代码174变更实施单信息项17412.8流程相关指标17512.9角色及职责说明179、6变更请求人176变更经理176变更主管177变更执行人177变更管理委员会178紧急变更管理委员会17813发布与部署管理流程17913.1流程定义17913.2流程目标17913.3流程执行原则180流程一般原则180发布优先原则180发布通知原则180DSL管理控制原则180发布上线审批拒绝原则181发布上线审批升级原则1811发布时间窗口原则181发布执行原则18113.4与其它流程的关系18213.5流程说明183一级流程183二级流程18513.6关键控制点19013.7主要相关数据说明191发布信息191发布来源192发布类型192是否常规发布192发布是否中断业务192是否需要10、用户测试193测试结果193发布状态193发布结束代码19313.8流程相关指标19413.9角色及职责说明194发布请求人194发布执行人195发布经理195IT部门领导196省公司领导196集团相关负责人19614测试管理流程19714.1流程定义19714.2流程目标19714.3流程执行原则197一般原则197设计原则197测试执行原则198测试关闭原则19814.4与其它流程的关系19814.5流程说明199流程说明199一级流程199二级流程20114.6关键控制点20414.7主要相关数据说明204测试申请单信息项204测试用例信息项205所属系统20614.8流程相关指标20711、14.9角色及职责说明207测试申请人207测试执行人208测试主管208测试环境管理员208测试经理20815资产与配置管理流程20815.1流程定义20815.2流程外部关系图20915.3流程目标20915.4流程执行原则210常规原则21015.4.2控制原则210稽核原则21115.5与其它流程的关系21115.6流程说明212一级流程212流程主要活动212流程输出213二级流程214流程泳道图21415.7关键控制点21515.8主要相关数据说明21615.9关键衡量指标22315.10角色及职责说明223配置经理224配置管理员22416日常运维管理流程22416.1作业计划管12、理流程224流程定义224流程目标225流程执行原则225与其他流程关系226流程说明226关键控制点228主要相关数据说明229关键流程衡量指标230作业计划分类说明230角色及职责说明23316.2值班管理流程234值班定义234流程目标234流程执行原则234流程说明235关键控制点236主要相关数据说明237角色及职责说明23816.3机房出入管理238流程定义238流程目标239流程执行原则239流程说明240关键控制点244主要相关数据说明244流程相关指标245角色及职责说明24516.4生产指挥调度管理流程246流程定义246流程目标246流程执行原则247与其它流程的关系2413、8流程说明249主要相关数据说明251流程相关指标253角色及职责说明25317IT服务管理流程实施指导25617.1项目启动和管理层认可25717.2建立流程场景25717.3将角色和职责映射到工作25717.4明确流程活动环节的交互界面25817.5人员岗位调整25817.6流程实施培训25817.7流程验证和测试25917.8细化流程的输入和输出25917.9流程配置与实现25917.10流程割接上线运行25917.11考核监控25917.12项目后评估2601 文档说明1.1 编制说明本规范是集团规范的重要组成部分，定义了集团IT服务管理流程体系框架，阐述了IT服务的基本概念，提出了参14、考的IT服务目录框架，描述了IT服务台职能以及事件管理等11个重要流程的定义、目标、执行原则、流程图、主要活动说明等内容，作为集团各省实施上述流程的规范要求。1.2 适用范围本规范适用于集团公司及下属省（市、区）分公司IT服务管理流程的梳理及建设，并为相关IT服务管理流程固化实施提供指导。1.3 规范文档本册规范独立成册，无其他附件。1.4 起草单位本规范起草单位为集团公司。1.5 解释权本规范的解释权属于集团公司。1.6 版权本规范的版权属于集团公司。2 建立IT服务管理流程体系的必要性随着全业务竞争的全面展开，运营商间的竞争日趋激烈，为有效增强集团综合竞争能力，需要尽快提升集团企业信息化的15、整体能力，实现更好的客户服务、更好的IT业务需求支撑、更有效的全网内部协同、更好的IT运营维护质量、更低的IT运营成本，更精确的IT管理，实现IT工作符合规范、质量可控、可衡量及并能够持续优化提升。目前，集团还没有建立IT服务管理相适应的流程制度，IT运营管理规范性及流程化程度不高，需要参照国际最佳实践（ITIL）建立与ITSP2.0相适应的IT服务管理体系，进一步规范将IT运营和管理工作，提高流程化协同能力及执行效率，提高运营维护工作质量：n 引入ITIL服务管理流程，建立集团统一的IT运维模式。目前，集团各省IT服务管理的水平、工作模式存在较大差异，不利于从全局衡量全国IT服务管理水平，不16、利于先进省经验的共享和推广，一定程度阻碍了集团IT整体服务管理水平的提高。引入基于ITIL的IT服务管理流程，有利于各省IT服务模式规范统一，有利于国际最佳实践和各省先进经验的系统固化，实现集团范围内的IT服务的一体化管理。n 引入ITIL服务管理流程，建立健全各省公司流程化的IT服务管理流程。目前部分省IT服务管理工作流程不清晰，缺少部分关键流程，已有过程执行不规范，效率难以科学衡量，质量及结果难以有效控制。引入基于ITIL的服务管理体系可以帮助各省公司参照国际最佳实践逐步健全、规范的运维管理流程，提高IT运营工作质量，降低运营风险。n 引入ITIL服务管理流程，提升集团的IT服务管理水平。17、目前集团缺少统一的IT服务管理质量衡量体系，难以有效评估各省的IT服务管理质量，不利于对整体IT服务管理工作进行优化。通过规范化的服务流程定义，参照ITIL最佳实践设定流程、活动、组织的衡量指标，可以对IT服务工作质量及效率进行有效的预测和控制，帮助集团建立可衡量、可评价、可持续优化的IT服务管理体系。n 引入ITIL服务管理流程，提高各省内部及省与集团之间的协同能力。目前各省公司内部及省与集团之间的协作方式以传真文件、电话、电子邮件为主，沟通工作量大，效率低，过程跟踪困难，关键信息不可跟踪。通过建立IT服务管理流程体系，借助IT服务管理技术平台支持，可将各省内部及省与集团之间的常用工作交互规18、范化、模式化，通过明确具体的沟通方式、交互信息及衡量指标，并实现系统支撑固化，实现协同的流程化、自动化，实现业务过程的有效跟踪和分析，从而提高协同工作的能力。n 引入ITIL服务管理流程，提高业务部门对IT支撑工作的感知。集团目前的IT运维还是以传统的面向技术的工作模式为主，没有实现服务化，通过参考ITIL最佳实践，梳理IT服务目录，针对不同的服务设定不同的服务水平协议，逐步规范业务部门与IT部门的服务关系，缓解业务需求与IT支撑之间的矛盾，通过服务级别管理来明确对服务质量的期望并对服务质量进行衡量。3 IT服务管理流程框架集团的IT服务管理框架将从集团的实际情况出发，结合ITIL V3.0的19、最佳实践，建立集团IT服务管理的整体框架和流程体系。本章将论述建立流程框架的整体思路，明确基本概念，对集团目前的IT服务管理相关活动进行分析，在此基础上给出流程框架的0级，1级和2级视图。本规范2级视图作为集团各省公司实施具体IT服务管理流程的参考。3.1 IT服务管理流程框架的整体思路3.1.1 流程框架设计指导思想集团IT服务管理流程框架设计的指导思想是将ITIL最佳实践与集团实际相结合，建立客户可感知，面向IT服务的流程体系。具体内容包括：n 参照ITIL V3梳理基本概念，统一立对IT服务、IT服务管理的理解；n 给出面向IT客户和用户提供的具体服务目录框架；n 参考企业实际IT运维工20、作流程，明确IT服务管理工作的范围和主要流程活动；n 参考ITIL最佳实践，对当前工作流程的范围、分类、具体内容进行修订和完善，建立集团IT服务管理流程框架。l 对目前已经比较成熟的流程，重点从有利于提升效率和集中管控方面完善。l 对目前比较薄弱的工作，以ITIL V3为基础，建立基本的工作流程，为将来进一步完善IT服务管理流程体系奠定基础。3.1.2 流程框架整体设计思路IT服务管理流程框架的建立是在对目标和驱动力的分析基础上，结合集团IT运维的实际情况和ITIL V3.0的建议，通过基本概念的建立，服务目录的梳理，现状流程的分析，建立整体流程框架，并细化到2级流程。整体思路如下图所示：图表21、 01 建立IT服务管理流程框架的整体思路(一) 工作思路及方法1. 对集团IT服务管理整体目标和业务驱动力的深刻理解是IT服务管理流程框架的建立的基础。2. 在对目标和驱动力深入分析、理解的基础上，结合集团IT运维的实际情况，参照ITIL V3.0最佳实践，梳理基本的概念，明确集团IT服务及IT服务管理的定义，明确集团IT服务的服务对象（IT客户和用户）。3. 以客户可感知的服务为出发点，梳理集团IT服务目录的分类及参考IT服务定义，明确集团当前IT服务的服务内涵。4. 以集团当前IT运维实际情况为基础，分析为IT客户和用户提供服务的过程，以及为保障整体服务质量而进行的日常运行维护活动。结合22、ITIL V3.0最佳实践的建议，对当前运维活动进行分析和分解，明确目标流程框架中要关注的要点。5. 在现状流程分析的基础上，建立集团IT服务管理流程框架的概念视图。结合ITIL V3对服务生命周期的管理，建立集团IT服务管理流程框架0级视图。根据ITIL V3.0的建议对当前IT运维工作进行梳理和规范细化，形成1级和2级视图。6. 对目标流程进行设计，在1级视图上明确每个流程的目标和范围、流程执行原则、流程/活动的描述、角色和职责、主要KPI、相关数据等。目标流程可以在以下方面对省公司进行指导：n 流程定义、目标和范围：帮助理解流程的内涵和边界。n 流程的执行原则：流程执行时的主要管控点。各23、省实施时可以对流程执行原则进行细化，但同时应保持管控点的完整性。n 高阶流程图：包括一级和二级流程图以及对二级流程图进行角色细分的泳道流程图。在高阶流程层面反映出流程中的主要活动。帮助理解流程主要阶段及主要活动，并对主要活动进行细化。n 关键控制点：对流程落地时应遵循的重要原则和保留的管控点清单。n 关键衡量指标：流程的关键KPI描述，为流程实施及建立相应考核体系提供参考。n 流程相关数据：定义流程执行时应输入、处理、输出的关键数据信息及业务定义，是流程执行过程需要保留的信息，为服务管理平台及业务流程配置，提供具体指导及依据。n 流程中角色、职责说明：描述流程相关的主要角色及职责，帮助省公司在24、流程落地时角色设计，以及实现和相关岗位的映射。3.2 基本概念在建立IT服务管理流程框架前，首先需明确集团IT服务管理的范围是什么，服务的对象是谁，客户和用户有哪些。在此基础上明确IT部门为IT客户和用户提供了哪些具体服务。对IT服务及服务对象（IT客户/用户）的理解是建立面向客户的服务流程体系的基础和前提。3.2.1 IT服务和IT服务管理集团的IT服务是集团企业信息化部为其客户创造价值的体现。包括系统服务及专业技术服务两大类。n 系统服务：是指MBOSS类系统提供的业务受理、服务开通激活、服务保障、计费账务、数据统计及报表生成等系统功能类或性能类服务。对此类服务，IT部门主要是通过日常运维25、系统监控及事件处理等，保障相关服务达到与业务部门签订的服务水平目标（如系统可用性等）。n 专业技术服务：是指企业信息化部人员提供的如资费套餐开发配置、计费结算处理、IT故障和投诉处理、现场服务等技术服务。此类服务，一般是由客户/用户主动发起请求，IT部根据相关标准、流程及规范，组织协调人员完成服务请求，满足所设定的服务水平。n 集团的IT服务管理：是以支撑企业战略转型为目标，以客户和业务为中心，借助技术手段，通过流程化的管理方法实现IT管控体系与技术体系的有机结合，以可衡量的方式高效率完成IT服务相关的规划、设计、建设与交付、运营与支持及持续改进等过程。3.2.2 IT客户和IT用户根据IT26、IL 有关定义，IT客户是为IT服务付费（或虚拟）的组织或个人，IT用户是使用IT服务的个人。目前，集团IT部服务的主要对象是管理层及内部业务部门（目前IT部不直接对外服务），这里我们给出了集团的服务对象相关定义。集团的IT服务对象包括IT客户和IT用户。1.IT客户：集团企业内部管理层、各个业务部门、以及由IT部直接提供IT服务的企业外部客户都是IT客户。2.IT用户：使用集团企业信息化部门提供的IT服务的组织和个人（包括企业外部和内部用户）都是IT用户。3.2.3 IT服务战略资产企业的战略资产是对企业具有战略价值的，可以为企业持续带来价值的资产。集团企业信息化部用于为IT客户和用户提供I27、T服务，并对IT服务进行持续有效的管理，保证持续提升集团整体价值的资产就是集团IT服务管理的战略资产。IT服务战略资产的内容包括IT基础设施，应用系统，组织人员，流程，信息数据等。3.2.4 其他相关人在集团IT服务管理流程框架中，除了提供IT服务管理的主体(企业信息化部)，IT客户和用户外，还有其他相关人。这些相关人包括企业的外部环境和提供IT服务的供应商等。企业外部环境包括相关的政策法规，企业市场环境，资本市场等会对集团IT服务管理体系的发展演变产生重大影响的要素。在建立IT服务管理体系的过程中，必须要充分考虑外部环境对企业整体战略的影响，切实保障IT服务管理的目标与企业战略目标相一致。供28、应商是IT服务管理体系中的重要因素。一方面供应商是实现IT服务的必要环节，另一方面有效的使用和管理供应商，可以保证将企业有效的资源聚焦于最能体现核心价值的业务上，保持企业具备持续的竞争力。3.3 集团的IT服务目录IT服务管理的实现是以服务的方式为IT客户和用户提供价值。因此，明确IT部门为客户和用户提供了哪些服务是建立面向客户的IT服务管理流程框架的基础。IT服务目录是对企业信息化部为客户和用户提供的所有服务及服务规格的有效组织形式。通过IT服务目录，客户和用户可以直观感受到企业信息化部的服务内容。在本规范中，描述了集团IT服务目录的整体分类体系，各省公司可根据整体分类体系制定符合自身实际情29、况的IT服务目录。根据集团IT服务的说明，集团IT服务目录从整体上分为两类：n IT系统服务：是指MBOSS类系统提供的业务受理、服务开通激活、服务保障、计费账务、数据统计及报表生成等系统功能类或性能类服务。n 专业技术服务：是指企业信息化部人员提供的如资费套餐开发配置、计费结算处理、IT故障和投诉处理、现场服务等需技术人员提供的服务。由于IT服务的定义与各省实际情况关系较为紧密，且IT服务的引入需要进一步探索，因此本次规范服务目录仅给出了服务名称，未给出具体的服务定义及水平协议。3.3.1 系统服务目录系统服务描述了由MBOSS类系统提供的IT客户/用户可感知的服务（如充值服务、缴费服务），30、以及用于支撑面向客户的服务所需要的面向技术的服务（如IVR自动语音、计费充值接口、信控复机等）。系统服务目录的关系如下图所示：图表 02 IT系统服务目录系统服务目录的颗粒度可以按照管理的水平及客户的感受进行细化。如IT服务管理初期，可以以单个IT系统为单位定义系统服务，如CRM,、计费等。随着IT服务管理的推进，可以将服务逐步拆解为更细粒度的服务（如计费系统拆分到计费处理、账务处理、信用控制等）。一个用户可感知的服务可能跨越多个应用系统，由多个面向技术的服务共同完成，不同的服务可能对应于不同的保障级别。图表 03 面向用户的系统服务和技术服务示意图下表是集团IT系统服务目录（面向用户）的一个31、参考示例。IT系统服务目录服务名称（L-1）（L-2）业务受理套餐业务受理固网业务受理移动业务受理宽带业务受理开通服务固网语音开通宽带开通移动业务开通增值业务开通计费结算服务计费服务出帐服务账单/发票提供服务结算处理服务欠费控制服务运营商结算报表服务SP结算数据报表服务充值缴费服务缴费服务充值服务查询服务详单查询账单查询余额查询短信提醒短信催缴余额提醒经营分析常规报表专题分析数据推送Email服务EMAIL服务企业管理服务财务报销表格 01 IT系统服务目录示例3.3.2 专业技术服务目录专业技术服务目录包括通过统一的服务界面，IT客户/用户可以感受到的企业信息化部人员提供的服务。专业技术服务32、目录包括了企业信息化部日常和客户/用户的交互活动及活动的规格（特性）。其中有些是对IT系统运营的保障和支持，例如参数配置、异常数据处理等，有些是纯粹的支持服务，例如业务咨询，数据提供等。专业技术服务的分类参考如下表：专业技术服务服务名称(L-1)(L-2)(L-3)事件处理事件处理电信客户IT投诉处理服务请求履行权限管理信息咨询IT系统使用咨询现场支持现场保障用户现场培训服务补丁提供和安装备品备件更换安全检查临时报表提供数据提取专题分析异常数据处理调帐处理异常话单处理IT系统内资料修正数据割接服务测试配合测试配合类计费验证测试政企客户整体方案设计服务 软件开发新系统开发新系统开发维护性开发新产33、品、新业务支撑类开发应用功能优化调整新业务平台、新网元接入类开发接口开发报表开发其他新功能开发参数配置服务产品、资费配置资费新增/修改销售品（套餐）新增/修改产品新增/修改计费参数配置结算类规则新增/修改计费局数据配置计费采集规则配置统计规则配置列收规则配置统计分析规则配置运营流程配置企业管理流程配置运营流程配置网络调整配合网络激活协议配置类告警规则配置服务网络资源配置服务表格 02 IT专业技术服务分类目录3.4 IT服务管理核心流程分析集团公司企业信息化部和各省公司企业信息化部目前已经为各个业务部门提供了大量的技术支持服务。部分省公司已经建立了相对完善的服务保障体系。在本规范中，首先要充分34、分析和吸收目前先进省份已经建立的IT服务管理流程；然后在ITIL的建议下对IT服务管理流程进行优化和完善；对于目前IT服务管理体系中相对薄弱的环节，将以ITIL的建议为主，建立基本的工作模式，做为将来完善IT服务管理的实践。本节将对集团IT服务管理实际生产环境中的服务保障类流程、需求分析和项目建设类流程、日常运维类流程进行分析，充分吸收其中的成功经验，并总结流程体系设计的要点。3.4.1 服务保障类流程3.4.1.1 流程描述服务保障类流程是企业信息化部对客户/用户申告的IT系统故障的处理过程。下图是对这一过程的描述：图表 04 服务保障类流程3.4.1.2 流程分析1.电话接听与服务请求过程35、分析输入：n IT客户/用户遇到IT方面的问题，通过电话进行事件申告。输出：n 如果是IT系统出现性能大幅下降、部分功能不可用等，启动事件处理过程。n 如果是分配权限的申请，则启动为用户权限分配过程。n 如果是服务请求，则进入服务请求流程。n 如果IT客户申告的事件涉及到IT系统的变动和调整，则告知用户走需求管理流程。分析：n 在对客户提供事件申告，权限分配或服务请求时，要采用统一的服务界面。对所有请求进行记录和分类管理。n 对于大多数客户的请求，不一定是系统的故障，更多的是由于对业务的不了解而提出的问题，即便是关于系统方面的问题，大多数问题也是比较基本的问题。n 电话接听人员是对所有请求提供36、服务的一线人员，需要具备良好的沟通技能和较广的业务知识。n 提高一线人员解决问题的效率可以大大提高后端IT服务管理流程的效率。n 对于比较专业的技术支持，可以考虑设置专人专席的方式。例如专门针对CRM或者计费系统的一线支持人员。n 在IT服务管理体系中，这部分活动可以映射到服务台。对应的IT服务管理流程包括事件管理、接入管理、服务请求管理等。2. 事件处理过程分析输入n IT客户/用户通过电话申告的事件。n 监控系统发现的事件。n 10000号转来的IT事件。n IT人员在日常运维中发现的事件。输出n 事件处理完成时关闭。有些事件在恢复IT服务以后，还会进行根本原因的分析，并实施解决方案。n 37、发现是重大事件故障，触发重大事件故障处理过程。分析：n 将事件处理的过程按照ITIL的建议进行分解。n 将恢复服务能力的过程定义为事件管理。目的是快速回复业务。n 将根原因分析，并确定解决方案的过程定义为问题管理，目的是防止事件再次发生。n 在恢复业务的过程中要增加技术升级和管理升级的管控，确保事件在约定的响应时间内解决。n 针对重大事件故障的上报和处理，要制定特定的处理流程。3. 系统优化过程分析输入：n 由IT人员定期启动。n 根据事件的影响和紧急程度启动。处理：n 通过分析前一段事件统计报表，分析造成事件的问题，分析根原因，采取改进措施，从而消除或减少事件的再次发生。输出：n 找出的问题38、得到解决，或者标识为已知错误，或者无法找到问题根原因。分析：n 对问题的处理过程没有很强的时间要求。n 问题的处理过程需要各个专业的领域专家深入参与。n 在IT服务管理体系中系统优化可以映射问题管理流程。n 问题的解决过程如果涉及到对IT环境的调整，需要在变更管理的控制下进行。3.4.1.3 与ITIL流程的映射图表 05服务保障类流程及其与ITSM映射关系3.4.2 需求分析和项目建设类流程分析3.4.2.1 流程描述需求分析和项目建设类流程是关于IT系统建设，维护性开发相关的过程的管理。这类流程的整体过程如下图所示：图表 06需求分析和项目建设类流程3.4.2.2 流程分析1. 需求分析和39、确认流程分析输入：n 需求来自于客户。n 需求也可能来自于日常运行维护过程发现系统的不足（扩容、改造需求）。扩容需求如：发现空间不够，需要扩硬盘；发现cpu利用率太高，扩cpu或主机。处理：n 对需求进行分类、排序、分析，审批和确认。输出：n 确定将来要实现的需求。n 对需求的描述要具体到可以估算可行性、工作量、所需使用的技术手段等。流程分析n 需求的优先顺序是按照紧急程度，和用户协定的不同实现时限要求。n 需求的归并和优化要在需求分析过程中完成。n 需求通过维护性开发或工程项目建设实现。2. 滚动规划流程分析输入：n 每年由集团公司定期发起。在规划调研阶段进行需求收集。输出：n 正式通过的规40、划，作为工程项目建设的输入。分析：n 在IT服务管理体系中，IT服务规划是年度IT滚动规划的输入。3. 工程项目建设流程输入：n 来自滚动规划需要进行立项的项目。n 规划外的项目，需要先进行预算申请。处理：n 软、硬件新建和扩容使用投资性成本，需要经过可研，立项和招投标的过程。n 测试、发布（版本发布、项目上线）需要进一步的管控子流程。输出：n 系统终验做为的终结点。流程分析：n 在可研阶段要考虑新增软、硬件在容量、可用性、灾备和信息安全方面的要求，同时要考虑对当前IT环境容量、可用性、灾备和信息安全方面的影响。n 在方案设计时，要考虑对IT配置环境的影响，在版本发布后，要保证对IT环境的配置41、变化在配置管理系统中及时更新。n 招投标选定供应商后，应该对供应商和合同信息进行记录，并建立和相关IT配置项的关联关系。n 在版本发布后，要进行运维的交接处理，保证对新建系统的维护工作纳入日常运维的体系。n 工程建设项目的管控是IT服务管理体系中典型的变更管理过程。4. 维护性开发流程分析输入：n 通过需求管理形成的需求确认单，其类型为维护性需求。n 事件和问题管理过程发现的软件bug。处理：n 维护性开发是以维护性成本为支出的软件修改和维护的活动。n 其中测试流程是日常维护的一个独立活动。n 版本发布是需要进一步管控的一个子流程。输出：n 修改完成正式发布上线作为流程的终结。流程分析：n 在42、方案设计时，要考虑对IT配置环境的影响，在版本发布后，要保证对IT环境的配置变化在配置管理系统中及时更新。n 维护性开发过程是IT服务管理体系中一个典型的变更管理过程。5. 硬件更换流程分析输入：n 在故障处理和根本原因分析过程，发现硬件设备问题，需要更换硬件时启动。输出：n 硬件更换，安装完成。流程分析：n 硬件更换流程也是一个典型的变更管理过程。n 硬件更换正式上线后要保证配置管理系统中正确记录了配置变更信息。6. 测试流程分析输入：n 软件开发完成后需要进行最终功能性和非功能性测试。n 日常维护过程中需要对服务的功能和能力进行测试。输出：n 测试报告。流程分析：n 软件开发过程中的单元测43、试，集成测试不在本流程中。n 测试流程作为IT服务管理体系的中一个独立流程，既可用于日常运维过程中对服务或系统的测试，也可用于软硬件系统正式发布前的测试。7. 版本发布流程分析输入：n 在测试过程已经通过测试的应用软件。输出：n 系统正式上线使用。流程分析：n 版本发布流程主要用于新开发软件或维护性开发过程中的部署上线过程管理。n 在进行变更管理过程中，如果涉及到影响范围较大的软件、硬件的部署上线，将按照ITIL的建议定义为发布与部署管理流程。现有的版本发布流程将并入集团IT服务管理体系中的发布与部署管理流程。在发布与部署管理流程中需将对发布包进行测试。8. IT财务管理流程分析输入：n 滚动44、规划正式稿。输出：n 批准的预算。流程分析：n 在集团IT服务管理体系中，IT预算管理是IT服务战略规划中的内容。n 如果MSS类的系统中有完善的预算管理，IT预算管理可以完全参考MSS中的管控要求。3.4.2.3 与ITIL流程的映射图表 07需求分析和项目建设类流程及其与ITSM映射关系3.4.3 日常运维类流程3.4.3.1 流程描述日常运维类流程描述了以作业计划的形式体现的周期性的维护工作。维护工作的结果可能会触发不同类型的支持流程。这类活动的管理过程如下图：图表 08日常运维类流程3.4.3.2 流程分析1. 作业计划分类可以根据作业计划支持的后续流程，对作业计划的具体工作进行以下分45、类：故障发现、配置核查与发现、性能检查、可用性保障、灾备演练、安全检查和供应商日常管理。2. 制定作业计划流程分析输入：n 作业计划申请表单。输出：n 有效的作业计划任务。分析：n 在新建系统，或者系统进行调整后，会产生新的作业计划。n 作业计划的内容会涉及IT服务管理的方方面面。n 作业计划的内容要和相关IT服务的保障要求相一致。n 在IT服务管理体系中，日常运维管理流程包括作业计划制定的流程。3. 执行作业计划流程分析输入：n 根据制定的作业计划，定时触发生成作业计划单。输出：n 作业计划执行完成后，记录作业执行执行结果。分析：n 在IT服务管理体系中，日常运维管理流程包括作业计划执行的流46、程。3.4.3.3 与ITIL流程的映射图表 09日常运维类流程及其与ITSM映射关系3.4.4 IT服务管理流程框架概念视图通过对IT服务管理核心流程的分析，可以建立集团IT服务管理流程框架的0级、一级、二级概念视图。3.5 IT服务管理流程框架0级视图图表 010IT服务管理流程0级视图流程域流程域说明服务台服务台是IT部的一个具体职能部门，是IT用户与企业信息化部的单一联系点，是集团内部的10000号，内部用户可以通过电话、邮件、即时通信工具等多种方式与服务台联系，获得支持、解决其问题或实现请求。用户也可以通过Web方式自助提交用户事件。服务运维服务运维域是保障IT运营过程中，及时响应客47、户的IT服务请求，及时处理IT故障，并对故障的根原因进行分析和解决，使IT服务保持在达成共识的水平上的相关管理活动。服务运维域包括服务请求管理、接入管理、事件管理、问题管理等流程。服务设计服务设计域是在IT服务战略的指导下，对IT客户提出的各类IT需求进行管理，设计满足IT战略和客户需求的IT服务，评估客户需求对整体IT环境的影响，并通过日常的管理活动保障IT整体环境满足服务级别的要求和IT环境整体设计的要求。服务设计域包括需求管理、服务目录管理、服务级别管理、服务可用性管理、服务容量管理、服务连续性管理、信息安全管理和供应商管理等流程。服务交付服务交付域是将需要交付的业务需求通过严格的控制过48、程，转移到真正的生产环境中，最终产生客户所需要的服务，并对IT生产环境中被管理资源信息的准确性和完整性进行控制。服务交付域包括变更管理，资产与配置管理，知识管理，发布与部署管理和测试管理流程。服务战略服务战略域是对集团IT服务管理体系的发展进行整体规划，对IT服务体系进行持续改进优化，对IT服务工作进行成本定量化的管理活动。服务战略域包含了IT服务规划、财务管理和IT服务持续改进三个流程。表格 03 流程域说明3.6 IT服务管理流程框架1级视图3.6.1 1级视图图表 011 IT服务管理流程框架1级视图3.6.2 1级视图说明0级流程1级流程1级流程定义服务运维服务请求管理服务请求管理是对49、来自IT用户的低风险、低成本的例行请求进行处理的流程。如：信息咨询、建议、非系统类投诉、重置密码、桌面服务请求等等。接入管理接入管理是对IT用户访问企业信息化部管辖范围内的IT基础设施或业务系统的访问权限进行申请、审批、分配、回收和定期稽核的管理流程。通过管理用户的访问权限，保证只有经过授权的用户才可以访问IT系统或服务。IT用户在申请IT服务接入权限时，应事先得到相关业务部门批准。人员变动经常会触发接入管理流程，实现访问权限变动申请、审批、授予的过程。事件管理事件管理流程是对IT生产环境中导致IT服务中断或潜在中断的事件进行管理，快速恢复IT服务能力的管理流程。它的目的是尽快恢复被中断或受到50、影响的IT服务，是以恢复服务为首要目的，可能采取临时解决方案，而不在于查找根本原因。事件的来源包括IT用户报告的事件、监控系统自动转发的事件、10000号系统自动转发的电信客户IT类事件等。问题管理问题管理流程是确定某一故障或具有相同症状的一组故障的根本原因，制定和实施解决方案，从而防止故障再次发生的管理流程。问题管理流程的目的是找出故障的根本原因，尽可能的给出解决方案或者临时应对措施。日常运维管理日常运维管理包括作业计划管理、机房出入管理、值班管理、生产指挥调度管理等流程。作业计划管理是对IT人员的日常维护作业进行制定、审核、执行、记录的管理流程。值班管理是对IT人员的日常值班工作进行安排、51、执行、记录的管理流程。机房出入管理是对出入机房人员的权限进行控制审查，并记录一切出入机房的管理流程。生产指挥调度管理流程立足于为集团、省、市公司三级企业信息化部生产、指挥及调度服务，实现对生产任务单、公文以及重点专题的执行跟踪和反馈。服务设计需求管理需求管理流程是对IT客户提出并经过需求归口部门审批通过的需求进行记录、分析、审批、跟踪、变更控制，对需求实施结果进行评估的管理流程。通过需求管理，保证业务需求清晰、可行，从而可以及时、准确地响应和支撑，并确保从需求提出到最终实现全过程是可跟踪、可追溯。需求的实现过程是通过变更管理流程进行控制的。服务目录管理服务目录管理流程是对所有即将投入使用和当前52、正在使用的服务进行生命周期状态、服务属性和关系进行管理和维护的流程。对服务的管理活动包括服务的新增和注销，以及通过变更管理流程的控制对使用中的服务属性和关系的维护。服务目录管理流程所管理的服务都存放于服务目录。服务目录包括服务的分类信息，属性和关系等信息。服务级别管理服务级别管理流程是对将要提供的服务定义服务级别，为当前正在使用的服务与IT客户建立服务级别协议，并通过监控，分析，协商和改进等方式保证IT服务的可用性和保障性满足服务级别协议中的要求。可用性管理可用性管理流程是根据需求和服务战略来设计和评估服务的可用性，并对IT环境中影响可用性的风险和正在使用的服务的可用性指标进行分析和评估，执行53、校正和预防性维护措施，保证IT服务的可用性满足设计要求。容量管理容量管理流程是基于企业业务目标对IT环境的整体容量进行规划设计，对支持当前IT服务的应用系统，IT基础架构的性能及负载情况，提供IT服务的组织能力进行监控与报告，并对IT资源的使用进行控制和优化。服务连续性管理服务连续性管理流程是管理在重大故障及灾难发生的情况下，将风险对业务的影响降低到可接受的水平，确保企业信息化部能为IT客户提供约定的最低级别服务。供应商管理供应商管理流程是帮助企业信息化部选择提供IT服务的合格供应商，根据业务需要和供应商签订IT服务合同，并对合同的内容和执行情况进行跟踪和评估的管理流程。供应商管理流程要确保与54、供应商签订的合同满足业务的需要，并且供应商对合同的执行达到其承诺的水平。信息安全管理信息安全管理流程是基于集团的企业安全管理框架，对安全事件和风险进行识别和处理的流程。信息安全管理流程遵循ISO2007的要求，主要内容集中的安全事件的收集和分析，对产生的安全风险进行处理。服务交付变更管理变更管理负责业务需求单、系统变更单的具体实施落实，包括变更方案、进度计划的制定，变更的审批、变更的实施准备（工程采购、软件开发等）、实施方案制定及审批、软件版本管理、验证测试等工作，工程类及维护类变更通过发布与部署管理完成变更到实际生产环境部署。通过对系统变更的控制，降低变更带来的风险，提高系统稳定性。 典型的55、变更如新功能开发、软件版本升级、硬件扩容、应用系统重要配置数据的修改等。非生产状态的IT环境的变更不在变更管理的范围。一个业务需求可能对应多个系统的变更。资产与配置管理资产与配置管理流程是对所有配置项及关联关系的识别、发现、更新、监控和稽核的管理流程。配置项包括应用软件、系统软件、IT基础设施、IT服务、文档等。配置管理流程中管理的配置项，如果还没有进入生产状态，其状态，属性及关系信息由配置管理流程维护，如果配置项进入生产状态，则需要在变更管理流程的控制下对配置项的状态，属性和关系信息进行维护。发布与部署管理发布与部署管理负责将通过测试验证后的变更按业务需要及技术要求、发布策略限制分批部署到生56、产环境，这些变更包括工程类及维护类变更，它包括发布计划制定、发布包构建、发布包测试、上线审批、发布执行、发布关闭等环节。通过发布管理，确保对生产环境的变更得到有效控制，提高生产环境稳定性，对IT服务影响最小。测试管理测试管理流程是对应用系统、IT基础设施进行的功能性和非功能性测试的管理流程，它包括测试请求记录与确认、测试计划制定、测试用例编写、测试准备、测试执行、测试回顾与关闭等管理流程。测试管理流程的目的是为了验证被测试产品是否符合预期目标。知识管理知识管理流程是对IT服务管理过程中产生的各类知识和经验进行收集、分类、审批、保存、回顾和共享的管理流程。经过知识管理流程所产生的知识要能够被企业57、内部相关使用人员安全，便捷，可靠的访问。服务战略IT财务管理IT财务管理流程是通过建立IT服务成本模型，对IT服务投资进行预算，实现IT财务预算及费用支出情况跟踪的管理流程。企业信息化部门依据IT 服务规划，制定年度IT 投资预算和成本预测。IT服务规划IT服务规划是指 如何将服务管理转化为战略资产;如何理清所管理的各种服务、系统和流程与所支持的业务模型、战略和目标之间的关系。IT服务规划是IT滚动规划的一个输入。服务持续改进IT服务持续改进流程是基于IT服务管理的战略目标，对IT服务管理的现状进行评估，测量，分析差距，确定改进方案，并对改进方案进行评估和实施的管理流程。IT服务持续改进流程遵58、循PDCA持续改进的质量控制原则。表格 04 1级流程定义说明3.6.3 1级流程负责人角色说明每个一级流程应设置流程负责人角色。流程负责人从宏观上监控流程，确保流程在IT部门范围内被正确的执行。当流程不能够适应IT部门的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现流程的持续改进。职责：q 确定流程的衡量指标。q 确保能够取得管理层的参与和支持。q 确保流程符合公司实际状况和公司 IT发展战略。q 总体上管理和监控流程，建立流程实施、评估和持续优化机制。q 确保流程有效、正确地执行，当流程不能够适应公司的情况时，必须及时进行分析、找出缺陷、进行改进，从而实现流程的持续59、改进。q 保持与其他流程负责人的定期沟通。3.7 IT服务管理流程框架2级视图图表 012 IT服务管理流程框架2级视图3.8 流程图设计规范为便于后续章节会对每个流程进行定义，设计流程图，本节对流程图的图例以及画法进行规范。3.8.1 原则1. 针对每个流程设计一级流程图、二级流程图和二级流程泳道图。流程图类型说明如下：1) 一级流程图主要对流程进行概要设计。2) 二级流程图对一级流程图中的每个活动进行细化，是对流程的详细设计。它的目的是尽可能发现所有的活动。3) 二级流程泳道图在二级流程图的基础上，加入活动与角色的对应关系，从中可以得出流程运行所需的角色和相应职责。2. 流程由活动构成，活60、动也可以演变为子流程。因此在命名过程中对流程和活动不进行区分，在流程图中以不同图标表示有更详细活动的子流程和没有更详细活动的活动。3. 流程图要反映出输入和输出，活动流转的过程，每个活动对应的负责人/执行人，关键的数据。4. 所有流程图使用预先定义好的图标和Visio模板。5. IT服务管理体系中描述的各类管理活动有些具有比较明显的流程性，有些活动是功能性的。在此不做严格的区分，在文档中对流程性较强的活动以流程图的方式描述，对功能性较强的活动以说明和要求的方式描述。 3.8.2 流程图的图例说明图表 013 描述流程用的主要图标4 本次规范发布流程说明IT服务管理涉及ITIL领域共21个流程和61、服务台职能，根据集团IT服务管理当前实际需要，本次规范重点定义其中11个常用流程和服务台职能：1. 由IT用户事件触发的：主要包括事件管理、问题管理、知识管理3个核心流程，服务请求管理、接入管理2个常用流程，以及服务台职能要求。2. 由IT客户业务需求触发的：包括需求管理、变更管理、测试管理、资产与配置管理、发布与部署管理等5个核心流程。3. IT日常运维管理：日常运维作为一个1级流程，主要包括值班管理、作业计划管理、机房出入管理、生产指挥调度管理等。其他流程将根据需要制定及下发。4.1 流程主要关系说明本次规范发布的主要流程及其之间的主要关系如下图：图表 014本次发布的流程之间的关系1. 62、由IT用户事件触发的流程之间关系1) 来自用户的不同类型事件启动不同处理流程：如果是对用户权限的变更请求，则启动接入管理流程进行处理。如果是引起IT服务中断或潜在中断的事件（如系统故障或性能问题），则启动事件管理流程进行处理。如果是信息咨询、现场支持、密码重置等服务请求，则启动服务请求管理流程进行处理。2) 事件管理与问题管理的关系：如事件处理只是采取了临时解决方案，未找到根本原因，则启动问题管理流程，查找事件的根原因，实施改进措施。2. 由IT客户业务需求触发的流程之间关系1) 需求管理与变更管理的关系：需求管理侧重于业务部门所提需求的可行性分析、工作量及工期估算及审批管理，同意接收的需求交63、由变更管理具体实现。需求单所对应变更全部实施完成后，关闭需求单。业务需求可以根据大的阶段拆分为子需求，但不需要拆分成针对单个系统的需求单。2) 变更管理与发布的关系：变更管理负责审批通过后的业务需求的具体实现。变更准备就绪后提交发布审批，发布与部署管理流程根据发布策略、变更特性及关联关系，按发布包分批将变更部署到实际生产环境。除紧急变更和标准变更外，其他变更均需要通过发布管理部署到生产环境。一个业务需求单必要时可以拆分为以系统为单位的多个变更单。3) 独立的测试管理流程：测试管理作为一个独立流程存在。测试管理从变更、发布等流程接收测试需求，制定具体测试计划和方案，完成测试并反馈测试报告及结论。64、4) 资产与配置管理与其它流程关系：资产与配置管理为其它流程提供配置数据的支持，变更管理和发布管理会调用资产与配置管理更新配置信息。3. IT日常运维管理与其它流程的关系：日常运维发现事件，启动事件管理流程。发布管理新增IT服务，启动日常运维管理，增加相应IT服务的作业计划。4.2 电信一点收费需求实现场景说明4.2.1 业务及功能描述电信一点收费即电信IVPN集团代付业务，指的是集团客户为个人使用的电信业务中的全部或部分费用进行代付。例如这个月手机话费是452元，你的报销标准是300元，那么公司给你付300元，你个人还需要支付152元，这个就是一种集团代付的典型业务场景。由集团公司下发集团综65、合VPN业务规范文件要求各省公司需要实现一点收费的业务功能。主要实现以下功能：1. 支持集团客户为各个成员用户支付某一额度费用（月限额），月限额内的费用由集团客户支付，超出月限额的费用由个人支付。2. 支持对集团客户在平台上设置的封锁号码的话单及费用进行处理，拨打封锁号码产生的费用只能计入个人账户，不能由集团代付，如168语音电话等。3. CRM系统需提供月限额和账目类型组的录入界面。4. 支持集团CRM接口到省CRM接口/省CRM接口到省计费接口的相关资料传递。5. 支持集团客户付费部分的账单和清单上传，并且本地不再保留应收数据。为实现一点收费业务需要涉及到总部CRM、总部计费、省CRM、省66、计费的修改。一点收费的总体流程如下图：图表 015 一点收费的流程示意图4.2.2 需求实现场景描述从一点收费业务需求提出到实现的整个过程，涉及需求管理、变更管理、发布与部署管理、测试管理四个流程。这个场景可以说明需求管理、变更管理、测试管理以及发布与部署管理四个流程之间的关系。图表 016 一点收费场景的流程关系图需求管理省公司市场部门根据集团集团综合VPN业务规范文件要求，提出“一点收费”需求，并通过归口部门审核人审核，确认需求合理后提交省公司IT部门需求联系人。省公司IT部门需求联系人对该需求单进行初步分析，认为需求涉及到本省计费系统、本省CRM系统的修改，将需求分配给相应的需求分析人员67、进行分析，编写需求规格说明书，并完成工作量概算评估。由于该需求由集团下发，场景假设集团到各省接口的改造已经实现，下面将不再描述。经需求分析并汇总后，得出需要对相关系统和接口进行如下改造： 1. 省CRM前台应用系统改造2. 省计费后台批价程序改造3. 省计费与省CRM客户资料接口改造4. 省CRM与省计费客户资料接口改造由计费、CRM相应需求分析人员进行分析，初步编写IT支撑方案，并与需求提出人确定需求的上线时间，提交到IT部需求经理进行审批。需求经理审批通过启动变更管理流程，此时该需求单尚未关闭，直到变更管理流程执行完毕，通知需求管理流程关闭该需求单。变更管理变更主管根据变更涉及的内容，将需68、求拆分为四张变更单分别为：CRM前台改造变更单、CRM与计费客户资料接口变更单、计费系统后台批价变更单、计费与CRM客户资料接口变更单。四张变更单相互关联，并同时与此需求单关联。每张变更单启动一个变更流程进行控制，变更主管针对每张变更单制定变更计划（包括上线时间），编写解决方案。一点收费需求对应的四个变更申请单属于典型的维护类变更，且风险较高，对现有的计费系统以及CRM系统将产生较大影响。因此需上报由相关系统领导以及技术专家等人员组成变更管理委员会进行审批。变更管理委员会审批通过后，分别由计费和CRM系统软件开发厂家人员进行软件开发，并启动测试管理进行开发阶段测试。变更主管接收到软件开发厂家测69、试通过的测试报告后，发起发布申请。发布与部署管理CRM发布执行人将CRM前台改造变更单、CRM与计费接口变更单的发布申请合并在一个发布单进行发布，这个发布单还可以包含其它CRM系统变更单。变更主管制定发布计划，确定上线时间。计费发布执行人将计费系统后台批价变更单和计费与CRM接口变更单的发布申请合并在一个发布单进行发布，这个发布单还可以包含其它计费系统变更单。变更主管制定发布计划，确定上线时间。到了发布时间窗口，CRM和计费发布执行人根据发布清单从DSL中获取发布包组件分别构建发布包，同时核对发布包间的关联先后顺序关系，如一点收费需求发布上线：CRM和计费发布执行人需确认两边发布需同时上线，确70、认无误后将发布包形成本次发布版本并在DSL中保存，然后分别启动测试管理。测试管理反馈测试报告，测试通过后上报发布经理审批上线。审批通过后由CRM与计费发布执行人分别把发布包部署到对应的生产环境中去。发布执行人对生产环境进行生产环境测试验证。如果发布不成功，则执行回退操作，将CRM与计费发布一起回退。发布成功后，发布关闭，更新发布公告，并将发布结果通知到变更管理，四张变更单关闭，变更关闭时通知到需求管理关闭需求单，流程结束。测试管理测试管理会被变更管理、发布与部署管理调用。变更测试主要针对单个变更以及单个变更关联变更的联调测试。发布测试主要是针对发布包级的测试，一个发布包一般包含多个变更，需要一71、起测试。针对发布上线前的测试，需要将CRM和计费两个发布包一起发布到测试环境中，一点收费测试用例主要测试内容为：n 省CRM前台应用系统录入集团客户封锁号码信息。n 省CRM受理业务时录入月限额信息及相关支付信息。n 省CRM将月限额信息及相关支付信息发送给省计费系统。n 省计费系统在进行计费处理时需要判断封锁标记，若为封锁情况（集团封锁号码呼叫、成员封锁号码呼叫、集团封锁或个人封锁），该话单的费用必须由个人帐户付费。n 省计费系统在进行帐务处理时需要判断月限额及相关支付信息，超出月限额部分由个人帐户付费，小于或等于月限额部分由单位帐户付费。n 集团付费部分账单和清单上传总部计费系统。当整个测72、试流程关闭时，由测试主管提交测试报告，反馈发布结果。5 服务台5.1 定义服务台是IT部的一个具体职能部门，是IT用户与企业信息化部的单一联系点，是集团内部的10000号。内部用户可以通过电话、邮件、即时通信工具等多种方式与服务台联系，获得支持，解决其问题或实现请求。用户也可以通过Web方式自助进行服务请求或IT事件申告。5.2 目标和范围为内部IT用户服务请求和事件申告提供统一的入口，方便用户使用。确保用户事件申告和服务请求能够准确的记录和跟踪，保证来自IT用户的事件申告和服务请求能够到达IT部门，并在处理过程与用户保持密切的沟通，提升用户服务感知。来自IT用户的服务请求包括服务请求（如换网73、线、密码重置、信息咨询、投诉与建议）、接入请求和需求申请等。来自IT用户的事件包括MSS、EDA、BSS、OSS、桌面终端等方面的事件。5.3 服务台类型根据服务台的职能可以分为以下几种：n 记录型服务台 记录呼叫请求及用户事件，能够进行事件分类，并通过标准化的术语进行描述。根据事件分类，将事件单转发给相应的支持人员。 服务台代表用户对事件或服务请求执行状态进行监控和管理。n 技能型服务台 服务台人员能够记录用户事件，能够进行事件分类，并通过标准化的术语进行描述。借助知识库的支持，能够解决普通请求和事件。 服务台人员还包括部分熟悉独立系统的一线维护人员，能够对本专业的用户事件和请求进行专业的支74、持。 如接听电话的人员不熟悉用户所报告事件的领域，则可以通过电话转接方式交由其他服务台人员继续处理，也可以先行进行事件或请求记录，再由相关服务台人员进行处理。 服务台人员可以根据服务请求所属的业务系统以及处理服务请求所需的技能来进行分组，通过自动语音功能直接引导用户到所需的专门服务台人员。 服务台无法处理的事件，应转发给相关的支持小组。技能型服务台首次呼叫解决率通常要远远高于记录型服务台。n 专家型服务台 该服务台具备基础设施和应用软件的专家知识，能够独立解决大部分用户事件及服务请求。 该服务台无法解决的事件仍应转发给相关的后端支持小组。5.4 集团的IT服务台类型根据集团现状，考虑服务请求响75、应的及时性以及保证专业技术人员能够专注于解决专业技术问题，建议设立技能型的服务台。大量简单的服务请求能够在服务台解决，如信息咨询类的服务请求。服务台充当一线支持的角色，无法处理的服务请求转发到二线专业技术人员解决。鉴于目前各省公司普遍采用本地网和省公司两级IT支撑模式，可以考虑设立两级联动的服务台，两级服务台的职责如下：n 本地网服务台为本地网各业务部门提供服务，解决来自业务部门的服务请求和事件，在本地网服务台无法解决时，向省级服务台反映，由省级服务台支持。n 省级服务台为本地网服务台和省公司各业务部门提供服务，响应本地网服务台不能处理的，以及省公司各业务部门提出的服务请求和事件。5.5 服务76、台主要职能n 响应服务请求 事件及服务请求记录o 支持用户通过登录自助服务web网站，提交服务请求、查询知识库。o 支持通过IVR方式自动对标准信息咨询类进行自动应答。o 所有的服务请求及用户事件都应该准确记录，以便进行进度监控和为流程控制提供有关的量化指标。 事件分类、排序及处理o 为服务请求、事件申告、接入请求提供初始支持。o 对于用户权限申请、变更类的请求，通过启动接入管理流程进行处理。o 对用户申告的事件进行分类、确定优先级，并启动事件管理流程进行处理。o 对用户的信息咨询、投诉建议、密码重置、更换网线等服务请求，通过服务请求管理流程进行处理。 事件监控及用户联络o 对无法在规定时间内77、解决的服务请求或事件，及时进行升级处理。o 及时通知用户关于服务请求、事件的状态和进展情况。o 在服务请求或事件处理完成时，对用户进行回访，关闭事件。n 发布信息 服务台负责对用户进行信息发布。 对于当前或预期发生的错误，通过各种渠道通知用户。 服务台向用户提供有关最新和现有的服务项目，服务级别协议（SLA），以及订购程序和成本等方面的信息。n 供应商联络 服务台应拥有相关IT系统维护供应商的联系渠道，并保持联系。5.6 与服务流程的关系服务台从事许多与ITIL基本流程相关的活动。n 服务请求管理流程来自于IT用户的服务请求都由服务台记录，并启动所对应的服务请求管理流程，进行初始处理，对处理过78、程进行监控，并在处理完成时通知IT用户。n 接入管理流程如果服务台判断服务请求属于接入类的请求，则启动接入管理流程。并对接入请求进行初始处理，对处理过程进行监控，在处理完成时通知IT用户。n 事件管理流程如果服务台判断服务请求属于事件类的请求，则启动事件管理流程。提供事件的一线支持，对事件处理全过程进行监控，并在处理完成时通知IT用户。n 资产与配置管理流程服务台在进行事件记录时，可通过查询IT资源数据库获得相关的配置项信息，为事件分类、优先级划分提供支持信息。n 知识管理流程 服务台通过知识库获得最直接的专家帮助，从而可方便、快捷的处理服务请求和事件，提高IT服务效率和质量。5.7 关键衡量79、指标1. 服务台处理的呼叫数目，以及整个服务台的该项指标2. 服务台无升级呼叫数量3. 超出SLA协议要求的呼叫数量4. 升级到2线支持的呼叫数量5. 用户平均等待时长6. 用户放弃的呼叫请求的数目7. 每呼叫平均持续时间6 服务请求管理流程6.1 流程定义服务请求流程是对来自IT用户的低风险、低成本的例行请求进行处理的流程，包括服务请求记录、审批、执行、关闭等环节。服务请求如：信息咨询、建议、非系统类投诉、重置密码、桌面服务请求等等。6.2 流程目标服务请求管理的目标如下：n 确保在成本允许范围内，在预先得到批准和确认的情况下，为IT用户和客户提供的一个请求和接受标准服务的渠道，快速实现来自80、IT用户和客户的服务请求。 多渠道快速响应服务请求（电话/Web/邮件/即时通信工具等）。 为用户提供及时的服务请求处理情况。 监控服务请求处理过程，必要时进行管理升级。n 确保服务请求处理过程中的关键信息能正确记录，为流程持续优化提供准确的数据信息。 准确记录服务请求信息及执行过程信息。 提供服务台及后台技术资源利用情况报表。 提供服务台、技术支持团队的工作效率报表。6.3 流程执行原则6.3.1 一般原则n 所有IT服务请求进服务管理系统：所有IT用户报告的服务请求都应该在IT服务管理系统进行准确的记录，确保所有用户的服务请求处理过程都能够进行端到端的监控，从而提高用户满意度。n 不断固化81、服务请求模型：应根据不同的服务请求类型，固化服务请求流程模型。流程模型中应包括处理的环节/步骤、每环节的负责人员、表单的预定义字段等。流程模型的不断建立、丰富和修正是流程落实和持续改进的重要内容。n 应定期进行服务请求执行情况回顾：应该定期生成服务请求管理报表；应该定期回顾流程执行情况，回顾内容包括关键衡量指标、流程执行效率和流程支持工具的有效性，以改进服务请求管理流程。6.3.2 升级原则n 服务请求处理过程全程监控：应对服务请求处理全过程进行监控，如无法在规定的时限内解决，应及时进行管理升级和技术升级；管理升级后，服务请求经理负责协调资源，并督促服务请求能够及时被响应和处理。6.3.3 审82、批原则n 业务部门先行审批原则：来自业务部门的服务请求，应经过业务部门先行审批，才能进入技术审批环节。业务部门审批侧重考虑服务请求执行成本因素。IT部门审批侧重考虑技术风险和合规性。对于简单的、例行的服务请求可进行预授权，无需审批就可直接执行，从而加快服务请求实现的速度，减少审批的工作量。6.3.4 关闭原则n 服务台统一关闭：由IT用户申报的服务请求单，应由IT服务台统一完成关闭。n 闭环管理：服务请求关闭时，应由服务台人员对IT用户或客户进行回访，确认已经实现了服务请求，如果IT用户或客户反馈服务请求未实现，则由原服务请求执行人继续执行服务请求。如果回访工作量太大，可定义其中部分服务请求进83、行回访。n 已关闭服务请求单不重开：已关闭的服务请求单不允许重开。如果服务请求重复发生，则创建一个新的服务请求单。6.4 与其它流程的关系图表 017 服务请求流程与其他流程的关系n 事件管理流程：服务请求管理流程在处理服务请求时，如果确定请求涉及的内容是IT事件或者是可能会影响业务的任何IT异常，应启动事件管理流程来处理事件。事件管理流程在处理事件时，如果确定事件其实是服务请求，则启动服务请求管理流程来处理服务请求。n 资产与配置管理流程：服务请求流程可以从资产与配置管理流程中获取需要的信息来响应和处理用户请求。n 知识管理流程：服务请求执行人从知识库中获取知识，帮助执行服务请求。6.5 流84、程说明6.5.1 服务请求6.5.1.1 一级流程6.5.1.1.1 流程图图表 018 服务请求一级流程6.5.1.1.2 活动说明序号步骤名称责任人说明1服务请求记录服务台q 本环节是服务请求管理的初始环节，服务台人员对所有IT用户报告的服务请求进行准确、详细记录。2服务请求审批请求审批人、服务请求经理q 服务请求审批包括财务审批和技术审批。财务审批侧重考虑服务请求执行成本因素。技术审批侧重考虑技术风险和合规性。3服务请求执行服务台、二线、三线q 服务请求执行人实现经过审批或预授权的服务请求。并对请求执行的过程进行记录。4服务请求关闭服务台q 在服务请求实现或被拒绝后，进入关闭环节。q 服85、务台人员对用户进行回访，确认正确实现了服务请求。如果未实现服务请求，则重新执行。5服务请求监控及管理升级服务台q 服务台人员对服务请求处理全过程进行监控，如服务请求无法在规定时限内实现时，及时通知服务请求经理及相关领导。表格 05 服务请求流程活动说明6.5.1.2 二级流程6.5.1.2.1 流程图图表 019 服务请求二级流程6.5.1.2.2 泳道图图表 020 服务请求二级流程泳道图6.6 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设置服务请求流程负责人、服务请求经理、服务台、二线支持、三线支持等角色。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2I86、T用户能够通过电话、email、用户自助登记等多种方式提交服务请求。关键管控点3所有服务请求必须进IT服务管理系统。4服务请求在执行前须进行审批，审批包括归口部门的审批和IT部门的审批。已进行预授权的服务请求，可以不审批直接执行。5服务请求关闭时，须具有通知请求者的机制。6已关闭的服务请求单不允许重开，如果服务请求重复发生，则创建一个新的服务请求单。7服务台人员对请求处理全过程进行监控，请求处理超时时，必须有清晰的管理升级机制。8服务请求处理过程必须保存如下信息：服务请求ID、请求人信息、登记时间、请求类别、服务请求提交渠道、请求标题、请求描述、请求审批人、审批时间、审批意见、请求执行人、请求87、状态、请求结束代码、处理是否超时、实际完成时间。关键信息要求表格 06服务请求流程关键控制点6.7 主要相关数据说明6.7.1 服务请求信息项服务请求单包含如下信息项，各省公司可以在此基础上扩充：序号信息项说明1请求ID请求单流水号 2请求人信息请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机 3登记时间在服务台生成请求记录的时间 4地点请求发生的地点 5请求类别参见“请求类别”6服务请求提交渠道参见”用户请求提交渠道”定义。7请求标题请求的简要描述 8请求描述对于整个请求内容的详细描述 9请求审批人服务请求的审批人员10审批意见11审批时间服务请求的审批时间12请求执行人88、请求的最终处理人 13请求状态参见“请求状态”定义14分配对象被分配的处理请求的人员 15请求处理日志反映请求信息项的变化历史，如一个请求在处理过程中请求状态变化的时间点等信息 16请求结束代码参见“请求结束代码”定义17处理是否超时“是”，“否”18实际完成时间记录请求处理的时间 19关联的事件单号服务请求转事件管理，关联的事件单号 表格 07 服务请求信息项说明6.7.2 用户请求提交渠道用户请求提交渠道用来标明用户服务请求的渠道。编码代码描述10电话报告用户或地市维护人员通过电话提交的请求，服务台人员手工创建请求单。11Web自助用户通过Web页面，自助创建的请求单。12电子邮件用户或地89、市维护人员通过邮件报告的请求，服务台人员手工创建请求单。13即时通信用户或地市维护人员通过即时通信工具报告的请求，服务台人员手工创建请求单。表格 08 用户请求提交渠道说明6.7.3 请求类别服务请求类别代码表明服务请求的分类，服务请求类别如下：编码代码描述10信息咨询业务咨询泛指客户对IT服务相关的各种业务知识的咨询。11投诉建议投诉与建议是指客户对IT服务相关的各方面活动的意见和建议。99其它服务请求其它服务请求是已经明确定义流程，响应时间，预期结果的标准服务。表格 09 请求类别说明对于其它类的服务请求，各省公司在具体实施中，可以进一步细化。6.7.4 请求状态服务请求状态代码表明服务请90、求所处的处理状态，服务请求状态如下：编码代码描述10已登记服务请求已登记入系统。11等待审批服务请求提交给相关审批人，等待审批。12已批准服务请求得到批准。13处理中服务请求履行人在此状态下，进行履行请求。14已完成请求履行完成，进入观察期。15关闭请求关闭，关闭请求时需指定关闭代码（成功，失败，已取消）。表格 010 IT请求状态说明6.7.5 请求结束代码请求结束代码说明了服务请求是在何种情况下关闭的，结束代码如下：编码代码描述10成功请求成功完成。11失败请求不成功。12已取消请求因为各种原因被取消。表格 011 IT请求结束代码说明6.8 关键衡量指标流程的考核指标是为了判断服务请求流91、程的效率和有效性。这些考核指标包括：序号衡量指标指标说明1服务请求的总体数量统计一段时间内真正的服务请求总数，不包括事件误报成服务请求。2服务请求的执行次数和比率统计一段时间内通过审批并进入执行的服务请求总数及其占服务请求总数的比例。3不同提交渠道的服务请求数量及百分比统计服务请求中，来源于电话、web、邮件、即时通信工具等不同方式的服务请求数量及百分比。4服务台执行的服务请求数量及百分比统计一段时间内由服务台直接执行的，未派发到二线等后台支持的服务请求数量及百分比。5各类别服务请求平均执行时长统计一段时间内统计信息咨询、投诉建议、其它类的服务请求的平均执行时长。6执行超时升级的服务请求数量/92、百分比统计一段时间内整体执行时间超出相应类别的服务请求执行时限的服务请求数量及其占服务请求总数的比例。7规定时间内执行的服务请求数量/百分比整体执行时间未超出相应类别的服务请求执行时限的服务请求数量及其占服务请求总数的比例。8用户对服务请求执行的满意程度可以通过系统外调查完成表格 012 关键衡量指标说明6.9 角色及职责说明服务请求可以与事件管理流程共用相同的角色，包括服务请求经理、服务台、二线支持、三线支持等角色。n 服务请求经理可以由事件经理兼任，对整个流程负责，协调资源，保证服务请求的及时执行。n 服务台负责服务请求的受理、初始处理。n 二线支持和三线支持做为服务请求的执行人负责专业要93、求高的服务请求的执行。n 请求审批人通常由业务部门负责人和技术负责人分别承担。负责对执行服务需支付的成本进行审批。以及对请求的合规性、真实性进行审批。如果每天需要处理的服务请求数量很大，也可以单独委派一个或多个事件管理团队专职处理服务请求。7 接入管理流程7.1 流程定义接入管理是对IT用户访问企业信息化部管辖范围内的IT基础设施或业务系统的访问权限进行申请、审批、分配、回收和定期稽核的管理流程。通过管理用户的访问权限，保证只有经过授权的用户才可以访问IT系统或服务。IT用户在申请IT服务接入权限时，应事先得到相关归口部门批准。人员变动通常会触发接入管理流程，实现访问权限变动申请、审批、分配或94、回收的过程。7.2 流程目标接入管理的目标如下：n 允许授权用户可以使用服务。n 阻止非授权用户的访问。n 及时发现授权错误的情况。n 及时发现权限被滥用，并能为权限滥用提供证据。7.3 流程执行原则7.3.1 一般原则n 所有接入申请在IT服务管理系统进行记录：所有的IT用户接入请求都应该在IT服务管理系统进行准确的记录，确保所有用户的接入请求处理过程都留下痕迹，可以审计。n 应定期进行接入管理执行情况回顾：应该定期生成接入管理报表；应该定期回顾流程执行情况。回顾内容包括关键衡量指标、流程执行效率和流程支持工具的有效性，以改进接入管理流程。7.3.2 权限分配原则n 系统的操作系统管理员帐号95、仅限于经授权的系统管理员，其帐号须经系统维护部门主管人员的授权审批。n 系统数据库的管理员帐号仅限于经授权的数据库管理员，其帐号须经系统维护部门主管人员的授权审批。n 系统的特权用户（例如具有增加/变更/删除用户等权限的用户）仅限于经授权的系统管理人员或业务人员，其帐号须经系统维护或业务部门主管人员的授权审批。n 厂商不得拥有超级用户帐号。n 系统的管理员帐号（包括操作系统、数据库和应用程序层面）如果由于系统限制存在共享，其密码在其中任一管理员离职时需及时更改，以防止非法访问。7.3.3 审批原则n 归口部门先行审批原则：接入申请应经过归口部门先行审批，才能将申请提交到IT部门。审批侧重分析接96、入请求用户身份是否真实以及授权是否合乎规定。服务台人员应负责收集用户身份真实性以及授权合规性的证据。7.3.4 关闭原则n 接入申请单由服务台统一关闭：由IT用户申请的接入申请单，应由IT服务台统一完成关闭。n 闭环管理：接入申请关闭时，应由服务台人员对IT用户或客户进行回访，告知权限变更的执行情况，如果IT用户或客户反馈权限变更错误，则由原权限变更执行人继续进行权限变更。7.3.5 稽核原则n 定期进行稽核：接入管理流程必须定期对已分配的权限进行稽核，以保证权限被正确授予，及时发现权限被错误授予的情况，并发起接入变更进行更正。定期的稽核工作由IT部门、应用系统管理员发起，由相关IT用户归口部97、门的权限审批人进行权限稽核。7.4 与其它流程的关系图表 021 接入管理与其他流程的关系图n 变更管理流程：如果变更导致IT用户访问系统的权限发生变化时，则触发接入管理的权限变更流程，对IT用户的权限进行相应的修订。n 信息安全管理：信息安全管理是接入管理的主要驱动力。它提供安全和数据保护策略指导接入管理的执行。接入管理是落实信息安全管理的具体举措之一。7.5 流程说明7.5.1 接入变更流程当对IT用户或用户组访问IT服务的权限进行申请、变更、回收时启动，并完成审批和权限授予或收回的流程。7.5.1.1 一级流程7.5.1.1.1 流程图图表 022 接入变更一级流程7.5.1.1.2 活98、动说明序号步骤名称责任人说明1接入变更记录服务台8 服务台对IT用户或用户组的接入变更申请进行记录。2身份确认服务台9 服务台确认申请人身份是否合法。10 服务台确认申请人是否有权限使用相应的服务。11 身份验证可以通过提交归口部门领导审批的申请材料或者归口部门领导发送的电子邮件作为确认依据。12 如果是软件开发商人员等外部用户并且第一次申请，需签订保密协议。3接入审批接入经理13 接入经理接收经服务台人员确认后的接入变更申请。14 检查身份确认资料是否齐全。15 可以批准同意变更权限或拒绝申请。4权限授予应用、技术管理人员，服务台16 在相应的系统进行权限授予或回收。17 一般情况由相应系统99、的管理人员在相关系统进行操作，变更相应权限。18 部分简单的授权工作，也可以委托服务台完成。5申请关闭服务台19 接入申请处理完毕后需要转回服务台，由服务台将接入申请关闭。20 关闭请求之前，服务台需要确认接入申请是否按要求处理完毕，并和请求提交人确认处理结果。表格 013 接入变更流程活动说明20.1.1.1 二级流程20.1.1.1.1 流程图图表 023 接入变更二级流程20.1.1.1.2 泳道图图表 024 接入管理二级泳道图20.1.2 权限稽核流程通过定期发起权限稽核流程，对现有IT用户或用户组已分配权限进行稽核，发现权限分配错误的情况，并启动接入变更流程对错误进行更正。20.1100、.2.1 一级流程20.1.2.1.1 流程图图表 025 权限稽核一级流程20.1.2.1.2 活动说明序号步骤名称责任人说明1发起权限稽核技术、应用管理人员21 技术、应用管理人员定期发起权限稽核，分IT用户、用户组归口部门生成稽核单。2权限稽核归口部门权限审批人22 归口部门权限审批人接收到本部门的权限稽核单，逐个用户或用户组核实服务使用权限，标识出授权异常的用户以及权限。23 将完成的审核结果提交到权限稽核发起人。3稽核结果分析技术、应用管理人员24 技术、应用管理人员检查审核报告，如发现授权异常，则启动接入变更流程进行更正。4稽核关闭技术、应用管理人员25 技术、应用管理人员整理资料101、，生成稽核报告，关闭稽核流程。表格 014 权限流程活动说明25.1.1.1.1 流程输出n 稽核报告：包括权限稽核的用户数、授权错误的用户数等统计信息，以及权限稽核涉及的系统、用户、授权是否正确、授权错误描述等明细信息。25.1.1.2 二级流程25.1.1.2.1 流程图图表 026 权限稽核二级流程25.1.1.2.2 泳道图图表 027 权限稽核二级流程泳道图25.2 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设置接入流程负责人、接入经理、服务台、技术应用管理人员、归口部门权限审批人等角色。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2所有接入申请必102、须在IT服务管理系统进行记录。关键管控点3归口部门必须设置专门IT权限审批人，对接入申请进行先行审批。4服务台人员确认申请人身份合法性，申请权限的合规性。5接入请求关闭时，必须具有通知请求者的机制，由请求者确认请求被成功处理。6应用、技术管理员必须定期发起权限稽核工作，具体的稽核工作由归口部门权限审批人执行。7接入变更请求处理过程必须保存如下信息：接入变更申请ID、申请人信息、登记时间、请求来源、用户类型、用户ID、相关系统、变更原因、变更内容、身份确认依据、身份确认人、身份确认时间、审批人、审批时间、执行人、执行时间、结束代码、申请单状态。关键信息要求8权限稽核过程必须保存如下信息：权限稽核103、单ID、发起人、发起时间、系统名称、用户类型、用户ID、稽核人、稽核时间、稽核结果、稽核结果描述、相关接入变更单、稽核单状态。表格 015 关键控制点说明25.3 主要相关数据说明25.3.1 接入变更申请单接入变更申请单包含如下信息项，各省公司可以在此基础上扩充：序号信息项说明1接入变更申请ID接入变更申请流水号 2申请人信息请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机 3登记时间在服务台生成请求记录的时间 4请求来源参见”请求来源”定义。5用户类型描述权限变更的用户ID类型，用户或用户组。6用户ID申请权限变更的用户ID或用户组ID。7相关系统需进行用户权限变更的系104、统。8变更原因提出权限变更的原因。9变更内容权限变更的具体内容。10身份确认依据归口部门提交验证授权合规的证据，可以是邮件。11身份确认人12身份确认时间13审批人14审批时间15执行人16执行时间17结束代码参见“结束代码”定义18申请单状态参见“申请单状态”定义表格 016 接入变更单信息项说明25.3.2 请求来源接入变更请求来源编码如下：编码代码描述10来自人事部门人员变动原因发起权限变更。11来自变更管理流程变更管理流程新增或减少IT服务，启动权限变更。12来自部门管理者各业务部门管理者请求对下属员工权限进行变更。13来自权限稽核权限稽核过程发现授权错误，启动权限变更。表格 017 105、请求来源编码说明25.3.3 申请单状态申请单状态代码表明接入变更申请单所处的处理状态，申请单状态如下：编码代码描述10已登记接入变更已登记入系统。11等待身份确认等待服务台人员对申请人身份及授权合理性进行确认。12等待审批接入变更申请提交给相关审批人，等待审批。13已批准接入变更得到批准。14处理中授权人在此状态下，执行权限分配或收回工作。15已完成权限分配完成后，进入观察期。16关闭接入变更关闭，关闭时需指定关闭代码（成功，失败，已取消）。表格 018 申请单状态说明25.3.4 结束代码结束代码说明了接入变更审请是在何种情况下关闭的，结束代码如下：编码代码描述10成功接入变更成功完成。1106、1失败接入变更审批不通过。12已取消请求因为各种原因被取消。表格 019 接入变更结束代码说明25.3.5 权限稽核单序号信息项说明1权限稽核单ID权限稽核单ID。2发起人发起稽核的人员。3发起时间4系统名称要进行权限稽核的系统。5用户类型描述权限变更的用户ID类型，用户或用户组。6用户ID要进行权限稽核的用户ID。7稽核人执行稽核任务的人员。8稽核时间执行稽核任务的时间。9稽核结果参见“稽核结果”定义。10稽核结果描述稽核结果的详细描述。11相关接入变更单稽核发现授权异常，发起接入变更进行修正。12稽核单状态参见“稽核单状态”定义表格 020 权限稽核信息项说明25.3.6 稽核结果稽核结果107、说明稽核执行的结果，稽核结果代码如下：编码代码描述10正确用户权限分配正确。11错误发现授权异常。表格 021 稽核结果说明25.3.7 稽核单状态稽核单状态代码表明接入稽核单所处的处理状态，稽核单状态如下：编码代码描述10已发起已经发起稽核单。11等待稽核等待归口部门权限审批人进行权限稽核。12已稽核已经完成权限稽核。13关闭稽核单关闭，关闭时需指定稽核结果（正确）。表格 022 稽核单状态说明25.4 关键衡量指标为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。序号衡量指标指标计算说明1接入变更请求总数在统计周期内，接入变更申请的总数108、量。2接入变更平均执行时长在统计周期内，接入变更的平均执行时长。变更平均执行时长=接入变更总时长/接入变更次数。3各种不同来源接入变更请求数量/比率在统计周期内，不同来源（来自人事部门、变更管理流程启动、来自变更管理、来自业务部门管理者）的接入变更申请的数量及其占接入变更总数的比例。4分系统统计接入变更数量/比率在统计周期内，不同系统的接入变更申请的数量及其占接入变更总数的比例。5服务台执行的接入变更数量统计一段时间内由服务台直接执行的，未派发到二线等后台支持的接入变更数量。6接入变更成功执行次数/比例在统计周期内，通过审批并执行成功的接入变更的总数量。7权限稽核发现授权错误总数（分系统）在统109、计周期内，通过分系统统计权限稽核发现授权错误的用户数及用户组数。8权限错误引起的事件数量在统计周期内，因为授权错误引发的事件数量。表格 023 关键衡量指标说明25.5 角色及职责说明25.5.1 服务台n 服务台接受用户关于分配或回收权限的请求。n 服务台核实用户是合法的员工、供应商或客户，核实用户有权进行访问。n 服务台将核实过的授权请求转发给相应的技术团队进行授权。n 简单的授权工作也可以由服务台人员来进行。n 授权完成后由服务台通知用户。25.5.2 技术和应用管理人员技术和应用管理人员扮演如下多种重要角色：n 在服务运维期间，他们一般执行权限管理工作。n 在服务设计期间，他们必须确保110、每个服务都建立了控制接入的机制。同时权限滥用能够被检测和停止。n 在服务转换期，他们将测试服务，确保接入能够按照设计被授予、控制和阻止。n 技术和应用管理人员也负责处理与接入管理相关的事件和问题。n 如果权限分配活动被委派给服务台，技术和应用管理人员必须确保这些服务台员工被充分培训，以使他们能够使用正确的工具执行这些任务。25.5.3 接入经理n 对接入权限变更进行审批。一般由各专业技术负责人担任。25.5.4 归口部门审批人n 定期对本部门的员工权限进行稽核。n 对本部门的接入申请进行审批。本项工作在流程之外进行。26 事件管理流程26.1 流程定义事件管理流程是对IT生产环境中导致IT服务111、中断或潜在中断的事件进行管理，快速恢复IT服务能力的管理流程。事件的来源包括IT用户报告的事件、监控系统自动转发的事件、10000号系统自动转发的IT类事件等。它的目的是尽快恢复被中断或受到影响的IT服务，是以恢复服务为首要目的，可能采取临时解决方案，而不在于查找根本原因。26.2 流程目标事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括： n 确保各类IT事件能够在成本允许的范围内，按照事件的优先级，快速、有序地解决，从而减少IT服务中断造成的影响。 多渠道快速响应服务请求（电话/Web/邮件/即时通信工具等）。 根据事件的优先级，影响度进行综合分类排序，如果112、判断事件优先级是紧急，则启动紧急事件管理流程进行处理。 为客户提供及时的事件处理状态信息。 监控事件处理过程，必要时进行管理和技术升级。n 确保IT事件处理过程中的关键信息能正确记录，为后续事件处理提供知识支持，为流程持续优化提供准确的数据信息。 按规范记录事件信息及解决过程信息。 服务台及后台技术资源利用情况。 服务台、技术支持团队的工作效率。26.3 流程执行原则26.3.1 一般原则n 所有IT事件进IT服务管理系统：所有的IT用户报告的事件都应该在IT服务管理系统进行准确的记录，确保所有用户事件都能够进行端到端的监控，从而提高用户满意度。事件记录应尽可能的清晰详尽，要包括与事件关联的配113、置项信息，为事件的后续处理提供支撑。n 事件根据优先级顺序处理：应根据事件的影响程度和影响范围综合设定优先级，服务台及技术人员根据优先级设定的先后顺序进行事件处理和解决。n 应定期进行事件执行情况回顾：应该定期生成事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估；应该定期回顾流程执行情况。回顾内容包括关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程。26.3.2 事件处理/升级原则n 事件处理过程全程监控：应对事件处理全过程进行监控，对不同紧急程度的事件设定不同的处理时限要求；事件诊断及恢复的各个环节，相应的支持人员应及时响114、应和处理；如不能在规定的时限内解决或无法解决，应及时进行管理升级和技术升级；事件经理应负责协调资源，并督促事件能够及时被响应和处理。n 紧急事件立即处理原则：优先级为紧急的事件，服务台应立即派发到二线支持，并电话通知到负责人。紧急事件被确认后，应及时启动紧急事件处理流程，成立应急小组，启动或制定应急预案，以更快的响应速度、更简要的流程、更精干的人力资源来保障紧急事件的优先响应和排除。n 重大故障及时上报原则：重大故障或跨省故障应及时上报集团，在上报集团前应由事件经理进行审核确认。26.3.3 重复事件原则当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建115、的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件被解决时，所有的重复事件都被解决。n 重复的事件应该被标识，不计入事件流程的关键衡量指标。n 监控系统应该自动过滤重复告警，避免将重复的告警发送到IT服务管理系统。n 服务台如可以判断到重复事件，则由服务台对重复事件标识，否则由二线、三线支持人员负责重复事件的处理。26.3.4 事件关闭原则n 由IT用户通过电话、邮件方式申报的事件单，应由IT服务台统一关闭。n 由IT用户自助登记的事件单，处理完成后，应由IT用户进行确认并关闭。n 后台技术人员自行创建的事件单，应本着“谁开单，谁负责关闭116、”的原则由创建人进行关闭。n 监控平台自动发送的事件单，第一次接收的维护人员负责关闭。n 事件表象解决后，事件即可关闭，如需对事件进行根原因分析，则启动问题管理流程，解决根本原因，避免事件的再次发生。n 事件关闭时，应核对事件初始分类的正确性再次检查，并及时进行调整，确保事件信息的准确性。n 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单。26.4 与其它流程的关系图表 028 事件管理流程与其他流程的关系n 日常运维管理流程：日常运维过程中，发现IT服务中断或潜在中断，应启动事件管理流程，对事件进行解决。n 资产与配置管理流程：为事件管理提供事件相关联的配置项及关联关系查询117、，帮助进行事件影响性分析，并帮助快速定位和诊断引发事件的故障。n 知识管理流程：事件处理完成后，部分具备参考性的处理案例进入知识库，作为知识保存，为后续服务提供支持。n 服务请求流程：事件管理流程在对事件进行分类和排序时，如发现事件其实是服务请求，则启动服务请求流程进行处理。服务请求管理流程在处理服务请求时，如果确定请求涉及的内容是IT事件或者是可能会影响业务的任何IT异常，应启动事件管理流程来处理事件。n 紧急事件管理流程：在对事件进行分类和排序时，如果确定事件的优先级是紧急，则启动紧急事件管理流程进行处理。n 问题管理流程：如事件处理只是采取了临时解决方案，未找到根本原因，则启动问题管理流118、程，查找事件的根原因，实施改进措施。n 变更管理流程：事件解决的过程中，如需要进行配置项修改，则需要发起变更请求。26.5 流程说明26.5.1 事件管理26.5.1.1 一级流程26.5.1.1.1 流程图事件管理一级流程设计如下图：图表 029 事件管理一级流程26.5.1.1.2 活动说明事件管理一级流程活动说明如下：序号步骤名称责任人说明1记录事件服务台q 对所有IT 事件进行准确、详细记录，事件的来源包括来自IT用户的事件申告、来自监控系统的事件告警、10000号转发的电信客户IT类事件申告、集团下发的跨省IT事件。事件记录应尽可能的详尽，要包括与事件关联的配置项信息，为事件的后续处119、理提供支撑。2事件分类和排序服务台、二线、事件经理q 对于每个事件，应确定分类和优先级，保证事件能够按照优先级有序、快速进行处理，同时应根据不同的分类启动不同的流程或直接进入后续环节。如果事件是服务请求，则启动服务请求流程进行处理；如果事件优先级为紧急，则启动紧急事件处理流程进行处理；如果事件是跨省事件，则上报集团协调处理。3事件诊断与恢复服务台、二线、三线q 服务台或二、三线支持人员运用自身技能、知识库、诊断工具，对事件进行调查诊断，在必要时进行技术升级，尽快恢复IT服务。q 事件处理引起的配置项变更，应通过变更流程进行，避免因排除事件而引起新的事件；在紧急情况下可以先行变更，但应在事件处理120、完成后，及时补录相应的变更单，确保配置项信息的准确性。4事件关闭服务台、二线、三线q 在事件解决后，进入本环节，重新核实事件的分类，必要时用户进行回访。如果需要进行后续根原因分析，则启动问题管理流程。如果事件处理过程有借鉴价值，则启动知识管理流程，将处理过程存入知识库。5事件监控及管理升级服务台q 对事件处理的全过程进行监控，当事件无法在规定时限内解决时，应及时启动管理升级，通知事件经理及相关领导。表格 024 事件管理流程活动说明26.5.1.2 二级流程26.5.1.2.1 流程图图表 030 事件管理二级流程26.5.1.2.2 泳道图图表 031 事件管理二级流程泳道图26.5.1.2121、.2.1 事件记录图表 032 事件记录泳道图26.5.1.2.2.2 事件分类和排序图表 033 事件分类泳道图26.5.1.2.2.3 诊断与恢复图表 034 诊断与恢复泳道图26.5.1.2.2.4 事件关闭图表 035 事件关闭泳道图26.5.2 紧急事件管理对紧急事件的处理过程管理，启动应急预案，升级为重大故障等。26.5.2.1 一级流程图表 036 紧急事件管理一级流程26.5.2.2 二级流程26.5.2.2.1 流程图图表 037 紧急事件管理二级流程26.5.2.2.2 泳道图图表 038 紧急事件管理流程泳道图26.6 关键控制点序号重点内容类别1省公司进行流程角色设置时122、，必须设置事件流程负责人、事件经理、服务台、二线支持、三线支持等角色。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2各省进行流程角色映射时，如果来自10000号的IT投诉较多时，应设置专职服务台人员来协调和跟踪电信客户IT投诉的处理。3必须支持电话、email、用户自助登记等多种方式进行事件申告。关键管控点4所有IT事件（投诉、事件等）必须进IT服务管理系统。5事件必须能与配置信息建立关联关系，支持事件的影响分析。6必须单独设立紧急事件管理流程，处理紧急事件。7事件的解决引起配置项的变更，必须启动变更管理进行控制。8事件关闭时，必须具有通知申告者的机制。9事件关闭时，必须重123、新核实事件的分类。10如果事件处理过程有借鉴价值，则必须启动知识管理流程，将处理过程存入知识库。11事件关闭时，如需对事件的根原因分析，必须启动问题管理流程进行处理。12已关闭的事件单不允许重开，如果事件重复发生，则必须创建一个新的事件单。13重大故障必须及时上报集团。14服务台必须对事件处理全过程进行监控，事件处理超时时，必须有清晰的事件管理升级机制。15事件处理过程必须保存如下信息：事件ID、请求人信息、登记时间、事件发生时间、事件来源、用户事件提交渠道、事件影响度、事件优先级、所属系统类型、事件分类、事件标题、事件描述、事件解决人、事件状态、解决方案、业务中断时长、事件结束代码、重复事件124、标记、重复事件ID、实际完成时间、关联配置项、关联的问题单号、关联的变更单号。关键信息要求表格 025 关键控制点说明26.7 主要相关数据说明26.7.1 事件信息项与事件单（含处理过程增加）相关的信息项如下：各省公司可以在此基础上扩充：序号信息项说明1事件ID事件单流水号。2请求人信息事件申报人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机。3登记时间在服务台生成事件记录的时间 4地点事件发生的地点。5事件发生时间针对事件：指的是业务中断的实际时间 （可能早于登记时间，需要调整确认）。针对其它：缺省值等于登记时间。6业务恢复时间针对事件的业务恢复实际时间。 7事件来源参见“125、事件来源”定义。8对端省事件ID 事件来源为“集团下发”时，下发的事件ID。9用户事件提交渠道参加”用户事件提交渠道”定义。10事件影响度参见“事件影响度”定义。11事件优先级参见“事件优先级”定义。12事件完成期限对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限。 13所属系统类型参见“所属系统类型”定义。14事件分类参见“事件分类”定义。15事件标题事件的简要描述。16事件描述对于整个事件内容的详细描述。 17事件解决人事件的最终解决人。 18事件状态参见“事件状态”定义。19分配对象被分配的技术支持组和人员。 20事件日志反映事件信息项的变化历史，如一个126、事件在处理过程中事件状态变化的时间点等信息。 21解决方案事件解决方案的描述。 22业务中断时长造成业务计划外中断的时间长度。23事件结束代码参见“事件结束代码”定义。24重复事件标记标记为重复事件。 25重复事件ID重复事件中主事件ID。26处理是否超时参见“处理是否超时”定义。 27实际完成时间记录事件已解决的时间。 28事件厂商参见附录C厂商和集成商名称标准。 29关联配置项记录出现事件的配置项代码。 30关联的问题单号记录由事件引发问题时，关联的问题单号。 31关联的变更单号记录由事件引发变更时，关联的变更单号。 表格 026 事件信息项说明26.7.2 事件来源事件来源代码用来标明事127、件的提出来源，事件来源可以包括以下几种：编码代码描述10用户事件用户或地市维护人员通过电话/邮件/Web/传真报告的事件，服务台人员手工创建事件单。11客服转单通过10000号系统自动转发的事件。12内部开单省公司业务支撑部门内部提交的事件。13监控告警监控工具自动转发过来的事件。14内部转发OSS电子运维等转发的事件。15集团下发集团转发的事件。表格 027 事件来源说明26.7.3 用户事件提交渠道用户事件提交渠道代码用来标明用户报告事件的渠道，提交渠道可以包括以下几种：编码代码描述10电话报告用户或地市维护人员通过电话报告的事件，服务台人员手工创建事件单11Web自助用户通过Web页面，128、自助创建的事件单12电子邮件用户或地市维护人员通过邮件报告的事件，服务台人员手工创建事件单13即时通信用户或地市维护人员通过即时通信工具报告的事件，服务台人员手工创建事件单表格 028 用户事件提交渠道说明26.7.4 所属系统类型当事件发生时，由服务台初步定位是哪个业务系统及子类出现问题，由二线进行进一步的明确。注：各省可以在本表的基础上扩展子类。一级（N1N2）二类（N3N4）编码BSS域（10）CRM系统100110000语音平台1002网上营业厅1003外部客户认证平台1004准实时计费系统1005在线计费系统1006综合结算系统1007统一充值平台1008综合采集预处理系统1009其129、他1099OSS域（11）综合服务开通系统1101综合服务保障系统1102综合资源管理系统1103网络运维管理系统1104施工调度系统1105综合网络管理系统1106自动激活系统1107专业网络管理系统1108其他1199MSS域（12）OA/企业内部门户1201财务管理专业系统1202供应链管理专业系统1203项目管理专业系统1204人力资源管理专业系统1205知识管理1206其他1299EDA域（13）企业数据应用门户1301ODS1302EDW1303其他1399ITOM域（14）IT基础设施监控系统1301应用软件监控系统1402业务数据监控系统1403IT服务管理系统1404其他14130、99表格 029 所属系统类型说明26.7.5 事件分类事件分类代码用于标识事件或申告的具体原因，由支持人员在处理过程中填写。在制作统计报表时，可以通过和所属系统类型代码的结合来统计分析事件。事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。注：各省可以在下表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。事件分类：一级分类（编码）二级分类（编码）三级分类（编码）编码硬件(HW)（10）容器(CTR)（01）机架(RCK)（01）100101机框(CLS)（02）100102服务器(SRV)（02）PC服务器（PCS131、）（01）100201小型机(EPS)（02）100202分区服务器(PRS)（03）100203网络设备(NWD)（03）光纤交换机(FST)（01）100301交换机(SWT)（02）100302路由器(RUT)（03）100303防火墙(FWL)（04）100304入侵检测设备(RMD)（05）100305无线AP(WAP)（06）100306负载均衡设备(LAD)（07）100307其他(OTH)(99)100399存储设备(STR)（04）磁带库 (TPL)（01）100401磁盘阵列(DKA)（02）100402其他(OTH)(99)100499终端(TMD)（05）打印机(PRR132、)（01）100501PC机(PCM)（02）100502其他(OTH)(99)100599硬件模块（HWM）（06）硬盘（HDK）（01）100601CPU（CPU）（02）100602内存（MEM）（03）100603板卡(BRD)（04）100604端口（PRT）（05）100605其他(OTH)(99)100699软件(SW)（11）操作系统(OPS)（01）Windows(WND)（01）110101Linu(LN)（02）110102Uni(UN)（03）110103Mac OS(MOS)（04）110104数据库(DBS)（02）ORACLE(ORA)(01)110201INFO133、RMI(INF)(02)110202SYSBASE(SBS)(03)110203SQLSERVER（04）110204其他(OTH)(99)110299集群软件(CLR)（03）集群软件(CLR)(01)110301集群节点(CLN)(02)110302中间件(MWR)（04）应用中间件(AMW)(01)110401消息中间件(MMW)(02)110402交易中间件(TMW)(03)110403其他(OTH)(99)110499应用系统(APS)(05)MSS（MSS）(01)110501OSS(OSS)(02)110502BSS(BSS)(03)110503EDA(EDA)(04)11050134、4ITOM(ITM)(05)110505操作系统逻辑单元(OSL)（06）卷(VOL)(01)110601交换空间(SWP)(02)110602文件系统(FLS)(03)110603系统服务(SSR)(04)110604系统进程(SPR)(05)110605系统日志(SLG)(06)110606其他(OTH)(99)110699数据库逻辑单元(DBL)（07）数据库参数(DBP)(01)110701数据库服务(DBS)(02)110702数据库内存(DBM)(03)110703日志文件(DBL)(04)110704存储区间(DBST)(05)110705存储文件(DBF)(06)110706其135、他(OTH)(99)110799中间件逻辑单元(MWL)（08）应用域(MAD)(01)110801应用集群(MCL)(02)110802应用服务器(MAS)(03)110803线程池(MTP)(04)110804数据库连接池(MDP)(05)110805其他(OTH)(99)110899应用系统逻辑单元(APL)（09）进程(APR)(01)110901进程池(APP)(02)110902接口(API)(03)110903应用数据文件(APF)(04)110904其他(OTH)(99)110999码号资源（NO）（12）IP地址资源(IPA)（01）IP地址池(IPP) （01）120101136、IP段(IPS) （02）120102IP地址(IPA) （03）120103域名（COM）（02）域名（COM）（01）120201表格 030 事件分类说明26.7.6 事件优先级优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。编码优先级代码描述10紧急q 系统事件导致客户无法办理或使用业务：如CRM、统一充值、网上营业厅、10000号、服务开通、网络激活、资源管理等，影响面为一个地市以上。q 计费类系统事件，影响到向客户收费：如：联机采集、OCS、在线计费系统、综合结算等，影响面为一个地市以上。q 系统事件影响大部分员工日常137、工作：如OA、财务管理系统等，影响面为全省或最少一个关键地市。q 因系统原因数据处理错误，导致大量用户投诉。q 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告。q 部分重要数据丢失，且无法全部恢复。11高q 系统事件影响大部分员工日常工作：如OA、财务管理系统等，影响面为一个或多个非关键地市。q 任一系统瘫痪，导致整个系统无法使用，并且非紧急事件。q 用户在营业现场反应激烈。q 监控管理平台严重告警。12中q 一般性系统事件。q 监控管理平台主要告警。13低q 一般单个用户申告。q 业务咨询。q 监控管理平台一般告警。表格 031 事件优先级说明以上优先级的描述仅供参考，各138、省根据实际情况自行定义优先级的条件要求。建议根据事件的影响范围和业务系统的关键程度来定义优先级。26.7.7 事件响应时限和解决时限在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制。一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念；也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理；如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果服务台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间139、；解决时限指的是事件状态从“已登记”到“已解决”经过的时间。事件优先级对应的事件响应时限和解决时限参考下表（以下时间是247工作时间）：编码优先级代码响应时限要求解决时限要求10紧急30分钟4小时11高1小时8小时12中4小时48小时13低8小时96小时表格 032 事件响应时限说明注：各省根据自己的业务需要可以修改优先级对应的响应时限和解决时限，但应该小于这个范围，并且定义的时候应该考虑事件影响度的定义。 26.7.8 事件影响度事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务事件所造成的损失来设定。定义事件影响度等级的因素有：n 是否影响了核140、心业务。n 所影响的用户数。n 服务失效的影响范围和时长。事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的事件会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。编码影响度代码事件性质描述10重大系统事件q 系统事件导致客户无法办理或使用业务，如CRM、统一充值、网上营业厅、10000号、服务开通、网络激活、资源管理等，影响面为一个地市以上，影响时长超过3个小时。q 计费类系统事件，影响到向客户收费，如：联机采集、OCS、在线计费系统、综合结算等，影响面为一个地市以141、上，影响时长超过3个小时。q 系统事件影响大部分员工日常工作，如OA、财务管理系统等，影响面为全省或最少一个关键地市，影响时长超过6个小时。客户投诉q 对电信公司造成巨大损失产生严重后果和不良影响的11严重系统事件q 系统事件导致客户无法办理或使用业务，如CRM、统一充值、网上营业厅、10000号、服务开通、网络激活、资源管理等，影响面为一个地市以上，影响时长超过30分钟，小于3个小时。q 计费类系统事件，影响到向客户收费，如：联机采集、OCS、在线计费系统、综合结算等，影响面为一个地市以上，影响时长超过30分钟，小于3个小时。q 系统事件影响大部分员工日常工作，如OA、财务管理系统等，影响面142、为全省或最少一个关键地市，影响时长超过30分钟，小于6个小时。q 任一系统瘫痪，导致整个系统无法使用，并且非重大故障。客户投诉q 局数据错误导致产生大量的错单。q 涉及到高额问题的客户投诉。q 用户在营业现场反映激烈。12一般系统事件q 系统内局部出现问题，不影响整个系统运行，不影响业务处理的事件。客户投诉q 不属于重大和严重的客户投诉。系统事件q 不影响系统的监控平台告警。13无客户投诉q 一般数据查询或者使用指导。表格 033 事件影响度说明注：各省公司根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。26.7.9 事件状态事件状态代码表明事件所处的处理143、状态，事件状态如下：编码代码描述10已登记新开事件记录或事件已创建。11分配到服务台事件已分配给服务台人员或一线人员。12分配到二线事件已分配到二线支持，二线还未响应。13分配到三线事件已分配到三线支持，三线还未响应。14服务台处理中服务台已接手处理事件。15二线处理中二线支持人员已接手处理事件。16三线处理中三线支持人员（厂商）已接手处理事件。17已解决事件已解决，支持人员联系用户验证事件是否获得解决。18关闭事件已关闭。表格 034 事件状态说明26.7.10 事件结束代码事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：编码代码描述10成功解决事件获得成功解决。11变通方法解决事144、件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析。12不成功事件没有获得解决（用户没有认可解决时使用）。13消失事件自行消失。14误报不属于业务支撑部门管理范围的事件。15可忽略如通过其它系统接口或监控系统提交的垃圾信息，经确认属于无效信息。表格 035 事件结束代码说明26.8 关键衡量指标为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。序号衡量指标指标说明1事件总数统计一段时间内真正的事件总数，不包括误报和可忽略的事件。2紧急事件数量及百分比优先级为紧急的事件总数、以及占事件总数的百分比。3不同来源的事件数量及百分145、比统计来源于用户事件、监控平台、集团下发、10000号转发、IT内部创建的事件及占总事件数量的百分比。4用户事件提交渠道百分比统计用户事件中，来源于电话、web、邮件、即时通信工具等不同方式的事件百分比。5服务台及一线解决的事件数量由服务台及一线直接解决的，未派发到二线等后台支持的事件数量。6各类型事件平均解决时长统计来源于用户事件、监控平台、集团下发、10000号转发、内部创建的事件的平均解决时长。7重新调整分类的事件数量统计初始登记中分配的事件分类，在后续派单及流转过程，以及关闭回顾中进行分类调整的事件数量及其占总事件数量的百分比。8计划外业务中断时长在事件关闭时应记录计划外业务中断时长，146、针对服务和系统累计的，统计周期内中断服务的总时长。9处理超时升级的事件数量整体处理时间超出相应级别事件处理时限（紧急：2小时，一般24小时）。10存在潜在问题的事件数量事件关闭时，发现存在潜在问题未解决需启动问题管理事件的数量。11规定时间内解决的事件数量/百分比统计一段时间内成功解决或变通解决并且处理未超时的事件总数，及其占所有事件总数的比例。12规定时间内响应的事件数量/百分比统计一段时间内成功解决或变通解决并且处理未超时的事件总数，及其占所有事件总数的比例。13客户投诉响应及时率统计一段时间内，针对客户投诉类事件，从事件单生成到事件单开始处理，满足投诉响应时限要求的比例。14客户投诉处理147、及时率统计一段时间内，针对客户投诉类事件，从事件单生成到事件单处理完成，满足投诉响应时限要求的比例。表格 036 关键衡量指标说明26.9 角色及职责说明26.9.1 事件经理事件经理负责事件解决过程中的协调和监控，事件升级的判断和具体执行。职责：n 负责对事件的解决协调资源，保证事件的最终排除。n 确保和问题管理流程经理的有效合作。n 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。26.9.2 服务台人员服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的二线支持工程师。与服务台一起工作进行事件处理的技术人员定义为一线人员。职责：n 负责247148、的值班和系统监控。n 响应客户投诉工单、热线电话、邮件、传真等事件报告。n 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等。n 对事件进行适当的分类、为事件分配优先级等。n 尝试使用工具对事件进行初步诊断，分析相关信息并解决问题。n 对服务台解决不了的事件，分配给最合适的二线支持小组/人员来处理。n 检查事件的处理进度，保持与事件报告人的联系，适时通知事件处理进展。n 与用户确认事件解决结果，关闭事件。26.9.3 二线支持人员二线支持人员是电信内部相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务149、。在省公司的实际情况中，技术人员一般会按照所维护的应用、系统进行分工，如：网络支持、主机支持、应用支持等。这些技术人员都可以映射为二线支持人员，在流程中不明确区分。职责: n 验证事件的描述和信息，进一步收集相关信息。n 进行深入调查研究或协调厂商支持，提供有效的解决方案。n 实施事件解决方案。n 更新事件解决信息，将已解决的事件转回服务台。26.9.4 三线支持人员包括应用开发厂商的后端研发团队、提供远程支持的设备厂商、或厂商的现场服务。职责: q 提供远程接入方式的支持，协助进行事件诊断及恢复。q 必要时提供现场支持和深入调查研究，提供有效的解决方案。q 参与重大事件解决方案的实施。27 150、问题管理流程27.1 流程定义问题管理流程是确定某一事件或具有相同症状的一组事件的根本原因，制定和实施解决方案，从而防止事件再次发生的管理流程。问题管理流程的目的是找出事件根本原因，尽可能的给出解决方案或者临时应对措施。27.2 流程目标问题管理流程的目标是降低生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。其目的包括：n 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生。n 通过对已知错误进行标识，最小化不能被消除事件的影响。n 提高IT服务的可靠性，降低IT支持成本。n 问题管理过程得到正确记录，满足审核和统计的管理要求。27.151、3 流程执行原则27.3.1 一般原则n 问题的解决需要对IT环境变更时，启动变更管理，对变更的影响进行分析，避免因排除事件而引起新的事件。n 定期举行问题管理会议通过查阅事件管理报表，对事件发生的趋势进行分析，主动发现事件的潜在原因。n 定期回顾流程执行情况，回顾内容包括关键衡量指标、流程执行效率等，以改进问题管理流程。27.3.2 创建原则n 事件在恢复服务后仍需后续分析处理的，应关闭事件单，创建问题单。n 维护中发现的潜在事件，尚未影响业务的，应建立问题单。n 工作分析会落实的潜在故障分析任务，应建立问题单。27.3.3 重复问题原则n 重复问题是指经过分析之后，根本原因相同的问题。例如152、：由事件管理流程输出的若干问题，经过分析之后，发现这些问题的根本原因是相同的，这些问题就可以定义为重复问题。对于重复问题应该被标识，不计入问题管理流程的关键衡量指标，但要建立重复问题之间的关联关系，在问题解决时进行统一回顾。27.3.4 问题关闭与回顾原则n 已关闭的问题单不允许重开。如果问题重复发生，则创建一个新的问题单。n 具有借鉴意义的问题在关闭时必须整理经验，提交知识库。n 对集团及其他省公司有借鉴意义的问题解决方案要上报集团，实现全国范围内的共享。27.3.5 与其他流程的关系图表 039 问题管理与相关流程的关系n 事件管理流程：事件在恢复服务后仍需后续分析处理的，应关闭事件单，创153、建问题单。这种情况下，问题单必须和事件单建立关联。n 日常运维管理流程：日常运维过程中发现问题，发起问题管理流程。n 变更管理：问题处理过程中，如果需要对系统进行变更，必须提交到变更管理进行处理，同时提交变更请求单（变更单必须和问题单建立关联），变更完成后，验证结果。n 资产与配置管理：问题处理过程中，可以通过资产与配置管理查询相关的配置项信息。如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联。n 知识管理：问题处理完成后，如有借鉴意义，则需要将问题解决方案提交到知识库中(问题单必须和知识单建立关联)。如问题解决方案对集团和其他省公司有借鉴意义，应及时上报集团，实现全国范围内的154、共享。n 需求管理：问题管理中给出的问题解决方案，如果是需要业务部门参与的软件更改或硬件扩容，则需纳入需求管理进行分析和审批。27.4 流程说明27.4.1 一级流程27.4.1.1 流程图图表 040 问题管理一级流程27.4.1.2 活动说明序号活动名称责任人说明1问题记录问题请求人问题处理专家n 本环节是问题管理的初始环节，问题申请的主要来源有：由事件管理流程提出的需要确定根本原因的问题。运维支撑人员在日常工作中发现的问题。定期分析事件记录找出的问题。本环节需要对以上来源的问题的申请进行准确、详细记录，记录信息包括问题特征、类型、关联配置项等信息，为下一步问题分析、诊断、解决提供良好的问155、题信息支撑。n 根据问题的类型及紧急程度进行对问题的初步分类和优先级排序。2问题核查与分派问题经理n 本环节主要对问题记录的完整性、合理有效性、重复性、分类和排序是否正确等方面进行核查，保证问题能够合理有效，分类及排序正确，为后续的问题处理提供支撑。由问题处理专家提交上来的问题，问题经理对其问题进行审核确认，判断问题是否需要继续处理。如果问题确认无效，则关闭问题，并通知相关人员阅知。n 经过问题经理审核通过的问题，将分派给相应问题处理专家进行问题处理。3问题分析、诊断、实施解决方案问题处理专家问题经理问题分析、诊断n 问题处理专家接受问题，并展开调查及诊断，对问题根本原因进行确认。n 将问题产156、生根本原因及时更新到问题记录中，并创建已知错误单，至知识管理流程。n 如果预计无法找到问题的根本原因，及时通报问题经理，有问题经理进行判断是否需要继续查找问题根本原因，如不需要则关闭问题，同时通知相关人员阅知。制定解决方案n 对于已经找到根本原因的问题，需要确定解决方案，以便永久的解决。n 问题处理专家推荐根本性解决方案或变通解决方法，由问题经理对提出的方案及或变通方法的可行性进行审核。n 问题处理专家预计在无法找到根本解决方案或虽有解决方案但目前无法实施（如实施的代价太大），通报问题经理，由问题经理进行审核，判断是否继续寻找其他解决方案或变通方法，如果不需要则通关闭问题，同时通知相关人员阅知157、。实施解决方案n 实施解决方案，并确保这些方案彻底解决问题。n 问题处理专家判断实施解决方案/变通方法是否需要通过变更流程；- 如需要，提交到变更的流程，并和该流程人员保持沟通，了解问题的解决状况，经过变更流程解决问题后返回问题经理处进行结果验证；- 如不需要变更，计划并组织实施解决方案以解决问题；结果验证通过后，将实施解决方案过程进行详细记录。4问题处理监控问题经理n 由问题经理对问题处理过程进行监控，如发现问题确实长期无法解决，关闭问题并将问题标识为无法解决。 5问题关闭问题处理专家问题经理n 整理问题处理经验，提交到知识管理系统。n 问题经理认为值得集团或其他省公司借鉴的问题解决经验，上158、传到集团，实现全国范围内的经验共享。n 对问题记录的信息项进行总结，更新问题记录并关闭问题。表格 037 问题流程活动说明27.4.2 二级流程27.4.2.1 流程图图表 041 问题管理二级流程27.4.2.2 泳道图 图表 042 问题管理二级流程泳道图27.5 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设置问题流程负责人、问题经理、问题处理专家、问题请求人、等角色。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2定期举行问题管理会议通过查阅事件管理报表，对事件发生的趋势进行分析，主动发现事件的潜在原因。关键管控点3问题的解决需要对IT环境变更时，必须启159、动变更管理流程。4具有借鉴意义的问题关闭时必须整理经验，提交知识库。对在全集团有借鉴意义的时候，必须上报集团。5在发现问题根原因，已知错误库的创建一条记录。6将重复的问题进行标识，并不计入问题管理流程的关键衡量指标。7有统一的流程经理，对所有问题流程进行全程监控。8问题处理过程必须保存如下信息：问题ID、请求人信息、登记时间、地点、问题来源、所属系统类型、问题分类、问题标题、问题描述、问题优先级、问题拒绝原因、变通方法、问题原因、重复问题标记、问题状态、问题日志、实际开始诊断时间、实际诊断结束时间、解决方案、问题结束代码、问题无法解决原因、关联配置项、关联配置项事件、关联的变更单号、关联的知识160、单号、问题关闭时间。关键信息要求表格 038 关键控制点说明27.6 主要相关数据说明27.6.1 问题信息项问题单包含如下信息项： 序号信息项描述1问题ID为每个问题分配一个唯一的序列号。2请求人信息问题请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机。 3登记时间生成问题记录的时间。 4地点记录问题发生的地点。 5问题来源参见“问题来源”定义。7所属系统类型参见“所属系统类型”定义。8问题分类参见“问题分类”定义。9问题标题简单描述问题。 10问题描述详细描述问题内容。 11问题优先级参见“问题优先级”定义。12问题拒绝原因详细描述拒绝问题原因，并推荐其他专家或专家组。161、 13变通方法详细记录问题的变通方法。14问题原因详细记录问题产生的根本原因。 15重复问题标记标记为重复问题，用已有标题号标注。 16重复问题ID为重复问题分配一个序列号，并且关联相应的问题ID。17问题状态参见“问题状态”定义。18问题经理该问题对应的问题经理。19问题处理专家负责该问题的问题处理专家。20问题日志反映问题处理过程中问题信息项的变化历史，包括分配的人员，状态等信息。 21实际开始诊断时间问题状态更新为“分析中”的时间。 22实际诊断结束时间问题状态更新为“已有解决方案”的时间。 23解决方案问题解决方案的详细描述。 24问题结束代码参见“问题结束代码”定义。25问题无法解决162、原因解释问题无法解决的原因。 26关联配置项记录问题的配置项代码。 27关联的事件单号记录引发该问题的事件单号。 28关联的变更单号记录由问题发变更时，关联的变更单号。 29关联的知识号记录问题对应的知识单号(系统自动填写。)30问题关闭时间当问题状态更新为“结束并关闭“的时间。 表格 039 问题信息项说明27.6.2 问题来源根据问题的不同来源对问题分类如下：编码代码描述10 事件研究事件管理流程提出的问题，要求对事件的根本原因进行分析。业务恢复后，相应事件单被关闭，但如果引起事件的潜在原因及规避措施仍需继续研究，则启动问题管理流程，创建问题单。例如：某日发生了一起集群无法切换的事件，导致163、某台主机发生事件后，没有切换到备用主机中去，从而影响了业务，事件处理人员在采取了手工切换的替代措施后，恢复了服务。为了分析为什么会发生该事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该事件进行研究分析。11维护提出技术专家在日常维护工作中提出的问题。日常维护中发现的潜在事件即使还没有影响到业务，也应该启动问题管理流程，创建问题单。例如：维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便研究分析，避免日后发生事件。12趋势分析通过分析事件记录找出的问题。常规的工作分析会上确定的、需要深入研究的任务落164、实到维护专家后，应启动问题管理流程，创建问题单。例如：在定期的会议中，对计费类的事件进行分析后发现，上周该类型的事件比平常的时候多了30，超过了规定的阀值，这表明计费系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。表格 040 问题来源说明27.6.3 问题优先级问题的优先级是问题处理专家解决问题的参照标准，对于关键级的问题，管理层应该优先协调资源对这些问题进行解决。结合集团的实际情况，问题的优先级定义如下：编码代码描述10关键从如下方面考虑，问题是否：n 影响到关键业务（如：综合帐务、CRM、电话呼叫中心等）。n 影响范围极大（如：一个关键地区或半数以上非165、关键地区）。n 紧迫程度最高（如：必须马上着手处理）。n 问题处理后可大幅节省投资、人力，有效提高服务质量和维护效率。11重要从如下方面考虑，问题是否：n 影响到较关键业务（如：联机采集、融合计费、产品管理等）。n 影响范围较大（如：一个以上非关键地区）。n 紧迫程度较高。n 问题处理后可有效节省投资、人力，一定程度提高维护质量。12普通从如下方面考虑，问题是否：n 影响到非关键业务。n 有一定影响范围。n 问题处理后对维护质量和效率的提升有限。表格 041 问题优先级说明27.6.4 问题状态为了记录问题处理的生命周期，需要设置不同的状态加以描述，如下所示： 编码代码描述10已登记问题登录到166、系统中。11分析中问题处理专家正在分析问题过程中。12已知错误问题等待中标识为已知错误问题，等待上一个问题处理结果。13已定位原因问题根本原因已找出。14已有解决方案解决方案已找到。15已提出变更请求已提交变更请求（RFC）。16已回顾已经对问题进行了回顾。17结束并关闭问题结束。表格 042 问题状态说明27.6.5 所属系统类型当问题产生时，应该由问题记录环节初步定位是哪个系统及子类出现问题。注：各省可以在此表的基础上扩展子类。一级（N1N2）二类（N3N4）编码BSS域（10）CRM系统100110000语音平台1002网上营业厅1003外部客户认证平台1004准实时计费系统1005在线167、计费系统1006综合结算系统1007统一充值平台1008综合采集预处理系统1009其他1099OSS域（11）综合服务开通系统1101综合服务保障系统1102综合资源管理系统1103网络运维管理系统1104施工调度系统1105综合网络管理系统1106自动激活系统1107专业网络管理系统1108其他1199MSS域（12）OA/企业内部门户1201财务管理专业系统1202供应链管理专业系统1203项目管理专业系统1204人力资源管理专业系统1205知识管理1206其他1299EDA域（13）企业数据应用门户1301ODS1302EDW1303其他1399ITOM域（14）IT基础设施监控系统13168、01应用软件监控系统1402业务数据监控系统1403IT服务管理系统1404其他1499表格 043 所属系统类型说明27.6.6 问题分类问题分类代码用于标识问题的具体原因，由问题处理专家在处理过程中填写。在制作统计报表时，可以通过和所属系统类型代码的结合来统计分析事件或申告。注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。问题分类一级分类（编码）二级分类（编码）三级分类（编码）编码硬件(HW)（10）容器(CTR)（01）机架(RCK)（01）100101机框(CLS)（02）100102服务器(SRV)（02）PC服务器（PCS）（01）100201小型机169、(EPS)（02）100202分区服务器(PRS)（03）100203网络设备(NWD)（03）光纤交换机(FST)（01）100301交换机(SWT)（02）100302路由器(RUT)（03）100303防火墙(FWL)（04）100304入侵检测设备(RMD)（05）100305无线AP(WAP)（06）100306负载均衡设备(LAD)（07）100307其他(OTH)(99)100399存储设备(STR)（04）磁带库 (TPL)（01）100401磁盘阵列(DKA)（02）100402其他(OTH)(99)100499终端(TMD)（05）打印机(PRR)（01）100501PC机170、(PCM)（02）100502其他(OTH)(99)100599硬件模块（HWM）（06）硬盘（HDK）（01）100601CPU（CPU）（02）100602内存（MEM）（03）100603板卡(BRD)（04）100604端口（PRT）（05）100605其他(OTH)(99)100699软件(SW)（11）操作系统(OPS)（01）Windows(WND)（01）110101Linu(LN)（02）110102Uni(UN)（03）110103Mac OS(MOS)（04）110104数据库(DBS)（02）ORACLE(ORA)(01)110201INFORMI(INF)(02)11171、0202SYSBASE(SBS)(03)110203SQLSERVER（04）110204其他(OTH)(99)110299集群软件(CLR)（03）集群软件(CLR)(01)110301集群节点(CLN)(02)110302中间件(MWR)（04）应用中间件(AMW)(01)110401消息中间件(MMW)(02)110402交易中间件(TMW)(03)110403其他(OTH)(99)110499应用系统(APS)(05)MSS（MSS）(01)110501OSS(OSS)(02)110502BSS(BSS)(03)110503EDA(EDA)(04)110504ITOM(ITM)(05)172、110505操作系统逻辑单元(OSL)（06）卷(VOL)(01)110601交换空间(SWP)(02)110602文件系统(FLS)(03)110603系统服务(SSR)(04)110604系统进程(SPR)(05)110605系统日志(SLG)(06)110606其他(OTH)(99)110699数据库逻辑单元(DBL)（07）数据库参数(DBP)(01)110701数据库服务(DBS)(02)110702数据库内存(DBM)(03)110703日志文件(DBL)(04)110704存储区间(DBST)(05)110705存储文件(DBF)(06)110706其他(OTH)(99)1107173、99中间件逻辑单元(MWL)（08）应用域(MAD)(01)110801应用集群(MCL)(02)110802应用服务器(MAS)(03)110803线程池(MTP)(04)110804数据库连接池(MDP)(05)110805其他(OTH)(99)110899应用系统逻辑单元(APL)（09）进程(APR)(01)110901进程池(APP)(02)110902接口(API)(03)110903应用数据文件(APF)(04)110904其他(OTH)(99)110999码号资源（NO）（12）IP地址资源(IPA)（01）IP地址池(IPP) （01）120101IP段(IPS) （02）1174、20102IP地址(IPA) （03）120103域名（COM）（02）域名（COM）（01）120201表格 044 问题分类说明27.6.7 问题结束代码为了表明问题的不同解决方式，定义如下结束代码：编码代码描述10根本解决找出问题的根本原因，并得到解决方案，成功解决。11变通方法没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法。12无法解决未找到问题的根本原因，没有解决方案，或目前无法实施解决方案，也无变通方法。13取消问题被问题经理拒绝。表格 045 问题结束代码说明27.7 关键衡量指标为了较好地控制问题管理流程的质量，必须为问题管理流程设置考核指标，通过175、对指标的分析，可以有效地对流程的运行情况进行监控和改进。问题管理流程的关键衡量指标如下：序号衡量指标指标计算说明1问题总数数量：在问题单中根据以下条件过滤【重复问题标记】为空。【问题结束代码】不等于取消。【登记时间】在统计周期内。2已找到根本原因的问题数量数量：在问题总数中，【问题状态】=已定位原因 的问题个数。3趋势分析问题所占比率数量：在问题总数中，【问题来源】=趋势分析 的问题个数。比率：数量 / 问题总数 100 %。5通过变通办法解决的问题数量数量：在关闭问题数量中，【问题结束代码】=变通方法的问题个数。6问题成功解决率数量：在关闭问题数量中，【问题结束代码】=根本解决的问题个数。比176、率：数量 /关闭问题数量 100 %。7平均诊断时间诊断完成问题数量：【实际诊断结束时间】在统计周期内的问题个数。平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】【实际诊断开始时间】）/ 诊断完成问题数量。表格 046 关键衡量指标说明27.8 角色及职责说明问题管理流程主要包括问题经理、问题处理专家两个角色。问题经理问题经理负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。职责:n 确认、审核和监视问题处理过程。n 必要时协调所需资源。问题处理专家问题处理专家通常由各专业组技术人员、厂商人员承担，负责问题的诊断和解决。 职责：n 定期对事件记录进行分析177、，发现潜在问题，发起问题管理流程。n 进行问题诊断和分析。n 开发、确认、实施解决方案。n 关闭问题、整理解决方案并提交知识库。问题请求人问题请求人主要负责问题的提出。28 知识管理流程28.1 流程定义知识管理流程是对IT服务管理过程中产生的各类知识和经验进行收集、分类、审批、保存、回顾和共享的管理流程。经过知识管理流程所产生的知识要能够被企业内部相关使用人员安全，便捷，可靠的访问。28.2 流程目标n 通过知识库的支持，在处理事件问题时，可以快速定位问题,并查找对应解决办法。n 知识库具有的业务帮助功能，使相关人员可以通过关键字查询业务帮助、产品、市场活动、发生过的处理流程、电子文档等。n178、 知识库管理也包括对其他管理流程产生的文档的存储和应用。n 所有流程均可以累积知识，知识管理可以为所有流程提供知识支撑。28.3 流程执行原则28.3.1 知识创建原则n 知识被创建后的状态为未分类，待审核状态。n 由知识经理对知识进行审核通过后，方可正式发布。n 创建知识时，首先检索系统里有没有相同的知识，如有雷同则关闭知识创建请求，可根据需要对原有知识做更新。28.3.2 知识库维护n 知识的扩充应该是一个持续的过程。通过对系统运行维护过程中出现的问题进行不断的总结，对知识库进行知识扩充。n 知识创建时应设定有效期。对过期的知识应该做失效处理，避免对后续的工作产生误导作用。失效的知识应由管179、理员负责判断是否删除。n 管理员定期收集对已有知识的改进/修正意见，及时更新知识内容，必须由知识库经理进行审核，审核通过后方可发布。28.4 与其它流程的关系图表 043 知识管理流程与其他流程的关系事件管理流程：在恢复服务后，记录事件处理过程，总结事件处理经验，将经验转化为知识。问题管理流程： 查找问题根本原因，并将已查到根本原因的问题提交到知识库；通过成功实施解决方案解决问题根本原因，将解决方案纳入至知识库中。发布与部署管理：将通过发布与部署管理，成功发布的解决方案纳入至知识库中。日常运维管理流程：将日常运维工作过程中总结的经验转化为知识。28.5 流程说明28.5.1 二级流程28.5.180、1.1 流程图图表 044-知识管理二级流程28.5.1.2 活动说明序号步骤名称角色说明1知识更新：知识申请知识管理员q 知识可来源于服务生命周期所有流程模块的经验、方案、解决办法的积累。q 通过人工的方式对知识总结并录入系统，并以待审批状态在系统内存放。q 知识的内容至少包括有标题、内容、分类、关键字等，如有需要还需提交附件。q 知识需要记录作者，所属部门，联系方式等信息。q 知识的信息来源与问题管理、事件管理、发布与部署管理、日常运维管理，按照某种规范自动采集原始信息上报知识管理员进行知识有效性检查。2知识更新：知识分类知识管理员q 根据知识的标题、内容、关键字等，将知识进行合理分类，具181、体分类可根据实际情况进行划分。3知识更新：知识审核知识经理q 初步判断知识是否有效、是否重复，将重复知识或无效知识放弃。q 判断是否具有借鉴意义，将无借鉴意义的知识放弃。q 判断知识内容是否完整、清晰，如不够完整、清晰则退回知识管理员进行知识修改，并注明退还原因。q 审批通过的知识转派知识管理员进行知识发布。4知识更新：知识修改知识管理员q 接收未通过审批的知识，根据知识经理要求，重新整理知识。q 将整理完毕的知识，重新上报知识经理审批。5知识更新：知识发布知识管理员q 进行知识发布。6知识更新：知识关闭知识管理员q 知识更新完成，测试可用，关闭请求。q 知识存在重复、无借鉴意义，关闭请求。7182、知识定期回顾：知识回顾计划知识管理员q 制定知识回顾周期、知识归并、知识取消原则。q 制定每类知识回顾周期、回顾要求、归并策略、资源调配等计划安排。8知识定期回顾：知识归并、知识取消知识管理员q 根据知识维护策略归并同类知识、取消已失去效用的知识。9知识定期回顾：知识回顾报告知识管理员q 根据知识归并、知识取消结果形成知识回顾报告，上报知识经理处审核。10知识定期回顾：回顾结果审核知识经理q 对知识回顾报告审核，评价知识回顾活动。11知识定期回顾：回顾关闭知识管理员q 定期知识回顾结束，流程关闭。表格 047 知识流程活动说明28.5.1.3 泳道图图表 045 知识管理二级流程泳道图28.6183、 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设置知识管理员、知识经理等角色。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2新知识申请由知识经理对知识进行审核通过后，方可正式发布。关键管控点3知识创建时应制定有效期，对过期的知识应该做失效处理，避免对后续的工作产生误导作用。失效的知识应由管理员负责判断是否删除。4管理员定期收集对已有知识的改进/修正意见，及时更新知识内容，必须由知识库经理进行审核，审核通过后方可发布。5知识处理过程必须保存如下信息：知识标题、关键字、作者信息、正文、分类、知识状态、有效期、知识权限、创建时间、最后修订时间。关键信息要求表格 04184、8 关键控制点说明28.7 主要相关数据说明序号信息项描述1知识标题简单描述知识主题。2关键字知识关键字，可根据关键字搜索知识。3作者信息系统记录作者的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机。4正文知识详细内容，也可用附件对正文做补充。 5分类按照知识策略指导对知识分类。6知识状态待审核、有效、失效。7有效期指定知识的有效时。8知识权限指定知识的可读、可改的人员范围。9创建时间系统自动记录知识发布时间 YYYY-MM-DD HH:MM。10最后修订时间系统自动记录知识最后一次修订时间。 表格 049 主要相关数据说明28.8 关键流程衡量指标为了较好地控制流程的质量，必须185、为流程设置衡量指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。知识管理流程的主要衡量指标如下：序号衡量指标指标计算1各类型知识的发布数量数量：每一知识类型的在统计时间区间内的发布数量。2各类知识的点击数量数量：每一知识类型在统计时间区间内的点击量。3知识评级由业务部门及运维支撑工作人员对知识的内容、质量进行评级，通过知识管理员进行汇总，评选优秀知识，优秀解决方案（Top N）。表格 050 关键衡量指标说明28.9 角色及职责说明知识管理员知识库管理员主要负责知识库信息的维护工作。职责:n 确保进入知识库系统的数据分类正确，关键字定义正确以及知识有效性、唯一性。n 将需要新增186、修订、删除的知识报知识经理审核。n 对过期的知识定期进行删除。n 对相似的知识定期进行合并整理。知识经理知识库经理是知识管理具体活动的负责人。n 对发布知识的合理性、唯一性、效益负责。n 负责知识定期回顾，审核知识回顾报告，评价知识回顾结果。29 需求管理流程29.1 流程定义需求管理流程是对IT客户提出并经过需求归口部门审批通过的需求进行记录、分析、审批、跟踪、变更控制，对需求实施结果进行评估的管理流程。通过需求管理，保证业务需求清晰、可行，从而可以及时、准确地响应和支撑，并确保从需求提出到最终实现全过程是可跟踪、可追溯的。需求的实现过程是通过变更管理流程进行控制的。29.2 流程目标n 187、统一管理业务需求，确保业务需求实现过程可跟踪、可管理、可追溯、不丢失。n 通过需求实现计划的排序，保证需求在总体控制下有序实现，提高需求支撑效率，提高IT客户满意度。n 通过需求管理，确保业务需求清晰、准确、可行，提高IT投资效率，同时帮助客户选择需求,优先实现具有高回报、高收益、相对低风险的需求。29.3 流程执行原则29.3.1 一般原则n 统一管理：对所有IT部门负责维护管理的应用系统的需求应当进行统一的管理。需求来源包括集团、省公司、分公司；需求分类包括维护配置类（产品、套餐资费等）、维护性开发类、项目性开发类、数据提供及软件补丁类。n 需求拆分：需求提出需要根据需求内容进行非相关性拆188、分，再根据需求分类（维护配置类、维护性开发类、项目性开发类、数据提供及软件补丁类）进一步拆分。n 闭环管理：从业务需求的提出，到业务需求评审、分析、开发、测试、上线和后回顾，进行全过程闭环管理。n 可追溯原则：应对整个需求开发过程进行有效的记录，以保证可追溯需求生命周期中任一环节的相关信息。n 预先协商需求上线时间原则：IT部门应在和业务部门共同协商的基础上，根据技术能力和业务需求，初步确认业务需求上线的时限要求。原则上除有特殊要求的需求之外，都应当根据IT部门的版本升级计划进行排定。n 文档模板化原则：通过统一的文档模板、规范的流程管理IT需求，从整体上提升运营支撑效率。n 版本控制原则：所189、有需求文档应进行统一管理，并保留重要的历史版本。应充分利用必要的需求管理工具，比如把需求文档统一放在VSS或者CVS等版本管理工具中。n 需求回顾原则：定期对需求进行回顾，评估需求管理的状况，并提供优化改进建议。29.3.2 评审原则n 归口部门先行审批原则：对提交的需求应在需求归口管理部门进行签字确认，对明确要实现的需求及实现计划应由需求归口管理部门和需求实现部门签字确认。29.4 与其它流程的关系需求管理与其他流程的关系，如图所示：图表 046需求管理与其他流程的关系图n IT服务规划管理经需求管理确认要纳入滚动规划的需求，做为滚动规划的输入。n 资产与配置管理资产与配置管理提供配置项的属190、性及配置项之间的关联性信息，为评估新需求实现的风险和影响范围提供数据基础。n 变更管理在完成需求提出、需求确认、需求分析和评审，并开始实现需要时，要发起变更请求单。由变更管理对需求的实现过程进行控制。变更关闭后通知需求管理进行需求后评估，并关闭需求。n 问题管理当问题管理中给出的问题解决方案是需要业务部门参与的软件更改或硬件扩容时，则纳入需求管理进行分析和控制。29.5 流程说明29.5.1 一级流程29.5.1.1 流程图图表 047 -需求管理一级流程29.5.1.2 活动说明需求管理一级流程活动说明如下：序号步骤名称责任人说明1需求提出需求提出人q 收集客户提出的维护配置类（产品、套餐资191、费等）、维护性开发类、项目性开发类、数据提供或者软件补丁类需求。并与IT客户进行沟通、确定需求来源、初步确定需求所属系统同时给出需求优先级。q 如果需求是IT部门提出的是系统优化，则直接提交给IT部门相关人员进行需求要点分析，否则提交给需求归口部门先行审批。2需求确认需求联系人q IT部门对收集的需求进行进一步业务确认，对需求要点和需求影响进行分析，评审需求是否必要，需求是否描述清晰，需求是否冲突，例如需求间的冲突，需求与现有业务的冲突等。q 如果需求被确认，则进入需求分析，对需求进行技术评审，否则回退给需求提出人，并且说明不予处理的原因。 3需求分析需求经理、需求分析人员q 确定需求分类，确192、认需求所属系统。q 根据需求分类将需求派发到不同的工作组或者个人。q 会同业务部门进行需求的详细分类、整理、归并等分析工作。q 给出需求的初步实现方案，分析技术和经济的可行性。q 给出实现需求的工期概算、工作量概算等。q 给出需求的实现方式建议，分为维护类需求、工程类需求、应急工程类需求、进入滚动规划的需求。4需求审批需求经理q 对需求分析提供的IT支撑方案方案与需求说明书进行综合评审和批准，通过评审的工程类需求和维护类需求进入变更管理；通过评审的需求是滚动规划需求进入下一年度滚动规划。如果没有通过IT方案评审，需求将被拒绝实现并且直接关闭；如果方案不合理，则返回重新进行IT方案编制。q 对于193、应急工程类需求，应召开紧急评审会，通过评审的进入变更管理，没有通过评审的项目纳入下年度滚动规划，并且通知用户。5需求实现q 通过评审的需求是在变更管理控制下进行实现。6需求关闭需求联系人q 需求实现后，所有需求文档归档，关闭需求单。表格 051 需求流程活动说明29.5.1.3 流程输出需求管理流程主要输出以下文档：n 需求规格说明书：阐述系统必须提供的功能和性能以及它所要考虑的限制条件。n IT支撑方案(初步)：阐述需求实现的技术方案。29.5.2 二级流程29.5.2.1 流程图图表 048需求管理二级流程29.5.3 流程泳道图图表 049 需求管理二级流程泳道图29.5.3.1 需求提194、出图表 050 需求提出泳道图29.5.3.2 需求确认图表 051 需求确认泳道图29.5.3.3 需求分析图表 052 需求分析泳道图29.5.3.4 需求审批与实现图表 053 需求审批与实现泳道图29.5.3.5 需求关闭图表 054 需求关闭泳道图29.6 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设置需求归口管理人、需求联系人、需求分析人员、需求经理。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2所有IT系统的需求，都必须通过进入需求管理支撑。关键管控点3需求提出需要根据需求内容进行非相关性拆分，再根据需求分类（维护配置类、维护性开发类、项目性开195、发类、数据提供或者软件补丁类）进一步拆分。4IT部门应在和业务部门共同协商的基础上，根据技术能力和业务需求，初步确认业务需求上线的时限要求，原则上除有特殊要求的需求之外，都应当根据IT部门的版本升级计划进行排定。5业务部门的需求需要经过业务部门领导审核通过后才可转入IT部门进行技术分析或技术审核。6需求确认阶段需要对需求分类进行确认并进行需求影响分析。7需求分析阶段需确定需求实现方式、编写需求规格说明书、进行工作量概算。8需求审批通过后，启动变更管理。9需求一般情况下要在变更管理执行完毕后才可关闭。滚动规划类需求可以例外。10用户能够通过web方式上报需求、能够查询自己的需求处理状态。11需求196、管理过程必须保存如下信息：需求ID、要求时限、需求标题、需求重要程度、优先级、需求来源、需求分类、需求影响、需求规格说明书、工作量估算、预计实现时间、审批结果、需求处理状态。关键信息要求表格 052 关键控制点说明29.7 主要相关数据说明29.7.1 需求申请单需求申请单的信息项如下：各省可以在此基础上扩充：序号信息项描述1需求申请单编号 需求申请单流水编号。2需求申报部门提出需求申请的部门。3联系人需求联系人，可以是需求提出人，也可以是需求相关人员。4联系方式需求联系人的联系方式，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机。5提交时间需求提交时间 YYYY-MM-DD HH:M197、M。6要求时限需求实现在什么时间之内，格式YYYY-MM-DD HH:MM。7需求标题需求简述能够简要描述需求的特征。8需求详细说明需求申请原因、背景、需求实现效果、功能要求、业务流程等。9需求重要程度参见“需求重要程度”编码。10优先级参见“优先级”编码。11需求来源参见“需求来源”编码。12需求分类参见“需求分类”编码。13需求影响需求变更时必须填写，包括需求变更的内容、变更原因、时间等信息。14需求规格说明书需求分析的产物。15工作量估算初步评估需求实现需要的工作量。16预计实现时间初步评估需求实现的时间。17需求审批人需求的审批人员。18审批结果同意或不同意。 19备注留用。 20需求198、处理状态参见“需求处理状态”编码。21需求结束代码参见“需求结束代码”编码。表格 053 需求申请单信息项说明29.7.2 需求处理状态需求处理状态的信息项如下：各省可以在此基础上扩充：序号信息项描述10已申请该需求已经登记。11已确认需求归口管理部门确定需求要实现。12已批准需求审批人批准同意需求实现方案。13已实现需求已经实现。14关闭需求已关闭。表格 054 需求处理状态说明29.7.3 优先级序号信息项描述10紧急11一般表格 055 需求优先级说明29.7.4 需求分类序号信息项描述10维护配置类11维护性开发类12项目性开发类13数据补丁类表格 056 需求分类说明29.7.5 需199、求来源序号信息项描述10集团11省公司12分公司表格 057 需求来源说明29.7.6 需求结束代码序号信息项描述10成功11拒绝表格 058 需求结束代码说明29.7.7 需求重要程度序号信息项描述10高11中12低表格 059 需求重要程度说明29.8 流程相关指标序号指标指标说明1需求总数统计一段时间内所有需求的数量。2各类型的需求数量及占比统计一段时间内不同类别（滚动规划需求、项目需求、维护性需求、应急工程）的需求数量及其占需求总数的比例。3紧急需求数量及所占比例（从需求提出到期望解决时间10个工作日的需求）统计一段时间紧急需求总数，及其占所有需求的百分比。4被拒绝的需求数量及占比统计200、一段时间内审批不通过的需求数量，及其占所有需求的百分比。5审批接受的需求数量统计一段时间内审批通过的需求数量，及其占所有需求总数的百分比。6已批准的需求的工作量概算统计一段时间内审批通过的需求的工作量概算总和。7在需求期望完成时间内完成的需求数量及其占比统计一段时间内按照期望时间完成的需求数量，及其占所有需求总数的百分比。表格 060 需求流程相关指标说明29.9 角色及职责说明29.9.1 需求提出人需求提出人是业务部门或者IT部门的人员，一般是系统的最终用户。其主要职责为：n 在系统使用过程中根据IT部门提供的模板编写系统改进意见、系统缺陷等维护类需求，或者是为满足工作需要而提出的新需求等201、。29.9.2 需求归口管理人需求归口管理人是需求提出人所对应的归口管理部门的人员。其主要职责为：n 负责需求的初步分析，对需求进行分类和进行。n 决定是否同意将需求提交到IT部门。29.9.3 需求联系人需求联系人是IT部门的成员，也称需求管理联系人。其主要职责为：n 负责需求的收集、整理分类、归并、优先级排序等管理工作，并对需求的规范性进行初步审核。n 负责IT系统需求文档的归档和版本管理工作。n 负责制定需求文档模板并推广其应用。n 在需求被实现后，通知需求提出人。29.9.4 需求分析人员需求分析人员是IT部门的成员，负责接收需求联系人提交的需求，编制IT支撑方案，并对需求的可行性进行202、分析。其主要职责为：n 会同业务部门进行需求的详细分类、整理、归并等分析工作，并编写需求规格说明书书。n 给出需求的初步实现方案，分析技术和经济的可行性。n 给出实现需求的工期概算、工作量概算等。n 给出需求的实现方式建议，实现方式可以是维护类需求、工程类需求、应急工程类需求或者进入滚动规划的需求等。29.9.5 需求经理需求经理是IT部门的成员，负责需求审批。其主要职责为：n 负责需求相关的决策。n 负责协调处理IT需求管理过程中的争议。30 变更管理流程30.1 流程定义变更管理负责业务需求单、系统变更单的具体实施落实，包括变更方案、进度计划的制定、变更的审批、变更的实施准备（工程采购、软203、件开发等）、实施方案制定及审批、软件版本管理、验证测试等工作，其中工程建设类变更和维护类变更通过发布与部署管理完成变更到实际生产环境的部署。通过对系统变更的控制，降低变更实施风险，提高系统稳定性。典型的变更如新功能开发、软件版本升级、硬件扩容、系统核心参数修改等。非生产状态的IT环境的变更不在变更管理的范围。一个业务需求单可能对应多个系统的变更单。30.2 流程目标变更管理流程将通过标准、统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。主要的目标包括：n 控制所有变更对服务能力造成的风险和影响。n 对客户的需求做出有效响应，提高业务支持的能力。 n 确保变更内容与进入变更管理流程的204、需求单相符合。n 通过严格的变更控制过程，尽可能减少不当变更造成的事件。n 变更实施过程得到正确记录，满足审核和统计的管理要求。n 通过有效管理变更过程，提高IT资源使用率。n 通过对所有变更的正确评估，可以维护IT生产环境的完整性。30.3 流程执行原则30.3.1 一般原则n 所有影响生产环境配置项的变更都必须严格遵循变更管理流程。n 所有的变更请求记录以及实施过程都可记录、可追踪。n 应定期产生变更管理报表，对失败的变更和风险等级重大的变更进行回顾和检查，以更好地管理变更流程。n 应定期对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进变更管理流程。205、30.3.2 变更分类执行原则n 标准变更采用预授权的方式，由变更主管直接安排实施，并通告变更经理。n 维护类变更以及工程建设类变更由变更经理总体负责，通过与各相关方面协同，采取多种方式（例如CAB会议），严格管理其计划、评估、审批、测试、实施。n 工程建设类变更需要对工程可研方案书、工程技术方案书以及工程合同进行管控。n 紧急变更提供变更快速实施处理的机制。30.3.3 变更审批原则n 变更经理负责审批风险等级为中和低的变更；n 变更管理委员会负责审批风险等级为高和重大的变更，建议变更主管参加变更管理委员会会议；n 紧急变更管理委员会负责审批紧急变更。30.3.4 变更通知原则对现有业务系统206、产生影响的变更，例如因实施变更而需要停机或者中止业务，均需在变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告。30.3.5 紧急变更处理原则n 紧急变更必须通过E-MAIL等书面方式申请，在得到紧急变更管理委员会审批通过后方可执行变更操作。n 紧急变更应快速制定变更计划，快速审批并进行必要的评估。一般来说紧急变更实施前需进行必要的测试，测试包含完整的测试用例，测试成功后方可在生产环境进行变更，但针对部分紧急程度很高的变更，因时间紧迫而无法完成的测试应在变更实施后安排补测。n 紧急变更管理委员会（ECAB）成员一般为公司领导、部门领导、各级主管等管理层人员，为了提高207、执行效率，需要事先制定紧急变更管理委员会的人员；n 紧急变更应越少越好，因为它们对业务的影响很大，而且有很高的失败风险，非必要情况下应尽量减少紧急变更的次数。30.3.6 变更测试原则n 对生产系统进行变更时，需根据变更的性质、影响面等情况在变更请求单中选择是否需要在测试环境进行测试。如果需要，则按照测试计划进行测试，测试后需由相关测试人员确认并提供测试报告。30.3.7 变更文档控制原则n 变更计划通常包括实施计划、测试计划、回退计划、配置项更新计划等；n 对应用软件版本上线类的变更，除变更计划外，还需包括变更功能说明文档、变更技术说明文档、包含完整测试用例的测试文档，并提供由执行测试人员确208、认的测试报告。n 对数据迁移类的变更，除变更计划外，还需包括转换方案，该方案一般包含数据转换策略、数据转换测试、数据备份及恢复方案、数据转换结果核对等方面的内容。30.4 与其它流程的关系图表 055 变更管理流程与其他流程的关系n 需求管理流程：需求管理流程中的需求是通过变更管理流程来实现的，需求管理流程为变更流程提供变更实现的时间表。n IT服务规划管理流程：IT服务规划中已经完成需求分析部分的需求，直接通过变更管理落实滚动规划。n 事件管理流程：事件的解决如果引起配置项的变更则需要触发变更管理流程来实现，变更成功实施后应当通知事件管理流程。n 问题管理流程：问题管理流程中对于错误的修正如209、果要引起配置项的变更，则需要触发变更管理流程，变更成功实施后应当通知问题管理流程。n 资产与配置管理流程：变更管理涉及到的配置改变应当在IT服务管理系统中得到体现，改变的数据可能包括配置项、配置项间的关系或配置项的某些属性。变更的评估需要从IT服务管理系统中获取相关的信息进行分析。n 测试管理流程：在变更管理流程中，要对完成的变更进行测试。通过向测试管理流程提交测试申请单来触发测试管理流程。在完成测试后，测试结果反馈给变更管理相关人员。n 发布与部署管理流程：变更计划实施的过程中，工程建设类变更以及维护类变更会触发发布与部署管理流程，如果发布与部署管理流程是由变更管理流程触发，则发布记录必须与210、变更记录相关联。n 接入管理流程：如果变更导致IT用户的权限变化，则触发接入管理的权限变更流程，根据变更的具体情况调整IT用户的访问权限。30.5 流程说明30.5.1 一级流程30.5.1.1 流程图图表 056 变更管理一级流程30.5.1.2 主要活动说明序号步骤名称责任人说明1变更申请变更申请人、变更主管q 变更申请人根据需求管理流程、IT服务规划流程、事件管理流程、问题管理流程、资产与配置管理流程、接入管理流程提出的变更请求，完善变更请求信息，跟相关部门或用户确认。q 创建变更申请单并保证变更信息项的完整性和正确性。q 针对变更申请单进行初步分析，确定是否需要进行变更分解操作。q 根211、据变更申请单的类别，确定变更申请单需要流转的路径。2变更计划和方案制定变更主管、变更执行人q 对于工程建设类变更，变更主管负责召集相关部门或厂商进行可研或委托可研完成细化可行性报告提交CAB进行立项审核。q 维护类变更以及标准变更，变更主管以及变更执行人需制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等（包括实施步骤、实施延续的时间、恢复计划、实施的人员安排、通告等）。q 变更方案要求有详细的操作命令，并包括实施变更的具体时间、实施步骤、实施人员安排、恢复计划、通告等。q 紧急变更由于变更时间紧迫需快速制定紧急变更计划和方案。3变更审批变更经理、变更管理委员会q 工程建设类变更212、，变更经理接收变更主管提交的可研结果进行立项审批，审批通过后进入招标阶段，对立项文档进行整理并归档。q 维护类变更，变更经理审阅所有提交的计划，包括实施计划、测试报告、回退计划、配置项更新计划等q 变更经理可以做出驳回或批准的意见需经过变更经理审批。q 对应用系统业务影响较大的重要变更需经过变更管理委员会的审批通过q 标准变更经过变更经理的预授权可直接进行变更实施。q 对应用系统业务影响较大的重大变更需经过变更委员会审批通过。q 紧急变更，需通过E-MAIL等书面方式申请，经过紧急变更管理委员会快速审批通过。4变更准备变更主管、变更执行人q 工程建设类变更需编写技术方案书并通过审批，经过招标、213、确认供应商并签订合同、合同采购等前期工程管理方面的准备，对相关文档进行整理并归档。q 工程建设类变更以及维护类变更需进行日程排定、软硬件实施准备等变更实施计划。q 工程建设类变更以及维护类变更在变更实施前应进行充分的测试，测试通过后由发布与部署管理流程来实施变更。q 紧急变更需快速制定紧急实施计划、测试计划、以及回退计划等。5实施审批变更经理- 标准变更在实施前需经过变更经理的审批。q 变更经理可以做出驳回或批准的意见。6变更实施变更主管、变更执行人q 变更主管监控整个变更实施过程。q 标准变更在对变更实施成功完成后调用资产与配置管理流程更新对应的配置项。q 必要时启动变更回退计划。q 实施完214、成后，通知变更主管，变更主管需填写由该变更所引起业务中断的关键系统名称和中断时长。q 工程建设类变更以及维护类变更在变更实施过程应走发布与部署管理流程。7变更回顾和关闭变更主管、变更经理、变更管理委员会q 变更发布完成后应对资产与配置管理项进行审查，对于配置项没有正确更新的，必须走资产与配置管理流程来更新配置项。q 变更成功后需通知变更申请人，返回变更结果。q 定期对变更管理流程进行回顾总结。q 变更主管负责将回顾结果更新到变更记录中。表格 061 变更管理流程活动说明30.5.1.3 流程输出n 标准变更：变更计划书、变更转换方案书、回退计划书、变更回顾报告等。n 维护类变更：变更计划书、变215、更功能说明书、变更技术方案书、测试计划书、测试方案书、测试报告、回退计划书、变更回顾报告、应用软件版本等。n 工程建设类变更：工程可研报告书、工程技术方案书、工程合同、工程计划书、应急方案书、测试计划书、测试方案书、测试报告、使用说明书、应用软件版本等。n 紧急变更：紧急变更计划书、测试计划书、测试报告、回退计划书等。30.5.2 二级流程图表 057 变更管理二级流程30.5.3 泳道图图表 058 变更管理二级流程泳道图30.5.3.1 变更申请图表 059 变更申请泳道图30.5.3.2 变更计划与方案制定图表 060 变更计划与方案制定泳道图30.5.3.3 变更审批图表 061 变更216、审批泳道图30.5.3.4 变更准备图表 062 变更准备泳道图30.5.3.5 实施审批图表 063 实施审批泳道图30.5.3.6 变更实施图表 064 变更实施泳道图30.5.3.7 变更回顾与关闭图表 065 变更回顾与关闭泳道图30.6 关键管控点序号重点内容类别1省公司进行流程角色设置时，必须设置变更管理流程负责人、变更请求人、变更主管、变更经理、变更执行人、变更管理委员会、紧急变更管理委员会等角色。角色的职责按照规范规定不能进行合并、修改、删除等操作，但可以根据需要进行扩充。组织及人员要求2变更管理委员会以及紧急变更管理委员会由变更经理领导和主持，成员主要由各相关领域的领导、各个217、IT维护小组的资深人员或者组长组成。3变更管理流程必须设置流程经理角色，负责对整个流程进行管控。4所有影响生产环境配置项的变更都必须严格遵循变更管理流程。关键管控点5所有的变更请求记录以及实施过程必须可记录、可追踪。6当变更对现有业务系统产生影响时，必须在变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告。7进行变更控制的时候，必须考虑回退及应急计划，一但变更失败可以通过回退或应急操作降低对生产环境的影响。8必须支持紧急变更处理流程，紧急变更流程和普通变更处理类似，但在审批环节会做简化，以提高响应速度。紧急变更管理委员会负责审批紧急变更。9变更经理负责审批风险等级为218、中和低的变更。10变更管理委员会负责审批风险等级为高和重大的变更，变更主管必须参加变更管理委员会。11紧急变更管理委员会负责审批紧急变更。12由于一个需求单可能涉及到多个业务系统功能的变更，因此变更管理流程必须支持对需求单进行拆分的功能。13工程建设类变更必须对工程可研方案书、工程技术方案书以及工程合同进行管控。14工程项目类变更和维护类变更必须通过发布与部署管理流程来实施和控制，发布与部署管理流程将发布结果反馈变更管理。15工程项目类变更和维护类变更在发布前必须在测试环境上进行测试，测试后需由相关测试人员确认并提供测试报告16变更实施环节中涉及到要更新配置信息，必须调用资产与配置管理流程。1219、7变更单必须保存如下信息：变更ID、登记时间、请求人信息、变更标题、变更来源、来源工单号、变更分类、所属系统类型、变更重要等级、变更描述、所影响的应用系统及部门、变更状态、变更主管、变更主管接受变更时间、变更计划、计划开始时间、计划完成时间、变更审批记录、实际开始时间、实际完成时间、变更观察记录、变更是否中断业务、业务中断时长、回顾意见、回顾代码、变更结束代码、关闭人、关闭时间、关联的发布单号。关键信息要求表格 062 关键控制点说明30.7 主要相关数据说明30.7.1 变更信息项变更单包含如下变更信息项：序号信息项描述1变更ID为每个变更请求分配一个唯一的序列号 2登记时间变更请求登记的时220、间 3请求人信息系统自动记录实际变更请求人的信息，包括：姓名、省/分公司、部门、联系方式等4变更标题简单描述变更请求（手工填写）5变更来源参见“变更来源”定义6来源工单号变更来源所关联的工单号7变更分类参见“变更分类”定义8所属系统类型参见“所属系统类型”定义9变更重要等级参见“变更重要等级”定义10变更描述详细描述变更的内容（手工填写）11所影响的应用系统、部门实施该变更将对哪些应用、部门产生影响，用于评估变更12变更状态参见“变更状态”定义13变更主管变更主管姓名14变更主管接受变更时间变更主管接受变更请求的时间15 变更计划使用附件形式。变更计划通常包括变更的实施计划、测试计划、回退计划221、配置项更新计划等 16计划开始时间变更计划开始时间 YYYY-MM-DD HH:MM 17计划完成时间变更计划完成时间YYYY-MM-DD HH:MM 18变更审批记录记录变更审批的历史记录，包括如下信息：审批人姓名、审批结果、原因、时间等 19实际开始时间变更实际开始时间YYYY-MM-DD HH:MM 20实际完成时间变更实际完成时间YYYY-MM-DD HH:MM 21变更观察记录描述变更结束后，观察期间的情况 22变更是否中断业务参见“变更是否中断业务”定义23业务中断时长造成相关业务计划外中断的时间长度(分钟，手工填写)24回顾意见变更委员会对变更进行回顾后得出的意见（手工填写）2222、5回顾代码参见“回顾代码”定义26变更结束代码参见“变更结束代码”定义27关闭人关闭人信息28关闭时间变更关闭的时间，关闭人手工填写。YYYY-MM-DD HH:MM29关联的发布单号如果变更触发发布与部署管理流程，则记录相应的发布单号表格 063 变更信息项说明30.7.2 变更来源变更来源代码用来标明变更的输入来源，变更来源可以包括以下几种：编码代码描述10需求管理11IT服务规划管理12事件管理13问题管理14资产与配置管理15接入管理16其他表格 064 变更来源说明30.7.3 变更分类编码变更分类描述10标准变更11工程建设类变更12维护类变更13紧急变更表格 065 变更分类说明223、30.7.4 所属系统类型见事件管理流程。30.7.5 变更重要等级变更重要等级包括以下几种：编码代码描述10重大11高12中13低表格 066 变更重要等级说明30.7.6 变更状态变更从提出到最后被关闭，会历经各个阶段。变更处于不同的处理阶段具有不同的状态，需要不同的角色参与。以下是变更请求从提出、实施到结束的整个生命周期中的不同状态：编码代码描述1已登记变更请求已登记入系统，变更主管还未受理。2计划中变更主管对变更进行规划，检验变更单的分类和信息是否正确，提交必要的变更文档。3等待审批变更请求提交给变更经理或变更委员会、或集团公司等待审批4已批准变更单得到批准（或简单变更预先批准）。5处224、理中变更主管在此状态下，进行任务的创建、分发，变更实施者实施变更。6已完成变更实施完成，进入观察期。7关闭变更关闭，关闭变更时需指定关闭代码（成功，失败，已取消）。表格 067 变更状态说明30.7.7 变更是否中断业务变更可能会引起业务中断，需要在变更评估时加以说明：编码代码描述10是变更会引起业务中断。11否变更不会引起业务中断。表格 068 变更是否中断业务源说明30.7.8 回顾代码回顾代码用于描述变更计划和实施过程的质量，以便更好地改善未来的变更。编码代码描述10实施正常变更实施计划、操作没有问题。11计划不全变更实施计划有缺陷，不完善。12实施操作有误变更实施人员在实施过程中操作有225、误。13不可预料情况其他不可预料的意外情况，如系统突然无法启动。表格 069 回顾代码说明30.7.9 变更结束代码变更结束代码用来描述其完结时的不同状态。编码代码描述10成功变更成功完成。11失败变更不成功，执行了回退计划。12已取消变更因为各种原因被取消。表格 070 变更结束代码源说明30.7.10 变更实施单信息项序号信息项描述1实施单ID为每个变更实施单分派一个唯一的序列号（系统自动产生）。2变更请求单号该变更实施单所属的变更请求单号，来源于变更信息项（系统自动关联）。3标题简单描述变更请求，来源于变更信息项。4实施内容描述变更实施的内容（手工填写）。5关联的配置项关联的配置项（手工226、关联）。6记录登记时间变更实施单创建的时间（系统自动产生）。7实施单状态该变更实施单的状态，由各省自行定义。8实施人员信息姓名、手机、办公电话、邮件地址、联系方式、地域、机构、部门 （手工填写）。9核查人信息姓名、手机、办公电话、邮件地址、联系方式、地域、机构、部门（手工填写）。10计划开始时间该实施单的计划开始时间（手工填写）。11计划完成时间该实施单的计划完成时间（手工填写）。12实际开始时间该实施单的实际开始时间（手工填写）。13实际完成时间该实施单的实际完成时间（手工填写）。14实施任务记录实施任务的工作日志、系统日志（手工填写）。15核查结论实施任务的核查结论（手工填写）。表格 07227、1 变更实施单信息说明30.8 流程相关指标为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。序号衡量指标指标计算1新增的每一变更分类的变更总量每一变更分类的【登记时间】在统计时间区间内的变更数量。2新增的每一重要等级的变更数量每一重要等级的【登记时间】在统计时间区间内的变更数量。3变更实施失败的数量【变更结束代码】=失败 and 【关闭时间】在统计时间区间内的变更数量。4变更实施成功的数量【变更结束代码】=成功 and 【关闭时间】在统计时间区间内的变更数量。5被取消的变更数量【变更结束代码】=已取消 and 【关闭时间】在统计时间区间内228、的变更数量。6计划内业务中断时长【变更状态】=已完成 and 【实际完成时间】在统计时间区间内的【中断时长】。表格 072 流程相关指标说明30.9 角色及职责说明变更管理流程应设置的角色为：变更请求人、变更经理、变更主管、变更执行人、变更管理委员会、紧急变更管理委员会。以下描述每个角色的职责。30.9.1 变更请求人根据工作的需要，发起变更请求的IT人员。其职责包括： n 必要时提出变更申请，创建RFC，并提交给相关技术领域的变更执行人。n 在变更处理过程中提供必要的信息。30.9.2 变更经理全面负责变更管理流程中的所有具体活动执行和审批，严格控制相应的控制点，保证变更按照变化有序高效的执229、行，通常由具有决策权的人员担任。其职责包括：n 帮助变更执行人协调必要的变更时间、人员等方面的协调工作。n 审批变更请求，确保只有授权和必要的变更才被实行，并使该变更影响最小化。n 成立变更管理委员会，并领导和主持变更管理委员会。n 定期召开变更会议，回顾变更。n 参与流程评估，对流程改进提出意见和建议，与流程负责人共同制定流程改进建议。30.9.3 变更主管 变更主管通常由与变更请求内容相关的具体技术领域的负责人或直接变更处理人担任。可以根据不同的变更种类，分派不同的人员作为变更主管。变更主管主要对技术方案的制定和实现负责。其职责包括：n 检查由变更申请人提交的每一个变更请求RFC，检查变更230、的正确性和必要性，必要时拒绝无关、无法实施或没有必要的变更请求。n 确定和检查RFC的分类、变更时间要求、分析风险等。n 作为具体变更的项目经理，负责领导变更的构建测试，实施和参与回顾。n 制定变更实施计划、测试计划、回退计划等。n 针对具体变更请求，评估并分派相应资源。n 确保变更在预定的时间，资源和成本内完成。n 在必要时，确保回退计划得以正确实。n 负责收集与该变更有关的部门或小组的意见，综合变更对于应用的影响。30.9.4 变更执行人变更执行人负责变更在生产环境中的实施，实际情况下现场厂商经常参与变更实施过程。其责任包括：n 协助变更主管制定变更实施方案、变更实施计划。n 记录变更实施231、相关的信息，确保文档的完整性。n 负责实施和测试。n 变更完成后，进行监控，并记录监控结果。n 与变更主管沟通，通报变更实施的进度和结果。30.9.5 变更管理委员会变更管理委员会是IT组织中对重大变更进行评估和批准或者拒绝某个变更请求的虚拟组织，帮助变更经理进行变更决策。其职责包括：n 针对具体变更请求，评估潜在影响和风险。n 协助变更经理对变更做出审批、决策。n 参加变更管理委员会会议。n 回顾失败的变更，以确保今后不再发生类似情形。n 回顾已成功执行的重大变更，确保满足变更的目的。n 对流程改进提出意见和建议。变更管理委员会的组成人员：n 变更管理委员会是由各省企业信息化事业部的管理人员232、组成的虚拟小组。主要由各相关领域的领导、各个IT维护小组的资深人员或者组长组成，有时也会包括发起变更请求的业务部门的代表、第三方厂商集成商等参与。变更管理委员会应当由该专业有较高技能的人员组成，同时，这些成员对于业务需求、业务逻辑、IT系统技术、应用开发、测试、支持等方面也较为熟悉，帮助变更经理对变更审批、决策、评审等重要环节提出意见。 30.9.6 紧急变更管理委员会紧急变更管理委员会是IT组织中对紧急变更进行评估和批准或者拒绝某个变更请求的虚拟组织，帮助变更经理决策管理变更。其职责包括：n 针对具体紧急变更请求，评估潜在影响和风险。n 协助变更经理对紧急变更做出快速审批、决策。n 参加紧急233、变更委员会会议。n 回顾失败的紧急变更，以确保今后不再发生类似情形。n 回顾已成功执行的紧急变更，确保满足紧急变更的目的。n 对流程改进提出意见和建议。n 紧急变更管理委员会的组成人员同变更管理委员会。31 发布与部署管理流程31.1 流程定义发布与部署管理负责将通过测试验证后的变更按业务需要及技术要求、发布策略限制分批部署到生产环境，它包括发布包的设计、发布包的组建、发布包的测试、用户培训的组织、发布的业务准备、实际部署后的验证测试以及IT资源配置状态的更新等环节。通过发布管理，确保对生产环境的变更得到有效控制，提高生产环境稳定性。一个发布包可以包括对多个系统的变更。31.2 流程目标n 确234、保正在对其进行改动的硬件和软件是可跟踪的、安全的，发布包所包含的发布项内容是兼容的，而且已安装的版本都是正确的、经过授权和经过测试的。n 确保将所有软件的主副本保存在最终软件库 (DSL)中，并确保通过资产与配置管理对配置数据进行更新。n 避免或降低发布可能带来对风险、问题和影响，并具备解决问题的方案。n 确保发布完成后，将新的服务相关的技术能力和业务能力知识转移给运维人员。31.3 流程执行原则31.3.1 流程一般原则n 所有工程类和维护类的变更都必须严格遵循发布与部署管理流程，更新的版本都是正确的、经过授权和测试的。n 所有发布执行工作都应被记录并可追踪。n 定期产生发布流程管理报表，对235、失败的发布进行回顾和检查，以更好地管理发布流程。n 定期对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进发布与部署管理流程。n 核心系统发布执行人和开发人员不应为同一人。31.3.2 发布优先原则n 来源于紧急变更的发布请求优先等级应放最高。n 发布项上线的优先等级应主要参考需求流程中IT部门和需求提出部门协定的上线时间点，通常情况下应在该时间点前完成上线。如有延迟需写明原因。31.3.3 发布通知原则n 每次发布都需要提前编写发布公告，提前告知业务人员和技术人员相关的业务变动，功能变动情况，并写明预计发布时间，发布结束后需再次通告。31.3.4 DSL236、管理控制原则n 发布管理确保所发布内容在DSL中得到及时更新。n 变更测试与审批通过后，相关人员需要将发布包组件存入DSL库中保存。发布执行人只能从DSL库中获取发布包组件构建发布包，并在DSL库里保存版本信息。发布包测试结束后，可根据发布包修改DSL库。只能从DSL库里获取发布包来更新生产环境。n 在DSL（最终软件库）中存储了软件配置最新发布版本；实施回退计划的原版本；以及历次发布的所有历史版本。包括软件原代码、发布输出文档，如：发布计划，发布手册。n DSL由软件控制主管进行严格管理，主要内容包括软件出入库、使用申请、更换等，并保证DSL中的软件记录与IT服务管理系统信息保持一致。n D237、SL中的软件版本管理可以由专业的软件开发配置管理软件来实现。n 定期核查DSL记录，进行历史版本软件源码与实施记录的一致性与完整性检查。31.3.5 发布上线审批拒绝原则如果一个发布请求被拒绝，应当通过变更管理流程来重新安排。被拒绝的发布请求应当作为失败发布。31.3.6 发布上线审批升级原则遵照发布策略指导，发布上线一般由发布经理决策。对于重大发布，在发布经理审批通过后提交省公司领导审批，由省公司领导考虑发布的合理性和上线时间要求。如果发布内容和集团存在重大联系，则在省公司领导审批通过后，还需要上报集团相关负责人审批，审批通过后才可以执行发布。31.3.7 发布时间窗口原则发布频率为每周或半238、月执行一次（发布频率不宜太高）。紧急变更导致的发布可以由发布申请人向发布经理申请额外的发布时间窗口。发布时间为营业下班后开始，营业上班前结束。为了保证发布流程中的测试、培训、通知等环节得到有效执行，重大发布请求至少在期望上线日1个月前提交。31.3.8 发布执行原则 发布执行人获取发布包必须从DSL库里获取；发布必须严格遵守发布操作手册执行；发布失败则需按照回退计划执行回退；发布完成后，发布执行人需要进行生产环境的发布验证测试；确认发布完成后，编写发布公告。31.4 与其它流程的关系图表 066：发布与部署管理与其他流程的关系关系n 变更管理变更管理通过发布流程实现变更内容在生产环境中的部署上239、线，同时发布流程为变更流程提供变更实施时间表。变更具备上线条件后，如果需要启动发布来实施这个变更，则向发布与部署管理流程提交发布申请工作单，在发布管理完成整个发布过程后，再回到变更管理流程，继续变更过程的回顾。n 资产与配置管理发布管理启动资产与配置管理更新配置项。配置管理提供配置项的属性及配置项之间的关系，支持发布管理的发布计划编写、风险分析。n 测试管理只有测试通过的发布包才具备发布上线的条件。发布管理完成发布包构建后，提交测试请求单，测试管理反馈测试结果，发布管理根据测试结果判断是否具备上线条件。n 知识管理通过发布管理，成功发布的解决方案，要纳入知识库中。n 作业计划在发布管理中提供新240、的IT服务时，应及时制定或更新作业计划，对新的IT服务提供日常运维保障。31.5 流程说明31.5.1 一级流程31.5.1.1 流程图图表 067-发布与部署管理一级流程31.5.1.2 主要活动说明序号步骤名称责任人说明1发布策略发布经理、IT部门经理q 发布策略是一个独立的流程，主要职能是制定省公司发布策略与原则，内容至少包括：发布时间窗口策略、DSL管理策略、发布执行策略、发布审批升级策略。q 发布时间窗口策略：确定发布频率，发布时间窗口，申请额外发布时间窗口条件。q DSL管理策略：保存发布包组件、发布包最终版本、可回退的原始版本。q 发布执行策略：必须经过发布上线授权才可执行发布，241、发布执行与回退严格遵照发布操作手册和回退计划执行。q 发布审批升级策略：定义重大发布评判原则，定义上报集团审批评判原则。2发布计划制定发布经理、发布执行人q 根据变更管理确定的发布版本和发布时间初步确定并记录本次发布内容项单，发布时间确定主要依据需求管理与业务部门商定的上线时间要求。q 分析本次发布内容项清单，获取配置管理发布相关配置项以及配置项间关联影响分析，并根据变更提供变更间关联关系（如：多系统同时发布，代码更新先后关系等）分析发布项业务影响。q 根据发布影响分析制定发布计划，内容包括：需求资源计划、数据备份计划 、验证测试计划、制定回退计划、编制发布操作手册、制定培训计划。q 发布计划242、需要发布经理审核，常规发布计划审批可进行预授权。3发布包构建发布执行人q 从DSL中获取发布包组件。q 完成发布包构建存放在DSL确定版本，根据关联关系确认发布顺序。4发布包测试发布执行人q 提交测试请求。q 接收测试管理测试报告，判断发布内容项是否满足上线要求。5上线审批发布执行人、发布经理、省公司领导、集团相关负责人q 上线审批，根据发布计划审批结果，测试结果，业务影响分析判断发布内容是否具备上线条件，如审批不通过，需写明原因。q 审批按照发布审批升级策略定义的不同的发布级别，逐级审批，包括发布经理审批，省公司领导审批，集团相关负责人审批。6发布执行发布执行人q 执行生产环境上线发布必须从243、DSL中获取发布包，并执行软件备份。q 发布执行需严格按照发布操作手册。q 发布完成需要进行生产环境发布验证测试。q 发布失败且不可修复，需按照回退计划执行回退。q 发布执行前需进行发布公告，告知相关人员发布范围，发布影响。q 发布结束后需再次公告。7发布回顾与关闭发布执行人q 检查介质库版本信息。q 检查发布计划，发布操作手册，测试报告等，进行文档归档。表格 073 发布与部署管理流程活动说明31.5.1.3 流程输出发布策略输出：发布时间窗口策略、DSL管理策略、发布执行策略、发布审批升级策略。发布计划输出：需求资源计划、数据备份计划、验证测试计划、制定回退计划、编制发布操作手册、制定培训244、计划。发布包构建输出：发布包、包括发布包、发布包版本信息、发布操作手册。发布执行输出：发布公告、发布执行结果。31.5.2 二级流程31.5.2.1 流程图图表 068发布与部署管理二级流程31.5.2.2 流程泳道图发布与部署管理流程图描述的是一个最完整的场景。省公司在系统落地时可根据发布内容的实际需要省去部分环节。如：硬件的变更发布计划不用象工程项目建设一样复杂，可省略发布包构建、发布包测试两个环节，发布包执行可省略下发发布包、组织培训等活动，发布关闭可省略软件版本审查、实施及帐号回收，数据补丁可简化发布计划，可省略发布包测试环节，发布关闭可省略软件版本审核、实施及测试帐号回收等活动。图表245、 069发布与部署管理二级流程泳道图31.5.2.2.1 发布策略图表 070发布策略31.5.2.2.2 发布计划制定图表 071发布计划制定31.5.2.2.3 发布包构建图表 072发布包构建31.5.2.2.4 发布包测试图表 073发布包测试31.5.2.2.5 上线审核图表 074上线审核31.5.2.2.6 发布执行图表 075发布执行31.5.2.2.7 发布关闭图表 076发布关闭31.6 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设置发布执行人、发布经理、IT部门领导、省公司领导、集团相关负责人。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要246、求2所有发布必须由变更流程启动。关键管控点3发布必须在发布时间窗口内执行。4需控制发布频率，非常规发布更应控制在较低比例。5软件版本发布在制定发布计划时必须编写回退计划，作为发布资料存放在DSL中。6每次发布都需要提前编写发布公告，提前告知业务人员、技术人员业务变动。7所有发布必须发布测试通过才可以进行上线审核。8所有发布必须经过上线审批才能执行。9发布管理确保所发布内容在DSL中得到及时更新,发布执行从DSL中获取发布包。10用户能够通过web方式上报发布请求、能够查询自己的发布处理状态。11发布执行需要将知识转交运维。12发布与部署管理过程必须保存如下信息：发布标题、关联的变更号、发布来源247、发布类型、发布是否中断业务、发布状态、发布结束代码、风险等级、发布影响、发布审批记录、是否需要用户测试、实际完成时间、测试结果。关键信息要求表格 074 关键控制点说明31.7 主要相关数据说明31.7.1 发布信息发布信息项举例：序号信息项描述1发布ID为每个发布请求分配一个唯一的序列号 。2登记时间发布请求创建的时间 。3请求人信息系统记录发布请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机。4发布标题简单描述发布请求。5关联的变更号变更流水号（ID）。6发布来源参见“发布来源”定义。7发布类型参见“发布类型”定义。8发布是否中断业务参见“发布是否中断业务”定义。9是248、否需要用户测试参见“是否需要用户测试”定义。10测试结果参见“测试结果”定义。11发布状态参见“发布状态”定义。12发布结束代码参见“发布结束代码”定义。13风险等级高、中、低、重大，参考变更“风险等级”定义，一个发布包含多个变更则风险等级取包含变更的最高风险等级。14发布影响实施该发布将对哪些业务应用、部门产生影响，用于评估发布。15 发布计划使用附件形式。发布计划通常包括发布的培训计划、测试计划、回退计划、发布操作手册等。16预计开始时间发布预计开始时间 YYYY-MM-DD HH:MM。 17预计完成时间发布预计完成时间YYYY-MM-DD HH:MM。 18发布审批记录记录发布审批的历249、史记录，包括如下信息：审批人姓名、审批结果、原因、时间等（包括变更请求审批记录和发布实施审批记录）。19实际开始时间发布实际开始时间YYYY-MM-DD HH:MM。 20发布实施记录用于描述实施时的现场情况。 21是否需要用户测试参考“是否需要用户测试”。22测试结果记录测试管理反馈的测试结果。23实际完成时间发布实际完成时间YYYY-MM-DD HH:MM。 24备注留用 表格 075 发布信息项说明31.7.2 发布来源编码代码描述10维护类变更由于维护类变更所发起的发布。11项目类变更由于新项目上线引发的变更所触发的发布。表格 076 发布来源说明31.7.3 发布类型编码代码描述10250、新系统上线新系统所有组件及功能的发布方式。11单项升级对某系统单项功能进行升级的发布实施方式。12包升级对一组相关系统的一组功能进行升级的发布实施方式。13数据补丁对某系统打数据补丁。表格 077 发布类型说明31.7.4 是否常规发布编码代码描述10是在正常发布时间窗口执行的发布。11否通过额外发布时间窗口审批执行的发布。表格 078 是否常规发布说明31.7.5 发布是否中断业务编码代码描述10是营业时间进行发布导致业务无法正常受理，定义为业务中断。11否发布不会引起业务中断。表格 079 发布是否中断业务说明31.7.6 是否需要用户测试编码代码描述10需要需要用户测试。11不需不需要用251、户测试。表格 080 是否需要用户测试说明31.7.7 测试结果编码代码描述10通过测试通过。11未通过测试失败。表格 081 测试结果说明31.7.8 发布状态发布从被发布经理接受到最后被关闭，会历经各个阶段。发布处于不同的处理阶段具有不同的状态，需要不同的角色参与。以下是发布请求从接受、计划到结束的整个生命周期中的不同状态：编码代码描述1新建新建发布请求。2制定发布计划制定发布计划。3申请发布计划审批提交发布经理进行发布计划审批。4构建发布包获取发布包组件，构建发布包。5测试请求进行测试管理申请请求。6发布上线审批提交发布经理进行上线审批。7省公司领导审批重大发布提交省公司领导进行上线审批252、。8集团相关负责人审批重大发布且与集团关系密切提交集团相关负责人审批。9发布执行发布流程经理已审批按计划发布至测试环境。10发布关闭完成发布回顾发布关闭。表格 082 发布状态说明31.7.9 发布结束代码发布结束代码用来描述其完结时的不同状态。编码代码描述10成功发布成功完成。11失败发布不成功，执行了回退计划或被拒绝。表格 083 发布结束代码说明31.8 流程相关指标为了较好地控制流程的质量，必须为流程设置衡量指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。发布与部署管理流程的主要衡量指标如下：序号衡量指标指标计算1各类型的发布数量每一类发布在统计时间区间内的发布数量。253、2各风险等级的发布数量每一类风险在统计时间区间内的发布数量。3发布实施成功的数量4发布实施失败的数量5发布包返工数量生产环境发布出现问题返工后发布成功的发布数量。6非常规发布数量是否常规发布代码为“否”在统计时间区间内的发布数量。表格 084 流程相关指标说明31.9 角色及职责说明流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员赋予不同的角色，也可能一个人被赋予多个角色，同时某一角色的人员也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的流程角色在具体的实现中可以有足够的灵活性。发布与部署管理流程254、建议的角色为：发布请求人、发布执行人，发布经理，IT部门领导、省公司领导、集团相关负责人以下描述每个角色的职责。31.9.1 发布请求人根据工作的需要，发起发布请求的IT人员，主要负责：n 必要时提出发布申请，并提交给相关技术领域的发布执行人。n 提供必要的发布描述信息。n 接收发布关闭信息。31.9.2 发布执行人发布执行人通常包含与发布请求内容相关的具体技术领域的负责人和具体实施执行人。可以根据不同的发布种类，不同阶段，分派不同的人员作为发布执行人。具体实施过程中也可以根据本省需要对发布执行人做进一步职能上的拆分。n 提取本次发布的发布项清单。n 作为具体发布工作的负责人或执行者，负责发布255、计划、割接计划制定以及发布验证的执行确认工作。n 针对具体发布请求，协调相应资源，如：负责与发布相关的软、硬件、人员的上线准备工作。n 确保发布在预定的时间，资源内完成。n 负责收集与该发布有关的部门或小组的意见，综合考虑发布对应用的影响。n 确保发布系统的使用人员与维护人员获取必要知识。n 提供发布系统的使用培训。n 提供发布系统的维护操作培训。n 提供发布系统的服务台培训。n 在培训中收集相关的反馈。31.9.3 发布经理n 发布经理全面负责发布与部署管理流程中的所有具体活动执行，保障所有发布依照预定流程顺利执行。通常由具有决策权的人员担任。n 审核发布项清单确认其正确性和必要性，必要时拒256、绝无关、无法实施或没有必要的发布请求。n 审批发布请求，制定发布周期、进行风险控制，确保被发布的版本都是正确、且通过有效测试。n 确定发布请求分类，指定发布执行人，进行发布工作的总体管理与监控。n 参与流程评估，对流程改进提出意见和建议，与流程负责人共同制定流程改进。n 对发布参与人员工作进行管理与考评。31.9.4 IT部门领导在发布策略里担任发布策略审核角色，发布经理提交的发布策略包括：发布时间窗口策略、发布包存放策略、发布执行策略、发布审核升级策略等。31.9.5 省公司领导根据发布审核申请策略定义的重大发布，需要由发布经理提交省公司领导做审核。n 审核发布请求，确认其正确性和必要性，把257、握重大发布的影响，必要时延缓或拒绝实施风险过大、发布时间不合理、没有发布必要的发布请求。31.9.6 集团相关负责人根据发布审核申请策略定义的重大发布且与集团关系重大，省公司领导审核通过后提交集团相关负责人审核。n 审核发布请求，确认其正确性和必要性，把握重大发布的影响，必要时延缓或拒绝实施风险过大、发布时间不合理、没有发布必要的发布请求。32 测试管理流程32.1 流程定义测试管理流程是对应用系统、IT基础设施进行的功能性和非功能性测试的管理流程。它包括测试请求记录与确认、测试计划制定、测试用例编写、测试准备、测试执行、测试回顾与关闭等管理活动。32.2 流程目标n 测试管理流程的目的是为了258、验证被测试产品是否符合预期目标。n 通过测试管理控制尽可能地发现并记录Bug。32.3 流程执行原则32.3.1 一般原则n 在测试过程中必须严格遵守测试流程，所有的工作都依照测试计划和测试方案进行。n 所有测试工作都应被记录并可追踪。n 定期对测试过程中产生的问题和缺陷进行回顾，并改进测试方法或策略，以更好的管理测试流程。n 测试环境需要从物理和逻辑上与生产环境隔离。n 定期对测试流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进测试管理流程。32.3.2 设计原则n 测试用例编写必须依据通过评审的测试方案中描述的测试需求编写，测试用例必须按照一定规格进行259、编写。n 测试用例必须覆盖所有测试需求，测试用例的测试结果必须是可度量的，清晰的，唯一的。n 测试用例必须明确测试策略。即明确是基于黑盒测试的测试用例还是基于白盒测试的测试用例。n 测试用例只有通过评审才能进入测试执行环节。32.3.3 测试执行原则n 测试执行过程中必须详细记录测试过程中出现的各类缺陷以及测试用例的最终执行结果。n 测试执行完成后必须提交测试报告。测试报告必须明确测试结果是通过还是不通过。32.3.4 测试关闭原则n 测试执行完毕后，测试人员需要提交测试缺陷记录报告、测试执行报告、测试总结报告等内容，测试申请人要对测试结果进行审核。 测试结果评审对测试执行完毕提交的文档进行确260、认。如果符合要求，则关闭测试。 如果测试结果评审确定需要重测，则继续执行测试，同时编写测试文档直到测试被确认完毕为止。 n 已关闭的测试单不允许重开。如果需要再次测试需重新提交一个新的测试申请单。32.4 与其它流程的关系测试管理与其他流程的关系，如图所示：图表 077 测试管理与其他流程的关系n 发布与部署管理流程：在发布管理中，发布包构建完毕后，需要对发布包进行测试。通过提交测试申请单来触发测试管理流程。在测试完成后，将测试结果反馈给相关人员。n 变更管理流程：在变更管理流程中，需要对完成的变更进行测试。通过向测试管理流程提交测试申请单来触发测试管理流程。在完成测试后，将测试结果反馈给变更261、管理中相关人员。n 资产与配置管理流程： 资产与配置管理提供测试管理所需的配置项与IT服务之间的关联查询及影响分析。32.5 流程说明32.5.1 流程说明32.5.2 一级流程32.5.2.1 流程图测试管理一级流程设计如下图：图表 078 测试管理一级流程32.5.2.2 活动说明测试管理一级流程活动说明如下：序号步骤名称责任人说明1测试记录与确认测试主管、测试申请人q 接受测试请求任务，记录测试请求内容。q 明确测试要点，并根据测试要点编写测试场景。q 完成测试内容、测试要点编写后送测试请求人确认。2测试计划制定测试主管、测试经理q 测试计划是对测试全过程的组织、资源、原则等进行规定和约262、束，并制订测试全过程各个阶段的任务以及时间进度安排并对各项任务的评估。q 测试计划制定完毕后，需要通过测试计划评审。q 评审测试计划是主要关注测试范围是否描述清楚、准确；测试资源是否充足，测试工期和进度是否合理；测试风险是否有合理的解决方案。3测试用例编写测试主管、测试执行人q 测试用例编写包括自动化及手工用例，测试用例的内容主要包括测试编号、测试用例所关联业务需求、测试环境、输入数据、测试步骤、预期结果、测试脚本等信息。q 测试用例编写完成后需要通过测试用例评审，测试用例评审时应包括测试用例是否覆盖了所有的测试需求，测试数据设计是否合理有效，测试预期结果是否清晰、准确、可度量。q 生产过程中263、存在测试工作提前量，如：在需求分析阶段已经开始测试用例地编写，则在此环节需核实测试用例合理性、完整性，并将测试用例报告作为附件提交下一环节。4测试准备测试环境管理员q 确认测试环境是否准备完毕。q 根据要求准备发布包。q 进行测试环境部署。5测试执行测试主管、测试执行人q 测试执行是测试执行人员根据测试用例按照预定的步骤执行测试的过程，并且详细的记录测试执行的结果。6测试评审与关闭测试主管q 测试通过评审后，将测试报告反馈测试请求人，关闭测试。q 审核测试是否按要求执行，如发现测试疏漏，则退还测试人员重新测试。q 审核测试报告是否详实，如测试报告不完整，则退还测试人员重新编写。q 测试管理关闭264、条件和测试是否通过无关，关闭的测试的结果可以是测试通过也可以是测试不通过。表格 085 测试管理流程活动说明32.5.2.3 流程输出测试管理流程中主要输出有以下文档：n 测试计划：测试计划对测试全过程的组织、资源、原则等进行规定和约束，制订测试过程各个阶段的任务和时间进度安排，并对各项任务的风险进行评估n 测试方案：测试方案是描述测试的要求、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。n 测试用例：测试用例是为特定目标而设计的一组测试输入、执行条件和预期结果。其目标可以是测试某个程序路径或核实是否满足某个特定的需求。n 测试报告：测试报告是把测试265、的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。32.5.3 二级流程32.5.3.1 流程图图表 079测试管理二级流程32.5.3.2 泳道图图 080 测试管理二级流程泳道图 32.6 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设置测试申请人、测试执行人、测试主管、测试环境管理员、测试经理。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2测试执行前需准备测试用例，测试用例必须覆盖所有测试需求，测试用例的测试结果必须是可度量的，清晰的，唯一的。关键管控点3测试用例评审通过后，才能进入测试的266、执行。4测试执行过程，逐项记录测试结果，所有测试工作都应被记录并可追踪。5测试结束需给出测试是否通过的结论并编写测试报告。6测试管理过程需保留：测试ID、测试类别、测试标题、关联的流水号、测试内容清单与资料、所属系统、测试结果。关键信息要求表格 086 关键控制点说明32.7 主要相关数据说明32.7.1 测试申请单信息项测试申请单的信息项如下，各省可以在此基础上扩充。序号信息项描述1测试ID系统自动生成测试流水号。2测试类别标志测试的类别如：系统集成测试、迁移测试、用户接受测试等。3请求时间系统自动记录请求单创建时间格式为YYYY-MM-DD HH:MM。4请求人信息系统记录发布请求人的信息267、，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机。5测试标题简单描述测试请求 6关联的流水号变更流水号（ID）、发布流水号（ID）。7预计开始时间发布预计开始时间 YYYY-MM-DD HH:MM。 8预计完成时间发布预计完成时间YYYY-MM-DD HH:MM。 9测试内容清单与资料用附件的形式保存。10所属系统见“所属系统”定义。11实际开始时间发布实际开始时间YYYY-MM-DD HH:MM。 12测试结果成功、失败13实际完成时间发布实际完成时间YYYY-MM-DD HH:MM。 14意见测试管理经手人，根据测试情况记录的个人意见。15备注留用。 表格 087 测试申请单信息项268、说明32.7.2 测试用例信息项测试用例的信息项如下，各省可以在此基础上扩充。序号信息项描述1测试用例编号测试用例分配唯一的编号标识。2所属系统见所属系统信息。3计划测试日期发布预计开始时间 YYYY-MM-DD HH:MM 。4需求编号测试用例所对应的需求编号。5业务规则编号主要描述该条测试用例覆盖了测试需求的那些业务。6主题（目录）主要描述在指定系统的那个目录下进行操作该用例。7前置条件说明该用例执行前必须满足的一些约束和假定。8测试概述描述该用例主要实现那个功能。9测试数据列出执行本测试用例所需的具体的每一个输入值。一些输入值可能要由下述的方式描述，如允许一定范围的输入数值要指明公差值，269、引用常量表或事务文件的数据，要指明引用的表或文件的名称。同时，如果输入值用到了相关的数据库、文件、终端显示信息、内存存储区数据，以及操作系统底层传递的数值等也要指明。另外，如果有必要也要说明各输入数值之间的依赖关系（如输入时间先后关系）。10预期结果描述测试项所希望或要求达到的输出或指标（例如系统响应时间）。列出所有预期指标要求下的具体预期输出数值，如需要也要列出描述预期输出数值的允许范围的公差值。11优先级高/一般/低。12重要程度重要/一般。13用例设计人测试用例编写人。14测试用例结果执行结果为：未执行/通过/失败。15 用例性质用例是正用例/反用例。16 用例执行人测试案例执行人。表格270、 088 测试用例信息项说明32.7.3 所属系统所属系统的信息项如下，各省公司可以在此基础上扩充。一级（N1N2）二类（N3N4）编码BSS域（10）CRM系统100110000语音平台1002网上营业厅1003外部客户认证平台1004准实时计费系统1005在线计费系统1006综合结算系统1007统一充值平台1008综合采集预处理系统1009其他1099OSS域（11）综合服务开通系统1101综合服务保障系统1102综合资源管理系统1103网络运维管理系统1104施工调度系统1105综合网络管理系统1106自动激活系统1107专业网络管理系统1108其他1199MSS域（12）OA/企业内部271、门户1201财务管理专业系统1202供应链管理专业系统1203项目管理专业系统1204人力资源管理专业系统1205知识管理1206其他1299EDA域（13）企业数据应用门户1301ODS1302EDW1303其他1399ITOM域（14）IT基础设施监控系统1301应用软件监控系统1402业务数据监控系统1403IT服务管理系统1404其他1499表格 089 所属系统说明32.8 流程相关指标序号衡量指标指标计算1测试用例总量一次测试活动中执行测试用例的总数。2测试用例通过率一次测试活动中测试通过的测试用例和测试用例总数的比率。3平均测试完成时间平均执行一个测试用例所用的时间。4测试用例复272、用率一次测试活动中复用的测试用例占总用例数的百分比。表格 090 流程相关指标说明32.9 角色及职责说明32.9.1 测试申请人在变更过程或者发布过程中有测试要求，接受测试任务请求的人。n 接受测试请求，并且记录测试结果。32.9.2 测试执行人测试人在测试管理中需要执行具体的测试工作n 进行具体测试场景、测试用例编写。n 执行具体的测试工作。n 记录测试结果和测试缺陷，生成测试报告。32.9.3 测试主管测试主管是测试项目的主要负责人，对整个测试的过程负责。不同的测试可以分派不同的人员作为测试主管。n 负责测试计划、测试方案的制定，并且参与测试计划的评审、协调测试资源、统一安排人员进行测试273、工作，对测试结果进行分析，负责测试报告的编写工作。n 负责审核测试申请中提交的文档、测试发布包是否满足测试要求。32.9.4 测试环境管理员测试环境管理员是主要负责测试环境的部署 。32.9.5 测试经理测试经理全面负责测试管理流程中的具体活动和审批，保证测试按照预先制定的流程有序高效的执行，测试经理在测试管理中具有决策权。n 参与测试计划和测试方案的评审。33 资产与配置管理流程33.1 流程定义资产与配置管理流程是对所有配置项及关联关系的识别、发现、更新、监控、稽核的管理流程。配置项包括应用软件、系统软件、基础架构、IT服务、文档等。资产与配置管理流程中管理的配置项，如果还没有进入生产状态274、，其状态，属性及关系信息由资产与配置管理流程维护，如果配置项进入生产状态，则需要在变更管理流程的控制下对配置项的状态，属性和关系信息进行维护。33.2 流程外部关系图 图表 081资产与配置管理与其他的流程关系33.3 流程目标资产与配置管理流程的总体目的是提供一个统一、一致的方式来管理IT基础架构中的各个组成部份，他的目标包括：n 所有配置项被正确识别。n 确保配置项信息完整性，并保留配置项历史变更记录。n 准确描述配置配置项与配置项的关联关系。n 通过维护配置项的准确性，对IT生产环境的稳定性提供支持，并提供配置项影响性分析。33.4 流程执行原则33.4.1 常规原则n IT服务管理系统275、将为所有IT运行及服务管理流程提供所需的信息，特别是针对事件和变更管理流程；所有事件、问题、变更、发布流程被触发后，均需要判断是否涉及到配置项信息的变化。如果涉及，则需要根据资产与配置管理流程来维护其信息，保证系统中的配置项信息和IT环境中的实际信息一致。资产与配置管理流程对系统中配置项的维护和管理过程进行控制。n IT服务管理系统准确反映当前已知的IT架构状态。n 应该定期对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进资产与配置管理流程。33.4.2 控制原则n 所有配置项的更改都需要通过变更管理流程进行控制。n 只有得到授权的人员（配置管理员）才能276、对系统中的配置项信息进行修改，修改之前需要对物理CI的属性进行核实。n 变更管理在变更实施前，要通知资产与配置管理流程根据变更要求进行配置数据准备工作。当变更完成后，通知资产与配置管理流程修改配置项状态。n 日常使用中发现的配置项信息不正确，系统稽核引发对配置项的修改要求等都需要通过变更管理流程进行控制。发起配置项修改请求的人将作为变更请求者，通过变更管理流程进行相应的审批，实现对配置项信息的修改（在变更结束阶段通知相关的配置管理员修改配置项）。n 在系统建设的初期，由于数据仍然处于调整中，可以由配置经理定义一个时间段，该时间段内的数据调整可以不经过变更管理流程控制。n 当确认配置项信息不需要277、在系统中保留时，进行配置项的删除。在系统中不对配置项进行物理删除，只通过删除状态属性来标识其是否被删除。n 需要定期计算配置项的“服务到期日期”来对配置项是否过保进行预警。33.4.3 稽核原则n 资产与配置管理流程必须定期对IT环境进行稽核和跟踪监测，以保证系统中配置项信息的准确、完整，并与实际IT环境的状态高度一致。该工作由配置经理负责。n 应该定期根据变更的执行情况对变更引发的配置项的修改情况进行稽核。n 只有配置项状态为生产状态，如“使用中”，才纳入稽核核查范围。33.5 与其它流程的关系n 事件管理流程：事件记录要与系统中的配置项关联。此外配置管理为事件管理提供配置项的具体信息。n 278、问题管理流程：问题记录要与系统中的配置项关联。配置管理为问题管理的根本原因分析提供参考信息。n 变更管理流程：变更管理与配置管理是紧密结合的，变更管理流程引发和控制对配置项的修改，配置管理为变更管理提供信息帮助变更的评估分析。n 发布与部署管理流程：资产与配置管理通过定义配置项间的关系和依赖性以及组件、服务功能和端到端服务的状态变化，提供配置项分析报告，来协助发布执行人制定发布计划。n 日常运维管理流程：日常运维计划执行的过程中可能会发现与系统中记录不一致的配置项，此时需要提交配置管理进行分析，并通过变更管理控制和修改。33.6 流程说明33.6.1 一级流程图表 082资产与配置管理一级流程279、33.6.2 流程主要活动资产与配置管理一级流程活动说明如下：序号步骤名称责任人说明1配置策略制定配置管理员、配置经理q 建立CI关系模型，CI间关系模型。q 制作CI收集模版：明确CI类别，CI层次，CI属性。q 制定CI维护策略：确定配置维护的步骤、更新方法、检查、审核过程。q 制定CI监控策略：确定监控频率，提交监控方法，自动比对生产环境与配置项差异，提交差异报告。q 制定CI稽核策略：确定CI稽核周期，CI稽核计划。2初始配置项信息收集配置管理员、配置经理q 根据CI模版要求，收集CI层次，CI关系，CI属性，并填写CI模板q 对物理环境配置项进行标识，建立实体与配置项关系。3配置信息280、初始化配置管理员、配置经理q 系统新建或者配置策略重大调整如CI层次增加导致大量CI更新时需要进行系统初始化q 核对CI信息，检查层次结构，属性是否满足配置策略要求。q 配置经理进行系统初始化审核：确认变更管理发起的配置项更新请求是否有效，确认配置项更改是否在配置项覆盖范围内，审核通过通知配置管理员进行资源管理系统维护。q 通过CI模板将CI信息维护进系统中。q 提交配置项信息更新结果。4配置项维护配置管理员、配置经理q 接收来源与变更的配置项更新请求。q 根据变更管理要求进行对有影响配置项进行差异分析，并根据要求填写、修正配置项收集模版。q 配置经理进行配置项维护请求审核：确认变更管理发起的281、配置项更新请求是否有效，确认配置项更改是否在配置项覆盖范围内，审核通过通知配置管理员进行资源管理系统维护。q 对物理环境配置项进行标识，建立实体与配置项关系。q 根据配置项收集信息维护系统中的信息。q 交配置项信息更新结果。5配置项监控配置管理员q 系统自动发现生产环境与系统配置项不一致情况。q 配置管理员对不一致进行协调分析，提交配置差异分析报告。q 提交变更管理进行配置项更改请求申请。6配置项稽核配置管理员、配置经理q 按照配置管理稽核策略，制定每类配置项稽核计划，稽核范围。q 协调配置稽核资源。q 通过作业计划对每类配置项进行周期性稽核，并生成稽核报告，提交差异配置项清单。q 配置经理审282、核配置项稽核报告，审核配置项差异清单。q 提交变更管理进行配置项更改请求申请。7定期生成配置报表配置管理员q 收集报表需求。q 按报表需求提供配置报表。表格 091 资产与配置管理流程活动说明33.6.3 流程输出配置策略制定输出： CI收集模版、CI维护策略、CI监控策略、CI稽核策略。初始化输出：配置项更新结果。配置项维护输出：配置项更新结果。配置项监控输出：配置项差异分析报告。配置项稽核输出：配置项稽核报告。33.6.4 二级流程图表 083：配置管理二级流程33.6.5 流程泳道图图表 084资产与配置管理流程泳道图33.7 关键控制点序号重点内容类别1省公司进行流程角色设置时，必须设283、置配置管理员、配置经理。角色的职责按照规范规定不能进行修改，可以进行扩充。组织及人员要求2在IT资源管理建设期初一段时间内，配置管理配置项变更可不通过变更管理控制，其他情况下配置项变更必须严格通过变更管理发起。关键管控点3各省需要通过作业计划定期对配置项定期稽核，且只有配置状态标志为使用中的配置项才纳入配置稽核检查范围。4具备自动发现功能，自动发现IT资源管理库里配置项信息与生产环境不一致，并输配置项差异分析报告。5配置项稽核需输出配置项稽核报告。6配置项信息需保留：配置项代码、名称、类别、使用部门、使用者、管理员、服务提供商、维护合同、审核状态、最近审核时间、创建时间、删除状态、删除时间、设284、备提供商、集成商、状态、最后更新时间、同类数量、采购日期。配置管理维护过程需保留：配置项代码、最后审核时间、审核状态、变更者、变更时间、状态、变更ID、CI变更类型。配置管理配置项监控、配置项稽核需要保留：工单ID、变更ID、审核状态、审核人、变更完成时间、不一直配置项信息、影响分析、原因分析。关键信息要求表格 092 关键控制点说明33.8 主要相关数据说明33.8.1.1 配置项分类配置项的层次按照三层设计，三层既保证CI可以被有效地分组，又可以保证层级不会过于复杂而导致系统难以维护和管理。各省公司可以在此表基础上，自行扩充层次结构和CI类别。不同种类CI所具有的属性不同，下表是本规范定义285、的配置项种类举例。一级分类（编码）二级分类（编码）三级分类（编码）编码硬件(HW)（10）容器(CTR)（01）机架(RCK)（01）100101机框(CLS)（02）100102服务器(SRV)（02）PC服务器（PCS）（01）100201小型机(EPS)（02）100202分区服务器(PRS)（03）100203网络设备(NWD)（03）光纤交换机(FST)（01）100301交换机(SWT)（02）100302路由器(RUT)（03）100303防火墙(FWL)（04）100304入侵检测设备(RMD)（05）100305无线AP(WAP)（06）100306负载均衡设备(LAD)（0286、7）100307其他(OTH)(99)100399存储设备(STR)（04）磁带库 (TPL)（01）100401磁盘阵列(DKA)（02）100402其他(OTH)(99)100499终端(TMD)（05）打印机(PRR)（01）100501PC机(PCM)（02）100502其他(OTH)(99)100599硬件模块（HWM）（06）硬盘（HDK）（01）100601CPU（CPU）（02）100602内存（MEM）（03）100603板卡(BRD)（04）100604端口（PRT）（05）100605其他(OTH)(99)100699软件(SW)（11）操作系统(OPS)（01）Wind287、ows(WND)（01）110101Linu(LN)（02）110102Uni(UN)（03）110103Mac OS(MOS)（04）110104数据库(DBS)（02）ORACLE(ORA)(01)110201INFORMI(INF)(02)110202SYSBASE(SBS)(03)110203SQLSERVER（04）110204其他(OTH)(99)110299集群软件(CLR)（03）集群软件(CLR)(01)110301集群节点(CLN)(02)110302中间件(MWR)（04）应用中间件(AMW)(01)110401消息中间件(MMW)(02)110402交易中间件(TMW)288、(03)110403其他(OTH)(99)110499应用系统(APS)(05)MSS（MSS）(01)110501OSS(OSS)(02)110502BSS(BSS)(03)110503EDA(EDA)(04)110504ITOM(ITM)(05)110505操作系统逻辑单元(OSL)（06）卷(VOL)(01)110601交换空间(SWP)(02)110602文件系统(FLS)(03)110603系统服务(SSR)(04)110604系统进程(SPR)(05)110605系统日志(SLG)(06)110606其他(OTH)(99)110699数据库逻辑单元(DBL)（07）数据库参数(DB289、P)(01)110701数据库服务(DBS)(02)110702数据库内存(DBM)(03)110703日志文件(DBL)(04)110704存储区间(DBST)(05)110705存储文件(DBF)(06)110706其他(OTH)(99)110799中间件逻辑单元(MWL)（08）应用域(MAD)(01)110801应用集群(MCL)(02)110802应用服务器(MAS)(03)110803线程池(MTP)(04)110804数据库连接池(MDP)(05)110805其他(OTH)(99)110899应用系统逻辑单元(APL)（09）进程(APR)(01)110901进程池(APP)(0290、2)110902接口(API)(03)110903应用数据文件(APF)(04)110904其他(OTH)(99)110999码号资源（NO）（12）IP地址资源(IPA)（01）IP地址池(IPP) （01）120101IP段(IPS) （02）120102IP地址(IPA) （03）120103域名（COM）（02）域名（COM）（01）120201辅助资源(A)（13）规划(PLN)（01）规划(PLN) （01）130101规划项目(PPJ) （02）130102工程项目(PRJ)（02）工程项目(PRJ) （01）130201合同(CTR)（03）合同(CTR) （01）130301291、文档(DOC)（04）文档(DOC) （01）130401软件介质(SWM)（05）软件介质(SWM) （01）130501补丁包(PAT)（06）补丁包(PAT) （01）130601其他(OTH)(99)其他(OTH)(99)139999IT组织(OG)（14）IT组织(ITO)（01）IT组织(ITO) （01）140101供应商(SUP)（02）供应商(SUP) （01）140201工作组(WKG)（03）工作组(WKG) （01）140301角色(ROL)（04）角色(ROL) （01）140401人员(ITP)（05）人员(ITP) （01）140501其他(OTH)(99)其他(292、OTH)(99)149999地域空间(LC)（15）行政管理区域(AR)（01）行政管理区域(AR) （01）150101维护管理区域(MAR)（02）服务区域(SAR) （01）150201站点(SIT) （02）150202机房(WKP) （03）150203服务(SR)（16）专业服务(PSR)（01）需求申请(RRQ) （01）160101服务申请(SRQ) （02）160102接入申请(ARQ) （03）160103事件申告(EVE) （04）160104其他(OTH)(99)160199系统服务(SSR)（02）技术服务(TSR) （01）160201业务服务(BSR) （02）160202表格 093 配置项分类说明33.8.1.2 CI的通用属性此处列举大部分CI均具有的属性、相关说明以及适用的CI类别：属性名称说明适用CI类别配置项代码CI的唯一识别码。适用所有类别CI名称CI的名称，填写时参见CI实体的名称。适用所有类别CI类别该CI所属类别，参见配置项层次设计。适用所