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

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

Учёт билетов в тетрадке всё ещё ведётся в некоторых авиакомпаниях (последний раз такое мы видели буквально в прошлом году в Латинской Америке). В СССР же он вёлся до 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) и так далее.

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