Hạ tầng 60 năm tuổi vận hành ngành hàng không: Vấn đề đã tạo nên cả một ngành công nghiệp

Vào tháng 12 năm 2025, một nhân viên của Technogise đã mở nền tảng doanh nghiệp của MakeMyTrip, nhập điểm đến và đặt cho tôi hai chuyến bay đến London. Toàn bộ quá trình diễn ra trong chưa đầy một phút. Một email xác nhận đã được gửi vào hộp thư của tôi cùng với hai mã đặt chỗ gồm sáu ký tự: DDTCIV và DHB4AL.

Tôi chuẩn bị có bài phát biểu tại ContainerDays 2026 — một hội nghị về container, điều phối (orchestration) và hạ tầng cloud-native (đám mây gốc), những hệ thống hiện đại, nhất thời và không trạng thái mà tôi dành cả đời nghề để suy ngẫm.

Sự mỉa mai chỉ thực sự chạm đến tôi khi tôi đang trên chuyến bay.

Hạ tầng đã thực hiện việc đặt những chuyến bay đó được thiết kế vào năm 1960. Nó chạy trên một hệ điều hành ra đời trước cả Unix. Nó sử dụng ngôn ngữ lệnh được xây dựng cho máy điện báo (teletypes). Và nó đã vận hành liên tục, không một lần viết lại hoàn toàn, trong hơn sáu thập kỷ — xử lý khoảng 10.000 giao dịch mỗi giây tại thời điểm cao điểm.

Tôi xây dựng các hệ thống phân tán. Tôi nghĩ mình hiểu về hạ tầng phức tạp. Nhưng rồi khi nhìn vào tấm thẻ lên máy bay của chính mình và bắt đầu gỡ rối, tôi mới nhận ra mình chưa biết gì cả.

Đây là phần đầu trong loạt bài sáu phần về những gì tôi đã tìm ra.

Hạ tầng hàng không cổ kính nhưng hiệu quả

Thế giới trước khi có SABRE

Để hiểu tại sao hạ tầng này tồn tại, ta cần hiểu vấn đề mà nó được tạo ra để giải quyết.

Đến giữa những năm 1950, American Airlines đang quản lý các đặt chỗ trên các thẻ chỉ mục (index cards). Một đặt chỗ yêu cầu một cuộc gọi điện thoại cho đại lý, người này sẽ tìm kiếm các giá thẻ vật lý qua nhiều văn phòng ở các thành phố khác nhau, xác nhận tình trạng sẵn có qua lời nói và gọi lại cho hành khách. Việc xác nhận một đặt chỗ xuyên Đại Tây Dương có thể mất tới 90 phút. Hãng hàng không này đang xử lý khoảng 85.000 yêu cầu đặt chỗ mỗi ngày tại hơn 50 thành phố. Hệ thống đang sụp đổ.

Nguồn gốc của cái mà sau này trở thành GDS — Hệ thống Phân phối Toàn cầu — gần như mang tính thần thoại. Năm 1953, C.R. Smith, chủ tịch American Airlines, ngồi cạnh R. Blair Smith, một nhân viên bán hàng của IBM, trên một chuyến bay xuyên quốc gia. Khi hạ cánh, phác thảo của một giải pháp đã được vẽ nên. IBM và American Airlines chính thức hợp tác phát triển vào năm 1959.

Kết quả là SABRE — Môi trường Nghiên cứu Kinh doanh Bán tự động (Semi-Automated Business Research Environment). Nó chính thức vận hành vào năm 1964.

Cùng năm IBM System/360 được công bố. Ba năm trước chiếc ATM đầu tiên. Năm năm trước khi con người đặt chân lên mặt trăng. Mười lăm năm trước bảng tính VisiCalc đầu tiên.

Trong vòng một thập kỷ, mọi hãng hàng không lớn đều đi theo:

• SABRE (1964): American Airlines + IBM (Nền tảng IBM ACP / TPF)
• Apollo (1971): United Airlines (IBM TPF)
• Galileo (1987): United + BA + KLM + Swissair (IBM TPF)
• Worldspan (1990): Delta + Northwest + TWA (IBM TPF)
• Amadeus (1987): Air France + Lufthansa + Iberia + SAS (Mainframe Bull → Unix)

Hãy nhận ra điểm chung. Tất cả đều hội tụ về cùng một nền tảng cơ bản. Điều dẫn tôi đến công nghệ mà hầu hết các kỹ sư phần mềm chưa từng nghe đến, và gần như chắc chắn đang xử lý một đặt chỗ máy bay somewhere trên thế giới ngay khi bạn đọc dòng này.

TPF — Hệ điều hành từ chối "chết"

Transaction Processing Facility (TPF) là hệ điều hành mainframe của IBM descended từ ACP, chương trình Airline Control Program gốc của American Airlines. Nó được thiết kế cho một mục đích duy nhất: xử lý khối lượng khổng lồ các giao dịch đơn giản với thời gian phản hồi dưới một mili-giây.

Nó không phải là Unix. Nó không chia sẻ dòng dõi, triết lý hay các trừu tượng của Unix. Nó ra đời trước Unix một thập kỷ.

Để hiểu TPF, bạn cần gạt bỏ hầu hết mọi thứ bạn biết về các hệ điều hành hiện đại:

• Mô hình quy trình: Không có quy trình (process), không có luồng (thread). Chỉ có các "chương trình" ngắn ngủi thực thi và thoát.
• Mô hình bộ nhớ: Các ô nhớ cố định cho mỗi giao dịch. Không có heap. Không có cấp phát động.
• Mô hình I/O: I/O đồng bộ cực nhanh đến DASD (Direct Access Storage).
• Lên lịch: Dựa trên ưu tiên, granularity ở mức micro-giây.
• Mô hình lỗi: Rollback ở mức giao dịch. Hệ thống không bị sập — chỉ có giao dịch thất bại.
• Ngôn ngữ chính: Assembler. Ngôn ngữ C được thêm vào sau này.

Thông điệp then chốt là TPF không thực sự là một hệ điều hành theo cách bạn nghĩ. Nó gần giống với những gì chúng ta gọi là runtime giao dịch — một hệ thống được xây dựng chuyên biệt để nhận một đơn vị công việc, thực thi một chương trình ngắn đối với nó, xác nhận thay đổi trạng thái và ngay lập tức chuyển sang việc tiếp theo. Không có daemon. Không có luồng nền. Không có trạng thái kết nối được duy trì trong bộ nhớ giữa các giao dịch.

Thiết kế này được tạo ra cho một khối lượng công việc cụ thể. Nó cực kỳ xuất sắc ở khối lượng công việc đó.

Các hệ thống dựa trên TPF hiện đại xử lý khoảng 10.000 giao dịch mỗi giây trong điều kiện bình thường. Trong đợt giảm giá vé — khi hàng triệu khách hàng cùng lúc phát hiện ra vé máy bay giá rẻ — con số đó có thể đạt tới 50.000 TPS. Thời gian khứ hồi thông tin đầu cuối: khoảng 100 mili-giây.

Vào những năm 1990, khi mọi ngành công nghiệp khác đang di chuyển khỏi mainframe sang Unix, các hãng hàng không nhìn vào các con số hiệu suất và ở lại. Các hệ thống thay thế không thể sánh được khả năng xử lý. Nhiều hệ thống đến giờ vẫn không thể. Các máy chủ mainframe IBM Z-series chạy z/TPF ngày nay không chạy nó vì hoài niệm. Chúng chạy nó vì không gì khác có thể đánh bại nó cho công việc cụ thể này trong 60 năm qua.

Ở đó có một bài học. Tôi sẽ quay lại vấn đề này sau.

Chuyến bay của tôi nằm ở đâu trong bức tranh này

Khi Technogise đặt chuyến đi ContainerDays của tôi thông qua myBiz, lượt đặt chỗ đã chạm đến một lớp cụ thể của hệ sinh thái này. MakeMyTrip sử dụng Amadeus làm GDS — hệ thống sinh ra từ sự hợp tác năm 1987 giữa Air France, Lufthansa, Iberia và SAS, và hiện là GDS thống trị trên khắp châu Âu, Ấn Độ và phần lớn châu Á - Thái Bình Dương.

Amadeus không chạy trên mainframe Bull gốc năm 1987. Nó đã di chuyển sang Unix vào những năm 1990, và từ đó đã dần chuyển sang kiến trúc hiện đại hơn. Nhưng mô hình dữ liệu, giao thức và quan trọng nhất là ngôn ngữ lệnh mà các đại lý sử dụng — chế độ mã hóa (cryptic mode) — vẫn liên tục với thiết kế gốc năm 1960. Định dạng PNR của tôi, cấu trúc vé điện tử, cách tính giá vé: tất cả đều tuân theo các quy ước được thiết lập trước khi tôi sinh ra.

Chuyến bay khứ hồi của tôi có một phức tạp thêm. Chuyến đi hoàn toàn là Air India — DDTCIV, NAG→DEL→LHR. Air India chạy trên Amadeus Altéa, một PSS (Hệ thống Dịch vụ Hành khách) hiện đại được xây dựng trên nền tảng hạ tầng Amadeus. Họ đã chuyển sang hệ thống này vào năm 2023, thay thế hệ thống SITA cũ trong một trong những lần di chuyển PSS hàng không lớn nhất lịch sử châu Á.

Chuyến về — DHB4AL, MAN→LHR→DEL→NAG — kết hợp British Airways (cũng chạy trên Amadeus Altéa) và Air India. Một PNR, hai hãng hàng không, cùng một nền tảng cơ bản. Sự nhất quán đó là điều khiến việc đặt chỗ hoạt động. Nó cũng là điều khiến việc sắp xếp lại chỗ (re-accommodation) hoạt động khi có sự cố — và sự cố thì đã xảy ra.

Nhưng tôi đang nói quá trước rồi.

IndiGo và sự phân kỳ của hãng giá rẻ

Có một hãng hàng không lớn khác của Ấn Độ đáng để hiểu rõ trước khi đi xa hơn: IndiGo.

IndiGo — hãng hàng không lớn nhất Ấn Độ về thị phần — không sử dụng Amadeus. Họ sử dụng Navitaire, một PSS được xây dựng riêng cho các hãng hàng không giá rẻ, hiện thuộc sở hữu của Amadeus nhưng hoạt động như một sản phẩm riêng. Nền tảng NewSkies của Navitaire được xây dựng chuyên biệt cho các chuyến bay điểm-điểm (point-to-point) khối lượng cao, biên lợi nhuận thấp — không có liên danh (interline), không có cấu trúc giá phức tạp, không có hành lý di sản.

Đây là một lựa chọn kiến trúc có chủ đích. Navitaire rẻ hơn để vận hành, cấu hình nhanh hơn và được tối ưu hóa cho mô hình của IndiGo: tần suất cao, giá cố định, độ phức tạp tối thiểu. Sự đánh đổi là khả năng tương tác giảm. IndiGo phân phối hàng tồn kho vào Amadeus cho các đặt chỗ của đại lý du lịch — bạn có thể thấy các chuyến bay 6E trong màn hình sẵn có mã hóa — nhưng hệ thống xuất vé và check-in hoàn toàn là Navitaire.

Sự chia cắt này quan trọng khi có sự cố. Một sự chậm trễ của IndiGo ảnh hưởng đến chuyến nối chuyến của Air India sẽ không kích hoạt việc sắp xếp lại chỗ tự động giữa các hệ thống. Con người phải can thiệp.

Những gì một lượt đặt chỗ 30 giây thực sự kích hoạt

Khi myBiz xác nhận đặt chỗ của tôi vào tháng 12 năm 2025, chuỗi sự kiện sau đã được kích hoạt:

1. Quản trị viên du lịch Technogise (cổng doanh nghiệp myBiz)
2. Lớp OTA MakeMyTrip (kiểm tra sẵn có, định giá)
3. GDS Amadeus (hàng tồn kho ghế, tạo PNR)
4. PSS Air India Altéa (xác nhận phân khúc, trạng thái HK)
5. IATA BSP (Kế hoạch thanh toán giải quyết) — định tuyến thanh toán
6. Vé điện tử được phát hành dưới mã số 098 của Air India
7. PNR DDTCIV được tạo, lưu trữ trong Amadeus
8. Email xác nhận → myBiz → Technogise → tôi

Mỗi mũi tên là một ranh giới hệ thống. Mỗi ranh giới có giao thức, chế độ lỗi và đặc tính nhất quán riêng của nó. Lượt đặt chỗ 30 giây che giấu một chuỗi các cuộc gọi đồng bộ và không đồng bộ qua các hệ thống được xây dựng trong các thập kỷ khác nhau bởi các công ty khác nhau ở các quốc gia khác nhau.

PNR ở cuối chuỗi đó — sáu ký tự, DDTCIV — là sợi chỉ giữ mọi thứ lại với nhau.

Trong phần tiếp theo, tôi sẽ giải mã chính xác sáu ký tự đó là gì, chúng chứa đựng những gì, và tại sao dòng tính giá vé trên vé điện tử của tôi lại là một trong những chuỗi thông tin dày đặc nhất trong hàng không thương mại.

Bài học chính

Phù hợp với mục đích vượt qua kiến trúc thời thượng. TPF không hiện đại. Nó sẽ thất bại trong mọi bài đánh giá kiến trúc mà một đội ngũ kỹ thuật đương đại áp dụng lên nó. Nhưng nó cũng xử lý 50.000 giao dịch mỗi giây với độ trễ dưới 100ms trên phần cứng có chi phí bằng một phần nhỏ so với hạ tầng đám mây tương đương. Nó đã làm điều này trong 60 năm. Bài học không phải là phần mềm cũ là phần mềm tốt — mà là công cụ đúng cho việc đúng, được bảo trì tốt, rất khó bị đánh bại.

Tiến hóa hội tụ là có thật. Mọi GDS lớn đều độc lập đi đến cùng một nền tảng cơ bản. Đó không phải là sự ngẫu nhiên — đó là thị trường tìm ra giải pháp tối ưu cho một vấn đề cụ thể. Khi bạn thấy mô hình đó trong lĩnh vực của chính mình, hãy chú ý đến nó.

Việc di chuyển rất tốn kém. Việc Air India chuyển sang Amadeus Altéa vào năm 2023 đã mất nhiều năm để chuẩn bị. Một công ty quy mô như một hãng hàng không, với lịch sử đặt chỗ nhiều thập kỷ, thỏa thuận liên danh, tích hợp chương trình khách hàng thân thiết và sự phụ thuộc vào hệ thống sân bay, không thể đơn giản là "nhấc và chuyển". Mô sẹo từ lần di chuyển đó vẫn còn nhìn thấy trong ngành. Tôi sẽ quay lại vấn đề này trong Phần 4.

Tiếp theo: Phần 2 — Sáu Ký tự. DDTCIV thực sự là gì, nó chứa đựng những gì, và tại sao nó ít độc đáo hơn bạn nghĩ.