红色三角帽：达美+红帽+IBM=?

文 | 李瀚明一李及李

红帽对公业务的核心竞争力

这段时间除了德州停电把 Sabre 总部搞得够呛以外，在美国航旅 IT 领域最大的新闻莫过于 IBM 在航空领域又攻下一城：继老客户美国航空公司（American Airlines）之后，IBM 又签下了达美航空公司（Delta Air Lines）的实施合约，将会承揽达美的全面 PaaS 化转型。

值得留意的是，这一次签约的团队不是和美国航空签约的 IBM Cloud 团队，而是和 IBM 在 2020 年收购而来的 Red Hat OpenShift 团队，严格来说是 Red Hat 的生意。

这也是首次有大型航空公司全面使用 PaaS 类解决方案。整个签约过程历时三年有余：自 2017 年四季度开始，达美和 Red Hat 密切合作，为既有系统设计了完整的 PaaS 化方案。

笔者有国内从业朋友问到 OpenShift 在航空业是如何应用的。笔者公司大规模使用 OpenShift 作为架构，因此（以请老朋友一顿饭的代价）和 Red Hat 航空业务首席架构师（也是全美唯一一个同时为四大航写过软件的团队）就这个问题进行了深入的交流，并总结了一篇文章供国内同行参考。

这篇文章将分为几个部分：我们先从 Red Hat 的哲学讲起。

Red Hat 的有趣之处

在笔者看来，Red Hat 是 IT 江湖内一家非常特别的公司，其主营业务是技术支持服务——这当然是一句玩笑话。但是，Red Hat 作为成功将 GNU/Linux 生态引入大型企业运营的功臣，通过解决一系列问题，获得了今天的行业地位。

熟悉企业 IT 的同行可能知道，五十年前的大型企业的 IT 架构往往以大型计算机（MainFrame） + 终端（Console）为绝对主力。这种架构一直延续至今，以 IBM/z 架构继续活跃在世间。在这种大型计算机上，运行着包括初代 Sabre 在内的航司 IT 架构。事实上，著名的 Sabre 系统是 IBM 大型机的最初几个应用，而美国航空也是第一批采用 IBM 大型机的公司（这里面的故事非常有趣——这一单生意是在美国航空的航班上成交的）。

但是大型机架构有一个问题，投资太大了。

在大型机刚刚面世的年代，像美国航空、达美航空这样业务稳定的航空公司在进行「数字化转型」时使用大型机可谓得心应手——它们本身具有巨大的业务量，通过大型机辅助处理可以大大提高生产力，降低单位顾客销售成本。

但对于开发新业务的时候，这个事情就不太好了——新业务、新应用一开始就投入大量资金买计算机的话，门槛很高，不利于快速试探市场。因此，企业在开发新业务的时候，需要「更小的计算机」——从 60 年代基于 IBM System 3x0 的大型机到 80 年代基于 UNIX 的小型机，再到 90 年代的微型机。

每一代转变往往都会带来一些新的从业者——Microsoft 和 Red Hat 就是在微型机时代成长起来的。Microsoft 最早的的微型机操作系统解决方案 Windows NT 3.1 Advanced Server（00 年成为 Windows Server）在 1993 年发布，而 Red Hat 则在 1995 年成立，并发布自己的发行版 Red Hat Linux（02 年成为 Red Hat Enterprise Linux）。

对大型企业而言，Red Hat Linux 相比 Windows Server 有两个优点：

第一是 RHL 基于的 Linux 内核原生兼容大部分按照 POSIX 标准实现的 UNIX 工具。相对底层 API 和 UNIX 完全不同，需要以子系统实现 POSIX 的 Windows 而言，原生兼容 POSIX 的 Linux 是移植原小型机应用软件的更好的选择。大部分小型机应用软件，可以平滑迁移到 Linux 这一点，为 Red Hat 的成功奠定了基础。

同时，Red Hat 通过招募开源人才和收费技术支持解决了开源代码的可靠性问题，这是第二个优点。开源软件长期存在着「谁为代码的 bug 负责」的问题——大部分开源代码的许可证文档里都明确说明「代码贡献者不负责」，因此总得找个人来负责才行。Red Hat 通过「订阅制」解决了这个问题——对技术支持按年收费。

这种「软件本体免费，增值服务收费」模式打开了 Linux 在企业界应用的局面，也奠定了 Linux 在企业界的信任。

00 年代的互联网世界——私有集群

90 年代 Windows 和 Linux 的服务器软件生态，以服务内部网为主——终端机拉专线到中央服务器进行处理。这个时候的终端机数量始终有限——以航空公司的销售系统为例，全世界的旅行社满打满算也没多少家，很容易就能通过 SABRE 完成接入。

但是 00 年开始进入了互联网时代，企业接入的终端数量大幅度增长——随之而来的是企业购置了越来越多的服务器组成集群处理业务。

这种集群架构带来了一个新问题——服务器就像交响乐团一样，需要一个指挥——中间件（Middleware）应运而生，开始协调底层服务器组合共同进行服务。一个通俗的解释是使用银行支行做例子：

客户进入支行以后，首先由大堂经理 / 保安（前台服务器）接待：不受欢迎的客户会被大堂经理赶出去（鉴权/访问控制）。

大堂经理根据柜员（业务服务器）当前的处理情况，安排客户到合适的柜员处办理业务（负载均衡），或者安排客户拿号等候（消息队列服务器）。

柜员接到客户的存款/提款请求后，去金库（数据库）完成请求。

一家支行可以由多个大堂经理、多个柜员、或者多个金库；

协调它们的人就是支行长（中间件）。

随着中间件的发展，使用集群处理业务变得可能。在妥善处理 ACID 的情况下，业务需求可以分散在多数据库、多后台处理。例如，马云和马化腾可以同时在自己的银行账户内进行存取款（需要将新的余额写入数据库）而不会干扰到对方钱包余额；北京-上海航班的订座和北京-广州航班的订座（也需要写入数据库）也同样互不冲突。

Red Hat 在中间件领域的造诣主要是处理 Web 请求的 JBoss 系统。这套系统相信国内同行用起来也是轻车熟路，在此不赘述。

容器化带来的 aaS 抽象

对于航空公司（以及其它很多企业来说），对公网服务的服务器具有两个特征：

它是非核心资产——其最好的形式是通过租赁获得使用权，而非购买使用权（操心折旧）。

服务器本身相对于其位置而言不重要——服务器的网络接入环境决定服务器的服务效果，而引入网络接入的土建和机电开销巨大。

因此，将服务器抽象化为计算资源对这些企业而言是最好的选择。从 2006 年的 AWS 开始，云服务迅速席卷企业 IT 行业。

云服务由于通过将传统的「购买产品」变成「订阅服务」，产生了一系列的 xaaS (x as a service，x 即服务) 生态。常见的 xaaS 生态有 Infrastructure、Platform、Software (例如存储和数据库，以及人工智能等应用软件) 以及 Function。各种云都会同时提供这四种 SaaS，在此不再赘述。

aaS 抽象带来的隐忧——不信任公有云提供商

aaS 模式和私有服务器集群最大的不同，在于客户失去了对服务器的物理控制权（物理控制权在「房东」身上）。这会对其上存储的关键信息——带来三个可能的问题：

首先是「我的信息会不会存着存着就被房东有意无意知道了」。这个问题在业界称为保密性（Confidentiality）——信息不被非授权人士获得的能力。保密性问题一般最好解决——先对保存在云端的数据进行加密，并通过身份认证和访问控制机制管理加密密钥，就可以达到限制访问保密信息的目的。

其次的问题是「我的信息会不会存着存着就被「房东」有意无意丢了一部分」。这个问题叫做完整性（Integrity）——信息在传输、存储过程中不丢失。完整性问题一般也好解决——大部分云服务提供商都有「n 个 9」的服务水平保证——这种服务保证一般通过备份和冗余处理。

再次是可用性（Availability）：如果我下一年不和「房东」续约，「房东」会不会不让我拿走数据？或者，会不会「房东」允许，但是「房东的房东」（监管部门）不允许？这个问题就相当棘手了——如果盲目依赖单一供应商，可能就会进入这样的窘境。

这三个问题往往最为棘手，因此很多大型企业或者对数据可控性有要求的企业，会选择同时和多家公有云企业签约。而这个时候，一个问题就会浮出水面——不同的公有云企业的设计逻辑、硬件选型等可能完全不同。

换言之——业务上云的最大障碍在于避免和单一云供应商的绑定：这对业务企业而言可能是致命的。

因此，一种名为「混合云」的模式出现了：既保留一部分自有服务器集群，又采购公有云的云服务（公私混合云），或者同时采购多家公有云的云服务（公公混合云）。不少公有云厂商都意识到了这一需求，推出了包括 AWS Direct Connect、Azure ExpressRoute 的服务，改善私有云连接到自家公有云的网络速度。但是，这并不能打消企业的疑虑。

Red Hat 的超脱地位

那么，在哪里找一家能够避免和单一供应商绑定（在各供应商的系统上都能很好的运行），同时对你的数据又没有兴趣的供应商呢？可以知道的是，这个供应商需要满足这样的条件：

兼容性好，和各家公有云都能维持不错的关系；换言之，供应商不能有明确的系统级倾向——最好各家云都吃得开。

可靠性好，在客户心中有一个值得信赖的口碑。换言之，客户必须已经对这家公司有信任——最好客户经理都别换。

Red Hat 完美满足这两个条件——RHEL 的立足点是中立而超然的技术提供商，在大型企业客户中很有口碑。对几乎所有云提供商而言，RHEL 都是大型企业客户指名道姓需要的操作系统。包括 AWS、Azure、阿里云、谷歌云都保证自身基础设施和 RHEL 架构的兼容性。

因此，Red Hat 在 2011 年搞出了 OpenShift 这个 PaaS 平台。OpenShift 既是 Red Hat 的公有 PaaS 平台，也可以部署在任意一台运行 RHEL 的计算机上，承载以容器为基本单位的负载。这种架构使得OpenShift 原生具备混合云能力。

换言之，使用 OpenShift 相当于使用公有云提供商的 IaaS 服务（虚拟机），并在上面搭建企业具有控制权的 OpenShift，让 OpenShift 为企业客户处理刚刚的三大难题：

保密性（对容器内的数据进行加密）

完整性（同一容器可以有多个冷热备份）和

可用性（云-云沟通，以及不受云服务商限制的容器迁移）

另一方面，Red Hat 本身在 Linux 上的造诣，使得 OpenShift 本身也是个体验非常优秀的 PaaS 平台。因此，OpenShift 迅速在市场扩展，成为了混合云业务的领先者（市占率超过四成）。即使是 AWS 这样的大厂，也需要为客户提供 OpenShift 作为选项，而非一味推荐自家的 Elastic Beanstalk。

（真是有什么样的需求，就有什么样的产品）

中国的云服务商没有为大型企业的挑战做好准备

笔者最后实在有几句话要讲。

航空公司作为最早使用 IT 服务的大型企业客户，对 IT 服务提供商的技术能力和产品能力都提出了极高的要求。从「双 Smith」时代开始，IBM、NEC、AWS 以及今天的主角 Red Hat 等 IT 企业就谦逊地面对航空公司等大型客户，切实地面向业务痛点勤勤恳恳地进行改进。

笔者刚刚从业这一行的时候，在东京和 NEC、AWS、Red Hat 的工程师一起为客户写软件。虽然笔者当时有着尚可的理论功底，但「事非做过不知难」，在实际应用中还是承蒙了这些老工程师的关照。而客户的产品经理中，也有对业务极为了解，一针见血地指出问题的高手。

然而，与国外 IT 服务商从大型企业开始不同，中国的云服务商都是从中小企业开始。最明显的特征是，国外 IT 服务商在 yum 系提供的选择是 RHEL，而国内云服务商在 yum 系提供的是 CentOS（RHEL 的社区复刻免费版本）。

这种面向中小企业开局的特点使得中国的云服务商往往居高临下地以传教士般的话语向客户灌输自身的「观点」。这种洗脑式销售当然对中小企业很适合——云对中小企业就是信息化「从 0 到 1」，有就比没有好；但是航空公司不少有强健的自有系统，「买家比卖家还懂」，那这一套洗脑式销售——忽悠谁呢？

同时，洗脑式销售带来的恶果还包括无视客户的业务需求，「为了卖系统而卖系统」、「销售和交付分离」、「层层转包，坑完客户坑转包商」等现象，导致云服务商在航空公司为代表的超大客户处纷纷翻车——华北华东华南西南、哪家机场哪家航司敢说自己没在云业务上经历过「仆街」？著名「负面教材」包括

某公司先「建 xx」后「yy + ss 双 xx」再「去 xx」，导致 yy 航司向该公司采购的「xx」措手不及；

某公司承接 yy 机场数字化转型项目，将其中的 zz 业务系统分包给对航空业务完全不熟悉的 aa 公司（如该公司自行竞标根本无法中标），导致 yy 机场该业务系统无法投用。

一朝被蛇咬，十年怕井绳，这种「仆街」经历令得中国各航空公司早已对「云」心生芥蒂——谁敢用这种「管杀不管埋」的系统？还是自己负责服务器管理为好（无奈）。

红帽为达美建议的转型之路

我们继续讨论 Red Hat OpenShift 平台是如何帮助 Delta 实现数字化转型的。早在 2017 年四季度，Red Hat 顾问工程师就加入 Delta 团队，开始设计达美航空的数字化转型计划。

在 2019 年的红帽客户分享会上，达美介绍称 Delta 为其数字化转型设定了五大目标：

1. 商业敏捷性（Business Agility）：创建模块化、对标商业实际的组件，从而快速适应商业变化；

2. 开发速度（Release Velocity）：建立 DevOps 文化和工具基础，改善总体开发发行速度；

3. 技术债务（Technical Debt）：基于工具的简化和持续评估，保证应用程序和现代数字化需要相符；

4. 可扩展架构（Scalable Architecture）：建立轻量化的部署单元从而按需满足扩展需求；

5. 保安脆弱性（Security Vulnerabilities）：对 CICD 和旧有操作建立标准化的保安扫描机制，并实施标准化的代码质量分析和汇报。

这五个点妥善地描述了达美所面临的转型困境——作为一家有 90 年历史的大型航空公司，达美航空（以及它的同行们）自大型机时代就开始进行 IT 开发。悠久的历史不仅为达美航空带来了宝贵的运行和销售经验，也带来了大量使用旧语言，旧技术开发的「技术负债」。达美有不少软件是在 90 年代刚刚信息化的时期开发的（甚至能够找到 60 年代大型机时代开发的软件），三十年来这些软件已经渐渐腐烂，维护非常困难。

因此，通过妥善、周全的方法进行系统架构的现代化，成为了达美航空在此次数字化转型中最大的目标——刚刚的五大目标正是这种「现代化」的具体体现」。

为了达成这两个目标，红帽和达美合作进行了三部曲：

1. 敏捷开发的理念贯彻和流程建设

2. 确立旧有业务软件转移的方法论

3. 通过模板和内部开源防止造车轮

# 敏捷开发的理念贯彻和流程建设

「统一思想」是达美第一阶段的主轴。要想顺利开展数字化转型，首先需要从 IT 开发人员的思想和制度建设开始。

达美航空的 IT 开发模式是与其他航空公司相似的「内部员工+外部承包商」的形式，因此在理念贯彻阶段需要形成可复制、可传授的「开发哲学」，从而便于协助承包商快速适应公司开发习惯。

达美航空的解决方案称为「Dojo Program」（道场）。这是一个为期 3 周的集中培训计划，用于为员工快速培训达美内部 API 的使用方法、DevOps 的开发方法等，从「自底向上」设计思维、敏捷开发和云技术三个方面对员工和承包商进行「数字化思维培训」。

# 确立旧有业务软件转移的方法论

刚刚的「数字化思维培训」保证了「新软件是用新平台开发」。但是，达美航空还有 2000 个不同的应用在旧有平台上运行。如果全部重新开发，将带来巨大的业务灾难。为了对旧有业务软件进行迁移，需要设立平稳的迁移途径并建立合适的重构机制，务求对业务开展不带来影响。

这些应用软件可以分为四类：

1. 按软件和所在环境的耦合性——耦合度越高的软件，向新平台迁移的技术难度就越高。

2. 按软件对应的业务的关键性——关键性越高的软件，向新平台迁移的业务难度就越高。

对于那些和环境高度耦合的应用程序，达美航空实行了三步架构：

1. 先通过容器（Container）技术，将应用软件和环境打包成可移植的容器；

2. 通过 OpenShift 的容器环境，先行对这些应用进行平滑迁移；

3. 之后逐步用新哲学对旧软件在容器环境下进行重构。

达美航空在 2017 年选定 OpenShift 容器平台之后，在 2018 年初对几个试点环境进行了迁移。之后，在 2018 年的第二季度和第三季度，逐渐完成应用迁移，并在 2019 年的第一季度基本完成了应用的原样迁移。

# 建立重构和开发的 SOP

SOP 是航空业最不陌生的名词之一。在软件开发过程中，SOP 也同样重要。在原样迁移之后，接下来就是用「新哲学」重构「旧软件」。

红帽在这一过程中，采用了基于 PaaS 的成套按需解决方案来完成旧软件向新 PaaS 架构的迁移。这一方案可以分为以下步骤：

1. 首先是软件本身的技术迁移，也即升级代码本身以利用所属编程语言的优化和特性；对版本控制等代码管理工具也进行了升级，从而得以在开发时集成代码风格一致性检查、文档检查等形式检查，确保代码的可读性和可维护性。

2. 同时，也对软件的编译等环节，通过编译器等的选型和优化改进软件在编译时的表现。例如，对于业务上常用的 Java 代码，通过使用在容器中运行的 Gradle 和 Maven 取代在开发机裸金属上运行的 Ant，可以降低对开发机的硬件需求，将编译的瞬间负载转移到按需付费的云平台上。

3. 为了确保能够及时发现软件的编译时错误，通过容器技术导入了 Jenkins 等持续集成、持续交付工具。通过让持续集成工具对主线代码的变动进行实时检查，可以避免编译时错误进入运行测试阶段，降低运行人员的负担。

4. 在运行测试阶段，例如 JBoss EAP（JBoss 企业应用平台）和 Apache Tomcat 这样的中间件能够根据 ORM 等设计规范为软件自动化生成 API 等外界接口，并和软件本身一起组成一个可迁移的容器。

5. 接下来将对容器及代码进行「云适配」，也就是贯彻「12 大原则」。——一份代码，多处部署；依赖关系，显式声明；配置参数，存于环境；后端服务，视作附加；构建运行，严格分离；应用进程，不设状态；服务界面，绑定端口；快速启动，优雅终止；开发上线，环境统一；事件经过，存于日志；管理任务，一次运行。

6. 之后，经过充分检查的容器将被自动化推送到生产环境中，在 A/B 灰度测试等运行时测试后推送给最终用户。

# 通过模板和内部开源防止造车轮

如果企业内部的从业人员对业内趋势和公司内既有的软件项目了解不深的话，在开发软件时很容易出现「重复造轮子」的情况。例如，营销部门和客户服务部门可能需要用途相似（甚至相同）的客户管理系统。如果分开向 IT 部门提交需求的话，就容易产生两个「相同的轮子」。

相同的轮子会严重影响公司内部的软件质量，浪费 IT 开发人员宝贵的开发时间用于重复劳动上。因此，在重构时抽取公司内部各既有软件的共同部分，以模式（Pattern）或者模板（Template）的形式呈现，是较好的做法。

达美航空在其中抽取了 40 种常见的模式模板，涵盖语言框架（Angular、Spring）、鉴权（LDAP、PingIdentity）、数据管理（Oracle、IBM DB2）、开发运维（GitLab、Jenkins）、自动化测试（Selenium、JACOCO）、应用服务器（JBoss、OpenJDK、nginx）等，并对这些典型模式模板进行了高度优化，使其满足 100% DevOps、100% 敏捷开发的要求。

同时，内部开源机制使得业务部门在提交新需求前可以在内部开源系统中查询 IT 部门已经实现的需求，从而避免重复提交。

# PaaS 对达美的好处

一方面，PaaS 为达美提供了应用环境一致性——构建、开发、测试、生产环境高度一致，降低了兼容性错误发生的概率，确保了最大限度的在线时间。

同时，PaaS 高度可伸缩的特点使得系统具有强劲的韧性，能够抗住瞬间并发压力。通过为每个请求生成一个容器的特性，即使在圣诞节-感恩节的订单高峰期，系统也能保持前台用户界面的正常加载；而通过数据库分实例运行（以每航班单独表的形式最大化并行能力），则可以降低旅客订票时的等待时间。

PaaS 带来的软件重构也使得达美得以重视其既有软件，清偿技术负债并转向具有强化的安全性和灵活性的持续集成架构。这大幅度降低了应用程序本身出现 bug 的可能性。

Red Hat 也为达美提供了其他支援工具——例如久经考验的 Red Hat Enterprise Linux、自动化服务器管理工具 Ansible 和补丁管理工具 Satellite。

# 总结

对于达美航空这样拥有悠久 IT 历史的企业而言，全面使用 OpenShift 这样的 PaaS 平台可谓是全面的转型。这种转型一方面需要企业 IT 员工通过 Dojo Program 培养其 DevOps 素养，一方面也需要在 PaaS 实施阶段确立对企业软件开发至关重要的原则和标准作业流程。

OpenShift 这样的中立提供商，确实为企业上云提供了可靠的提供商中立的解决方案，避免了企业核心数据被锁住的风险。例如，OpenShift 实践可以平稳地从 Microsoft Azure 转向 Amazon AWS、IBM Cloud 或者其他公有云提供商；达美的 OpenShift 建构在 IBM Cloud 上，而国泰的 OpenShift 建构在 Amazon AWS 上。

这或许为国内担心核心数据被单一供应商锁住的航空公司们提供了一条途径——希望这篇文章能够对国内同行航空公司的 IT 转型提供帮助。