紅色三角帽：達美+紅帽+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 轉型提供幫助。