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

原创者也技术琐话

刚接触航空业时，觉得自己像刚踏上美洲的弗朗西斯科.皮萨罗，或是刚遇见毛利人的库克船长，仿佛走进了信息技术的蛮荒之地，随便播下一颗“现代技术”种子，就能长出一片跨时代的技术森林。

与国内行业解决方案提供商交流之后，这种自信似乎得到了印证。一个拥有几十家航司客户的产品，代表着行业最高水平，却不支持插件化定制，没使用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架构，系统架构适配信息结构；这些事件、状态、工序、流程最终沉淀为数据，成为更深层变革的土壤。

数据说话

数据积累是航空业天然优势，飞机运行数据，从发动机性能参数，到飞行轨迹，到飞行员的每一次操作，从首飞开始完整记录。每一次故障，即便是空调扇叶螺丝松动，都要记录在案，而每一次修理，更是从使用什么工具，到每个具体的修理动作，比如登上脚手架，都详细记录。

这座数据金矿的价值不言而喻，但挖掘起来难度不小，主要原因是专业门槛太高，业务专家普遍缺乏系统意识，技术人员和技术专家就像修建通天塔的工匠。

即便如此，对数据客观性的认可是共通的，每当双方各执一词，无论是立场还是观念的冲突，只要一方能够拿出扎实的数据佐证，通常就可以把问题范围缩小到数据有效性层面。

航司生产运行变动成本中，燃油占了大头，节油于航司不只是环保问题，更是真金白银的利润问题，飞机加多少油不只是个技术问题，更是理念之争。争论的两端，一方是公司要省钱，另一方则是航空公司最举足轻重的群体——飞行员。

飞行员在航空公司是特权阶层，享有巨大的发言权，就像互联网公司里的程序员，不可小觑。从飞机发动机启动开始，机长是负责航班的第一责任人，如果航班出现了特殊状况，比如备降或者返航，甚至被迫盘旋等待，油箱里有油，心里就不慌。可是飞机的载重是有限的，装了太多油，机票就只能少卖几张了，而且油自重也耗油，有时为了降落不超重，还要刻意消耗一些油减重，实在可惜。

理论上，航班耗油取决于飞机载重和航线距离，同时受天气情况（气温、湿度、风力）影响，备用油主要看备降场的选择，传统计算模型是物理公式，技术上本没有讨论空间，但理论与实践的差距很微妙，飞行员作为直接实践者，站在安全的制高点，质疑理论值只需要一个例外。

技术手腕如何对抗安全大棒？唯有动用数据的力量。如果预估油量计算模型吸收飞行员实际飞行的数据作为参数，飞行员操作习惯、飞机特性等公式中没包括的因素，都能涵盖了。

具体方案分为两个阶段：数据积累和模型训练。积累阶段，制作航班计划计算预估油耗时，选取条件最近似的历史数据作为锚点，记录每个航班的实际飞行数据，包括航距、载重、天气和耗油，进而按照不同飞行阶段细分数据，得到更精确的油耗，这个锚点油量也会作为参照值记录到这次航班的飞行数据中

积累一段时间的数据后，比对锚点油量、计划油量和实际耗油，如果锚点油量比计划油量更接近实际耗油，那么这个历史数据就可以用来修正计划油量计算模型，累计飞行数据不断训练，模型稳定后，就可以直接计算更准确的锚点油量。

往期推荐

技术琐话

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

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

没有银弹

没有上线，就没有伤害

局方，局方

数据说话

15 年工龄的阿里P9职场历程亲述

撸了个 DDD 项目，爽！

在业务系统中寻求技术含量

15年架构师+6年CTO的架构大佬，离开了阿里

7张图揭晓RocketMQ存储设计的精髓

……