
Vấn đề xây dựng một ngành công nghiệp
The Problem That Built an Industry
Vấn đề xây dựng nên một ngành công nghiệp Phần 1/6 trong loạt bài Iron Core — cơ sở hạ tầng 60 năm tuổi phục vụ 4,5 tỷ người mỗi năm. Vào tháng 12 năm 2025, ai đó ở Technogise đã mở MakeMyTrip's...
Vấn đề đã xây dựng nên một ngành công nghiệp
Phần 1/6 trong loạt phim Iron Core — cơ sở hạ tầng 60 năm tuổi phục vụ 4,5 tỷ người mỗi năm.
Vào tháng 12 năm 2025, một người nào đó ở Technogise đã mở nền tảng công ty của MakeMyTrip, nhập điểm đến và đặt cho tôi hai chuyến bay đến London. Toàn bộ sự việc diễn ra chưa đầy một phút. Một email xác nhận đã đến hộp thư đến của tôi. Đã xuất hiện tham chiếu đặt chỗ gồm sáu ký tự: DDTCIV và DHB4AL.
Tôi định phát biểu tại ContainerDays 2026. Hội nghị về vùng chứa, điều phối và cơ sở hạ tầng dựa trên nền tảng đám mây — loại hệ thống hiện đại, phù du, không trạng thái mà tôi dành cả cuộc đời làm việc của mình để suy nghĩ.
Điều trớ trêu chỉ xảy đến với tôi trên chuyến bay tới.
Cơ sở hạ tầng đặt chỗ các chuyến bay đó được thiết kế vào năm 1960. Cơ sở hạ tầng này chạy trên hệ điều hành có trước Unix. Nó nói một ngôn ngữ lệnh được xây dựng cho teletypes. Nó đã chạy liên tục mà không cần viết lại hoàn toàn trong hơn sáu thập kỷ — và xử lý khoảng 10.000 giao dịch mỗi giây vào lúc cao điểm.
Tôi xây dựng hệ thống phân tán. Tôi nghĩ tôi hiểu cơ sở hạ tầng phức tạp. Sau đó, tôi nhìn vào thẻ lên máy bay của mình và kéo sợi chỉ.
Đây là loạt bài gồm sáu phần về những gì tôi đã tìm thấy.
Thế giới trước SABRE
Để hiểu lý do tồn tại của cơ sở hạ tầng này, bạn cần hiểu vấn đề mà cơ sở hạ tầng này được xây dựng để giải quyết.
Vào giữa những năm 1950, American Airlines đã quản lý việc đặt chỗ trên thẻ chỉ mục. Việc đặt chỗ yêu cầu một cuộc gọi điện thoại đến đại lý, người này sẽ tìm kiếm các giá đựng thẻ vật lý ở nhiều văn phòng thành phố, xác nhận tình trạng sẵn sàng bằng lời nói và gọi lại cho hành khách. Việc đặt chỗ xuyên Đại Tây Dương có thể mất 90 phút để xác nhận. 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 trên hơn 50 thành phố. Hệ thống đang sập.
Nguồn gốc của cái sẽ trở thành GDS — Hệ thống phân phối toàn cầu — gần như là thần thoại. Năm 1953, C.R. Smith, chủ tịch American Airlines, ngồi cạnh R. Blair Smith, 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ọ hạ cánh, bản phác thảo của giải pháp đã được phác thảo. IBM và American Airlines đã ký kết quan hệ đối tác phát triển chính thức vào năm 1959.
Kết quả là SABRE — Môi trường nghiên cứu kinh doanh bán tự động. Nó đi vào hoạt động vào năm 1964.
Cùng năm IBM System/360 được công bố. Ba năm trước máy ATM đầu tiên. Năm năm trước khi hạ cánh 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 làm theo:
| GDS | Được sáng lập | Chủ sở hữu ban đầu | Tech Tổ chức |
|---|---|---|---|
| SABRE | 1964 | American Airlines + IBM | 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 | Bull mainframe → Unix |
Chú ý chủ đề chung. Tất cả đều hội tụ trên cùng một thời gian chạy cơ bản. Điều này đưa tôi đến với phần công nghệ mà hầu hết các kỹ sư phần mềm chưa bao giờ nghe đến và gần như chắc chắn đang xử lý việc đặt vé máy bay ở đâu đó trên thế giới khi bạn đọc nội dung này.
TPF — Hệ điều hành không chịu ngừng hoạt động
Cơ sở xử lý giao dịch (TPF) là hệ điều hành máy tính lớn của IBM có nguồn gốc từ ACP, Chương trình kiểm soát hàng không ban đầu của American Airlines. Nó được thiết kế cho một mục đích: xử lý khối lượng lớn giao dịch đơn giản với thời gian phản hồi dưới một phần nghìn giây.
Nó không phải là Unix. Nó không chia sẻ dòng dõi, triết lý hoặc sự trừu tượng của Unix. Nó có trước Unix một thập kỷ.
Hiểu TPF đòi hỏi phải gạt bỏ hầu hết mọi thứ bạn biết về hệ điều hành hiện đại sang một bên:
| Thuộc tính | TPF | Hiện đại OS |
|---|---|---|
| Mô hình quy trình | Không có quy trình nào. Không có chủ đề. Các "chương trình" tồn tại trong thời gian ngắn thực thi và thoát ra. | Quy trình, luồng, coroutine |
| Mô hình bộ nhớ | Các "ô" bộ nhớ cố định trên mỗi giao dịch. Không có đống. Không có phân bổ động. | Bộ nhớ ảo, vùng nhớ khối xếp, GC |
| Mô hình I/O | I/O đồng bộ cực nhanh với DASD (Truy cập trực tiếp Bộ nhớ) | I/O không đồng bộ, bộ nhớ khối, NVMe |
| Lập lịch | Ưu tiên, dựa trên mức độ ưu tiên, chi tiết micro giây | Thường mili giây mức độ chi tiết |
| Mô hình lỗi | Khôi phục cấp độ giao dịch. Hệ thống không gặp sự cố — giao dịch xảy ra. | Tùy thuộc vào ứng dụng |
| Ngôn ngữ chính | Trình biên dịch. C đã được thêm sau. | Mọi thứ |
Thông tin chi tiết quan trọng là TPF không thực sự là một hệ điều hành như bạn nghĩ. Nó gần giống với cái mà ngày nay chúng ta gọi là thời gian chạy giao dịch — một hệ thống được xây dựng có mục đích để nhận một đơn vị công việc, thực thi một chương trình ngắn dựa trên đơn vị công việc đó, cam kết thay đổi trạng thái và tiếp tục ngay lập tức. Không có daemon. Không có chủ đề nền. Không có trạng thái kết nối nào tồn tại 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. Nó đặc biệt làm tốt 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 rằng các chuyến bay có giá rẻ - con số đó có thể lên tới 50.000 TPS. Hành trình khứ hồi của tin nhắn từ đầu đến 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 chuyển từ máy tính lớn sang Unix, các hãng hàng không đã xem xét các con số hiệu suất và giữ nguyên. Những sự thay thế không thể phù hợp với thông lượng. Nhiều người vẫn không thể. Các máy tính lớn dòng Z của IBM chạy z/TPF ngày nay không còn lỗi thời nữa. Họ đang điều hành nó vì không có gì khác có thể đánh bại nó trong công việc cụ thể này trong 60 năm qua.
Có một bài học trong đó. Tôi sẽ quay lại vấn đề này.
Chuyến bay của tôi phù hợp với điều này ở đâu
Khi Technogise đặt chuyến đi ContainerDays của tôi thông qua myBiz, việc đặ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 của mình — hệ thống ra đời từ mối quan hệ 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 máy tính lớn Bull gốc 1987. Nó di chuyển sang Unix vào những năm 1990 và từ đó đã dần dần chuyển sang một kiến trúc hiện đại hơn. Nhưng mô hình dữ liệu, giao thức và quan trọng là ngôn ngữ lệnh mà các đặc vụ sử dụng - chế độ khó hiểu - vẫn liên tục với thiết kế ban đầu của những năm 1960. Định dạng PNR của tôi, cấu trúc vé điện tử của tôi, 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òn phức tạp hơn nữa. 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 cơ sở hạ tầng của 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 đợt di chuyển PSS của hãng hàng không lớn nhất trong lịch sử hàng không Châu Á.
Chuyến về — DHB4AL, MAN→LHR→DEL→NAG — kết hợp giữa 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 đó chính là điều đã giúp việc đặt phòng thành công. Đó cũng là điều khiến việc điều chỉnh lại có hiệu quả khi có sự cố xảy ra — và mọi việc đã xảy ra không ổn.
Nhưng tôi đang đi trước chính mình.
IndiGo và sự khác biệt giữa các nhà cung cấp dịch vụ ngân sách
Có một hãng hàng không lớn khác của Ấn Độ đáng để tìm hiểu trước khi chúng ta đi xa hơn: IndiGo.
IndiGo — hãng hàng không lớn nhất Ấn Độ tính theo thị phần — không sử dụng Amadeus. Nó sử dụng Navitaire, một PSS được chế tạo riêng cho các nhà cung cấp dịch vụ 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 biệt. Nền tảng NewSkies của Navitaire được xây dựng có mục đích dành cho các chuyến bay có khối lượng lớn, lợi nhuận thấp, điểm-điểm — không nối chuyến, không xây dựng giá vé phức tạp, không có hành lý cũ.
Đây là sự lựa chọn kiến trúc có chủ ý. Navitaire vận hành rẻ hơn, cấu hình nhanh hơn và được tối ưu hóa cho mô hình IndiGo: tần suất cao, giá cố định, độ phức tạp tối thiểu. Sự đánh đổi là giảm khả năng tương tác. IndiGo phân phối hàng trong kho vào Amadeus để đặt chỗ cho đại lý du lịch — bạn có thể thấy các chuyến bay 6E trong màn hình hiển thị tình trạng phòng trống khó hiểu — nhưng hệ thống bán vé và làm thủ tục hoàn toàn là của Navitaire.
Sự phân chia có ý nghĩa quan trọng khi có sự cố xảy ra. Sự chậm trễ của IndiGo ảnh hưởng đến kết nối của Air India không kích hoạt việc tự động điều chỉnh lại giữa các hệ thống. Con người phải can thiệp.
| Hãng hàng không | PSS | GDS Phân phối |
|---|---|---|
| Air India (AI) | Amadeus Altéa | Amadeus (chính) |
| IndiGo (6E) | Navitaire NewSkies | Amadeus / Sabre (thông qua lớp phân phối) |
| Vistara (được hấp thụ vào AI) | Amadeus Altéa | Amadeus |
| Air India Express | Navitaire | Amadeus / Saber |
Việc đặt trước 30 giây thực sự kích hoạt
Khi myBiz xác nhận việc đặt chỗ của tôi ở Tháng 12 năm 2025, trình tự sau đã được kích hoạt:
Quản trị viên du lịch công nghệ (cổng thông tin công ty myBiz)
↓
Lớp OTA MakeMyTrip (kiểm tra tình trạng sẵn có, giá cả)
↓
Amadeus GDS (số lượng chỗ ngồi, PNR sáng tạo)
↓
Air India Altéa PSS (xác nhận chặng, trạng thái HK)
↓
IATA BSP (Gói thanh toán thanh toán) — định tuyến thanh toán
↓
Vé điện tử được xuất theo mã số Air India 098
↓
PNR DDTCIV đã được tạo, lưu trữ trong Amadeus
↓
Email xác nhận → myBiz → Technogise → tôiMỗi mũi tên là một ranh giới hệ thống. Mỗi ranh giới có giao thức riêng, chế độ lỗi riêng và đặc điểm nhất quán cuối cùng của riêng nó. Việc đăng ký 30 giây che giấu một chuỗi cuộc gọi đồng bộ và không đồng bộ trên các hệ thống được xây dựng trong nhiều 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 liên kết tất cả 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 gì và tại sao dòng tính giá vé trên vé điện tử của tôi là một trong những chuỗi chứa nhiều thông tin nhất trong ngành hàng không thương mại.
Bài học mang về
Thể dục phù hợp với mục đích hơn kiến trúc thời thượng. TPF không hiện đại. Nó sẽ thất bại trong mọi đánh giá kiến trúc mà một nhóm kỹ thuật đương thời áp dụng cho nó. Nó cũng xử lý 50.000 giao dịch mỗi giây với độ trễ dưới 100 mili giây trên phần cứng có chi phí chỉ bằng một phần dấu chân đá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ụ phù hợp cho công việc phù hợp, được bảo trì tốt, rất khó bị đánh bại.
Sự tiến hóa hội tụ là có thật. Mọi GDS chính đều đến cùng một nền tảng cơ bản một cách độc lập. Đó không phải là sự trùng hợp ngẫu nhiên - đó là thị trường đang khám phá ra giải pháp tối ưu cho một vấn đề cụ thể. Khi bạn nhìn thấy mẫu đó trong miền của riêng mình, hãy chú ý đến nó.
Việc di chuyển rất tốn kém. Việc Air India chuyển đến Amadeus Altéa vào năm 2023 đã được chuẩn bị trong nhiều năm. Một công ty có quy mô như một hãng hàng không, với lịch sử đặt chỗ hàng thập kỷ, các thỏa thuận liên hãng, 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ể chỉ đơn giản là "nâng lên và thay đổi". Vết sẹo từ cuộc di cư đó vẫn còn hiện rõ trong ngành. Tôi sẽ quay lại ở Phần 4.
Tiếp theo: Phần 2 — Sáu nhân vật. DDTCIV thực sự là gì, nó chứa gì và tại sao nó kém độc đáo hơn bạn nghĩ.
The Iron Core là một bộ truyện gồm sáu phần của Ajitem Sahasrabuddhe. Ajitem là kỹ sư phần mềm tại Technogise và phát biểu tại ContainerDays 2026 ở Luân Đôn.
Tác giả: ShaggyHotDog