Боты на VPS — systemd, вотчдоги и fail2ban без сюрпризов

У меня на серверах крутится десяток с лишним ботов — своих и клиентских. Правило, выстраданное практикой: бот, запущенный «в screen на всякий случай», умрёт в самый неудобный момент. Всё, что должно жить, живёт под systemd.

Минимальный юнит

Ничего сложного: юнит-файл с Restart=always, паузой перед рестартом и логами в journald. Упал — поднялся. Сервер перезагрузился — сервис поднялся сам, потому что enabled. Это база, которая закрывает 90% проблем «бот молчит».

Оставшиеся 10% — интереснее: процесс жив, но завис. Снаружи всё зелёное, внутри — ничего не работает. Для таких случаев поверх systemd у меня вотчдог: раз в несколько минут проверяет не «жив ли процесс», а «отвечает ли бот на команду». Не ответил дважды — рестарт и сообщение мне в Telegram.

Грабли, на которые наступил

ReadTimeout в логах — не всегда беда. VK-бот одной клиентской студии регулярно пишет таймауты в лог. Первое время я дёргался и лез чинить. Оказалось — штатная икота long-polling, бот сам переподключается. Вывод: прежде чем чинить «ошибку», проверь, а сломано ли что-то для пользователя.

fail2ban банит и хозяина. Опечатался в пароле пару раз с нестабильного IP — и SSH молча закрылся: «Connection closed by port 22». Выглядит как падение сервера, на деле — ты сам в бан-листе. Лечится через веб-консоль провайдера: разбанить IP и почистить набор правил в nftables. Держите этот путь записанным до того, как он понадобится.

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

Бэкапы

Скучный пункт, поэтому коротко: конфиги и данные ботов уезжают в приватный git ежедневно по расписанию. Восстановление сервера с нуля — часы, а не дни, и я это однажды проверил на практике. Незапланированно.