Когда вы бронируете авиабилет через смартфон в 2026 году, ваш запрос проходит через множество уровней современных технологий: мобильное приложение, веб-сервис, платежный процессор, прежде чем попасть в систему, которая фактически зарезервирует за вами место. Эта система, в большинстве случаев, представляет собой программное обеспечение, корни которого уходят в 1960-е годы, работающее на инфраструктуре, которую туристическая индустрия пытается заменить уже десятилетия, но так и не может полностью это сделать. Sabre, Amadeus и Travelport вместе обрабатывают практически все бронирования авиабилетов на Земле. Вместе они обрабатывают миллиарды транзакций в год для сотен авиакомпаний, тысяч туристических агентств и в режиме реального времени, охватывая миллионы комбинаций мест. Самая старая из них ведет свою историю от мэйнфрейма IBM 1964 года, который сократил время бронирования с 90 минут до нескольких секунд и навсегда изменил коммерческую авиацию.
История того, почему эти системы остаются на своих местах, — это не история организационной инерции или инженерного консерватизма. Это история о том, что происходит, когда программное обеспечение настолько глубоко внедряется в критически важный операционный процесс, что затраты и риски его замены не могут быть оправданы с учетом каких-либо реалистичных сроков, и о том, как отрасль отреагировала, модернизируя основные системы, а не пытаясь их заменить. Для любого, кто работает над масштабной модернизацией устаревших систем, системы бронирования авиабилетов являются наиболее наглядным примером того, что на практике означает «слишком важно, чтобы выйти из строя».
Работайте изнутри. Знайте граф зависимостей.
SMART TS XL Извлекает бизнес-правила, карты зависимостей и неиспользуемый код из программ на COBOL и устаревших программ.
УЗНАТЬ БОЛЬШЕ…Истоки: Почему мэйнфреймы решили проблему авиакомпаний
Первоначальная версия SABRE (Semi-Automated Business Research Environment) не была продуктом, а представляла собой индивидуальное решение для конкретного операционного кризиса. В конце 1950-х годов компания American Airlines росла быстрее, чем её система ручного бронирования могла справиться с нагрузкой. Бронирование места требовало телефонного звонка, ручной проверки физической инвентарной карточки, резервирования, обратного звонка и бумажной записи — процесс, который в среднем занимал 90 минут на одно бронирование и не был масштабируемым.
Когда система SABRE, построенная на двух мэйнфреймах IBM 7090 и подключенная к 1,500 терминалам по всей территории США и Канады, начала полноценно функционировать в 1964 году, она могла обрабатывать 7,500 бронирований в час с практически нулевым уровнем ошибок. Впервые авиакомпания получила возможность поддерживать информацию о наличии мест в режиме реального времени, хранить полные данные о пассажирах и обеспечивать мгновенное бронирование по всей своей сети. Время бронирования сократилось с 90 минут до секунд.
Архитектурное решение, сделавшее это возможным — централизованная обработка транзакций на мэйнфрейме — было выбрано не по философским соображениям. Оно было выбрано потому, что в 1964 году это была единственная доступная архитектура, способная удовлетворить требованиям к задержке, надежности и одновременному доступу, предъявляемым к управлению запасами авиабилетов в режиме реального времени. И она работала настолько хорошо, что стала архитектурным шаблоном, на основе которого были построены все последующие системы бронирования авиабилетов.
Система обработки транзакций IBM (TPF), первоначально разработанная для SABRE, стала операционной средой для всей этой категории. По данным IBM, её до сих пор используют почти все крупнейшие банки, страховые компании, розничные продавцы и авиакомпании. Когда компания Amadeus была основана в 1987 году, она использовала TPF в качестве основы. Когда Galileo (ныне Travelport) запустила свою GDS, она также использовала TPF. В коммерческой авиации сейчас сосуществуют три поколения систем обслуживания пассажиров, и многие из них до сих пор работают на мэйнфреймах TPF, не потому что сама технология никогда не подвергалась сомнению, а потому что пропускная способность транзакций, надежность и отказоустойчивость, которые TPF обеспечивает на мэйнфреймах, оказались действительно трудновоспроизводимыми в эквивалентном масштабе на альтернативных архитектурах.
Что эти системы на самом деле делают в масштабе
Масштабы работы систем бронирования авиабилетов не всегда интуитивно понятны с точки зрения разработки программного обеспечения. Глобальная система дистрибуции обрабатывает не только наличие мест, но и решает сложнейшую комбинаторную задачу управления запасами.
Один трансатлантический рейс имеет сотни тарифных классов. Каждый тарифный класс имеет свои специфические правила: требования к предварительной покупке, минимальный срок пребывания, периоды, на которые билеты не распространяются, сборы за изменение бронирования, разрешенные или запрещенные пересадки, соглашения о код-шеринге с партнерскими авиакомпаниями. Бронирование, включающее две авиакомпании, пересадку и перелет туда и обратно, создает матрицу из потенциально тысяч допустимых комбинаций тарифов, которые необходимо проверить, рассчитать стоимость и сопоставить с данными о наличии мест в режиме реального времени, прежде чем будет получен ответ, как правило, менее чем за секунду.
В пиковые периоды бронирования Sabre и Amadeus совместно обрабатывают десятки тысяч транзакций в секунду. Не в минуту, а в секунду. Каждая транзакция включает в себя поиск мест в режиме реального времени, оценку правил тарифов, создание или изменение записи PNR (Passenger Name Record) и координацию с системами управления вылетом, программами лояльности и дополнительными услугами. Гарантированное время ответа измеряется в миллисекундах, поскольку туристический агент или система бронирования, ожидающие проверки тарифа более нескольких секунд, истекут по таймауту и либо повторят транзакцию, либо отменят ее.
TPF на оборудовании мэйнфреймов обеспечивает такую пропускную способность при таком уровне отказов, в который трудно поверить ИТ-специалистам из других отраслей. Отказоустойчивость мэйнфрейма, резервные процессоры, компоненты с возможностью «горячей» замены, десятилетиями отлаженного кода операционной системы обеспечивают доступность на уровне «пять девяток» в качестве стандартного параметра работы, а не желаемой цели. Воспроизведение этого показателя при эквивалентных затратах на облачной инфраструктуре было главной технической задачей каждой программы модернизации ИТ-инфраструктуры авиакомпаний, предпринимавшейся с 1990-х годов.
Попытки модернизации: к чему привели десятилетние программы?
История модернизации систем бронирования авиабилетов — это история программ, которые изначально ставили перед собой цель заменить ядро системы, а спустя годы пришли к гибридной модели, которая, вместо этого, использовала это ядро в качестве оболочки.
Проект Jetstream компании American Airlines, запущенный в 2000-х годах с явной целью замены мэйнфрейма Sabre PSS, завершился внедрением нового продукта Sabre вместо создания альтернативы. Первоначальное предположение о том, что создание замены собственными силами позволит быстрее получить более совершенную систему, столкнулось с той же реальностью, с которой сталкивается почти каждая крупномасштабная программа замены устаревших систем: существующая система содержала требования, о которых никто не знал до тех пор, пока замена не оказалась неспособной их удовлетворить.
Нам нужно глубже разобраться в стеке и изменить основной механизм, а также отделить правила, чтобы мы могли быстро их изменять. Это заявление руководства ИТ-отдела American Airlines во время программы Jetstream точно описывает проблему. Правила, встроенные в устаревшую систему, логика построения тарифов, реализация соглашений о код-шеринге, расчеты соответствия нормативным требованиям, интеграция с системами управления доходами — все это накапливалось на протяжении десятилетий в результате изменений в бизнесе и не было задокументировано в какой-либо форме, позволяющей извлечь эти данные без запуска существующей системы и наблюдения за ее поведением.
Собственная программа модернизации Sabre, начавшаяся всерьез в 2010-х годах, заняла более десяти лет и обошлась в миллиарды долларов, чтобы перенести большую часть кода с локальной инфраструктуры мэйнфреймов. По состоянию на 2019 год примерно 11 процентов кода Sabre все еще работало в локальных центрах обработки данных, а остальная часть была перенесена. В феврале 2026 года Sabre продлила долгосрочное соглашение с WestJet о предоставлении услуг PSS, продемонстрировав, что даже после десяти лет усилий по модернизации и миллиардов инвестиций, PSS остается коммерческой основой бизнеса.
Компания Amadeus добилась более полного вывода из эксплуатации мэйнфреймов, достигнув важной вехи — отказа от последних мэйнфреймов в пользу облачной инфраструктуры. Однако подход Amadeus, заключающийся в постепенной замене функциональных компонентов при сохранении основной модели данных и архитектуры транзакций, фактически сохранил архитектурные решения, принятые на мэйнфрейме, даже при изменении оборудования. Семантика транзакций, структура PNR, логика управления запасами — все это перешло на современную инфраструктуру, сохранив при этом свои фундаментальные принципы проектирования.
Почему замена сложнее, чем кажется: скрытая сложность
Стандартное объяснение того, почему системы бронирования авиабилетов до сих пор используются на мэйнфреймах, — это стоимость и риск. И то, и другое реально. Но это лишь симптомы более глубокой технической реальности, которую стоит точно понять, поскольку она применима к любой программе модернизации критически важных устаревших систем.
Бизнес-правила существуют только в коде. Логика построения тарифов в глобальной системе распределения отражает десятилетия нормативных требований, двусторонних соглашений с авиакомпаниями, пересмотра стандартов IATA и изменений бизнес-правил, ни одно из которых не задокументировано в какой-либо форме, независимой от кода, который их реализует. Спецификация — это реализация. Замена реализации без спецификации означает исчерпывающее наблюдение за поведением существующей системы, достаточно тщательное, чтобы воссоздать то, что говорила бы спецификация, — процесс, который занимает годы и никогда не бывает полным, поскольку охват наблюдений никогда не может быть достаточно полным, чтобы охватить каждый частный случай.
Семантика транзакций, которую современным архитектурам сложно воспроизвести. TPF обеспечивает синхронную, атомарную обработку транзакций с гарантированной согласованностью по всей базе данных PNR, блокировке места, обновлению записи о пассажире, авторизации платежа и записи подтверждения — все это фиксируется как единый атомарный блок или не фиксируется вовсе. Воспроизведение этого в распределенных микросервисных архитектурах требует тщательной оркестровки, компенсирующих транзакций и распределенного управления блокировками, что является сложным и потенциально более медленным процессом, чем синхронный аналог на мэйнфрейме. Опыт авиационной отрасли показывает, что «в конечном итоге согласованность» — это недопустимое свойство для количества мест, перебронированный рейс — это конкретный, операционно катастрофический сбой, а не временная несогласованность, которую нужно устранить позже.
Поверхность интеграции. Зрелая система управления пассажирскими перевозками авиакомпании подключена к сотням внешних систем: системам управления вылетами, управления доходами, программам лояльности для часто летающих пассажиров, системам аэропортов, сторонним системам GDS, партнерам по код-шерингу, системам нормативной отчетности и многому другому. Каждое соединение имеет специфические интерфейсные контракты, форматы сообщений, требования к синхронизации, механизмы обработки ошибок, которые реализованы в существующей системе и на основе которых построена каждая зависимая система. Замена системы управления пассажирскими перевозками требует либо одновременного сохранения всех существующих интерфейсных контрактов (что ограничивает архитектуру замены), либо координации изменений со всеми зависимыми системами (что расширяет область применения за пределы возможностей одной программы).
Проблема данных в реальном времени. Бронирования авиабилетов — это данные в реальном времени, бронирования, сделанные за несколько месяцев вперед, которые должны быть выполнены в точности так, как было забронировано. Не существует четкой точки перехода, где данные старой системы могли бы остаться нетронутыми. Миграция должна перенести каждый актуальный PNR из старой системы в новую, со всеми связанными правилами, тарифами, ограничениями и дополнительными услугами в неизменном виде. Миграция PNR в глобальном масштабе с гарантией нулевой потери данных и идентичного поведения оказалась одной из самых сложных технических проблем при модернизации предприятий.
Архитектурный подход: модернизация вокруг ядра.
Реальный успех в Amadeus, Sabre и отдельных авиакомпаниях был достигнут не за счет замены, а за счет стратегического преобразования и постепенного извлечения ресурсов.
API-обертка предоставляет доступ к основным функциям бронирования в виде современных REST или SOAP API, позволяя новым приложениям взаимодействовать с устаревшей системой через современный интерфейс, не затрагивая основную логику транзакций. Авиакомпании создали мобильные приложения, веб-системы бронирования и инструменты обслуживания клиентов на основе API-уровней, которые преобразуют современные запросы в вызовы транзакций TPF и возвращают структурированные ответы. Зеленый экран терминала заменяется современным графическим интерфейсом пользователя; базовая обработка транзакций остается неизменной.
Метод Strangler Fig применяется к неосновным функциям. Функции, смежные с основной, такие как управление доходами, управление программами лояльности, отчетность и аналитика, планирование работы персонала, извлекаются по одной и внедряются на современной инфраструктуре. Каждое извлечение уменьшает размер устаревшей системы, не затрагивая ядро транзакций, которое представляет наибольший риск. За более чем десятилетие поэтапного извлечения роль устаревшей системы сужается от всеобъемлющей платформы приложений до узкоспециализированного механизма обработки транзакций.
Облачная инфраструктура с сохранением архитектуры. При выводе из эксплуатации мэйнфрейма Amadeus рабочие нагрузки были перенесены в облачную инфраструктуру с сохранением архитектуры транзакций, изначально разработанной на мэйнфрейме. Изменилось оборудование; программная архитектура, модель данных, семантика транзакций, структура PNR сохранили архитектурные решения, доказавшие свою правильность на протяжении десятилетий.
Новая система управления предложениями и заказами в дополнение к устаревшей системе PNR. Стандарт IATA ONE Order, заменяющий записи на основе PNR современной моделью управления заказами, внедряется авиакомпаниями в качестве дополнительного уровня к существующей системе на основе PNR. Технологии Sabre следующего поколения для управления предложениями и заказами, упомянутые в обновлении соглашения с WestJet в 2026 году, позиционируют это как путь вперед, не замену системы PSS, а добавление современного коммерческого уровня, который в конечном итоге будет обрабатывать все большую долю бронирований, в то время как ядро PNR будет обрабатывать оставшуюся часть.
Что это означает для любой критически важной модернизации устаревших систем?
История с системами бронирования авиабилетов не является уникальной для авиации. Это наиболее наглядный пример закономерности, которая наблюдается в основных банковских системах, управлении страховыми полисами, выставлении счетов в телекоммуникационных компаниях и обработке государственных пособий: программное обеспечение становится авторитетным источником бизнес-правил, служит интеграционным центром для десятков зависимых систем и работает в масштабе и с такими требованиями к надежности, которые делают радикальную замену действительно нецелесообразной.
Эти выводы справедливы для всех отраслей:
Извлечение бизнес-правил из кода до начала любой модернизации является обязательным. Программы на COBOL и TPF, реализующие расчет тарифов, логику соглашений о код-шеринге и правила соответствия нормативным требованиям, являются единственной сохранившейся документацией по этим правилам. Модернизация, которая не извлекает и не проверяет эту логику предварительно, не сможет создать замену, которая будет корректно работать во всех случаях, поскольку она не может знать все случаи без анализа всего кода.
Карта зависимостей определяет последовательность миграции. Ни одна авиакомпания не смогла успешно заменить свою систему управления безопасностью полетов (PSS), начав с наиболее важного и интегрированного компонента. Каждая успешная модернизация начиналась с периферии: систем отчетности, вспомогательных служб, некритических административных функций, и постепенно продвигалась внутрь. Эта последовательность определяется графом зависимостей: компоненты с наименьшим количеством входящих зависимостей безопаснее всего рассматривать в первую очередь.
Эксплуатационная проверка на каждом этапе является обязательной. Подход с двойным запуском, при котором новая система запускается параллельно со старой, сравниваются результаты, проверяется эквивалентность до перенаправления трафика, — это единственный подход, отвечающий требованиям надежности систем, где отказы имеют физические, финансовые и нормативные последствия.
Как SMART TS XL Применимо к анализу устаревших данных, связанных с авиаперевозками.
Авиакомпании, использующие Sabre или Amadeus PSS наряду со своими собственными программами на COBOL, системами расчета тарифов, учета доходов, расчета бонусных баллов и нормативной отчетности, сталкиваются с той же аналитической проблемой, что и любая программа модернизации корпоративных мэйнфреймов: понять, что на самом деле содержит код, прежде чем принимать решение о том, что с ним делать.
SMART TS XLАвтора статический анализ кода Эта процедура извлекает логику бизнес-правил, встроенную в программы COBOL, правила проверки тарифов, расчеты учета доходов, логику определения уровня лояльности, которая отсутствует только в программном коде. Для авиакомпаний, планирующих модернизировать смежные системы, не затрагивая ядро PSS, эта процедура извлечения предоставляет спецификацию, которой должна соответствовать замена.
Сопоставление зависимостей приложений формирует граф зависимостей, определяющий последовательность миграции: какие программы со стороны авиакомпаний зависят от каких потоков данных из PSS, какие программы формирования отчетов зависят от каких пакетных выходных данных COBOL, какие нижестоящие системы необходимо обновлять при изменении любого компонента. Граф зависимостей делает возможной поэтапную и безопасную модернизацию — тот же подход, который Sabre и Amadeus использовали для основных систем, применив его к окружающему их коду со стороны авиакомпаний.
Возможность анализа воздействия отвечает на вопрос, предшествующий каждому решению о модернизации: если эта программа изменится, что еще будет затронуто? Для авиационных систем, где изменение расчета в программе учета доходов может одновременно повлиять на отчетность перед регулирующими органами, расчеты с партнерами и финансовую консолидацию, знание масштаба воздействия до внесения каких-либо изменений является необходимым условием для управления изменениями, соответствующего требованиям надежности авиакомпании.
Анализ модернизации устаревших систем предоставляет полный перечень данных, полученных до модернизации: каждая программа, подлежащая модернизации, ее сложность, зависимости, процент неиспользуемого кода и классификация рисков миграции. Урок любой программы модернизации авиакомпании: начинайте с периферии, двигайтесь внутрь, проверяйте на каждом этапе, необходимо знать, где находятся периферия и как выглядит структура зависимостей. Эти знания получают из структурного анализа самого кода, а не из документации, написанной до того, как код изменился.
Геологические слои критически важного программного обеспечения
Когда вы бронируете авиабилет на смартфоне в 2026 году, вы взаимодействуете с программным обеспечением, имеющим несколько различных геологических уровней. Современный интерфейс на поверхности. Уровень API под ним. Транзакционный движок PSS еще ниже, работающий на инфраструктуре, которая существенно изменилась с 1960-х годов, но сохранила семантику транзакций и модели данных, которые были верны на момент их разработки и оказались слишком надежными, чтобы от них отказываться.
Система бронирования авиабилетов — это не провал модернизации. Это результат шести десятилетий рациональных решений инженеров и руководителей, которые каждый раз, когда предлагалась замена, понимали, что риск ошибки превышает затраты на сохранение работающей системы. Системы, которые существуют так долго, делают это потому, что они заслужили это, транзакция за транзакцией, рейс за рейсом, сезон бронирования за сезоном бронирования.
Практический урок для любой команды по модернизации заключается не в том, что старые системы никогда не следует заменять. Он состоит в том, что решение о замене должно приниматься на основе полного понимания того, что они содержат, что от них зависит и каков полный масштаб изменений, а не на основе оптимистичных оценок, сделанных до оценки сложности. Авиационная отрасль усвоила это на собственном горьком опыте. Инструменты анализа, которые позволяют получить полное структурное знание до написания первой строки нового кода, позволяют усвоить это на менее затратном уровне.
