Билеты, баги и БДСМ: хроники тревел-стартапа

Если вы никогда не задумывались, на чём вообще держится индустрия путешествий, присаживайтесь. Рассказ будет недолгим — минут на сорок. Если вы хоть раз покупали авиабилеты онлайн, то наверняка заметили странную особенность даже самых «успешных» сервисов: они умеют ровно две вещи — найти билет и продать билет. Всё. Как только ваши планы внезапно меняются, магия испаряется, и начинается древний ритуал: вы берёте телефон, звоните в поддержку и слушаете саундтрек, который не выбирали. Бездушный автоответчик шепчет, что все операторы заняты, просит остаться на линии, а в трубке тихонько умирает ваше свободное время.

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

А PSS — Passenger Service Systems — это как раз те самые динозавры. Древние, массивные, неприкасаемые. В них живут бронирования, билеты, тарифные правила и вся логика, объясняющая, почему перелёт с пересадкой в Чикаго стоит как подержанная «Тесла». PSS — это священные реликвии, написанные в эпоху телетайпов и перфолент, и с тех пор тронутые примерно столько же раз, сколько египетские пирамиды. Работает? Работает. Значит, не трогаем. Любая попытка модернизации выглядит как попытка провести МРТ на мамонте: интересно, но зачем?

Поэтому неудивительно, что всё это великолепие дожило до наших дней практически без изменений. И у этого есть простое объяснение: менять дорого, а платить никто не хочет. Да и с точки зрения авиакомпании логика железобетонная: не нравится процесс покупки билета? Ну… не покупай. Иди пешком. Всё равно на этом направлении летаю только я, аэропорт арендован до конца времён, а вероятность появления конкурента примерно равна шансу увидеть мамонта, который сам пытается подключиться к USB‑C.

Когда появился Интернет, GDS, конечно, решили «идти в ногу со временем». Ну как решили… Телетайпы стали дорогими, бумага — тоже, а оплачивать выделенные линии ради того, чтобы печатать шифровки в стиле «рейс вылетел, но это не точно», стало уже совсем несолидно. Поэтому вся эта доисторическая инфраструктура была аккуратно перенесена… в терминал. Чёрный экран, зелёные буквы, ощущение, что сейчас появится курсор‑квадратик и предложит ввести команду HELP. Дёшево, сердито, и главное — можно продолжать ежегодно продавать обновлённый справочник кодов.

А коды — это отдельная глава эпоса. Трёхбуквенные коды аэропортов, двухбуквенные коды авиакомпаний — привет от IATA. Удобно, чёрт побери. И придумано всё это было не ради красоты, а чтобы телетайпы не захлебнулись от длинных названий, а мейнфреймы не умерли от перегрузки. На секундочку: расписание авиакомпаний составляется на год вперёд. И даже в виде этих компактных кодов, упакованных в специальный формат, оно занимает около 1.5 гигабайт. Сегодня это смешно, а шестьдесят лет назад — это была инженерная задача уровня «как упаковать слона в чемодан и ещё оставить место для зубной щётки».

И вот что особенно прекрасно: в таком виде это расписание рассылается до сих пор. Да‑да, в 2026 году IATA продолжает продавать гигабайтные файлы, которые выглядят как смесь древнего заклинания и дампа памяти. Парсинг этого чуда — отдельная сказка. Ты сидишь, смотришь на эти строки, и пытаешься понять, что именно хотел сказать автор: «вылет в 13:40», «рейс отменён» или «поздравляем, вы нашли секретный уровень».

И всё это нужно не только хранить, но и давать удалённый доступ турагентствам по всему миру. Через терминалы. Через протоколы, которые выглядят как ASCII‑магия. Через каналы связи, которые сегодня бы не выдержали даже TikTok‑ролика. Интернет ничего не исправил — он просто позволил всей этой конструкции продолжать жить, слегка замаскировав седину.

Нет, ну конечно, в какой‑то момент товарищи из GDS решили, что надо бы «делать API», чтобы выглядеть модно, молодёжно и вообще не отставать от прогресса лет так на двадцать. И если кто‑то сейчас подумал: «Ну вот, молодцы же!» — вы очень торопитесь с выводами. Выбор у них пал на SOAP. Да‑да, тот самый SOAP, который даже в нулевых считался чем‑то вроде корпоративного BDSM: формально работает, но каждый раз больно. И то, что они наваяли поверх своих доисторических систем… я даже не знаю, как это корректно назвать. Схема такая: ты шлёшь SOAP‑запрос → где‑то в недрах GDS он преобразуется в старые добрые телетайпные коды → эти коды запускаются в древний PSS → PSS что‑то отвечает → GDS парсит этот ответ обратно → пытается собрать SOAP‑ответ → и присылает его тебе, как будто всё так и было задумано.

На бумаге выглядит почти прилично. Но есть нюанс: GDS работают через сессии со стейтом. То есть чтобы добиться какого‑то результата, нужно создать сессию и слать запросы в строго определённой последовательности, как будто проходишь квест в стиле «введи команду, чтобы открыть дверь». Ошибся шагом — всё, начинай сначала, сессия умерла, попробуй ещё раз. И вот результат: у GDS всё это вылилось примерно в 300+ эндпоинтов. Чтобы просто реализовать работу с самолётами, гостиницами и прокатом машин, тебе нужно имплементировать около 140 эндпоинтов. Сто сорок. Чтобы купить билет и забронировать отель. Это не API — это производственная версия «Тёмных душ», только вместо меча у тебя SOAP‑клиент, а вместо боссов — XML‑схемы, которые весят как небольшой роман.

То есть вы уже можете примерно представить весь этот технологический карнавал, но, поверьте, это только аккуратный краешек. Дальше начинается настоящее веселье. Например, в Java‑моделях для этих самых 140 эндпоинтов — больше миллиона строк кода. Миллион. Строк. Кода. Конечно, руками это генерировать никто в здравом уме не будет, но чтобы генератор выдал хоть что‑то, что не развалится при первом же запуске, вам понадобится опыт настройки, понимание SOAP и крепкая нервная система. Потому что каждая моделька для каждого эндпоинта поставляется как независимая сущность, без малейшего намёка на общую структуру. Хотите, чтобы после генерации у вас получилось что‑то рабочее? Терпение. И ещё раз терпение.

И вот тут мы подходим к главному, почему большинство даже очень успешных компаний так и не продвинулись дальше «поиска» и «купить». Потому что некоторые процессы на стороне GDS, которые вроде как были покрыты API, внезапно оказались… не рабочими. Формально эндпоинт есть, документация есть, схема есть, а по факту — он стабильно возвращает ошибку. Помните про сессии и стейты? Так вот, некоторые команды, которые должны были вызываться внутри этих API‑процессов, по какой‑то причине потерялись по дороге.

Чтобы всё это понять, вам нужно рядом с IDE открыть тот самый терминал (который они теперь гордо запускают в браузере) и следить вручную, в каком состоянии находится ваша сессия. То есть вам нужно стать тем самым тревел‑агентом со справочником команд. И вот тут в ход идут настоящие реликвии:

• A — показать доступность по маршруту

• AN15MAYYULNYC — доступность на конкретную дату

• 01Y1 — забронировать место в нужном классе

• RT — показать текущее бронирование

• ER — сохранить изменения

• XI — удалить сегмент

• FXP — пересчитать тариф

• WPNC — пересчитать тариф с правилами

• @ — повторить предыдущую команду

И это только разминка. Дальше идут команды, которые выглядят как смесь заклинаний и случайного набора символов, и каждая из них что‑то делает. Иногда даже то, что вы ожидали. И самое прекрасное: чтобы ваш API‑процесс работал, вам нужно дополнять вызовы SOAP‑эндпоинтов ещё одним специальным API, который является тупой обёрткой над этими терминальными командами. То есть вы буквально шлёте XML, который внутри вызывает терминальную команду 1970 года, которая внутри вызывает PSS 1960 года, который внутри вызывает боль.

И вот эта часть оказалась не по силам любителям смузи и микросервисов. Потому что одно дело — писать REST на Go, а другое — сидеть ночью, смотреть на терминал 1980 года в браузере и думать: «Господи, что я делаю со своей жизнью».

А дальше был NDC. Если SOAP когда‑то был такой себе «красивой» обёрткой над GDS — XML сверху, телетайпные команды внутри — то NDC стал тем же самым, только уровнем ниже, прямо поверх PSS. То есть индустрия сказала: «Ну раз GDS — это боль, давайте общаться напрямую с авиакомпаниями». Логично звучит ровно до того момента, пока не вспоминаешь, что PSS — это те же самые динозавры, просто без посредника.

И тут важно понимать: NDC — это не стандарт. Это рекомендация. Такой себе документ в духе: «Ну вы там сами разберитесь, как хотите, главное назовите это NDC». И авиакомпании разобрались. Каждая — по‑своему. Кому‑то приснился JSON. Кому‑то XML. Кому‑то гибрид, который вызывает флэшбеки у людей, переживших SOAP. Кто‑то реализовал половину процессов. Кто‑то треть. Кто‑то сделал всё, но так, что лучше бы не делал. В итоге NDC — это тот же самый хрен, только сбоку и с логотипом авиакомпании. Те же команды PSS, та же логика, те же ограничения — просто теперь без GDS между вами. Это буквально: трактор, на который поставили сенсорный экран и наклейку “API‑READY”. Снаружи — красиво. Внутри — тот же дизель 1963 года, который заводится только если ударить по нему разводным ключом и прочитать молитву из мануала Sabre.

И самое смешное: многие компании, увидев NDC, подумали: «О! Наконец‑то нормальный API!» А потом через пару месяцев сидели над логами и спрашивали друг друга: «Ребята… а почему наш JSON вызывает команду AN15MAYYULNYC?» Потому что это не электрокар. Это всё тот же трактор. Просто теперь с USB‑портом.

И самое забавное — весь этот бардак, вся эта архитектура из телетайпов, динозавров и JSON‑обёрток — это ещё не весь цирк. Потому что чтобы вообще получить доступ ко всему этому великолепию, вам нужно не только заплатить денег (и денег немалых), но ещё и обзавестись личными знакомствами. Да‑да, всё как в 1960‑х, только теперь вместо виски и сигар — Zoom‑коллы и LinkedIn. Помните логику авиакомпаний? «Не нравится — иди пешком». Так вот, она распространяется и на партнёрства.

Формально процесс выглядит так:

1. Вы пишете в авиакомпанию или GDS: «Здравствуйте, мы хотим интегрироваться».

2. Они отвечают: «Спасибо за интерес, мы рассмотрим вашу заявку».

3. И дальше… тишина.

4. Недели.

5. Месяцы.

6. Иногда — кварталы.

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

И весь этот бардак с доступами касается не только авиакомпаний. В тревеле так устроено всё: отели, прокат машин, страховки, туроператоры — у всех одна и та же философия. Доступ стоит денег, процессы непрозрачные, документация выглядит как археологические раскопки, а без личных контактов вы будете ждать ответа бесконечно долго. Формально у всех есть «портал для партнёров», а по факту всё работает по принципу: «Если вам действительно надо — вы сами найдёте человека, который знает человека». И вот это становится сюрпризом для тех, кто думал, что тревел‑интеграции — это просто «подключиться к API».

И даже когда вы наконец выбили доступ, начинается следующий уровень ада — сертификация. Прежде чем вас пустят в продакшен, вы обязаны пройти набор тестовых сценариев, которые придуманы так, будто их писал человек, который никогда не видел свой же API. Часть сценариев противоречит документации, часть — реальности, часть — просто не работает, но вы всё равно должны «успешно пройти». И самое прекрасное: если что‑то падает на их стороне, вам скажут «мы не можем воспроизвести, попробуйте ещё раз». В итоге сертификация превращается в игру «угадай, что хотел сказать PSS», и только после этого вам торжественно выдают продакшен‑ключ, который тоже может не работать с первого раза.

После всех этих лет в тревеле — PSS, GDS, NDC, интеграции, стартапы, костыли, ночные дебаги — у нас накопилось столько опыта, что мы уже узнаём ошибки Sabre/Amadeus/Travelport по запаху. И всё это время мы строили системы для клиентов, под их процессы и их хотелки. Но когда дело доходило до собственных поездок, мы всё равно открывали десятки вкладок, сравнивали цены, ловили глюки на сайтах авиакомпаний и вручную собирали маршрут. В какой‑то момент это перестало просто раздражать — стало утомлять. Поэтому мы и полезли в эту авантюру: сделать сервис, который работает так, как нам самим удобно. Причём не просто сервис, а чатовый, где всё должно быть быстро, понятно и без шаманских танцев. То есть взять индустрию, которая живёт в 1960‑х, и заставить её выглядеть так, будто она родилась в эпоху мессенджеров — когда ты пишешь пару сообщений, система помнит историю, понимает контекст и собирает всё под тебя, без квеста «выживи среди тревел‑сервисов».

Первая попытка вообще была другой: мы делали приложение, где можно было самому собирать свой план поездки, раскладывать всё по дням, шарить друзьям, делиться с другими пользователями, смотреть чужие маршруты — такой тревел‑конструктор. И получалось, честно, довольно интересно. Но проект так и не дожил до релиза: он умер где‑то в наших внутренних тестах. Потому что чтобы такое приложение зажило, нужно сообщество — люди, которые будут создавать планы, делиться ими, вдохновлять других. А заставить кого‑то в наше время поставить новое приложение — задача, мягко говоря, неблагодарная. В итоге проект отправился в стол, к большой куче других идей, которые тоже «почти получилось, но нет».

А потом, спустя какое‑то время, мы сидели с одним типом, перебирали те самые пыльные проекты, и я показал ему один совсем древний прототип — настолько древний, что рядом с ним, кажется, действительно можно было найти кости динозавров. В том прототипе можно было искать самолёты прямо из Slack (у Slack, кстати, довольно мощная система темплейтов, хоть и выглядит как артефакт из музея интерфейсов). Тип за идею ухватился и предложил мутить стартап. Мы согласились, но только по‑честному: мы делаем продукт, а он приводит TMC — тревел‑менеджмент компанию с кучей корпоративных клиентов, которые возьмут наш сервис. Мы собрали MVP, сделали демо для большой британской компании — и они были в восторге. Но, как это обычно бывает с большими компаниями: им всё нравится, они эмоционально уже готовы кричать «заткнись и возьми мои деньги», но между этим моментом и реальными деньгами обычно проходит пара лет. Мы это понимали, нас это устраивало. А вот нашего самопровозглашённого CEO — нет. Он решил, что надо срочно звать инвесторов, чтобы денег было не много, но зато сегодня. Мы с этим не согласились, у него бомбануло, и на этом месте весь проект весело сдулся.

Потом, спустя какое‑то время, мы смотрели на весь этот весёлый хайп вокруг ChatGPT, который обещал, что вот‑вот «сделает весь тревел прямо в чате». Один друган, фанат ChatGPT до соплей, уверял меня, что всё уже почти готово, осталось подождать недельку. Я смеялся, он обижался. Но в какой‑то момент мы подумали: чаты — это действительно удобно. И главное — зачем изобретать свой чат, если у нас уже есть куча популярных чатов, и у всех есть API. Так что мы просто начали писать строчка за строчкой новый проект. Начали с отелей: во‑первых, проще получить доступ к инвентори, во‑вторых, на отелях можно отработать весь флоу без боли уровня авиабилетов.

Чаты выбрали самые популярные — WhatsApp, Telegram, Facebook, Instagram. И по дороге выяснилось интересное: чаты — это закрытые каналы, а значит, в них можно показывать цены, которые ниже публичных. Так называемые private rates. Если кто не знал: даже сам отель на своём сайте не может показывать цену ниже определённой, потому что у него есть соглашение о rate parity — обязательство держать публичную цену не ниже, чем на Booking/Expedia и прочих OTA. Но в закрытых каналах (чаты, корпоративные системы, закрытые клубы) это правило не действует, потому что цена не считается публичной. Поэтому в чатах можно показывать то, что на сайте отеля показывать нельзя.

И вот так, строчка за строчкой, у нас появилась первая живая версия. Почти 3 миллиона отелей по всему миру, включая приватные цены, которые нельзя показывать публично. Чат понимает больше 100 языков, так что можно писать хоть по‑испански, хоть по‑тайски, хоть по‑русски — ему всё равно. Вся система построена на Rust, без каких‑то там аффилейтных ссылок и редиректов: только хардкор, прямые запросы и одноразово генерируемые вспомогательные страницы. Потому что, как ни крути, людям нужно посмотреть фото отеля, а в популярных чатах функционал для этого… ну, скажем так, минималистичный. Платежи — через Stripe с 3DS, всё по‑взрослому. Отели поддерживают поиск, бронирование, отмену, и есть 24/7 поддержка по телефону (правда, только на английском — это уже от поставщика инвентори). И когда всё это заработало, мы решили добавить немного веселья — встроили реферальную систему прямо в чат. Каждый может получить свой реферальный линк и разослать друзьям, без регистрации, без кабинетов, без лишних движений.

Когда отели заработали стабильно, мы поняли, что это только разогрев. Дальше — авиабилеты, страховки, машины, трансферы. И вот тут чатовый формат начинает играть на полную: тревел‑флоу сам по себе диалоговый. Ты и так в жизни общаешься с друзьями, партнёром, коллегами: «когда летим?», «какой отель?», «а машину берём?», «а страховка нужна?». Мы просто перенесли этот естественный процесс в интерфейс, который уже существует — чат. Без форм, без табличек, без «заполните 12 полей, чтобы продолжить». Пара сообщений — и бот понимает, что тебе нужно: перелёт, отель, страховка, машина, трансфер. Он помнит историю, знает контекст, подсказывает, если что‑то забыто. И чем дальше мы шли, тем больше понимали: чат — это идеальный UI для тревела, потому что тревел — это цепочка шагов, а не одна большая форма.

Поэтому мы начали добавлять новые штуки. Сейчас в работе:

• билеты на ивенты — концерты, выставки, фестивали, всё в том же чате;

• планировщик поездок — можно собрать весь маршрут, а бот будет держать его в голове;

• проактивные напоминания — если попросить, бот сам будет напоминать о каждом следующем шаге: регистрация, выезд в аэропорт, чекин в отель, возврат машины;

• авиа‑обновления в реальном времени — как только мы договоримся с авиакомпаниями, бот сможет автоматически вносить изменения в бронирование при задержках и отменах, без твоего участия.

То есть идея простая: всё, что раньше требовало 10 сайтов, 20 вкладок и 3 нервных срыва — теперь живёт в одном диалоге.

После выбора комнаты система автоматически возвращает вас в чат — ничего специально нажимать или «возвращаться» не нужно. Дальше бот сам предложит забронировать выбранный вариант. Можно согласиться сразу, можно отложить — решение за вами. И да, это не демо и не тестовые данные: отели бронируются по‑настоящему, это реальный инвентори, который можно купить и использовать. Внутри чата уже существует что‑то вроде «корзины», просто она пока невидимая и очень простая. Сейчас туда можно положить только один отель. Если вам нужно несколько комнат, важно заранее сказать, сколько человек едет и сколько комнат требуется — тогда система подберёт корректные варианты и положит их в этот внутренний контекст. В будущем эта «корзина» станет полноценным центром вашей поездки: туда будут складываться отели, билеты, трансферы, ивенты — всё, что вы напланируете — и потом можно будет оформить всё одним бронированием. Если какой‑то оффер исчезнет, бэкенд автоматически подберёт замену, а бот просто сообщит об этом в чате. То есть это не просто фильтрация того, что нашёл провайдер. Это живой тревел‑флоу, который собирается прямо в чате и превращает вашу поездку в цельную историю, а не набор разрозненных действий.

Мы будем рады, если вы запустите текущий флоу, ткнёте в него пальцем и честно расскажете, что удобно, а что хочется мысленно заархивировать вместе с терминальными справочниками 1987 года. Нам не нужно отчитываться перед инвесторами, защищать роадмапы на совете директоров или согласовывать каждый релиз с продуктовым комитетом. Нас двое. Мы пилим это на свои, по вечерам и выходным, а единственная метрика, которая нас волнует — «работает ли оно у человека или он сейчас тихо пытается расколотить телефон об угол стола». Поэтому любая проблема о которой вы сообщите в чате летит напрямую в наш сервис емаил, без фильтров, прослоек и бюрократии. И да, мы будем переодически постить апдейты, честно рассказывать, какие новые фичи прикрутили, и не обещать чудес. Мы не можем переделать индустриальный зоопарк изнутри — там слишком много динозавров, и они плохо реагируют на рефакторинг. Вместо этого мы просто аккуратно драпируем его современным интерфейсом, прячем ASCII‑заклинания за обычным диалогом и делаем вид, что всё это работает на чистой магии, а не на десятилетиях корпоративного техдолга. Следите за публикациями, пробуйте, пишите, что бесит, а что, наоборот, зашло. Мы читаем, впитываем и по мере сил добавляем новые элементы.