2026年，當你用智慧型手機預訂機票時，你的請求會經過多層現代技術——行動應用、網路服務、支付處理商等等——最終到達為你保留座位的系統。在大多數情況下，這個系統是源自於20世紀60年代的軟體，運作在旅遊業幾十年來一直試圖替換卻始終未能完全取代的基礎設施上。 Sabre、Amadeus和Travelport三家公司幾乎處理全球所有的航空公司預訂業務。它們每年處理數十億筆交易，涉及數百家航空公司、數千家旅行社，以及涵蓋數百萬種座位組合的即時庫存。其中歷史最悠久的Sabre可以追溯到1964年的IBM大型主機，它將預訂時間從90分鐘縮短到幾秒鐘，徹底改變了商業航空業。
這些系統之所以依然沿用現狀，並非源自於組織慣性或工程保守主義。而是當軟體與關鍵業務流程深度整合，以至於替換的成本和風險在任何現實的時間框架內都無法得到充分論證時，會發生什麼事？以及產業如何應對，選擇圍繞核心進行現代化改造，而非試圖徹底替換。對於任何從事大規模遺留系統現代化改造的人來說，航空公司訂票系統是「至關重要，不容失敗」這一概念在實踐中的最佳例證。
起源：大型主機為何贏得航空難題
最初的 SABRE（半自動化業務研究環境）並非一款產品，而是針對特定營運危機而客製化的解決方案。 1950 年代末，美國航空公司的業務成長速度超過了其人工預訂系統的處理能力。當時，預訂座位需要撥打電話、人工核對紙質庫存卡、等待預訂、回撥電話，以及紙本記錄，整個流程平均每次預訂耗時 90 分鐘，且難以擴展。
1964年，SABRE系統全面投入營運。該系統基於兩台IBM 7090大型機構建，連接美國和加拿大的1,500個終端，每小時可處理7,500筆預訂，錯誤率幾乎為零。航空公司首次能夠即時掌握座位庫存信息，儲存完整的乘客記錄，並實現全網即時預訂。預訂時間從90分鐘縮短至幾秒鐘。
實現這一目標的架構選擇——在大型機硬體上進行集中式事務處理——並非出於哲學考量，而是因為在1964年，它是唯一能夠滿足實時航空公司庫存管理對延遲、可靠性和並發訪問要求的架構。而且，它的運作效果非常出色，以至於後來所有航空公司訂票系統都以此為架構模板。
IBM 的事務處理設施 (TPF) 最初是為 SABRE 設計的，後來成為整個產業標準的運作環境。據 IBM 稱，幾乎所有大型銀行、保險公司、零售商和航空公司至今仍在使用它。 1987 年 Amadeus 成立時，其係統正是基於 TPF 建構的。 Galileo（現為 Travelport）推出其全球分銷系統 (GDS) 時，也是基於 TPF 構建的。如今，商業航空領域同時存在三代旅客服務系統，其中許多系統仍運作在 TPF 大型主機上。這並非因為這項技術從未受到質疑，而是因為 TPF 在大型主機硬體上實現的事務吞吐量、可靠性和容錯能力，在其他架構上很難以同等規模複製。
這些系統在大規模應用時實際上能做什麼
從軟體工程的角度來看，航空公司訂票系統的運作規模難以直觀理解。全球分銷系統不僅處理座位可用性，還管理著極其複雜的組合庫存問題。
一趟跨大西洋航班就有數百個票價等級。每個票價等級都有特定的規則：提前購票要求、最短停留時間、不適用日期、改簽費、是否允許中途停留以及與合作航空公司的代碼共享協議。如果預訂涉及兩家航空公司、一次中轉和往返行程，就會產生數千種有效的票價組合，這些組合必須經過核查、定價，並與實時庫存進行比對，然後才能返回結果，通常需要不到一秒鐘的時間。
在預訂高峰期，Sabre 和 Amadeus 系統每秒可處理數萬筆交易。注意，是每秒，而不是每分鐘。每筆交易都涉及即時庫存查詢、票價規則評估、PNR（旅客姓名記錄）創建或修改，以及與出發控制系統、常旅客系統和輔助服務系統的協調。保證回應時間以毫秒計，因為旅行社或預訂引擎如果等待票價查詢超過幾秒鐘，系統就會超時，要么重試，要么放棄交易。
在大型主機硬體上實現TPF吞吐量，其故障率之低令其他行業的IT專業人士難以置信。大型主機的容錯能力、冗餘處理器、熱插拔組件以及數十年來不斷強化的作業系統程式碼，使得五個九的可用性成為標準運作參數，而非理想目標。自1990年代以來，如何在雲端基礎設施上以同等成本複製這一優勢，一直是所有航空公司IT現代化項目面臨的核心技術挑戰。
現代化嘗試：長達十年的計畫實際上發現了什麼
航空公司訂票系統現代化的歷史，就是一部旨在替換核心系統，但多年後卻演變成將核心系統包裹起來的混合系統的歷史。
美國航空公司的Jetstream計畫於2000年代啟動，其明確目標是取代Sabre大型主機PSS系統。最終，該專案選擇了採用新的Sabre產品，而不是自行開發替代方案。最初，人們認為自主研發替代系統能夠更快地打造出更優質的系統，但這種假設卻遭遇了幾乎所有大型遺留系統替換項目都會遇到的現實：現有系統存在一些直到新系統無法滿足時才被發現的需求。
我們需要深入系統底層，改變核心引擎，並解耦規則，以便能夠快速更改。這段話出自美國航空Jetstream計畫期間的IT領導階層，精準地描述了問題所在。嵌入在舊系統中的規則，包括票價構建邏輯、代碼共享協議實施、監管合規性計算以及收益管理集成，都是在數十年的業務變革中積累起來的，而且沒有任何形式的文檔記錄，使得我們只能通過運行現有系統並觀察其運行情況才能提取這些規則。
Sabre 自身的現代化改造計畫於 2010 年代正式啟動，歷時十餘年，耗資數十億美元，最終將其大部分程式碼從本地大型主機基礎設施遷移出去。截至 2019 年，Sabre 約 11% 的程式碼仍在本地資料中心運行，其餘程式碼都已遷移完畢。 2026 年 2 月，Sabre 與 WestJet 續簽了長期產品服務系統 (PSS) 協議，這表明即使經過十年的現代化改造和數十億美元的投資，PSS 仍然是其業務的商業基石。
Amadeus 實現了更徹底的大型主機退役，完成了最後一批大型主機的淘汰，轉而採用雲端基礎設施，這標誌著其發展歷程中的一個里程碑。 Amadeus 採取的方法是，在保持核心資料模型和事務架構不變的情況下，逐步替換功能元件，從而有效地保留了源自大型主機的架構決策，即使硬體發生了變化。事務語意、PNR 結構、庫存管理邏輯：這些都在遷移到現代基礎設施的同時，保留了其基本設計。
為什麼替換比看起來更難：隱藏的複雜性
航空公司訂票系統為何仍運作在大型主機上，通常的解釋是成本和風險。這兩點的確存在。但它們只是更深層技術現實的表象，而這種現實值得我們深入理解，因為它適用於所有關鍵任務型遺留系統現代化改造專案。
僅存在於程式碼中的業務規則。全球分銷系統中的票價建構邏輯包含了數十年的監管要求、雙邊航空公司協議、國際航空運輸協會（IATA）標準修訂以及業務規則變更，而這些內容均未以任何獨立於實現它們的代碼的形式記錄下來。規範即是實現。在沒有規範的情況下替換實作意味著需要對現有系統的行為進行詳盡的觀察，以重建規範原本應包含的內容。這個過程耗時數年且永遠無法完成，因為觀察範圍永遠無法涵蓋所有極端情況。
現代架構難以複製事務語意。 TPF提供同步、原子事務處理，保證整個 PNR、座位保留、乘客記錄更新、支付授權和確認記錄的一致性，所有操作要么作為一個原子單元提交，要么根本不提交。在分散式微服務架構上複製此功能需要精心編排、交易補償和分散式鎖定管理，這既複雜又可能比同步大型主機上的同等功能慢。航空業的經驗表明，「最終一致性」對於座位庫存而言是不可接受的，超售航班是具體的、運營上災難性的故障，而不是可以稍後解決的暫時性不一致。
整合介面。成熟的航空公司旅客服務系統 (PSS) 連接著數百個外部系統：離港控制系統、收益管理系統、常旅客系統、機場系統、第三方全球分銷系統 (GDS) 連接、代碼共享合作夥伴、監管報告系統等等。每個連接都有特定的介面協定、訊息格式、時序要求和錯誤處理機制，這些協定、要求和機制都是現有系統所實現的，並且所有依賴系統都是圍繞這些協定建構的。替換 PSS 需要同時維護所有現有的介面協定（這會限制替換架構），或者需要與每個依賴系統協調變更（這會將範圍擴展到任何單一程式都無法管理的程度）。
即時數據難題。航空公司預訂數據是即時數據，這些預訂通常提前數月完成，必須嚴格按照預訂內容執行。舊系統的資料無法完全遷移，因此不存在可以忽略的乾淨俐落的切換點。遷移必須將舊系統中所有即時PNR資料完整地遷移到新系統，包括所有相關的規則、票價、限制和輔助服務。在全球範圍內實現PNR遷移，並確保零資料遺失和行為完全一致，已被證明是企業現代化改造中最具挑戰性的技術難題之一。
建築應對方案：圍繞核心進行現代化改造
在 Amadeus、Sabre 和各家航空公司，真正成功的做法不是替換，而是策略包裝和逐步提取。
API封裝將核心預訂功能以現代REST或SOAP API的形式公開，使新應用程式能夠透過現代介面與原始系統交互，而無需觸及核心事務邏輯。航空公司已在API層之上建立了行動應用程式、網頁預訂引擎和客戶服務工具，這些API層將現代請求轉換為TPF事務呼叫並傳回結構化回應。綠幕終端被現代圖形使用者介面（GUI）取代；底層事務處理流程保持不變。
對於非核心功能，我們採用「絞殺者無花果」式的萃取方法。與核心功能相鄰的功能，例如收益管理、會員計畫管理、報表和分析、機組人員排班等，會被逐一提取出來，並在現代化的基礎設施上重新部署。每次提取都能在不觸及風險最高的交易核心的前提下，減少原有系統的資源佔用。經過十多年的逐步提取，原有系統的角色從一個包羅萬象的應用平台逐漸縮小為一個專注於特定交易功能的引擎。
雲端基礎設施架構得以保留。 Amadeus的主機退役計畫將工作負載遷移到雲端基礎設施，同時保留了源自主機的事務架構。硬體發生了變化；軟體設計、資料模型、事務語義、PNR 結構等，都保留了數十年來被證明正確的架構決策。
在保留原有PNR的基礎上，引入了新的報價和訂單管理模式。航空公司正在將IATA ONE訂單標準作為與現有PNR系統並行的一層進行部署，該標準以現代化的訂單管理模型取代了基於PNR的記錄。 Sabre在2026年與WestJet的續約協議中提及的下一代報價和訂單技術，將此定位為未來的發展方向，而非取代PSS，而是增加一個現代化的商業層，最終處理越來越多的預訂，而PNR核心系統則處理剩餘部分。
這對任何關鍵任務型傳統系統現代化意味著什麼
航空公司訂票系統的故事並非航空業獨有。它是銀行核心系統、保險單管理、電信計費和政府福利處理等領域普遍存在的一種模式的最顯著例證：軟體成為業務規則的權威規範，作為數十個依賴系統的整合中心，並且其運行規模和可靠性要求使得大規模替換變得真正不可行。
這些經驗教訓在各行業都是一致的：
在任何現代化改造開始之前，從程式碼中提取業務規則是必不可少的。實現票價建構、代碼共享協議邏輯和監管合規規則的 COBOL 和 TPF 程序是這些規則僅存的文件。如果不先提取並驗證這些邏輯，現代化改造就無法產生在所有情況下都能正確運行的替代方案，因為如果不分析所有程式碼，就無法了解所有情況。
依賴關係圖決定了遷移順序。沒有一家航空公司能夠成功地從最關鍵、整合度最高的組件著手來替換其旅客服務系統 (PSS)。所有成功的現代化改造都是從邊緣系統開始的，例如報告系統、輔助服務、非關鍵的行政職能，然後逐步向內推進。這個順序源自於依賴關係圖：哪些元件的外部依賴最少，就可以優先處理，最安全。
每一步的運行驗證都至關重要，不容商榷。雙系統並行運行驗證方法，即新系統與舊系統並行運行，比較輸出結果，並在任何流量轉移之前驗證其等效性，是唯一能夠滿足系統可靠性要求的方案，因為此類系統的故障會造成物理、經濟和監管方面的後果。
SMART TS XL 適用於航空公司相關傳統分析
航空公司如果同時運行 Sabre 或 Amadeus PSS 以及自己的 COBOL 程序、費率計算系統、收入會計、忠誠度積分計算、監管報告，就會面臨與每個企業大型機現代化項目完全相同的分析挑戰：在決定如何處理代碼之前，了解代碼實際包含的內容。
SMART TS XL“ 靜態程式碼分析 提取嵌入在 COBOL 程序中的業務規則邏輯、票價驗證規則、收入核算計算以及會員等級資格邏輯，這些邏輯僅存在於程序代碼中。對於計劃在不觸及 PSS 核心的情況下升級相鄰系統的航空公司而言，此提取過程產生的規範是替換系統必須滿足的條件。
應用程式依賴關係映射建立了依賴關係圖，該圖決定了遷移順序：哪些航空公司端程式依賴來自 PSS 的哪些資料來源，哪些報表程式依賴哪些 COBOL 批次輸出，以及當任何元件發生變更時，哪些下游系統必須更新。依賴關係圖使得增量式、安全的現代化成為可能，Sabre 和 Amadeus 也採用了相同的方法來實現核心系統，並將此方法應用於圍繞核心系統的航空公司端程式碼。
影響分析能力能夠解答所有現代化決策之前都必須面對的問題：如果這個程式改變，還有哪些面向會受到影響？對於航空公司係統而言，收入會計程序中的計算變更可能會同時影響監管報告、合作夥伴結算和財務合併，因此，在進行任何變更之前了解其影響範圍，是滿足航空公司可靠性要求的變更控制的先決條件。
遺留系統現代化分析提供了完整的現代化前清單：涵蓋所有相關程序、其複雜性、依賴關係、死代碼比例以及遷移風險等級。所有航空公司現代化專案的經驗教訓——從邊緣入手，逐步向內推進，並在每個步驟進行驗證——都要求我們了解邊緣在哪裡以及依賴結構是什麼樣的。這些知識來自於實際程式碼的結構分析，而不是來自於程式碼演化之前所寫的文件。
關鍵任務軟體的地質層
2026 年，當你用智慧型手機預訂機票時，你接觸的軟體其實是由多個截然不同的「地質層」構成的。最外層是現代化的使用者介面，其下是 API 層，再往下是 PSS 交易引擎。這套系統運作在基礎設施之上，雖然自 20 世紀 60 年代以來已經發生了翻天覆地的變化，但它仍然保留著當初設計時就正確無誤、且久經考驗的可靠交易語義和數據模型。
航空公司訂票系統並非現代化的失敗。它是六十年來工程師和管理人員理性決策的成果。他們每次提出替代方案時，都明白出錯的風險遠大於保留現有系統的成本。能夠長期運作的系統，都是憑藉著一次次交易、一次次航班、一個個預訂季的累積而贏得認可的。
對於任何現代化團隊而言，切實可行的經驗教訓並非舊系統永遠不應該被替換，而是替換決策必須在充分了解其包含內容、依賴關係以及實際變更範圍之後做出，而不是在未評估複雜性之前做出樂觀估計。航空業為此付出了慘痛的代價。正是那些能夠在編寫第一行新程式碼之前就提供完整結構資訊的分析工具，使得以更經濟的方式學習這些知識成為可能。
