应用系统运维（企业大数据应用平台ETL系统运维实施技术方案）

企业大数据应用平台ETL系统运维实施技术方案

1项目服务方案

1.1日常维护方案

1.1. 1项目概述

背景介绍

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

服务目标

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

服务原则

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

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

1.1.2 故障响应和服务内容

故障等级和服务响应

重点值守：

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

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

突发情况响应

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

服务满意度保障

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

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

生产安全

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

信息安全

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

优化建议

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

临时任务：

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

服务内容

7X24小时电话支持服务

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

常规巡检

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

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

XX运维服务

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

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

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

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

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

日常监控运维

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

XX重点流程监控及维护：

• 重点监控日程序

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

• 重点监控月程序

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

• 重点监控分钟程序

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

1. 流程调度监控及维护

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

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

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

1. 固定分发接口配置

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

1、维护突发事件处理

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

月初运维任务

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

1. 属地化基站维表

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

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

2）账单科目维表维护

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

每月待客户通知shfin.r_vr011表维护完成，XX确认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环节的数据质量问题的查证工作；
• 按开发需求完成接口数据的重抽工作；
• 协助XX团队对执行失败、异常程序，程序运行缓慢等问题定位；
• 当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/boXXcdr/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角互查确认XX维护结果；XX维护日报：日常维护交班需生成当班次（包括白班、夜班）工作明细报告；新员工入职一周后，由老员工负责收集新员工开通权限的各项信息后且已邮件形式发送给局方对口人；

考勤管理

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

安全管理

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

1.2服务支撑体系

1.2.1 服务组织

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

• 项目经理职责：

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

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

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

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

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

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

7、负责项目阶段质量。

• 运维工程师职责：

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

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

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

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

1.2.2服务流程

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

1..2.3服务规范体系

1.3 质量控制能力

1.3.1 服务质量管理

质量管理体系标准

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

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

质量控制过程

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

质量评定计划

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

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

1.3.2 质量保障体系

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

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

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

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

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

1.3.3 质量管理措施

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

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

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

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

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

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

1.3.4 项目培训方案

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

现场培训

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

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

专业培训

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

2、培训内容和培训对象

（1）系统维护管理培训

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

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

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

（2）操作使用操作手册

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

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

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

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

4、相关要求

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

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

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

1.3.5 服务工作协同

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

项目周报

项目月报

项目例会

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

项目评审报告

变更控制报告

1.4 应急预案

1.4.1 应急响应方案

启动应急流程

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

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

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

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

成立应急小组

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

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

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

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

应急处理过程

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

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

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

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

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

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

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

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

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

应急处理结果评估

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

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

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

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

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

统计和报告

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

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

1.4.2下重点保障方案

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

方案实施流程

重点保障策略

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

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

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