摘 要:上海浦东国际机场一期于 1999 年正式建成通航。机场方通过国际招标引进了由澳大利亚Intersystem 公司开发,配以IBM 小型机及 SAN 存储组成机场航班信息显示系统(以下简称航显系统)的基本后台架构。后经过二期建设、虚拟化技术的引入以及卫星厅的扩容,目前的航显系统已经足够强大和稳定。作为浦东机场的核心信息系统,其强大的续航能力只是基础,还需要通过科学、完善、契合的维护方式对其进行养护,以维持其一贯的稳定性。
关键词:航显系统;信息安全:设备运维:人机结合
中图法分类号:V351文献标识码:A
1 系统简介
1.1 概述
作为国内最大的国际机场、航空枢纽港,浦东机场航班信息显示系统是浦东机场的核心系统。其通过与集成系统的接口连接获取当日乃至次日的航班信息,通过外围显示设备为旅客及工作人员提供实时准确的航班动态信息。
自1999 年浦东机场开航至今,航显系统的后台构成模式从IBM 小型机逐渐演化成以VMware 虚拟化为主,共有24 台虚拟服务器组成,其中12 台作为主服务器,12 台作为备用服务器。其兼备了虚拟化层面的实时切换技术,同时也具备软件层面的热备技术。其外围显示由2 200 台设备组成,包括7 种不同的显示设备。
随着浦东机场卫星厅的开航,后台又进行了大量的扩容,目前其后台由3 个主机房组成,形成3 地(T1、T2 航站楼和卫星厅)异地互备,同时2018 年建成了航显系统的备份系统,在极端情况下备份系统能完全替代主运营系统,并在不影响现场业务的情况下接管主运行系统。
1.2 机房设备
机房设备主要包括服务器、光纤交换机、存储,通过双机房备份、虚拟化共享技术实现系统的强大冗余能力。网络拓扑图如图1 所示。
2 系統维护中的难点及解决方案
作为浦东机场的核心业务系统,航显系统应具备7?24 小时的运行能力,任何的例行维护、系统升级都不应对其业务工作产生影响[1] 。因此,合理、科学、完善的运维方式必不可少,本文将从以下几方面对其进行研究。
2.1 信息安全
作为近期国家和公司大力推进和强化的一项基础工作,信息安全在系统运维的过程中需要做到规范、合理化,以保证系统免受网络攻击和非法外部入侵,以下是本文在信息安全方面的思路和解决方案。
2.1.1 建立主机root 用户口令的管理制度
(1)严格控制知晓口令的人员。
(2)制定root password 规则,有条件可定期更改此规则。
(3)如有条件口令,可由2 位系统管理员产生,每一位制定口令的一半。
(4)使用passwd 命令定期修改root 口令,更改频率为至少1 年1 次,并填写口令修改记录。
2.1.2 建立应用系统管理员admin 用户口令的管理制度
(1)严格控制知晓口令的人员。
(2)如有条件口令,可由2 位系统管理员产生,每一位制定口令的一半。
(3)使用passwd 命令定期修改sadmin 口令,更改频率为至少1 年1 次,并填写口令修改记录。
2.1.3 建立操作员的安全管理制度
(1)利用安全管理工具来控制对Rapid Fids 的所有应用工具和数据的存取权限。
2.1.4 建立航显系统备份策略
(2)对所有服务器虚机每年备份1 次。
(3)在系统的操作系统和数据库升级前,对系统进行备份。
2.1.5 建立航显系统账户管理制度
(1)每年度对用户的账号进行整理与清除无效账号,并对活动的账号进行口令的更改,由用户提出申请,系统管理员更改口令。
(2)若有人员变动不再担任系统管理员,则必须将该账户禁用或删除。
(3)管理员账号每年度更改一次密码,由各管理员自行更改。
(4)航显系统工作站的密码每年度更改一次,由系统管理员自行更改。
2.1.6 建立航显系统密码管理制度
(1)若只有口令密码,则管理员有将口令密码告知他人的权利,其他口令密码知情人不得将口令密码告知他人。服务器密码和终端管理员权限密码由系统管理员掌握。终端受限账号密码和应用软件密码由用户掌握,并设专人负责保密和维护工作。
(2)严格限制服务器、终端、应用软件口令密码的知情人员范围。
(3)密码长度必须不小于8位,密码为数字、字母大写、小写和特殊字符中至少2 种的组合,所有密码都不能为连续或重复的字母与数字;密码不能具有某种规律性。
2.1.7 建立航显系统日志检查记录制度
管理员每周对服务器上的系统日志进行检查,并对除以下情况外的记录做进一步记录和分析。
(1)定期出现、原因已知且对系统没有重大影响的报错。
(2)曾经出现、原因已知且对系统没有重大影响的报错。
(3)非系统核心区域出现的报错,如某一终端报错,确认不会对系统造成影响的报错。
2.2 系统日常维护
为保持系统的稳定,需要持续地对系统进行健康性检查,依据历年来的经验做实时地调整和优化,包括以下部分。
2.2.1 航显系统例行检查日维护
每日对系统中的服务器资源使用情况进行巡检:其中包括磁盘空间和CPU 检查、资源组online 情况、JBoss 进程运行情况等内容,并对其进行记录。
2.2.2 航显系统例行检查季度维护
每个季度需对系统进行重启HA 操作:手动关闭和开启HA,并对重启后的运行状态进行确认,并进行记录。
2.2.3 航显系统例行检查节日维护
重大节日前需对系统进行检查,其中包括所有服务器的工作状态检查,航显工作站检查等。
2.2.4 航显系统例行检查年度维护
每年度需对系统进行一次清理AQ 操作。
2.3 应急预案制定
作为系统维护中必不可少的部分,应急预案在系统发生故障时有很大的参考价值,也可作为对新同事新员工的培训内容。应急预案若做得好就能很快地找到故障原因并对其排除,大量减少处置时间和缩小对生产运行的影响范围。因此,根据以往的维护经验,总结出典型的重大故障的应急处置方案,并制定流程图。
2.3.1 航显数据库服务器故障应急预案
(1)故障现象。
本故障可能导致航显系统以下故障现象:
①所有航显显示设备无法更新显示;
②现场航显设备(行李小键盘、FCS)无法操作;
③TOC 操作人员无法使用客户端软件;
④所有离港操作终端与柜台航显设备无联动。
(2)故障判断。
根据服务器日志和故障现象判断。
(3)风险分析。
级别:严重影响航班运营。
后果:航显系统瘫痪,各终端设备保留故障前显
示内容,无法显示航班动态信息,操作终端无法操作。
风险概率:待定(依据实际稳定情况)。
(4)故障处理。
用root 用户登录10.28.170.11 pvgrs6db01 运行
#ha_standby.sh pvgrs6db01
#ha_mon.sh 检查pvgrs6db02 是否正常运行
#ha_online.sh pvgrs6db01 保持节点pvgrs6db01 启动
2.3.2 航显应用服务器故障应急预案
(1)故障现象。
本故障可能导致航显系统以下故障现象:
①航显显示设备无法更新显示;
②DMU 中无法连接现场设备;
③离港操作终端与柜台航显设备无联动。
(2)故障判断。
根据服务器日志和故障现象判断。
(3)风险分析。
级别:影响航班运营。
后果:根据不同应用服务器功能,导致无法显示
航班动态信息,操作终端无法操作等故障。
风险概率:待定(依据实际稳定情况)。
(4)故障处理。
用root 用户登录10.28.170.51 pvgrs6isa01 运行
#ha_standby.sh pvgrs6isa01
#ha_mon.sh 检查pvgrs6isa02 上是否正常运行
#ha_online.sh pvgrs6isa01 保持节点pvgrs6isa01启动
2.3.3 航显核心进程故障应急预案
(2)故障现象。
本故障可能导致航显系统以下故障现象:
①航显显示设备无法更新;
②部分航显功能无法正常使用。
(3)故障判断。
根据服务器日志和故障现象判断。
(4)风险分析。
级别:影响航班运营。
后果:航显部分功能无法使用。
风险概率:待定(依据实际稳定情况)。
(5)故障处理。
连接CS 服务器10.28.170.102,进入u/ fids/ lbin运行核心进程重启脚本。
2.4 航顯系统上下屏规则制定
由于航显系统的实时性及需求的多变性,需要根据旅客、工作人员、服务部门的一些要求做临时或实时调整[2] ,对此要制定各个区域的航班显示规则,并根据多方要求评估规则的可行性和调整范围,为此制定如下航班显示规则。上屏规则如表1 所列。
以下是特殊情况下的显示规则。
航班状态“NOP”需TOC 座席人员手工操作。值机柜台FCS 操作:柜台计划开始办票前60 分钟,计划结束办票后120 分钟。
登机口FCS 操作:计划开始登机前10 小时,计划结束登机后10 小时。
登机口更改显示规则,国际国内均显示3 小时内更改信息。
2.5 人机结合的维护模式
除上文例行维护内容外,建立监控平台并实行实时监控,用短信、声光的方式对发生的故障进行通告,以达到预防、预警、预控的目的,保持系统的持续稳定运行。
3 结束语
作为浦东机场的重要信息系统,航班信息显示系统的覆盖范围涉及全部旅客及现场工作人员,所以保障航显系统及其他重要信息系统的持续稳定运行是运维部门的首要职责,本文对航显系统的运维研究及方案制定,可作为其他信息系统的参考标准,并逐步推广、落实,以及持续改进。
参考文献:
[1] 褚瑞娟.航显系统显示方案设计与实现[D].北京:北京邮电大学,2014.
[2] 金辉,石敏. 成都双流国际机场航显系统的设计实现[J].计算机系统应用,2003(3):8?11.
作者简介:
唐源源(1981—),本科,工程师,研究方向:工业自动化系统、人工智能在机场运行和管理中的功能与运行保障。