应用维护实施项目技术方案

项目概述

项目背景

项目目标

术语定义及缩写说明

项目范围

项目简介

维护内容和标准

总体标准

本次维护项目的主要内容是应用系统的常规性维护。维护工作内容包括但不限于以下内容，公司按照具体要求开展招标范围内应用系统维护及相关工作。

系统运行监控

1）监控要求

系统保障组每日完成巡检工作并填写《巡检工作情况表》，提交至协调组联系人处，若有系统异常需第一时间进行分析并根据应急预案进行相应处理。

巡检周期：第一周，工作时间每2小时一次；第一周过后，每日巡检一次。

2）基础环境巡检

巡检类别巡检范围巡检内容责任单位

基础环境巡检数据库服务器检查服务器硬件运行状况；

检查服务器网络设备运行状况及网络情况；

检查数据库运行状况；

运行保障组

应用服务器

文件服务器

3）服务器巡检

巡检类别巡检范围巡检内容责任单位

服务器

巡检

数据库服务器检查服务器资源占用情况；

检查均衡器运行情况；

检查集群节点运行情况；

检查服务器日志情况，对异常进行排查处理；

运行保障组

应用服务器

文件服务器

4）应用系统巡检

巡检类别巡检范围巡检内容责任单位

应用巡检应用系统

主要及常用功能

通过登录应用系统检查：

移动应用市场发布功能，检查是否正常；

应用保障组

系统日常操作

通过对系统进行操作，以满足业务运行的需要而进行的常规的操作动作；也包括在授权和被监控状态下的对系统运行的业务进程和数据进行修改。

1）常规主动操作

系统自身运行日记的备份，定期清理；

定期检查系统（包括系统附带组件）服务状态，并定期启停系统（包括系统附带组件）服务以释放资源；

按信息中心要求，到指定地点现场解决系统应用问题。

2）常规响应操作

建立或终止系统会话连接；

系统作业提交；

简单故障处理；

提供系统初步需求、功能分析服务；

简单业务流程的调整设计及实施；

根据系统管理员提供的数据库脚本提取数据；

业务问题、系统优化等系统问题的支持服务；

按要求完成指定的周报报表、KPI报表等目前系统前台无法满足需求需人工后台操作的数据处理工作。

3）跨系统协同工作

按照安排处理跨系统协同运维工作，包括但不限于以下工作内容：其他系统发生代码变更、故障、缺陷等影响本系统时，我公司提供相关运行分析、代码修改、缺陷排查、故障处理等相关服务。日常协同监控，对协同问题的分析定位并提供相应的分析报告。

系统深度巡检

按要求开展巡检工作，检查各功能模块能否正常访问，包括典型操作响应时间、系统病毒定期查杀、口令安全情况、日志审计分析、关键进程及资源消耗分析、队列、数据库运行情况等，并编制系统运行状态巡视检查记录。

1)应用系统健康度检查：

按要求开展巡检工作；

典型操作响应；

系统功能健康度检查；

后台异常进程检查；

系统日志分析；

关键进程及资源消耗分析；

系统缺陷的发现及报告；

编制系统运行状态巡视检查记录

2)应用系统安全巡检：

按要求开展巡检工作；

系统口令安全情况；

系统用户权限分配情况；

系统漏洞检查；

系统病毒查杀；

编制系统运行状态巡视检查记录。

3) 数据库安全巡检：

检查CPU个数及状态；

检查并记录内存状态、内存大小；

检查逻辑盘个数及状态；

检查各网卡工作状态；

检查IO使用情况及文件线程资源使用情况。

系统运行分析

定期统计业务应用系统的故障与告警、日志及各项运行数据，定期提交系统运行分析报告。

收集业务运行指标数据并开展业务运行情况分析；

收集系统性能指标数据并开展系统性能情况分析；

收集系统日志并开展系统日志情况分析；

收集系统接口状态数据并开展系统接口状态分析；

收集定期内系统发生故障或存在的缺陷情况并开展系统故障及解决情况分析；

系统高风险期预警报告，系统漏洞与安全预警报告。

系统应用层面备份、恢复和验证

定期进行业务应用系统备份与恢复

1）应用系统备份

按照信息中心的要求定期核查应用系统备份情况。

2）应用系统恢复

按照信息中心要求参与应用系统恢复和演练工作，包括

应用系统恢复操作后，验证恢复结果；

应用系统恢复后的性能与功能检查；

其它必要的操作，如年度应急恢复演练。

培训及知识管理

培训用教材包括相应软件的安装、维护和测试技术，其内容包括：软件系统的操作方法、维护方法、安装调试、排除故障等各个方面，培训教材与最新版本的软件系统相一致，用中文编写。

培训服务还包括搭建系统培训临时环境，开展系统培训前的各项准备工作，包括数据准备、系统测试等内容。

应急保障

应急保障时期（特殊时期、防风防汛应急保障或其它应急场景）提供至少1位系统技术支持人员驻场进行值守工作和7×24小时的系统技术电话支持工作，技术支持人员能够应对系统故障处理，提供处理紧急问题的各类技术解决方案的能力，确保业务系统在应急保障期间稳定运行。

系统重大故障处理技术支持工作

系统发生故障时提供技术服务支持，按公司服务请求进行及时处理，并保证有至少1名专职人员到故障现场进行处理，确保业务系统稳定运行，对突发问题及时进行处理。

配合开展系统应急演练工作

提供系统的应急演练的技术协助工作，包括协助搭建应急演练测试环境，编制应急处理预案并定期更新，以保证应急处理符合实际情况需要。

故障处理（含安全隐患整改）

负责受理用户报障、告警、巡检发现的信息系统故障，开展系统故障定位、原因分析、故障排除，并提交解决方案和优化建议。

服务请求分析、系统告警信息分析、巡视发现的系统故障分析；

快速故障恢复

故障定位和初步确定解决方案；

按照要求一个工作日内编制故障分析报告，提出系统优化建议；

编制系统故障整改技术方案；

故障解决（主备切换、集群节点启停等运行方式切换）；

对系统的安全漏洞进行整改加固。

系统优化

根据系统运行状态、缺陷和故障解决情况，提出对系统优化的建议，制定实施方案，并加以实施，达到优化应用系统的目的。

性能调优设计工作；

定期对系统运行状态和系统运行存在的风险进行分析并提出优化和整改建议，编制相应系统性能优化和系统风险整改的分析报告，全过程跟踪相应的问题点并处理对系统性能存在的问题，编制系统性能调优技术方案或作业计划；

对系统性能存在的问题进行分析，编制系统性能调优技术方案或作业计划；

性能调优测试工作；

系统性能调优发布和版本管理工作；

数据库数据优化维护工作；

技术性文档的完善和更新工作。

系统业务数据维护技术支持

按需开展数据处理及日常工作技术支持、业务数据资源维护、业务数据应用维护管理、业务数据质量维护管理工作。

1)数据处理及日常工作技术支持：

开展后台业务数据操作或数据处理的技术支持；

核查业务数据的问题，包括业务数据模型、业务元数据解释、业务应用模块，提供数据字典；

为业务系统用户提出的数据状况、数据处理问题提供及时的技术支持。

2)业务数据资源维护管理：

检查分析数据资源运行状态，包括用户、库表变更情况、ETL流程调度情况、数据量变化情况等内容；

开展数据库数据的批量校验、导入。

编制数据资源维护的实施技术方案、作业计划；

新数据资源管理数据接口设计调整工作；

数据资源的抽取、校验及核查实施工作；

维护业务系统数据字典，包括更新、变更、发布；

开展业务数据资源的抽取工作，根据技术方案、作业计划进行数据资源抽取。

3)业务数据应用维护管理

编制业务系统运行、指标简报；

维护业务系统内部报表数据及计算逻辑；

协助编制系统业务数据应用技术方案、作业计划，提供数据解释、数据现状分析及应用技术方案可行性分析；

协助开展业务数据应用需求分析、设计、调整工作；

开展系统业务数据应用发布和版本管理工作；

实施系统业务数据应用操作作业工作。

4）组织机构调整的业务数据调整技术支持：

在系统运行过程中，因组织部门变更需要调整系统数据，包括但不限于：业务流程、组织及业务数据等数据的调整。提供支持包括但不限于：

初步分析业务流程、组织及业务数据（历史单据、在途单据）调整需求；

编制系统业务流程、组织及业务数据（历史单据、在途单据）调整技术方案或作业计划；

业务流程、组织及业务数据（历史单据、在途单据）调整涉及、实施、测试工作；

制定版本发布计划和版本管理工作；

业务流程、组织及业务数据（历史单据、在途单据）调整处理作业；按照要求进行日常监控值班，使用公司提供的监控工具监测信息系统的运行状态及运行指标，对于系统发出的告警，及时进行确认，对形成隐患或故障的告警，及时通知相关人员进行处理，并进行跟踪反馈；配合编制信息系统运行监控分析报告等运行维护报告；受理信息系统故障情况，并配合组织协调故障处理；配合编制系统检修作业计划，并协助进行检修作业实施。

系统日志维护

项目实施

根据技术招标书的要求结合自身在信息系统运维管理实践和项目经验，认真实施此次招标的项目。从项目的角度提出软件系统维护过程的安排，同时根据本项目的特点，对拟投入本项目的人员情况进行说明，同时详细说明此项目组成员在维护本项目范围内应用系统所承担的职责和所具有的优势，从系统维护的人员方面确保项目的正常进行。

技术联络会

为了确保项目的顺利进行和完成，在项目实施过程中，建立必要的技术联络会制度。

实施工作记录单

问题报障记录

项目实施阶段，用户应用系统过程中，通过电话、邮件、微信等方式提交系统报障时，现场实施工程师会记录用户姓名、联系方式、所属班组、报障问题、答复内容、跟踪情况等信息进行记录，并安排工程师第一时间处理解决，对于不能及时解决的给出相应答复，并告知解决时间。做到报障问题从提出到解决的全程跟踪历史记录，并最终形成问题报障记录单存档保存。

现场驻点记录

对于报障问题通过远程服务无法解决的问题，维护人员会前往用户基层班组中进行解决，按照提出的问题解决情况，记录报障用户基本信息与实施人员预约到达客户现场时间，对现场反馈的问题进行处理。并形成现场驻点记录单存档保存。

现场工作日报

现场实施团队会每天记录工作日志，以备项目闭环管理。

月度维护报告

每月总结电话报障与现场解决问题数量、问题类型、处理时间、用户反馈结果等情况，以每月项目维护报告的形式向局方汇报，让局方相关人员时刻了解项目现场的实施情况。

年度维护报告

年底结合当年的电话报障与现场解决问题数量、问题类型、处理时间、用户反馈结果及一年中每个月的维护报告等情况，以年度项目维护报告的形式向局方汇报，让局方相关人员时刻了解项目现场的实施情况。

项目管理

项目管理工作内容具体包括：

发展了适用于自己的项目管理方法，结合合作伙伴以及客户方面总结的经验而形成了一种用于项目管理的解决方案。

对项目的组成部分或模块进行完整系统设计。

制定项目目标及项目计划、项目进度表。

制定项目执行和控制的基本计划。

项目进程控制，配合上级管理层对项目进行良好的控制。

进行有效的沟通管理可以提升班组的工作效率，降低工作风险。

管理项目中的问题、风险和变化。

项目团队建设。

各部门、各项目组之间的协调并组织项目培训工作。

针对项目本身建设特点，以公司自身项目管理经验为基础，深入理解信息化项目管理要求，下述的完整的流程化项目管理要点：

进度管理

进度管理将作为一项日常的正式的项目管理活动纳入日程，需要项目管理组和各子项目负责人的共同配合来完成。

已完全理解招标文件的要求，系统技术维护的服务工期为：根据具体的订单合同确定维护服务工期。拟定2018年2月1日开始本项目的维护工作，2018年12月30日完成竣工验收工作。具体计划如下：

序号工作项工作内容时间

1项目启动编制维护计划，召开项目启动会2018年2月1日-2018年2月3日

2应用系统维护完成系统日常操作、系统深度巡检、、系统运行分析、系统应用层面备份/恢复和验证、培训及知识管理、应急保障、故障处理（含安全隐患整改）、系统优化、系统业务数据维护技术支持等工作2018年2月4日-2018年12月28日

3竣工验收编写竣工验收报告，协助完成项目的竣工验收2018年12月29日-2018年12月30日

进度计划的制定

各个子系统或模块在完成系统设计后，应该制定详细的项目工作进度，工作安排的详细程度应该在每一个可单独跟踪的功能模块级别上，并已经分配给具体的人员。项目管理小组使用该任务资源在开发域中的域帐号作为任务分派的对象。

进度的跟踪

任务进度报告

项目组成员必须每日提交工作进度报告，工作进度报告分为两个部分：

1、任务完成状态日报

通过进度跟踪系统每日（工作日结束时）填写任务完成的情况，基于当前完成情况对于剩余工作量给出真实的估计。该日报必须每日执行。

2、工作报告日报

通过进度跟踪系统每日（工作日结束时）填写任务进展的说明。该日报在任务进展发生了延迟或出现重大问题时需要填写提交，如果任务顺利执行，该报告可以不填写。

被分配任务的项目组成员从项目进度跟踪站点上得到其任务分配：

1）如果没有特殊原因，必须接收该任务并回复，或者拒绝并回复原因。

2）在接下来执行的过程中，需要每天提交对于该任务的完成报告。

3）小组汇总所有的进度报告，并根据该数据更新项目进度，作出项目进度图表。

进度评估与报告

将项目组提交的进度计划作为比较基线，根据项目组成员提交的进度日报同步更新，对实际执行情况和计划进行对比，给出项目进度报告，对于出现的任务延迟迹象及早发现，同时对于项目进度状况进行分析。

进度控制

项目进度控制是指按照项目进度计划对项目的实际进展情况进行控制，以保证项目能按时完成。有效项目进度控制的关键是监控项目的实际进度，及时、定期地将它与计划进度进行比较，并立即采取必要的纠正纠正措施。进度控制的内容主要包括：确定当前进度的状况；对造成进度变化的因素施加影响，以保证这种变化朝着有利的方向发展；确定进度是否已经发生变化；在变化实际发生时，对这种变化进行管理。

当项目的实际进度满后于计划进度时，通常可以有以下一些方法缩短活动的工期：

投入更多的资源以加速活动进程；

指派经验更丰富的人去完成或帮助完成项目工作；

经甲方同意，缩小项目活动范围或降低项目活动要求；

]通过改进方法或新技术提高生产率。

另外，我们还加强项目小组内部的沟通和交流，提高项目开发团队的开发效率，加强质量措施的落实，对成员的职责和绩效进行考核，杜绝由于项目质量问题或技术问题引起不必要的变更。

质量管理

项目中采取在各里程碑审查的方式进行质量保障。在我公司项目实施小组中，所有成员都要对产品的质量负责。以下内容是对项目各阶段成果进行审查的规范。

审查的内容

对于编码由于时间和资源的限制可以不在项目总体的级别上进行审查。

审查的方式

在每一个阶段里程碑（分析、设计、编码）召开项目审查会议，分别和各个项目组进行相关内容的审查。

参加审查的角色

主审员

由客户方负责人和我司项目负责人担任。负责协调召开审查会议，召集相关人员，督促准备审查所需要的资料。

责任人

由接受审查的子系统负责人担任。

审查员

由各子系统项目经理担任其他接受审查子系统的审查员是一个很好的选择。

审查过程

1、计划

1）目标：确定需要审查的工作；确定需要审查的工作是否已经可以进行审查；确定审查小组；

2)活动：确定需要审查的工作；确定审查小组；主审员需要确保审查小组了解审查的过程；主审员将会议日期、时间和地点通知审查组成员；主审员和责任人确定审查所需要的资料。

2、准备

1）目标：通过严格审查工作成果和评审资料来做好审查会议准备工作

2）活动：审查员评估工作成果并写下自己的意见

3、审查会议

1）目标：确定正在审查的工作成果中存在的问题

2）活动：审查员介绍在准备阶段自己对于审查工作成果的意见；责任人可以就问题和意见陈述自己的看法；记录最后经大家讨论后确认的问题。

4、追踪

1）目标：确保已经采取了改正措施来改正审查期间发现的问题；

2）活动：责任人和主审员就落实改进措施的计划安排方面达成一致意见；责任人解决审查组确定的问题；当修改工作完成时，主审员审查修改工作。

风险管理

风险管理将作为一项日常的正式的项目管理活动纳入日程，需要项目管理小组和项目成员的共同配合来完成。IT项目由于其规模大和复杂性等特点，在实施过程中存在着不确定的因素，比一般产品生产具有更大的风险，进行风险管理尤为重要。我公司风险管理遵循微软MSF风险管理体系。

风险管理模型

风险管理是一个生命周期过程，该过程中包括：

1、评估风险：可以使项目组将隐含的风险提出来，在风险发生并危害项目对其控制，防止风险危害项目。

2、分析风险：对评估活动中提出的风险项目进行分析，确认其各个风险要素，使项目组以及客户作出相应的决定

3、风险计划：在对风险进行了分析的基础上，需要将作出的决定和措施成为正式的风险计划使项目按照计划安排活动

4、采取措施：在风险计划制定后，需要密切注视在计划中所列举的风险因素的变化情况，并在风险出现时采取措施

5、风险控制：需要把对风险的管理纳入日常的项目管理活动。

风险计划

风险计划是评价、识别并分析潜在风险区域的过程。可以通过列举通常的软件项目风险因素以使风险识别更加明析。制作风险评估表是识别风险的好办法，在风险评估表中我们统计特定风险对项目可能造成的潜在后果。

风险计划的要素有：

风险描述：对于风险情况的介绍。

可能性：风险发生的可能性。风险不是必然要发生的，如果一个对项目存在危害的事件是必然要发生的，那这个事件就不能作为风险。对于风险可能性的标识有助于对那些高可能性的风险投入更大的关注。

严重性：风险如果发生对于项目的危害程度。

危害值：一个综合考虑可能性和严重型后对风险的一个评估，这个评估反应了风险应该被关注的程度。

对策：对策分为两个部分：一是对于采取预防措施以阻止风险的发生，另一方面也要考虑如果风险发生后需要采取什么措施。这两方面的计划构成了完整的风险对策。

触发标志：风险是一种可能性，并且制定风险主要的出发点是预防它，但也要考虑到风险发生后情况。对于风险发生后的应对策略，需要争取一定的提前时间以启动必要的各项工作，设立触发标志是为设立一个判别标识，在该触发标志所标明的条件具备时，说明风险已经越来越可能成为现实了。

风险责任人：风险预防和跟踪需要有人的参与，在风险计划中责任明确是一个重要的原则，对每一个列入了视线的风险都要指定对风险预防和跟踪负责的人员。

风险计划不是一个静止的文件，它应该随着项目状况的变化而变化。所以在任何项目中，风险管理都必须被作为一个日常的正式活动列入项目工作计划，成为项目管理人员的一个重要工作。

变更管理

实施范围控制

保持项目实施范围的前后一贯性是非常重要的。如果出现需要改变原定实施范围的需求，都应以正式文档方式提出。项目小组成员必须谨慎考虑项目范围的改变将对整个项目进程可能产生的影响，必须在批准后才能进行。在实施过程中必须加以跟踪。

范围改变文档内容

说明范围改变内容、理由。说明改变部分在项目进程中的状态。评估改变部分对项目进程可能的影响。评估改变部分对项目费用可能的影响。

批准程序

提出实施范围改变请求报告。提交客户方项目经理查阅和签字批准并内部存档，同时提交项目管理委员会、实施方项目经理等。凡涉及到整个项目进展，费用成本调整较大的改变，必须交由项目管理委员会批准通过。

跟踪执行

范围改变书签字后，开始正式执行。调整相应的实施计划。任务完成进度报告应当定期提交项目双方检查，完成后应当由双方项目经理签字。

验收管理

在具备功能验收、试运行验收条件后向项目建设方提供包含验收方案、具体验收项目、验收目的、验收标准、验收人员等的验收申请，项目建设方应在收到我司验收申请后十个工作日内答复，并组织验收。

提供验收的技术文件资料清单：

序号名称份数备注

1项目初步验收遗留问题整改报告1 

2项目系统运行报告1 

3项目系统运行报告审核报告1 

4项目系统现场处置方案1 

5项目系统实用化工作方案、系统实用化评价细则1 

6项目需求列表1 

7项目问题列表1 

8项目培训计划、培训记录1 

9项目监理质量评估报告1 

沟通管理

沟通管理是一个收集与反馈，存储与加工，解决与发布在项目执行过程中所汇集的各种信息的处理过程。简单的说就是信息的传递和理解。主要过程包括：

第一，沟通计划编制，包括确定项目干系人的信息和沟通需要，谁需要什么信息，什么时候需要，如何把信息发送给他们。

第二，信息发送，及时向各项目干系人提供所需信息。

第三，绩效报告，收集并发布有关项目绩效的信息，包括状态报告，进展报告和预测。

第四，管理收尾，生成、收集和分发信息来使阶段或项目的完成正规化。

培训方案

充分研究和扩展移动终端硬件的便捷性特点，深入挖掘硬件潜能，将业务数据和辅助信息带到工作现场，使班组工作人员减少大量的资料、信息查阅工作量，通过音视频应用等辅助功能，增加班组工作人员现场工作时的交流和沟通的手段，提高工作效率，降低工作风险。

培训方式

培训采用知识讲解、交流培训(问题研讨)等结合的方式进行实施。为了达到更好的培训效果，课程采用由浅入深的方式，逐步提高。具体方式如下：

◆ 培训前自我学习

培训前参加培训的人员根据提供的资料，独立进行自学，了解所要培训的知识，为正式培训做好准备。

◆ 培训中集中授课

由培训讲师根据课程安排对学员进行系统的培训。具体采用讲师模拟流程执行任务等方式。

◆ 培训后反馈答疑

培训结束后，所有学员对培训的内容、过程等方面存在的任何问题都可以反馈到项目组QQ群，培训讲师将会对这些问题进行详细的解答。

培训范围

培训分开培训,培训范围内为主要为合同产品的最终用户、关键用户及运维人员等。

培训内容

操作培训

操作培训指满足最终用户和一般维护人员对整合系统所提供功能的使用方法的培训，培训内容如下：

(1)人机接口的常规操作和使用方法；

(2)系统平台日常报表功能使用方法；

(3)使用人员自主组态使用方法；

(4)系统平台后期数据管理及分析方法等。

维护培训

维护培训指为技术人员提供硬件和软件日常维护方法的培训，以保证项目采购单位技术人员能够对我们提供的产品进行一般故障处理工作。培训内容如下：

(1)系统软硬件故障诊断和查找方法；

(2)系统网络设备故障诊断和查找方法；

(3)硬件设备常见故障的修复方法；

(4)软件常见故障的修复方法；

(6)软件安装及二次开发培训。

培训师资

专业姓名联系方式职位资历

培训课程计划

序号培训课程培训时间

10App管理1-2小时

培训组织职责

一套健全有效的组织机构是贯彻工作意图和顺利进行项目实施的重要条件和保证。在工作之初，首要工作是提出并组建适于本工作实施和管理的全套组织和领导机构。从实施和管理的职责看，这套组织应是完整配套的；从人员素质构成看，这套组织应是精干、高效的。

组织管理

组织架构图

我们将按以下组织结构来安排项目工作的开展，从而保证项目如期、保质完成：

技术服务团队

项目应急预案

系统故障应急预案

系统架构图

应急处理流程

应用系统重大故障

启动条件：新系统在短期运行过程中出现重大故障无法处理，重大故障指该故障导致系统主要模块无法正常使用，且预计在48小时内无法恢复。

处置方案：直接使用系统完整备份对系统进行恢复，同时停止系统的运行。对系统运行期间已产生的数据，通过手工处理方式添加至原系统中。

执行单位：由应急协调组组织。

基础环境重大预案

启动条件：数据库、网络、服务器出现重大故障，导致系统无法正常使用，预计在48小时内无法恢复。

处置方案：需准备一台后备应用服务器，在原相关设备出现问题时进行替代。对系统运行期间已产生的数据，通过手工处理方式添加至原系统中。

执行单位：基础平台处理组。

普通故障

启动条件：应用系统出现异常，但不影响整体的正常使用，或影响正常使用，但能够在48小时内恢复；基础环境出现异常，但不影响整体运行，并且能够在48小时内恢复。

处置方案：功能缺陷直接报开发处理，功能需求报系统问题反馈，流程、数据、咨询问题报客服处理。

执行单位：根据具体故障情况由应用系统处理组或基础平台处理组处理。

系统故障排查

发生各类应急情况时，系统维护人员必须在第一时间到达现场进行故障排查，对于网络通信故障，第一时间通知信息中心网络管理员，分析网络故障原因，排查故障点。对于软件故障，及时判断是否应用系统故障、数据库Oracle故障或Tomcat故障并按照以下方法处理。

Oracle数据库故障常规处理方法

通过使用oracle或其它第三方工具（比如PL/SQL Developer）进行数据库连接测试，看能否连上数据库以判断数据库是否停止。如数据库已停止联系信息中心网络管理员通知数据库服务器厂商进行抢修。

使用数据库实例下任意帐户（比如gzemos_dba /*******），在控制台窗口执行“select 1 from dual”语句，查看是否可以执行最为简单的SQL语句。如果出现第三方软件提示ORA-XXXXX的提示错误，表示数据库底层出现检索数据异常，联系信息中心网络管理员通知数据库服务器厂商进行抢修。

在保证数据库查询正常的情况下，使用gzemos_dba /******帐户，在第三方工具执行“select * from top_employee”，查看当前执行的语句是否能够查询出数据，如果查询不出，表明业务数据丢失。开发商应急工作小组马上进行数据恢复。

Tomcat应用服务器故障常规处理方法

如果应用服务器在输入http://10.150.140.113:8080/platform地址无法访问的情况下，表明应用服务器已经异常停止。可以查看tomcat域日志信息，定位问题。

如果出现后台日志报数据库连接池断裂的情况，建议重启tomcat应用，因为在Tomcat 7相关版本中，一旦由于网络环境不稳定等原因造成数据库与应用服务器之间数据链接失败，数据库将不会自动重新链接，需要使用人工手动重启服务。

应用系统故障常规处理方法

如果确定为应用系统故障问题，开发商应急工作小组组织人员从log4j日志、后台日志中快速查找【ERROR】信息，根据《系统功能故障错误编码档案》定位问题和解决办法。

现场处置方案

现场系统应急场景汇总

应急场景一：

应用服务器由于突发事件导致宕机；

应急场景二：

3G前置机服务器由于突发事件导致宕机

应急场景三：

数据库服务器及存储由于突发事件导致宕机

安全策略

1)数据库、程序文件、配置文件的定期备份由安全运行分部负责保存到磁带机上。

2)应用服务器和数据库服务器通过权限控制，确保数据和程序文件不被非法修改和删除。

3) 安全运行分部的有关人员定期检查服务器和备份过程是否正常。

4）数据库管理员制定数据库服务器突发事件中的事物的回滚和数据恢复机制。

5)系统管理员每天检查服务和备份文件是否正常。