亚马逊云服务AWS业绩（你的金卡已上云）

星空联盟和 AWS 于12月14日正式达成协议，开始迁移核心 IT 业务到 AWS 上。总算松了口气的笔者，得以腾出时间将这个项目的一些有趣的细节介绍给中国的各位同行朋友。

作者 | 李翰明

航空公司，或者说任何公司的经营，都牵涉到三种流动：物品流、资金流和信息流。它们之间大体可以构成 T 字形关系：物品和资金相向而行，构成「用钱采购商品-卖出商品赚钱」的循环；信息流则同时驱动物品流和资金流，起到「驱动者」的角色。对于企业而言，这三者的流动畅通，直接关系到企业的正常经营。

大型航空公司的物品流、资金流和信息流往往牵涉多个国家和城市，具有高度复杂的特点。例如，航空公司每年可能收到各外站以 70 多种货币支付的机票款，从 40 多个国家采购食材，每天接到以 20 多种语言打入的客服电话，种种例子，不一而足。

对于国际化运行的航空公司而言，汇兑手续费每节约一个点、食材采购的价格每降低一个点、客服人员的工资每降低一个点，都能带来数百万美元的收益。因此，在全球化时代集合全球智慧、资源和资金活动，以全球供给应对全球需求，对航空公司而言就至关重要了。

事实上，航空公司的这些操作行之有年。例如，航空公司通过「合作轧帐」的形式，抵消自己在对方国家收到的票款头寸。轧帐使得德国人在美国收到的美元和美国人在欧洲收到的欧元可以直接互相兑换，降低了资金在银行系统中流动的成本和时效，提高了资金的使用效率。

又比如，不同国家的星盟成员合作，互相为对方的空乘队伍提供外语和文化适应性培训，最终形成了星盟内部通用的多语言国际化服务手册。这一服务后来陆续拓展到其他星盟航空公司，形成了完整的语言培训体系。

可以说，航空联盟建立了航空公司之间的信任关系，为航空公司的业务提携带来了极大的便利。联盟建立起来的长期信任关系，使得航空公司之间从「合作伙伴」上升到了「知己朋友」，得以通过互相学习，取长补短提升自己在目标市场的竞争力。

因此，航空联盟建立 20 余年来，其核心目的都是为了降低「做朋友的阻力」。而联盟整体上云，也是这一工作的一部分。

星空联盟的上云之路并不容易。虽然 AWS 在星盟大多数公司的所在国家都设有数据中心，但如此大规模，前无古人的迁移，仍然遇到了很多可见的困难。

其中一项困难在于，迁移核心业务系统，对航空公司而言相当于「边飞行边更换发动机」，难度绝对不低。因此，在最开始的时候，星盟并没有迁移运价、飞行等核心系统，而是选择以「新系统」为契机，开始在 AWS 上建立统一的鉴权和管理平台，并在新平台上逐渐建立备份系统，最后逐渐实现迁移。

例如，星盟将各参与航空公司的「知识库」统一到 AWS 提供的智能搜索引擎 Kendra 上。通过将航图、维修手册、事故报告、服务指南、机场和目的地信息等种种信息以结构化的数据存储在覆盖全球的数据库中，星盟得以在全世界的成员航空公司之间快速共享信息，服务超过五十万名机务工程师、飞行员、乘务员和地勤员工。

例如，机务工程师可以快速查询盟内其他公司的维修案例，从而更快诊断故障所在；飞来本地的客场飞行员，可以快速查询枢纽航空公司提供的本场飞行注意要点；甚至乎，本地职员可以向外航同行们，推荐当地好吃的餐馆。

之后是下一代的常客系统。AWS Aurora 的新一代数据库管理系统为星盟成员提供更具灵活性的常旅客管理（即使是盟内交换数据时同样如此）。例如，订购过特殊餐的常客即使乘坐其他星盟成员的航班，只要填写了卡号，就也能在无需额外通知的情况下，享受符合饮食习惯的特殊餐食；喜好靠窗座位的常旅客，也能在联盟成员航班上享受自己偏好的座位。同时，针对大型企业和跨国公司的灵活差旅解决方案，也得以借助 AWS 提供的技术能力实现。

同时，AWS Sagemaker 机器学习和数据分析能力也帮助星盟成员优化旅客体验。例如，AWS 可以实时处理世界各地机场的抵离港延误情况，并在海量行程中，寻找出盟内外可能错失中转的旅客进行处理。例如，当辛辛那提-芝加哥航班延误时，系统甚至能够为后续的芝加哥-东京航班给出以分钟为单位的延迟起飞建议，使得后段航班可以在不延误到达的前提下，尽可能接上前段航班延误的乘客。

随着边缘系统在 AWS 上的开发趋于佳境，联盟在 AWS 上构建的用户认证和数据权限管理系统也趋于成熟。系统允许不同成员航空公司的职员使用单点登录访问系统，并获取用户协议许可的己方权限范围内的信息。

随着周边系统的投用，核心关键系统，例如销售、筹划和离港这些较早完成信息化的系统的迁移也逐渐提上日程。借由系统迁移解决业务流程设计不当带来的问题，成为「上云」的核心工作。

例如，在国际联程中的运价结算问题，常年困扰联盟内的各航空公司。由于竞争要素影响，国际联程航班的结算上时常会出现利润分配不均匀的现象。例如，同样是承运新奥尔良到芝加哥的一位客人，承运衔接客人（例如经芝加哥飞往东京或上海的客人）要比承运直达客人（到达芝加哥的客人）收入要少很多。这打击了客源国航空公司（例如美联航或汉莎航空）参与联程合作的意愿，影响了联盟的总体竞争力。

因此，通过 AWS Neptune 数据库，联盟可以在盟内联程航班上快速分析联盟的国际线网络的航班的意图出价，并通过协调国际段承运人和国内段承运人之间的利益分配，在联盟整体机票服务的竞争效率和联盟内各航空公司之间的公平合作之间取得平衡。

同时，AWS 和 Amadeus 之间的合作，也使得销售系统向云的迁移更加顺畅。Amadeus 在开发 Altea 的过程中，充分考虑到了 Altea 在云上运行的可能性和云平台的特点，在分布式处理等领域做了充分的优化和处理，在保证 ACID 的前提下提高了性能效率。

向航空公司提供云平台并非易事。任何有志于此行的从业者都明白，航空公司作为业务流程复杂，涉及单位众多的大型企业，其上云之路必然伴随着对业务流程的全面梳理。上云本身不应该是目的，而应该是提升经营效率，降低经营成本的手段。

例如，虽然云服务有着「随用随买」的特性，但如果 IT 系统未有对并行化执行的 ACID 性能做优化的话，即使「随用随买」也无法解决突发需求带来的宕机问题。换言之，瓶颈并不在云等基础架构本身，而是在云上运行的软件系统。

而除了系统性能本身的提升之外，利用云平台的技术能力，充分提升系统功能，也是上云的目的之一。例如，AWS Redshift 允许全日空在海量数据中按照自然语言逻辑寻找数据，从而大大简化数据分析师的工作。

同时，上云也强化了第三方系统集成商和航空公司的合作。像 Amadeus 这样的系统集成和应用提供商可以通过云快速接入航空公司的系统，为航空公司提供可靠的专业技能服务。在服务过程中，权限管理系统可以保证数据在合规要求限制内共享，确保开发灵活性和数据安全性。

这套系统不但惠及传统大型 IT 提供商，也令创业公司可以基于 AWS 系统，快速发展和航空公司的合作。由于数据共享的低成本，航空公司可以简化其决策流程，并以结果而非资质评价创业公司的技术实力。同时，云数据库的数据混淆机制和云上 IDE，可以在避免核心经营数据或知识产权泄漏的同时，降低创业公司的流程性障碍，从而将合作聚焦在核心业务中，提高开发效率。

因此，对于国内的云服务商也好，有意上云的航空公司也罢，明确上云的目的始终是最重要的。从星空联盟的例子中可以看出，提升性能、扩充功能、发展合作这三点，将为参与的航空公司在未来提供更多机遇。我们当然希望这一模式能够在国内发展，助力国内航空公司完成高质量管理转型。