# Я запустил телеграм-бота в день выхода статьи — и он умер через час
Пятница. Публикация. И тишина
В пятницу я выложил статью о своём боте-дайджесте — и почти одновременно выкатил большое обновление на сервер. Через час понял, что что-то не так: подписчиков нет, сообщений нет.
Открыл диагностику: **сессия Telegram, через которую бот читает каналы, мертва. Навсегда.** Telegram увидел, что один и тот же ключ авторизации используется с двух разных IP одновременно, и аннулировал его. Это правильная защита — так Telegram спасает аккаунты от угона. Мой случай был ложным срабатыванием, но Telegram не знает, чей ключ «настоящий».
Что случилось по минутам
**16:40** — выкатил обновление на сервер. Контейнер пересобрался, бот перезапустился.
**16:44** — Telethon (клиент, который читает каналы) подключился. Всё выглядело нормально.
**~17:00** — первая волна юзеров с статьи. Бот отвечает, дайджесты собираются.
**21:07** — диагностика показывает: сессия парсинга мертва. Причина — «ключ использовался с двух IP одновременно». Вероятный сценарий: во время пересборки старый контейнер ещё держал соединение, пока новый подключался — Telegram увидел два IP у одного ключа и убил его.
**21:07–09:00** — бот работал, но не мог читать каналы. Дайджесты встали. Я узнал о проблеме не сразу — а это и есть главная ошибка.
5 уроков, которые я вынес
1. Никогда не подключайся к сессии с двух машин
Самая дорогая ошибка: тестовые скрипты на домашнем компе с той же сессией, пока продакшен работает в облаке. Теперь правило: production-сессия живёт только в одном месте.
2. Заводи «аренду» на сессию
Теперь перед каждым подключением бот захватывает lease — запись «этот IP держит сессию с такого-то времени», обновляемую раз в минуту. Если чужой живой lease мешает подключению — бот ждёт его освобождения, а не врубается параллельно. Двойной IP стал невозможен по построению.
3. Ставь предохранитель на штормы
Первая реакция на мёртвую сессию была неправильной: бот десятки раз подряд пытался переподключиться, Telegram это видело — и процесс упал целиком. Теперь при повторяющейся фатальной ошибке бот уходит в паузу на 5 минут и не мучает API.
4. FloodWait — это инструкция, а не враг
Когда Telegram говорит «подожди 30 секунд» — бот теперь ждёт ровно 30 секунд и повторяет один раз. Раньше он мог вернуться раньше и раззадорить лимиты.
5. Мгновенный сигнал админу
Раньше о смерти сессии я узнавал через 12 часов — из отсутствия дайджестов. Теперь при фатальной ошибке бот сам пишет мне в течение минуты: что умерло, почему, и как чинить.
---
Чек-лист отказоустойчивости для своего бота
Забирайте, если собираете своего Telegram-агента:
- **Минимальный интервал между запросами к Telegram** (0.75 с) — пачки каналов не бьют по аккаунту залпом - **FloodWait = пауза ровно по сроку Telegram + одна повторная попытка**, повторный флуд — канал пропускается без мучений - **Предохранитель**: повторяющаяся фатальная ошибка → пауза 5 минут, а не шторм реконнектов - **Lease на сессию**: двойной IP невозможен технически - **Heartbeat**: бот подтверждает «я жив» каждую минуту; протухший lease чужая инстанция может забрать - **Сигнал админу при смерти**: не «тихо деградирую», а сообщение в течение минуты
---
Что в итоге
Бот восстановлен, сессия работает, дайджесты идут. Статья из первой части — тоже на месте и даже нашла первых читателей.
Самое ценное, что я вынес: **падение в день запуска — это не провал запуска, это первый стресс-тест, который ты не планировал**. Все эти защиту теперь проверены не в теории, а боем.
Если собираете своего бота — начните с чек-листа выше. Грабли уже насттопаны.
---
*Бот из истории: бот — дайджесты твоих каналов без воды