运维体系.doc

运维体系

75
2020年4月19日
文档仅供参考，不当之处，请联系改正。

运维体系

-3

目 录
1. 概述 3
1.1. 目标 3
1.2. 适应范围 3
2. 基本工作制度 3
2.1. 保密制度 3
2.1.1. 机房保密制度 3
2.1.2. 信息系统保密 4
2.2. 运维工作时间安排 4
2.3. 办公网络设备管理制度 5
2.4. 重要期间运维保障 5
2.5. 运维质量分析会 5
2.6. 运维人员工作管理 5
2.6.1. 工作汇报 5
2.6.2. 运维报表管理规定 6
2.6.3. 运维工作质量管理 6
3. 资源配置 7
3.1. 基本准则 7
3.2. 运维组织结构 8
3.3. 角色职责 8
3.3.1. 运维经理 9
3.3.2. 一线运维工程师 9
3.3.3. 二线运维工程师 9
3.3.4. 三线支持（原厂商） 10
4. 日常运维作业计划 10
4.1. 作业计划分类说明 11
4.1.1. 故障检查 11
4.1.2. 能力检查 11
4.1.3. 可用性检查 12
4.1.4. 业务数据检查 12
4.1.5. 配置检查 12
4.2. 作业计划管理流程 13
4.2.1. 流程定义 13
4.2.2. 流程目标 13
4.2.3. 流程框架 13
4.2.4. 流程泳道图 14
4.2.5. 角色和职责 15
4.2.6. 流程说明 15
4.2.7. 流程相关指标 16
5. 服务管理流程 16
5.1. 事件管理 16
5.1.1. 流程定义 16
5.1.2. 流程目标 17
5.1.3. 流程框架 17
5.1.4. 流程泳道图 18
5.1.5. 角色和职责 18
5.1.6. 流程环节说明 21
5.1.7. 流程相关指标 28
5.2. 问题管理 29
5.2.1. 流程定义 29
5.2.2. 流程目标 29
5.2.3. 流程框架 29
5.2.4. 流程泳道图 30
5.2.5. 角色和职责 31
5.2.6. 流程环节说明 31
5.2.7. 流程相关指标 34
5.3. 需求管理 35
5.3.1. 流程定义 35
5.3.2. 流程目标 35
5.3.3. 流程框架 36
5.3.4. 流程泳道图 36
5.3.5. 角色和职责 37
5.3.6. 流程环节说明 37
5.4. 变更管理 40
5.4.1. 流程定义 40
5.4.2. 流程目标 40
5.4.3. 流程框架 41
5.4.4. 流程泳道图 42
5.4.5. 角色与职责 43
5.4.6. 流程环节说明 44
5.4.7. 流程相关指标 47
5.5. 资产与配置管理 47
5.5.1. 流程定义 47
5.5.2. 流程目标 47
5.5.3. 流程框架 47
5.5.4. 流程泳道图 48
5.5.5. 角色和职责 49
5.5.6. 流程环节说明 50
5.5.7. 流程相关指标 54
6. 运维工具 55
6.1. 自助服务 55
6.2. 监控工具 55
6.3. 诊断工具 55
6.4. 远程控制工具 56
6.5. 流程控制工具 56
7. 知识管理 56
7.1. 运维工作相关知识 56
8. 风险管理 57
8.1. 风险定义 57
8.2. 运维风险识别 57
8.3. 运维风险分析方法 57
8.4. 项目风险应对策略 58
8.5. 风险登记处理表 58

1. 概述
1.1. 目标
根据工程项目的建设内容，对其建设的软硬件平台进行统一运维规范，并参考业界标准、最佳实践，分析并借鉴国内外相关企业建设经验建立此规范，成功实现统一运维提供管理依据。
1.2. 适应范围
本方案适用于此项目的建设、运行及持续改进提供依据。
2. 基本工作制度
2.1. 保密制度
2.1.1. 机房保密制度
1、严格遵守保密纪律，增强保密意识，保守系统机密，不能向无关人员泄漏系统结构、容量配置等技术资料。所有机房原始记录，未经许可一律不许带出机房。
2、不准携带公司技术业务文件进入公共场所和探亲访友，在私人信件、广告宣传中，严禁泄漏机密。
3、各种涉及运行维护和系统设备情况的图纸资料要注意妥善保存。
4、实施为用户保密的制度，不能私自完整下载和获取用户的私人信息。
5、严禁设备厂家未经允许经过技术手段对已投入运行的系统进行遥控遥测和远程维护。已经投入运行的系统数据未经批准严禁向设备厂家或第三方提供。
6、加强网络安全管理，确保网络信息不受侵犯，保密信息不被泄露，网络信息不丢失，网络信息正常传递。
7、生产核心网络以及与外部因特网存在接口的网络，应特别加强网络安全管理，提高防范措施。
8、运行维护人员有责任根据系统、设备以及网络的能力，在严格遵守国家法律和制度规定的前提下，对国家行政机关和安全部门提供必要的技术支持和服务。
2.1.2. 信息系统保密
1、凡管理、操作、维护企业信息化系统的工作人员，有权了解与本职工作相关的系统资料，并严格遵守保密要求，不得向无关人员泄露资料内容。
2、各种涉及企业信息化系统运行维护的资料，包括系统配置、设备档案、维护手册、操作说明、应用系统文档等，应有专人负责保管。
3、经有关领导批准后，只允许在工作地点查阅、复印、使用保密文档，不准携带与系统相关的文件进入公共场所等其它非工作地点。严禁在私人信件、广告宣传等交流中泄露系统机密。
4、所有工作人员，应加强安全保密意识，参加保密教育学习，熟悉并严格执行保密规则。
2.2. 运维工作时间安排
工作时间分为日常上班时间（包括轮班）和节假日上班时间安排，需要根据项目实际需要进行安排。
针对本项目提供现场技术服务，以确保用户系统的正常高效运行和及时解决运行中的问题，服务请求提供7×24小时响应，2小时内到达服务现场，3小时内解决问题。
注：如客户方有特别工作时间安排，以服从客户方安排为主，并告知直接主管人员，以进行合理的资源调配。
2.3. 办公网络设备管理制度
运维人员所使用的办公网络设备如由客户方提供，应严格遵守客户方对于办公网络设备的管理制度。
2.4. 重要期间运维保障
为保证特定重要期间系统的稳定运行，需要制定特别的运维保障计划，并严格执行。
2.5. 运维质量分析会
定期召开系统运维质量分析会，研究讨论系统运行维护情况，发现运维风险，改进运维质量，保障系统的稳定运行，并提出下一阶段的工作目标。
运维质量分析会的内容包括：故障归类统计、故障发生及主要原因分析、故障记录是否及时、完整、相应解决措施是否合理，以及提出改造和优化建议等，并在会后生成月度运维质量总结报告及跟踪改进事项，并落实到责任人和改进时间。
运维质量分析会议一般每月召开一次，因此，在日常运行维护中，必须做好日常的运维质量分析指标监控工作。会议召开之前，会议组织方需要准备好相关运维资料和数据。
2.6. 运维人员工作管理
需要将运维工作的成果向主管部门和主管人员进行通报，让她们及时了解运维工作情况，并给予运维工作必要的支持。
2.6.1. 工作汇报
Ø 每周进行一次运维工作汇报，汇报内容包括本周运维工作情况，侧重于事件汇总，事件分析，下周工作计划；
Ø 每月进行一次运维工作月汇报，汇报内容包括当月运维工作情况，侧重于重大事件汇总说明，以及趋势性分析，并根据项目需要生成相应数据分析月报，下月工作计划等；
Ø 年度运维工作汇报，汇报工作包括最近一年的工作情况，及更多改进内容；
Ø 其它汇报事宜，包括最近新的项目的一些工作成果，工作情况，及工作当中总结的经验，教训等事宜；
2.6.2. 运维报表管理规定
Ø 汇总分析技术指标、系统运行、事件/故障等情况和数据，按时填报相应报表；
Ø 上报数据应准确真实，并由专人进行整理，并由主管人员进行审核；
Ø 不同的报表有不同的上报时限要求，一般不应超过上报期限，并由主管人员进行审核；
2.6.3. 运维工作质量管理
需要对运维工作的质量进行管理，奉行PDCA（计划、执行、检查、处理）。并能够对工作经验进行总结，方便以后开展工作。
Ø 每项运维工作的开展都需要周密的计划，确保运维工作所需的各类要素得到保障，对可能出现的问题进行预判，并制定应对策略；
Ø 执行过程应该严格按照工作标准和计划进行，发现问题及时反馈给工作主管人员，及时修正计划；
Ø 执行结束后需要检查工作情况，及时发现工作中存在的一些不足，及时进行改进，并记录工作经验，避免出现类似问题；
Ø 处理，及时处理已经出现的问题，及时改进工作方法，应对各类紧急故障；
Ø 对问题的处理经验的积累有助于以后处理相同问题，并给其它问题的处理带来灵感；
3. 资源配置
根据运维工作任务进行角色分工以及确定所需人员和对应职责，并根据运维需要进行设备和办公环境分配。
3.1. 基本准则
Ø 按照“因事设岗，以岗定责，以工作量定员”的原则，科学合理地设置运行维护岗位、维护人员配置；
Ø 维护人员必须熟练掌握本专业的运行维护技能，胜任本职工作。维护人员数量的确定应少而精，提倡一专多能，提高工作效率；
Ø 维护人员的技术业务层次应分级，要以实际技术水平和工作能力为主考核维护人员，在维护队伍中引进必要的竞争机制；
Ø 定期对维护人员的维护技能进行测试，按照岗位要求，对维护技能的掌握情况、应急方案实施情况的进行测试和演练；
Ø 维护人员具备以下条件：
a) 肯于吃苦，勤于钻研，良好的职业道德，团队意识强；
b) 良好的沟通、综合分析和逻辑思维能力，较高的服务意识；
c) 扎实的专业知识理论基础；
d) 遵守运行维护的各项工作规定，掌握本专业知识“应知、应会”；
e) 在专业领域具备优化分析、达到解决问题、完成职责的综合能力；
f) 较强的学习意识和能力，能够不断的进行自我知识更新；
3.2. 运维组织结构

3.3. 角色职责
以下是本运维项目中涉及到的各类角色，不同角色可能是由不同人担当，也可能多个角色由同一人担当。
3.3.1. 运维经理
负责运维团队人员及日常事务管理。及时处理各类故障，并将运维情况及时通报给相关主管人员，及时完成上级交派的各项运维任务。其主要职责如下：
Ø 全面负责项目运维工作，并严格按照客户方及公司要求的标准的运维流程进行运维工作；
Ø 掌握必要的技术运维技能，满足日常运维工作的需求；
Ø 建立标准的运维流程，方便公司对运维进行更好的管理；
Ø 良好的学习能力，不断的提高自身技术、管理水平；
Ø 每周、每月、每年对运维工作进行总结，及时上报主管领导；
Ø 做好各类文档的制定和管理工作；
3.3.2. 一线运维工程师
对业务运行情况进行不间断监控，及时处理各类突发事件，各类故障，并将运维情况及时通报给运维主管人员，及时完成上级交派的各项运维任务。其主要职责如下：
Ø 全面负责运维工作，并严格按照公司的标准的运维流程进行运维和服务器管理等工作；
Ø 掌握必要的技术运维技能，满足日常运维工作的需求；
Ø 良好的学习能力，不断的提高自身运维技术水平；
Ø 每周、每月、每年对运维工作进行总结，上报主管领导；
3.3.3. 二线运维工程师
负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。二线支持主要是该项目的开发、实施人员。其主要职责如下：
n 进行事件的深入调查研究；
n 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动；
n 必要时引入供应商的支持；
n 更新事件根源和最终解决方案；
n 更新事件记录，确保事件状态代码真实反映事件状态；
n 及时提供有效解决方案；
n 与其它小组合作，确定解决方案；
n 已解决的事件转回服务台，由服务台关闭事件；
n 如果二线不能在解决时限内解决这个事件，应当将事件进行升级；
如二线支持人员出现调动，需由项目研发部及时安排空缺填补，并通知运维部对应项目的运维主管。如一线支持无法及时联系到对应的二线支持人员，由运维主管按照升级机制寻求二线支持人员的上一级主管安排资源。
3.3.4. 三线支持（原厂商）
三线支持人员是相关问题领域的专家。负责提供对一、二线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。主要包括服务器/数据库/中间件/业务系统等专家。其主要职责如下：
n 提供远程接入方式的支持，协助进行事件诊断及恢复；
n 必要时提供现场支持和深入调查研究，提供有效的解决方案；
n 参与重大事件解决方案的实施；
4. 日常运维作业计划
日常作业计划是用以保证系统正常运行的重要措施，其主要包括作业计划制定和作业计划执行两部分。作业计划制定并下达后，必须认真保质保量地完成，不能任意更改，如遇特殊情况需要变动时，需经主管领导批准，并以书面变更通知为准。
作业计划落实过程中，要采取多种形式进行落实，提倡使用电子运维系统或监控系统集中对作业计划进行管理，能够实现系统自动监控的，要实现自动数据采集、分析、告警，提醒维护人员及时按照事件流程及时处理。
作业计划在执行过程中要进行详细记录，作业记录要求填写测试数据，严禁乱用标识符。
手工检查或填写的有关作业计划，要和维护值班记录结合起来，定期巡查、及时填写。作业计划的执行监督、检查和考核由各运维组长负责。
各运维项目组应根据维护工作需要，定期组织对维护作业计划进行修订和完善。修订完善内容主要分为两方面，一是对已执行的作业计划进行修订，根据具体情况对作业项目进行合理调整，完善原有计划；二是结合新增业务，增补维护作业新项目。
4.1. 作业计划分类说明
4.1.1. 故障检查
作业计划工作中需要执行部分作业，来发现故障，例如：
l 检查各个核心应用的主要功能；
l 检查主机运行状况和日志；
l 检查数据库运行状况和日志；
l 检查中间件运行状况和日志；
l 检查网络设备运行状况和日志；
l 检查存储设备运行状况和日志；
l 检查一体化备份系统、应用交付控制器、视频联网监控平台、云计算平台运行状况和日志；
l 检查应用软件运行状况和日志；
故障检查类的作业计划，在发现故障时会触发事件管理流程；
4.1.2. 能力检查
作业计划工作中需要执行部分作业，对各类资源的处理能力的使用情况进行检查，例如：
l 检查服务器cpu和内存占用情况；
l 检查存储设备空间使用情况；
l 检查网络带宽占用情况；
l 检查网络设备端口占用情况；
l 检查软件许可权使用情况；
l 检查业务的发展情况；
l 检查数据的增长情况；
4.1.3. 可用性检查
作业计划工作中需要执行部分作业，对可用性情况进行检查，例如：
l 检查服务器性能超阀值情况；
l 检查数据库性能超阀值情况；
l 检查中间件性能超阀值情况；
l 检查网络设备性能超阀值情况；
l 检查存储设备性能超阀值情况；
l 检查防病毒、入侵检测、防火墙、VPN性能超阀值情况；
l 检查应用软件性能超阀值情况；
4.1.4. 业务数据检查
对各种业务系统的数据进行稽核、比对。
4.1.5. 配置检查
作业计划工作中需要执行部分作业，对配置进行核查，例如：
l 定期审核配置项属性以及配置项之间的关系，以确保其与实际的物理环境保持一致。配置审核活动需要对配置项信息与配置项物理存在性进行双向验证。
配置核查与发现是配置管理的一部分，也配置管理落实到日常运维中的一个具体举措。
4.2. 作业计划管理流程
4.2.1. 流程定义
作业计划管理是对IT人员的日常维护作业进行制定、审核、执行、记录的管理流程。它包括作业计划制定和作业计划执行两个流程。
作业计划制定流程是根据服务设计、服务运维的要求，制定需要周期性或持续执行的日常运维作业计划的管理流程。
作业计划执行流程对日常运维作业计划的执行过程进行记录，对执行结果进行评估，并触发相关后续流程对发现的问题进行处理的管理流程。
4.2.2. 流程目标
l 作业计划管理的主要目标是保证IT服务的正常提供和交付。
l 实现IT部门日常运维工作的固化，使IT部门日常的运维工作不至于被遗忘漏做。
l 保证每项日常运维工作的执行能够留下痕迹，有据可查，IT人员的工作可量化、可考核。
l 经过日常运维工作有计划、定期的执行，使IT服务更加主动，减少事件的发生，提高IT系统的运行质量。
4.2.3. 流程框架

4.2.4. 流程泳道图

4.2.5. 角色和职责
4.2.5.1. 作业计划制定人
作业计划制定人根据需要在系统中制定新的作业计划。
4.2.5.2. 作业计划审批人
作业计划审批人对作业计划制定人提交的作业计划进行审批，对作业计划执行的结果进行审核。
4.2.5.3. 作业计划执行人
作业计划执行人是作业计划的具体实施人员。其主要职责如下:
l 执行根据的作业计划生成的任务单；
l 对执行的过程和结果进行详细的记录；
l 如果执行过程中发现问题，及时与负责人进行沟通，寻求帮助，启动后续流程，从而解决问题；
4.2.6. 流程说明
4.2.6.1. 作业计划制定
作业计划制定人根据实际情况的需要制定或修改已有作业计划的执行任务、执行周期、执行人员等配置信息。
作业计划审批人检查计划的配置信息，包括作业计划分类、作业内容、作业计划执行时间、执行人等。
如果不满足要求，则转“选择作业计划分类”进行重新修改。
审核经过后，在系统中更新相关的作业计划配置信息。
4.2.6.2. 作业计划执行
根据系统中的作业计划，创立相应的任务单。
IT人员执行任务单，并记录作业执行的结果，在执行过程中，如发现事件或潜在问题，应及时启动事件管理流程或问题管理流程进行处理。
4.2.7. 流程相关指标
流程的考核指标是为了判断运维计划流程的效率和有效性。这些考核指标包括：
l 执行作业计划的总体数量；
l 按时执行作业计划的总数量；
l 作业计划按时执行率；
l 成功执行作业计划的总数量；
l 作业计划成功执行率；
l 作业计划执行发现的故障数量；
l 作业计划执行发现的问题数量；
l 作业计划执行启动的变更数量；
Ø
5. 服务管理流程
对本项目运维过程中出现的各类事件、变更、配置进行规范化的管理，定义如下服务管理流程。
5.1. 事件管理
5.1.1. 流程定义
事件管理流程是指对IT生产环境中导致IT服务的非计划性中断或IT服务质量下降，以及对IT服务已造成影响或潜在影响的事件进行管理。其目标是尽可能快地恢复正常的服务运营，最小化对业务运营的负面影响，确保达到尽量好的服务质量和可用性水平。因此，事件管理重在以恢复服务为首要目的，可能因为暂时无法在容许的时间范围内查明事件根本原因并解决，而采取临时解决方案。事件的来源包括IT用户或IT客户报告的事件、监控系统自动发现/转发的事件，以及运维人员发现的事件等。
5.1.2. 流程目标
事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：
n 确保各类IT事件能够在成本允许的范围内，按照事件的优先级，快速、有序地解决。
Ø 多渠道快速响应服务请求（电话/Web/邮件/即时通信工具等）。
Ø 根据事件的优先级，影响度进行综合分类排序，如果判断事件优先级是紧急，则启动紧急事件管理流程进行处理。
Ø 为客户提供及时的事件处理状态信息。
Ø 监控事件处理过程，必要时进行管理和技术升级。
n 确保IT事件处理过程中的关键信息能正确记录，为后续事件处理提供知识支持，为流程持续优化提供准确的数据信息。
Ø 按规范记录事件信息及解决过程信息。
Ø 服务台及后台技术资源利用情况。
Ø 服务台、技术支持团队的工作效率。
5.1.3. 流程框架

5.1.4. 流程泳道图

5.1.5. 角色和职责
5.1.5.1. 服务台
服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师。与服务台一起工作进行事件处理的技术人员定义为一线人员。
职责：
n 负责7×24（根据项目实际需要）的值班和系统监控；
n 响应客户投诉工单、热线电话、邮件、传真等事件报告；
n 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等；
n 对事件进行适当的分类、为事件分配优先级等；
n 尝试使用工具对事件进行初步诊断，分析相关信息并解决问题；
n 对服务台解决不了的事件，分配给最合适的一线支持小组/人员来处理；
n 检查事件的处理进度，保持与事件报告人的联系，适时通知事件处理进展；
n 与用户确认事件解决结果，关闭事件；
5.1.5.2. 一线支持
一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务。
职责：
n 验证事件的描述和信息，进一步收集相关信息；
n 决定需要采取何种措施恢复服务并实施有效的行动；
n 提供现场支持，2小时内到达服务现场；
n 根据优先级提供有效的解决方案；
n 实施事件解决方案；
n 更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件；
n 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理；
5.1.5.3. 二线支持
负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。二线支持主要是该项目的开发、实施人员。
职责：
n 进行事件的深入调查研究；
n 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动；
n 必要时引入供应商的支持；
n 更新事件根源和最终解决方案；
n 更新事件记录，确保事件状态代码真实反映事件状态；
n 及时提供有效解决方案；
n 与其它小组合作，确定解决方案；
n 已解决的事件转回服务台，由服务台关闭事件；
n 如果二线不能在解决时限内解决这个事件，应当将事件进行升级；
5.1.5.4. 三线支持(原厂商)
三线支持人员是相关问题领域的专家。负责提供对一、二线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。主要包括服务器/数据库/中间件/业务系统等专家。
职责：
n 提供远程接入方式的支持，协助进行事件诊断及恢复；
n 必要时提供现场支持和深入调查研究，提供有效的解决方案；
n 参与重大事件解决方案的实施；
5.1.5.5. 事件经理
事件经理负责事件解决过程中的协调和监控，事件升级的判断和具体执行。
职责：
n 负责对事件的解决协调资源，保证事件的最终排除。
n 确保和问题管理流程经理的有效合作。
n 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题。
5.1.6. 流程环节说明
5.1.6.1. 事件记录
应完整地记录事件信息和时间戳，而不论事件是从客户电话/邮件报过来，还是从经过自动检测发现的。所有事件的相关信息都应该详细记录，以便能够维护一个完整的历史数据库，而且有助于事件方便地转移给其它支持人员处理。
事件信息一般能够包括：
n 唯一的事件编号
n 事件来源
n 事件分类
n 紧急程度
n 影响程度
n 优先级
n 日期/时间
n 记录人的姓名或编号
n 联系方法
n 用户的姓名、部门、电话、地址
n 反馈方法（电话或电子邮件等）
n 症状描述
n 事件状态（处理中、等待中、已关闭等）
n 指派的支持小组或人员
n 关联的问题或已知错误
n 事件处理的活动
n 解决的日期和时间
n 关闭日期和时间
5.1.6.2. 事件分类
事件记录的部分工作应包括分配适当的事件分类代码。在问题管理等其它服务管理活动中，查找事件类别/频度以便能够发现事件趋势时，是非常重要的。事件一般按多级分类。
5.1.6.3. 确定优先级
事件的优先级一般经过考虑事件的紧急度和影响度来确定。能够参考以下表格，结合项目实际情况来确定：
事件优先级
影响度
高
中
低
紧急度
高
1
2
3
中
2
3
4
低
3
4
5

优先级
描述
目标解决时间
1
紧急
1小时
2
高
3小时
3
中
3小时
4
低
3小时
5.1.6.4. 初步诊断
事件经过服务台发送之后，服务台分析人员必须开展初步诊断，典型情况是当用户正在通电话时，尽力发现事件的所有症状，以准确确定出了什么问题、如何纠正。在这个阶段，诊断脚本和已知错误信息会在更早的、准确的诊断中体现最大的价值。
如果可能，当用户还在线时服务台分析人员就解决这个事件，成功解决后需要关闭这个事件。如果服务台分析人员不能在用户在线时解决事件，但服务台分析人员认为有希望在允许的时间内、无须其它的支持小组协助情况下解决这个事件，分析人员应该把这个想法通知用户，并将事件编号给用户，继续努力寻找解决方案。
5.1.6.5. 事件升级
职能性升级。当服务台已经清楚靠自己不能解决这个事件时（或者时间已经超过允许时间时，只要最先达到两者之一），事件就必须进行升级。
如果组织内有一线支持（如：常驻客户方的一线运维人员）且服务台相信她们能够解决这个事件，事件就应该转给她们。如果一线支持无法解决就应该升级到二线（主要指项目实施、开发相关人员），若二线不能在允许时间内解决，事件应该立即升级到三线。三线可能是组织内部的（比如：技术专家），也可能是软件开发商、硬件生产商或维护商。升级的规则及时间要求应该在一线支持、二线支持、三线支持之间达成一致协议。
管理性升级。如果事件很严重，比如优先级为1时，就应该通知合适的事件经理（一般为运维主管）。当“调查和诊断”和“解决和恢复”耗费过多时间或者发现是很困难的时候，就需要进行管理性升级。管理性升级应该延续为管理链，以便高级经理能够意识到，并准备采取任何必要的行动，比如分配必要的资源、让供应商或维护商加入。当出现在事件分配给谁处理的问题上出现争论时，也需要进行管理性升级。
5.1.6.6. 事件报告
当事件升级至管理层时，需要提交事件报告，如果因为时间紧迫来不及填写事件报告，在电话/邮件报告事件的同时，尽快补充。事件报告主要包括如下几方面：
l 项目名称
l 事件报告人信息及联系方式
l 事件报告时间
l 事件处理人信息及联系方式
l 问题描述
l 事件影响分析
l 问题调查/诊断过程说明
l 临时解决方案
l 最终解决方案
事件报告应该是一份不断完整的报告，最终也需要提交给客户审阅。
5.1.6.7. 调查与诊断
参与事件处理的支持人员需要调查和诊断出了什么问题，包括为了解决和重构事件的任何行动的细节都应该记录到事件记录中，以便所有活动的完整的历史记录得到全时的维护。
调查应该包括以下活动：
l 准确定位问题所在和用户所发现的状况；
l 确认事件的全部影响，包括受影响用户的数量和范围；
l 识别触发事件发生的可能因素（比如近来的变更、某些用户行动？）；
l 经过搜索以前的事件/问题记录或者已知错误数据库或者厂商/供应商错误日志/知识库，进行知识查找；
l 详细评估事件；
l 收集和分析所有相关信息，找出解决方案（包括临时方案）或流转至 n 线支持；
5.1.6.8. 解决恢复
发现潜在解决方案后，要进行应用和测试。采取哪些行动、牵涉到哪些人，不同的事件可能都不相同，但可能包括以下：
l 请用户直接在自己的桌面或远程设备上执行一些操作；
l 服务台集中地（重启服务器）实施解决方案，或进程诊断和实施解决方案；
l 请专家支持小组实施特定的恢复行动，比如网络支持小组配置路由器；
l 请第三方供应商或维护商去解决事件；
即使找到了解决方案，还是要进行充分的测试，以确保恢复行动是完整有效的且保证服务能够完全恢复。
不论采取什么行动、由谁进行，事件记录必须按照所有相关信息和细节进行更新，以便维护完整的历史记录。在事件处理完成以后，事件处理小组应该将事件发回服务台进行关闭。一般事件的解决方式有采用了解决方案或临时方案来恢复服务，或者发起变更申请 RFC 的方式来解决事件。
5.1.6.9. 临时解决方案
当事件根本原因在预定义的处理时间内无法解决时，运维人员需要尽快提供临时解决方案，减少对客户的影响及损失。在实施临时性解决方案之前，需要做到不影响系统稳定性、完整性，并及时与客户沟通解决方案。
5.1.6.10. 事件沟通及关系处理
对于所有达到一定级别（1级、2级）的事件，运维组长/主管都要全程参与并监控整个处理过程，并与客户保持积极、良好的沟通渠道，安抚客户情绪，并及时向客户汇报事件处理进展。如有必要，主动向上级申请必要的资源支持，并负责将最终处理结果与客户直接进行沟通，同时提交完整的事件报告给上级领导。
5.1.6.11. 事件关闭
服务台应该检查确保事件被完全解决、用户是满意的且同意关闭该事件。服务台应该检查以下：
l 事件关闭时，应核对事件初始分类的正确性再次检查，并及时进行调整，确保事件信息的准确性；
l 如需对事件进行根本原因分析，则启动问题管理流程，解决根本原因，避免事件的再次发生；
l 已关闭的事件单不允许重开。如果事件重复发生，则创立一个新的事件单；
l 用户满意度调查，开展用户满意度的回访或电子邮件调查；
l 事件记录。不放过任何突出的细节，确保事件记录被完整记录，以便完成足够详细的、完整的历史记录；
事件的关闭动作一般是由服务台来完成，可是根据实际需要有的时候也能够采用自动关闭或者由用户来关闭的方式来关闭事件。总之，关闭事件应该是在用户确认事件解决之后才发生的活动。
5.1.6.12. 事件响应时限和解决时限
在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制。一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念；也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理；如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其它相关管理人员。
响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果服务台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间；
解决时限指的是事件状态从“已登记”到“已解决”经过的时间。
以下为一事件优先级对应的事件响应时限和解决时限参考示例（以下时间是24×7工作时间），各项目需要根据实际情况进行制定。
编码
优先级代码
响应时限要求
解决时限要求
10
紧急
30分钟
3小时
11
高
3小时
3小时
12
中
3小时
3小时
13
低
3小时
3小时
5.1.6.13. 事件影响度
事件影响度用于衡量事件所影响业务的严重程度。严重程度一般经过事件所影响的人数、关键系统数以及服务事件所造成的损失来设定。
定义事件影响度等级的因素有：
n 是否影响了核心业务。
n 所影响的用户数。
n 服务失效的影响范围和时长。
事件影响度在事件的生命周期中是能够改变的，例如，初始等级为严重的事件会随着服务失效的时间变成重大故障，因此事件的影响度应在事件得到解决（服务恢复）后重新确认。
事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。以下为一示例说明：
编码
影响度代码
事件性质
描述
10
重大
系统事件
q 系统事件导致客户无法开展业务；
q 系统事件严重影响客户的日常工作；
客户投诉
q 对客户造成巨大损失产生严重后果和不良影响的；
11
严重
系统事件
q 系统事件导致客户无法办理或使用业务；
q 系统事件影响大部分客户日常工作；
q 任一系统瘫痪，导致整个系统无法使用，而且非重大故障。
客户投诉
q 局数据错误导致产生大量的错误。
q 涉及到高额问题的客户投诉。
12
一般
系统事件
q 系统内局部出现问题，不影响整个系统运行，不影响业务处理的事件。
客户投诉
q 不属于重大和严重的客户投诉。
系统事件
q 不影响系统的监控平台告警。
13
无
客户投诉
q 一般数据查询或者使用指导。
5.1.7. 流程相关指标
为了控制流程的质量，必须为流程设置衡量指标。经过对指标的分析，能够有效地对流程的运行情况进行监控和改进。
序号
衡量指标
指标说明
1
事件总数
统计一段时间内真正的事件总数，不包括误报和可忽略的事件。
2
紧急事件数量及百分比
优先级为紧急的事件总数、以及占事件总数的百分比。
3
不同来源的事件数量及百分比
统计来源于用户事件、监控平台、内部创立的事件及占总事件数量的百分比。
4
用户事件提交渠道百分比
统计用户事件中，来源于电话、web、邮件、即时通信工具等不同方式的事件百分比。
5
服务台及一线解决的事件数量
由服务台及一线直接解决的，未派发到二线等后台支持的事件数量。
6
各类型事件平均解决时长
统计来源于用户事件、监控平台、内部创立的事件的平均解决时长。
7
重新调整分类的事件数量
统计初始登记中分配的事件分类，在后续派单及流转过程，以及关闭回顾中进行分类调整的事件数量及其占总事件数量的百分比。
8
计划外业务中断时长
在事件关闭时应记录计划外业务中断时长，针对服务和系统累计的，统计周期内中断服务的总时长。
9
处理超时升级的事件数量
整体处理时间超出相应级别事件处理时限（紧急：<2小时，一般<24小时）。
10
存在潜在问题的事件数量
事件关闭时，发现存在潜在问题未解决需启动问题管理事件的数量。
11
规定时间内解决的事件数量/百分比
统计一段时间内成功解决或变通解决而且处理未超时的事件总数，及其占所有事件总数的比例。
12
规定时间内响应的事件数量/百分比
统计一段时间内成功解决或变通解决而且处理未超时的事件总数，及其占所有事件总数的比例。
13
客户投诉响应及时率
统计一段时间内，针对客户投诉类事件，从事件单生成到事件单开始处理，满足投诉响应时限要求的比例。
14
客户投诉处理及时率
统计一段时间内，针对客户投诉类事件，从事件单生成到事件单处理完成，满足投诉响应时限要求的比例。
5.2. 问题管理
5.2.1. 流程定义
问题管理流程是确定某一事件或具有相同症状的一组事件的根本原因，制定和实施解决方案，从而防止事件再次发生的管理流程。
5.2.2. 流程目标
问题管理流程的主要目标是预防问题和事故的再次发生，并将未能解决的事故的影响降低到最小。与事故管理强调事故恢复的速度不同，问题管理强调的是找出事故产生的根源，从而制定恰当的解决方案或防止其再次发生的预防措施。
问题管理流程包括了诊断事故根本原因和确定问题解决方案所需要的活动，经过合适的控制过程，特别是变更管理和发布管理，负责确保解决方案的实施。问题管理还将维护有关问题、应急方案和解决方案的信息，以使组织能够减少事故的数量和影响。
5.2.3. 流程框架

5.2.4. 流程泳道图

5.2.5. 角色和职责
5.2.5.1. 问题经理
问题经理负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。
职责:
n 确认、审核和监视问题处理过程。
n 必要时协调所需资源。
5.2