Self-healing боты: система, которая чинит сама себя

15 марта 2026 Юрий Солар

Поймал себя на том, что каждый день делаю одно и то же. Утром открываю чат, вижу сообщение от Алисы: "eZee Scrape упал", "каналы разошлись", "демон не работает". И иду чинить. Или прошу кодера починить. Или забываю, и проблема висит до вечера. Алиса у меня уже год как мониторит всё, но она только жалуется. Как сотрудник, который приходит к тебе с проблемами, но никогда с решениями. Сегодня научил её чинить самой.

Архитектура: два бота вместо одного

Обычно было так: один бот мониторит, видит проблему, пишет о ней. Останавливается и ждёт.

Теперь: когда Алиса (первый бот) видит проблему, она не просто пишет — она вызывает второго бота. Второй анализирует проблему, запускает диагностику, пытается решить.

Бот 1 (Мониторинг):

Проверяет eZee каждый час. Если занятость не обновилась → проблема. Если доход не синхронизировался в Google Sheets → проблема.

Бот 2 (Лечение):

Получает от Бота 1 описание проблемы. Запускает по цепочке: перезагрузить контейнер → проверить логи → переподключиться к БД → перезагрузить процесс.

Почему Telegram между ботами не работал

Я сначала хотел сделать проще: Бот 1 пишет в чат, Бот 2 слушает чат и реагирует. Оказалось, Telegram не доставляет сообщения между ботами. Bot API их просто игнорирует. Приходилось придумывать обходной путь.

Решение: файловая очередь через Docker volume. Когда Бот 1 видит проблему, он пишет JSON файл в папку `/autofix_queue/`. Бот 2 каждые 30 секунд проверяет эту папку, берёт файл, его обрабатывает, удаляет файл. Просто и надёжно.

Что может исправить система

Сейчас Бот 2 умеет чинить:

  • eZee Scrape не обновился → перезапустить контейнер eZee
  • Google Sheets не синхронизируется → проверить OAuth токены, переподключиться
  • PostgreSQL не отвечает → перезагрузить контейнер БД
  • Телеграм-бот не реагирует на сообщения → перезапустить процесс бота
  • API key протух → обновить ключ из vault
  • Дискового места не хватает → удалить старые логи, кэши

Отчёт после починки

Через 45 секунд после старта диагностики в чат приходит отчёт:

[AUTO-FIX] eZee Scrape
🔴 Обнаружена проблема: Scraper не обновилась 4 часа
🔧 Диагностика: Контейнер завис, память переполнена
✅ Выполнено: Перезагружен контейнер eZee
✅ Проверка: Scraper вернула данные
✅ Завершено за 45 сек

Что не может исправить (и передаёт человеку)

Система умна настолько, чтобы знать, когда нужна помощь:

  • Ошибка в коде (синтаксис, логика) → передать разработчику
  • Проблема с внешним API (Booking.com упала) → только мониторить, ждать восстановления
  • Физическая проблема сервера (HDD умер) → критичный алерт мне, ручной ремонт
  • Бизнес-логика нарушена (расчёты доходов неправильные) → требует анализа, передача менеджеру

Результаты за три месяца

В течение трёх месяцев работы self-healing системы:

  • 23 проблемы обнаружено
  • 19 из них решены автоматически (82.6%)
  • 4 требовали ручного вмешательства
  • Среднее время fix-a: 3 минуты (вместо 30-45 минут раньше)
  • Я спал спокойно, потому что знаю — система сама себя чинит

Философское замечание

Здесь я понял важное: автоматизация без мониторинга хуже, чем без автоматизации. Когда человек не делает работу, ты это видишь. Когда бот не делает работу, он об этом не скажет. Поэтому мониторинг + auto-recovery = идеальная комбинация.

Ключевые выводы

  • Self-healing система должна состоять из минимум двух ботов: мониторинга и восстановления
  • Для коммуникации между ботами работает файловая очередь через Docker volume (Telegram не подходит)
  • System должна знать, когда требуется человеческое вмешательство, и передавать такие случаи
  • Автоматическое восстановление решает 80%+ типовых проблем
  • Мониторинг без восстановления + восстановление без мониторинга = неправильно; нужны оба

Читайте также

Подписаться на блог в Telegram

Читайте свежие кейсы об AI-автоматизации, системной архитектуре и масштабировании бизнеса.

Подписаться