查看原文
其他

航空公司系统是怎样炼成的

者也 技术琐话 2022-07-13

刚接触航空业时,觉得自己像刚踏上美洲的弗朗西斯科.皮萨罗,或是刚遇见毛利人的库克船长,仿佛走进了信息技术的蛮荒之地,随便播下一颗“现代技术”种子,就能长出一片跨时代的技术森林。
与国内行业解决方案提供商交流之后,这种自信似乎得到了印证。一个拥有几十家航司客户的产品,代表着行业最高水平,却不支持插件化定制,没使用gitflow管理产品线和业务线,每个客户的代码都是单独维护的;航班运行全生命周期管控系统不允许宕机,却不具备基本的负载均衡、故障转移、服务降级,数据库没有主从热备,只有日备份,系统稳定性完全靠祈祷;系统升级没有回退机制,不支持新老并行,每次升级都是一场勇气与决心的冒险。
正当我撸起袖子,手握互联网技术的利剑,准备披荆斩棘,收割航空业信息化的硕果,开心地回答这道天赐送分题时,行业却问了我另一个问题:这系统安全吗?航空业对安全的追求深入骨髓,答不好就是送命题。安全是每个中国民航人做每件工作的必答题,值得国人骄傲的是,中国民航局对安全运行的要求和管控远高于世界平均水平,所以互联网典型思维,诸如快速试错、容灾,名字都不合法。



没有银弹


航空安全问题的边界在哪里,可以试着从航天安全切入,关于航天,埃隆.马斯克当有发言权,毕竟他的公司Space X,领先于NASA,实现了火箭回收重复利用的商业化。Space X的创举打破了航天技术高深莫测的神话,凡人也可以做出火箭,那么航空业的安全应该也可以通过我们熟知的技术来解决。
NASA,地球上少数几个可以和Google争夺人才的机构,是软件工程的鼻祖,世界上最初的巨型软件项目就是NASA的项目,这些项目的底线是不能出错。为了管理庞大软件项目的复杂性,NASA在实践中提出了软件工程概念,用系统化的工程方法解决业务复杂性问题。顺便提一句,软件工程师这个称谓也是由NASA的“临时编码工”玛格丽特提出来的,在她刚加入这个行业时,软件还只是硬件的一个部件。
既然安全问题说到底是个技术问题,既有的技术实践依然有效,那么航空业的信息化又回到了技术的轨道上。

没有上线,就没有伤害

第一个接受安全问题拷问的是运行控制系统,这个系统负责从制定航班计划,到飞行员资源调配,再到飞机起飞降落管控,乃至航班异常处理(备降/返航/调机),是航司生产运行的中枢系统。如此关键的系统,在设计之初,就考虑了平滑上线方案,保持老系统功能可用的条件下,业务分航线逐步切到新系统运行,一旦出现系统故障,可以立刻切回老系统继续管控航班。
这套方案最大的挑战在于电报系统,电报系统是航司和空管沟通航班调度的关键通道,每个航司只有一条专线与空管相连,无法做双线热备,是整套系统唯一的SPF(Single Point of Failure)。电报系统通过电报机通信,发送摩斯电码,模拟信号,据说建国前就在使用了,谍战片里那种,这样的古董系统,偶尔出现乱码也情有可原吧,但请谨记,航空业不允许出错,所以这就相当于要求一个Java程序员用C写代码,还不许有bug。
 
解决问题的关键在于回归问题本原,监控系统可用性的最基本策略是心跳检测,通过定时发送测试电报给自己,覆盖了发送和接收双向通道的可用性检测,并结合正常业务电报的收发以及航班疏密,适当减少检测频度以节约成本。
如何让新老系统共用一条线路?“Any problem in computer science can be solved with another level of indirection”,封装电报系统,内部分航线调度,隔离新老系统。同时冷备一条网络线路,预防运营商抽风。
做足了准备工作,系统终于要上线了,在发布准备会上,业务部门突然提出,分航线迁移业务不可行,因为虽然航班管控是按航线组织的,但飞行员是个共享稀缺资源池,如果按航线拆分,将出现飞行员短缺,而且局方不认可系统新老并行方案,局方要求新系统不允许出现故障。


局方,局方

中国民航局作为世界上最严厉的监管机构之一,事无巨细地监管着每一家航空公司的生产运行,高度管控可能局部高效,但整体必然低效,因为整体效率完全取决于管理层,这要求管理层都是超人。这与日新月异的大环境显然冲突,业内人都在呼唤变革,自上而下的严密监管体系制约了个体的创造力,变革只能自下而上通过奇点突破形成裂变辐射的形式发生。
我们希望在航空业的探索能够找到那个奇点,但在此之前,首先要解决业务部门尖锐的问题:局方不认可。备用系统为什么不被认可?不出故障只能是结果,怎么能是要求?再次回到问题本原,业务部门反对新老系统并行的真正原因是,不愿意在新老系统中录入两遍基础数据,这会增加工作负担。
找到根源,问题就解决了一半,通过自动同步新老系统数据,业务部门只需要录入系统差异部分数据,不仅规避了大量的重复人工,也保证了数据完整性和准确性。这件事不仅让我意识到要善于捕捉和发掘业务部门潜台词,更让我明白局方是个重要的第三方,可以是问题的核心,也可以是解决问题的支点。
新系统尽量实现自动化,但并非所有数据都能自动采集,有些即便可以自动获取但仍需人工确认,这些不自动的部分就像人类进化的尾巴,反成了难以忍受的累赘,比如上客时间和加油量等数据的录入,完全是线下行为,只能人工事后录入系统。这些遗留的人工,在自动化背景下成了额外的工作,没有人愿意接手。
体制是把双刃剑,可以借助监管的力量,反推信息化,统一技术目标与业务目标,形成部门合力,局方对航司各项工作可追溯的要求就帮了忙。所有工作必须可以通过各种工作日志、工单、审批单、会议纪要等完全还原,尤其当回溯事故/故障的原由,只要还原结果表明不存在人为过失,就可以免责,所以有句行业戏言,“工作做的好,不如记录记得好”。由此,为了保证信息流闭环,这些数据理所应当分到了合适的席位人工录入。
当然,在后续迭代中,所有现场人员都会配备信息终端,这类信息录入会简化成按钮点击,甚至只需摇一摇,即可完成;而系统本身也将演化成Event Sourcing架构,系统架构适配信息结构;这些事件、状态、工序、流程最终沉淀为数据,成为更深层变革的土壤。

数据说话

数据积累是航空业天然优势,飞机运行数据,从发动机性能参数,到飞行轨迹,到飞行员的每一次操作,从首飞开始完整记录。每一次故障,即便是空调扇叶螺丝松动,都要记录在案,而每一次修理,更是从使用什么工具,到每个具体的修理动作,比如登上脚手架,都详细记录。
这座数据金矿的价值不言而喻,但挖掘起来难度不小,主要原因是专业门槛太高,业务专家普遍缺乏系统意识,技术人员和技术专家就像修建通天塔的工匠。
 即便如此,对数据客观性的认可是共通的,每当双方各执一词,无论是立场还是观念的冲突,只要一方能够拿出扎实的数据佐证,通常就可以把问题范围缩小到数据有效性层面。
航司生产运行变动成本中,燃油占了大头,节油于航司不只是环保问题,更是真金白银的利润问题,飞机加多少油不只是个技术问题,更是理念之争。争论的两端,一方是公司要省钱,另一方则是航空公司最举足轻重的群体——飞行员。
飞行员在航空公司是特权阶层,享有巨大的发言权,就像互联网公司里的程序员,不可小觑。从飞机发动机启动开始,机长是负责航班的第一责任人,如果航班出现了特殊状况,比如备降或者返航,甚至被迫盘旋等待,油箱里有油,心里就不慌。可是飞机的载重是有限的,装了太多油,机票就只能少卖几张了,而且油自重也耗油,有时为了降落不超重,还要刻意消耗一些油减重,实在可惜。
理论上,航班耗油取决于飞机载重和航线距离,同时受天气情况(气温、湿度、风力)影响,备用油主要看备降场的选择,传统计算模型是物理公式,技术上本没有讨论空间,但理论与实践的差距很微妙,飞行员作为直接实践者,站在安全的制高点,质疑理论值只需要一个例外。 
技术手腕如何对抗安全大棒?唯有动用数据的力量。如果预估油量计算模型吸收飞行员实际飞行的数据作为参数,飞行员操作习惯、飞机特性等公式中没包括的因素,都能涵盖了。
具体方案分为两个阶段:数据积累和模型训练。积累阶段,制作航班计划计算预估油耗时,选取条件最近似的历史数据作为锚点,记录每个航班的实际飞行数据,包括航距、载重、天气和耗油,进而按照不同飞行阶段细分数据,得到更精确的油耗,这个锚点油量也会作为参照值记录到这次航班的飞行数据中
积累一段时间的数据后,比对锚点油量、计划油量和实际耗油,如果锚点油量比计划油量更接近实际耗油,那么这个历史数据就可以用来修正计划油量计算模型,累计飞行数据不断训练,模型稳定后,就可以直接计算更准确的锚点油量。


往期推荐




技术琐话 


以分布式设计、架构、体系思想为基础,兼论研发相关的点点滴滴,不限于代码、质量体系和研发管理。




您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存