Перед вами шестая и заключительная часть (а вот первая, вторая, третья, четвёртая и пятая) серии статей, посвящённых информационным технологиям в авиаперевозках. Сегодня мы поговорим об изменениях, происходящих в этой сфере. Системы, построенные на базе стандарта NDC, вот уже 14 лет пытаются вытеснить традиционные GDS. Этого до сих пор, в полной мере, не произошло. У такого положения дел есть определённые политико‑экономические причины. Здесь же автор расскажет о том, что он, благодаря инциденту с птицей, узнал о системах, которые вот уже много лет пытаются заменить.
На конференции ContainerDays 2026 я делал доклад о средах выполнения контейнеров. Я говорил о пространствах имён Linux, о контрольных группах, о примитивах ядра, благодаря которым возможно существование Docker и Kubernetes. Всё это часть современных инфраструктур, легко создаваемых и уничтожаемых, не хранящих сведения о состоянии систем. Это — системы, которые проектировались в расчёте на то, чтобы их можно было бы легко заменять на другие.
А инфраструктура, благодаря которой я попал на сцену, где делал доклад, была спроектирована ещё до появления Linux. До появления Unix. Даже до появления интернета.
Бронирование рейсов, доставивших меня на ContainerDays, было сделано сотрудником Technogise через портал myBiz и обработано системой Amadeus. Агент Amadeus, где‑то в ахмедабадском офисе MakeMyTrip, создал мой PNR‑документ, работая в терминале. Команды, которыми он пользовался, выглядели как те, которые мы рассматривали в третьей части. А модель данных, лежащая в основе структуры PNR, была сформирована в 1960-х годах.
IATA, ещё с 2012 года, планирует замену этой системы на новую, называемую NDC. Но сегодня, четырнадцать лет спустя, эта замена всё ещё, в полной мере, не состоялась.
Что такое NDC?
NDC (New Distribution Capability, новая дистрибутивная модель) — это XML‑стандарт, разработанный IATA для нужд авиационной отрасли. GDS (Global Distribution System, глобальная дистрибьюторская система) основана на командах, вводимых в терминале, на сообщениях формата SITA Type B, на модели данных, появившейся в эпоху телетайпов. А NDC обладает современным API. Этот API основан на XML, структурирован, спроектирован с расчётом на то, чтобы авиакомпании могли бы напрямую предоставлять более обширный набор данных и сервисов покупателям, подключённым к их системам.
Проблема, для решения которой создан стандарт NDC, вполне реальна. Существующая модель GDS ограничивает возможности авиакомпаний в плане того, что они могут продавать. Когда GDS возвращает ответ на запрос о наличии свободных мест — там имеются сведения о классах бронирования и о ценах. Эта система не может выдать сведения о дополнительных продуктах непосредственно в тот момент, когда с ней работает покупатель. Речь идёт о конкретных вариантах повышения класса обслуживания, о пропусках в бизнес‑залы, о пакетах премиального питания, о кобрендинговых кредитных картах. Обширные каталоги продуктов авиакомпаний невидимы для канала дистрибуции, обслуживаемого GDS.
А NDC меняет ситуацию, позволяя авиакомпаниям формировать ответы на запросы покупателей, выдавая им полный перечень предлагаемых товаров и услуг. Сравним новые возможности, которые даёт NDC, с возможностями старых систем.
Мир NDC
Поисковый запрос покупателя → API авиакомпании → Полное предложение. |
Места, багаж, питание, повышение класса обслуживания, комбинированные предложения. И всё это — в одном ответе на запрос. |
Возможности персонализации, основанные на программах лояльности и на особенностях поведения покупателя. |
Динамическое ценообразование, основанное на сегментации клиентов. |
Старый мир (EDIFACT или терминал)
Поисковый запрос покупателя → GDS → Сведения о местах и базовых тарифах. |
Запросы на дополнительные продукты и услуги обрабатываются отдельно, после создания бронирования. |
Технические спецификации NDC опубликованы, к ним открыт свободный доступ для всех желающих. Несколько авиакомпаний создали API, основанные на NDC. Несколько агрегаторов и TMC (Travel Management Company, Агентство делового туризма) создали NDC‑клиенты. Сама по себе эта технология вполне работоспособна.
А вот её широкое распространение — это уже совсем другая история.
Экономика сопротивления
Почему NDC внедряется в сферу авиаперевозок не особенно быстро? Чтобы с этим разобраться, нужно сначала понять то, как зарабатывают те, кто имеет отношение к существующим GDS.
Когда турагент бронирует рейс, пользуясь Amadeus, Sabre или Travelport, авиакомпания платит владельцу GDS сегментный сбор. Обычно — это что‑то в районе $3-5 за каждый забронированный полётный сегмент. Путешествие по маршруту NAG→DEL→LHR, содержащее 2 сегмента, обходится примерно $6-10. Ежегодно в крупной авиакомпании бронируются десятки миллионов полётных сегментов. А значит — только одна она приносит владельцу GDS сотни миллионов долларов.
Владельцы GDS платят турагентствам вознаграждения за бронирования. Это — фиксированная выплата за каждое бронирование, стимулирующая агентства пользоваться GDS, а не покупать билеты напрямую у авиакомпаний.
Внедрение NDC угрожает этим способам заработка. Авиакомпании хотят внедрять NDC, так как благодаря этому они смогут избавиться от сегментных сборов и продавать билеты напрямую агрегаторам и онлайн‑агентствам. Турагенства занимают неоднозначную позицию. Внедрение NDC может означать для них потерю вознаграждений за бронирования, а так же — необходимость создания множества новых каналов взаимодействия с различными авиакомпаниями вместо использования одного GDS‑терминала. А компании, владеющие GDS, не спешат ускорять собственное вытеснение с рынка.
Кого устраивают медленные темпы внедрения NDC
Владельцы GDS: доходы от сегментных сборов. |
Традиционные турагентства: вознаграждения за бронирования, знакомые инструменты. |
Авиакомпании, возможностей которых недостаточно для полноценного внедрения NDC: пытаются выиграть время, не решая существующие проблемы. |
Кому выгодно как можно более быстрое внедрение NDC
Авиакомпании: уменьшение сегментных сборов. |
Онлайн‑агентства с мощными ИТ‑инфраструктурами: расширение набора предлагаемых товаров и услуг, прямые сделки. |
Крупные корпоративные клиенты: повышение качества данных об авиаперевозках, возможность прямых переговоров с авиакомпаниями. |
В результате перед нами — стандарт, появившийся 14 лет назад, который, с одной стороны, даёт реальные преимущества, ведёт к прогрессу, а с другой — наталкивается на серьёзное противостояние, вызванное экономическими факторами. И широкое внедрение стандарта NDC замедляют не его технические характеристики, а то, что он нарушает сложившиеся схемы заработка.
Как со всем этим обстоят дела у индийских авиакомпаний?
Индийский рынок авиаперевозок одновременно движется в двух разных направлениях.
Компания Air India, принадлежащая сейчас Tata Group и работающая на Amadeus Altéa, поддерживает NDC. Преобразование компании под влиянием Tata Group включало в себя инвестиции в технологии дистрибуции. В Air India, в рамках более широкого процесса цифровой трансформации, были созданы API, реализующие возможности NDC. Крупным корпоративным клиентам Air India посредством NDC даются более широкие возможности приобретения дополнительных товаров и услуг.
Но при этом моё бронирование, оформленное компанией Technogise в 2025 году и прошедшее через платформу myBiz, сделано с помощью инструментов командной строки Amadeus. Это так из‑за того, что именно на этих инструментах основана инфраструктура дистрибуции MakeMyTrip. Из‑за того, что бэкенд myBiz подключён к Amadeus. И из‑за того, что бронирование рейсов через NDC, несмотря на то, что оно осуществимо, пока не является стандартной опцией для корпоративных клиентов среднего размера.
Компания IndiGo, использующая Navitaire, относится к NDC иначе. Лоукост‑модель этой компании идеально согласуется с тем, что обещает внедрение NDC в плане прямых продаж билетов. А именно: меньше посредников, более низкая стоимость дистрибуции, больше контроля над продуктом. IndiGo гораздо агрессивнее продвигает идею налаживания прямых взаимоотношения с корпоративными клиентами. В случае с IndiGo внедрение NDC не особенно сильно повлияет на сегментные сборы, так как эта компания, следуя особенностям своей модели развития, уже минимизировала стоимость использования GDS.
Получается, что авиакомпания, которой есть что продавать через NDC, это как раз тот случай, когда существующая инфраструктура дистрибуции очень сильно интегрирована в системы компании. Например, в Air India имеется и множество классов обслуживания, и широкий выбор вариантов питания, и код‑шеринг, и программа лояльности. В результате ей тяжелее перейти на новые технологии. А авиакомпания, продукты которой устроены гораздо проще (IndiGo), способна без особых сложностей и рисков перейти на NDC.
Пример использования NDC
Для разработчика, привыкшего к REST API, NDC, на первый взгляд, выглядит привычно. Вот запрос на поиск вариантов перелёта:
POST /AirShopping HTTP/1.1 Content-Type: application/xml <IATA_AirShoppingRQ> <CoreQuery> <OriginDestinations> <OriginDestination> <Departure> <AirportCode>NAG</AirportCode> <Date>2025-02-08</Date> </Departure> <Arrival> <AirportCode>DEL</AirportCode> </Arrival> </OriginDestination> </OriginDestinations> </CoreQuery> <Travelers> <Traveler> <AnonymousTraveler> <PTC>ADT</PTC> </AnonymousTraveler> </Traveler> </Travelers> </IATA_AirShoppingRQ>
Сравните это с запросом, используемым в командной строке Amadeus:
AN08FEBNAGDEL
Первый запрос выразителен, хорошо структурирован, его можно распарсить любым современным набором инструментов. Второй — это просто 14 символов. Его, правда, быстрее набирать на клавиатуре. А NDC‑запрос обладает более богатыми возможностями, его легче, с точки зрения программиста, интегрировать в систему. Выбор подходящего формата зависит от того, где именно планируется его использовать, от того, будет ли с ним работать агент‑человек, сидящий за клавиатурой, или программная система, автоматически обрабатывающая запросы на поиск вариантов перелёта.
Данные, которые возвращает API NDC в ответ на подобный запрос, соответственно, содержат гораздо более обширный набор информации. Объект, представляющий собой описание предложения авиакомпании, включает в себя не только информацию о рейсах и о классах обслуживания. Тут может иметься и карта мест в салоне самолёта, и предложения дополнительных услуг, и условия применения тарифов. Именно ответы такого формата позволяют OTA предлагать пользователям настоящие сравнения продуктов, а не скучный прайс‑лист, где разные предложения отличаются лишь ценой.
Проблема равнозначного представления сведений о продуктах авиакомпаний
Существует один аргумент в пользу широкого внедрения NDC, который пробивается сквозь коммерческий шум. Это — равнозначное представление сведений о продуктах авиакомпаний.
Из API NDC авиакомпаний часто можно получить сведения о тарифах и предложениях, которые отсутствуют в GDS. И это не случайно: авиакомпании используют NDC для прямых продаж продуктов, иногда — по более выгодным ценам, чем те, что представлены в GDS. Но это создаёт проблему для корпоративных программ деловых поездок. Дело в том, что путешественник, при оформлении бронирования через агентство, используемое его компанией (в которой применяется GDS) может попросту не видеть более дешёвых или более подходящих тарифов для своей поездки.
Возможна и обратная ситуация: существуют тарифы, доступные исключительно в GDS. Некоторые договорные корпоративные тарифы публикуются только в GDS, а в NDC их нет, так как агентства работают именно через GDS.
Сейчас рынок авиаперевозок фрагментирован. Он разделён на три канала дистрибуции:
Канал 3: NDC‑агрегаторы
Достоинства: канал NDC, поддерживающий множество авиакомпаний в одной интеграции.
Недостатки: наличие дополнительного посредника; это решение пока не универсально.
Канал 2: прямой доступ к NDC
Достоинства: полный каталог предложений, нет сборов за пользование GDS, персонализация.
Недостатки: фрагментация по реализациям, выполненным разными авиакомпаниями.
Канал 1: традиционные GDS
Достоинства: универсальный охват авиакомпаний, единый интерфейс, отлаженные рабочие процессы.
Недостатки: отсутствие предложений, доступных только через NDC; сегментные сборы для авиакомпаний.
В случае с программами деловых поездок, вроде той, что применяется в Technogise при бронировании рейсов через myBiz, практическое решение вопроса выбора механизма бронирования выглядит так: использование GDS и принятие того, что некоторые NDC‑предложения при этом могут быть не видны. Компаниям средних размеров, вроде Technogise, попросту нерационально тратить административный ресурс на поддержку прямых NDC‑связей со всеми необходимыми авиакомпаниями. Именно поэтому бронирование моего путешествия было выполнено посредством командной строки Amadeus. Это — рациональное коммерческое решение, а не следствие технического несовершенства систем компании, в которой я работаю.
Какие сведения об устойчивости систем я получил благодаря инциденту с птицей?
В пятой части я рассказал о том, как моё бронирование DHB4AL было автоматически переоформлено после отстранения от полётов борта VT‑AEQ. Автоматическая система переоформления бронирования, работа которой началась в 14:57 UTC, нашла альтернативные рейсы, обновила сведения в моей PNR‑записи и уведомила меня об изменениях через считанные минуты после отмены рейса. Всё это функционирует на базе Amadeus Altéa. Это — та же платформа, которая обрабатывает команды, вводимые в терминале, построенная на базе соглашений о модели данных, принятых в 1960-е годы.
Система сделала своё дело. Она справилась, работая в условиях высокой нагрузки, в жёстких временных рамках. Она правильно спланировала сложное путешествие с несколькими перелётами. Всё это было сделано менее чем за десять минут.
В NDC пока нет подсистемы управления сбоями, сравнимой с той, что имеется в GDS. Стандарты NDC нацелены на продажу товаров и услуг, на управлением предложениями, на создание заказов. И с этими задачами NDC‑системы справляются достойно. Но эти стандарты не полностью охватывают обработку нестандартных ситуаций (IRROP, Irregular Operation, нештатная операция). В Altéa заложены правила, формировавшиеся в течение десятилетий практического использования GDS. Системы, работающие на базе ОС TPF, содержат глубоко проработанные механизмы обработки нештатных ситуаций. Когда что‑то идёт не так, эти механизмы способны справиться лучше, чем свежий стандарт. Нечто подобное, почти наверняка, уже случалось, поэтому в старых системах существуют правила практически на все случаи жизни.
Это — весомый аргумент в пользу сохранения текущего положения дел. И дело не в том, что старые технологии лучше новых в некоем абсолютном смысле. Дело в том, что эти технологии прошли проверку сбоями, случавшимися в течение шестидесяти лет. Для большинства критических ситуаций, которые уже случались, где‑то в экосистеме GDS уже есть правила, помогающие с ними справиться. А стандарт NDC, как бы хорошо он ни был спроектирован, начинает путь накопления подобных знаний с нуля. Разработчикам NDC ещё предстоит столкнуться с огромным количеством редких, но существующих сценариев. Правила, которые должны применяться при возникновении таких сценариев, пока не написаны.
Размышления после конференции ContainerDays
Я выступил на конференции. Потом вернулся домой, в итоге — не так, как планировалось, а через Мумбаи.
На обратном рейсе, где‑то над Персидским заливом, я достал свои заметки, которые делал в ходе работы над этой серией материалов. Архитектура TPF. Модель данных PNR. Команды терминала Amadeus. Столкновение с птицей. Автоматическое переоформление бронирования. Сотрудница компании, которая его откорректировала.
На конференции, где я только что выступал, было множество инженеров, которые создают облачные инфраструктуры, легко создаваемые и уничтожаемые, не хранящие состояния систем. Это системы, которые спроектированы с прицелом на то, чтобы их можно было бы легко заменять, с прицелом на их неизменяемость. Их, если появится что‑то более совершенное, без проблем можно на это поменять.
А инфраструктура, которая перенесла меня на расстояние в 15 000 километров и обратно, совсем на всё это не похожа. Она хранит состояние. Она рассчитана на внесение в неё глубоких изменений. Она не проектировалась в расчёте на то, что её что‑то заменит. Ей 60 лет, и она четыре раза за день изменила сведения о моём бронировании, не забыв о том, кто я такой, или о том, куда я направляюсь.
Облачные инфраструктуры — это инструмент, который подходит для тех задач, на решение которых он рассчитан. А инфраструктура GDS — это тоже инструмент, подходящий для решения определённых задач. Их объединяет именно это — то есть то, что они отлично подходят для решения определённых задач. А это свойство не имеет ничего общего ни с новизной, ни с изяществом архитектуры.
GDS, в итоге, заменят. Несуществующая денежная единица NUC исчезнет. Терминал GDS станет музейным экспонатом. А инструментом, обеспечивающим продажи товаров и услуг в коммерческой авиации, станет NDC или что‑то такое, что ещё не появилось.
Но до тех пор, пока этого не произошло, вы, когда увидите шестисимвольный PNR‑код, будете знать о том, что содержит документ, который с ним связан, о том, как был построен этот документ, и о том, через что ему пришлось пройти, чтобы вернуть вас домой.
Итоги
Если вы собираетесь заменить существующую систему на что‑то другое, то вы обязательно должны знать о том, какие именно функции она выполняет. Инфраструктура GDS — это старая, надёжная, проверенная практикой система, применяемая во всём мире. На достижение тех качеств, которыми она обладает, ушли десятилетия. Стандарт NDC, по определённым направлениям, технически превосходит GDS, но он всё ещё, через четырнадцать лет после появления, не готов к полноценной обработке нештатных ситуаций. Это — повод адекватно оценивать последствия перехода на новую систему, анализируя то, как старая система ведёт себя при сбоях и проверяя способность новой системы обеспечивать тот же функционал.
Экономические факторы оказывают более сильное влияние на внедрение новых технологий, чем технические характеристики этих технологий. Внедрение NDC ограничено коммерческими факторами, которые объясняют сильное тяготение индустрии к тому, чтобы всё оставалось так, как есть. На то, как именно идёт распространение NDC, влияют несколько факторов: сегментный сбор, вознаграждения турагентств, стоимость создания уникальных каналов взаимодействия с различными авиакомпаниями. В ситуациях, когда стандарт, качественный с технической точки зрения, внедряется не очень хорошо, причины происходящего обычно лежат в сфере экономических выгод, сопутствующих применению старых стандартов, а не в технических недостатках новых.
Практическая надёжность систем, проявляющаяся в нештатных ситуациях, нарабатывается со временем, а не закладывается в них в момент создания. Система управления сбоями Altéa надёжно справляется с переоформлением бронирований из‑за того, что эта система миллионы раз решала подобную задачу. При этом каждая неувязка, которая возникала раньше, приводила к появлению соответствующего правила. Архитектура системы может способствовать тому, чтобы в неё можно было бы добавлять новые правила, не нарушая работу старых, но сами правила накапливаются во время работы системы. Любая новая система, которая придёт на замену старой, потратит годы на решение редких, но вероятных проблем, с которыми старая система уже умеет справляться.
Проектируя сложную систему хорошо разберитесь в том, как именно в этой системе принимаются решения. Некоторые из них можно полностью доверить автоматике, некоторые может принимать автоматика, которой помогает человек, а некоторые может принимать только человек. Сотрудница авиакомпании, которая откорректировала моё бронирование, переоформленное автоматически, не выступала в роли человека, который «затыкает дыры» некачественной системы. А именно, сотрудница применила свои знания о расписании и о стыковках рейсов, которыми не обладал алгоритм. Система спокойно дала приоритет решениям, принятым человеком. Выявление границы между решениями, принятие которых можно автоматизировать, и решениями, которые должен принимать человек, знакомый с обстановкой — это задача из сферы проектирования систем, а не из сферы подбора персонала. В авиации имеется понимание того, где именно должна проходить эта граница. Это понимание подкреплено шестьюдесятью годами практики.
Итоги серии статей Iron Core
Когда в декабре 2025 года сотрудник компании Technogise организовал моё авиапутешествие на конференцию ContainerDays, я ещё не знал о том, что потрачу долгие месяцы на чтение документации IATA, на расшифровку строк расчёта тарифов, на извлечение телеметрии ADS‑B из CSV‑файлов, взятых из FlightRadar24.
Всё началось с шестисимвольного кода из письма с подтверждением бронирования. Я потянул за эту нитку и распутал целый клубок интересных фактов и событий:
В 1953 году на борту самолёта состоялся один важный разговор, который привёл, в 1959, к соглашению между IBM и American Airlines, и к тому, что в 1964 году заработала новая система.
Операционная система, которая появилась на десятилетие раньше Unix, до сих пор способна обслуживать по 10 000 транзакций в секунду.
Командный язык, созданный для телетайпов, всё ещё позволяет хорошо обученным сотрудникам решать задачи быстрее, чем обычный графический интерфейс.
Модель данных, которая вобрала в себя 60-летнюю историю анализа нештатных ситуаций, до сих пор не потеряла структурной целостности.
Система возрастом 60 лет отлично справилась с инцидентом, когда Boeing 787–8 Dreamliner столкнулся с птицей в Терминале № 2 аэропорта Хитроу.
Сотрудница Air India, взглянув на то, что нашёл алгоритм переоформления бронирования, смогла предложить более подходящий вариант.
Инфраструктура, которая обеспечивает авиаперелёты — это не какой‑то там раритет. Это — пример того, как выглядит система, созданная в расчёте на решение конкретной задачи. Система, которую поддерживают настоящие профессионалы. Система, которой дали достаточно времени на то, чтобы стать по‑настоящему надёжной.
О, а приходите к нам работать? 🤗 💰
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата‑инженеров и мл‑рисерчеров.
