电信xx公司计算机系统应急预案演练方案-综合业务支撑系统(IBSS-CRM)-V0.2.doc

广东分公司计算机系统应急预案_综合业务支撑系统（IBSS）V1.0

xxxxxx公司计算机系统
应急预案演练方案
综合业务支撑系统（IBSS&CRM）
Version 0.2

中国电信股份有限公司xxx分公司
2008年06月
修订控制页

修订号
修订日期
修订内容简述
修订人
版本号
1
2008-6-6
初稿
陈军
苏智
唐凯超
陈辉
0.1
2
2008-6-11
审核确认
陈辉
0.2

目 录
修订控制页 2
1. 总则 5
1.1. 编写目的 5
1.2. 适用范围 5
1.3. 编制依据 5
1.4. 编写人员 5
1.5. 解释权 6
1.6. 版权 6
2. 应急演练预案 6
2.1. 演练内容索引 6
2.2. 演练要求 7
2.3. 职责分工 7
2.4. 演练时间安排 7
3. 演练方案 8
3.1. 演练方案1：应用服务器1（含接口）无法提供服务 8
3.1.1. 目的 8
3.1.2. 注意事项 8
3.1.3. 历时要求 8
3.1.4. 参考操作步骤 8
3.2. 演练方案2：应用服务器2（含后台独立进程）无法提供服务 11
3.2.1. 目的 11
3.2.2. 注意事项 11
3.2.3. 历时要求 11
3.2.4. 参考操作步骤 11
3.3. 演练方案3：任意一台数据库服务器无法提供服务 12
3.3.1. 目的 12
3.3.2. 注意事项 12
3.3.3. 历时要求 12
3.3.4. 参考操作步骤 12
3.4. 演练方案4：任意一台数据库和应用服务器1（含接口）无法提供服务 15
3.4.1. 目的 15
3.4.2. 注意事项 15
3.4.3. 历时要求 15
3.4.4. 参考操作步骤 15
3.5. 演练方案5：任意一台数据库和应用服务器2（含后台进程）无法提供服务 16
3.5.1. 目的 16
3.5.2. 注意事项 16
3.5.3. 历时要求 16
3.5.4. 参考操作步骤 16
3.6. 演练方案6：在应急环境下存储系统恢复性测试演练（IT内控要求） 17
3.6.1. 目的 模拟磁盘存储设备出现不可预知的问题导致配置信息或者数据丢失，利用备份好的数据进行恢复工作。 17
3.6.2. 注意事项 17
3.6.3. 历时要求 19
3.6.4. 参考操作步骤 1）、配置信息恢复 19
4. 演练结束 25
5. 附件一：演练记录表格 26
6. 业务验证参考用例 26
6.1.1. 检查主机系统运行状态 26
6.1.2. 检查数据库运行状态 26
6.1.3. 检查IBSS应用状态 26
6.1.4. 进行实单测试 27

1. 总则
1.1. 编写目的
本地综合业务支撑系统（IBSS&CRM）为xxx电信的核心BSS系统之一，其不间断运行的能力对xxx电信有着重要的作用。
本文的编写目的是为各分公司重大系统的应急演练提供指导，确保在系统异常时，可以有序的实施恢复操作，及时恢复业务。
本方案是模拟分公司综合业务支撑系统（IBSS）在运行过程中或者操作过程中出现的常见系统重大故障进行故障处理的演练方案，其目的是增强分公司各部门对综合业务支撑系统（IBSS）故障处理及配合的能力，在发生故障时，能采用快速有效的手段，迅速恢复业务，尽可能减少故障对业务的影响。

1.2. 适用范围
适用系统：综合业务支撑系统（IBSS）1.x，客户关系管理系统（CRM） 2.x
适用对象：各分公司的IBSS系统管理员、维护支撑人员以及其他相关部门的管理人员。
1.3. 编制依据
《xxxxxx公司计算机系统应急预案_综合业务支撑系统（IBSS）_V1.0》，中国电信股份有限公司xxx分公司
1.4. 编写人员
一、xxxxxx公司计算机系统应急预案 编写工作小组人员名单：
组长：孙丹宇
副组长：杜涛
成员：徐文罕、梁振宇、陈辉、林群辉、黄书成、刘长成、陈军、江粤雄、唐凯超（亿迅）、苏智（亿迅）

二、本分册主要编写人员名单：陈军、陈辉、唐凯超（亿迅）、苏智（亿迅）
1.5. 解释权
本规范的解释权属于中国电信股份有限公司xxx分公司。
1.6. 版权
本规范的版权属于中国电信股份有限公司xxx分公司。

2. 应急演练预案
2.1. 演练内容索引
本演练方案包括如下内容，各分公司可以根据实际情况进行调整：
演练
序号
演练预案
演练预案分类
备注
1
应用服务器1（含接口）出现严重故障无法提供服务
单点故障

2
应用服务器2（含后台独立进程）出现严重故障无法提供服务
单点故障

3
任意一台数据库服务器出现严重故障无法提供服务
单点故障

4
任意一台数据库服务器和应用服务器1（含接口）出现严重故障无法提供服务
多点故障

5
任意一台数据库服务器和应用服务器2（含后台独立进程）出现严重故障无法提供服务
多点故障

6
在应急环境下存储系统恢复性测试演练（IT内控要求）
存储故障

特别提示：由于应急演练比较复杂，为确保应急演练正常进行，应该在维护单位的指导下进行。
2.2. 演练要求
演练要求如下：
1、 每系统每年至少演练一次。
2、 每次演练至少演练2.1小节中的两个典型预案。
3、 演练时间建议在业务非营业时间和非业务忙时进行。
4、 演练按照相关维护管理规定进行。
5、 各分公司演练前应在本方案基础上结合本地实际情况制定详细的演练计划和业务验证用例。
6、 每次演练后，需要编写演练总结，对发现的问题及时进行整改。

2.3. 职责分工

部门
职责描述
责任人
联系电话
备注
网络运营部
协调各部门、演练发文通知、组织演练

IT维护中心
负责演练牵头、组织、演练操作

业务支持中心
负责业务运行记录、观察，业务测试工作

10000号中心
负责客户解释工作

网络监控中心
业务运行记录、演练过程监控

亿迅公司
技术支持

2.4. 演练时间安排
演练
序号
演练预案
演练时间范围
备注
1

2

3. 演练方案
3.1. 演练方案1：应用服务器1（含接口）无法提供服务
3.1.1. 目的
模拟应用服务器1（含接口）宕机情况下，无法提供服务，在短时间完成故障处理，恢复业务。
3.1.2. 注意事项
演练过程影响应用服务器2（含后台独立进程）中断服务。
3.1.3. 历时要求
总历时：XX分钟以内。
3.1.4. 参考操作步骤
1、 通知业务支持中心准备开始进行演练，并作相关记录、观察。
2、 模拟应用服务器1（含接口）宕机
3、 用IBSS用户登陆应用服务器2（含后台独立进程）并停掉全部应用
，执行命令如下：
tmshutdown –y –w1
cd /export/home/ibss/batch
ibsssupershell.sh stopall
修改应用服务器2（含后台独立进程）的IP为应用服务器1（含接口）的IP，修改应用服务器2机的机器名为应用服务器1机的机器名。执行:
ifconfig lan0:1 plumb
ifcofnig lan0:1 ibssapp1_IP netmask 255.255.255.0 up
hostname 新主机名（注：应用服务器1的主机名）
4、 修改应用服务器2机/export/home/ibss/batch目录下的配置文件：（注意以下凡是要修改配置文件，修改之前先作好备份）
ibss_process_data 中：
找到第一行，如：ibssapp2 //IP2:4888
修改成应用服务器1的机器名和IP：端口（ibssapp1 //IP1:4888）
当前目录下tux.env 文件，修改下面内容相对的IP：
WSNADDR=//ibssapp2_IP:4888
改为： WSNADDR=// ibssapp1_IP:4888
IMWSNADDR=/ ibssapp2_IP:4878
改为：IMWSNADDR=//ibssapp1_IP:4878
5、 修改应用服务器2机器/export/home/ibss/config目录下ibss域的相关配置
ibss域的ubb修改内容：
ibssapp2 LMID=simple
改为应用服务器1的机器名ibssapp1
WSL SRVGRP=WSLGROUP1 SRVID=210 CLOPT="-A -t -- -n // ibssapp2_IP:4888 -m 50 -M 100 -x 10 -T 10"
修改IP，为：
WSL SRVGRP=WSLGROUP1 SRVID=210 CLOPT="-A -t -- -n / ibssapp1_IP:4888 -m 50 -M 100 -x 10 -T 10"
重新编译ubb：
tmloadcf –y ubb
ibss域dmconfig文件的修改内容：
simpapp NWADDR="//ibssapp2_IP:4688"
NWDEVICE="/dev/tcp"
改为：
simpapp NWADDR="//ibssapp1_IP:4688"
NWDEVICE="/dev/tcp"
重新编译dmconfig：
dmloadcf –y dmconfig
tux.env 文件中修改下面内容相对的IP：
WSNADDR=// ibssapp2_IP :4888; export WSNADDR
改为：
WSNADDR=// ibssapp1_IP:4888; export WSNADDR
6、 重新编译应用服务器2机器上接口域的域间通信dmconfig和ubb。
7、 建立接口目录下的data目录的数据链接link。
8、 将之前备份的应用服务器1机的crontab内容加进应用服务器2机的crontab里，运行crontab –e进入编辑，增加和应用服务器1上一样的内容，保存退出即可。
9、 全部启动应用服务器2上的IBSS域和接口域的所有服务和后台独立进程、适配器进程、转换进程。
进入目录：cd /export/home/ibss/config
执行：. ./tux.env
执行：tmboot –y
进入目录：cd /export/home/ibss/batch
执行：ibsssupershell.sh startall
进入目录：cd /export/home/intf/tuxedo/config
执行：. ./intf.env
tmboot –y
进入目录：cd /export/home/intf/runprog/adapter
执行：adaptersupershell.sh startall
进入目录：cd /export/home/intf/runprog/calltranall
执行：calltranallsupershell.sh startall
10、 通知业务支持中心切换完毕，并进行业务方面的测试。
11、 记录测试结果。
12、 恢复系统运行。

3.2. 演练方案2：应用服务器2（含后台独立进程）无法提供服务
3.2.1. 目的
模拟在ibss系统应用服务器2（含后台独立进程）宕机，无法提供服务，在短时间完成故障处理，恢复业务。
3.2.2. 注意事项
3.2.3. 历时要求
总历时：XX分钟以内。
3.2.4. 参考操作步骤
1、 通知业务支持中心准备开始进行演练，并作相关记录、观察。
2、 模拟应用服务器2（含后台独立进程）宕机
3、 修改相关配置文件
1) 修改应用服务器1（含接口）/export/home/ibss/batch目录下的配置文件：
ibss_process_data
找到头一行：如：ibssapp2 //IP2:4888
修改成应用服务器1（含接口）机器名和IP：端口（ibssapp1 //IP1:4888）
tux.env 中修改下面内容相对的IP：
WSNADDR=// ibssapp2_IP:4888
改为： WSNADDR=// ibssapp1_IP 4888
IMWSNADDR=// ibssapp2_IP:4878
改为：IMWSNADDR=// ibssapp1_IP:4878
2) 建立将之前备份的应用服务器2机的crontab内容加进应用服务器1机的crontab里。
3) 将/export/home/ibss/batch目录下程序赋予执行权限
cd /export/home/ibss/batch
chmod 755 *
4) 启动此/export/home/ibss/batch目录下的独立进程：
ibsssupershell.sh startall
4、 通知业务支持中心切换完毕，并进行业务方面的测试。
5、 记录测试结果。
6、 恢复系统运行。
3.3. 演练方案3：任意一台数据库服务器无法提供服务
3.3.1. 目的
模拟在ibss系统任意一台数据库服务器单机宕机情况下，实现在短时间完成故障处理，恢复业务。
3.3.2. 注意事项
演练过程影响部分连接到故障数据库服务器上的业务（部分业务需要重启，并再连接另一数据库）。
3.3.3. 历时要求
总历时：XX分钟以内。
3.3.4. 参考操作步骤
1、通知业务支持中心准备开始进行演练，并作相关记录、观察。
2、模拟数据库服务器1（IBSS1）宕机 （注：具体模拟方法可以考虑拔网线或者停数据库服务）
3、用oracle用户登陆两台中间件应用服务器1、2
分别修改两台中间件应用服务器上面oracle客户端目录中的tnsnames.ora文件，将故障数据库主机的IP和实例名连接修改为正常的那台数据库2(IBSS2)的连接。
su – oracle9i
cd $ORACLE_HOME/network/admin/tnsnames.ora
修改tnsnames.ora文件
vi tnsnames.ora
将IBSS1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = IBSS1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ibss1)
)
)
修改为：
IBSS1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = IBSS2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ibss2)
)
)
（注：具体主机名、实例名请参照各本地网环境）
4、重启中间件应用服务器1（含接口）的服务和进程
进入目录：cd /export/home/ibss/config
执行：. ./tux.env
执行：tmboot –y
进入目录：cd /export/home/intf/tuxedo/config
执行：. ./intf.env
tmboot –y
进入目录：cd /export/home/intf/runprog/adapter
执行：adaptersupershell.sh startall
进入目录：cd /export/home/intf/runprog/calltranall
执行：calltranallsupershell.sh startall
5、重启中间件应用服务器2（含后台独立进程）的服务和进程
进入目录：cd /export/home/ibss/config
执行：. ./tux.env
执行：tmboot –y
进入目录：cd /export/home/ibss/batch
执行：ibsssupershell.sh startall
6、通知业务支持中心切换完毕，并进行业务方面的测试。
7、记录测试结果。
8、恢复系统运行。

3.4. 演练方案4：任意一台数据库和应用服务器1（含接口）无法提供服务
3.4.1. 目的
模拟在ibss系统任意一台数据库服务器以及应用服务器1（含接口）宕机
况下，实现在短时间完成故障处理，恢复业务。
3.4.2. 注意事项
演练过程影响部分连接到故障数据库服务器上的业务（部分业务需要重启，并再连接另一数据库）。
3.4.3. 历时要求
总历时：XX分钟以内。
3.4.4. 参考操作步骤
1、通知业务支持中心准备开始进行演练，并作相关记录、观察。
2、模拟应用服务器1（含接口）和任意一台数据库服务器宕机
3、参照演练方案1方式修改应用服务器2（含后台独立进程）上面的相关配置。
4、参照演练方案3方式修改应用服务器2（含后台独立进程）上面的数据库连接配置。
5、全部启动应用服务器2（含后台独立进程）上面的IBSS服务和进程。
6、通知业务支持中心切换完毕，并进行业务方面的测试。
7、记录测试结果。
8、恢复系统运行。

3.5. 演练方案5：任意一台数据库和应用服务器2（含后台进程）无法提供服务
3.5.1. 目的
模拟在ibss系统任意一台数据库服务器以及应用服务器2（含后台独立进程）宕机情况下实现在短时间完成故障处理，恢复业务。
3.5.2. 注意事项
演练过程影响部分连接到故障数据库服务器上的业务（部分业务需要重启，并再连接另一数据库）。
3.5.3. 历时要求
总历时：XX分钟以内。

3.5.4. 参考操作步骤
1、通知业务支持中心准备开始进行演练，并作相关记录、观察。
2、模拟应用服务器2（含后台独立进程）和任意一台数据库服务器宕机
3、参照演练方案2方式修改应用服务器1（含接口）上面的相关配置。
4、参照演练方案3方式修改应用服务器1（含接口）上面的数据库连接配置。
5、全部启动应用服务器1（含接口）上面的IBSS后台服务和进程。
6、通知业务支持中心切换完毕，并进行业务方面的测试。
7、记录测试结果。
8、恢复系统运行。
3.6. 演练方案6：在应急环境下存储系统恢复性测试演练（IT内控要求）
3.6.1. 目的
模拟磁盘存储设备出现不可预知的问题导致配置信息或者数据丢失，利用备份好的数据进行恢复工作。
3.6.2. 注意事项
首先应做好磁盘阵列备份工作，具体操作如下：
1）、配置信息备份
磁盘阵列的备份需要通过手工方式将阵列信息及划分情况记录成文档,信息包括RAID方式、LUN的划分。
以EMC CX3-40为例，配置信息列表：
配置项目
设置
RAID类型
RAID 0+1
LUN 大小
60G/个
端口map
Map到所有端口
连接主机
Ibssdb1，ibssdb2，ibssapp1，ibssapp2
存储组
存储组1（ibssdb1，ibssdb2，lun1-lun20）
存储组2（ibssapp1，ibssapp2，lun21-lun40）

操作系统中所使用的存储划分情况可用以下命令收集：
Sun平台：
# vxprint –ht > [hostname]_vxprint.out
HP平台：
# vgdisplay –v > [hostname]_vgdisplay.out
IBM平台：
#lsvg >[hostname]_lsvg.out
2）、数据备份
l DP备份软件
通过运行软件HP OnmiBack 6.0客户端软件backup选项在文件列表中选择备份策略进行备份（系统平时按定制的策略自动执行备份，也可进行手工备份）。
备份内容
备注
/lbill
一般每月备份一次

l NBU备份软件

打开NBU CONSOLE，然后选择Policies，选中文件系统的备份策略，然后选右键菜单的Manual backup，做手工备份。

3.6.3. 历时要求
总历时：XX分钟以内。
3.6.4. 参考操作步骤
1）、配置信息恢复
阵列配置信息的恢复需要建立在原来信息备份的基础上。阵列配置信息的备份主要是记录配置参数， 如果阵列出现配置信息丢失的情况，通过原来记录的配置参数文档重建RAID及LUN，划分给相应的主机使用即可。
注意：配置信息的恢复操作存在不可逆性，出现此类故障时，建议在厂家的指导下进行。
2）、文件系统数据恢复
阵列的文件系统数据出现丢失时，可以使用最近的备份进行恢复。由于阵列的数据量大，目前我们一般都通过备份软件（DP或NBU）采用磁带库进行数据备份。
基于备份基础之上，如果出现数据丢失，按以下方法进行数据恢复：
l DP恢复步骤
通过运行软件HP OnmiBack 6.0客户端软件restore选项在文件列表中选择需要恢复的文件进行恢复。

l NBU恢复步骤
1. 先进入NBU CONSOLE
2. 选FILE菜单，选择backup、archive、restore

进入到这个界面：

选择FILE ->　specify netbackup machines and policy type

选择恢复的server，source and destination client
在这里server 选master，source client 选择要恢复的client，destination如fsibss1，并点选make current设为current，在policy type中如果client为unix file system 则选取standard。如下图所示：

将destination client设为fsibss1，并设为current，如下图：

按确定，就会弹出恢复窗口：

选择要恢复到的日期，选择要恢复的文件或目录，按左侧的restore按钮，执行恢复。

点选view status，可以查看恢复的情况。

4. 演练结束
按计划完成演练工作后，IT维护中心负责将ibss系统切换到正常状态，负责做好测试确认，确保系统及业务运行正常后通知相关部门及参与人员演练工作结束，并做好记录。
演练结束后，由IT维护中心负责编写演练工作报告，并对根据演练实际情况对应急预案进行完善。

5. 附件一：演练记录表格
演练方案：
序号
演练细项
负责人
历时
演练情况
签字
备注

6. 业务验证参考用例
6.1.1. 检查主机系统运行状态
1. 用户可以正常登录主机 su - ibss
6.1.2. 检查数据库运行状态
1. 使用tnsping 数据库实例名 检查数据库启动
2. 使用sqlplus 用户名/密码@实例名 检查用户名/密码正确
3. 执行一个SQL, select * from tb_pm_product 检查数据正常
6.1.3. 检查IBSS应用状态
1. 使用ps -ef |grep WSL|grep -v grep查看启动了哪些域
显示结果格式如下：
ibsstest 16863 1 0 Apr 20 ? 0:19 WSL -C dom=ibss -g 31 -i 210 -u ibssapp -U /home/ibsstest/testa
“dom=”后面的就表示已经启动的中间件域名；有多少行就表示启动了多少 个不同的域
2. 执行：ps -ef |grep WSL|grep intf 如果有返回就表示有启动接口域。
3. 查看日志文件，看是否有报错信息
6.1.4. 进行实单测试
1. 进行实单测试，查看整个业务流程是否正常

第27页 共27页
内部资料，注意保密