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

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

数据说话

数据积累是航空业天然优势，飞机运行数据，从发动机性能参数，到飞行轨迹，到飞行员的每一次操作，从首飞开始完整记录。每一次故障，即便是空调扇叶螺丝松动，都要记录在案，而每一次修理，更是从使用什么工具，到每个具体的修理动作，比如登上脚手架，都详细记录。这座数据金矿的价值不言而喻，但挖掘起来难度不小，主要原因是专业门槛太高，业务专家普遍缺乏系统意识，技术人员和技术专家就像修建通天塔的工匠。 即便如此，对数据客观性的认可是共通的，每当双方各执一词，无论是立场还是观念的冲突，只要一方能够拿出扎实的数据佐证，通常就可以把问题范围缩小到数据有效性层面。

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

飞行员在航空公司是特权阶层，享有巨大的发言权，就像互联网公司里的程序员，不可小觑。从飞机发动机启动开始，机长是负责航班的第一责任人，如果航班出现了特殊状况，比如备降或者返航，甚至被迫盘旋等待，油箱里有油，心里就不慌。可是飞机的载重是有限的，装了太多油，机票就只能少卖几张了，而且油自重也耗油，有时为了降落不超重，还要刻意消耗一些油减重，实在可惜。理论上，航班耗油取决于飞机载重和航线距离，同时受天气情况（气温、湿度、风力）影响，备用油主要看备降场的选择，传统计算模型是物理公式，技术上本没有讨论空间，但理论与实践的差距很微妙，飞行员作为直接实践者，站在安全的制高点，质疑理论值只需要一个例外。 

技术手腕如何对抗安全大棒？唯有动用数据的力量。如果预估油量计算模型吸收飞行员实际飞行的数据作为参数，飞行员操作习惯、飞机特性等公式中没包括的因素，都能涵盖了。具体方案分为两个阶段：数据积累和模型训练。积累阶段，制作航班计划计算预估油耗时，选取条件最近似的历史数据作为锚点，记录每个航班的实际飞行数据，包括航距、载重、天气和耗油，进而按照不同飞行阶段细分数据，得到更精确的油耗，这个锚点油量也会作为参照值记录到这次航班的飞行数据中积累一段时间的数据后，比对锚点油量、计划油量和实际耗油，如果锚点油量比计划油量更接近实际耗油，那么这个历史数据就可以用来修正计划油量计算模型，累计飞行数据不断训练，模型稳定后，就可以直接计算更准确的锚点油量。