Так в Сирене выглядит бронирование по маршруту Москва (Внуково) — Краснодар и обратно

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

Учёт билетов в тетрадке всё ещё ведётся в некоторых авиакомпаниях (последний раз такое мы видели буквально в прошлом году в Латинской Америке). В СССР же он вёлся до 1972 года, когда появилась первая сеть из авиакасс в четырёх сотнях городов, соединённых с центральным компьютером. Женщину вынули, автомат поставили. Там, где компьютеров не было, диспетчер связывался с ближайшим центром, где компьютер был.

Эти прекрасные романтические времена, когда Аэрофлот фактически повлиял на изобретение советских сетевых протоколов — первая Сирена работала на аналоге UDP с 97% доставкой. Прогресс советских баз данных и прочих технологий, которые сейчас воспринимаются как антураж Фаллаута, — через несколько витков эволюции превратился в связку из нескольких систем, которые, собственно, и выписывают вам билет.

Сейчас расскажу про эту архитектуру.

Очень коротко:
  • Авиакомпании выгружают свои тарифы, расписания и доступные билеты в инвенторные системы (собственные «хранилки»).
  • GDS соединяют инвенторные системы разных компаний и позволяют искать билеты в них. К этим системам подключаются продавцы и берут в них билеты для своих клиентов.
  • В мире есть несколько больших GDS, и одна из них — отечественная Сирена.

Теперь всё будет чуть слож��ее.

Инвенторная система (CRS)


Основа распределения мест авиакомпании — это инвенторная система. По сути, это расширенный аналог тетрадки с записями мест. В инвенторной системе как минимум хранится расписание рейсов и наличие мест на них, а также занятые места связываются с пассажирами.

Билеты перед вылетом проверяются по спискам, которые выгружаются из инвенторной системы на аэропорт отбытия.

Вход и выход простые: вы можете получить из инвенторной системы расписание и наличие мест либо указать, что одно из свободных мест нужно занять вот таким-то пассажиром. Конечно, современные инвенторные системы обладают чуть более широким функционалом, чем просто хранение данных и два внешних API-вызова, но про это дальше.

Инвенторные системы обычно объединяются с какой-то инфраструктурой в контур, который сертифицируется для хранения персональных и банковских данных, прочих чувствительных материй. Всё это вместе обычно называется хостом авиакомпании.

Поднять хост — это целый бизнес, потому что вам нужно развернуть ЦОД, в него натаскать своих серверов, всё это сертифицировать по российским стандартам и множеству зарубежных (начиная с PCI DSS и заканчивая…). Также сверху поставить решение, которое обеспечит совместимость со всеми мировыми системами продажи билетов. И ещё нужно это всё поддерживать. Получается достаточно дорого, поэтому хосты обычно строятся и группируются теми, кто способен один раз отработать процесс создания инфраструктуры под них и поддержки ПО.

Собственно, Сирена (та самая система резервирования авиабилетов) эволюционировала, в частности, в Сирену-Трэвел, которая поддерживает хосты для российских авиакомпаний. Вообще, держать хост у кого-то — общемировая практика. Насколько я знаю, собственные хосты (не SaaS и не аутсорс) поддерживают Эмирейтс и Туркиши. В России вообще нет ни одной авиакомпании, имеющей хост не в виде SaaS.

Глобальная распределительная система (GDS)


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

Очевид��о, был запрос на систему, которая собирала бы все данные со всех хостов и давала возможность решить задачу коммивояжёра на полном графе. Чтобы пассажиру можно было полететь из Нового Уренгоя в Париж с какими угодно пересадками так, как ему нравится: быстрее всего, дешевле, с остановкой в Стамбуле на сутки, без Лондона (потому что там у него нет визы) и так далее.

Появились агентства, которые имели несколько пультов разных авиакомпаний, и кассиры запускали запросы сразу на нескольких ЭВМ. Это выглядело жутким костылём, и нормальное решение виделось достаточно очевидным: нужно было просто уговорить все авиакомпании держать хосты в одной системе.

Но суперхост — идея нежизнеспособная.

Во-первых, исторически это было невозможно. Из-за технических ограничений тех лет просто нельзя было держать базу данных такого размера. Для понимания — первая советская Сирена была разделена на региональные подсистемы, в которых кластеризовались рейсы по авиакомпаниям нескольких схожих направлений. Примерно до середины 1990-х это было около 60 разных «дробных» баз в разных регионах, и нужна была какая-то связка между ними.

Во-вторых, организационно гораздо проще воспользоваться обычным запросом расписания из хоста, чтобы опросить все хосты подряд и составить общее расписание. Это если вы вспомните, что авиакомпании вообще-то бывают в разных странах, а в разных странах — разные стандарты, договорное право и желание хранить свои данные у себя.

В итоге понадобилась надстройка, умеющая собирать расписания и доступность мест с хостов.

Системы, которые опрашивали хосты таким образом, стали современными GDS.

Упрощённо, GDS умеет собирать всё подмножество расписаний хостов, делать поиск на нём и показывать пассажиру (или кассиру) варианты, как добраться из точки А в точку Б, а потом отправлять в инвенторную систему запрос на занятие мест.

То есть это такая обёртка поверх CRS, ставшая, по сути, интерфейсом к хостам.

Соответственно, в случае Советского Союза и России дальше появилась интеграция ГРС Сирена с Сиренами-2000 (региональными инстансами и хостами авиакомпаний). С единого терминала можно было заказывать любой рейс.

Поисковая нагрузка


Инвенторные системы по своей архитектуре очень часто легасевые либо просто не предназначенные для высоких нагрузок. В них нужно отправлять целевой запрос: «Дайте расписание конкретного рейса в определённый день. Фиксируем: есть свободные места, вот эти два займите вот этими пассажирами». Поиск по десяткам разных дат и сотням рейсов они не выдержат в силу своего устройства. А как раз GDS стали прослойкой, которая вполне может отдавать тысячи комбинаций, то есть делать поиск по запросам типа «что у вас вообще есть в Магадан?» или искать с гибкими датами. Для рейса, например, в Эквадор с плавающей датой отбытия нужно было бы сделать от 50 до двух–трёх тысяч запросов в хосты, если бы не было GDS. Соответственно, GDS ещё обеспечивает синхронизацию своих расписаний с хостами, обращаясь в них не каждый раз, а только по изменению на хосте.

Тарифы


Любой тариф должен быть представлен в некотором универсальном виде, позволяющем понять, как он применяется и при каких условиях. В итоге сейчас для нас на практике есть два набора стандартов: общемировой и отечественный. Они совместимы, конечно, но правила тарифной сетки хранятся в двух разных компаниях. У нас это центр расписания и тарифов (ЦРТ). GDS использует базу данных ЦРТ для того, чтобы понять, как и какую услугу считать.

Исторически было так: сначала авиакомпания просто говорила, сколько стоит перелёт и это записывалось в билет в графу «тариф». Затем по ряду причин из тарифа стали выделять сборы: аэропортовый сбор за услуги воздушной гавани и терминала, топливный сбор, госпошлина и дистрибутивный сбор.

Соответственно, для каждого предложения клиенту цены надо очень точно знать: из чего складывается цена на билет, кто из участников цепочки сколько получит.

Этим всем занимается система взаиморасчётов (СВВТ), а ЦРТ — часть СВВТ.


Расчёт тарифа перед продажей билета

Усложнение GDS


Представьте, что вам нужно пересадить человека между двумя авиакомпаниями — сделать connected flight, то есть с гарантией доставки. Опять же, в первом приближении выглядит просто: нужно посмотреть, есть ли у компании А и компании Б соглашение, а потом сформировать один билет из двух сегментов по этому соглашению. Но тут необходимо учесть множество деталей. Например, укладывается пересадка в MCT или нет (это минимальное время от прибытия самолёта до конца посадки другого, зависит от особенностей аэропорта: по проверкам, расстоянию, досмотрам ручной клади и багажа). А если на одном рейсе пассажиру можно 7 кг ручной клади в одной сумке, а на другом 10 кг в любых рекомбинациях — какое правило применять и показывать в тарифе?

И это только стыковки М1. Последние годы развиваются стыковки М2 — новое поколение, когда GDS объединяет две несвязанные соглашениями авиакомпании (или даже авиакомпанию с железнодорожными и автобусными перевозчиками). А иногда система продажи авиабилетов вообще продаёт вам билет на поезд и автобус в М2-стыковке.

В случае Сирены М2 стыковки делались с Deutsche Bahn для доставки по Германии сначала рейсом Аэрофлота в страну, а потом поездами по ней. Сейчас их по понятным причинам уже нет.

Опять же, когда вы начинаете собирать в GDS железнодорожные билеты из АСУ Экспресс (из более консолидированной GDS железных дорог), подтягивать автобусные билеты из аналогов хостов автобусных перевозчиков или их аналогов GDS, то возникает непреодолимое желание интегрировать в систему вообще всё. Сирена в какой-то момент торговала даже билетами на концерты, раз уж инфраструктура имеется. Но поскольку это был не их бизнес, довольно скоро пришли профильные игроки вроде Партера и написали более специализированные и более конкурентные системы.

Следующая задача для GDS — код-шер и интерлайн-перелёты. Например, летит один физический самолёт, но в нём два рейса: один, скажем, S7, а второй — Air France. Формально его выполняет одна из авиакомпаний, а вторая включила его в свою сетку расписания как собственный. Технически можно хранить все такие рейсы в хостах как свои, то есть загружать расписания вообще всех авиакомпаний, с которыми есть соглашения. На практике обычно такое решение используется редко из-за роста базы (и стоимости содержания хоста), и такие рейсы очищает и склеивает между собой уже GDS.

Оплаты


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

Чуть сложнее, если у вас прямой договор с агентством. Там фактическое поступление денег займёт слишком много времени, поэтому обычно есть договорённость уровня «агентство записывает клиента в инвенторную систему, и мы рассчитываемся в конце месяца» или на подобном уровне. Нюанс в том, что турагентство может внезапно разориться (что регулярно и случается) и тогда деньги за цикл могут не дойти до авиакомпании, поэтому используется система депозитов или банковских гарантий.

GDS в итоге должна иметь ещё какой-то сервис, который позволяет заплатить за билет, а не просто его найти и выписать. У нас в России это транспортная клиринговая палата (ТКП). Фактически это компания, которая заключает договоры с каждым из участников, обеспечивает их деятельность банковскими гарантиями или депозитами и делает так, что деньги от клиента в конечном итоге поступят продавцу. Поскольку она ещё и К, там происходит взаимозачёт, и только потом движение денег.

Что получается


  • Авиакомпании держат свои расписания и наличие мест в хостах.
  • Хосты обычно находятся на инфраструктуре компаний, делающих GDS.
  • GDS объединяет хосты, добавляет тарифные правила, делает стыковки, обеспечивает взаиморасчёты через клирингового партнёра.
  • Один хост может быть подключён к нескольким разным GDS.
  • Хосты могут синхронизироваться с другими хостами партнёрских авиакомпаний, используя GDS как шину.
  • GDS может стыковаться с другой GDS или аналогом на другом виде транспорта.
  • GDS не видна пассажиру, он видит TA или OTA — конечных продавцов билетов.

Интересно, что данные продавцов часто используют ещё и метапоиски, которые ищут билеты среди всех продавцов рынка, сравнивая уже конечные предложения с учётом всех промежуточных комиссий, скидок, акций и т.п. Например, мы работаем в России как OTA, продавая билеты напрямую (доставая их из GDS или через прямой договор с перевозчиком), а когда осуществлялись полёты в Европу (мы открывали представительство в Австрии) — там мы были классическим метапоиском, накладывающим свою комиссию на европейские OTA.

Теперь про комиссии. В России Сирена преимущественно берёт комиссию с агентств за выписанный билет. Западная практика — GDS платят агентствам как дистрибьюторам, а авиакомпании, соответственно, платят GDS сбор (11 евро) за каждый сегмент. Сирена — первоисточник контента с билетами. Уже агентствам интересно подключаться к ней и получать от неё сервис.

Ещё один отличный вопрос: откуда тогда тут иностранные компании, которые как-то влияют на наших перевозчиков? В силу определённых особенностей, до появления 153-ФЗ про «приземление» персональных данных, авиакомпании с международными полётами часто сотрудничали с иностранными GDS-операторами для содержания у них хостов. К примеру, Аэрофлот раньше покупал эту услугу у Sabre (и ещё покупает формально, но могу ошибаться), а S7 — у Amadeus. Хост, соответственно, соединялся с несколькими разными GDS, включая Сирену. GDS выступала в роли дистрибьютора билетов, например, у Сирены сейчас 15 тысяч точек продажи и 800 агентств-партнёров (включая нас и других онлайн-продавцов билетов, например, но мы случай немного особый, поскольку сотрудничаем с четырьмя разными GDS и имеем ещё прямые договоры с рядом перевозчиков). Есть страны СНГ, где большинство точек продажи Amadeus, например, поэтому если хочется продавать билеты из этой страны — партнёрство с ними как с GDS становится почти обязательным.

Когда стало невозможно сотрудничать с западными компаниями, возникла необходимость переноса хостов. Был норматив, который требовал переносить хосты в РФ, но перевозчики откладывали сколько могли. В феврале наступил дедлайн. Например, недавний переезд Победы из Navitaire в Сирену — как раз перенос хоста.

Теперь перейдём к вопросу, почему при проблемах с GDS может пострадать продажа билетов у самой авиакомпании. Ещё более интересным следствием того, что GDS фактически выступают умным интерфейсом к хостам, стало то, что напрямую через хост продавать не очень удобно. Даже когда авиакомпания создаёт свой сайт, ей часто удобно продавать не впрямую, а через GDS, пользуясь уже готовыми сервисами код-шера, интерлайна, подключением к ТКП и так далее. Единственное исключение — оформление продаж услуг вроде бортового питания. В итоге, если вдруг из-за санкций с вами перестаёт работать GDS, нужно быстро поменять систему, через которую сделан магазин на сайте, иначе отвалятся и собственные продажи тоже.

Следующий этап развития Сирены — биржа всех возможных услуг партнёров с возможностью их комбинировать под страховку риска, а продаваться это будет агентствам как ИТ-инструмент для получения оптимального билета.

Это ещё не всё, погодите!


У OTA вроде нас могут быть собственные средства, которые обогащают всю эту историю. Во-первых, для ускорения поиска, чаще всего используются объёмные кеши сопоставления данных GDS по расписаниям, тарифным правилам и дополнительным услугам. Чтобы показать клиенту информер со стоимостью билетов по его хитрому маршруту на ближайшую плюс-минус неделю, используются именно собственные кеши, иначе GDS сложились бы под шквалом запросов. Собственные кеши нужны и для того, чтобы опрос GDS занимал не 5–10 минут, а секунды — просто проверить даты обновлений хостов и получить инкремент.

Прямые договоры с авиакомпаниями требуют работы с их инвенторными системами. Поскольку они очень часто немного легаси, нужно либо учить оператора работе с консолью, либо делать собственную обвязку с автоматизацией (или не заключать прямой договор и работать через интерфейсы GDS).

Кроме основных вещей, описанных в стандартах, нужно постоянно поддерживать ещё множество подсистем: например, учитывать, куда и с какими документами можно лететь, где какие правила провоза багажа (вроде габаритов или допустимого веса, что важно для интерфейсов выдачи по билетам), знать время на дорогу между терминалами и аэропортами (чтобы не пытаться продать два разных билета при поиске сложного маршрута без учёта того же MCT) и так далее.

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