××系统
应 急 处 理 预 案
编制人： 编制部门： 软件开发部 编制日期： 生效日期：
信息系统应急处理预案
1 系统信息
系统全称 甲方单位 乙方单位 系统管理部门 ××系统 ×× ×× 软件开发部 系统访问地址：http://10.128.13.252:7001/jmsc/ 应用服务器IP：10.128.13.252 应用服务器操作系统：windows 2003 服务中间件类型：weblogic 8.1.3 数据库服务器IP：10.128.13.252 数据库服务器操作系统：windows 2003 数据库类型：oracle9.2 系统运行环境 数据库名称：JMSC 其它注意事项：（短信服务、FTP服务、自动备份等情况说明） ·252服务器是应用服务、数据库两个放在一起的； ·应用服务启动后还要启动短信平台服务； ·252服务器上每天对JMSC进行备份（保留7天文件）； ·250服务器上每天对JMSC进行异机备份（保留1天文件）； 2 系统负责人
直接负责人 间接负责人 所属部门 软件开发部 软件开发部 ×× ×× ×× 部门负责人 软件开发部 ×× 姓名 联系方式 办公座机：×× 手机：×× 办公座机：×× 手机：×× 办公座机：×× 手机：×× 办公座机：×× 手机：×× - 1 -
信息系统应急处理预案
3 名词解释
3.1 系统运行环境：包括系统应用服务、系统服务中间件、数据库系统、服务器硬件资源、网络环境等。
3.2 系统故障：指系统运行环境发生异常或遭受非法入侵，导致系统不能正常使用或数据丢失等情况。
3.3 移动存储设备：指移动硬盘、U盘等可携带的存储设备。
3.4 网络管理部门：指应用系统所在单位内专门负责网络环境及硬件资源管理工作的部门。 3.5 服务器管理部门：指应用系统所在单位内专门负责管理和维护服务器及相关附属硬件资源的部门。
3.6 异机备份：指在另一台电脑中通过数据库链接对数据库服务器中的数据库进行备份，备份文件留在该电脑中，以防止数据库服务器发生损坏导致数据丢失。
4 系统故障分类
故障分类 应用服务故障 故障描述 应用服务中间件（Weblogic、Tomcat等）的应用服务发生故障，导致应用服务自动关闭、系统登录页面无法访问、程序部署文件异常、服务日志内容异常时，统称为“应用服务故障”。 数据库故障 数据库管理系统软件（Oracle、SQL Server）或数据库本身发生故障，导致数据库中业务数据无法访问、数据库日志异常等情况发生，统称为“数据库故障”。 网络故障 本地局域网络发生故障导致局域网不通、系统无法访问、系统访问报错等情况，统称为“网络故障”。 服务器硬件故障 应用服务器、数据库服务器发生硬件故障，导致服务器关闭或损坏、应用服务或数据库无法访问等情况发生，统称为“服务器硬件故障”。 非法入侵系统或服务器 应用服务遭到未授权入侵、应用服务器或数据库服务器遭到未授权访问，导致应用服务无法访问、数据库无法访问、数据丢失或泄密等情况，统称为“非法入侵系统或服务器”。 - 2 -
信息系统应急处理预案
5 系统预防措施
5.1
应用程序备份
直接负责人负责应用系统的程序备份工作，要求在部门SVN配置库中保持系统程序最新
版本。在进行程序修改和更新过程中必须保证服务器端和SVN配置库中的程序版本一致。
间接负责人有责任及权利监督检查直接负责人的应用系统程序备份工作。 5.2
数据库备份
直接负责人负责设置数据库自动备份策略，并要求每天对备份文件进行检查。备份基本
原则：一是要求在数据库服务器和异机同时备份数据库；二是要求数据库进行每天备份；三是要求定期删除过期备份文件，以保证硬盘空间足够产生新备份文件。
间接负责人有责任及权利监督检查直接负责人的数据库备份工作。 5.3
服务器操作系统账号、密码管理
直接负责人负责服务器端操作系统登录账号、密码的管理工作，要求账号和密码要具有
一定复杂度（字母、数字、符号混合使用），并定期进行更改，账号和密码未经上级领导授权不得随意告诉他人使用。
间接负责人有责任及权利监督检查直接负责人的账号、密码管理工作。 5.4
应用系统管理员账号、密码管理
直接负责人负责应用系统（包括权限平台、工作流平台等软件）管理员登录账号、密码
的管理工作，要求账号和密码要具有一定复杂度（字母、数字、符号混合使用），并定期进行更改，账号和密码未经上级领导授权不得随意告诉他人使用。
间接负责人有责任及权利监督检查间接负责人的账号、密码管理工作。
6 系统应急处理措施
6.1 当系统发生故障时，系统直接负责人应立即通知部门经理，并即刻前往故障现场，如因特殊情况无法及时赶到，应立即通知间接负责人代替前往。
6.2 系统负责人到达故障现场后，应首先判断故障的类型和严重性，根据结论决定是否需要
- 3 -
信息系统应急处理预案
其他相关人等（部门经理、另一系统负责人、其他相关部门负责人等）也立刻赶往现场协助排障，如有需要则立即电话通知。
6.3 在故障现场，系统负责人全权指挥系统的应急处理过程，根据故障类型安排相关人等的应急处理工作。
6.4 当发生应用服务故障时，应按如下步骤依次尝试排障： 6.4.1 尝试重新启动应用服务，并检查故障是否恢复；
6.4.2 应用服务启动后，检查其所占CPU和内存大小，排查是否所占资源异常； 6.4.3 检查应用服务相关日志文件，寻找故障发生原因；
6.4.4 检查操作系统相关日志文件，寻找故障发生原因，如有必要可重新启动操作系统； 6.4.5 检查数据库中的系统登录记录表，排查是否有异常登录发生； 6.4.6 检查应用程序部署文件，排查是否有文件异常上传或改变； 6.4.7 检查应用服务控制台，排查是否有异常文件被部署并发布； 6.5 当发生数据库故障时，应按如下步骤依次尝试排障： 6.5.1 不要重启数据库或数据库应用服务器；
6.5.2 先检查数据库最近一次备份文件是否存在，如存在则先拷贝至移动存储设备中一份，
尝试手动备份当前数据库数据，并将备份文件拷贝至移动存储设备中； 6.5.3 如数据库无法访问，先登录应用服务控制台，排查数据库链接是否异常； 6.5.4 使用PLSQL Developer尝试连接数据库，排查数据库是否运行正常； 6.5.5 检查数据库相关日志文件，排查数据库是否运行正常； 6.5.6 检查数据库中系统登录记录表，排查是否有异常登录发生； 6.5.7 尝试重启数据库或数据库应用服务器，并检查故障是否恢复；
6.5.8 如有必要可重新安装数据库系统，并利用备份文件将原有业务数据恢复最新版本； 6.6 当发生网络故障时，应按如下步骤依次尝试排障：
6.6.1 检查服务器网卡、交换机等网络设备，排查是否硬件损坏或松动； 6.6.2 如确认是网络故障，应立即联系网络管理部门到达现场进行排障；
6.6.3 网络排障后，应立即检查应用服务和数据库访问是否正常，并检查数据库备份文件是
否缺失，如有上述情况发生应立即予以补救；
6.7 当发生服务器硬件故障时，应按如下步骤依次尝试排障：
6.7.1 当发生服务器硬件故障时，如果服务器已经关闭，不要擅自开机，以免因短路等原因
对服务器造成再次伤害；
- 4 -
信息系统应急处理预案
6.7.2 立即联系服务器管理部门，要求其立刻派人到达故障现场对服务器及相关附属硬件资
源进行排查；
6.7.3 故障排除后，应立即对服务器上与应用系统相关的重要文件、数据、程序等进行备份，
备份应采用移动存储设备或网络异机拷贝方式进行，以免硬件损坏导致信息丢失； 6.7.4 备份工作完成后，应对服务器上的应用服务运行环境进行一次全面检查，目的是排查
硬件故障是否导致系统运行环境发生异常变化，如发生异常变化应及时修复或调整； 6.8 当发生系统或服务器遭受非法入侵时，应按如下步骤依次尝试排障：
6.8.1 发现系统或服务器遭受非法入侵后，应立即断开网络、关闭应用服务，以防止被继续
入侵产生更大损失；
6.8.2 检查应用系统运行环境和服务器，排查非法入侵的途径和方式，认真检查应用系统、
数据库、服务器中是否留有病毒、木马、人为存放的恶意后门程序等；
6.8.3 紧急更改应用系统、服务器操作系统等相关登录账号和密码，防止再次遭受非法入侵； 6.8.4 如有必要可暂时停止应用服务的使用，寻找问题解决办法，对所有管辖下的服务器进
行紧急安全补救，确保其它服务器不发生同样的非法入侵情况； 6.8.5 对非法入侵的后果进行评估，如实向上汇报非法入侵情况和解决方案；
6.9 系统故障排除后，现场系统负责人需填报一张“系统故障排除记录表”，将本次故障情况、排障经过、排障结果等情况如实填写记录在案，该表由系统负责人和部门经理签字确认，然后正式归档以备今后查阅对比使用。
7 签字页
我已阅读了本预案中各部分的内容，并充分了解了我所拥有的权利和责任。我保证在本系统发生故障时，将严格按照应急处理预案中的内容进行排障，并在排障过程中尽到我所应尽到的责任和义务。 系统负责人（签字）： 部门经理（签字）： 签字日期： 签字日期： - 5 -
信息系统应急处理预案
系统故障排除记录表
系统名称 故障发生日期 故障处理人 故障排除日期 协助人员 故障描述 排障经过描述 排障结果 系统负责人签字： 签字日期： 部门经理签字： 签字日期： - 6 -
信息系统应急处理预案
- 7 -