11 мин

6.4K

Представляем вам перевод первой статьи из серии материалов об информационных технологиях в авиаперевозках. Серия называется «Iron Core». Речь здесь пойдёт о ядре, о фундаментальной инфраструктуре информационных систем авиационной индустрии. Ядро это, созданное около 60 лет тому назад, до сих пор не теряет актуальности. Ежегодно оно обеспечивает организацию перелётов для 4,5 миллиардов человек.

Всё началось в 1953 году — с одного разговора, произошедшего на борту самолёта и давшего начало разработке технологического стека, который в наши дни обрабатывает десятки тысяч бронирований авиабилетов в секунду. Поразмышляем о том, почему этот стек до сих пор не потерял актуальности.

В декабре 2025 года кто-то из Technogise (я работаю в этой компании) вошёл в корпоративный раздел платформы MakeMyTrip, ввёл необходимые данные и забронировал мне билеты, организовав путешествие в Лондон. Всё это дело заняло меньше минуты. Письмо с подтверждением тут же попало ко мне во «Входящие». Там, кроме прочего, были шестисимвольные коды бронирования: DDTCIV и DHB4AL.

Я собирался выступать на конференции ContainerDays 2026. Она посвящена контейнерам, оркестрации и облачным инфраструктурам — всем тем современным эфемерным системам, не хранящим состояние, в размышлениях о которых проходят мои рабочие будни.

Ирония ситуации дошла до меня лишь во время полёта.

Архитектура инфраструктуры, благодаря которой были организованы мои полёты, берёт своё начало в 1960-х годах. Она до сих пор использует технологии, возникшие до появления Unix, в ней применяются командные языки, созданные для телетайпов. Её реализация, аппаратное обеспечение, сопутствующее ПО — всё это много раз заменялось и обновлялось. Но при этом неизменными оставались модель данных, протоколы, семантика транзакций. То, чем пользуются в наши дни, не появилось в результате некоего разового переписывания кода: изменения накапливались, система развивалась, не прекращая обслуживать полёты. И в наши дни она продолжает функционировать, обрабатывая, в моменты пиковых нагрузок, десятки тысяч транзакций в секунду.

Я занимаюсь разработкой распределённых систем. Я думал, что понимаю то, как работают сложные вычислительные инфраструктуры. Тогда, в самолёте, я посмотрел на свой посадочный талон и решил разобраться в том, как всё устроено в авиации. В результате то, о чём я узнал, превратилось в серию из шести статей.

Каким был мир до SABRE?

Для того чтобы понять то, почему в авиации существует подобная инфраструктура, надо чётко представлять себе задачу, для решения которой она была создана.

В середине 1950-х компания American Airlines вела учёт бронирований рейсов с помощью бумажных каталожных карточек. Для того чтобы заказать билет, нужно было позвонить агенту, который проверял картотеки в офисах разных городов, устно подтверждал доступность билетов и перезванивал пассажиру. Подтверждение бронирования на трансатлантический рейс могло занять до 90 минут. Авиакомпания обрабатывала примерно 85000 запросов на бронирование в день более чем в 50 городах. Система балансировала на грани коллапса.

История создания того, что стало называться GDS (Global Distribution System, глобальная дистрибьюторская система), отлично задокументирована, хотя, в пересказах и обросла некоторыми мифами. В 1953 году С. Р. Смита, президента American Airlines, разместили в кресле самолёта рядом со специалистом по продажам IBM Р. Блэром Смитом. Полёт был долгим. Через 6 лет IBM и American Airlines заключили официальное соглашение о сотрудничестве.

В результате этого сотрудничества и появилась система SABRE (Semi-Automated Business Research Environment, полуавтоматическая среда для коммерческих исследований). Её запуск состоялся в 1964: через пять лет после соглашения 1959 года и через одиннадцать лет после разговора, состоявшегося на борту самолёта в 1953 году.

Таковы сроки разработки и ввода в эксплуатацию подобных систем. В тот же год, когда была запущена система SABRE, IBM объявила о выходе System/360. Это случилось за три года до появления первого банкомата. За пять лет до высадки человека на Луну. За пятнадцать лет до выпуска VisiCalc.

В следующие десять лет все крупнейшие авиакомпании последовали примеру первопроходцев:

Четыре из пяти технологических стеков, представленных в этой таблице и созданных в Северной Америке, были основаны на операционной системе IBM TPF (или на её предшественнице ACP). Исключение — Amadeus. Сначала в этой системе применялись мэйнфреймы Bull, а позже — Unix. И хотя не все эти проекты работали на одних и тех же компьютерных системах, всем им нужно было решать задачу одного и того же вида. А именно: обрабатывать огромные количества маленьких транзакций, чувствительных к задержкам. Эти транзакции выполнялись в условиях единых правил расчётов, работая с общим хранилищем со сведениями о рейсах. Происходило всё это в условиях, где стандарты IATA (International Air Transport Association, международная ассоциация воздушного транспорта) и добровольные коммерческие соглашения между авиакомпаниями делали отклонения от общепринятой практики слишком дорогими.

То, что разные подходы к решению задачи бронирования оказались очень похожими друг на друга, не было результатом случайного совпадения инженерных подходов. Стандарты обмена сообщениями IATA, соглашения между авиакомпаниями, издержки, возникающие из-за несовместимости систем — всё это подтолкнуло разные авиакомпании к созданию совместимых решений. Когда в разных частях какой-нибудь сферы деятельности появляются сходные технологические решения — это говорит о том, что нормативные стандарты и стоимость перехода на другие технологии обычно влияют на создание этих решений сильнее, чем результаты независимых изысканий.

TPF: операционная система, которая отказывается умирать

Transaction Processing Facility (TPF) — это операционная система для мэйнфреймов IBM, предком которой является ACP (Airline Control Program) — система, изначально разработанная для American Airlines и предназначенная для управления авиаперевозками. Эта ОС была создана в расчёте на решение единственной задачи: обработка огромного объёма простых транзакций с задержками, не превышающими одной миллисекунды.

Это не Unix. У них нет общих предков, общей философии создания и использования системы, общих абстракций. Эта система появилась на десятилетие раньше Unix.

Для того чтобы разобраться в том, что это такое, надо забыть почти всё, что нам известно о современных операционных системах:

TPF — это, в привычном понимании, не вполне то, что принято считать «операционной системой». Это ближе к тому, что в наши дни называют средой выполнения транзакций (transaction runtime). Это — система, созданная специально для того, чтобы принять логическую единицу работы, выполнить с её использованием короткую программу, зафиксировать изменения состояния системы и немедленно перейти к следующей задаче. Путь прохождения транзакции с точки зрения приложения умышленно минимизирован: тут нет долгоживущих процессов-воркеров, привязанных к конкретным клиентам и удерживающих состояние соединения в памяти между выполнением отдельных задач. В ходе обслуживания транзакции не применяется обычная для Unix модель выделения отдельного потока на каждый запрос. При этом в TPF, на уровне ОС, существуют система планирования, подсистема ввода/вывода и системные процессы. Вышесказанное не означает, что система, в паузах между обработкой транзакций, вообще ничего не делает.

Подобная архитектура создавалась для решения единственной задачи. И задачу эту она решает исключительно хорошо.

Современные системы, основанные на TPF, обрабатывают, в обычных условиях, около 10000 транзакций в секунду (TPS, Transaction Per Second). Во время распродаж, когда миллионы покупателей одновременно узнают о том, что авиабилеты подешевели, этот показатель может достигнуть 50000 TPS. Сквозная круговая задержка при передаче сообщения составляет примерно 100 миллисекунд. Эти показатели отражают особенности жёсткой транзакционной модели и являются результатом шестидесяти лет практической эксплуатации и оптимизации систем бронирования авиаперелётов.

В 1990-х годах, когда все остальные переходили с мэйнфреймов на Unix, авиакомпании взглянули на показатели производительности новых систем и решили ничего не менять. Альтернативные решения не могли дать сопоставимой пропускной способности в интересующих авиакомпании задачах. И до сих пор многие системы этого не могут. Мейнфреймы серии IBM-Z, работающие под управлением ОС z/TPF, используются до сих пор совсем не из чувства ностальгии.

Sabre (компания) в наши дни продаёт облачные услуги, предназначенные для решения задач авиакомпаний, а так же — предлагает API-First-продукты. В авиационной индустрии параллельное использование старых базовых систем и современных интерфейсов встречается гораздо чаще, чем об этом можно подумать, читая новости.

Какое отношение это имеет к моим билетам?

Когда сотрудник Technogise забронировал мне билеты, необходимые для посещения ContainerDays, воспользовавшись myBiz, заказ затронул определённую часть описываемой экосистемы. Платформа MakeMyTrip использует, в роли GDS, систему Amadeus. Эта система появилась в 1987 году — как результат сотрудничества компаний Air France, Lufthansa, Iberia и SAS. Теперь это — ведущая GDS в Европе, в Индии и в большей части стран Азиатско-Тихоокеанского региона.

Amadeus не использует мэйнфреймы Bull, с которых всё началось. В 1990-х годах эта система перешла на Unix и с тех пор её программно-аппаратная основа постоянно обновляется. Но модель данных, протокол, командный язык, используемый агентами (cryptic mode — режим командной строки) не теряют связи с исходными наработками 1960-х годов. Формат моего PNR-кода, структура электронного билета, то, как вычисляется стоимость перелёта: всё это подчиняется правилам, утверждённым ещё до моего рождения.

Мой перелёт на конференцию полностью обслуживался компанией Air India (DDTCIV, NAG→DEL→LHR). В Air India используется Amadeus Altéa. Это — современная PSS (Passenger Service System, система обслуживания пассажиров), построенная на базе инфраструктуры Amadeus. Авиакомпания перешла на неё В 2023 году, заменив устаревшую систему SITA. Это — одна из крупнейших миграций такого рода в авиационной истории Азии. Стоимость и сложность этого перехода — темы, на которых стоит остановиться подробнее. Мы сделаем это в 4 части этой серии статей.

Обратный перелёт (DHB4AL, MAN→LHR→DEL→NAG) обслуживали несколько авиакомпаний — British Airways (тут тоже используется Amadeus Altéa) и Air India. Так как оба перевозчика на моём маршруте используют один и тот же технологический стек — Amadeus — один и тот же PNR может использоваться обеими компаниями. Здесь нет необходимости пользоваться специальными мостами между PSS разных разработчиков. Именно эта унификация позволила оформить мои билеты, а так же — в случае, если что-то пошло бы не так — именно она позволила бы их переоформить.

IndiGo и особенности бюджетных авиакомпаний

IndiGo (крупнейшая, по доле рынка, авиакомпания в Индии) не пользуется продуктами Amadeus. В этой авиакомпании применяется разработка Navitaire — PSS, созданная специально для лоукостеров. И хотя этой PSS сейчас владеет Amadeus, функционирует она как отдельный продукт. Платформа NewSkies, созданная Navitaire, изначально создавалась в расчёте на высокие объёмы перелётов с низкой маржинальностью, на point-to-point-рейсы (прямой перелёт из точки А в точку Б). При использовании такой системы не нужно учитывать особенности соглашений между авиакомпаниями. Здесь нет сложных механизмов расчёта тарифов, нет нужды поддерживать совместимость с устаревшими системами.

Это — осознанный архитектурный выбор. Решение Navitaire лучше подходит под бизнес-модель IndiGo: высокая частота перелётов, фиксированные цены, минимальная сложность. В результате оно выигрывает у других подобных решений: оно дешевле, его легче настраивать, оно лучше оптимизировано. Но за всё надо платить. В данном случае минусы заключаются в ограниченной совместимости с другими системами. IndiGo передаёт сведения о рейсах в Amadeus, что позволяет клиентам бронировать билеты через туристические агентства (это — рейсы с кодом 6E, которые можно увидеть в cryptic mode-терминалах). А вот системы оформления билетов и регистрации на рейс в IndiGo полностью основаны на решении Navitaire.

Это разделение приводит к появлению определённых сложностей в том случае, если что-то идёт не так. Если рейс IndiGo опаздывает на стыковку с рейсом Air India, это не вызывает автоматического переоформления билетов, выполняемого в разных системах. Тут необходимо вмешательство человека.

Что, на самом деле, происходит в ходе бронирования, занимающего 30 секунд?

Когда платформа myBiz подтвердила в декабре 2025 года моё бронирование, произошло следующее:

Границы каждого блока символизируют границы различных систем. Внутри них используются собственные протоколы, собственные способы обработки отказов, собственные характеристики достижения согласованности в конечном счёте (eventual consistency). За процессом бронирования билетов, занимающим 30 секунд, скрывается целая цепь синхронных и асинхронных вызовов, выполняемых между системами, созданными в разные десятилетия, разными компаниями, в разных странах.

PNR-код, который получается в итоге (шесть символов, DDTCIV) — это нить, которая связывает это всё воедино.

В следующей части мы с вами расшифруем этот код, поговорим о том, что собой представляют эти шесть символов, что они содержат, и почему строка расчёта тарифа в моём электронном билете — это одна из самых информационно насыщенных строк в коммерческой авиации.

Итоги

Узкоспециализированная, отлично протестированная архитектура, которую поддерживают люди, глубоко её понимающие, может оказаться наилучшим инструментом для решения тех задач, под которые она создавалась. Её очень сложно заменить. Операционная система TPF далеко не нова. Она провалила бы большинство архитектурных ревью, которым могли бы её подвергнуть современные команды инженеров. Главное в ней — транзакционная модель, рассчитанная на работу с информацией о местах в самолётах и на взаиморасчёты. Её десятилетиями подвергали тонкой настройке, применяя в реальных условиях. Она способна справляться с пиковыми нагрузками в 50000 транзакций в секунду, обеспечивая сквозную задержку порядка 100 миллисекунд. Эти показатели — результат того, что архитектура идеально подогнана под рабочую нагрузку, а не общее свойство мэйнфреймов.

Похожие стеки технологий, используемые в некоей сфере деятельности, обычно указывают на ограничения, общие для всех компаний, работающих в этой сфере, а не на то, что изыскания специалистов из разных компаний привели к схожим результатам. История разработки GDS — это не рассказ о том, как разные компании, не связанные друг с другом, нашли одно и то же решение некоей задачи. Экономика эпохи, когда в ходу жёсткое регулирование всего и вся, соглашения между компаниями, стандарты обмена сообщениями IATA, сетевые эффекты, когда чем шире используется технология — тем она ценнее — всё это подтолкнуло авиакомпании к движению к совместимым решениям. Несколько крупных игроков рынка сделали ставку на TPF, используемую в качестве базовой системы обработки транзакций. Разработчики Amadeus пошли другим путём, но внешняя часть этой системы использует те же исторически сложившиеся решения, что и другие системы. Речь идёт о кодах PNR, о тарифах, о командном режиме работы с системой. Размышляя об этом, ценнее обратить внимание на то, почему расхождения между системами оказывались достаточно дорогим удовольствием, а не на то, почему инженеры из разных компаний принимали похожие решения.

Переходы на новые PSS — это проекты, занимающие годы и несущие неприятные последствия для компаний, решившихся на такой шаг. Переход Air India на Amadeus Altéa в 2023 году затронул собранную за десятилетия историю бронирований, соглашения о взаимодействии между авиакомпаниями, интеграцию программы лояльности, зависимые системы аэропортов. А после того, как система была запущена, влияние перехода на операционную деятельность Air India ощущалось ещё многие месяцы. Масштаб и возраст данных — это те факторы, которые отличают переход авиакомпаний на новые PSS от типичных в корпоративной среде замен программного обеспечения.