一张机票背后，藏着60年前的操作系统：航空业为何至今离不开“上古基础设施”
30秒订票的现代幻觉
科技行业很喜欢谈“云原生”、谈微服务、谈弹性扩缩容。打开差旅平台，输入目的地，点确认，几秒钟后邮箱里躺着一封行程单——这一切太丝滑了，以至于我们很容易误以为，支撑它的也必然是某种摩登、轻盈、随时可重构的新世界。
但现实往往比想象更有戏剧性。软件工程师 Ajitem Sahasrabuddhe 在一次通过企业平台预订伦敦航班的经历中，顺着自己的六位预订代码一路追查，发现那张看似普通的机票，最后竟把自己带回了1960年代。那套系统比 Unix 还早，命令风格带着电传打字机时代的痕迹，核心设计已经连续跑了60多年，却依然在全球航空网络中处理着海量交易。
如果你觉得这像某种“技术债奇观”，那就只看对了一半。另一半更值得玩味：航空业不是不知道什么是现代化，也不是没钱升级，而是在反复比较之后，发现这套老系统在它最关键的任务上，依旧打得过很多新方案。它像一台外表陈旧、发动机却异常稳定的重型机器，没人会夸它时髦，但所有人都默认，关键时刻还得靠它。
航空订票系统，原本是被逼出来的
要理解今天的航空基础设施，得先回到上世纪50年代。那时美国航空的预订管理，靠的是索引卡片、电话和人工协作。旅客打来电话，代理人要在不同城市的办公室里翻卡片、核库存、再口头确认。一张跨大西洋机票，确认90分钟并不稀奇。今天我们嫌App转圈3秒太慢，当年的旅客等一张票，够看完一部老电影。
问题是，航空业当时已经开始规模化。美国航空彼时每天要处理大约8.5万次预订请求，分布在50多个城市。这个体系不是“不够优雅”，而是快要崩了。于是，后来几乎写进技术史神话的一幕出现了：1953年，美国航空总裁 C.R. Smith 在一趟国内航班上，恰好坐在 IBM 销售员 R. Blair Smith 身边。两人落地前，自动化订票系统的轮廓已经勾出来了。
1959年，IBM 与美国航空正式合作开发，1964年，SABRE 上线。这个年份很有意思：那一年 IBM System/360 刚发布，离人类登月还有5年，离第一台 ATM 机还有3年。也就是说，当大多数人还没见过自动取款机时，航空公司已经在部署大规模实时交易系统了。某种意义上，航空业是全球最早被“实时计算”逼着进化的行业之一。
后来的故事也很整齐。联合航空有 Apollo，欧洲后来有 Amadeus，Galileo 和 Worldspan 也相继出现。不同公司、不同地区、不同商业利益，最后却不约而同收敛到相似的底层形态。这不是偶然，而是市场在高压环境下对“最适合这类问题的解法”进行的长期筛选。
TPF：一套不像操作系统的操作系统
这套形态的名字，叫 TPF，Transaction Processing Facility，事务处理设施。它源自美国航空早年的 ACP，后来成为 IBM 主机世界里一个极其特殊的存在。说它是操作系统没错，但它又和我们熟悉的 Linux、Windows、Unix 几乎不是一个物种。
TPF 的哲学非常反直觉。它没有现代意义上的进程和线程模型，没有大家习惯的那种动态内存分配，没有花哨的运行时生态。它把一项工作拆成极短、极明确的交易：收到请求，执行一小段程序，提交状态，结束。事务失败了就回滚事务，而不是把整个系统拖下水。它不是为“通用计算”设计的，它像一把只做一件事的工业扳手——但这件事，它做到了极致。
Ajitem 在文中提到，现代基于 TPF 的系统在日常状态下能处理约1万笔事务每秒，遇到大促销、低价票放量时，峰值可到5万 TPS，端到端往返延迟大约100毫秒。把这个数字放在云计算语境里看，就很有冲击力了。今天我们习惯用分布式系统解决扩展性问题，前提是接受更复杂的一致性管理、更长的链路和更高的运维成本。但航空订票的核心链路不太允许“差不多就行”。一张座位库存、一段联程、一笔票价规则，只要有一个环节错位，就可能变成柜台前的争吵、航司的赔付，甚至大面积运行混乱。
所以，TPF 的存在本身就是一个提醒：技术先进与否，从来不是看它听起来像不像 2026 年，而是看它是否在关键约束下赢得了时间考验。很多工程师会本能地嫌弃主机、嫌弃汇编、嫌弃“古老命令行”，这完全可以理解。但如果一种系统在60年里都没被彻底替代，我们至少该先问一句：它到底解决了什么别人没解决好的问题？
你的机票不是一张票，而是一串跨系统承诺
更有意思的，是“30秒订票”背后那条漫长而脆弱的链路。Ajitem 的差旅订单通过企业平台 myBiz 发起，经过 MakeMyTrip 的在线旅行社层，进入 Amadeus 这样的全球分销系统（GDS），再触达航司自己的旅客服务系统（PSS），同时还要和票款结算体系、电子客票编号体系、PNR 记录体系发生关系。用户只看到一个六位预订代码，比如 DDTCIV，但那其实是一根把多个异构系统勉强拴在一起的线。
这里最值得普通读者了解的，是 GDS 和 PSS 的区别。GDS 像一个全球机票批发与分销网络，负责让旅行社、企业差旅平台、渠道商都能看到并处理航班库存；PSS 则更像航司自家的“乘客大脑”，掌管订座、值机、登机、客票等核心流程。前者强调分发和连接，后者强调执行和履约。你订到一张票，不只是“数据库插入了一条记录”，而是多个系统彼此承认：这个座位、这个价格、这个人、这笔钱、这段旅程，都成立。
也因此，航空 IT 的麻烦从来不是“平时能不能跑起来”，而是“出错时怎么收场”。文中提到，印度航空已经迁移到 Amadeus Altéa，而印度最大廉航 IndiGo 使用的是 Navitaire NewSkies。后者是为低成本航空优化的体系，便宜、快、简单，特别适合点对点、高周转、低复杂度运营模式。但代价是互操作性往往差一些。平时看不出问题，一旦延误、改签、联程保护、跨航司重订这些情况冒出来，系统之间的边界就会突然变得非常真实，最后往往还得靠人工补缝。
这也是航空出行里最让人无奈、但又最能暴露底层真相的时刻：你以为买的是“从 A 到 B 的服务”，实际上买到的是一堆系统之间暂时达成共识后的结果。天气、维护、机组、空管、前序航班、合作航司、票规、库存，一旦哪一环失手，这个共识就会松动。
为什么这件事在今天尤其重要
过去几年，科技行业有一种很强的冲动：把一切旧系统都视作包袱，把迁移上云、平台重构、架构统一视作理所当然的方向。这个冲动不全错，毕竟旧系统维护人才稀缺，开发体验差，和现代工具链也格格不入。可航空业的例子告诉我们，迁移从来不是一句“lift and shift”能概括的。
一家大型航司背后，不只是几十年的预订记录，还有常旅客体系、联运协议、机场离港系统、清算网络、客服流程、地服操作、代码共享伙伴。这些关系像老城区地下的水电管网，平时没人看见，改造时才发现每挪一厘米都可能牵一大片。印度航空在 2023 年迁移到 Amadeus Altéa，就被视为亚洲航空业一次极具规模的 PSS 切换。对外看是“系统升级”，对内更像一场不能停业的心脏移植。
这件事之所以在当下格外值得看，是因为 AI 和云计算正在让很多行业重新相信“大重构”与“全栈替换”的可能性。可航空业会提醒你：在关键基础设施领域，替换成本不是 PPT 上的一张路线图，而是数十年业务规则、行业协议和灾难恢复经验的总和。新系统当然可能更灵活、更开放、更易开发，但是否真的足够可靠、足够可解释、足够经得起高峰与故障场景的反复冲击，这是另一回事。
我自己的判断是，未来航空 IT 不会回到纯主机时代，但也不会轻易彻底抛弃那套“以事务为王”的老哲学。更可能的路线，是外围越来越现代，核心越来越保守：App、接口层、数据分析、客户运营可以云化、智能化、实时化，但真正决定一张座位能不能卖、一次改签能不能落地的那部分系统，仍会保持极高的稳定优先级。说白了，航空业愿意在体验上冒险，却不敢在结算与库存上浪漫。
这给整个科技圈都上了一课：不是所有基础设施都适合追逐潮流。有些系统之所以看起来“古老”，不是因为没人懂创新，而是因为它们背负的责任太重，容错空间太小。你可以笑它界面像上世纪，但当春运、暑运、节假日高峰真的来临时，大家最终希望它像老火车司机一样——不花哨，但别掉链子。