что такое валидирующий перевозчик
О процедуре электронного билетооформления. Часть 2
Примечание: В зависимости от обстоятельств, валидирующий перевозчик, маркетинг- перевозчик и фактический перевозчик могут быть одной и той же авиакомпанией (например, если вся перевозка выполняется одной авиакомпанией, которая оформила билет) или тремя разными авиакомпаниями.
Файл электронного билета
По сути, контроль означает, что авиакомпания получает в свое распоряжение электронный вид полетного купона электронного билета как основание для дальнейших действий, например, перевозки пассажира или возврата денег пассажиру за неиспользованный билет. Это то же самое, что получить в свое физическое распоряжение полетные купоны бумажного билета, то есть получить право на соответствующие действия, например, на выполнение перевозки пассажира или на возврат ему денег за неосуществленную перевозку.
Право передавать контроль над купоном другой авиакомпании принадлежит валидирую- щему перевозчику. Принимая такое решение, он должен исходить из таких критериев, как наличие двустороннего соглашения по электронному билетооформлению, присутствие или отсутствие в билете разрешительных/ограничительных записей и т.д. Единовременно контроль над купоном может принадлежать только одной авиакомпании. Если контроль был ранее передан Авиакомпании А, то валидирующий перевозчик не может передать контроль Авиакомпании В, предварительно не отозвав его у Авиакомпании А. Такой порядок установлен во избежание многократного использования конкретного билета или купона.
Статус полетного купона электронного билета
Каждый полетный купон электронного билета, хранящийся в ETS валидирующего перевозчика, имеет соответствующий код статуса купона. По этому коду можно определить состояние купона на каждый данный момент. После оформления электронного билета всем его купонам присваивается статус «Открыт для использования» (« Open for Use »).
По мере использования купонов для перевозки или для других операций (например, для возврата денег пассажиру) код статуса купонов в ETS обновляется с целью фиксации произведенных операций.
Что такое единый авиабилет, или Когда не нужна виза при транзите
Почему мы задали вопрос о едином билете?
Потому что от этого зависит, берет ли на себя авиакомпания полную ответственность за транзит вас и вашего багажа через пересадочные аэропорты, или вам придется организовывать стыковку самостоятельно. От этого зависит, нужны ли вам визы для транзита через аэропорты пересадок. От этого зависит, нужно ли вам выходить из транзитной зоны, чтобы забрать свой багаж и зарегистрировать себя и багаж на следующий рейс.
«Единый билет» — понятие условное. В общих чертах — это один билет на весь маршрут следования, включая все полетные сегменты. А полетных сегментов может быть несколько.
1. Основная отличительная черта — единый билет имеет один номер/код бронирования в системе бронирования («код бронирования / booking reference / reservation code / confirmation / PRN» и т.д.), который указывается в так называемой маршрутной квитанции.
Единый билет всегда имеет только один код бронирования в системе бронирования на весь маршрут следования — как правило, 6 букв/цифр.
Это не код заказа сайта-агрегатора.
Это не код бронирования авиакомпании, хотя они могут и совпадать. Если авиакомпаний несколько, могут быть указаны несколько кодов бронирования авиакомпаний, для каждой авиакомпании свой. При этом код бронирования в системе бронирования все равно должен быть один.
Если авиакомпания не использует международную систему бронирования, она укажет свой собственный код бронирования, в котором может быть больше, чем 6 знаков.
Это не номер электронного билета. Если билет туда и обратно, в маршрутной квитанции будут два номера электронного билета — номер билета туда и номер билета обратно.
Если единый билет авиакомпания выписывает в бумажном виде, он будет на одном бланке авиакомпании.
2. Покупка билета одной транзакцией не означает, что он будет единым. Точно так же покупка одного билета на весь маршрут на сайте-агрегаторе или на сайте агента не гарантирует, что он будет единым. Агрегаторы могут компоновать перелеты под ваш маршрут, стыкуя предложения разных авиакомпаний и совершенно не заботясь о том, чтобы соблюсти визовые требования транзитных стран. При этом вы даже можете купить билет одной транзакцией, но фактически это будет несколько отдельных билетов.
3. Единые билеты бывают разные.
Самый простой пример — все полетные сегменты выполняет одна авиакомпания. В ее обязанность входит доставить вас и ваш багаж из начальной точки маршрута в конечную, включая транзитные аэропорты. Она же сама и перегрузит ваш багаж, и вы получите его в конечной точке маршрута. В случае задержки первого рейса и вашего опоздания на последующие авиакомпания обязана доставить вас в конечный пункт другими рейсами (своими или компаний-партнеров). Некоторые авиакомпании, например, Turkish Airlines или Emirates, в случае длительной стыковки (более 6-8 часов) в транзитном аэропорту (как правило, это их «домашний» аэропорт) могут организовать вам бесплатную экскурсию по городу или предоставить отель.
Покупка двух отдельных билетов на рейсы одной и той же авиакомпании не означает, что вы купили единый билет. Авиакомпания может пойти вам на встречу, сама перегрузить ваш багаж в транзитном аэропорту и даже обеспечить ваш безвизовый транзит через этот аэропорт, но это будет скорее исключением. Правилом будет отказать вам в посадке на рейс, если транзит через стыковочный аэропорт требует визы, а у вас ее нет, и выдать вам багаж после выполнения своих обязательств по первому полетному сегменту, а не перегружать его на свой следующий рейс. Авиакомпания сама принимает решение, как с вами поступить, и об этом решении вы узнаете в последний момент при регистрации на рейс, что крайне рискованно с точки зрения планирования запасных вариантов.
Если единый билет продан авиакомпанией, работающей по код-шеринговому соглашению, ее обязательства ничем не отличаются от описанных выше. Разница только в том, что в таком билете есть валидирующий перевозчик — как правило, это авиакомпания, выполняющая более продолжительную часть маршрута; она же и получает ваши деньги и выписывает вам билет. В случае непредвиденных обстоятельств все претензии нужно предъявлять валидирующему перевозчику. При этом название фактического (оперирующего) перевозчика вы можете даже не знать, поскольку его может не быть в выписанном вам билете.
Если авиакомпании работают по интерлайн-соглашению, которое предполагает взаимное признание авиабилетов и возможность продавать перевозки по маршрутам другой стороны, то и в этом случае билет будет единым, если в перевозке участвуют обе авиакомпании. Все перечисленные выше обязательства по отношению к вам и вашему багажу сохраняются, однако, в отдельных случаях следует просить зарегистрировать багаж до конечного пункта. Но если на одном из полетных сегментов произошло ЧП, вы должны предъявить претензию к фактическому перевозчику на этом сегменте. В билетах такого типа указываются все задействованные перевозчики.
4. Посадочные талоны. Получение посадочных талонов на первый и все последующие полетные сегменты при регистрации на рейс в первом аэропорту вылета — отличительная черта единого билета.
В некоторых случаях все же придется получить посадочные на последующие сегменты в транзитных аэропортах. Так может быть, если компании-перевозчики по вашему маршруту действуют по интерлайн-соглашению, или компания не готова в данный момент выдать вам посадочный на следующий рейс, или произошло изменение в расписании, или еще ряд случаев. Это не должно вас смущать, поскольку посадочный на следующий рейс вы все равно получите.
5. В случае, если ваш маршрут предполагает транзитные стыковки в странах / аэропортах, имеющих визовые требования по отношению к вашему гражданству, единый билет обеспечит вам безвизовый транзит при таких стыковках. Исключение составляют:
6. Частным случаем является отсутствие в некоторых аэропортах транзитной зоны или ее работа только в дневное время (на ночь аэропорт закрывается). Чаще всего авиакомпании не продают единый билет с вылетом из страны, гражданам которой требуется виза для транзита через такие аэропорты.
Летим с собакой в Италию – «Аэрофлот», KLM & AirFrance
Летим в Италию! Летим с собакой. Как получить разрешения и подтверждения на перелет с животным в салоне самолета, если рейс комбинированный – «Аэрофлот», KLM, AirFrance да с пересадками.
К апрельскому полёту Москва–Болонья мы начали готовиться заблаговременно. Очень заблаговременно. Ещё в феврале. Причин для такой заблаговременности было несколько. Одна из них – в феврале у нашей чихуахуа Лулу началась течка. А это значит, перед нами нарисовался вопрос – рожать или не рожать.
Если рожать, то в апреле никуда не лететь. Принятие решения было мучительным 🙂 Поэтому на семейном совете мы определились, что если получим все разрешения и подтверждения от авиакомпаний, то полетим (и роды перенесём на следующую течку). Если же не получим подтверждения от одной из авиакомпаний, то остаемся дома, плачем горькими слезами по потерянным билетам и забронированным виллам и рожаем 🙂
Италия или рожать? Вам, наверное, уже интересно, чем закончились наши колебания. – Мы летим! А рожать будем – если всё сложится – в декабре 🙂
Теперь о том, что делать и как получать подтверждение на провоз животного в салоне самолёта, если рейс комбинированный с несколькими авиакомпаниями.
Наш полет:
Москва – Париж / «Аэрофлот»
Париж – Болонья / AirFrance
Болонья – Амстердам / KLM
Амстердам – Москва / «Аэрофлот»
Валидирующий перевозчик (англ. Validating Carrier) – это авиакомпания, которая ответственна за тикетинг (то есть за все операции с вашим билетом, включая его оформление, продажу, возврат, обмен и так далее) и все другие операции, связанные с перевозкой.
Если сложный билет (с одной или несколькими пересадками и сменой перевозчиков) покупался в турагентстве (как это было в нашем случае) или через онлайн-сервис по бронированию билетов, то на распечатке электронного билета с маршрутом следования надо искать, кто же является валидирующим перевозчиком.
Если билет покупался на сайте одной из авиакомпаний, участвующих в перевозке, то валидирующим перевозчиком будет именно эта авиакомпания.
Запрашивать подтверждение на провоз животного надо именно у той авиакомпании, которая является валидирующим перевозчиком. Эта авиакомпания даст или не даст разрешение на все сегменты полёта.
В нашем случае валидирующим перевозчиком была AirFrance. Но так как у меня предвзятое отношение к этой авиакомпании, то звонить я решил в её дочернюю KLM.
Шаг 1. Сначала читаем на сайте KLM информацию о перевозке животного в салоне самолета:
Шаг 2. Звоним в KLM по телефону +7.495.4117766
Вежливые сотрудники поинтересуются породой собаки, размером переноски (я дал допустимые размеры, указанные на сайте KLM) и общим весом переноски с собакой. Иногда подтверждение на провоз животного могут дать сразу же. Так как наш перелет состоял из нескольких сегментов (Москва–Париж–Болонья–Амстердам–Москва), то меня попросили перезвонить через пару дней.
Шаг 3. Перезваниваем через пару дней и получаем разрешение на перевоз собаки в салоне самолёта.
Дополнительные предосторожности в отношении животных со вздернутыми носами:
В стрессовых ситуациях животные со вздернутыми носами, такие, как мопсы, бульдоги, боксеры, пекинесы, ши-тцу или персидские кошки, могут испытывать трудности с дыханием из-за своей морфологии. Перед полетом рекомендуется проконсультироваться у ветеринара.
В отличие от «Аэрофлота», который только устно по телефону озвучивает, разрешили или нет, KLM указывает информацию о полученном вами подтверждении на провоз животного. Подтверждение можно найти на сайте KLM в разделе «Моё путешествие». О том, какие документы должны быть на собаку для международных перелетов, я уже рассказывал вот здесь.
Сколько стоит билет для собаки?
Специально позвонил ещё раз в KLM, чтобы уточнить, надо ли оплачивать билет для собаки за каждый сегмент перелёта.
Ответ был простой и ясный: Если пересадка менее 12 часов, то платить надо только один раз (55 Евро) за всё направление. То есть за первое направление Москва–Париж–Болонья – платим 55 Евро только в Москве. И за второй перелёт Болонья–Амстердам–Москва – платим 55 Евро только в Болонье. Конечно, при условии, что на все сегменты перелета у вас один билет, а не разные билеты, купленные у разных авиакомпаний.
Полёт с «Аэрофлотом» и в этот раз был прекрасен. Молодцы они! Если интересно, по ссылкам ниже можно почитать о том, как мы летаем с чихуахуа Лулу:
PS: Всё-таки и в этот раз AirFrance испортила настроение. Они как-то на ровном месте умудряются какими-то своими интонациями и жестами омрачить путешествие. Странная, нелюбимая авиакомпания. Когда же она уже обанкротится?!
Обратная сторона авиабилета. Как Туту.ру помогает подобрать оптимальный тариф
Весной 2014 года были приняты поправки к Воздушному кодексу РФ, позволяющие авиакомпаниям заключать договор на перевозку без возврата платы за проезд в случае расторжения договора. Иными словами, на рынке авиаперевозок появились невозвратные тарифы. До этих изменений авиакомпании могли лишь удерживать штраф в размере не более 25% от стоимости билета, если пассажир сдавал билет позднее, чем за сутки до вылета. Новые поправки позволили авиакомпаниям предложить пассажирам более дешевые, но невозвратные билеты.
В это же время появились бюджетные «безбагажные тарифы». На самом деле, полностью безбагажными их назвать нельзя: по закону РФ, пассажир имеет право провезти с собой до 10 кг личных вещей. И здесь есть интересный момент: закон не регулирует, каким образом пассажир перевозит эти 10 кг — в салоне самолета или в багажном отсеке. Как известно, в салон нельзя брать множество вещей: например, жидкость более 100 мл, маникюрные ножницы, пилочку и некоторые гаджеты. Даже если тариф включает провоз багажа, каждая авиакомпания сама определяет максимальный вес и размеры багажа и ручной клади на одного пассажира.
Пассажиры путались в тарифах, возникало много вопросов, связанных с провозом багажа и доплатой перевеса. В этой статье я хочу рассказать, что и как мы сделали, чтобы облегчить пользователям Tutu.ru поиск наиболее подходящих авиабилетов среди десятков доступных вариантов.
Цены на билеты многих авиакомпаний не выглядели привлекательно на фоне экономического кризиса, отнюдь не дешевеющих тарифов на поезда и появления «Победы», которая действительно сбила цены на многих направлениях. Например, до появления лоукостера я летал в Чебоксары и обратно за 8–10 тысяч рублей, а сейчас полет обойдется в 3–6 тысяч.
Осенью 2015 года авиакомпании с целью снижения цен начали активно внедрять безбагажные и невозвратные тарифы. Для нас было очень важно предоставить пользователю возможность самостоятельно выбирать интересующие его опции. Люди сталкивались с тем, что в аэропорту требуют доплатить за багаж, или что билет нельзя сдать или обменять. Мы хотели дать человеку возможность выбрать именно то, что ему нужно, максимально облегчив и ускорив поиск билетов. С другой стороны, и сами авиакомпании выдвинули своим агентам, в том числе и Туту.ру, требование показывать информацию об особенностях тарифа уже на этапе поиска.
К тому моменту мы уже показывали клиентам, можно ли сдать или обменять билеты. С багажом все оказалось сложнее.
На вкус и цвет GDS’a нет
Данные по багажу мы получаем от систем бронирования (GDS — Global Distribution System), что накладывает некоторые ограничения. Во-первых, мы работаем с несколькими GDS, а также с агрегаторами GDS, и это требует поддержки решения для каждой из систем.
Во-вторых, исторически сложились два типа авиакомпаний. Одни ограничивают максимальный багаж по весу, а другие — по числу мест. Например, «Аэрофлот» дает ограничение по числу мест, и из GDS нам поступают малоинформативные данные о багаже: «1 piece» без информации о максимальном весе.
И, наконец, самое главное. Информация об ограничениях на багаж приходит из GDS подчас тогда, когда клиент уже выбрал конкретное предложение и приступил к оформлению заказа. Мы же стремились дать клиенту возможность сравнить предложения еще на этапе выбора. Посылать уточняющие запросы к GDS, пока клиент выбирает, было бы слишком накладно и по деньгам, и по времени: на одном направлении в день могут быть десятки и сотни предложений.
Конечно, GDS не стоят на месте, и в новых версиях API интересующей нас информации приходит больше, а для некоторых GDS она доступна уже на этапе поиска. Но в большей степени это относится к крупным авиакомпаниям, которые перешли на систему брендированных тарифов (о ней речь пойдет позже). Мы используем эту информацию, но всё же этого недостаточно, чтобы сделать действительно удобный сервис. GDS не всегда следят за тем, чтобы авиакомпании вносили информацию о багаже, и уж тем более не несут ответственности, если правила изменились, а информацию в GDS ещё не внесли, или если при внесении была допущена ошибка. Поэтому для многих небольших и региональных авиакомпаний этой информации в GDS нет. Данные об ограничениях на ручную кладь не вносит практически ни одна авиакомпания.
Есть и совсем сложные случаи, например, авиакомпания Оренбуржье заносит в GDS информацию, что разрешен багаж весом не более 10 кг. При этом рейсы выполняются на самолётах Ан-2, у которых нет багажного отделения, поэтому взять запрещенные к провозу в салоне вещи не получится. В данном случае мы показываем пользователям, что на рейсе нет багажа, но разрешена ручная кладь весом до 10кг.
С возможностью обмена и возврата на тот момент все было немного лучше, но лишь немного. Информация о возможности возврата и обмена билета (как и о багаже) нередко была доступна только по выбранному предложению, а не на этапе поиска. Причем данные из GDS приходили нам не в виде удобного для обработки XML, а в виде «простыни» текста, в которой единственное форматирование — разное количество пробелов в начале строки.
Мы уже знали, как определять по таким текстам условия обмена и возврата и даже до какого срока они возможны: у одних компаний до окончания регистрации, у других — не позднее, чем за 48 часов до вылета и т.д. Для этого мы сохраняли тексты тарифных правил по всем заказам, которые сделали наши пользователи. Затем простая, но автоматическая система находила в сохраненных текстах меняющиеся от заказа к заказу части, вроде суммы штрафа за возврат, и вырезала их. От полученного текста с пропусками вычислялся некоторый хеш, и затем исходные, т.е. без пропусков, правила группировались по этому хешу. Практически каждый заказ после оплаты просматривался операторами нашего контакт-центра. Операторы читали конкретный текст правил, определяли в нем условия обмена и возврата, и ставили в соответствии с хешем этого текста удобоваримое описание Например, «Возврат возможен не более чем за 24 часа до вылета». Впоследствии, когда очередной клиент делал заказ, и для текста тарифных правил вычислялся хеш, мы уже могли показать понятные условия обмена и возврата. Но на этапе поиска это решение опять-таки не подходило: информация приходила уже на этапе оформления заказа.
Новая система тарифов
Разработку нового решения мы начали с простейшей системы, умеющей показывать ограничения только для авиакомпаний S7 и Уральские Авиалинии. Они первыми в России перешли на новую систему тарифов. Как работала старая система: допустим, авиакомпания открывает продажу на рейс, который будет выполнять самолет на 300 человек. Эти 300 мест разбиваются на 10-20 так называемых классов бронирования (не путать с классами обслуживания: Эконом, Бизнес, Первый и т.д.). Каждый класс фактически определяет услуги, предлагаемые авиакомпанией: норму провоза багажа, включенное питание, возможность выбора места, а также обмена и возврата билета и т.д. В зависимости от набора услуг меняется и стоимость тарифов в этом классе. Причем на разных рейсах внутри одного класса бронирования набор услуг может отличаться.
Новая система тарифных семейств (еще их называют брендированными тарифами) проще. Классы бронирования остаются, но за доступные опции отвечает код тарифа, а именно его название; конкретный класс бронирования и рейс на это уже не влияют. Например, у S7 есть 4 тарифных семейства: Эконом Базовый — невозвратный и только с ручной кладью, Эконом Гибкий — возвратный и с включенным багажом 23 кг, Бизнес Базовый — невозвратный, без доступа в бизнес-зал и с одним местом багажа до 32 кг и Бизнес Гибкий — возвратный, с доступом в бизнес-зал и двумя местами по 32 кг. Отличить их друг от друга очень просто: в коде тарифов семейства Базовый есть подстрока BS, а в коде тарифов семейства Гибкий — подстрока FL. Класс бронирования уже не отвечает за доступные опции. Например, если осталось 9 мест по классу бронирования N, то на эти места можно купить билеты и с багажом, и без него.
Вскоре еще несколько крупных российских авиакомпаний перешли на тарифные семейства. Мы поставили перед собой цель предоставить пользователю возможность выбора в подавляющем большинстве случаев (даже когда нужно долететь из Якутска в Белую Гору). Кроме того, с тарифными семействами все просто только до тех пор, пока клиент летит собственными рейсами авиакомпании, которой эти тарифы принадлежат. Как только возникает пересадка со сменой авиакомпании, начинаются исключения.
Разработка собственного решения
Разработку собственного решения мы начали с тщательного анализа. Мы пошли к операторам нашего контакт-центра и долго выпытывали у них, какая авиакомпания отвечает за предоставление клиенту тех или иных опций. Немного отвлекаясь, отмечу, что в процессе покупки билета участвует до трех авиакомпаний сразу: та, которой принадлежит самолет (мы называем её оперирующей), та, чей номер рейса указан на вашем билете (маркетинговая), и та, которая продала вам билет на своем бланке и будет распределять деньги между остальными (валидирующая).
Например, вы летите из Челябинска в Рим с пересадкам в Москве и Дюссельдорфе. На сегменте Челябинск — Москва вы летите собственным рейсом авиакомпании S7 — S7-8. На сегменте Москва — Дюссельдорф самолет принадлежит S7, но на билете у вас указан рейс авиакомпании AirBerlin и номер AB-5911. Значит, на этом сегменте оперирующий перевозчик — S7, а маркетинговый — AirBerlin и такая комбинация называется codeshare-соглашением. Дальше из Дюссельдорфа до Рима вы летите собственным рейсом AB-8718 AirBerlin. При этом весь перелет из Челябинска в Рим оформлен одним электронным билетом, который продала вам авиакомпания AirBerlin несмотря на то, что на первом сегменте вы летите собственным рейсом S7. В данном случае AirBerlin является валидирующим перевозчиком, т.е. авиакомпанией, которая по взаимному соглашению с другими авиакомпаниями-участниками перелета оформляет билет и будет осуществлять взаиморасчеты. Такое соглашение называется interline. Чаще всего валидирующая компания является и маркетинговой на каком-нибудь из сегментов, однако бывают случаи, когда отличаются все три авиакомпании — оперирующая, маркетинговая и валидирующая.
Так вот, на этапе сбора информации мы выяснили, что обычно опции задает маркетинговая авиакомпания — та, чей номер рейса указан у вас в билете и которой принадлежит тариф. Правда, может оказаться, что самолет оперирующей авиакомпании не рассчитан под нормы маркетинговой. Это относится в основном к багажу. Например, в самолете может не быть багажного отсека, как, например, в Ан-2. Кроме того, на рейсах с пересадками на разных сегментах могут быть разные правила провоза багажа и сомнительно, что пассажир будет рад где-нибудь в промежуточном пункте избавляться от лишних 2 кг багажа. С другой стороны, «Аэрофлот» чаще всего гарантирует своим клиентам свои нормы багажа, даже если у оперирующей авиакомпании нормы меньше.
Даже в рамках одной авиакомпании часто встречаются исключения на конкретном направлении и даже по конкретному аэропорту. Например, у Qatar Airways норма бесплатного провоза багажа в эконом-классе для рейсов из России — 1 место весом не более 30 кг, а для рейсов из США — 2 места не более чем по 23 кг каждое. У многих компаний меняются нормы багажа на рейсах на Ближний Восток — в Турцию и Египет. Есть и совсем исключительные случаи, когда на каком-нибудь отдельном направлении право устанавливать нормы багажа и взимать плату за их превышение выкупает не относящаяся к авиакомпании фирма.
Параллельно с накоплением знаний о проблеме мы начали собирать ту информацию, которая нам приходит из GDS, в надежде вытащить из нее закономерности. Нам нужно было поддерживать нашу базу знаний, поскольку тарифные правила авиакомпаний меняются постоянно. Идея не сработала: только для одного «Аэрофлота» с довольно стандартизированными правилами мы получили дерево решений, занявшее лист A4 очень мелким шрифтом.
Внедряем механизм FRule
В итоге мы решили использовать механизм FRule, который уже давно использовался в нашей команде и изначально представлял собой механизм гибкого конфигурирования. Позднее мы успешно применили его в нескольких прикладных задачах.
FRule — это система гибкого конфигурирования, которую мы разработали для наших сервисов. Впоследствии названием FRule стали называть архитектурный подход для описания системы, в которой необходимо гибко задавать и выбирать частный случай среди множества общих случаев.
Представляет он из себя вот что. Допустим, у нас есть функция от N переменных. Сначала мы задаем
Затем фиксируем какую-нибудь переменную 
и задаем
А, например, для 
задаем
Дальше фиксируем 
и продолжаем процесс, по сути переходя от общего к частному. Затем на вход этой функции подаются какие-либо данные. В случае с определением нормы багажа это данные полетного сегмента: откуда, куда, когда, какие авиакомпании, код тарифа и т. д. Здесь есть один нюанс: переменные в функции 
могут быть неравнозначны между собой. Рассмотрим простейший случай функции двух переменных 
. Пусть мы задали
Для заданной таким образом функции 
не определено. Чтобы избавиться от таких неопределенностей мы используем предустановленную систему приоритетов: мы говорим, что значения определенные для набора, в котором фиксирована только 
, приоритетнее, чем значения, определенные для набора, в котором фиксирована только 
. При этом значения, определенные для набора, в котором фиксированы и , и , приоритетнее значений, определенных для наборов, в которых фиксирована только одна из переменных. Таким образом, 
. Эти приоритеты обычно проистекают из предметной области и бизнес-логики, например, очевидно, что указание города приоритетнее указания страны.
Прежде чем разрабатывать решение для продакшена, мы решили проверить его «на коленке», и не зря. Физически механизм FRule представляет собой набор соответствий «параметры — значение» функции , хранящийся в MySQL. Исходя из приоритетов наборов при обращении к FRule, выполняются нехитрые запросы до того момента, пока не будет найден результат, который затем кэшируется. Для первоначальных задач конфигурирования этого более чем хватало. Выяснилось, что задачу определения опций необходимо дорабатывать. Оказалось, что для расчета багажа всех предложений по маршруту Москва — Санкт-Петербург на один день потребовалось 20 минут. Пересмотрев систему приоритетов и убрав оттуда избыточные и неиспользуемые наборы, мы сократили его до 3 минут. Однако это все равно было много.
Узким местом оказалась MySQL, а точнее, количество и накладные расходы на запросы, которые мы ей посылали в том случае, если результата для конкретного предложения нет в кэше. Для каждого предложения мы начинали искать совпадения: сначала по наиболее частному набору, затем переходили ко все более и более общим наборам. Приведем пример, чтобы представить масштаб бедствия. Сейчас у нас 288 наборов с разным приоритетом. Предложений по поиску на одно направление могут быть сотни и тысячи, и несмотря на то, что не все они будут показаны пользователю, обрабатывать требуется все.
Для решения этой проблемы мы решили перенести вычисления на бэкенд. Вычисление значений состоит из двух частей. Первая — это построение некой специальным образом организованной структуры. Вторая — вычисление значений исходя из этой структуры.
Рассмотрим, что за структуру мы строим. Вернемся к нашему примеру функции от двух переменных. Для нее мы определили такой приоритет наборов:
Напомню, что самый верхний набор является самым частным — если для всех входящих в него полей есть явно заданное значение функции, то оно и будет использовано. По сути, мы преобразуем плоскую табличку, хранящуюся в базе данных, в набор деревьев для каждого набора переменных. Рассмотрим процесс построения набора деревьев для набора 
. Сначала запросом типа
Мы получаем из базы данных все строки, для которых определены и , и . Затем группируем их по значению переменной . Затем правила в каждой группе группируем по переменной , и т.д. Таким образом, для наиболее частного набора строим такой набор деревьев:
Эту процедуру повторяем для каждого набора переменных. Например, для набора 
мы выберем правила запросом
Неиспользуемые в наборе переменные помечаем значением NOT_SPECIFIED. После того, как получены наборы деревьев для каждого набора параметров, складываем их в один массив с сохранением порядка приоритетов наборов.
В итоге для функции получаем такой набор деревьев:
Структура для проверки построена, остается лишь пропустить через нее входные данные функции. Перебираем деревья сверху вниз и обходим каждое их них, для каждой переменной выбирая ту ветвь, которая соответствует её значению. Если же такой ветви нет, то пробуем пройти по ветви NOT_SPECIFIED. Если значение найдено, то возвращаем его.
Кэширование данных
На самом деле, строить набор деревьев при каждом вызове FRule было бы странно — его можно один раз посчитать и запомнить. Кроме того, у нас несколько серверов, на которых может выполняться эта задача, так что неплохо было бы еще и передавать набор деревьев между ними. Для кэширования и синхронизации между серверами вычисленных значений мы используем memcache. Однако обращаться каждый раз к memcache, чтобы забрать из него набор, дорого — реальные наборы занимают несколько мегабайт и нет никакого смысла гонять их по сети. Поэтому кроме memcache мы используем еще и APCu (а до перехода на PHP7 — xCache). Если сервер построил или получил из memcache набор деревьев, то он сохранит его в APCu и в следующий раз возьмет оттуда.
Возникает еще проблема с синхронизацией изменений — ситуация, когда правила были изменены и на одном севере они применились, а на другом всё считается по-прежнему из-за старых данных в APCu, недопустима. Для решения этой проблемы мы храним в memcache текущий номер версии структуры. Он состоит из временной метки и версии кода, который построил структуру. Такая же метка хранится также в APCu каждого из бэкендов. Перед тем, как взять деревья из APCu, бэкенд проверяет, совпадает ли номер версии в его APCu с сохраненным в memcache. И если не совпадает, то перестраивает структуру и устанавливает в memcache и свой APCu новый номер. При редактировании правил из админки номер версии в memcache просто сбрасывается: таким образом все бэкенды узнают о том, что надо перестроить структуру.
Что мы в итоге получили
У пользователя, для выдачи которого нет данных в кэше, вычисление данных о тарифных опциях занимает от долей секунды до 15-20 секунд на очень больших выдачах, где много рейсов и много пересадок. Вскоре после выхода бэкенд-части на бой наши фронтенд-разработчики сделали фильтры по багажу, возможности обмена и возврата, благодаря чему клиенты могут сразу отсечь неинтересные им предложения. По статистике, новыми фильтрами пользуются порядка 10% посетителей, а интересуются параметрами багажа и возвратности 15%. Теперь пользователям не приходится долго искать тот же рейс, но с багажом или возможностью возврата. Мы научились отображать краевые случаи, например, авиакомпания «Полярные авиалинии» суммарно разрешает взять 20 кг багажа, из которых не более 5 — в ручную кладь.
Вот пример результатов нашей работы. Мы помогаем купить билеты не только по традиционным маршрутам в Санкт-Петербург, Сочи или Симферополь, но у нас довольно популярны и региональные направления. Посмотрим на рейс авиакомпании Алроса из Красноярска в Мирный:
Сразу при поиске можно посмотреть все подробности: и возможность обмена или возврата, и норму багажа, и норму ручной клади, и даже особую схему их расчета, когда пассажир может взять именно суммарно 20 кг багажа. Зачастую такую информацию можно получить или на сайте авиакомпании, или только из личного общения с представителем авиакомпании. Стоит отметить, что это не только наше желание показать всю информацию честно и четко — все эти параметры очень важны самим покупателям при выборе, и без них мы получаем обратную связь от пользователей, что этого не хватает.
С технической точки зрения, мы получили базу знаний, содержащую порядка 10 000 правил, что в значительной мере покрывает наш ассортимент. Конечно, остаются еще предложения, для которых у нас пока не заведены правила — особенно это касается тех направлений и предложений, по которым у нас редко ищут и покупают. Для того, чтобы контент-менеджеры могли оперативно узнавать о таких предложениях, мы разработали специальную систему логирования: стоит прийти значению той или иной опции, которая отличается от значения в нашей базе знаний или которой в ней нет, в течение часа контент-менеджеры об этом узнают. Для поддержания базы в актуальном состоянии наши контент-менеджеры постоянно взаимодействуют с авиакомпаниями и проверяют, нет ли изменений на официальных сайтах, созваниваются с их представителями.
Созданный механизм достаточно легко расширяется: мы можем начать показывать информацию о размере доплаты за багаж, возможности провоза спортивного снаряжения, количестве начисляемых бонусных миль и т. д.