Как Алиса перестала жаловаться и начала чинить сама: автофикс через цепочку ботов

Примерно раз в день, иногда чаще, у меня в чате появляется сообщение от Алисы. «eZee Scrape упал». «Канал синхронизации разошёлся». «Демон мониторинга не отвечает». Формулировки разные, суть одна: что-то сломалось, и Алиса об этом сообщает.

Алиса — это мой главный мониторинговый бот. Она следит за всем: бронирования, каналы продаж, внешние интеграции, скрипты на сервере. Год я строил эту систему наблюдения, добавлял новые проверки, уточнял пороги срабатывания. Алиса стала очень хорошим детектором проблем.

Но до 26 марта 2026 года у неё была одна принципиальная ограниченность: она только жаловалась. Видела проблему, писала в чат — и всё. Дальше проблему должен был решать я. Или просить кодера. Или забывал, и проблема висела до вечера.

В тот день я это изменил. Алиса научилась не только обнаруживать проблемы, но и вызывать второй бот для их устранения. Теперь от обнаружения до починки проходит 45 секунд — без моего участия.

Почему «умный детектор» — только половина системы

Когда строишь мониторинг, первый шаг — научить систему замечать отклонения. Это технически понятная задача: задаёшь пороги, пишешь правила, настраиваешь уведомления. За год я построил довольно развитую систему мониторинга: Алиса проверяла десятки параметров каждые несколько минут.

Проблема появляется на следующем шаге. Обнаружение — это не решение. Это только сигнал, что нужно решение. И пока цепочка «обнаружение → решение» включала меня как промежуточное звено, система зависела от моей доступности.

Бали — хорошее место для жизни, но не лучшее для синхронного реагирования на технические инциденты. Я часто на пляже, в кафе, за рулём скутера. Алиса может написать в любой момент. Иногда я отвечаю сразу, иногда через час, иногда вижу сообщение и думаю «разберусь вечером» — и забываю.

В результате среднее время устранения типового инцидента (перезапуск скрипта, ресинхронизация канала, очистка застрявшей очереди) было непредсказуемым. Могло быть пять минут, если я был у компьютера. Могло быть несколько часов, если я был занят.

Для бизнеса с 16 виллами и активными бронированиями это плохо. Разошедшиеся каналы продаж — это потенциальный овербукинг. Упавший мониторинг бронирований — это пропущенные заявки. Каждый час простоя стоит реальных денег.

Идея цепочки ботов

Идея была простой: а что если Алиса при обнаружении проблемы не только напишет мне, но и автоматически вызовет второго бота — того, который умеет чинить? Этот второй бот получает описание проблемы, анализирует ситуацию, запускает нужные команды и отчитывается о результате.

Такая цепочка: детектор → фиксер. Алиса видит — Клод (второй бот на базе Claude API) чинит. Мне в чат приходит итоговый отчёт: что было сломано, что сделано, какой результат.

На практике это означает, что я больше не промежуточное звено в обработке типовых инцидентов. Алиса + Клод закрывают их самостоятельно. Мне остаётся только прочитать отчёт — или вообще не читать, если всё починилось без последствий.

Звучит очевидно. Реализация оказалась нетривиальной из-за одного технического ограничения.

Почему Telegram не годится для bot-to-bot общения

Первая идея была самой простой: пусть Алиса пишет Клоду в Telegram. Алиса обнаруживает проблему → отправляет сообщение в чат Клода → Клод читает → чинит → отвечает обратно Алисе.

Это не работает. Telegram не доставляет сообщения от одного бота другому боту. Это ограничение платформы: боты могут получать сообщения от людей и отвечать им, но не общаться напрямую между собой через стандартный API.

Технически это сделано намеренно — чтобы предотвратить бесконечные петли и спам-цепочки между ботами. Логично с точки зрения безопасности, но неудобно, когда тебе нужна именно такая архитектура.

Можно было обойти это через группу — добавить обоих ботов в один чат и пусть Алиса пишет туда, а Клод слушает этот чат. Но это создало бы шум в рабочих каналах и потребовало бы сложной фильтрации, чтобы Клод реагировал только на нужные сообщения.

Нужен был другой подход.

Решение: файловая очередь через общий том

Оба бота — Алиса и Клод — работают в Docker-контейнерах на одном сервере. Это открывает возможность, которой нет в Telegram: общая файловая система через Docker volume.

Схема получилась следующая:

• Алиса обнаруживает проблему
• Записывает задание в JSON-файл в общую папку /shared/autofix/queue/
• Клод каждые 30 секунд проверяет эту папку на наличие новых файлов
• При нахождении файла — читает задание, анализирует проблему, выполняет команды
• Записывает результат в папку /shared/autofix/results/
• Алиса периодически проверяет результаты и отправляет итоговый отчёт в Telegram

Файл задания выглядит примерно так:

{
  "task_id": "fix_20260326_143022",
  "problem_type": "ezee_scrape_down",
  "detected_at": "2026-03-26T14:30:22+08:00",
  "details": {
    "service": "ezee-scrape.service",
    "last_successful_run": "2026-03-26T12:15:00+08:00",
    "error_log": "Connection timeout after 30s",
    "villa_ids_affected": [3, 7, 12, 15]
  },
  "priority": "high"
}

Клод получает этот файл, анализирует тип проблемы и запускает нужный сценарий устранения. Для `ezee_scrape_down` — это проверка сервиса, перезапуск если нужно, проверка соединения с eZee API, запуск принудительной синхронизации.

Как Клод «думает» о починке

Клод — это не просто скриптовый исполнитель с жёстко прописанными командами. Он работает на Claude API с системным промптом, который описывает его роль: технический инженер, знающий архитектуру всей системы.

Когда Клод получает задание, он сначала анализирует ситуацию. Смотрит на тип проблемы, читает контекст, проверяет последние логи через SSH-команды. Потом принимает решение о последовательности действий.

Для стандартных проблем — упавший сервис, зависшая очередь, истёкший токен — у него есть отработанные сценарии. Но если проблема нестандартная, он не пытается чинить наугад. Вместо этого добавляет в отчёт флаг «требует ручного вмешательства» и описывает, что именно непонятно.

Это принципиальный момент: я не хотел, чтобы автофикс работал по принципу «попробую всё подряд». Лучше правильно диагностировать и ничего не трогать, чем неправильно починить и сделать хуже.

В системном промпте Клода прямо прописано: «Если ты не уверен в причине проблемы или в правильности действия — остановись и запиши в отчёт, что нужна проверка человека». Это не ограничение возможностей, это правильная архитектура для критических систем.

Первый реальный тест

Запустил систему 26 марта. В тот же вечер — первый реальный инцидент: eZee Scrape не ответил на плановую проверку. Раньше Алиса написала бы мне: «eZee Scrape упал», и я бы шёл разбираться.

На этот раз я увидел в чате другое сообщение:

Я был на обеде. Проблема решилась без меня. Это было необычное ощущение — привык, что технические инциденты требуют моего внимания, а тут просто отчёт о закрытом событии.

Что умеет чинить автофикс

За первые недели работы системы сформировался список типовых инцидентов, которые Клод закрывает самостоятельно:

• Упавшие сервисы — перезапуск через systemctl, проверка зависимостей, валидация после рестарта
• Зависшие очереди — диагностика причины зависания, очистка или переобработка зависших задач
• Разошедшиеся каналы продаж — принудительная ресинхронизация с Airbnb/Booking через API
• Истёкшие токены — обновление токенов для внешних сервисов, где это настроено автоматически
• Переполненные логи — ротация логов, освобождение дискового пространства
• Временные сетевые проблемы — повторные попытки с экспоненциальной задержкой

Что Клод не трогает без меня:

• Изменения в базе данных (кроме заранее согласованных операций очистки)
• Обновления конфигурационных файлов
• Любые операции с деньгами или бронированиями
• Проблемы, которые он видит впервые и не понимает причину

Граница между «чиню сам» и «зову человека» — это граница обратимости. Если действие легко отменить и не затрагивает клиентские данные — Клод действует. Если есть риск необратимых последствий — останавливается и пишет мне.

Техническая деталь: почему файловая очередь, а не HTTP

Можно было сделать это через HTTP — Алиса отправляет запрос на внутренний API Клода, тот обрабатывает и отвечает. Это была вторая идея после Telegram.

Отказался по нескольким причинам.

Первая — надёжность. HTTP-запрос может упасть если Клод перезапускается, перегружен или сеть нестабильна. Файловая очередь персистентна: файл лежит в папке до тех пор, пока Клод его не обработает, независимо от состояния самого Клода в момент добавления задачи.

Вторая — асинхронность. Алисе не нужно ждать ответа от Клода. Она записала файл и пошла дальше мониторить. Клод обработает в своём темпе. Это важно, потому что починка может занять минуту, а Алиса за это время должна продолжать следить за другими параметрами.

Третья — наблюдаемость. Папка с заданиями и папка с результатами — это живая история всех инцидентов. Я в любой момент могу открыть и посмотреть, что происходило: какие проблемы были, что Клод делал, какие результаты. Это намного удобнее, чем разбирать логи HTTP-запросов.

Что изменилось в операционной модели

До автофикса: Алиса обнаруживает проблему → пишет мне → я анализирую → чиню или делегирую → проблема закрыта. Среднее время: от 15 минут до нескольких часов в зависимости от моей доступности.

После автофикса: Алиса обнаруживает → передаёт Клоду → Клод чинит → присылает отчёт. Среднее время для типовых инцидентов: 45-90 секунд.

За первые две недели работы системы — 12 инцидентов. 9 закрыты Клодом самостоятельно. 3 переданы мне как требующие ручного вмешательства (один раз — нестандартная ошибка в eZee API, два раза — проблемы, требовавшие изменения конфигурации).

Из 9 автоматически закрытых — ни одного, где бы починка привела к новым проблемам. Это важный показатель: система не просто быстрая, она надёжная.

Связь с более широкой идеей самоуправляемого бизнеса

Я давно думаю о том, что такое «самоуправляемый бизнес». Не бизнес, который работает без людей — это утопия. А бизнес, где каждый типовой сценарий обрабатывается автоматически, и человек занимается только нетипичным.

Автофикс Алисы — один шаг в эту сторону. Раньше «бот упал» было событием, которое требовало моего времени. Теперь это фоновый процесс, который система решает сама и отчитывается о закрытии.

Это высвобождает внимание для другого. Я уже писал про сдвиг от исполнителя к наладчику — когда твоя задача не делать руками, а делать так, чтобы система делала сама. Автофикс — ещё один элемент этой логики.

Смешная деталь: в процессе разработки я столкнулся с тем, что самое сложное — это не написать код для Клода, а правильно описать границы его полномочий. «Чини всё, что можешь» — плохая инструкция. «Чини только то, что обратимо, и останавливайся при неопределённости» — работающая инструкция. Это и есть разница между автоматизацией, которой доверяешь, и автоматизацией, которая рано или поздно создаёт больше проблем, чем решает.

Что дальше

Следующий шаг — расширить библиотеку сценариев Клода. Сейчас он умеет обрабатывать примерно 15 типов инцидентов. У Алисы мониторится около 40 параметров. Значит, для части из них автофикс ещё не настроен.

Каждый раз, когда Клод передаёт мне проблему с флагом «требует ручного вмешательства», я анализирую: это действительно нетипичный случай, или это типовая ситуация, просто для неё ещё не написан сценарий? Второй вариант — задание написать новый сценарий и добавить его в библиотеку Клода.

Через несколько месяцев хочу добиться, чтобы Клод закрывал самостоятельно не 75%, а 90% инцидентов. Не потому что 90% — красивое число, а потому что 10% нетипичных случаев — это тот остаток, где действительно нужно моё мышление.

Остальное пусть чинит сам. Я буду на пляже.