应用系统运维（77页2）

免责声明

资料下载方式

以下是方案全文：

目 录

1 项目服务方案 3

1.1 日常维护方案 3

1.1.1 项目概述 3

1.1.2 故障响应和服务内容 4

1.2 服务支撑体系 45

1.2.1 服务组织 45

1.2.2 服务流程 46

1.2.3 服务规范体系 47

1.2.4 团队稳定性方案 56

1.3 质量控制能力 62

1.3.1 服务质量管理 62

1.3.2 质量保障体系 63

1.3.3 质量管理措施 63

1.3.4 项目培训方案 64

1.3.5 服务工作协同 65

1.4 应急预案 72

1.4.1 应急响应方案 72

1.4.2 重点保障方案 77

项目服务方案

日常维护方案

项目概述

背景介绍

为保障企业大数据应用平台的日常生产运维工作，保持运维工作的延续性，需由“经分后台SS、ETL等应用日常维护服务”提供相关的监控、维护工作。

服务目标

在确保企业经营分析系统运维工作顺利开展，包括经分现网系统每日正在运行的上千项流程的日常运维、DACP流程调度、数据分发、进出口数据质量、ETL配置维护以及及时性监控、月生产维护、重点应用及时完成情况监控。

服务原则

例行服务必须按规定时间进行，服务响应时间必须在合同规定的时间内执行，故障应急必须迅速做出反应。准确无误地完成所承诺的服务。要求避免服务过程中的失误，避免服务过中影响局方的业务稳定。术业有专攻，提供专业的服务团队为局方提供专业服务，保证服务质量。

符合局方相关维护规定，做好信息安全保密工作。

故障响应和服务内容

故障等级和服务响应

重点值守：

在局方的要求下，主要是在重要通信保障或国定节假日期间，根据保障等级要求，提供

现场或远程VPN值守服务，根据服务质量进行考核。

突发情况响应

面对突发情况或突发事件，应提供应急响应，要求按照故障等级和响应时限到达现场处理。如有同类故障的处理预案，立即进行业务恢复。否则升级至远程技术支撑中心，同时通报各相关厂商请求提供技术支持服务。同时，现场支持服务工程师将到达现场，实施或配合进行业务恢复和故障处理。

服务满意度保障

空中选号系统服务确保及时、有效的解决服务中出现的问题，不造成各类故障预警，使空中选号系统达到服务满意度指标考核要求。

具体工作：1、对空选系统进行维护；2、确认系统情况合理升级系统版本；3、相关应用配置按需调整；4、对相关应用特征进行及时更新。根据要求，对流量策略进行调整，并对设备系统进行安全漏洞扫描，及时更新系统补丁，避免系统隐患。

生产安全

维护人员需遵守局方的人员进出、机房管理与安全生产规定。

信息安全

维护人员需遵守局方信息安全相关保密规定。系统安全服务包括系统安全保障、信息安全支持服务。系统安全保障是根据相关方要求，定期检查空选系统安全设置，防止一些未经允许的访问影响系统的安全。信息安全支持服务是根据集团信息安全规范和工信部信息安全按要求，确定支持服务作业计划，定时进行系统和应用安全性检查，定期进行系统密码回收和检查，定时对系统的补丁、漏洞等进行检查，对发现或受理的问题进行预防性的维护作业，消除故障隐患。根据不同时期的不同要求，经过协商确认后，系统安全服务作业计划具体内容项目可以定期或不定期的调整。

优化建议

积极主动对系统运营提出性能或功能上的优化建议，与局方人员一起，进行实施，评估能否取得明显效果。

临时任务：

有承担局方临时交办任务的义务，并根据具体情况，承诺相应的服务质量。

服务内容

7X24小时电话支持服务

提供7X24小时电话支持，受理报障，咨询和远程技术支持服务。拨打报障电话3次内有人应答

常规巡检

常规巡检月为单位，范围包括：

为保障系统的健康、高效运行，消除问题隐患，提供系统巡检服务。

SS运维服务

• 工作概述：
• 保障DACP调度系统上YT机平台及MPP平台的程序正常运行；
• 工作重点：
• 每天全程监控重点流程：

夜间3次定时巡检汇报：2点，5点，8点

白天2次重点监控汇报和多次巡检调度系统：重点汇报11点，17点

• 根据流程的重要程度，按既定的时效及质量要求，及时监控、发现、并处理DACP调度系统中的各类异常问题；
• 重点监控并优化重点流程的调度情况，保障出数的及时性及准确性；
• 定期总结DACP调度中的系统、流程调度等问题，并及时进行主动优化或反馈给开发人员进行优化，以保障DACP调度系统的稳健性及效率。
• 自动化告警脚本按需求阀值调整、优化。
• 工作内容：

SS运维服务主要包括了日常监控运维、月初运维任务等。具体维护内容如下：

日常监控运维

SS日常监控运维工作包括流程调度监控及维护、固定分发新增、临时任务处理及跟踪等。

SS重点流程监控及维护：

• 重点监控日程序

总数：1000 （个）监控时段：00:00-23:00 （每日）

• 重点监控月程序

总数：60（个）监控时段：00:00-23:00 （1号-7号）

• 重点监控分钟程序

总数：10 （个）监控时段：00:00-23:00 （每日）

1. 流程调度监控及维护

• 负责监控DACP平台；
• 负责监控及处理调度流程异常的问题，包括失败，等待，长时间未触发，流程依赖缺失，权限缺失等问题；
• 每天通过后台自动化监控脚本，对全量调度流程进行全方位监控，将日常遇到的失败，延迟等问题进行定位分析并优化处理，程序问题及时协调开发人员及时进行处理；
• 对常见问题进行总结分析，归纳问题的发生频率、影响面、共性等，针对性制定优化措施，以减低挂起量，提升出数及时性，提升日常运维效率。

1. SS重点流程监控及维护
2. 临时任务处理

临时任务包括各项临时性、突发性、及专项任务等，诸如系统割接上线配合，因数据错误、程序问题等需要流程临时调度、批量重跑后续，查找流程下线需要的详细信息以及流程下线，支撑经分侧查证流程调度情况，重点应用重点支撑保障、固定分发问题查证等。

1. 固定分发接口配置

由于经分生产所需或日常工单需求所需，SS维护人员对现有接口进行修改配置或新增配置。

1、维护突发事件处理

由于日常生产中遇到各类突发事件,例如数据库宕机、表空间满、调度系统异常、4A平台异常等等。

月初运维任务

SS月初运维任务包括属地化基站维表维护、账单科目维表维护、主策划维表、部分DWD月流程手工维护、月末DWD重点日流程手工维护、以及属地化月表后置流程调度。

1. 属地化基站维表

每月月底最后一天完成属地化基站文件导入数据确认后，维护人员电话督促各属地基站维护人员必须在1号完成基站维护，如遇不可控因素影响进度必须及时上报。

13个属地完成基站维护后，维护人员完成相应的验证工作，验证完成后邮件通知后续维护人员。

2）账单科目维表维护

每月初对账单科目维表DIM_ACC_ITEM_CODE按要求进行更新个性化处理。

每月待客户通知shfin.r_vr011表维护完成，ss确认shfin.r_vr011表从mpp已成功分发至一体机SHFIN.RPT_VR011。（注：select * from all_objects where object_name like'%RPT_VR011%'确认分发一体机成功）手工调度以下程序。

3）主策划维表

每月初对主策划维表按要求进行更新个性化处理；同时打上相应的完成标识。

每月甲方通知数据表维护完成。

4）部分DWD月流程及月末DWD重点日流程

对于部分需要手工干预的DWD月流程及部分月底的DWD日流程进行前置判断验证，并及时进行手工调度并跟踪过程、及完成情况。

每月当出账那边出完账验完数据之后，甲方通知一体机和24库数据都已到位，可以执行以下操作。

在以上程序运行成功后

5）属地化月表后置流程调度

每月月初在用户属地化表已经生成验证通过的情况下，对于依赖该表的后置流程进行手工干预发起调度，并跟踪过程及完成情况。

属地化数据验好后，待甲方邮件通知结果表已分发到MPP库：

确认分发表分发完成；

分发完成后将DACP调度（MPP任务）强制通过，监控后续程序调度情况。

自动化维护及监控措施

1) 模板化辅助维护手段

2) 自动化监控措施

ETL运维服务

• 工作概述：
• 保障云化ETL平台、话单合并服务器的正常运行；
• 实时监控云化ETL平台的接口运行情况、及时处理因各种故障原因导致失败的接口，确保平台的数据采集、预处理、传输、入库、库内处理的及时性和准确性；
• 定期分析云化ETL平台接口各个环节的运行情况、相关程序内存使用率、ODS表空间使用率等数据进行分析，设计合理的优化措施来保障平台系统的稳健性及生产效率。
• 保证重点大接口在规定时间之内完成。

日常ETL维护

1. 云化ETL平台的日常运维

• 基本信息
• 日接口1600个左右，月接口1200个左右，小时接口逾40*24个左右；
• 涉及外围数据库约 35台；
• 涉及各类外部业务平台约50个；
• 日常运维包括：

1. 及时处理各种原因导致的数据抽取、装载失败接口（如ETL平台本身软硬件故障、源文件缺失、源表表结构变化、源数据库连接异常等）；
2. 按需求工单要求新增抽取库、新增外部数据接入、新增接口配置等；
3. 按需求工单要求对存量接口进行修改；
4. etl调度计划、优先级等例行优化；
5. 完善各类告警配置；
6. 实行7*24专人值班制度，每日例行巡检工作（白天：8:00、12：00、17:00；晚上：05:00、21：00，）：

巡检内容：

• 5：00通报今日重点接口的完成情况详情；
• 5：00通报截止当前ETL接口总体情况报告（当日接口任务量，截止当前接口完成总数，失败总数，待调度总数，终止总数）；
• 21:00-8:30全程监控并及时处理网管电话告警；
• 21:00通报当日话单接口各个小时总体情况
• 8:00、12:00、17:00 针对Jobtracker，Taskertracker，话单合并等程序进行巡检，及时对各类异常问题进行查证处理，并保持跟踪直至问题解决。

1. 日常维护过程有13个接口为重点关注对象,要保证这些接口完成的及时性。
2. 话单装载保障工作

涉及话单接口主要有GPRS、语音、短信、物联网以及各类漫入话单；

维护工作包括：

• 话单原始文件的采集、合并、传输以及最终入一体机和MPP数据库全过程的监控和问题处理；
• 因数据仓库故障，需人工处理故障期间失败话单接口；
• 因话单服务器故障，需人工处理故障期间话单分发，合并，上传程序；
• 配合各类对话单数据质量验证的工作；
• 目前有如下话单，其中第一类话单：10003、10010、10025为大数据量话单，是计费侧主动推送，其余均为第二类话单，数据量较小的话单,也是计费侧主动推送。
• 第一类大数据量话单 10003、10010、10025的装载流程图如下：

• 其余第二类话单的流程装载流程图如下：

1. VGOP类接口的保障工作

• VGOP类接口180个左右
• 配置VGOP日接口依赖小时VGOP接口工作流程；
• 应开发需求对现有接口配置修改（如：接口调度时间，接口优先级，添加一体机）；
• 应开发需求配置VGOP接口个性化监控；
• 及时反馈需求人员因源文件缺失导致接口长期失败的状况，并协同需求人员拟定处理方案；
• VGOP主要分为两种类型，一种为一级vgop，另外一种为二级VGOP，他们的装载流程分别如下，他们的主要区别为DL2环节需要通过中转机到集团主机采集VGOP数据文件和校验文件。

1. 日常etl 各类问题的查证及临时工作

• 协助开发部门，完成etl环节的数据质量问题的查证工作；
• 按开发需求完成接口数据的重抽工作；
• 协助SS团队对执行失败、异常程序，程序运行缓慢等问题定位；
• 当etl系统出现问题，可以借助后台进程的日志信息来查找异常问题所在：

1. 配合审计工作的历史数据抽取

• 应审计要求完成新增配置；
• 应审计要求对重新抽取历史数据（重抽接口数量、数据周期往往非常大）；
• 审计期间协助审计人员进行数据质量验证相关工作；
• 来自审计方面的需求每年一般在2-3 次，每次持续1-2个月；
• 每天ETL系统每个时间段抽取的数量如下图：

• 每个源数据库中抽取的数据量统计图如下：

1. ETL系统告警

基本情况：当系统进程出现异常情况,或者接口运行过程中超时未完成等异常情况时,系统就会发送告警信息.当告警级别较高时,如进程异常就会有人工拨打告警电话给值班工程师.

• 告警级别一般时,只会收到告警短信,如下图所示:

• 当告警级别较高时,如进程异常就会有人工拨打告警电话给值班工程师.如下图所示:

ETL平台相关的维护工作

基本情况：

平台涉及应用服务器：18台

平台涉及各类监控、预处理、库内处理、接口特殊处理shell和python脚本：50个

包括：

• 平台涉及的服务器的各类空间维护，包括ETL使用的文件系统的维护清理和压缩、表空间的维护清理、数据生命周期的管理、超级大表的维护管理，MPP数据库数据倾斜问题的处理、MPP数据库事务日志问题的简单处理
• 不定期对核心脚本进行优化完善和各类维护

1. ETL数据源库切库操作

基本情况：少数接口的切库直接在前台操作即可，接口配置管理中选择接口进行修改，但涉及接口较多的库需要利用sql语句批量修改，操作如下：

• 后台批量切库操作（在后台修改配置表务必做好备份工作，以便恢复）；
• 配置表修改范围

• 备份数据库表的操作（模拟接口04882，原抽取库为shcrmbcv3改为shdd21）
• 修改后台表

1. 更新para_value（数据源）
2. 更新para_value（连接字符串）
3. 更新src_db字段，值：shdd21
4. 更新src_db字段，值：shdd21

• 结果验证

查看接口配置：如图：

• 批量调度该接口较早周期，观察实际抽取库信息，如图：

1. ETL系统Mpp库并发数调整

• 后台查看日志观测数据库连接情况
• 扩大MPP连接数操作
• 重启 datasource 进程：
• 查看日志；db2_mpp_pro连接数是否已调整

1. ETL系统批量修改调度时间

案例描述：新客服库例行维护，维护时间段0-2点，3点恢复

解决思路：需要把调度时间在0-3点时间段的接口完后延

• 前台修改

若少量接口的时间调度，直接在前台修改即可。

注：修改完成后，要将该接口执行一次下上线操作；

• 后台修改

若涉及接口较多，需要在后台修改，提高效率

• 操作步骤：

1. 备份相关表：
2. 更改表 st_b_task(任务调度配置表)
3. 更改表 ST_B_TASK_TRIGGER（任务调度时间配置表）
4. 次日观察调度时间是否已修改，next_trigger_time是否改变

1. ETL系统loadmp，inmp

• 第一步（前台修改），进入 “主机管理”界面；
• 第二步（后台修改），进入数据库（51）执行以下SQL。

1. 夜间值班常见问题以及处理办法

• 话单问题之一: 装载一直为执行状态

案例: 今日话单告警为10010接口，2019021821批次LOADYT一直为执行状态，并且没有生成临时表；

处理方法：前台界面，重跑一体机入库节点，恢复正常

• 话单问题之二：没有原始小文件

案例：2：00—5：00 之间没有 原始小文件，导致一体机和mpp 库装载失败。

处理方法：

1. 联系计费侧，确认原始话单小文件没有送达etl 的原因
2. 创建空文件（对应目录：/etlfile1/bosscdr/etlloadfile/话单类型/周期）

在失败批次的校验文件里中插入对应的空文件记录

（校验文件）

1. 创建好后，进入前台界面点击重跑该批次接口

1. 接口在LOADYT环节出现僵死

特殊情况下，一体机临时表装载完成后，没有返回成功状态，导致LOADYT组件状态一直处于执行中。

• 分析

判断LOADYT环节是否僵死，登入到该接口（LOADYT环节）执行主机确认主机上的sqlldr进程是否存在(ps -ef | grep接口号)；

• 进程存在：说明该接口仍处于LOAD状态，如果LOAD的时间比往常要久需从其他层面分析原因；
• 进程不存在：登入ORACLE数据库判断临时表select count(1) from SHODS.LD_04113_20190110存在并确认数据量是否与MPP库一致。当确认数据无误时；可进行下步操作；
• 处理方法：进程存在：判断是单个接口装载入库慢还是所有接口入库慢(判断视图:etl_YT_two_day)，评估下影响面，紧急需要在经分群告知下（注意语言表达）；
• 进程不存在,而且数据已经装载临时表完毕：

1. 首先将临时表rename为正式表
2. 正式表进行赋权
3. 先在前台找到该接口实例号，如图：

1. 再修改后台实例节点表，把该接口LOADYT状态置成功

1. ETL系统中tasktracker进程僵死或进程掉线了

问题描述：执行机tasktracker僵死，无法向Jobtracker请求任务。

处理方式：根据告警查询或观察前台页面执行机完成任务数。

• 第一步：找出哪台执行机进程僵死或掉了
• 第二步 ：先根据sql来判断哪台执行机进程僵死；

通过“【网管】Tasktrakc超过60分钟未获取任务，请查证”这条告警信息，在all_ monitor.sh中查出对应sql并执行。

• 第三步：观察前台页面
• 第四步：重启对应执行机上的tasktracker进程，

1. ETL配置库连接池上限

问题描述：Tasktracker接口初始化失败。

失败原因：Tasktracker连接配置库的线程数到达最大值。

处理方式：把失败的接口手工调度一次；

1. ETL系统查询当天有系统BUG导致失败的接口
2. ETL系统新增一类话单
3. ETL系统新增一台执行机
4. 查找前台展示信息对应的后台SQL的方法

1. 预处理，库内处理浮动IP设置
2. 执行进程因 fetchsize崩溃快速止损

ETL月维护任务

1. 月接口维护

月接口的维护时间一般从每月1日到10日；

月接口总数逾1200

主要包括：

• 跟踪当月月接口完成情况，及时对因各种原因导致的失败接口进行故障原因分析、定位和处理；
• 配合开发人员对当月数据质量异常接口查证处理；
• 每月根据实际情况完善月接口监控，对辅助脚本进行完善，出具月度ETL工作报告等；

1. 模拟出帐

根据开发部门需求每月中旬以后做2-3次相关模拟出账数据的抽取，以确保正式抽取时，数据的准确性，工作内容：

• 待模拟库准备好后，人工把相关接口调整到模拟库进行抽取；
• 接口成功后，通知相关人员接口已成功，如接口期间出现突发状况，及时通知各环节负责人员，并一同协助解决故障问题；

• 出账范围

• 操作步骤

• 前台观察模拟出账与物联网模拟出账

1. 每月2次的例行维护工作

• 因源库维护工作需将接口调度时间进行推迟，且全程跟进涉及接口运行情况直至接口成功，数据质量验证无误为止；
• 处理因MPP、一体机数据库维护导致的话单装载中断、失败等故障，验证数据质量无误为止；

1. 每个月末最后一天切换正式库与BCV库

• 每个月末最后一天23点前手工把CRM库（正式），ZW库（正式）订单库（正式），PUB库（正式）置成切换到BCV库，且把正式库和BCV库状态置为待绪。
• 每月1日把上面切换的数据库库还原。

分发平台维护

1.分发平台维护内容

分发接口总数约为3000左右：

• MPP库-集市库：353个左右
• MPP库-TD库：200个左右
• MPP库-VGOP库：50个左右
• MPP库-前台库：890个左右
• 一体机-集市库：275个左右
• 一体机-MPP库：740个左右
• 一体机-TD库：120个左右
• 一体机-前台库：60个左右

1）分发平台的配置、监控、维护、和问题处理

• 根据开发部门需求配置新增分发接口；
• 根据每日接口运行情况不定期调整各个时间段接口完成情况总数的阀值；
• 每日多次定时对接口完成情况进行巡检；
• 及时处理各类失败和僵死的接口，如发现外部原因导致的问题，及时与相关负责人联系并解决；

2）分发平台本身的维护

• 对固定分发进程进行监控检查，进程主要包括分发总控进程，分发出库进程，分发入库进程等
• 分析定位进程异常原因，处理各类进程异常问题。
• 分发平台的环境维护，包括各类空间告警、清理、维护等。
• 及时处理各类失败和僵死的接口，如发现外部原因导致的问题，及时与相关负责人联系并解决；

3）出具月度分发平台的巡检报告

每月7号提供上月分发平运行报告，内容包括：

• 截止7号分发接口总数，失败总数；
• 当月存在的问题接口，接口是否已经处理完毕；
• 各个库每小时完成接口总数的情况。

4）分发进程的启停

• 初始化任务进程启停

• 出库控制程序启停

• 入库控制程序启停

1. 分发初始化任务进程的应急切换步骤

初始化进程目前只部署在248、250上，假定248 服务器出现硬件故障，需将248的初始化进程切换到250上，切换步骤如下：

• 250上，进入/home/etla/disp/目录下
• 执行初始化任务进程启动脚本

nohup /bin/bash /home/etla/disp/dsDispatch.sh> /dev/null &

• 观察任务是否能正常下发

1. 分发AGENT的应急切换步骤

目前有A/B/C台服务器, 假定A 服务器出现硬件故障, 需要将 A上的分发任务切换到 B/C , 切换步骤如下:

• 将A上的分发配置表进行备份，以便于A恢复后，重新恢复分发任务

Create table DISP_EXP_CFG_20181015 like DISP_EXP_CFG;

Insert into DISP_EXP_CFG_20181015 select * from DISP_EXP_CFG;

入库配置表备份方式同上

• 将配置在A上的任务全部切换到C上，

update DISP_EXP_CFG set agent_name='AGENT_C' where agent_name='AGENT_A';

• 将当日已经在A上运行，且未运行成功的接口全部切换到C上

Update disp_export_ctl set deal_stat=0,agent_name='AGENT_C' where agent_name='AGENT_A' and deal_stat<>99 and deal_stat<>'-100';

Update disp_import_ctl set deal_stat=0,agent_name='AGENT_C0' where agent_name='AGENT_A' and deal_stat<>99 and deal_stat<>'-100';

• 检测切换任务后，任务是否能正常分发

1. 分发情况快速查询

• 当天分发进度 (disp_today)

说明：

库名：指分发中的入库名称

5点：指0：00~5：00期间

参考值：最近一个月完成接口累计完成数的平均值

完成量：当天接口的接口累计完成数

偏移比：完成量相对于参考值的增长率

• 正在执行的接口量(disp_execute)

说明：

入库等待量：超过10分钟，没有开始入库的接口量（数值较大，一般是出现了问题，如进程僵死）

• YT出库完成量（disp_export_ytinfo）

说明：

每小时YT出库完成量

监控范围：0-9点

• MPP出库完成量（disp_export_mppinfo）

说明:

每小时MPP出库完成量

监控范围：0-9点

• MPP入库完成量（disp_import_mppinfo）

说明：

每小时MPP出库完成量

监控范围：0-9点

2.重点值守保障

在局方的要求下，主要是在重要通信保障或国定节假日期间，根据保障等级要求，提供现场或远程VPN值守服务，根据服务质量进行考核。

3.突发情况响应

面对突发情况或突发事件，应提供应急响应，要求按照故障等级和响应时限到达现场处理。如有同类故障的处理预案，立即进行业务恢复。否则升级至远程技术支撑中心，同时通报各相关厂商请求提供技术支持服务。同时，现场支持服务工程师将到达现场，实施或配合进行业务恢复和故障处理。

4.服务满意度保障

空中选号系统服务确保及时、有效的解决服务中出现的问题，不造成各类故障预警，使空中选号系统达到服务满意度指标考核要求。

具体工作：1、对空选系统进行维护；2、确认系统情况合理升级系统版本；3、相关应用配置按需调整；4、对相关应用特征进行及时更新。根据要求，对流量策略进行调整，并对设备系统进行安全漏洞扫描，及时更新系统补丁，避免系统隐患。

5.生产安全保障

维护人员需遵守局方的人员进出、机房管理与安全生产规定。

6.信息安全保障

维护人员需遵守局方信息安全相关保密规定。系统安全服务包括系统安全保障、信息安全支持服务。系统安全保障是根据相关方要求，定期检查空选系统安全设置，防止一些未经允许的访问影响系统的安全。信息安全支持服务是根据集团信息安全规范和工信部信息安全按要求，确定支持服务作业计划，定时进行系统和应用安全性检查，定期进行系统密码回收和检查，定时对系统的补丁、漏洞等进行检查，对发现或受理的问题进行预防性的维护作业，消除故障隐患。根据不同时期的不同要求，经过协商确认后，系统安全服务作业计划具体内容项目可以定期或不定期的调整。

7.优化建议

积极主动对系统运营提出性能或功能上的优化建议，与局方人员一起，进行实施，评估能否取得明显效果。

8.临时任务

有承担局方临时交办任务的义务，并根据具体情况，承诺相应的服务质量。

其他内容

按时总结DACP、 ETL、分发维护技能及经验，定期组织安排培训，共享维护经验，提升维护质量及效率。

培训安排

日常培训

每月安排两次培训，按入职先后顺序进行轮换（内容包括工作经验分享、技能提升、日常工作中各类问题处理等等）。

新人培训

新人入职后前2月强化培训使其能够快速融如入到日常维护工作中（掌握工作内容、操作制度、问题查证、常见问题处理方式等等）。

日常管理

人员管理

做好团队建设工作，避免由于投入力量不足或能力不够而引发维护及时性和质量问题；

• 确保维护团队人员的技术能力和沟通能力，服从上级管理，一经管理方决定的任务，应立即遵守执行；确保工作的连续性、人员的稳定性，降低人员变动带来的额外成本做好员工的人员培训、入离职申请等工作；驻场人员必须保守客户单位的机密，务必妥善保管所持有的文档、文件；驻场人员确保7*24小时全天待命；上班期间确保现场人员可随时实时处理问题；每日下班前A、B角互查确认SS维护结果；SS维护日报：日常维护交班需生成当班次（包括白班、夜班）工作明细报告；新员工入职一周后，由老员工负责收集新员工开通权限的各项信息后且已邮件形式发送给局方对口人；

考勤管理

• 严格遵守客户单位的办公时间，不得迟到早退；如请假未得到客户单位管理人员同意或未提出申请，按旷工处理；因特殊原因需要延长假期的，需得到客户单位和公司批准，否则按旷工论处；驻场人员因病必须治疗及修养时，凭市级以上医院诊断书办理请假手续；

安全管理

• 严格遵守并执行《信息系统运营部工作现场安全守则》 ，定期安排生产安全宣贯演练，预防为主，提升人员、团队的安全意识；确保各项工作遵照公司及中心信息安全管理规定，做好帐号管理、敏感信息查询、生产环境访问、系统安全审计等信息安全工作；在各类项目建设、系统维护工作中充分考虑信息安全，确保访问控制、原始记录、日志审计等符合信息安全规范；

服务支撑体系

服务组织

我司提供9人的团队服务于本项目，服务组织机构如下：

• 项目经理职责：

1、与用户讨论并确定最终项目范围和实施方法；

2、负责制订具体的项目计划，包括培训计划；

3、把握项目各方面的进程；

4、指导业务流程重组和项目变更；

5、检查及调控项目实施范围；

6、向公司汇报项目状况，提出建议及改进措施；

7、负责项目阶段质量。

• 运维工程师职责：

1、负责本项目相关软件的日常维护、升级以及软件应用的二次开发工作。

2、负责面向决策层、管理层、应用层、系统维护层人员提供培训。

3、负责系统维护以及相关技术支持工作。

4、提供系统集成方面的技术支持。

服务流程

为保证现场服务实施的质量能够稳定并不断有所提升，保障客户需求能够得到有效满足，保障现场服务实施团队为客户提供统一、标准化的服务支持，并为客户设立专门的客户服务专员，对进行全程跟踪，提升服务实施专业性，制定服务流程：

服务规范体系

运维规范

现今，随着计算机技术，特别是网络技术的飞速发展，对于许多行政单位，许多企业而言，IT技术越来越深入到核心业务，影响策略制定和企业的发展。从而对IT环境的可靠性，可用性和快速适应性提出了越来越高的要求，与此同时，IT环境(包括软/硬件及相关技术)却变得越来越复杂。因此，对于一个单位而言：

• 如何把有限的IT资源最有效的作用于核心业务的发展
• 如何最快地获取专业的支持能力
• 如何实现对系统的完善管理，提高系统的可靠性和可用性
• 如何提高用户的工作效率，增加最终用户满意度
• 如何跟上IT技术的发展，及时更新相关技术
• 如何提高对IT系统利用的灵活性
• 如何更好地管理IT运营成本
• 以提高服务能力，将会是单位可能面临的问题。

IT服务管理（ITSM）是一套帮助企业对IT系统的规划、研发、实施和运营进行有效管理的方法，是一套指导IT服务的方法论。ITIL是英国国家电脑局（CCTA）于八十年代开发的一套IT业界的服务管理标准库，它把业界在IT管理方面最好的方法归纳起来，形成规范，旨在为企业的IT部门提供一套从计划、研发、实施到运维的标准方法。它一经提出，便被欧洲各大公司纷纷采纳，随后在澳洲，美洲和亚洲流行开来，目前已成为IT服务管理事实上的标准。

通过参考这些标准，我们可以充分借鉴国际化标准的IT服务管理最佳经验，使我们“站在巨人的肩膀上”来设计、规划及运维IT服务，尽可能少走弯路，有效提高IT服务的质量。

ITIL框架图

ITIL是基于流程的方法论。IT部门可用其检查是否用一种可控的和可训练有素的方法为最终用户交付所需的IT服务。ITIL合并了一套最佳的实践惯例，可适用于几乎所有IT组织，无论其规模大小，或采取何种技术。

ITIL对IT服务管理实践中涉及的许多重要问题进行了系统的分析，包括全面的检查清单、任务、程序、责任等与任何IT服务组织密切相关的问题。这些概念的定义也涵盖了大多数IT服务组织的主要行为。IT服务组织可以借助ITIL的指导建立和拓展自己的IT服务流程。

我司学习ITIL、ITSS与ISO9001等国内外先进标准，运维管理规范采用ISO9001模式编写，涵盖服务管理体系、服务级别管理、服务台管理流程、突发事件管理、问题管理、变更管理、发布管理、配置管理等方面，如下图所示：

如上图所示，是一个金字塔结构。处于最高层的，是《客户满意度指引》，一切服务均以“保证客户最大满意度”为前提展开。与之同级的还有服务管理体系文件与总体文件，用以与服务管理体系相结合，并且维持服务管理规范的改良性原则。处于中层的，是ITIL核心的11个标准流程，均根据实际情况进行了修订和优化，以确保在实际工作中能够得到实际应用，运维管理规范是各种操作指南与巡检制度，包括日常管理制度等，确保提供给客户的服务，是统一形象的规范化标准服务。巡检制度的建立，为企业系统“提高系统可用性、提高系统健壮性、提高各级人员技能素质”的“三提高”目标奠定了坚实的基础。

突发事件管理

突发事件管理流程致力于解决突发事件，并快速恢复服务供应。突发事件被记录下来，并且事件记录的质量决定了相关的其它流程的效力。

服务台接近于突发事件管理流程和问题管理流程，并处于它们之间。如果没有适当的控制，变更有可能引入新的突发事件。因此需要建立有效途径对变更进行跟踪。这是为什么建议持续不断地将突发事件记录在同一个CMDB中，并分类为“问题”，“已知错误”，“变更记录”等信息，以促进服务台界面的信息沟通能力，简化事件调查和报告。

突发事件的优先权及其升级需要作为服务级别管理流程中的一部分进行协商，并在SLA中备案。

突发事件管理的目标：

突发事件管理的目标是尽可能迅速地根据SLA中定义的普通服务级别作出反应，使产生问题后对业务行为及组织和用户的影响最小。突发事件管理也应该保留对事件的有效记录，以便于衡量和改进流程，并向其它流程汇报。

突发事件流程如下图所示：

问题管理

对于突发事件有两种处理方法，一种是对其做出服务快速响应，尽快恢复其正常运行，另一种是鉴别和解决问题根源。这两种方法之间存在微妙的区别，而且经常被互相混淆。对其做好区分具有重要意义。

如果问题被怀疑存在于IT架构内部，问题管理流程将会瞄准其潜在的根源。一个问题可能是被突发事件暴露出来的，但是显然，问题管理的目标是解决问题根源，预防其可能产生的干扰，而不是迅速恢复系统运行。

当问题被识别后(被识别的问题通常称之为已知错误)，通常需要进行一个业务决策，决定是否采取永久性措施改进系统架构，以预防再次发生新的突发事件。如果需要，提交一个变更请求来实现改进。

为了有效和高效地识别突发事件背后的问题根源及其发展趋势，问题管理流程需要准确全面的突发事件的记录。问题管理流程同样需要和可用性管理流程密切联络，以确定这些趋势并明确补救措施的重要性。

流程：

配置管理

配置管理致力于控制一个变化中的IT架构(标准化和状态监控)，鉴别配置项目(清册，相互关联，审核与注册)，收集和管理有关IT架构的文档，为所有其它流程提供IT架构的相关信息。

配置管理是所有其它服务管理流程不可分割的一部分。拥有当前架构中所有部件的最新的，准确的，全面的和详细的信息，并管理其变更，使这些信息有效而高效地支持其它流程运行。变更管理可以与配置管理集成。至少，建议在配置管理系统中控制变更的登录和实施，并自在配置管理系统的帮助下对变更影响做出评估。因此所有变更请求应该被输入配置管理数据库(CMDB)，并随着变更请求的进展随时更新记录，直至其实施。

配置管理系统识别一个变更项目和架构中其它部件的关系，将这些部件的所有人召集到影响评估流程中来。不管一个变更是否在架构中实施，相互关联的配置管理记录应该在CMDB中得到更新。最好在变更发生时，使用集成工具自动地更新记录。

CMDB应该开放给整个服务支持组，使所有人理解部件失效可能的原因，从而使突发事件和问题可以被更容易地解决。CMDB还应当被用来把突发事件及问题记录和其它记录联系起来，比如失效的配置项目(ConfigurationItem-CI)和用户之间的联系。如果缺少了配置管理流程的集成，发布管理将难以实现，并可能错误连连。

服务交付流程同样依赖于CMDB中的数据。例如：

服务级别管理需要识别相互结合在一起的部件，并在此基础上设置支持协议，交付服务。

IT财务管理需要知道每个业务部门使用的IT架构部件，尤其是对于收费的项目。

IT服务持续性和可用性管理需要识别部件，用于问题风险分析和部件失效影响分析。

下图显示了配置管理和其它服务管理流程之间的关系：

图：能力管理，变更管理，配置管理和发布管理之间的关系

变更管理

变更管理专注于对IT架构实施可控的变更。此流程的目标是确定所需的变更，并决定这些变更如何在对IT服务产生最小的不利影响的范围内得以实施。同时确保其变更是可追溯的，而且是经过整个组织内部有效地磋商和协调的。在客户组织提交变更请求后，由配置管理流程监控其状态，与问题管理和若干其它流程进行协调。变更实施履行一特定的路径，包括定义，计划，建立，测试，接受，实施，和评估。

变更管理流程依赖于配置数据的准确性，以确保获知所有实行变更造成的影响。因此变更管理与配置管理之间有密切的联系。

变更流程的详细内容应在SLA中存档，确保用户知道提交变更申请的程序，项目目标及时间，以及实施变更造成的影响。

变更的详细内容需要通知服务台。即使变更经过了全面测试，仍然很有可能存在实施变更的过程中发生各种困难，这些困难可能缘于变更没有按需求或预期运行，或者对变更对功能造成的影响产生质疑。

变更咨询会议(ChangeAdvisoryBoard-CAB)由可向变更管理小组提供专家意见的人员组成。这个会议很可能由来自于所有领域的IT及业务单位的人参与。

发布管理

发布是指一组配置项目(ConfigurationItems–CI)经过测试被引入处于活动状态的环境中。发布管理的主要目标是确保发布信息被成功地公布，包括归纳综合，测试与存档。

发布管理确保只有经过测试和正确授权的软硬件版本才能提供给IT运行环境。发布管理与配置管理和变更管理的行为密切相关。真实的变更实施经常通过发布管理行为得以贯彻。

变更的结果可能经常来自于新硬件，新版本软件，以及新的文档(自行建立，或购买而来)等。对它们进行控制，并打包和颁发。有关存档安全和公布程序应该和变更管理和配置管理流程紧密集成。发布的程序也可能作为突发事件管理和问题管理流程中不可分割的一部分，同时还和CMDB密切相连，以维护及时更新的记录。

团队稳定性方案

人员管理原则

1、分配的工作要适合他们的工作能力和工作量

人岗匹配是配置员工追求的目标，为了实现人适其岗，需要对人员和岗位进行分析。每个人的能力和性格不同，每个岗位的要求和环境也不同，只有事先分析、合理匹配，才能充分发挥人才的作用，才能保证工作顺利完成。

通过四种方法来促进人岗匹配：第一，多名高级经理人同时会见一名新人员，多方面了解他的兴趣、工作能力、工作潜能；第二，公司除定期评价工作表现外，还有相应的工作说明和要求规范；第三，用电子数据库贮存有关工作要求和人员能力的信息，及时更新；第四，通过“委任状”，由高级经理人推荐到重要岗位的候选人。

2、论功行赏

人员的贡献受到诸多因素的影响，如工作态度、工作经验、教育水平、外部环境等，虽然有些因素不可控，但最主要的因素是人员的个人表现，这是可以控制和评价的因素。其中一个原则是——人员的收入必须根据他的工作表现确定。人员过去的表现是否得到认可，直接影响到未来的工作结果。论功行赏不但可以让人员知道哪些行为该发扬哪些行为该避免，还能激励员工重复和加强那些有利于公司发展的行为。因此，在工作表现的基础上体现工资差异，是建立高激励机制的重要内容。此外，巴斯夫还根据员工的表现提供不同膳食补助金、住房、公司股票等福利。

3、通过基本和高级的培训计划，提高人员的工作能力，并且从公司内部选拔有资格担任领导工作的人才。

为人员提供广泛的培训计划，由专门的部门负责规划和组织。培训计划包括一些基本的技能培训，也涉及到高层的管理培训，还有根据公司实际情况开发的培训课程，以帮助人员成长为最终目标。组织结构的明确，每个人员都知道自己岗位在公司中的位置和作用，还可方便地了解到有哪些升迁途径，并可获取相关的资料。巴斯夫在晋升方面有明显的内部导向特征，更趋向于从内部提拔管理人员，这为那些有志于发展的人才提供了升职机会。

4、不断改善工作环境和安全条件

适宜的工作环境，不但可以提高工作效率，还能调节人员心理。根据生理需要设计工作环境，可以加快速度、节省体力、缓解疲劳；根据心理需要设计工作环境，可以创造愉悦、轻松、积极、活力的工作氛围。对工作环境进行人性化的改造。

安全是对工作条件最基本的要求，但却是很多企业难以实现的隐痛。建立了一大批保证安全的标准设施，由专门的部门负责，如医务部、消防队、工厂高级警卫等，负责各自工作范围内的安全问题。向所有的工人提供定期的安全指导和防护设施。还可以建立各种安全制度，如大楼每一层都必须有一名经过专门安全训练的员工轮流值班。除设施和制度的保障外，还以奖励的方式鼓励安全生产，那些意外事故发生率最低的车间可以得到安全奖。

5、实行抱合作态度的领导方法

在领导与被领导的关系中，强调抱合作态度。

领导者在领导的过程中，就如同自己被领导一样，在相互尊重的氛围中坦诚合作。巴斯夫的领导者的任务是商定工作指标、委派工作、收集情报、检查工作、解决矛盾、评定下属职工和提高他们的工作水平。其中，最主要的任务是评价下属，根据工作任务、工作能力和工作表现给予公正评价，让下属感受到自己对企业的贡献、认识到在工作中的得失。评价的原则是“多赞扬、少责备”，尊重员工，用合作的方式帮助其完成任务。任务被委派后，领导必须亲自检查，员工也自行检验中期工作和最终工作结果，共同促进工作顺利完成。

人员激励方案

实施人员激励的意义

员工是企业一切活动的核心，企业的发展离不开员工才能的发挥，而激励是员工努力工作的动力源泉。于是，如何对员工实施恰当的激励便成为企业关注的首要问题。

制定激励方案的指导思想

1、人的行为受两大动力体系的驱动。一是自我动力，二是超我动力。这两大动力的平衡关系，决定了人的行为方向。组织中对人的管理，就是想办法将两大动力维持在较高的水平并共同指向组织目标。

2、“自我动力”的启动，主要靠个人利益的吸引。具体方式就是提供三个激励：报酬激励、成就激励、机会激励。

3、“超我动力”的启动，主要靠组织目标、事业理想、企业精神、核心理念与价值观。

4、公司员工因为受到的教育程度较高，因此，其自我和超我强度要高于一般员工。针对知识员工的激励策略必须适应这种较高的自我与超我动力。

激励体系与激励作用

1、激励体系

2、激励作用

激励措施

（一）完善福利

1、为员工上社保。

2、为辛苦工作的员工提供带薪休假。

3、节假日分别为员工发放过节费。

4、培训

季度培训需求分析，并根据培训需求调查每月制定培训计划。将培训作为员工的一项福利，作为公司的企业文化来发展，通过培训来建立学习型企业。

（二）成就激励制度

1、授权

（1）上司对下属适当放权，提高员工的责任感；增强每个员工工作的挑战性。

（2）研究证明，即使你只是让员工有权力调整办公室灯光明暗度，这种小权力都会让他们更有工作动力。企业员工渴望能够在工作中自由地展示他们的才华，发挥其聪明才智，这意味着领导不应告诉员工去做什么，而是在员工“迷途”时给予支持和指导。

（3）这项工作在确定岗位说明书时与各部门协商进行。

2、业绩竞赛

（1）对部门员工的表现用数据显示成绩和贡献，进行排名，并逐一表扬优秀员工。

（2）公司设立“业绩竞赛”专栏，张贴每季度的竞赛结果，公布优秀的前5名。

（3）用数据显示成绩和贡献，能更有可比性和说服力地激励员工的进取心。

3、目标任务沟通

（1）在项目、任务实施的过程中，经理应当为员工出色完成工作提供信息。

（2）这些信息包括公司的整体目标任务，需要专业部门完成的工作及员工个人必须着重解决的具体问题。

（3）每周召开一次办公会，每月第一周周一召开办公会，各个经理沟通公司当月的整体目标任务，以及需要各部门完成的工作。

4、群策群力

做实际工作的员工是这项工作的专家。所以，经理必须听取员工的意见，邀请他们参与制定与工作相关的决策。坦诚交流不仅使员工感到他们是参与经营的一分子，还能让他们明了经营策略。如果这种坦诚交流和双向信息共享变成经营过程中不可缺少的一部分，激励作用更明显。

5、表扬员工

（1）当员工出色完成工作时，经理当面表示祝贺。这种祝贺要及时，要说得具体。

（2）如果不能亲自表示祝贺，经理应该写张便条，赞扬员工的良好表现。书面形式的祝贺能使员工看得见经理的赏识，那份“美滋滋的感受”更会持久一些。

（3）项目成功后，公司要开会庆祝，鼓舞士气。庆祝会不必隆重，只要及时让团队知道他们的工作相当出色就行了。

（4）经理还应该公开表彰员工，引起更多员工的关注和赞许。

对于表现不佳的员工，有时候主管必须做的是帮助他们建立信心，给予他们较小、较容易的任务，让他们尝到成功的滋味，并给予他们正面的回馈。之后再给予他们较重要的任务，以逐渐引导出好的表现。

（5）只重结果，不重过程。

管理者在对员工进行鼓励时，应该鼓励其工作成果，而不是工作过程。有些员工工作很辛苦，管理者可以表扬他的这种精神，但并不能作为其他员工学习的榜样。否则，其他员工就可能会将原本简单的工作复杂化，甚至做一些表面文章，来显示自己辛苦，获取表扬。从公司角度而言，公司更需要那些在工作中肯动脑子的员工，所以，公司应该鼓励员工用最简单的方法来达到自己的工作目标。总之，工作成果对公司才是真正有用的。

6、将绩效评估和员工发展紧密结合

将工作态度、表现和绩效与个人薪资、晋升挂钩，成正比关系。

（四）机会激励

1、人力资源部和各经理根据员工的工作技能，把员工安排到相应的岗位，一是做好员工队伍建设，培养后备干部；二来也是对员工职业生涯的规划。

2、员工职业生涯规划管理这一激励措施是基于组织与员工共同成长、共同发展和共存共荣的观念的，是人本管理思想的最佳实现方式。它具有深层次的激励效应。

3、人力资源部制定和实施培训计划，增加员工学习的机会。

质量控制能力

服务质量管理

质量管理体系标准

本项目实施应采用先进的质量管理模式和科学的质量管理体系和流程，并根据项目自身特点选用合适的质量控制规程。

目前，我司主要采用ISO9001质量标准和软件成熟度模型（CMM）两种控制规程。针对本项目，公司将采用ISO9001质量体系标准，在项目实施的过程中严格执行质量标准。

质量控制过程

本项目中，由项目经理制订质量控制计划，项目质量控制组进行审核。审核方面包括：质量控制措施是否足够、各个成员的质量责任是否明确合理，测试方法是否适用。

质量评定计划

为了加强项目质量管理和界定产品质量标准，本公司将制订适应于项目的检查验收规定和质量评定标准，确保工程质量。

本项目中，应实行两级检查、两级验收制度。一级检查、二级检查和一级验收由本公司实施小组组织完成；二级验收由用户组织实施。各级检查验收严格按项目实施中制订的相应的检查验收规定和质量评定标准执行。对实施和验收过程中出现的重大技术问题，将上报用户协调处理，对一般质量问题的处理应予以书面记录。

质量保障体系

我司将质量视为整个项目计划的一部分。项目计划书中的质量计划部分明确了关键过程和最终结果的评估程序和衡量标准。质量计划和客户要求的质量相一致，以确保项目达到客户在功能、绩效和质量等各方面要求。我们的质量保障包括以下几个方面：

（1） 项目质量管理评估：在项目进行过程中，定期评估项目进程、客户期望、质量问题和风险等；

（2） 资料管理和变革控制：界定所有与质量控制有关的资料和软件数据的管理要求，包括各项计划、过程、表单和标准等等；

（3） 确定流程（如开发流程、监控流程，评估流程和人员安排流程）的执行过程；

（4） 项目质量绩效标准：包括目的、衡量方法和汇报方式。

质量管理措施

在项目实施过程中还将采取如下措施保障项目实施质量：

（1）在项目实施前后对网络性能进行评估。

（2）在系统部署完成后要在实际环境中进行网络连通性测试、安全策略验证和应用系统测试。

（3）配合应用系统做好压力测试，根据压力测试结果调整系统配置。

（4）项目实施后要进行一定时间的试运行，在试运行期间要重点监控网络环境的运行情况、安全策略的验证和业务应用系统运行情况，若出现的问题要及时查找原因并加以修正。

（5）在试点实施过程中验证方案的可行性和正确性。

项目培训方案

技术培训包括现场培训和专业培训，均有我司负责。采购方有权对我方提出的培训方案和培训计划进行选择和调整。

现场培训

现场培训由我司在项目实施现场进行。

我司承诺安排项目采购人认可的具有相关专业资格或者实际工作经验的人员进行培训；现场培训贯穿于整个项目实施过程。

专业培训

1、我司若中标，将制定详细的人员培训方案，培训方案包括培训目的、培训时间安排、人数、教材编写、培训师资情况、培训组织方式等。

2、培训内容和培训对象

（1）系统维护管理培训

培训内容主要包括系统的操作、配置、维护等，系统常见故障现象的诊断和处理，常见的问题及解决方案等。我司为所有被培训人员提供培训环境、文字资料和讲义等相关用品。所有的资料用简体中文书写。

培训时间：系统试运行期间，具体时间由采购人指定。

培训对象为系统运行管理与维护人员。

（2）操作使用操作手册

培训内容包括系统组成、结构、功能、使用办法等。我司承诺为所有被培训人员提供培训环境、文字资料和讲义等相关用品。所有的资料用简体中文书写。

培训时间：系统试运行期间，具体时间由采购人指定。

培训对象为采购人指定的相关人员。

3、所有的培训教员必须用中文授课，除非有其他的协议规定。

4、相关要求

（1）我司承诺选派具有一定资质和实践经验，且受过专门训练的高级专业技术人员负责各分项的技术培训工作。

（2）我司的培训内容包括基本理论、系统的操作、运行管理、现场操作辅导等，培训方式应应包括技术授课、操作示范、参观学习和其他必须的业务指导和技术咨询，确保培训人员对系统基本理论、技术特性、操作规范、运行规程、管理维护等方面获得全面了解和掌握。

（3）我司承诺在培训开始前20天内将培训计划和教材提交采购人审核，除上述培训外，我司还须负责在现场组织对系统的操作，调试和运行技术示范和业务指导。

服务工作协同

我司将制定完整的项目沟通计划，项目的沟通途径主要包含以下种类：项目周报、项目例会、项目月报、项目评审报告、变更控制报告，主要的沟通频率参加下表：

项目周报

项目月报

项目例会

项目组应定期召开项目团队内部例会、项目例会、里程碑会议。项目例会是高效沟通的重要渠道，每次会议前应及时发布会议通知，明确会议的目的、时间、地点、参加人员、会议议程和议题，并下发会议资料，以便大家提前准备，有效地节约会议时间。会议中由专人做好会议纪要，会议结束前进行总结，重申会议决议。

项目评审报告

变更控制报告

应急预案

应急响应方案

启动应急流程

当服务主管收到服务台人员或助理提交的《运维工作单》，并判断该问题属于重大事故时，则启动应急处理流程。重大事故包括以下几种情况：

• 大范围系统中断
• 区域性系统崩溃
• 关键业务中断
• 大范围病毒爆发
• 系统严重破坏
• 数据严重破坏

根据重大事故的紧急程度和状态不同，服务主管可采取以下方式启动应急流程：

• 当紧急事件发生时，我司的运维人员首先要进行故障分析，确定故障的范围和程度，确认为紧急故障的，在查找原因和解决问题的同时，要同步将故障解决情况通报给部门领导、及向客服中说明事件发生的状况。如需其他部门协助的，需要请求相关部门共同尽快解决故障。
• 对于病毒突发事件，当病毒大面积地感染终端，我司的现场服务人员将已感染的终端从局域网中断开，投标人的运行人员将第一时间收集病毒信息，并向现场人员提供有针对性的应急方案；如果应急方案没有效果，要立即和杀毒软件厂方联络，由双方共同协同提供有效的应对措施。
• 对于网络中断事件，我司的运维人员首先要判断中断原因，如果是局域网本地设备或线路造成的，依网络运行处理流程优先快速处理；如果是电信服务提供商造成的，要立即联络电信技术部门解决问题。
• 对于系统故障事件，我司的运维人员首先要启用备用系统，再判断故障类型：硬件损坏、操作系统故障、软件故障。硬件损坏的情况，首先向服务器供应商报障；操作系统故障多数情况都和硬件故障同时出现，处理方式相同；软件故障如果是由购买的软件造成的，立即向软件厂商寻求技术支持；如果是公司自行开发的软件，立即向相关人员联系并排除故障。。
• 对于自然灾害性事件，运行管理人员要尽可能将设备转移到安全地带，将损失降低到最少。
• 对于电力中断事件，由于机房多采用UPS防止断电带来的系统停机现象，在UPS还能供应电力期间恢复供电，对系统使用不会有影响；但遇到特殊情况导致供电部门在短期内不能恢复供电时，如有备用发电设备要启用备用发电设备供电，否则要关闭所有设备，确保突然断电造成设备损坏。
• 在故障排除之后，运行管理人员要填写故障记录，如果故障是由于项目实施中存在的隐患造成的问题，具体操作请参见上层文件《网络系统维护管理指引》。故障记录汇总到“系统运行故障记录表”，重大事故由故障处理人填写故障报告。

成立应急小组

《启动应急流程申请单》获批准后（包括口头批准），由主管部门负责组建应急小组。应急小组由多方人员组成，例如信息中心代表、运维部代表、服务主管、客户代表、供应商代表以及其他第三方人员等。

应急小组对发生的重大事故进行讨论分析并制定应急处理方案。

运维小组会根据实际人员需求情况从公司本部调配足够人员加入到应急小组。

运维小组会根据实际需求情况从公司本部调配足够的资金以保障事件处理经费需求。

应急处理过程

根据应急小组制定的应急处理方案具体实施应急处理活动，并将实施过程和结果记录在《应急处理过程记录》中。涉及到客户现场服务的应取得客户的签字确认。

应急处理实施过程中涉及需要协调配合的工作由服务主管填写《资源申请单》，说明需要获得的资源、需要协调配合的工作等，经应急小组审批通过后由相关人员代表配合实施。

应急处理实施过程中涉及需要采购的，由服务主管填写《资源申请单》，说明需要采购的产品名称、型号/规格/功能、厂商/供应商、费用等。《资源申请单》经应急小组审批通过后由运维工程师实施采购，并将采购过程和结果记录在《资源申请单》中，应急小组对采购结果进行确认。

应急处理实施过程中涉及需要变更的，由服务主管填写《变更请求表》，说明变更内容、变更原因、变更方案等，经应急小组批准后直接由运维工程师根据《变更请求表》中的变更方案实施变更，并将变更过程和结果记录在《变更日志》中。

所有应急处理活动均应记录在《应急处理过程记录》中。

具体涉及到网络紧急故障处置，我们以恢复使用为第一目标。

在确认设备故障情况下，将第一时间采用备机备件恢复网络功能；

在链路故障情况下，启动备用链路进行通讯恢复，并积极配合链路运营商恢复链路；

在大面积病毒爆发情况下，利用趋势病毒爆发阻止功能，首先阻止网络病毒传播途径，阻止病毒源，并积极联系厂商获取最新病毒码对全网进行病毒处置。

应急处理结果评估

应急处理过程完成后，服务主管向应急小组提交应急处理过程相关表单，包括《启动应急流程申请单》、《应急处理过程记录》、《资源申请单》、《变更请求表》、《变更日志》等。应急小组对应急处理结果进行评估和确认，并在《应急流程评估单》中填写评估意见。

如果应急小组评估意见为达到要求（即问题得到解决并恢复服务），则应急流程结束。

如果应急小组评估意见为未达到要求，则由应急小组讨论分析原因，根据分析结果可采取以下措施：

• 如果需要继续进行应急处理，则由应急小组提出应急处理方案，进行应急处理过程；
• 如果不需要继续进行应急处理：
• 如果有新的问题产生，则由服务主管填写《运维工作单》，转【问题管理】流程处理；
• 如果有新的变更需求，则由服务主管填写《变更请求单》，转【变更管理】流程处理；
• 否则应急流程结束。

应急流程结束时，由服务主管在《运维工作单》中记录应急处理结果及关联表单编号。配置管理员对应急处理结果进行检查，登记新的配置项或更改后的配置项。

统计和报告

每月或每季度对应急流程情况进行统计，形成《应急流程管理报告》，并提交给服务主管。《应急流程管理报告》内容包括：启动应急流程次数（不同类别的次数）、原因分析、影响分析、完成情况、所需时间、各项资源利用情况、费用情况、意见和建议等。

《应急流程管理报告》经项目经理确认后提交客户主管。

重点保障方案

运维项目组制定了详尽的应急处理预案，整个流程严谨而有序。但在服务维护过程中，意外情况将难以完全避免。我们将对项目实施的突发风险进行详细分析，并且针对各类突发事件，设计了相应的预防与解决措施，同时提供了完整的应急处理流程。

方案实施流程

重点保障策略

（1）值班人员平时应做好重点事件的监控工作，对于重点事件应认真分析、准确判定故障发生的数据域，负责跟踪该事件直至其结束。对于不在运维中心的故障，应在第一时间内通知负责人去现场处理，密切关注事件流程及进展情况，并做好登记工作上报领导。

（2）正常情况下，要求值班人员在10分钟内进行事件确认。如果属于一般事件则按照事件流程进行分派处理，否则应迅速启动《重点保障预案》，并严格按照《重点保障预案》所规定的步骤快速实施应急处置，及时汇报上级领导，掌握实时处理情况。

（3）在处理过程中，如需其他部门去现场增援处理，应及时向上级领导部门汇报，协调沟通，尽快联系技术工程师或厂家技术支持赶赴现场援助处理。