Всем привет! Меня зовут Олег Балбеков, я из команды Evrone. В прошлых сериях вы читали мои статьи о том, как я создал «братишку», и о том, как я завайбкодил сервис за неделю. Сегодня же я хочу рассказать вам о настоящем инженерном приключении, которое со мной произошло в процессе построения сервиса Mimirjotun.ru.
Мы с коллегами делаем цифровые продукты уже семнадцать лет. За эти годы я выучил наизусть классический набор инженерных рисков — упадёт сервер, отвалится канал к ДЦ, крешнется хард, потеряются бэкапы — и набор готовых решений под них. Это азбука, которая казалась исчерпывающей.
Но 2026 год преподнёс мне сюрприз. Создавая свой ИИ-стартап, я понял, что мир изменился, и в нём появился целый новый класс архитектурных рисков — таких, о которых в моей азбуке не было ни строчки. И ровно об эти новые риски я и пошёл спотыкаться.
Итак, усаживайтесь поудобнее и слушайте историю — историю про путешествия… путешествия нашей инфраструктуры и о реалиях разработки современных ИИ-стартапов из Москвы.
Что вообще за сервис 🛠️
Идея простая: Я создал AI-помощник для редакторов Telegram-каналов. Подключаешь свои источники — другие каналы и RSS-ленты — а сервис сам читает, скорит посты по «горячести» и присылает тебе в личку готовый черновик: рерайт текста плюс сгенерированная картинка. Остаётся только нажать «Опубликовать» или разрешить автопостинг в твой канал.
Внутри — классический современный стек: Rails + Sidekiq + Postgres + Redis на бэкенде, Claude Sonnet для текста, fal-ai Flux для картинок, MTProto для чтения каналов. Чистый ИИ-стартап нового поколения. Завайбкодил MVP за неделю, дошёл до деплоя.
Вот тут и начались приключения…
Приключение первое: лендинг едет из Амстердама в Москву ✈️
По старой доброй привычке поднимаю прототип на DigitalOcean. Почему там? Потому что удобно, потому что всю жизнь так делали, потому что аккаунт давно создан, карточка привязана, дроплет поднимается за минуту. Амстердам, базовый дроплет за двадцать баксов, docker-compose.
Гордо шлю жене ссылку: «Зайди, зацени какую я штуку запилил!»
Жена пишет: «У меня белая страница».
Постой. Открываю с ноута — работает. С телефона — работает. Прошу попробовать с VPN. Включает — заходит. Выключает — белая страница.
И вот тут я хлопаю себя по лбу. Конечно же. Из России DigitalOcean доступен не у всех провайдеров — много подсетей заблокировано. У одних провайдеров открывается, у других — нет. Из дома на МГТС — не открывается. То есть половина моих потенциальных пользователей просто не увидит мой стартап.
Раньше как было? Запилил штуку, развернул где удобно — и работает. Где удобно, там и хостится. Теперь — нет. Теперь от того, где физически крутится твой VPS, зависит, увидит ли его пользователь.
Решение: переезжаю на Timeweb. Российский хостинг, российский IP, доступен всем без исключения. Переношу всю инфру — PostgreSQL, Redis, MinIO, nginx, certbot — через docker-compose, переключаю DNS, жду переделегирования домена. Сайт открывается из дома. Ура.
И знаете что? Это даже хорошо, что я споткнулся об эти грабли сразу, на этапе MVP. Потому что очень скоро мне делать биллинг, подключать платёжные системы, хранить персональные данные пользователей. А для всего этого хостинг в России — это не «опционально, если очень хочется», это базовое требование. Так что переезд, который я воспринял как вынужденный, оказался ровно тем, что мне и так пришлось бы сделать через месяц-два. Просто «судьба» меня деликатно подтолкнула в нужном направлении.
Приключение второе: ИИ-стартап без ИИ 🤖
Деплою на Timeweb. Настройки те же. Запускаю первый прогон скоринга. Sidekiq берёт job из очереди, вызывает Claude API…
HTTP 403 Forbidden
Access to Anthropic models is not allowed from unsupported
countries, regions, or territories.
И вот тут я второй раз хлопаю себя по лбу. Anthropic не работает с российскими IP. Это широко известный факт. Я это знал. Я об этом сто раз читал. Но когда строил архитектуру — почему-то держал в голове только сторону «как сделать, чтобы пользователи могли заходить», и совершенно упустил из виду сторону «а откуда мой сервер будет ходить наружу».
Хе-хе, ну то есть, я ИИ-стартап, я переехал на российский хостинг, чтобы пользователи могли заходить, и тут же сам себе закрыл доступ к API, на котором держится половина продукта. Без ИИ я не существую.
Океееей, поднимаю снова дроплет на DO Amsterdam — но уже не как фронт для пользователей, а как outbound-proxy для тех сервисов, куда из России не дотянуться.
Между двумя серверами поднимаю Tailscale — overlay-сеть на WireGuard, которая создаёт между ними приватный канал через DERP-релеи. Никакие фильтры в эту трубу не лезут, потому что снаружи это просто шифрованный UDP-трафик.
На DO ставлю tinyproxy, который слушает на Tailscale-IP.
На Rails-сервере в Timeweb настраиваю переменные окружения так, чтобы всё, что идёт к Anthropic, летело через туннель — а всё, что внутри (база, Redis, MinIO, fal.ai), ходило напрямую. Для них наш Rails выглядит как запрос из Амстердама, для всех остальных — никаких лишних хопов.
Прогон отрабатывает чисто. Стартап снова стартап.
Кстати, этот эпизод хорошо подсветил один из тех самых «рисков с другой стороны», о которых я говорил во вступлении. Доступ к ИИ-API могут отключить совершенно внезапно и без объяснений. И если у вас на этом API держится продукт — у вас не будет ни плана Б, ни даже двух часов на то, чтобы переключиться. Поэтому: заводите альтернативные аккаунты у того же провайдера заранее, держите ключи нескольких разных моделей и провайдеров наготове, проектируйте код так, чтобы провайдер модели был легко переключаемым. Океееей, урок усвоен!
Приключение третье: тестируем гипотезу про Telegram из России 📡
Хорошо. Сервис на российском хостинге, ИИ через прокси работает. Осталось наладить чтение Telegram-каналов через MTProto.
И тут начинается интересное… Конечно же я знаю о том, что в данный момент Telegram в опале, у него «приключения»… Но я всё же думал, что Telegram-инфраструктура с российского хостинга должна всё же работать. Почему я так подумал? Потому что Telegram-боты у людей в России массово работают, личные клиенты подключаются, всё живёт. Логично было предположить, что и серверная сторона MTProto будет вести себя так же.
Возможно, вы знакомы со мной как с человеком, который продвигает Ruby в России — мы создали конференцию RubyRussia. Поэтому мне, конечно же, было интересно поднять работу с Telegram на основе самого популярного ruby gem’а — tdlib-ruby. Окей, поднял, настроил, сервис начал получать апдейты, на радостях даже подумал — ну вот, тут-то всё в порядке.
А потом начал замечать странное.
То коннект отваливается посреди сессии. То дата-центры Telegram внезапно перестают отвечать. То TDLib ругается на таймауты. То всё стабильно работает час, а потом резко всё умирает на десять минут. Стал собирать метрики — картина невесёлая: с российского IP MTProto-трафик где-то проходит, а где-то режется по непредсказуемой логике. На одном сервачке — всё ок, подключил проксик с другого — флапает каждые двадцать минут. Никакой стабильности. Сидеть и гадать, повезёт ли тебе сегодня с маршрутом, — это не то, на чём строится продакшен.
Гипотеза провалена. Решение — выносить всю Telegram-логику туда, где MTProto работает свободно. То есть обратно на DO Amsterdam, который у нас уже стоит как outbound-узел.
Заодно решаю ещё одну проблему, которая всплыла параллельно. tdlib-ruby оказался настолько неактуальной обвязкой, что 33% постов в каналах терялись как MessageContent::Unsupported. Истории, платные реакции, мини-приложения, новые типы медиа — всё, что Telegram добавил за последние три года, просто не парсилось. Плюс TDLib возвращает значительно заниженные view-counters не-членам канала — это в хлам ломало мой скоринг «горячести» постов.
Поэтому переезжаю не просто на другой сервер, а сразу на другую библиотеку — Telethon на Python. Создаю отдельный микросервис mimir-tg на FastAPI:
-
отдельный git-репозиторий, отдельный deploy lifecycle
-
живёт на DO Amsterdam, ходит к Telegram напрямую
-
поллит каналы каждые 5 минут
-
пишет посты прямо в Postgres на Timeweb через Tailscale (
asyncpg) -
раздаёт метрики рельсе через REST API
Rails теперь полностью не знает про MTProto. Просто ходит к Python-сервису через Tailscale за метриками. Сам Python-сервис ходит к Telegram прямо из Амстердама — никаких прокси в пути, всё чисто и предсказуемо.
Попутный бонус: микросервисы теперь деплоятся независимо. Когда я меняю код Rails, Python-листенер не перезапускается, Telegram-сессия не пересоздаётся, пропусков опроса каналов нет. То, что начиналось как вынужденный обходной манёвр, превратилось в нормальную сервисную декомпозицию.
Что получилось в итоге 🏗️
Конечная архитектура простая, если описать её одной фразой: два сервера, между ними Tailscale-туннель, разделение труда по «гражданству».
Российский сервер на Timeweb: смотрит на пользователей, держит веб, базу, очереди, объектное хранилище. Всё, где есть взаимодействие с пользователем и его данными — здесь.
Голландский сервер на DO Amsterdam: ходит туда, куда из России не пускают. На нём живёт outbound-proxy для Claude API и микросервис на Telethon, который читает Telegram-каналы напрямую.
Tailscale между ними: приватный шифрованный канал, по которому ходят сервис-сервисные запросы. Никакого публичного интернета между нашими узлами нет.
Всё в бете. На сильных нагрузках пока не тестилось — у меня сейчас десятки живых пользователей, но не сотни и не тысячи. Базовая конструкция уже доказала, что держится: tinyproxy крутится без перезапусков, Tailscale ни разу не падал, Telethon-сервис стабильно пишет в базу через туннель.
Урок, который я выучил 🎓
Вот к чему я хочу подвести.
Раньше — то есть лет десять назад — когда я строил продукты прям своими руками, был один важный, но как будто незаметный «компонент по умолчанию»: интернет. Он был просто фоном. Сервер можно было поставить где угодно, ходить откуда угодно куда угодно, и архитектурно это вообще не было решением — это была атмосфера, воздух. Сначала ты делал продукт, потом думал, где его захостить — и второе было копеечным вопросом удобства.
Сейчас это так больше не работает. И, что особенно обидно, это не работает не громко и заметно, а тихо и в самых неожиданных местах. Тебе никто не присылает уведомление: «дружище, вот тебе список всех мест, куда твой сервер не сможет дотянуться, и список всех IP-диапазонов, до которых не дотянутся твои пользователи». Ты узнаёшь это эмпирически, по белой странице у жены и по 403-й ошибке в логах Sidekiq.
Поэтому если вы сегодня собираетесь делать ИИ-стартап для российского рынка — вот короткий чек-лист, который я для себя сформулировал постфактум. Хорошо бы пройтись по нему до того, как вы начнёте писать код:
-
Где хостить фронт? Если ваша аудитория — Россия, хостинг должен быть в России. Не потому что так модно, а потому что половина зарубежных хостеров блокируется у части провайдеров, а ещё впереди закон о персональных данных (152-ФЗ) и платёжки, с запретом о трансграничной передаче персональных данных.
-
Куда ходит ваш бэкенд? Составьте список всех внешних API, к которым обращается сервер: ИИ-провайдеры, платёжки, почтовые сервисы, аналитика, мессенджеры. Для каждого проверьте, доступен ли он с российского IP. Для тех, кто недоступен — заранее планируйте outbound-туннель через зарубежный узел.
-
Один провайдер ИИ — это bus factor. Заведите аккаунты у нескольких, держите ключи разных моделей наготове, проектируйте абстракцию провайдера в коде. Внезапный бан вашего основного аккаунта — это сценарий не «если», а «когда».
-
Tailscale ваш друг. Сшивать разнесённые по разным юрисдикциям серверы через публичный интернет — больно и хрупко. Через overlay-сеть — просто и надёжно. WireGuard под капотом, ноль конфигов, заводится за десять минут.
-
Не храните в ИИ-провайдере чувствительные данные. Это, в общем-то, общее правило, но в наших реалиях оно усиливается: если завтра вас неожиданно отключат, вы даже не сможете попросить «дайте экспорт».
Современный ИИ-стартап из России — это не «такой же, как раньше, плюс пара нюансов». Это другая дисциплина. У вашей архитектуры теперь есть геополитика, и игнорировать её — значит проектировать не то, что будет работать в реальности, а то, что работало бы в идеальном мире десятилетней давности.
Я этот урок выучил на собственной шкуре, за неделю беготни между двумя серверами, через белую страницу у жены, через 403 в логах и через флапающий MTProto. Вы теперь — за пять минут чтения этого поста.
Берите, пользуйтесь, экономьте себе неделю. Стройте, делайте, запускайте. Только держите «карту» в голове 🗺️
Олег Балбеков, @obalbekov
Автор: Lxx
