# Я запустил телеграм-бота в день выхода статьи — и он умер через час

Пятница. Публикация. И тишина

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

Открыл диагностику: **сессия 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 чужая инстанция может забрать - **Сигнал админу при смерти**: не «тихо деградирую», а сообщение в течение минуты

---

Что в итоге

Бот восстановлен, сессия работает, дайджесты идут. Статья из первой части — тоже на месте и даже нашла первых читателей.

Самое ценное, что я вынес: **падение в день запуска — это не провал запуска, это первый стресс-тест, который ты не планировал**. Все эти защиту теперь проверены не в теории, а боем.

Если собираете своего бота — начните с чек-листа выше. Грабли уже насттопаны.

---

*Бот из истории: бот — дайджесты твоих каналов без воды