Подхват проекта — Telegram-бот
Заберём Telegram-бота, Mini App или внутреннего бота у предыдущей команды. Начинаем с аудита кода, Bot API, webhook, базы данных, очередей, оплат, интеграций, админки и серверных доступов. Дальше — стабилизация, поддержка или развитие по согласованной модели.
Что мы понимаем под подхватом
Работающий бот — это не только код. Это токен и права в BotFather, сервер и окружения, webhook или polling, база данных, очереди и фоновые задачи, платежи и подписки, интеграции с CRM, сайтом, 1С и внутренними системами, админка операторов, логи, мониторинг и алёрты. Подхват — это вернуть контроль над всем перечисленным.
Разбор репозитория, окружений и секретов. Аудит работы Bot API, обработки update и лимитов Telegram. Проверка базы, очередей, платежей, подписок, выдачи доступа и интеграций. Состояние сервера, релизов, мониторинга и бэкапов. Письменный отчёт с приоритезированными рисками. Передача токена, серверных доступов и артефактов с письменным актом. Дальше — поддержка или развитие по согласованной модели.
Точечная правка одной команды бота без аудита и без ответственности за релиз. Полная переработка концепции «нового бота» без разбора текущего. Работа без подтверждённых прав на токен, код и сервер. Сопровождение бота, который бизнесу проще закрыть и собрать заново.
Когда нужен подхват
Если совпали два-три пункта — пора смотреть, что на самом деле происходит с ботом.
Команда перестала отвечать или отвечает «через раз». Задачи открыты, релизов нет, бот работает «как есть».
Сообщения обрабатываются с заметной задержкой, периодически бот вообще не отвечает. Причину объяснить никто не может.
После очередной выкладки webhook перестаёт принимать update, Telegram отключает доставку или возвращает 5xx, ручное переключение становится регулярной операцией.
Часть оплат проходит со второй попытки, выдача доступа задержана, подписки не продлеваются, статусы заказов уезжают.
Массовые сообщения упираются в лимиты Telegram, пользователи получают дубли, часть аккаунтов получает rate-limit или блокируется.
Лиды не доезжают до CRM, заказы расходятся между ботом и 1С, сайт и бот показывают разные состояния, обмены падают молча.
Серверные ключи, доступ к базе или права в BotFather — на личном аккаунте прошлой команды. Восстановление владения — отдельный сюжет.
Прод горит, а воспроизвести деплой и выпустить фикс в нужный срок из доступных людей никто не может.
Кому не подойдёт
Называем заранее, чтобы не тратить ваше время и не вводить в заблуждение.
Если задача — собрать новый бот без разбора старого, это не подхват. Под такую задачу есть отдельная страница про разработку ботов.
Если у вас нет подтверждённых прав на токен бота, серверные доступы и код, и получить их хотя бы на чтение невозможно — мы не работаем.
Одна команда, одно сообщение, без аудита и без ответственности за выпуск — это та же история, которая привела в текущую ситуацию. Заходим минимум через аудит.
Иногда честный ответ — закрыть бота и собрать новый под актуальный бизнес-замысел. В таком случае подхват тратит ваши деньги впустую.
Что проверяем в первые дни
Сразу не лезем чинить. Сначала проходим по списку и фиксируем состояние, чтобы дальше работать с фактами, а не с предположениями.
Структура репозитория, активные ветки, расхождение прод-ветки и того, что фактически крутится на сервере. Где лежат env и секреты.
Как принимаются update, как обрабатываются ошибки, как ведёт себя бот под лимитами Telegram, как организован retry и идемпотентность.
Схема, миграции, консистентность, бэкапы и их фактическая восстанавливаемость. Что меняется руками через консоль, а что через миграции.
Как устроены отложенные задачи и рассылки, не блокируют ли они основной поток обработки сообщений, как обрабатываются ошибки и ретраи.
Какой провайдер, как реализована идемпотентность, как обрабатываются вебхуки, как происходит выдача и отзыв доступа, как ведётся учёт подписок.
Контракты и состояние интеграций, версионирование, обработка ошибок сторонних систем, наличие retry и алёртов на провалы.
Кто и что может делать через админку, есть ли роли и аудит действий, как заводятся новые операторы, как закрывается доступ бывшим.
Что и куда пишется, есть ли алёрты на падения и просадки, как обрабатываются необработанные исключения, что видно в случае инцидента.
Что вы получаете после аудита
Артефакты остаются у вас даже в случае, если дальше работаете не с нами.
Письменный разбор кода, Bot API, базы, очередей, платежей, интеграций, админки и серверных доступов с приоритезированными находками.
Таблица: риск, вероятность, влияние, приоритет, ответственный. Разнесена по слоям, чтобы видеть, где горит первым.
Что и в каком порядке забрать у прошлой команды: токен и права в BotFather, серверные доступы, база, env, CI/CD, аналитика, интеграции.
Список работ после старта подхвата с оценкой трудоёмкости. Цель — снять острые риски и вернуть управление в проект.
Сгруппирован по приоритету: что в ближайший релиз, что в следующий, что в техдолг.
Куда двигать релизный процесс, что закрывать алёртами в первую очередь и как должна выглядеть рабочая схема бэкапов и восстановления.
Поддерживать текущую архитектуру, стабилизировать, частично переписать или переписывать полностью — обоснованное решение по итогам аудита.
Первый месяц
В первый месяц не «переделываем под себя». Снимаем острые риски, чтобы релизы и работа бота перестали быть лотереей.
Фиксируем версии тулчейна и зависимостей, переменные окружения и скрипты выкладки. Деплой должен получаться у любого инженера команды, а не у одного человека.
Переоформляем секреты, переносим env в безопасное хранилище, закрываем токены в коде, выдаём роли и доступы по принципу наименьших привилегий.
Приводим работу с Bot API к предсказуемому состоянию: корректная обработка update, ретраи, идемпотентность, поведение под лимитами Telegram, понятные ошибки в логах.
Проходим сценарии оплат и подписок, чиним идемпотентность, вебхуки платёжных провайдеров и логику выдачи и отзыва доступа.
Делаем фактическую проверку восстановления из бэкапа, наводим порядок с миграциями, прекращаем менять схему руками через консоль.
Логирование с контекстом, ключевые метрики по обработке сообщений и платежам, алёрты на падения webhook, очередей и сторонних API.
Короткие регламенты по выкладке, фикс-релизам, ручным операциям в админке и действиям при инцидентах. Без «знания в голове одного человека».
Чего не ломаем при переходе
Эти ограничения мы соблюдаем сами, чтобы переход был предсказуемым, а пользователи бота — не пострадали.
Смена токена обнуляет интеграции и логику авторизации. Идём на это только осознанно, с планом миграции и обновлением всех зависимых сервисов.
Переключение webhook или возврат к polling делается по согласованному окну с готовым откатом. Без «попробуем и посмотрим, что будет».
Любая рассылка проходит через проверку сегмента, лимитов Telegram и нагрузочного поведения. Иначе блокировки и потеря пользователей.
Изменения в платёжных и подписочных потоках обкатываются на тестовом боте и тестовых счетах. На прод выходят только после подтверждённого сценария.
Доступ закрывается только по вашему решению и после письменного акта передачи. До этого момента идёт параллельная работа в режиме чтения.
Стек и типовые конфигурации
Заходим в проекты на стеках, с которыми работают наши команды. Если вашего нет в списке — напишите, скажем честно, готовы ли мы подхватить или порекомендуем тех, кто делает это лучше.
aiogram, pyTelegramBotAPI, FastAPI и Django как backend.
grammY, Telegraf, NestJS и Express как backend.
Боты и backend на Laravel или Symfony, где это уместно.
React, Next.js, Vue с Telegram Web Apps SDK и валидацией initData.
PostgreSQL, MySQL, Redis, очереди на Redis или RabbitMQ.
Docker, GitLab CI, GitHub Actions, VPS и cloud, nginx, мониторинг.
Частые проблемы
Это не «страшилки». Это то, что регулярно встречается в ботах, приходящих на подхват. Владелец продукта обычно об этом не знает.
Токен бота, ключи платёжных провайдеров и сторонних API закоммичены в код. После увольнения сотрудника всё ещё в истории.
URL webhook прописан в чьей-то консоли, скрипт переустановки отсутствует, при смене сервера всё восстанавливается «по памяти».
Схема базы менялась руками через консоль, миграций нет или они частичные. Поднять второй стенд по образцу прода невозможно.
Массовая рассылка выполняется в том же процессе, что и обработка сообщений. На время рассылки бот заметно тормозит или зависает.
Повторный вебхук от платёжного провайдера приводит к двойной выдаче или двойному списанию. Возвраты и спорные ситуации разбираются вручную.
При временном падении CRM, 1С или сайта запросы теряются, события до целевой системы не доезжают. Алёрта об этом нет.
Все операторы видят и могут всё. Кто и когда поменял статус заказа, выдал доступ или удалил пользователя — восстановить нельзя.
В логах либо ничего, либо «всё подряд». Контекст конкретного сообщения или пользователя не вытащить, инциденты разбираются часами.
Один VPS, без снапшотов и без проверенных бэкапов базы. Падение сервера — это потеря данных и истории взаимодействия.
Фронт Mini App и серверная часть писались разными подходами или командами. Часть бизнес-правил дублируется, часть расходится, сложно сказать, какая «настоящая».
Чек-лист передачи доступов
Часть пунктов выглядит банально, но именно они срывают подхват бота чаще, чем сложный код.
Типы Telegram-проектов
Если ваш случай — в списке ниже, опишите его в заявке. Обсуждаем по существу: что досталось, какие риски, с чего начнём.
Заявки, статусы, уведомления клиентам.
Платёжные провайдеры, чеки, возвраты.
Тарифы, продления, выдача и отзыв доступа.
Web-приложение внутри Telegram с авторизацией через initData.
Сбор контактов, квалификация, передача в CRM.
Очередь обращений, операторы, история диалогов.
Доступ к корпоративным системам, уведомления, отчёты.
Двусторонний обмен с amoCRM, Bitrix24 или собственной CRM.
Сегменты, лимиты, отписки, антиблокировки.
Профиль пользователя, история, документы, операции.
Шире Telegram-бота
Если нужно забрать не только бота, но и backend, сайт, CRM, мобильное приложение или внутреннюю админку — начните с общей страницы подхвата проекта.
Если рядом с ботом есть смежная часть, у нас уже есть отдельные страницы про подхват Python-проекта и подхват интеграций и API.
Если вы не подхватываете старого бота, а хотите разработать нового, посмотрите страницу про разработку Telegram-ботов.
FAQ
С короткой стартовой сессии и заявки на аудит. Обсуждаем, что делает бот, какой у него стек, какие доступы и аккаунты уже на вашей стороне, что произошло с прошлой командой. По запросу подписываем NDA. Дальше — аудит кода, Bot API, webhook, базы, очередей, платежей, интеграций и серверных доступов. Условия подхвата обсуждаем после отчёта.
Да, если у выбранного сценария есть чёткие границы: понятная команда или кнопка, отдельный обработчик, идентифицируемые состояния пользователя. Аудит в этом случае фокусируется на коде, состояниях, очередях и обработчиках именно этой ветки бота. Контракт с остальным кодом, БД и интеграциями описываем отдельно, чтобы было понятно, какие выводы возможны без полного аудита, а какие — нет.
BotFather привязан к Telegram-аккаунту владельца бота. Если бот был создан с личного аккаунта прошлой команды, владение восстанавливается через передачу прав в BotFather или через перевыпуск бота с переносом данных. На аудите фиксируем текущее состояние и предлагаем безопасный план передачи, чтобы пользователи не получили «новый» бот с потерей истории.
Сначала фиксируем, что доступно: токен, сервер, база, env, логи. На основе работающей системы реконструируем поведение бота, описываем сценарии и контракты с внешними API. Дальше принимаем решение: восстанавливать кодовую базу по факту, частично переписывать или собирать заново с переносом данных.
Да. Заходим в проекты на aiogram, pyTelegramBotAPI и связки с FastAPI или Django. Mini App-фронт под Telegram Web Apps SDK при необходимости разбираем отдельно.
Да. Заходим в проекты на grammY и Telegraf, в том числе в связке с NestJS или Express. Mini App-фронт на React, Next.js или Vue с Telegram Web Apps SDK подхватываем вместе с backend.
Да. Подхват Mini App покрывает и фронтенд, и серверную часть: авторизация через initData, валидация подписи, контракты с backend, платежи, выдача доступа. Если бот и Mini App написаны разными командами, аудит честно покажет, где границы расходятся.
На аудите смотрим обе стороны. Часто баги бота — следствие нестабильного backend, неконсистентных контрактов или сломанных вебхуков от CRM. В отчёте отделяем бота от смежных систем и предлагаем план по каждой части. Backend и интеграции можем взять в подхват вместе с ботом или оставить вашей команде.
До любых изменений снимаем карту webhooks, очередей и сценариев: какие команды и кнопки используют пользователи, как обрабатываются платежи Telegram Payments и внешние эквайринги, какие состояния хранятся в базе. Перевыпуск токена и переключение webhook идут отдельным окном с согласованием. Сценарии диалогов и состояния пользователей не трогаем «по дороге» в рамках срочной стабилизации.
По итогам подхвата готовим короткий чек-лист для внутреннего разработчика: владение в BotFather, токен и его ротация, webhook-эндпоинт и обработчики, схема состояний пользователей, описание команд и кнопок, очереди и фоновые задачи, обработка платежей, регламент изменений. Документируем нетривиальные сценарии и состояния, чтобы новый разработчик понимал, почему диалог устроен именно так. Можем сопровождать первые недели его работы.
Заказать аудит Telegram-бота
Опишите, что делает бот, на каком стеке он написан, какие доступы есть и что произошло с предыдущей командой. Вернёмся с конкретикой и предложим стартовую сессию.
Подхват Telegram-бота
Поля помечены под подхват бота: что за продукт, какой стек, что произошло, какие доступы есть.
Заявка придёт на hi@khaiam.ru. Можно написать сразу в Telegram .
Заявка отправлена
Если задача срочная, можно сразу написать в Telegram .