[Перевод] Кто потерял моего ребёнка? Попытка реверс-инжиниринга десятилетнего бага в системе бронирования авиарейсов

Кто потерял моего ребёнка? Попытка реверс-инжиниринга десятилетнего бага в системе бронирования авиарейсов

Простой

12 мин

460

Обзор

Перевод

Стресс за стрессом

Мы поняли, что планы пошли наперекосяк, когда ни я, ни мой партнёр не смогли пройти онлайн-регистрацию на рейс. За прошедший десяток лет мы каждый год проделывали этот путь: из Сан-Франциско через Франкфурт в Хельсинки и обратно. Но это будет наш первый перелёт с ребёнком — мы предпримем смелое путешествие на 18 с лишним часов с нашей дочерью у меня на коленях.

Мы заранее приехали в аэропорт и поспешили к стойке регистрации, чтобы поговорить с представителем авиакомпании United. Когда агент открыла наше бронирование, её радостная уверенность сменилась растерянностью. Возникла загадочная проблема: хотя мы с партнёром сделали всё правильно при покупке, наша дочь билета не получила. Агент вызвала своего начальника, который уверил нас, что может вручную выпустить билет, чтобы мы получили посадочный талон на дочь. Минута тянулась за минутой, начальник вводил в консоль команды с сосредоточенностью разработчика ПО. Наконец, как нам и было обещано, наши посадочные талоны распечатали. Я решила, что это обязательная часть процесса: полёт с младенцем через Атлантику — не для слабых духом, особенно с пересадкой и долгой поездкой на машине. Мы подготовили дочери утреннюю бутылочку и морально приготовились к бессонному перелёту с несколькими сменами подгузников в крошечной трясущейся туалетной кабине.

На обратном пути из Хельсинки первый сегмент нашего путешествия в рамках код-шерингового соглашения с United выполняла Lufthansa. Мы снова не смогли пройти регистрацию онлайн и снова приехали сильно заранее, чтобы обратиться к агенту. Я ожидала сообщения о потерянном билете и медленного, но верного решения проблемы вручную. Однако представитель Lufthansa нас огорошил: у нашего ребёнка не просто не было билета — в бронировании вообще отсутствовала запись о ней. Хуже того: они никак не могли исправить последний (межатлантический) сегмент, потому что внести необходимые изменения могла только United. Мы задержали очередь на час с лишним, пока агент пытался связаться с представителем United по телефону. Наше отчаяние нарастало, но мы как-то убедили её позволить нам сесть на первый рейс до Франкфурта, где бы можно было поговорить с агентом United и разобраться с последним проблемным сегментом.

После ещё одного напряжённого «сеанса программирования» на стойке United во Франкфурте мы добрались до дома. Я задалась вопросом, был ли это единичный глюк только нашего бронирования? Он странным образом походил на проблему, с которой столкнулась моя невестка прошлым летом, летя домой из Германии с её двумя детьми. В аэропорту рядом с домом её родителей представитель Lufthansa тоже сообщил ей, что записи о её ребёнке отсутствуют. Но ей повезло меньше — Lufthansa отказалась пускать её на борт и заставила купить билеты заново. Когда она вернулась в аэропорт, та же проблема возникла снова, но на сей раз она настояла и села в самолёт.

Десятилетний баг?

Моя семья оказалась в хорошей компании: поискав в Интернете, я нашла больше десятка постов о том, что United некорректно резервировала билеты летящих на одном месте с родителями детей, и такие ситуации возникали больше десятка лет [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]. Вот лишь некоторые из цитат:

они не смогли распечатать наши билеты Lufthansa на ребёнка, потому что ребёнок как будто отсутствовал в бронировании Lufthansa — ааааа! (United Infant Ticket Problems, 2013) [1]

…но сообщили, что мы не можем сесть на самолёт в аэропорту Пиарко (POS), потому они не могут найти в своей системе бронирования моего ребёнка (Air Passenger Rights (Canada), 2019) [4]

… когда я подошла на регистрацию Lufthansa в FRA, мне сказали, что у ребёнка нет билета! (Paid for Infant in lap but no ticket at check in, 2023) [6]

Возвращаясь обратно, я снова не смогла пройти регистрацию с ребёнком. Поехала в аэропорт, где мне сказали, что у ребёнка нет билета. (Forced to pay for infant, 2024) [9]

Невероятно: эта агент сказала, что наш ребёнок не оформлен на рейс. Я ответила, что у меня есть чек на $85, которые я заплатила United Airlines за билет на перевозку ребёнка на руках. (Help! Why did United Airlines charge me twice for my lap baby?, 2025) [10]

Проблема встречается слишком часто и стабильно, чтобы её можно было бы списать на единовременную ошибку. И несмотря на нервотрёпку с Lufthansa, улики в основном указывают на United.

Это очень походило на программный баг или на класс связанных багов. Здесь присутствуют классические компоненты, повышающие вероятность сбоев ПО: относительно редкие входные данные (ребёнок на руках на международном рейсе), координация между распределёнными системами (из-за стыковки авиалиний/код-шеринга) и сложная спецификация (правила оформления билетов на детей, зависящие и от авиакомпании и от места назначения).

Мне стало любопытно. В чём же может заключаться проблема? Кроме того, если я разберусь, что происходит технически, то это избавит меня (и других) от кучи стресса в будущих перелётах.

Бронирование и билеты

Я начала с того, что озадачило меня при первом общении с представителем United: как наша дочь могла быть в бронировании, но не иметь билета? Разве при бронировании мест на рейс мы не покупаем билеты?

Оказалось, что на самом деле процесс бронирования состоит из двух отдельных этапов, создающих две отдельные записи:

• Бронирование маршрута — именно его обычно можно увидеть в электронном письме с подтверждением. Каждому бронированию присваивается код подтверждения, например, MZXTIF. В нём содержится информация о пассажирах, точных рейсах, которыми они полетят, а также дополнительные сведения о багаже, выборе мест и многом другом. Одно бронирование может включать рейсы нескольких авиакомпаний. Например, рейс United из Сан-Франциско во Франкфурт, а затем рейс Lufthansa из Франкфурта в Хельсинки.

• Авиабилет для каждого пассажира на весь маршрут. После того, как United принимает бронирование, авиакомпания должна оформить билет по этому маршруту, чтобы окончательно подтвердить поездку. Именно поэтому в некоторых письмах с подтверждением говорится: «Мы обрабатываем ваш запрос и скоро выпустим билет». Билет крайне важен: именно он позволяет зарегистрироваться на рейс и пройти на посадку. Оформление билета по бронированию — непростой процесс, который включает проверку маршрута на соответствие применимым тарифным правилам (для внутренних или международных рейсов), а также расчёт стоимости билета, налогов и сборов. Хотя билеты обычно оформляются быстро и без проблем, в некоторых случаях этот процесс может занять несколько дней или даже (изредка?) завершиться полной неудачей.

Обладая этим знанием, я могу точнее разбить на категории проблемы с детьми, летящими на руках у родителей:

• Отсутствующий билет: вы успешно выполнили бронирование United для себя и ребёнка, но билет на него не был создан. Без билета ребёнка не пустят на рейс.

• Отсутствие в бронировании: процесс бронирования снова как будто был выполнен, но когда вы регистрируетесь в авиакомпании-партнёре, например, Lufthansa, в её копии бронирования нет записи о ребёнке.

И бронирование, и получение билета технически и операционно сложны. Допустим, вы бронируете маршрут с участием нескольких авиакомпаний. United должна найти и зарезервировать места в системе бронирования Lufthansa, а затем оформить билеты на весь маршрут. При перелёте с участием нескольких авиакомпаний по интерлайн-соглашению или код-шерингу бронирование необходимо скопировать из системы авиакомпании, оформляющей билет (United), в системы авиакомпаний, выполняющих рейсы (например, Lufthansa), и поддерживать синхронизацию данных между ними. Перед регистрацией на рейс авиакомпания, оформившая билет, должна также передать часть прав на управление билетом авиакомпании-оператору, чтобы та могла допустить пассажиров на борт.

Не упрощает ситуацию и то, что системы Passenger Service Systems (PSS) многих компаний до сих пор работают на ПО мейнфреймов IBM. А усложняет ситуацию то, что современные стандарты обмена данными уходят корнями в форматы телетайпа 1960-х из самого начала истории массовых авиаперевозок.

Курица, паста или младенец?

Начав исследовать способы моделирования и передачи между авиакомпаниями бронирований, я обратила внимание на некоторые проблемы. Основной тип данных при бронировании — это запись passenger name record (PNR), содержащая маршрут группы путешествующих вместе пассажиров. PNR содержит имя каждого пассажира плюс информацию обо всех сегментах перелётов. Запись каждого пассажира, в свою очередь, может содержать special service request (SSR) для одного или нескольких сегментов маршрута. Согласно Википедии, SSR обычно включают в себя «требования к питанию, услуги по предоставлению кресла-каталки и другие подобные запросы». Стандарт AIRIMP IATA определяет структуру PNR при передаче между системами сообщений о бронировании.

Так как же моделируются младенцы без отдельного места? Можно наивно ожидать, что у них всегда есть собственная запись о пассажире наряду со взрослыми, возможно, с особой аннотацией, например, «младенец».

Однако согласно стандартам обмена данными IATA, ребёнок без места на самом деле считается special service request. Дети, летающие на руках у родителей, на каждом сегменте перелёта закодированы как запись SSR взрослого пассажира, с которым они будут сидеть. То есть в сообщениях между системами тип данных SSR может указывать потребность в веганском питании (VGML), предупреждать о перевозке массивного спортивного оборудования (SPEQ) или… представлять основную запись о маленьком человечке, находящемся в бронировании (INFT)¹.

1TIBSHIRANI/JULIE MS
SSR VGML UA NN1 SFOFRA 0058Y19JUL
SSR INFT UA NN1 SFOFRA 0058Y19JUL.WAGER/SOFIA 01JUL24

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

Легко представить, что SSR может теряться при копировании бронирования между системами двух авиакомпаний: например, принимающая система не поддерживает конкретный код запроса или возникла проблема парсинга и валидации содержимого, из-за чего SSR отбрасывается. Если я выполняю бронирование через United, то почти уверена, что придётся напоминать Lufthansa, что предпочитаю азиатскую вегетарианскую еду (AVML, моя любимая!)

Риск представляет и повторное бронирование: если взрослый повторно забронировал новый сегмент перелёта, то в него должны быть перенесены все связанные с ним SSR INFT, или же ключевая запись о ребёнке может быть утеряна. Плюс система должна понимать, что ребёнку нужно повторно выдать билет вместе со взрослым.

Пол — понятие растяжимое

Примерно в 2010 году Администрация транспортной безопасности США (US Transportation Security Administration, TSA) начала требовать, чтобы в бронировании указывалась дополнительная информация о каждом пассажире для проверки по списку особого контроля; эта программа называется Secure Flight. Для кодирования этих данных Secure Flight авиакомпании задействовали уже используемый SSR DOCS, который применяется для передачи информации о документах, например, номеров паспортов. Каждый пассажир в PNR каждого рейса, входящего в воздушное пространство США, должен иметь запись SSR DOCS, где указывается его полное имя, дата рождения и пол.

Данные Secure Flight требуются и детям, летящим на руках у взрослых. Как моделировать данные их документов, учитывая, что дети моделируются как SSR взрослого пассажира? Если просто добавить ещё одну запись SSR DOCS к соответствующему взрослому, то будет непонятно, относится ли эта информация к взрослому или к ребёнку. Поэтому в стандарте AIRIMP IATA определены два новых пола: младенец женского (FI) и мужского (MI) пола. Если данные Secure Flight содержат один из этих «младенческих полов», то эта информация ассоциируется с ребёнком.

1TIBSHIRANI/JULIE MS
SSR VGML UA NN1 SFOFRA 0058Y19JUL
SSR INFT UA NN1 SFOFRA 0058Y19JUL.WAGER/SOFIA 01JUL24
SSR DOCS UA HK1/////01DEC91/F//TIBSHIRANI/JULIE
SSR DOCS UA HK1/////01JUL24/FI//WAGER/SOFIA

Это создаёт необычную ситуацию: у одного взрослого пассажира может быть две записи SSR DOCS, смысл которых определяется полом. Если бы мы встретили такое поведение при ревью-кода, то подумали бы «хм, возможно, не стоит использовать этот enum не по назначению», поэтому поразительно видеть такое в международном стандарте.

Ещё больше усложняет ситуацию то, что в стандарте определён нераскрываемый пол U, для которого по крайней мере в некоторых системах нет «младенческого» эквивалента. Остаётся надеяться, что никто не попробует ввести U одновременно для взрослого и для летящего у него на руках ребёнка!

Рабочая гипотеза

Когда Lufthansa отказалась сажать мою невестку на рейс, агент авиакомпании сказал ей нечто загадочное наподобие «у вашего ребёнка отсутствует дата рождения». Читая онлайн о других случаях, я также заметила упоминания «данных secure flight»:

Когда я позвонила им, мне сказали, что United Airlines никогда не помещает данные secure flight в информацию билета ребёнка… другой представитель сообщил, что они постоянно сталкиваются с этой проблемой в билетах детей, выпущенных United. (United Infant Ticket Problems, 2013) [1]

сколько бы я ни добавляла младенца через телефон, приложение постоянно удаляет информацию Secure flight (Add Lap Infant After Booking, 2020) [5]

Вполне вероятно, что ПО United не может правильно отправлять данные DOCS детей в другие системы. Возможно, в данных DOCS отсутствуют ключевые компоненты или они отформатированы неожиданным образом, из-за чего принимающая система отбраковывает их. Если это так, то это объяснило бы оба класса проблем:

• Отсутствующий билет: при получении билета может возникать сбой из-за отсутствия данных Secure Flight. Согласно как минимум одному источнику, «Оформление билета блокируется, если в SSR DOCS отсутствуют SFPD».

• Отсутствие в бронировании: если система Lufthansa ожидает, что в каждой записи SSR INFT будет присутствовать соответствующая запись SSR DOCS, то любая проблема в этих данных может вызвать отбрасывание или повреждение данных SSR INFT, из-за чего ребёнок как будто пропадает из бронирования. А если он не получил билет, то не будет никакой надёжной записи, с которой можно свериться.

Хоть это всего лишь гипотеза, я вполне довольна результатом своего расследования. Отраслевой стандарт создаёт определённые риски при реализации, однако программное обеспечение United в этой ситуации почему-то оказывается не на высоте.

United — не единственный перевозчик, у которого возникают проблемы с детьми, перевозимыми на руках: пассажиры American Airlines тоже многократно жаловались, что компания не смогла выдать им билеты [12, 13, 14, 15]².

сотрудник… подтвердил, что такое постоянно случается в AA с бронированием для детей (Friendly Warning for AA Travelers Flying International with Infant, 2023) [14]

Любопытно, что American Airlines вообще не требует билетов на младенцев на всех рейсах внутри страны. Для этих рейсов SSR INFT необязателен, но данные Secure Flight должны быть прикреплены к одному из взрослых при помощи SSR DOCS. Легко понять, каким образом может возникнуть ошибка в системе бронирования!

В следующий раз

В свете полученных знаний во время следующего полёта на United с ребёнком я планирую предпринять следующие действия:

1. Позвонить в United, чтобы убедиться, что у ребёнка есть билеты на весь маршрут. Проверить, что её полное имя, дата рождения и пол отображаются в бронировании (это косвенно даст понять, что данные Secure Flight корректны), и что её бронирование и билет надлежащим образом «привязаны» к моим. Записать или распечатать номера билетов всех, чтобы при необходимости показать в аэропорте.

2. Приезжать в аэропорт раньше обычного при перелёте как туда, так и обратно.

3. Избегать рейсов, совершаемых авиакомпаниями-партнёрами, отдавая предпочтение только самолётам United. Если мы вынуждены будем лететь на Lufthansa, то позвонить им заранее, чтобы убедиться, что ребёнок есть в их копии бронирования и что у них есть номер её билета.

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

Победа без победителя

Я рада, что теперь у меня есть уверенность в возможности решения проблем с билетами. И я получила большое удовольствие от попыток «реверс-инжиниринга» дефекта ПО исключительно по публично доступным материалам.

Но кое-что по-прежнему не даёт мне покоя: нерешённый вопрос о первопричине всего этого. Программный баг годами нарушал планы множества семей, так почему же его до сих пор не устранили? Устраняют ли его сейчас? Как могут некоторые баги, несмотря на свою вредность, продолжать жить в системах долгие годы?

По этой теме сказано уже многое. Многие авиакомпании работают с легаси-ПО, поэтому внесение изменений в него — рискованный и обременительный процесс³. Программное обеспечение авиакомпаний должно решать классические проблемы распределённых систем, например, обеспечение согласованности данных. Код-шеринг также порождает проблемы с распределением ответственности и определением того, кто за что отвечает: авиакомпания, по вине которой у пассажира возникла проблема, не обязательно оказывается той, которой предстоит оперативно её решать. Многие ошибки не приводят к ощутимым последствиям, поскольку их удаётся «замять» благодаря героическим усилиям сотрудников аэропортов, работающих с пассажирами.

Каждое из этих наблюдений по-своему верно, но мне любопытно, нельзя ли объяснить происходящее более простыми и прямыми словами. По моему опыту, в отношении программных ошибок действует простое правило: если ошибку в принципе можно исправить и кто-то достаточно влиятельный действительно заинтересован в её исправлении, то её исправят⁴. Даже если для этого придётся кропотливо вносить изменения в устаревшее программное обеспечение. Даже если для понимания проблемы потребуется обзвонить знакомых из десяти разных авиакомпаний, чтобы выяснить, какие неочевидные ожидания заложены в их системах. Ошибку исправят, даже если она кроется в стороннем программном обеспечении, и для этого придётся снова и снова писать письма его поставщику, а затем лично явиться к нему в офис.

Если баг можно устранить и кому-то это важно кому-то вышестоящему, то его устранят. На мой взгляд, этот баг можно устранить. Так, что возможно, не хватает только одного ингредиента?

Примечание: я разработчик ПО, но никогда не работала в авиакомпании и в авиационной отрасли в целом. Я провела это исследование по открытым источникам. Если вы работаете в авиации, то любопытно было бы услышать вас в комментариях! Как вы думаете, в чём истинная проблема?

Примечания

1. В стандарте AIRIMP IATA определяется способ передачи сообщений между системами и указывается SSR INFT, который должен использоваться для детей, летящих на руках у взрослых. Внутренне некоторые системы бронирования также добавляют имя ребёнка к концу поля имени взрослого (наряду с добавлением в SSR INFT). ↩︎

2. Сообщается, что многие другие авиакомпании укорачивают или обрезают имена детей; это может препятствовать посадке на борт, если имя на билете ребёнка больше не совпадает с именем в паспорте. Air Canada иногда сокращает имена детей [16, 17]: одна семья, которой отказали в посадке, была вынуждена потратить более 8 тысяч канадских долларов, чтобы вернуться в Торонто. Как минимум одна семья застряла посреди маршрута British Airways из-за проблемы с обрезанием имени [18, 19], а Vietnam Airlines регулярно сокращает имена детей [20]. Согласно документации Qatar Airways, длинные имена names «не конвертируются автоматически в информацию SSR INFT в PNR, что приведёт к расхождению с информацией INFT». ↩︎

3. Отрасль авиаперевозок готовится к принятию нового стандарта New Distribution Capability (NDC), которая моделирует пассажиров (в том числе и младенцев) более чётко. Хоть это и замечательный шаг, для полного перехода понадобится много времени: согласно исследованию 2025 года, «лишь 27% авиакомпаний уже предприняло шаги для начала... преобразований». Тем временем, авиакомпании должны сохранять возможность общаться по старому стандарту для поддержки маршрутов между разными авиалиниями. ↩︎

4. В редких случаях проблему просто невозможно решить. Допустим, может существовать поведение, считающееся многими ошибочным, но для некоторых пользователей остающееся крайне желательным. Из-за этого изъян становится частью спецификации, превращаясь одновременно и в баг, и в фичу. В других случаях спецификация может быть теоретически нереализуемой. ↩︎