Бот для Telegram на Python

Бот на Python — нормальный выбор, когда нужна своя логика, интеграции с CRM и учётными системами и полный контроль над данными. Конструктор закрывает MVP за дни; код оправдан, когда сценарий перерос меню из кнопок или когда тариф платформы растёт быстрее выручки. Ниже — практичный разбор по официальному Telegram Bot API: как принимать обновления, где теряются заявки, как собрать MVP «заявка + алерт» и что проверить перед рекламой.

Два способа получать обновления

Способы взаимоисключающие: пока активен webhook, `getUpdates` не работает. Статус смотрите через `getWebhookInfo`, снятие — `deleteWebhook`. Непрочитанные апдейты на стороне Telegram не хранятся дольше 24 часов — упавший сервер в выходные может означать потерянные заявки.

Для webhook в документации указаны порты 443, 80, 88, 8443. Сертификат должен быть валидным; self-signed допускается только при загрузке публичного ключа через `setWebhook`. На практике проще терминировать TLS на nginx и проксировать на локальный порт приложения.

Библиотеки: aiogram и python-telegram-bot

Обе обёртки закрывают 95% задач бизнес-бота:

• - python-telegram-bot — зрелая экосистема, много примеров, удобные `ConversationHandler` и job queue;
• - aiogram 3.x — асинхронный стиль, FSM из коробки, удобен при высокой нагрузке и множестве интеграций.

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

Каркас проекта

Минимальная структура, которую не придётся переписывать через месяц:

app/
  main.py          # точка входа, выбор polling/webhook
  config.py        # настройки из env
  handlers/        # команды и callback
  services/        # CRM, оплаты, LLM
  storage/         # SQLite/Redis для FSM
  texts/           # утверждённые формулировки

Токен бота — секрет. Он даёт полный контроль над ботом. Храните его в переменных окружения, не коммитьте в git, не отправляйте в общий чат. При утечке — перевыпуск через BotFather и ротация на сервере.

MVP: заявка за четыре шага

Типовой сценарий, который окупается быстрее «универсального ассистента»:

/start или deep-link
 → меню из 3–5 пунктов (FAQ / заявка / контакты)
 → ветка заявки: услуга → город → срок → телефон
 → sendMessage менеджеру с chat_id пользователя
 → пользователю: «приняли, ответим в …»

Технически:

1. 1. `/start` — приветствие и `ReplyKeyboardMarkup` или `InlineKeyboardMarkup`.
2. 2. FSM — храните шаг диалога в Redis или SQLite, не в глобальных переменных (иначе при двух воркерах состояние поплывёт).
3. 3. `answerCallbackQuery` — обязателен на inline-кнопки, иначе клиент видит «часики».
4. 4. Контакт — можно запросить кнопкой `request_contact`, но многие не нажимают; дублируйте текстовый ввод с валидацией.

Для маркетинговых deep-link параметров используйте payload в `/start`: `t.me/YourBot?start=utm_campaign_march`. Парсите аргумент в хендлере и сохраняйте в заявке — это базовая атрибуция без отдельной аналитики.

Лимиты API, которые ломают прод

Бот не может написать пользователю первым. Это не баг Python — это правило платформы. Любая «база для рассылок» через Bot API невозможна; аудитория набирается входящим трафиком.

Интеграции без переусложнения

Не подключайте LLM к прайсу и срокам: цены и юридические формулировки остаются в сценарии или в базе, которую редактирует владелец услуги.

Деплой и наблюдаемость

Polling: systemd-unit или Docker с `restart=always`, один инстанс (два процесса с polling на одном токене — гонка апдейтов).

Webhook: uvicorn/gunicorn за nginx, health-check на `/health`, логирование `update_id` для идемпотентности.

Минимальные алерты:

• - процесс не отвечает 2–3 минуты;
• - ошибка отправки менеджеру;
• - рост `429` подряд;
• - webhook вернул не `200` (Telegram повторяет доставку, но копится очередь).

Логи храните без полных телефонов в открытом виде, если это не согласовано политикой ПДн.

Тестирование перед трафиком

Чеклист на 30 минут:

• - [ ] `/start` с payload и без;
• - [ ] все кнопки меню и «назад»;
• - [ ] заявка доходит в чат менеджера с `chat_id` клиента;
• - [ ] ветка «не понял» ведёт к человеку;
• - [ ] перезапуск процесса не теряет FSM (если обещали сохранение);
• - [ ] `deleteWebhook` + polling на staging, обратно webhook на prod.

Прогоните 20 реальных вопросов клиентов — не «тестовых», а из переписки менеджера.

Частые ошибки

• - Два способа приёма апдейтов одновременно — «бот молчит» без явной ошибки.
• - Секреты в репозитории — компрометация за минуты сканера.
• - FSM в памяти процесса — пользователь «застревает» после деплоя.
• - Нет `answerCallbackQuery` — ощущение «сломалось».
• - Меню на 15 пунктов — никто не доходит до заявки.
• - ИИ без базы — выдуманные цены и репутационные риски.

Частые вопросы

Polling или webhook для малого бизнеса?

Для MVP допустим polling на недорогом VPS. Когда бот связан с рекламой и SLA по заявкам — webhook, мониторинг и один ответственный за инциденты.

Нужна ли база данных?

Для простого FAQ — часто нет. Для заявки, FSM, статусов заказа и интеграций — да, хотя бы SQLite или Redis.

Можно ли без Python?

Да, через конструктор чат-бота без кода. Python — когда нужны ваши API, нестандартная логика и предсказуемая стоимость при росте.

Как связать бота с сайтом?

Кнопка «Написать в Telegram», deep-link с UTM, виджет с QR. На сайте держите форму дублем — бот не должен быть единственной точкой входа.

Гео: один код — разные рынки

• - Часовые пояса. Клиент из Владивостока пишет, когда в Москве ночь. В тексте бота укажите реальный режим ответа менеджера, не «24/7», если это не так.
• - Региональные офферы. Deep-link `start=spb_promo` и `start=kazan_promo` позволяют одному боту вести разные landing-ветки без отдельных токенов.
• - Удалённая разработка. Бот не привязан к городу заказчика: тот же стек работает для сайта и бота под Уфу и для проекта в Новосибирске — меняются тексты и CRM, не архитектура.
• - ПДн в РФ. Телефон и имя — персональные данные: согласие, политика, ограничение доступа к логам.

Чеклист продакшена

• - [ ] Выбран один способ приёма апдейтов, webhook проверен через `getWebhookInfo`
• - [ ] Токен только в env, есть порядок ротации
• - [ ] MVP: меню, FAQ, заявка, эскалация, алерт менеджеру
• - [ ] Обработка `429`, лимиты длины сообщений учтены
• - [ ] FSM переживает рестарт
• - [ ] Дублирующий канал заявки (форма на сайте)
• - [ ] Согласие на обработку ПДн на шаге контакта

Что сделать дальше

1. 1. Зафиксировать сценарий заявки на одной странице.
2. 2. Собрать MVP на polling, прогнать 20 реальных вопросов.
3. 3. Перевести на webhook, включить алерты.
4. 4. Подключить один источник трафика с разметкой `start=`.

Отдельно зафиксируйте версию API в конфиге: Telegram периодически добавляет поля в `Update` и типы кнопок. Обновление библиотеки без прогона регресса по сценарию — частая причина «внезапно перестали работать callback».

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