Публикуем перевод пятой части из серии статей (вот первая, вторая, третья и четвёртая), посвящённой информационным технологиям в авиаперевозках. Сегодня поговорим о задержанном стыковочном рейсе, об отстранённом от полётов Boeing 787-8, и о том, что сделала 60-летняя система после того, как в аэропорту Хитроу всё пошло наперекосяк.
Вылет рейса BA1361 из Манчестера задерживался.
Я наблюдал за тем, как время на табло вылета пересекло отметку в 9:40, но никаких новостей там не было. Тогда я уже открыл программу FlightRadar24. Воздушное судно с позывным SHT3R, первые сведения о GPS-координатах которого были зарегистрированы в 10:28 UTC, всё ещё не покидало Терминал №2 в аэропорту Манчестера. Самолёт начал движение в 10:35. В 10:49, с отставанием от расписания на шестьдесят девять минут, было убрано шасси.
Я, во время снижения самолёта, поразмышлял о том, сколько у меня есть времени. Посадка должна была состояться примерно в 11:40. Переход между терминалами №5 и №2 в Хитроу занимает минимум 35 минут. Сюда входит время, необходимое на поездку на межтерминальном шаттле, на проверку безопасности, на пеший переход. Отправка рейса AI112 была запланирована на 13:00. В лучшем случае у меня в запасе было около 45 минут.
Этого не хватило бы, если бы самолёт, выполнявший предыдущий рейс, уже прибыл бы с задержкой.
А этот самолёт, и правда, прибыл с задержкой.
Прибывающий самолёт: VT-AEQ, AI111
AI112 (LHR→DEL) — это обратный рейс. Самолёт, который его обслуживает, прибывает из Дели, номер его рейса обозначен как AI111. В авиации на прямых и обратных рейсах, соответствующих прямым и обратным участкам маршрута, используется один и тот же бортовой номер самолёта. Речь идёт об одном и том же самолёте, который, после прибытия в аэропорт назначения, готовят к новому полёту и отправляют в следующий рейс.
16 февраля 2026 это был самолёт VT-AEQ: Boeing 787-8 Dreamliner компании Air India. Он покинул Дели в 02:09 UTC, выполняя рейс AI111.
Я это знаю, поскольку данные ADS-B, имеющиеся на FlightRadar24, отражают сведения обо всём полёте. Вот материалы из CSV-файла:
Callsign: AIC111 Departure: 2026-02-16T02:09:50Z (Delhi: VIDP) Arrival: 2026-02-16T12:41:33Z (London Heathrow: EGLL) At gate: 2026-02-16T12:52:33Z Route: 02:09Z Delhi (28.56°N, 77.08°E) takeoff 03:07Z Gujarat coast (23.73°N, 72.17°E) FL300, 442 kts 04:31Z Oman coast (23.30°N, 61.33°E) FL300, 442 kts 05:50Z Persian Gulf (26.61°N, 51.23°E) FL340, 454 kts 06:54Z Iraq (32.51°N, 45.01°E) FL340, 468 kts 09:24Z Black Sea (42.66°N, 28.28°E) FL360, 466 kts 10:19Z Hungary (46.44°N, 19.94°E) FL360, 450 kts 11:52Z Netherlands coast (51.67°N, 4.52°E) FL360, 430 kts 12:24Z Descending over Essex (51.55°N, 0.23°E) 11,900 ft 12:41Z Wheels down, Heathrow 12:52Z At gate, Terminal 2
Между взлётом в Дели и посадкой в Лондоне прошло 10 часов и 32 минуты. Прибытие рейса AI111 в аэропорт LHR запланировано на 12:15. Борт VT-AEQ приземлился с 26-минутным опозданием.
Окно возможностей сужается: поминутная хроника событий
Вот что происходило параллельно с приземлением борта VT-AEQ в аэропорту Хитроу:
11:40Z BA1361 выпустил шасси, Терминал №5 в Хитроу Телеметрия SHT3R это подтверждает: 53.47°N, -0.49°E, LHR взлётно-посадочная полоса 27L 11:49Z BA1361 у гейта, Терминал №5 54-минутное опоздание относительно запланированного прибытия в 10:55 Мне нужно добраться до Терминала №2. Варианты: A) Подземный поезд Heathrow Express T5→T3→T2 (~20 минут) B) Межтерминальный автобус (~25 минут) Запланированное время отправлений рейса AI112: 13:00Z Имеющийся запас времени: 71 минута Межтерминальный трансфер: минимум ~35 минут Резерв: 36 минут, если AI112 будет следовать расписанию. ~12:30Z Я прохожу проверку в Терминале №2. Табло вылета: AI112 ЗАДЕРЖАН. Облегчение. Относительное облегчение. Проверяю FlightRadar24. Рейс AIC111 находится на заключительном этапе захода на посадку. 12:41Z Наблюдаю, как, в соответствии с телеметрией, самолёт перестал снижаться. 12:52Z Самолёт у гейта. Новые данные на табло вылета: AI112 → 14:15
Время вылета 14:15 — это не некое произвольное значение. На наземное обслуживание широкофюзеляжного Boeing 787 обычно нужно 60-75 минут. Сюда входит высадка пассажиров, чистка салона, посадка новых пассажиров, заправка, доставка питания, погрузка багажа, буксировка. Борт VT-AEQ оказался у гейта в 12:52. Если прибавить сюда 75 минут — получится 14:07. Время отправления 14:15 представляет собой реалистичный наиболее ранний срок отправления, вычисленный системой.
У меня было ещё два часа. Я нашёл себе место в Терминале №2 и заказал кофе.
Столкновение с птицей: что случилось с самолётом?
Где-то между 12:52 и 14:57 UTC самолёт VT-AEQ столкнулся с птицей.
У меня нет отчёта об инженерном обследовании самолёта. Я знаю только то, что сообщил мне сотрудник наземной службы Air India у Терминала №2, а так же — то, на что указывает последовавшее за инцидентом переоформление билетов. А именно — самолёт был отстранён от полётов. Между задержкой рейса и отстранением борта от полётов имеется огромная разница.
Если рейс задержан — это означает, что самолёт, в итоге, вылетит из аэропорта. Продолжается его наземное обслуживание, пассажиры ждут, на табло появляются новые сведения о времени его отправления.
А вот отстранение от полётов значит снятие борта с обслуживаемых им рейсов до завершения проверки или технического обслуживания. Все рейсы, которые он обслуживает, отменяются. Забота о пассажирах с этих рейсов ложится на систему управления сбоями авиакомпании и на каждого сотрудника, находящегося в этот момент за стойкой.
Борт VT-AEQ был отстранён от полётов. Рейс AI112 отменили.
Изменения в PNR, происходящие в реальном времени: DHB4AL в сложной ситуации
В 4:57 UTC система управления сбоями авиакомпании Air India выдала уведомление об изменении данных:
Тема: Изменение рейсов для DHB4AL Хотим проинформировать вас об обновлении данных вашего бронирования с кодом DHB4AL. Обратите внимание на то, что ваше бронирование на первоначальный рейс было отменено/изменено. ПЕРВОНАЧАЛЬНЫЕ РЕЙСЫ: AI 112 LHR → DEL 14:15 → 05:10+1 AI 415 DEL → NAG 06:20+1 → 08:05+1 ОБНОВЛЁННЫЕ РЕЙСЫ: AI 162 LHR → [DEL] 08:45+1 → 23:45+2 AI 425 [DEL] → NAG 06:20+2 → 08:05+2
Это уведомление — результат работы автоматической системы переоформления бронирования. Это — первая попытка системы найти альтернативные рейсы. В пределах нескольких минут после принятия решения об отмене рейса модуль управления сбоями Altéa сделал следующее:
Идентифицировал всех пассажиров с рейса AI112, которых ожидают дальнейшие стыковочные рейсы.
Запросил данные об имеющихся местах на альтернативных маршрутах.
Предварительно назначил пассажирам новые рейсы.
Обновил сегменты PNR.
Запустил процесс отправки уведомлений.
Эта скорость — результат масштабной автоматизации операций. Результат работы системы выглядит приемлемым. Но сотрудники наземной службы Air India в Терминале 2 понимали, что эти результаты далеки от оптимальных.
PNR как конечный автомат: четыре смены состояния за день
Моя PNR-запись с кодом DHB4AL побывала 16 февраля в четырёх различных состояниях. Каждый переход представлял собой набор изменений статусов сегментов в Amadeus Altéa:
СОСТОЯНИЕ 1: Исходное бронирование (5 декабря 2025 года): BA1361 MAN→LHR HK1 09:40 ← Полётный сегмент British Airways AI112 LHR→DEL HK1 13:00 ← подтверждено, исходное время AI415 DEL→NAG HK1 06:20+1 ← подтверждено СОСТОЯНИЕ 2: Изменение расписания без выдачи уведомления (январь–февраль): BA1361 MAN→LHR HK1 09:40 ← без изменений AI112 LHR→DEL HK1 14:15 ← время отправления обновлено, без уведомления AI415 DEL→NAG HK1 06:20+1 ← без изменений СОСТОЯНИЕ 3: Автоматическое переоформление бронирования после отмены рейса: BA1361 MAN→LHR HK1 09:40 ← выполнен ✓ AI112 LHR→DEL XX1 14:15 ← аннулирован: статус изменён на XX AI415 DEL→NAG XX1 06:20+1 ← каскадное аннулирование AI162 LHR→DEL HK1 08:45+1 ← добавлен новый сегмент AI425 DEL→NAG HK1 06:20+2 ← добавлен новый сегмент СОСТОЯНИЕ 4: Ручное изменение данных, выполненное агентом (Стойка у Терминала №2): BA1361 MAN→LHR HK1 09:40 ← выполнен✓ AI112 LHR→DEL XX1 14:15 ← аннулирован (не изменилось в сравнении с состоянием 3) AI415 DEL→NAG XX1 06:20+1 ← аннулирован (не изменилось в сравнении с состоянием 3) AI130 LHR→BOM HK1 21:00 ← агент обнаружил более подходящий вариант AI2583 BOM→NAG HK1 19:55+1 ← маршрут с пересадкой в Мумбаи
В состояниях 3 и 4 PNR-код DHB4AL не поменялся. Номер билета, 098-5801178359, тоже не изменился. А изменился сам тот документ, ссылкой на который является PNR-код. Шесть символов какими были, такими и остались. А вот структура данных, с которой они связаны, была полностью перестроена.
Именно так выглядит то, что называют «концепцией согласованности в конечном счёте». И происходит это всё в системе, которая появилась за сорок лет до формулирования этой концепции.
Проблема SSR: что упустила автоматика?
Когда одни полётные сегменты PNR отменяют, а другие добавляют, запросы на специальное обслуживание (SSR, Special Service Request) оказываются ни к чему не привязанными. Так, мой запрос HNML (индуистское питание) был подтверждён на рейсе AI112. Но этого рейса в моём бронировании больше нет. Новые сегменты не наследуют SSR автоматически от старых сегментов.
В процессе автоматического переоформления бронирования (состояние 3) система управления сбоями может привязать существующие SSR к новым сегментам, а может этого и не сделать. Это зависит от конфигурации Altéa и от того, был ли сбой помечен как непреднамеренный. На практике после непреднамеренных переоформлений бронирований обработка SSR выполняется в разных авиакомпаниях по-разному. Поэтому службы поддержки клиентов авиакомпаний обычно рекомендуют повторно подтверждать запросы на питание после непреднамеренных переоформлений бронирований.
Сотруднику, который вручную переоформлял моё бронирование (состояние 4), пришлось сделать следующее:
Отменить сегменты, автоматически созданные в состоянии 3.
Продать новые сегменты по маршруту LHR→BOM→NAG.
Повторно добавить к новым сегментам сведения о SSR.
Снова выпустить посадочные талоны.
Всё это, с точки зрения пассажира, находящегося у стойки, заняло около 10 минут. А вот с точки зрения системы эти действия выражаются в 15-20 командах терминала, выполненных в интерфейсе агента Altéa. Каждая из этих команд меняет конкретный элемент конкретного PNR.
Человек в контуре управления системы
Автоматическая система переоформления бронирований сделала то, на что она была рассчитана. А именно — она нашла свободные места, выдала их пассажиру, обновила данные в PNR и уведомила пассажира. Всё это было сделано в течение нескольких минут после отмены рейса.
Сотрудница Air India в Терминале №2 взглянула на рейсы AI162 и AI425 и нашла более удобный маршрут через Мумбаи, обеспечивающий мне более подходящее время пересадки на пути домой. Она знала расписание, знала о том, на какие полёты имеются места в моём классе бронирования, знала о том, какими рейсами можно вылететь из Мумбаи в Нагпур. При этом знала она это всё лучше, чем знал алгоритм, так как она уже много раз принимала подобные решения.
Нельзя говорить о том, что автоматическая система не справилась со своей задачей, выдав неоптимальный результат. В масштабах индустрии авиаперевозок, когда одновременно могут быть отменены сотни рейсов, автоматическая система справляется с переоформлением бронирований тысяч пассажиров. И делает это она за считанные секунды. Люди на такое не способны. Алгоритм оптимизирован в расчёте на скорость работы и на использование имеющихся свободных мест в условиях жёстких временных рамок. Его не создавали в расчёте на знание особенностей расписания, которое приходит с практикой.
Во сколько всё это обошлось авиакомпании?
Изменения в бронировании DHB4AL 16 февраля были вызваны непреднамеренным изменением маршрута, ответственность за последствия которого лежала на авиакомпании. Авиационное законодательство Соединённого Королевства (Регламент UK261, основанный на EU261) даёт мне следующие права:
Бесплатное переоформление билетов на следующий доступный рейс до моего пункта назначения.
Питание и напитки во время ожидания (компания Air India предоставила ваучеры).
Размещение в отеле, если время ожидания захватывает ночь (меня это не коснулось, так как мой новый подходящий полёт был в тот же день, в 21:00).
Выплата компенсации в том случае, если задержка в пункте назначения превысила 3 часа (в моём случае так и было, задержка превысила этот порог на несколько часов).
Размер компенсации в соответствии с Регламентом UK261 для маршрута протяжённостью свыше 3500 километров при задержке прибытия в конечный пункт, превышающей 4 часа, составляет £520. В системах Air India фиксируются сведения о причине проблемы, туда вносятся сведения о переоформлении бронирования, о задержке в пункте назначения. Всё это передаётся в систему обработки компенсаций. Эта система и сама по себе представляет целую предметную область. Она определяет ответственность сторон, выполняется расчёт размеров компенсации, обрабатывает претензии. И всё это — в масштабах, соответствующих тысячам пострадавших пассажиров, с рейсами которых возникли какие-то проблемы.
Тут я не буду вдаваться в подробности об этой системе. Выплата компенсаций, как мне сказали, дело долгое.
Итоги
Проектируйте конечные автоматы в явном виде до начала моделирования основного сценария их использования. PNR с кодом DHB4AL прошёл через четыре состояния за один день. Система смогла обработать каждый из этих переходов благодаря тому, что PNR — это явный конечный автомат. Статусы сегментов (HK, XX, TK) — это объекты первого класса, они не выводятся из комбинаций булевых флагов. Когда сегмент аннулируется, система делает запись о том, что он аннулирован. Когда в PNR добавляется новый сегмент — он содержит в себе определённый статус. Такая ясность и однозначность состояний применяется ко всей структуре путешествия. Но при этом в системе может наблюдаться рассогласование вспомогательных данных, вроде моего запроса на особое питание. Придерживайтесь тех же принципов, создавая собственные модели интересующих вас предметных областей. А именно — по возможности применяйте явные состояния и явные переходы между ними. Используйте такие модели, в которых недопустимые комбинации состояний просто невозможно описать.
Автоматическое переоформление бронирований — это подход, хорошо показывающий себя в крупных масштабах. А вмешательство человека — это правильный шаг, нацеленный на учёт индивидуальных потребностей пассажиров. Система управления сбоями нашла свободные места на подходящие рейсы, не дала пропасть бронированию DHB4AL. А сотрудник авиакомпании нашёл более удачный вариант, на который не обратила внимания автоматика. И это правильно — применять архитектуру, которая позволяет и то, и другое. А именно — автоматически решать стандартные вопросы и вручную, под контролем защитных механизмов, вносить в систему коррективы, учитывающие особенные ситуации. Это — не компромисс между двумя неудачными подходами, каждый из которых плохо справляется с решением основной задачи.
Каскадные зависимости должны быть частью предметной области, а не частью прикладного кода. Когда отменили рейс AI112 — рейс AI415 тоже был автоматически аннулирован. Пассажир, который не может добраться до Дели, не сможет сесть и на рейс из Дели в Нагпур. Система понимает эту зависимость и, без необходимости явного вмешательства человека, аннулирует полётные сегменты, зависимые от отменённого рейса. Это понимание заложено в модель данных, выраженную в виде зависимости между связанными сегментами PNR. Код приложения, реализующий каскадное аннулирование зависимостей — это конструкция, которая может легко сломаться. А вот модель предметной области, в рамках которой существуют зависимости, выраженные явным образом, это уже нечто гораздо более прочное и стабильное.
О, а приходите к нам работать? 🤗 💰
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.
