范文一：银行系统应急处理预案

平顶山市商业银行银行卡业务系统应急处理预案

第一章 系统简介及相关人员

1.1银行卡系统简介

银行卡业务系统是银行卡交易转接的重要前置系统，也是联网业务运行、交换清算数据的支撑平台。

1.2银行卡业务系统主机简介

银行卡业务系统主机有服务器两台IBM小型机。 主机硬件环境见下表：

系统软件环境见下表：

1.3 应急指挥组

应急指挥小组组成由总行应急指挥小组组成。

1.4 处置团队

处置团队由应用系统管理技术人员、相关业务人员、和技术支持公司组成。 系统管理人员：A角：李安民 B角：王春耀。 技术支持人员：见下表

技术支持公司：深圳市长亮科技有限公司

第二章 应急启动条件

由于主机硬件或软件等故障，导致银行卡业务系统预计中断超过半小时，启动预案。包括但不仅限于以下具体情况：

一、由于电源模块、网卡、硬盘等故障，导致生产主机无法提供服务； 二、由于数据库数据破坏等原因，导致生产主机无法提供服务； 三、由于银行卡业务系统软件程序问题，导致生产主机无法提供服务；

四、生产主机和备用主机同时故障，无法提供服务；

第三章 应急处理流程

银行卡业务系统发生上述故障，按照故障程度将处理流程分为仅启动技术应急和同时启动技术应急及业务应急两类处理流程。

仅启动技术应急：针对由于分行原因预计核心业务中断半小时到2个小时内，如生产主机不能提供服务，但备用主机可以接管并提供服务的情况。该类情况包括上列第一、二、三条；

同时启动技术应急及业务应急：针对由于分行原因预计核心业务中断超过2个小时，如生产主机和备用主机同时不能提供服务的情况。该类情况包括上列第四条。

3.1 仅启动技术应急

3.1.1人员安排如下：

3.1.2流程如下：

一、 上报：

上报人发现或接到生产主机故障，并判断生产主机半小时到2个小时内无法恢复正常服务状态，将该故障情况上报执行批准人；

二、 批准：

经执行批准人批准，启动应急；

三、 信息发布：

经执行批准人同意，协调人以统一口径通知会计结算部、营业网点目前故障情况，以对客户做好解释工作；

四、 应急执行：

执行处理人根据故障现象采取技术手段：

? 针对上列第一条硬件故障，执行处理人采用手工切换的方式，将生产主机切换

到备用主机，切换步骤见附录二，该步骤约在30分钟内完成；执行处理人手工切换完成后，验证应用系统是否正常提供服务，如果可以正常提供服务，将恢复正常情况上报执行批准人；如果仍无法正常提供服务，上报人将故障情况上报执行批准人，由执行批准人确认事件升级，并报告应急指挥组，应急流程转入3.2同时启动技术应急及业务应急；

? 针对上列第二条数据库故障，执行处理人采用恢复数据库的方式，将上一日的

数据库备份恢复到生产主机的数据库中，该步骤约在30分钟内完成；执行处理人恢复数据库完成后，通知会计结算部处理现代化支付等业务数据的补录或调整问题；

五、 信息反馈：

协调人经执行批准人批准，通知会计结算部、营业网点银行卡业务系统恢复正常；

六、 总结：

上报人总结应急执行过程，将记录文档（见附录三）上报执行批准人；

七、 生产主机故障恢复正常后，上报执行批准人，确定适当时间，将应用系统由备

用主机切换到生产主机。

3.2 同时启动技术应急及业务应急

3.2.1人员安排如下：

3.2.2流程如下：

一、 上报：

上报人发现或接到生产主机故障，并判断生产主机和备用主机超过2个小时无法恢复正常服务状态，将该故障情况上报技术批准人，技术批准人将故障情况上报执行批准人；

二、 批准：

经执行批准人批准，启动应急；

三、 信息发布：

经执行批准人同意，协调人通知会计结算部、营业网点目前故障情况，以统一口径对客户做好解释工作；

四、 应急执行：

执行处理人根据分工采取技术手段：

? 经业务批准人批准，执行处理人（业务）办理紧急付款业务；

? 经技术批准人批准，执行处理人（技术）将上一工作日的银行卡业务系统的应

用程序和数据库备份文件恢复到银行卡业务系统测试机上，并修改IP地址为生产机的IP地址，启动银行卡业务业务系统；启动成功后，验证应用系统是否正常提供服务，如果可以正常提供服务，将恢复正常情况上报技术批准人，技术批准人将恢复正常情况上报执行批准人；通知会计结算部处理现代化支付等业务数据的补录或调整问题；

五、 信息反馈：

协调人经执行批准人批准，通知会计结算部、营业网点核心帐务系统恢复正常；

六、 总结：

上报人总结应急执行过程，将记录文档（见附录三）上报技术批准人，技术批准人将总结汇报执行批准人；

七、 主机故障由上报人及总行支持人员共同处理，恢复正常后，上报技术批准人，

确定适当时间，将应用系统切换到生产主机。

附录一： 银行卡业务系统备机的版本更新

人工实现：一上线，生产机、备份机就配置成一样，可以实现版本更新。 附录二： 银行卡业务系统切换步骤

１、 在生产机器上关闭银行卡业务系统。 ２、 拔掉生产机器86.0.1.162的网线。

３、 在银行卡业务系统备机上，用netconfig修改本机网络地址为86.0.1.162，并重新启动机器。

４、 在备机上启动银行卡业务系统。

附录三：应急事件登记表

应急事件登记表

范文二：银行金融系统应急预案

大庆邮政金融系统故障技术应急预案

一、总则

1． 1目的

本预案旨在全面提高应对金融生产系统中各种突发事件的能力,提供科学的指挥方案,最大限度地减少突发事件所造成的业务停顿时间。力争在最短的时间内恢复系统运行，保证生产系统的稳定、安全运行。

1． 2工作原则

1．2．1 贯彻统一领导，分级负责，反应及时，措施果断，依靠科学，加强合作的原则。邮政金融系统故障具有突发性强、影响大、范围广的特点，一旦出现重大故障必须在行领导的统一指挥下，以省级运行维护部门为中心，相关部门积极配合，协同作战，迅速反应，最大限度地保证业务的连续性和安全性。

1．2．2 遵循预防为主，常备不懈的方针。做好应对突发事件的思想准备和思想教育；加强生产系统的日常监控；通过技术创新和技术进步完善监控和预警手段；加强专业队伍建设和培训；制定完善的单项应急处理流程，提高处理速度。定期进行预演。

二、组织结构与职责

金融技术应急组织机构由突发事件领导小组，突发事件应急办公室和各技术应急小组构成。

2.1应急领导小组。

应急领导小组由相关技术领导组成，负责重大故障应急对应的决

策。

2．2 应急办公室。

2．2．1应急办公室由市局信息技术中心和市行渠道与科技部。

2.2.2应急办公室工作职责。

1） 贯彻执行上级领导部门的工作部署。

2） 进行生产环境安全教育，定期演练。

3） 组织安全检查；监督应急措施的落实和整改。

4） 遇到故障发生，协调相关各部门、厂商和省分行相关部门，行使指挥职能。

2．3技术应急小组。

2.3.1技术应急小组由省分行技术部门的运行维护技术人员组成。

2.3.2技术应急小组职能。

1）

2）

3） 制定具体的应急措施，不断完善应急措施。 24小时监控系统运行，发生故障及时预警、上报。 执行上级制定的应急措施。

技术应急小组由市局信息技术中心和市行渠道与科技部组成。

三、监测和预警

3.1故障监测与预警发布

3.1.1 监控。省级维护部门建立了网络和主要设备、系统的运行监控系统，一旦发生故障，会产生声音报警。其他设备和系统采用设备巡检制度，定时对设备运行状态进行记录。

3．1．2监控部门一旦发现故障报警，要及时应急办公室。应急办公室按上报的故障分类和级别，组织应急处理。

预警级别在二级（含二级）以上报应急办公室，由应急办公室上报应急领导小组。

当故障预警的应急处理在规定的时限内没有处理完成，或故障预警级别上升，则由应急办公室启动相应级别的应急处理，超过二级预警上报应急领导小组。

3.2预警级别

3.2.1网络

一般预警：预警级别为四级。部分支行线路发生故障，导致业务无法进行。预警信息用蓝色表示。

较重预警：预警级别为三级。地市对省中心的主干线路发生故障，或地市中心网络汇接设备发生故障，导致一个地区的业务全部瘫痪。预警信息用黄色表示。

严重预警：预警级别为二级。省中心一条骨干线路或部分网络设备发生故障，导致全省业务停顿1小时以上或国家局线路或设备出现故障导致省际业务无法进行。预警信息用橙色表示。

特别严重预警：预警级别为一级。省中心全部骨干线路；主、备网络设备设备出现故障，导致全省和省际业务在短时间内无法进行。预警信息用红色表示。

3.2.2 设备

一般预警：预警级别为四级。外围系统硬件设备或核心系统硬件

设备只是产生硬件故障报警，出现了设备故障的提示。预警信息用蓝色表示。

较重预警：预警级别为三级。外围系统硬件发生故障，但业务仍可维持进行。预警信息用黄色表示。

严重预警：预警级别为二级。核心系统一台主机出现重大故障，无法运行；或部分外围系统出现严重硬件故障而导致业务停止。预警信息用橙色表示。

特别严重预警：预警级别为一级。发生不可预测性自然灾害，导致省中心机房严重破坏；或核心主机、存储等出现重大故障，无法运行（主、备机均无法运行）。预警信息用红色表示。

3.2.3 系统

一般预警：预警级别为四级。外围系统cpu、内存、网络和存储等资源占用较大，导致网点交易缓慢。预警信息用蓝色表示。

较重预警：预警级别为三级。储蓄主机系统cpu、内存、网络和存储等资源占用较大，导致网点储蓄等主要交易缓慢；外围系统cpu、内存、网络、存储等资源占用严重，导致部分或全部前端交易无法进行，并且故障在1小时内无法解决的。预警信息用黄色表示。

严重预警：预警级别为二级。储蓄系统出现严重的交易堵塞现象，网点业务无法正常开展，并且在1小时内没有解决；外围系统出现严重故障，无法开展业务，在2小时内无法解决的。预警信息用橙色表示。

特别严重预警：预警级别为一级。出现严重的系统故障，导致全

省无法开展业务，并且在2小时内无法解决的（外围系统时限为1天）；或结息没有结束，导致业务停顿。预警信息用红色表示。

四、应急响应

4．1网络应急响应

4．1．1蓝色预警-四级预警的应急响应。分支机构操作发现故障后，应立刻通知分支行维护协调人，并由维护协调人通知本地区公司维护人员，由本地公司维护人员负责故障的处理和与相关线路运营商的协调。如果本地区50%以上网点出现线路故障，并且在4小时内无法修复的，升级为黄色警告。

4．1．2 黄色预警-三级预警的应急响应。分行维护协调人上报省行应急办公室，同时通知本地区维护负责人，由本地区负责人启动相关网络应急流程。应急办公室上报省分行应急领导小组。应急办公室及时与故障地区维护单位沟通故障处理情况，并上报给应急领导小组。故障在24小时内无法解决的，升级为橙色预警。

4．1．3 橙色预警-二级预警的应急响应。机房值班人员发现故障后，立刻通知省中心网络维护员和维护部门负责人，在半小时内到达现场，确定故障情况后，上报省分行应急办公室，应急办公室上报省分行应急领导小组，并向相关部门发布故障警报和预警级别。应急办公室到大省中心机房，组织技术应急，提出技术应急方案，经应急办公室上报应急领导小组批准后实施。应急办公室及时掌握故障处理进展，并及时汇报。应急领导小组在1小时内到达现场，指挥应急处理。

4．1．4 红色预警-一级预警的应急响应。机房值班人员发现故

障后，立刻通知省中心网络维护员和维护部门负责人，在半小时内到达现场，确定故障情况后，上报省分行应急办公室，应急办公室上报省分行应急领导小组，并向相关部门发布故障警报和预警级别。应急办公室和应急领导小组在半小时内到达现场，由应急领导小组组织应急处理，提出整体应急方案，由技术应急领导小组上报分行主要领导，待应急方案批准后实施。

4．2设备应急响应。

4．2．1 蓝色预警-四级预警的应急响应。机房值班人员发现故障后，立刻通知相关系统的维护技术人员，维护人员通过远程或到达现场的方式，经一步确定故障的程度，并执行一般故障处理流程。

4．2．2 黄色预警-三级预警的应急响应。机房值班人员发现故障后，立刻通知相关系统的维护技术人员，维护人员和维护主管等半小时内到达现场，执行应急处理流程，同时报告应急办公室。应急处理完成后，维护人员和维护主管监控系统运行情况，确认系统运行平稳后，方可离开现场，并上报应急办公室，应急办公室上报应急领导小组。

4．2．3 橙色预警-二级预警的应急响应。机房值班人员发现故障后，立刻通知相关系统的维护技术人员，维护人员和维护主管等半小时内到达现场，确认故障情况，报应急办公室，办公室成员1小时内到达现场，指挥应急处理，并上报应急领导小组。如果是主机故障，启动主机应急流程。其他故障，办公室协同技术应急小组，制定应急方案，上报领导小组，并及时通知相关业务部门。必要时应急领导小

组到达现场指挥应急处理。

4．2．4 红色预警-一级预警的应急响应。机房值班人员立刻上报应急办公室和应急领导小组，各技术应急小组、应急办公室、领导小组成员半小时内到达现场。应急办公室通知相关业务部门，应急领导小组上报省分行主要领导。应急领导小组组织应急方案，上报省分行主要领导，待方案批准后，领导小组统一指挥应急处理的实施。

4．3系统应急响应

4．3．1 蓝色预警-四级预警的应急响应。相关系统的技术维护人员在发现故障后，向运维主管报告故障情况，维护主管组织技术人员登陆故障系统查找、分析故障原因，制定故障处理方案并实施。如果故障在48小时内无法解决或情况迅速恶化，升级为黄色预警。

4．3．2 黄色预警-三级预警的应急响应。相关系统的技术维护人员在发现故障后，向运维主管报告故障情况，维护主管上报应急办公室，并在1小时内到达现场，组织技术人员登陆故障系统查找、分析故障原因，制定故障处理方案并实施，处理情况报应急办公室。应急办公室及时汇总情况，并上报应急领导小组。如果故障在2小时内没有得到解决，或情况进一步恶化，则升级到橙色预警。

4．3．3 橙色预警-二级预警的应急响应。机房值机人员或相关系统的技术维护人员在发现故障后，通知运维主管，维护主管上报应急办公室。运维主管组织技术人员半小时内到达现场登陆故障系统进行故障分析、诊断。应急办公室上报应急领导小组，并发布故障预警级别，应急办公室和领导小组人员在半小时内到达现场。应急领导小

组组织应急方案的制定，并上报分行主要领导。由应急办公室组织应急方案的实施，并及时向应急领导小组和分行领导汇报应急进展情况。

4．3．4 红色预警-一级预警的应急响应。发生故障后，立刻报应急办公室和应急领导小组，由应急办公室发布红色预警。相关应急小组尽快赶到现场。由应急领导小组组织应急处理。应急领导小组及时向分行主要领导上报应急处理情况。

五、后期处理

在应急处理完成后，应急办公室要及时组织人员做好后期现场的整理、恢复工作，及时会同相关设备、系统厂商完成设备、系统的善后处理；总结应急过程中的问题，完善应急预案和应急处理流程，并及时整理、归档。

六、宣传、培训和演练

应急办公室要定期组织相关的应急宣传和培训，不断加强安全意识。定期组织应急演练，使相关人员熟悉应急流程。加强技术培训，增强应急处理能力。

范文三：电子银行突发事件应急预案

××银行××分行电子银行重大突发事件应急预案

第一章 总则 第一条 为有效处置电子银行突发事件，防止风险扩散和蔓延，提高 快速反应和处置能力,最大程度降低突发事件的危害,保障 电子银行业务安全、稳定、健康发展，依据《××银行电子 银行业务管理办法》《××银行重大突发事件应急预案》及 、 《××银行电子银行重大突发事件应急预案》等有关规定， 制定本预案。 第二条 电子银行突发事件的处置，应坚持在省分行统一领导下，按 照“分级负责、分类处置、快速高效、安全稳妥”的原则， 有关部门密切配合、各级行协调联动，尽快恢复电子银行的 正常运营，最大限度地减少损失和降低不良影响。 第三条 本预案适用于超出事发行的处置能力，或者涉及跨 地区处置范围，需要由上级行负责协调、处置的电子银行重 大突发事件的应急处置工作。 第二章 组织机构及职责 第四条 省分行电子银行处负责建立和完善电子银行突发事件的防 范、处置机制；接收、整理电子银行突发事件的有关信息资

料；协调和督办电子银行突发事件应急处置的落实工作；收 集保管有关档案资料；向主管电子银行业务的行领导报告有 关情况；向相关业务部门通报有关情况；向二级分行通报电 子银行突发事件处理情况。 第五条 办公室、法律与合规处、风险管理处、会计结算处、科技处、 保卫处等相关部门予以配合，负责处置各自职责范围内涉及 电子银行突发事件应急事宜，提出具体应急处理措施并予以 落实。

第三章 突发事件的分类及级别界定 第六条 本预案所指电子银行突发事件是指突然发生，对电子银行业 务正常经营管理带来较大影响，造成或者可能造成客户及我 行重大财产损失、声誉损失，或者可能带来全行性连锁反应 及系统性风险，造成较大社会影响的电子银行紧急事件。主 要包括以下四类: (一) 重大突发电子银行运营事件。主要包括:发生电子银行应用 系统、应用技术出现重大问题,或被人为攻击破坏等而导致 电子银行服务连续中断（正常工作时间内 4 小时或正常工作 时间外 8 小时以上）的事件。

(二)重大突发电子银行案件事件。主要包括:发生批量客户 资料丢失、威胁客户资金安全的案件；发生巨额资金（50 万 以上）被盗案件；发生假冒网站、假冒电话银行及假冒手机 银行等案件。 (三)重大突发电子银行违规操作事件。主要包括:发生从业 人员操作失误或违规操作,导致电子银行业务出现重大差错 或隐患的事件;发生从业人员利用工作便利盗取客户资料、 证书等，引发客户资金风险的事件。 (四)其他电子银行重大突发事件。主

要包括:发生大规模的 电子银行客户群体性事件;其他不可抗力因素对电子银行业 务造成严重影响等事件。 第七条 按照影响范围和严重程度，电子银行突发事件分为 以下三级： （一）涉及跨省范围，有可能影响全行电子银行正常经营管 理活动，或者影响全行电子银行业务稳定的事件，已经或者 即将出现全行性连锁反应，需要全行协同配合共同处置的突 发事件或发生 100 万元以上客户巨额资金损失、危害严重的 突发事件为Ⅰ级电子银行突发事件。 （二）涉及两个或两个以上的地区（市） ，有可能影响全省 农业银行电子银行正常经营管理活动，或者影响全省农行电 子银行业务稳定的突发事件为Ⅱ级电子银行突发事件。 （三）涉及两个或两个以上县（市） ，有可能对辖内农行电

子银行经营管理带来较大影响，或者可能影响全辖电子银行 业务稳定的突发事件为Ⅲ级电子银行突发事件。 第八条 电子银行突发事件等级界定：当电子银行突发事件分级指标 有交叉，难以判断级别时，应按照较高级别处理；当电子银 行突发事件随着事态发展有所升级，按升级后级别处理。 第四章 应急响应 第九条 电子银行突发事件应急响应程序 （一）电子银行突发事件发生时，事发行要立即开展处置工 作，采取有效措施控制事态发展。及时向上级行报告突发事 件情况，上报实行逐级报告制。 （二）各二级分行在接到突发事件情况报告后，应在第一时 间通过电话将情况向省分行电子银行处报告，随后再上报 《××银行电子银行重大突发事件报告表》 （见附件 2）,并 在突发事件处置完毕后上报处置结果。 电子银行突发事件发生后,应该按照有关规定报告本地金融 监管机构。 （三）由省分行发现的电子银行突发事件，电子银行处应向 事发行核实情况，进行事件级别认定，对Ⅰ级和Ⅱ级电子银 行突发事件立即上报省分行主管行领导，并将情况通报相关 二级分行及时有效开展处置工作。属于Ⅲ级电子银行突发事 件，通报相关二级分行处置。

第十条 电子银行突发事件报告内容 二级分行向省分行上报电子银行突发事件应填写《××银行 ××分行电子银行重大突发事件报告表》 （见附件 2） ，内容 包括： （一）发生突发事件的机构名称、时间和联系人。 （二）发生突发事件的原因、性质、等级、影响范围，以及 可能涉及的金额和人数。 （三）事态的发展趋势，可能造成的损失，已经采取和准备 进一步采取的应对措施，需要省分行解决的问题。 （四）其他与本事件有关的内容。 第十一条 电子银行突发事件信息发布 电子银行突发事件发生后，根据管理权

限和规定程序通过有 关媒体对外发布信息或进行公告。二级分行未经授权不得对 外发布电子银行突发事件信息。 第五章 应急处置 第十二条 重大突发电子银行运营事件处置 (一)各级行应加强对电子银行业务的监测和维护,及时处置 电子银行运营事件，确保电子银行系统连续、正常运行。发 现电子银行应用系统、应用技术重大问题的，首先积极协调 本级行科技部门予以解决；本级行不能解决的，应及时报告 省分行，由电子银行处根据具体情况协调科技部门或上报总 行予以解决。

（二）在阶段时间内由于交易量过大或其他原因造成网络拥 堵的，二级分行应及时向省分行报告，电子银行处协调科技 部门或上报总行解决。 （三）由于通讯设备或公众网络故障造成业务较长时间中断 的，事发行应及时报告省分行，并积极联系设备服务商或网 络运营商，查明原因，排除故障，恢复正常运营。 （四）在解决问题的过程中，要向客户做好解释说明和安抚 工作，及时引导客户通过柜台等其他渠道办理业务，为客户 提供持续的、适当的服务，基本满足客户的需要和期望。 第十三条 重大突发电子银行案件处置 （一）发生批量客户资料丢失、威胁客户资金安全的案件处 置 1.各级行应加强对客户资料等敏感信息的保护。如发生批量 客户资料丢失，从业人员盗取客户资料、客户证书或银行证 书等案件，电子银行主管部门要及时协调保卫部门向当地公 安机关报案，协助公安机关侦破案件。 2.对证书被盗等威胁客户资金安全的，要立即采取果断措 施，通过通知客户更改密码、证书挂失、暂停渠道及在必要 时联系科技部门对涉及客户的账户资金予以暂时冻结等手 段，确保客户资金安全，尽量减小损失和影响。 (二) 发生客户巨额资金被盗案件处置 1.各行应加强对电子银行案件的防范工作。发生客户巨额资

金被盗案件，事发行保卫部门应尽早向公安部门报案，并及 时向省分行报告；省分行接到报告后，保卫处、电子银行处 应协助公安部门侦破案件，协调二级分行保卫部门和电子银 行主管部门帮助客户追缴损失资金。 2.二级分行请求省分行协查可疑交易记录情况、客户账户资 金情况或者客户资料等信息的，须在案件报告中予以说明， 由省分行电子银行部门进行协查后，将结果迅速反馈有关 行。 3.由于农业银行业务、技术等自身原因引发的电子银行业务 风险问题，造成客户资金损失的，应依照相关法律法规，承 担赔偿责任。事发行要首先向客户垫付风险资金，尽量避免 媒体炒作；垫付资金的事发行可及时向上级行报告并申诉理 由，根据案件发生实

际情况向有关责任行追缴垫付资金。 4.各级行在处理客户投诉的过程中，要妥善安抚客户，并根 据案件性质、客户损失金额大小、客户的情绪和社会影响等 因素具体分析，采用不同办法进行处理，尽量把社会负面影 响降到最低限度。 (三)假冒网站、假冒电话银行、假冒手机银行案件处置 1.各级行电子银行主管部门应加强对假冒网站、假冒电话银 行和假冒手机银行的监测和预警。发现假冒网站、假冒电话 银行和假冒手机银行的，要将有关情况及时报告本级行保卫 部门，由保卫部门负责向所在地公安机关报案，各行保卫部

门同时负责将有关情况上报省分行保卫处。 2.二级分行电子银行主管部门负责将假冒网站、假冒电话银 行和假冒手机银行有关情况上报省分行电子银行处并填写 《假冒网站（假冒电话银行、手机银行）和可疑电子邮件举 报通知书》 （见附件 3） ；负责跟踪假冒网站、假冒电话银行 和假冒手机银行的关闭情况，及时将跟踪情况向省分行电子 银行处报告。 3.省分行保卫处负责将事发行公安部门无法关闭假冒网站 等情况向省级公安部门报告，并协助尽快查处关闭相关假冒 网站、假冒电话银行或假冒手机银行。省分行电子银行处负 责将假冒网站等情况上报总行电子银行部，并跟踪假冒网站 等的关闭情况。 第十四条 重大突发电子银行违规操作事件处置 (一)发生操作人员操作失误或违规操作，导致电子银行业务 重大差错或风险的处置 各级行电子银行部门应加强对电子银行从业人员的业务培 训和管理，避免违规操作事件的发生，发现问题要立即采取 措施纠正。对从业人员违规操作引发的重大突发事件，事发 行要迅速启动本级应急预案,开展先期处置工作，对事件进 行调查,核查事件发生真相并评估由此形成的危害程度及影 响范围,组织协调有关单位及部门,采取积极的补救措施及 后续管理措施,做好控制和降低风险的各项工作，并及时向

上级行报告。 (二)发生从业人员利用工作便利取得客户资料、证书，引发 客户资金风险的处置 各级行电子银行部门应加强对电子银行从业人员管理，发现 问题应立即责令离岗，委派其他人员追索丢失资料。尽快联 系科技部门对涉案资金予以暂时冻结，通知客户更换账户密 码，必要时通过保卫部门向公安部门报案。 第十五条 其他电子银行重大突发事件处置 (一)各级行电子银行主管部门应加强监测和预警。当行内发 生大规模的电子银行客户群体性事件或其他不可抗力因素 对电子银行业务造成严重影响等事件时,必须立即向上级行 报告。办公室、宣传部门要密切关注外界媒体动向，配合

电 子银行主管部门利用正面宣传平息事态。 (二)发生大规模电子银行客户群体事件和不可抗力因素对 电子银行业务造成严重影响的事件，事发行要立即开展先期 处置工作，做好客户解释和安抚工作，把影响降低到最小程 度。

(三)根据电子银行突发事件的严重程度，必要时省分行组织 相关部门成立突发事件工作组，迅速赶赴现场，指导突发事 件处置工作。 第十六条 各级行处置电子银行突发时间时必须严格执行相

应的保密规定。 第六章 后期处置 第十七条 事后调查与情况总结 （一）突发事件处置完毕后，各事发行电子银行部门应对突 发事件、应急处置工作的有关过程及处置结果进行全面总 结，对由突发事件导致的直接和间接损失情况进行收集整理 和量化统计，并向上级行电子银行部门作出正式报告。 （二）各级行应针对电子银行突发事件处置过程中暴露出的 问题，提出切实可行的防范措施和办法，对业务制度、安全 控制方式和技术手段等进行改进和完善,并进一步修改、完 善本级应急预案。 第十八条 责任与奖惩 （一）电子银行突发事件处置工作实行领导负责制和责任追 究制。对发生下列情况的直接责任人和相关责任人给予纪律 处分或者给予相应的行政处罚，并对单位有关负责人进行问 责。 1.违反本预案规定，漏报、瞒报、谎报突发事件，造成严重 后果的； 2.违反制度规定或因失职、渎职行为造成突发事件发生的； 3.突发事件发生后没有采取有效措施处置，造成重大损失或 事态扩大，影响恶劣的。 （二）对在重大突发事件应急管理和处置工作中作出突出贡

献的集体和个人给予表彰和奖励。 第七章 附 则

第十九条 本预案由××银行××分行（电子银行处）制定、 解释和修订。 第二十条 各二级分行应根据本预案，结合各行实际制定本 行电子银行突发事件应急预案，报上级行备案后实施。

范文四：电子邮件系统应急预案

电子邮件系统应急预案

第一章 总则

一、目的

全面应对通信网络突发事件，确保通信业务安全畅通，提高应对突发事件的综合管理水平和应急处置能力。

二、工作原则 （一）指导原则

统一指挥，分级负责，信息共享，密切协同，快速反应，保障有力。

（二）保障原则

在“先重点，后一般；先抢通，后抢修”总体原则下。 重点保障重点用户、收费用户的使用。

（三）编写原则

遵循面向业务的原则，具备可操作性，涉及的环节尽量少，启动的时间尽量短。

三、编制依据

电子邮件系统应急预案制定依据为省公司我部门考核的要求，以及为了确保广大邮箱用户正常使用的基础上制定的。

电子邮件系统应急预案备件使用参照《数据网备品备件管理制度》。

四、适用范围

应急预案适用范围，为辽宁通信公司省网管中心的邮件系统在设备故障、自然灾害及其他突发事件中遭到破坏情况下的应急处置和业务恢复。

第二章 组织机构和职责

一、组织机构

为保证通信安全，在通信网络出现阻断或业务疏通能力大幅下降时，能够迅速采取有效保障措施。

1、通信保障领导小组

2、电子邮件系统通信保障实施小组

二、工作职责

应急预案要以应对电子邮件系统突发事件进行响应的全过程为主线，即自突发事件发生、预警开始，到业务保障和设备恢复的全部结束为止，明确每个环节的主办部门与协办部门，明确各部门的职责。

各级通信保障实施小组职责负责预案的具体实施，组织抢通、抢修通信设施，并跟踪处理解决结果，及时汇总上报。

各级设备维护中心负责组织制定、修改和完善专业设备应

急预案，并定期组织预案的演练工作。

第三章 应急响应

一、预警

通过对网络设备日常运行数据和网络中业务流量的监测，对全网通信安全造成重要影响的信息进行收集和分析。

按照早发现、早处置、早报告的原则，明确影响范围，建立信息传递渠道，落实责任机制，加强监督管理，采取有效措施保障网络安全运行。

一般情况下，应逐级报告，遇紧急或特殊情况，准许越级报告，并于报告后逐级补报。

二、电子邮件系统的应急响应处置

1 电子邮件系统的工作流程

AIMC系统工作流程图

1.1 SMTP 的工作流程

1.2 Web Mail的工作流程

1.3 POP3的工作流程

1.4 IMAP4的工作流程

2 应急预案

影响业务的故障点

电子邮件系统主要有四种业务：smtp/pop3/imap4/webmail。从系统物理结构分析，四种业务的工作流程都涉及到邮件业务系统、用户认证系统、邮件存储系统、磁盘阵列、网络系统（电子邮件系统物理结构图和配置列表见附件2和附件3），webmail 除以上子系统外还涉及到webserver 服务器。每个子系统都可能成为影响业务的障碍点。

相应的应急预案

针对每个障碍点制定了相应的应急预案，并且每个应急预案有相应的启动条件，当满足某个条件时，就启动相应的应急预案。当故障发生后，值班人员首先根据故障现象判断故障点，并启动相应的应急预案；如果无法判断故障点或者不能启动应急预案，要立即通知系统管理员处理。每个障碍点对应的应急预案只适用于本障碍点，不能够屏蔽其他障碍点。

各个子系统的应急预案汇总如下：

2.1 webserver应急预案

启动条件

当发生下列情况之一，在规定的时间内无法恢复时，启动webserver 应急预案：

⑴、两台主用webserver 由于进程运行异常，页面无法正常显示； ⑵、两台主用webserver 的页面被篡改； ⑶、硬件故障，致使webserver 无法启动。 判断方法

Webserver 服务器共有两台，IP 地址分别为202.96.74.113和202.96.74.114，端口为2080。故障判断时，应该对这两台服务器分别做检查。例如：检查202.96.74.113这台机器，URL 为 http://202.96.74.113：2080，查看页面显示是否正常。

启动步骤

⑴、停掉主用的webserver ，启动备用的webserver 。启动备用webserver 的操作需要5分钟时间。

登录mail5.online.ln.cn 和mail6.online.ln.cn $ cd /opt/aihttpd/bin $ ./apachectl stop 登录mail8.online.ln.cn $ cd /opt/aihttpd/bin $ ./apachectl start

⑵、如果主用webserver 的页面被篡改，替换出现问题的webserver 的页面文件后，再重启webserver 。

$ cd /opt/aimc

$ tar xvf webroot.040430.tar $ cd /opt/aihttpd/bin $ ./apachectl stop

$ ./apachectl start

此项操作如果从备份目录获取页面文件，需要5分钟时间；如果从备份带获取页面文件，需要10分钟时间。

注意事项

⑴、在日常维护中，应当定期检查备用web server的可用性，并检查备份带和磁带机的可用性，定期更新备份文件和备份带。

⑵、在网络小组的协助下，通过apache server 的事务日志和系统登录日志查找攻击源，及时在前端路由器上进行封堵。

⑶、主用的webserver 服务器在南机房20、21机柜上，机器名称为 mail5.online.ln.cn 、mail6.online.ln.cn 。备份文件存放在mss1存储服务器/home1/backup。

撤销条件

当出现故障的webserver 恢复时，将备用的webserver 停掉，并启动已经恢复的webserver 。

登录mail5.online.ln.cn 和mail6.online.ln.cn $ cd /opt/aihttpd/bin $ ./apachectl start 登录mail8.online.ln.cn $ cd /opt/aihttpd/bin $ ./apachectl stop

2.2 用户认证系统应急预案

启动条件

当发生下列情况之一，在规定的时间内无法恢复时，启动用户认证系统应急预案：

⑴、aiuum 进程运行异常；

⑵、aiuum 无法连接oracle 数据库，或者无法读取数据库的aiuum 数据字典；

⑶、oracle 数据库运行异常；

⑷、uas0、uas1服务器硬件故障，致使服务器无法启动。 判断方法

⑴、很多用户通过客户端软件（outlook 、foxmail ）或者webmail 方式收发邮件时频繁提示“密码不对”或者“你没有访问此邮箱的权限！”, 可以断定是用户认证服务器的问题。

⑵、在uas0、uas1上运行如下命令：

/opt/aiuum/bin/ServicePool monitor查看aiuum 服务进程组的运行信息。如果运行信息中的“CurrentProcessCount=0”，表明连接数据库失败，或者无法读取数据库的AIUUM 数据字典。

启动步骤

⑴、在前台业务服务器上修改aimc.ini 配置文件，将下面红色字体修改为 Server1=9 10.1.32.3 8889 10

[UAPI]

;Backend: 1-LDAP, 2-RADIUS, 4-System, 8-Oracle, 16-OCS, 128+-WAN Server0=0 0.0.0.0 0 0 ; the backend,ip/connect_string,port and rate of the certify servers

Server1=9 10.1.32.1 8889 10 10.1.32.2 8889 10 Server2=0 0.0.0.0 0 0 ⑵、重启aimc 进程 cd /opt/aimc ./aimc_stop ./aimc_start 注意事项

⑴、启用备用认证数据库后，用户信息将不能进行增、删、改操作，但不影响用户认证。

⑵、此项操作需要修改10台业务服务器的配置，每台服务器需要2分钟时间，总共需要20分钟时间。这项操作的最佳配置为2个人，分别负责5台业务服务器，这样共需要10分钟时间。

撤销条件

当uas0、uas1的数据库恢复正常时，可以将前端业务服务器上的aimc.ini 配置文件改回，重启aimc 进程并进行测试。

2.3 邮件存储系统应急预案

采用1台SUN E6500和2台SUN E3500组成邮件存储服务器群，实现MSS （Mail Storage System ）功能。3台MSS 之间通过软件进行负载分担。服务器上配置了Veritas File System 、Veritas Volume Manager 软件，提高了文件访问的效率，同时，配置了Veritas Cluster Server软件进行负载分担和互为备份：任何一台服务器出现故障其他服务器都可以马上接替其工作，配置了一台HUB 配合负载分担的切换工作。

3台存储服务器都采用双千兆网卡与Catalyst4006连接，每台服务器上的两块网卡都同时工作，绑定1个IP ，平时一块网卡作为备用网卡，当主网卡出现问题或者网线出现故障时，备用网卡会自动接管主网卡工作，做到无缝切换。

启动条件

当发生下列情况之一，在规定的时间内无法恢复时，启动邮件存储系统应急预案：

⑴、某个mailroot 对应的mss 进程运行异常； ⑵、mss 服务器硬件故障。 判断方法：

⑴、很多用户通过客户端软件（outlook 、foxmail ）或者webmail 收取邮件时，连接总是超时或者提示“系统I/O error ”，可以判断为邮件存储系统的问题。

⑵、通过mapi 命令查看某个mailroot 对应的mss 进程运行状态： ①、uapi –s 邮箱内部uid –f location查看用户的mailroot 值，例如为0；

②、telnet 到这个mailroot 对应的存储服务器上，执行如下命令： /opt/aimc/0/mapi/bmb 邮箱内部uid

如果系统报错或者超时，表明mailroot 对应的mss 进程有问题。 启动步骤

将这个mailroot 切换到其他存储服务器上。以root 权限登录mss 服务器，执行如下操作：

#hagrp –switch ServicesGroupName –to sysName

其中ServicesGroupName 为 mss0 mss1 mss2 mss3 mss4 mss5（mss*表示资源组的名称）

sysName 为mss0 mss1 mss2（mss*表示存储服务器的名称）

执行上述操作后，通过hastatus 命令查看切换是否正常 撤销条件

当原mss 进程恢复正常时，将对应的mailroot 手工切换回原存储服务器上。

2.4 磁盘阵列应急预案

方案说明

存储子系统拓扑图

当邮件系统连接的磁盘阵列由于光纤交换机、磁盘阵列、磁盘、光通路阻塞，或者veritas volume manager 软件等故障导致磁盘阵列上的mailroot 不能挂接到前端存储服务器时，可以在前端存储服务器的本地硬盘建立临时mailroot 以保证邮件收发服务。

在启动应急预案前，首先判断故障点，如果是硬件故障，替换相应的硬件；如果是软件原因，联系相关人员处理；如果在规定的时间内无法判断出故障点或

者无法恢复故障点，应当启动磁盘阵列应急预案。

启动条件和存在的问题

当发生下列情况之一，在规定的时间内无法恢复时，由系统管理员，向省数据局应急预案指挥小组请示，批示后启动邮件存储系统应急预案：

⑴、磁盘阵列故障，导致磁盘阵列不可用；

⑵、光纤交换机、HBA 卡、光纤故障，导致光通路阻塞；

⑶、veritas volume manager软件故障，导致无法mount 到逻辑盘； 判断方法：

⑴、磁盘阵列（硬盘，SP 磁盘控制器，电源，风扇）如果出现硬件故障，都可以通过点击Navisphere Manager图形化管理工具Storage Button查看Physical 选项来确定。

⑵、通过光纤交换机和SP 磁盘控制器的状态灯，可以确定光通路是否堵塞。 ⑶、在mss 服务器上执行 # cd /dev

# ls clsp*

如果可以列出clsp0, clsp1的设备名称，说明磁盘阵列已经被系统识别，可以判断HBA 卡没有问题。

⑷、当很多用户反映接收不到磁盘阵列中的邮件时，可以判断是磁盘阵列故障。

存在问题

本预案启动后，用户将无法收取保留在磁盘阵列中的邮件；在邮件回迁的过程中，用户将无法收取保留在临时盘上的邮件。但是，用户保留在磁盘阵列或者临时盘上的邮件都不会丢失。这些问题要通知各市局值班人员和投诉部门，及时向用户做解释工作。

启动步骤

⑴、规划mailroot

在前端存储服务器上准备临时mailroot 。mss0、mss1的本地硬盘空间比较大，而且可以扩展多块硬盘，而mss2的本地硬盘空间小，无法扩展硬盘，因此mss0、mss1将分别存储3个mailroot 的邮件，具体规划如下：

mss0 对应 m0、m2、m3

mss1对应 m1、m4、m5

⑵、建立mailroot

在mss0上做如下操作：

创建两个目录，分别为/home、/home1,在这两个目录下建立相应的mailroot ，并将目录属主变为aimc 。 cd /home; mkdir m0

chown –Rf aimc:aisoft /home/m0 touch /home/m0/m0 cd /home1; mkdir m2

chown –Rf aimc:aisoft /home1/m2 touch /home1/m2/m2 cd /home1; mkdir m3

chown –Rf aimc:aisoft /home1/m3

touch /home1/m3/m3

在mss1上做如下操作：

创建一个目录为/home1,在这个目录下建立相应的mailroot ，并将目录属主变为aimc 。 cd /home1; mkdir m1

chown –Rf aimc:aisoft /home1/m1 touch /home/m1/m1 cd /home1; mkdir m4

chown –Rf aimc:aisoft /home1/m4： touch /home1/m4/m4 cd /home1; mkdir m5

chown –Rf aimc:aisoft /home1/m5

touch /home1/m5/m5

注意事项

①、在日常维护中不要删除上述目录，也不要占用这些目录的磁盘空间。正

常情况下，临时盘可以存储系统2天的邮件信息，如果启用应急方案后，发现临时盘磁盘空间不足，应该及时增加新硬盘。

②、以上操作事先应当准备完毕，应急预案启动时需要检查临时mailroot 的可用性，大约需要2分钟时间。

③、当mss0或者mss1不可用时，将所有的mailroot 规划到一台mss 服务器上。

⑶、停止HA 服务

以root 身份分别在mss0、mss1、mss2做如下操作：

hastop -local –force cd /etc/rc3.d

mv S99vcs s99vcs

此项操作需要5分钟时间。

⑷、修改IP 地址

在mss0上作如下操作： ifconfig ge0:4 plumb

ifconfig ge0:4 inet 10.1.42.3 netmask 255.255.0.0 up

在mss1上做如下操作： ifconfig ge0:4 plumb

ifconfig ge0:4 inet 10.1.43.3 netmask 255.255.0.0 up

在mss2上作如下操作： ifconfig ge0:2 down

ifconfig ge0:3 down

此项操作需要5分钟时间

⑸、修改配置文件

在mss0上做如下操作： cd /opt/aimc/0

mv mss.ini mss.ini.操作人. 时间 cp mss_yj.ini mss.ini

cd /opt/aimc/2

mv mss.ini mss.ini.操作人. 时间 cp mss_yj.ini mss.ini cd /opt/aimc/3

mv mss.ini mss.ini.操作人. 时间

cp mss_yj.ini mss.ini

在mss1上作如下操作： cd /opt/aimc/1

mv mss.ini mss.ini.操作人. 时间 cp mss_yj.ini mss.ini cd /opt/aimc/4

mv mss.ini mss.ini.操作人. 时间 cp mss_yj.ini mss.ini cd /opt/aimc/5

mv mss.ini mss.ini.操作人. 时间

cp mss_yj.ini mss.ini

此项操作需要3分钟时间。

⑹、重启mss 服务

重启mss 进程，并且观察restart.log 及测试服务是否正常。 cd /opt/aimc ./aimc_stop ./aimc_start

tail –f restart.log

注意事项

①、所有启动应急预案的准备工作总共需要15分钟时间。

②、当故障在15分钟内无法修复时，就应该从两方面入手：1、继续查找故障原因，争取修复故障。2、开始应急预案实施前的准备工作，如果故障在规定的时间内无法恢复，将启用应急预案。

③、有些准备工作可以并行操作，例如：检查临时mailroot 的可用性、停止HA 服务、修改配置文件；有些工作必须串行工作，例如：修改ip 地址必须在

停止HA 服务之后操作。因此，准备工作的最佳人员配置为2个人，一个人负责检查临时mailroot 的可用性和修改配置文件，一个人负责停止HA 服务和修改ip 地址，这样整个准备工作需要10分钟时间（详细流程见附件1）。

撤销条件及撤销步骤

⑴、撤销条件

如果磁盘阵列恢复正常，首先将应用回迁到磁盘阵列上，再将临时盘上的邮件回迁到磁盘阵列上。

⑵、撤销步骤

①、恢复其他主机配置及服务

当磁盘整列恢复后，先恢复各存储服务器的配置文件和ip 地址，并手工将磁盘阵列挂接导存储服务器上，重启mss 服务进程，观察服务是否正常。

②、回迁用户邮件

当服务稳定后，在临时mailroot 所在主机上进行邮件回迁磁盘阵列的操作。下面是回迁用户邮件的shell 脚本，参数是临时mailroot 的ID 。以Aimc 用户执行： cd /opt/aimc/setup

nohup migrate.sh mailrootid &

#!/bin/sh

if [ $# -lt 1 ];then echo "$0 "

exit 1

fi

cd ${HOME}/setup

mrhome=`inifile ../$1/config/mss.ini MSS MailDir`/m$1

userlist=`find ${mrhome}/MB/ -name mailinfo.dat|nawk -F/ '{printf("%s ", $(NF-1));}'`

cd ../$1/mapi

rm -f ${HOME}/setup/mail$1.lst

for user in ${userlist}

do

bmb ${user} | nawk -v prefix=${mrhome}/MF -v uid=${user} '{ if($8=="UserLevel") {

groupid=$10

}

if($1==">") {

mf=substr($(NF-8), 4, length( $(NF-8) ) - 4 );

tmp="00000000000"mf;

len=length( tmp );

printf( "%s %s/%d/%d/%d/%d\n", uid, prefix, substr( tmp, len - 7, 2 ), substr( tmp, len - 5, 2 ), substr( tmp, len - 3, 2 ), substr( tmp, len - 1, 2 ) , groupid );

}

}' >> ${HOME}/setup/mail$1.lst

done

awk '{if ($3!="1") { print $1 " " $2}}' mail$1.lst >> mail$1.uid cd ${HOME}/setup

nawk -v mr=$1 '{if( system( "echo "$1" > usr"mr".dat;grpsend -d now -u 1-1 -f "$2" -o usr"mr".dat") != 0 ) print $0; }' ./mail$1.uid > error$1.lst

邮件回迁的原理为：

a 、首先指定mss 服务器上的某个不用的mailroot 作为邮件回迁时的源mailroot （下面称之为临时mailroot ）。修改临时mailroot 的mss.ini 配置文件，将mail directory（MailDir ）指向相应MB 、MF 所在的目录。

b 、用bmb 的方式获取磁盘阵列故障期间都有哪些用户收到了邮件，邮件存放的位置及用户等级。

c 、根据用户等级的不同（用户等级等于1为免费用户）将收费用户和重要用户提取出来。

d 、用aimc 的发送邮件工具grpsend 先将收费用户和重要用户的邮件回迁到磁盘阵列中，并保持发件人、发信时间等邮件信息不变；再将免费用户的邮件回迁到磁盘阵列中。

e 、所有用户的邮件回迁完毕后，将临时mailroot 下的mss.ini 配置文件恢复为原来的配置。

注意事项

⑴、磁盘阵列应急方案只提供邮件收发服务，对于用户在原邮箱设置的邮箱信息，如过滤规则，地址簿，邮件到达通知等没有提供。同时搬迁脚本只回迁用户邮件，对于用户在临时mailroot 设置的邮箱信息，包括过滤规则，地址簿，邮件到达通知等没有搬迁。

⑵、当邮件存储系统的3台mss 服务器都不可用时，将临时mailroot 加载

到备份的用户认证服务器上。

⑶、回迁用户的操作应当按照“先重点、后一般”的原则进行。由于待回迁的邮件很多，需要很长时间完成。因此，应当将收费邮箱和重点邮箱（企业邮箱、政府邮箱）的邮件分拣出来，先对这部分邮件进行回迁，再对免费邮箱对应的邮件进行回迁。

⑷、当用户邮箱保留在临时盘上和磁盘阵列上的邮件大小总和超过邮箱的quota 值时，临时盘上的部分邮件将无法回迁到磁盘阵列上。

⑸、用户等级为0的邮箱表示为自定义邮箱，quota 值在mailinfo.dat 控制文件中定义。当启动应急预案后，这部分邮箱的quota 值变为系统缺省大小，即1M ，因此需要手工修改这部分邮箱的quota 值。

⑹、回迁邮件过程可能会遇到一些非可预见的问题，需要厂家技术支持。但是，电子邮件系统的维保服务已经过期，厂家原则上不予提供技术支持。如果省数据局无法协调厂家提供技术支持时，需要省公司协调解决。

⑺、磁盘阵列应急预案中涉及的步骤比较多，预案中列出的时间只是每个操作步骤需要的时间，处理故障的响应时间还与很多因素有关，例如：值班人员是否能够处理、系统管理员是否具备处理条件、是否能够立即响应，考虑到以上因素可能满足不了故障处理的时限要求。

⑻、EMC CLARiion4500磁盘阵列的模块（SP 磁盘控制器、电源、风扇、sps 电源、光纤交换机）都是全冗余设计，某个模块损坏将不影响业务。但是在极端情况下，两个模块同时损坏，整个磁盘阵列将不可用，需要立即更换坏件，且在更换坏件时需要厂家提供技术支持。鉴于以上情况，应该购买磁盘阵列相关的备品备件和厂家技术支持服务。

2.5 网络系统应急预案

aimc 系统在网络上采用2台四层交换机Alteon 184和2台Catalyst 4006组成。采用四层交换机是为了实现多台业务服务器之间的负载分担，由于Alteon 184只有8个端口，所以需要使用Catalyst 4006扩展端口，连接更多的服务器。

Alteon 184和Catalyst 4006均采用双备份双连结，防止单点故障。 启动条件

在极端情况下，两台alteon184交换机都不可用时，应当启用备用alteon 交换机进行替换。

启动步骤

⑴、将配置文件通过tftp 方式上传到备用alteon180e 交换机，确认配置没有问题。

⑵、将alteon184上的链路按照相同的端口号切换到备用的alteon180e 上，并观察应用是否恢复。

注意事项

⑴、配置文件中涉及到“alteon184”的字样一定要更新为“alteon180e ”。 ⑵、如果上联链路或者上联端口有问题，联系网络小组，协助查找故障原因。网络小组人员联系方式：

岳 峰：81259122

孟 涛：81903066

陶世阳：81885979

撤销条件

当主用的alteon184交换机恢复时，将相应的链路从备用的alteon180e 切换回alteon184上。

2.6 厂家联系人员名单及方式

3 附件

3.1 附件1 启动磁盘阵列应急预案流程图

启动磁盘阵列应急预案流程图

3.2 附件2 电子邮件系统物理结构图

电子邮件系统物理结构图

3.3 附件3 电子邮件系统基本配置列表

第四章 附则

一、预案修订与更新

应急预案的动态管理是保证预案具有针对性及可操作性的重要基础工作和基本要求。各级预案应明确修订周期。将预案修订应作为预案本身的一部分，并纳入年度维护作业计划。

原则上，各级应急预案的修订工作暂定为一个自然年度周期。

由于设备更新、升级、改造以及其他原因导致网络资源发生变更时，要随时进行修改。

应急预案中涉及的人员、联络方式、号码等变动时，应随时组织修改更新。

二、预案学习与演练

预案涉及到的所有部门要对预案进行有针对性的操作培训。

在各级网管中心的统一指挥调度下，进行模拟训练和预案演习。

应将预案学习与演练例纳入年度维护作业计划。

范文五：银行外汇金宏系统应急预案

附件3:

银行外汇金宏系统应急预案

在外汇金宏系统上线过程中～为了应对可能出现的风险～确保国际收支统计申报数据报送的及时性、准确性、完整性以及进出口核销业务的正常开展～特制定本应急预案。

一、人员要求

应急预案由国家外汇管理局及其分支机构,以下简称外汇局,和外汇金宏系统工作小组负责组织实施。

二、适用范围

外汇金宏系统应按照国家外汇管理局规定的时间在全国范围内进行上线～如果外汇金宏系统在上线过程中出现故障导致银行的新业务数据连续一周,7日,无法通过外汇金宏系统报送外汇局～或者银行自身计算机处理系统,包括其接口程序,出现问题导致银行连续一周,7日,无法通过接口向外汇金宏系统报送基础数据～外汇局和银行应当启动本应急预案。

三、应急预案的内容

,一, 应急预案一:如果银行自身计算机处理系统,包括其接口程序,出现问题导致银行连续一周,7日,无法通过接口向外汇金宏系统报送基础数据～则银行应当向外汇局报告～由外汇局开放外汇金宏系统基础信息手工录入功能后～银行应将新业务数据手工录入到外汇金宏系统,银行版,中。

- 27 -

银行自身计算机处理系统,包括其接口程序,故障消除后～应当于第二个工作日内向外汇局报告～由外汇局关闭外汇金宏系统基础信息手工录入功能～银行恢复通过接口程序向外汇金宏系统报送业务数据。

,二, 应急预案二:如果外汇金宏系统在上线过程中出现故障导致银行的新业务数据连续一周,7日,无法通过外汇金宏系统报送外汇局～则外汇局应当暂停外汇金宏系统～启用如下应急措施:

1. 客户仍应按照《通过金融机构进行国际收支统计申报业务操作规程,试行,》的规定办理国际收支统计申报～收入网上申报客户暂时改为纸制申报形式前往银行提交相关凭证。

2. 银行应当妥善保存纸制相关凭证～待外汇金宏系统恢复正常运行后集中补录或导入相应的业务数据。

3. 进出口核销系统相应启动应急措施～外汇局采用手工方式在进出口核销系统录入核销信息～以便企业正常办理进出口核销业务。

4. 外汇金宏系统故障消除后～外汇局应当于第二个工作日内通知银行恢复启用外汇金宏系统～银行在补录或导入相应数据后报送外汇局。

三、应急预案的启动程序

,一, 对于因银行自身计算机处理系统,包括其接口程序,存在问题而导致新业务数据连续一周,7日,无法导入金宏工程外汇

- 28 -

金宏系统并报送外汇局的～该银行应向外汇局报告～由外汇局启动应急预案一。

,二, 对于因外汇金宏系统存在问题而导致各银行连续一周,7日,无法报送新业务数据的～国家外汇管理局将以发文的形式在全国范围内启动应急预案二。

五、应急预案启动后的后续处理

,一, 对于银行自身计算机处理系统,包括其接口程序,存在问题～银行应当尽快查找原因及时解决～并将问题解决时间表报国家外汇管理局。

,二, 对于因外汇金宏系统存在的问题～国家外汇管理局将统一负责尽快解决。

,三, 启用应急预案的相应故障消除后～外汇局应通知银行解除相应的应急措施。

- 29 -

转载请注明出处范文大全网 » 银行系统应急处理预案