1上海铁路局客票发售和预订系统应急预案实施细则（上铁客发452号）

上海铁路局文件

上铁客发〔2009〕452号

关于重新公布《上海铁路局客票发售和 预订系统应急预案实施细则》的通知

各客运直属站，各车务段，各客运段，浦东、金温公司：

按照应急预案每两年进行修订、补充和完善的要求，结合我局实际，现重新公布《上海铁路局客票发售和预订系统应急预案实施细则》，请认真贯彻执行。

二○○九年十二月三十一日

— 1 —

上海铁路局客票发售和预订系统

应急预案实施细则

为建立健全路局客票发售和预订系统（以下简称“客票系统”）应急保障体系和运行机制，快速、有效地处理客票系统的安全事故和突发事件，根据铁道部《铁路客票发售和预订系统应急预案》（铁运函〔2007〕125号）的要求，结合我局实际，特制定本实施细则。

本实施细则适用于全局（含合资公司）客票系统因网络、设备、软件等故障或遭受大规模“病毒”感染、非法入侵及其它不可预测的因素导致客票系统中断或售票异常的安全事故和突发事件。

1．组织机构及职责 1.1 应急组织机构

路局成立客票系统安全事故和突发事件应急领导小组（以下简称“客票应急领导小组”），由路局主管运输的副局长任组长，路局办公室、客运处、计统处、财务处、电务处、机务处、公安局、宣传部、信息技术所为组员单位。下设应急领导小组

— 2 —

办公室，应急领导小组办公室设在路局客运处，由路局客运处处长任主任，成员由路局办公室、客运处、电务处、机务处、宣传部、信息技术所相关人员组成。

各站段应比照路局成立客票系统应急领导小组和办公室，由有关领导和业务技术部门参加，负责相关售票、客运组织和故障处理等工作。

1.2 客票应急领导小组主要职责

(1)根据铁道部客票系统应急领导小组的指示和要求，指挥本局客票系统安全事故和突发事件的应急处置工作。

(2)根据事故和事件的影响范围和严重性，决定启动相应的应急预案。

(3)指导、协调、检查客票应急领导小组办公室工作。 (4)决定向铁道部客票应急领导小组请求支援和报告。 (5)负责有关紧急事项的决策。 1.3 客票应急领导小组办公室主要职责

(1)负责制定、完善路局客票系统安全事故和突发事件应急预案实施细则。

(2)负责指导站段制定客票系统相关应急措施，监督检查应急预案的应变及快速反应能力。

(3)遇重大情况，负责及时向路局客票应急领导小组汇报。 (4)负责安全事故的应急处置、治安保障、系统恢复、后勤

— 3 —

保障、事故调查、新闻发布工作。

(5)负责向客票系统相关技术支持单位(铁科院、设备供应单位等)请求技术支持。

(6)负责日常具体工作。

1.4 客票应急领导小组办公室成员职责

路局客运处负责组织、协调应急预案处置工作；电务处负责保障客票系统的网络畅通和通讯联系；机务处负责保障客票系统的电力供应；信息技术所负责客票系统安全事故和突发事件应急处置的技术保障和处理工作；办公室负责后勤保障工作；宣传部负责新闻报道和对外新闻发布工作。

2．预防和预警机制

(1)客票系统广域网、局域网必须使用专用通道、独立运行，与外网安全隔离；客票系统终端设备必须为专用设备，严禁安装、使用非客票系统的软件及数据。

(2)客票系统技术维护单位应建立详尽的系统管理、维护台帐，细化系统的维护流程，规范系统的日常维护。

(3)完善客票系统数据清理和备份机制，按照有关规定定期对客票系统的过期数据进行清理，对重要数据进行备份，并建立相关台帐。

(4)加强对客票系统的软硬件监控，按照《上海局客票发售

— 4 —

和预订系统运行管理实施细则》（上铁客发〔2005〕293号）的有关规定对主机系统、网络系统的运行状况进行定期、定时监控，发现问题及时处理，并建立相关监控台帐。

(5)客票系统维护单位要建立主要设备的运行预警指标体系，并依据系统的指标体系对主要设备进行监控，发现异常信息应及时处理和汇报。

(6)路局对车站客票系统的使用和维护情况进行定期巡检和不定期抽查。

3．应急响应 3.1 应急响应标准

铁路客票系统应急响应按安全事故、突发事件的严重程度和影响范围，分为Ⅰ、Ⅱ、Ⅲ、Ⅳ四级：

Ⅰ级应急响应的安全事故和突发事件是指：全路客票系统由于外部攻击及不可抗拒因素造成客票系统严重破坏，导致系统崩溃，中断运行8小时及以上，铁路运输无法正常运行，造成巨大经济损失和政治影响的事故。

Ⅱ级应急响应的安全事故和突发事件是指：铁路客票系统由于外部攻击、设备损毁、数据丢失等原因，导致以下结果之一的事故：

（1）全路客票系统中断运行4小时以上，造成经济损失并严重影响全局运输生产；

— 5 —

待供电正常，若有电，则转(2)；

(2)关闭主机系统及所有主机电源开关；

(3)每台主机分别上电，若不能恢复，尝试用其他临时备用服务器来接管应用，并加紧催促维护厂商修复主机。

3.2.3 存储设备故障 3.2.3.1 一台存储设备故障

检查主机上的应用进程，若售票正常，由于是双存储镜像配置，可以按计划对故障存储设备进行维护，不影响系统正常，并联系厂商尽快恢复。

3.2.3.2 多台存储设备故障

（1）检查供电情况，若无电则关闭机器所有交流直流开关，并关闭主机系统，等待供电正常，若有电，则转（2）；

（2）检查主机上的应用进程，若售票正常，说明存储设备已经自动切换到备份设备上，可以按计划对故障设备进行维护，若不正常，转（3）；

（3）联系厂商尽快恢复。 3.2.4主机系统太慢不能正常使用

（1）检查主机系统（SuperDome、RX4640）和存储系统日志文件，查找有否明确故障根源并得以解决。若不能解决，则转（2）；

（2）整个系统完全重启一次，恢复应用进程，恢复售票。

— 26 —

3.3各联合站主机系统故障应急处理操作步骤

联合站系统配置与路局相比只缺少扩展服务器，当主机发生故障时参照路局客票系统的应急处理步骤。

目前我局客票系统的存储系统均配置为两台镜像，因此，当发生一台故障时，不影响生产。当发生存储系统故障时，一方面联系厂商尽快处理，另一方面视故障的程度启用备用系统。

第四章 客票应用系统

本章节适用于路局地区中心、联合站、车站客票应用系统。 以下是常见的严重故障紧急处理方法。

4.1 路局主机后台营销分析进程没有正常结束，造成售票速度缓慢

现象：

在白天售票高峰期间，出现售票速度缓慢或者是更加严重的程度。

分析及处理过程：

以sybase5用户登录，执行： ps –usybase5

检查进程列表中是否存在以YD或YT开头的进程，如果没有则应分析其它原因。如果有那么执行

isql –Usa –Psa_password

— 27 —

1> sp_lock 2> go

检查输出结果，看dbname列所对应的名字是否有较多的tempdb，并看table_id列所对应的名字中是否有1,2,3之类的表id，如果确认这些，那么需要将营销分析进程杀掉。

4.2 路局中心主机ctms进程占用大量tempdb资源，互相锁定，导致售票速度缓慢或者是更严重的结果。

现象：

在白天售票高峰时段，出现售票速度缓慢或者是更加严重的程度。

分析及处理过程：

在通过（1）方法检查过系统中没有以YD或者YT开头的进程之后，需要对数据库中的锁和线程进行进一步的分析。以sybase5用户登录之后，执行：

isql –Usa –Psa_password 1> sp_lock 2> go

看是否存在大量的锁 1> sp_who 2> go

看是否很多线程很多blk_spid的值不等于0。如果是，那么

— 28 —

重新启动连到主机上的四台ctms应用服务器上的ctms进程。

以ctms5用户分别登录到四台ctms应用服务器，执行： stopctms.sh

输入sa密码：xxxxxxx startctms.sh

4.3 某个联合站出现无法售票(ctms应用服务进程相关) 现象：

在该联合站下面所有的车站均无法售票。 分析及处理过程：

首先检查到该联合站网络是否畅通，如果有问题，通知网络组人员解决。确认网络正常之后，需要判断ctms应用服务器的ip地址是否down，如果是，那么需要车站技术人员重新启动ctms应用服务器操作系统。

如果没有问题，那么登录到该联合站的ctms应用服务器上，重新启动ctms进程。以ctms5用户登录，执行：

stopctms.sh

输入sa密码：xxxxxxx startctms.sh

4.4 某个联合站出现无法售票(应用服务器操作系统相关) 现象：

在该联合站下面所有的车站均无法售票，经初步诊断后确认

— 29 —

应用服务器的ip地址已down。

分析及处理过程：

目前，各联合站配置的专用应用服务器为多台微机服务器，操作系统为Linux，均配置双网卡绑定模式，运行ctms服务进程。在发现应用服务器的IP地址down后，在应用服务器控制台上以root用户登录系统，在命令行键入ifconfig，查看两个网卡的状态，看bond0、eth0、eth1是否均获取IP地址。

如发现应用服务器上述网络服务设备没有获取IP地址，则在命令行键入/etc/init.d/network restart命令，再查看是否已获取IP地址。如已获取IP地址，则再重起ctms服务，故障排除；如获取IP地址失败，则重起应用服务器操作系统。

如多台应用服务器操作系统故障均不能排除，则启动数据库服务器上的ctms服务进程，修改窗口的连接配置参数，将连接请求应急连接到数据库服务器上运行的ctms服务进程，以暂时恢复售票。

4.5 某个联合站出现无法售票(数据库相关) 现象：

车站售票无法售票，经过检查数据库的日志，发现数据库中有错误信息。

分析及处理过程：

针对数据库日志中所产生的错误信息，根据Sybase故障处

— 30 —

理手册进行处理，如果无法处理，由路局技术人员立即联系铁道部总体组和Sybase公司人员处理。

4.6 复制故障处理 （1） 复制数据库挂起

现象：中心修改了基础信息，但是车站（联合站）没有修改。 判别办法：使用命令isql -Usa -P -SH1X_RS,登录复制服务器，运行：

1> admin who_is_down 2> go

检查是否有记录，如果有，那么即为到车站（联合站）的连接挂起；无则正常。

处理办法：根据admin who_is_down命令运行的结果，运行resume connection to XXX_DS.center，（其中XXX代表的是所挂起的车站的电报码，也就是admin who_is_down运行的结果中的Info的名字），如：

Spid Name

State

Info

----------------------- 23

RSI

Suspended MLE_DS.center

（2）复制服务器代理异常停止

现象：中心修改了基础信息，但是所有车站均没有做相应修改。

— 31 —

判别办法：检查数据库的日志文件，看里面是否有如下出错信息，同时登录复制服务器运行admin who_is_down有如下运行结果：

Spid Name

State

Info

----------------------- 23

RSI

Suspended H1_DS.center

处理办法：

?使用命令isql -Usa -Pxxxx –SH1_DS登录数据库服务器，执行：

1> sp_start_rep_agent ‘center’ 2> go

? 运行命令之后，监控数据库日志，并登录复制服务器用admin who_is_down查看到中心的连接是否挂起，直到不再出现该记录。

（3）如何判断铁道部到路局中心复制不正常

现象：路局客票管理所做了基础数据维护，可以查得到数据，但是路局并没有得到相关数据，那么可以判断是铁道部到路局的复制有异常，致电021-49120请铁道部解决。

4.7 数据传输管理(DBCS)

数据传输管理主要完成分布式数据库之间信息的相互透明传送，从而在分布式数据库之间实现数据库的一致性和完整性，

— 32 —

属于松散一致性的数据耦合机制。

（1）启动dbcs 以dbcs5用户登录,执行 cd bin start_server （2）停止dbcs 以dbcs5用户登录,执行 cd bin stop_server

（3）dbcs的运行监控 以dbcs5用户登录，执行 cd scripts/monitor vres

第五章 客票网络与通信系统

本章节适用于路局地区中心、各联合站、各联网车站的网络通信系统。

5.1路局地区中心网络故障的应急处理

应急故障处理人员应与机房值班人员进行情况交流，分析故障现象，确定故障的源点，并对故障进行分类：路由器故障，交换机故障，负载均衡器故障，通信通道故障，病毒及其它原因引

— 33 —

起的网络故障。

5.1.1路由器故障

（1）E1端口故障，启用备份端口，并设置相应的参数。 （2）E1接口模块故障，把该模块所有接口移至备份接口模块，并设置相应的参数。

（3）IOS系统故障引起该路由器不能正常工作，把该路由器所有接口移至热备的路由器，并设置相应的参数；如热备路由器上的模块不能满足需要，则应增加相应的路由器，安装E1接口模块，并设置有关的接口参数。

（4）站段路由器上的路由表混乱，造成某些重要信息点不能到达，重新启动路由器。

5.1.2交换机故障

（1）RJ45端口故障，启用备份端口，并设置相应的VLAN。 （2）RJ45接口模块故障，把该模块所有接口移至备用模块，并设置有关的参数。

（3）光纤接口模块故障，尽快更换备份光纤接口模块。 （4）系统故障引起交换机不能正常工作，把该交换机上有关接口移至热备的交换机，并设置有关的参数，如VLAN、TRUNK、路由等。

（5）交换机上的路由表混乱，造成某些VALN、重要信息点不能到达，重新启动交换机。

— 34 —

5.1.3通信通道故障

应立即通知铁通有关部门处理；对影响面较大或性质较为严重的突发故障，应急小组技术人员应及时配合铁通有关部门，进行故障恢复。

5.1.4病毒及其它原因引起的网络故障

一旦确定病毒源点或其它引起网络故障的设备，应立即把病毒源点或其它引起网络故障的设备从客票网络中隔离，然后再对故障设备进行处理，待设备恢复正常后联入客票网。

5.1.5负载均衡交换机故障

（1）登录负载均衡交换机，查看各服务端口，判断故障点。 （2）若应用进程正常，重新启动故障主机，尝试恢复。 5.2 联合站网络故障的应急处理 5.2.1 路由器故障

（1）V.35端口故障，启用备份端口，并设置相应的参数。 （2）IOS系统故障引起该路由器不能正常工作，把该路由器所有接口移至热备的路由器，并设置相应的参数；如热备路由器上的接口不能满足需要，则应增加冷备路由器；如没有冷备的路由器，则首先满足站段连接路局地区中心的需要。

5.2.2 交换机故障

（1）RJ45端口故障，启用备份端口，并设置相应的VLAN。 （2）RJ45接口模块故障，把该模块所有接口移至备用模块。

— 35 —

（3）系统故障引起交换机不能正常工作，把该交换机上有关接口移至热备的交换机，并设置有关的参数，如VLAN、TRUNK、路由等，如没有备份的交换机。

5.2.3负载均衡交换机故障

（1）登录负载均衡交换机，查看各服务端口，判断故障点。 （2）若应用进程正常，重新启动故障主机，尝试恢复。 5.2.4 通信通道故障

应立即通知铁通有关部门处理；对影响面较大或性质较为严重的突发故障，应急小组技术人员应及时配合铁通的有关部门，进行故障恢复。

5.2.5 病毒及其它原因引起的网络故障

一旦确定病毒源点或其它引起网络故障的设备，应立即把病毒源点或其它引起网络故障的设备从客票网络中隔离，然后再对故障设备进行处理，待设备恢复正常后联入客票网络。

5.3各联网车站网络故障的应急处理 5.3.1 路由器故障

（1）V.35端口故障，启用备份端口，并设置相应的参数。 （2）IOS系统故障引起该路由器不能正常工作，把该路由器所有接口移至热备的路由器，并设置相应的参数。

5.3.2 交换机故障

（1）RJ45端口故障，启用备份端口，并设置相应的VLAN。

— 36 —

（2）RJ45接口模块故障，把该模块所有接口移至备用交换机。

5.3.3 通信通道故障

应立即通知铁通有关部门处理；对影响面较大或性质较为严重的突发故障，应急小组技术人员应及时配合铁通的有关部门，进行故障恢复。

5.3.4 病毒及其它原因引起的网络故障

一旦确定病毒源点或其它引起网络故障的设备，应立即把病毒源点或其它引起网络故障的设备从客票网络中隔离，然后再对故障设备进行处理，待设备恢复正常后联入客票网络。

— 37 —

附件4：

上海铁路局客票系统应急备用系统、 车站应急售票系统启用操作说明

自我局客票系统5.0版本实施以来，客票系统的运行模式与技术结构发生了较大变化，席位集中于地区中心，车站以联合站方式相对集中，大部分车站取消了服务器。在提升管理效率的同时，系统故障潜在风险也相应增大。地区中心级系统（主机、网络）发生故障会影响全局的售票；联合站级系统（主机、网络）发生故障将影响一个地区的售票。为提高系统的整体可靠性，必须根据目前我局客票系统5.0版本运行特点，建立起相应的应急保障备用系统，确保在系统发生各类故障时，能及时恢复售票，将影响降低到最小。同时，根据铁道部关于车站应急售票系统使用的安排，在车站部分售票窗口安装配置应急售票软件。

我局客票备用系统分路局地区中心、联合站两类，备用系统的配置与启用模式在客票系统应急预案中已作说明。现就备用系统、车站应急售票系统启用的具体操作说明如下。

一、路局地区中心备用系统的启用 1．采用方式

— 38 —

在路局地区中心按照地区中心级可靠性保障系统实施要求，配置硬件级镜像备用和软件级镜像备用系统。当地区中心系统发生硬件级故障时，自动启用硬件级镜像备用系统；当地区中心系统数据库发生严重故障导致无法售票时，需经技术人员处置判断后，报相关领导核准决定是否启用软件级镜像备用系统。

2．启用条件

路局地区中心系统故障分存储硬件级故障与数据库软件级故障，两类故障情况下备用系统启用条件差异较大。

发生存储硬件级故障时，硬件级镜像备用系统的启用是自动进行的；

发生数据库软件级故障时，软件级镜像备用系统的启用会造成系统恢复后续一系列困难，因此，软件级镜像备用系统的启用要特别慎重。只有当数据库软件故障难以在短时间内恢复，造成全局性较长时间无法售票时，经路局相关部门领导认可后，才能启用软件级镜像备用系统。

二、联合站主机故障情况下备用系统的启用

目前，我局客票系统设置11个联合站，配置数据库服务器，分别为：

路局级联合站；蚌埠、南京、杭州地区联合站；徐州、南京、上海、无锡、苏州、杭州站；金温公司。

联合站备用系统设置在路局地区中心，以一备多的形式建

— 39 —

立，即用一套主机作为全局所有联合站的备用主机。当全局任一或多个联合站的主机发生故障时可启用此备用系统，并能发售有座票。

1．主机配置

主机配置：HP GS80主机 + EMC存储； 主机IP地址：198.112.1.3 2．启用条件

当全局任一或多个联合站的主机发生故障短时间无法恢复，且故障点的网络与地区中心畅通时，均可启用此备用系统。

3．启用切换方法 a) 路局备用服务器端操作 此部分操作由路局技术人员处理。

以ctms5用户登录备用服务器GS80(198.112.1.3)，并执行以下命令：

$cd EXEC-5_0

$cp ctms_XXX.cfg ctms.cfg

（注：此处XXX应该为该故障车站电报码。以无锡站为例： cp ctms_WXH.cfg ctms.cfg） $cd

$startctms.sh $ps –uctms5

— 40 —

确定ctms进程是否已经启动。

启动ctms后，可先使用一个窗口测试，如正常，可将其它窗口转过来。

ｂ）故障车站端操作

当路局备用服务器端操作完成后，通知车站，由车站技术人员在窗口机上执行以下操作：

在窗口机上运行dsedit，选择DSQUERY接口,并将接口指向修改为：

198.112.4.10，9010

运行售票程序，先使用一个窗口测试，如正常，在其它窗口同样操作，并通知路局客票组，对窗口机票卷号调整后恢复车站售票。

三、车站应急售票系统的启用

车站在外部网络中断的情况下，没有配置备用服务器的，应及时启用应急售票系统，采取离线售票方式，发售无座席位。

应急售票系统启用说明：

(1)在车站管理机上停止ASA数据库服务，运行ASA9目录下的stopserver.bat文件。

(2)关闭车站管理机上的mobile_link下载同步程序对话框。 (3)开启管理机上的FTP服务，下载根目录为C:\\ASA9\\database。如果车站不使用FTP服务或者车站局域网

— 41 —

出现故障，必须先手工拷贝C:\\ASA9\\database下的数据库文件mobile_client.db，mobile_client.log到售票窗口机指定的目录下（C:\\Asa9\\database\\）。

(4)车站在获得路局客运部门同意的情况下，从路局客票管理所获取启动密码，启动应急售票程序，仔细核对当前票号后开始应急售票。

(5)当所有的应急窗口机开始售票后，关闭管理机上的FTP服务。

(6)当故障恢复后，对应急售票窗口进行结帐汇总，自动上传存根及窗口相关数据，上传成功确认无误后，恢复正常的联网售票。

(7)联网售票恢复后，本班次结束时，需要对应急售票窗口进行补结账。

(8)恢复联网售票后并且确认应急售票信息上传无误的情况下，重新启动车站管理机的ASA数据库服务和mobile_link下载同步程序。

— 42 —

附件5：

车站应急售票系统使用办法

第一条 车站应急售票系统适用于路局地区中心客票系统发生故障、路局与车站网络中断等故障状态下以及中心或联合站客票系统进行停机维护期间，车站实现离线售票，发售本站无座席车票。

第二条 为确保车站应急售票系统与客票系统的数据同步，车站应在客票局域网内设置应急管理机（配置要求同售票窗口机）作为数据下载终端。

第三条 车站要加强应急管理机的维护，定时下载数据，原则上分上午、下午各下载数据一次，车站客票系统技术管理人员每周对管理机的数据下载进行检查，并建立维护、检查台帐。

第四条 车站应急售票程序只安装在车站售票窗口，代售点和其它场所不得安装使用，车站要合理设置应急售票、退票窗口的位置和数量，原则上应急售票窗口数量不得少于车站主业窗口的1/3。

第五条 车站要将应急售票系统的窗口配置情况（窗口号、数量、用途等）报路局客票管理所，由路局客票管理所进行应急售票赋权，赋权内容包括应急售票窗口的窗口号、启动密码、售票

— 43 —

时间等。

第六条 路局客票系统主管部门负责车站应急售票系统的启用，并将应急售票系统的启动密码告知车站。

第七条 售票员进入应急售票系统时，首先要认真核对计算机系统显示未售第一张票和电子票实物未售第一张票的票符票号是否相符，不符时必须调整一致后方可发售车票。

第八条 应急售票系统仅售本站无座车票，办理中转签证和退票，不办理始发改签和中途下车签证，不办理异地票和需要中转换车的车票业务。

第九条 车站要根据旅客运输计划组织原则安排无座计划，有序组织窗口发售车票。

第十条 应急情况下的退票业务原则上要求扫描二维码还原票面信息，二维码无法扫描时，手工输入票面下方21位数字还原票面，退票席位均不返库。

第十一条 应急情况下的作废票比照正常售票时办理，暂不办理联网售出车票的作废票处理。

第十二条 当客票系统恢复正常并运行稳定后，首先恢复非应急售票窗口的正常联网售票，然后再恢复应急售票窗口的正常售票。应急售票窗口恢复正常售票前，必须先将应急售票存根信息全部上传至客票系统。

第十三条 应急售票窗口恢复联网售票时，必须先核对票符

— 44 —

本文来源：https://www.bwwdw.com/article/e645.html