У меня в проде крутится 30+ агентов. Они собирают сигналы, пишут черновики, следят за пайплайнами — и, если не проверять, отлично имитируют бурную деятельность. Из инцидентов выросли четыре проверки. Каждая стоила мне нервов, некоторые — денег.
1. Проверка «Кто виноват: провайдер или я?»
Однажды утром мониторинг завалил меня алертами: «внешний провайдер лежит». Я уже собирался ждать, пока починят чужое, но заглянул в системный журнал. Оказалось, процессу-шлюзу не хватило RAM, ОС его убила (OOM Killer), а мониторинг просто зафиксировал таймаут и решил, что виноваты другие.
Что проверить: посмотрите, как система реагирует на одновременный сбой нескольких задач. Если мониторинг сразу обвиняет внешний мир, вы слепы.
Как понять, что провалено: в логах мониторинга пусто, кроме «timeout», а в journalctl — записи о принудительном завершении процесса из-за нехватки памяти.
Чем полечить: встройте в мониторинг «запрос к себе». Сначала система проверяет свой статус (RAM, CPU, диск), и только если внутри всё чисто — смотрит наружу. Запустилось — не значит работает.
2. Проверка «Артефакт вместо статуса»
Позже я обнаружил, что агент, отвечающий за сборку отчётов, две недели рапортовал «Success». На деле он просто не находил нужный скрипт для запуска, возвращал пустой ответ, а мой планировщик считал отсутствие ошибки успехом. Система работала в режиме «театра теней».
Что проверить: что именно вы считаете успехом? Если «ответ 200» или «скрипт завершился без кода ошибки», вы в зоне риска.
Как понять, что провалено: агент отчитывается об успехе, но за последние 24 часа размер файлов в папке вывода не изменился ни на байт.
Чем полечить: замените проверку статуса проверкой артефакта. Если на выходе нет свежего файла с данными — это провал. Кстати, 50% токенов я сэкономил, когда перенёс жёсткую логику на обычные скрипты, оставив LLM только роль «думателя» и «писателя». ИИ-инфра: тренды — это не про то, чтобы заставлять модель делать всё подряд.
3. Проверка «Жёсткого пола»
Ещё через месяц пайплайн начал выдавать «мусор» при формально валидных файлах — классическая тихая деградация (полный разбор этого инцидента — в кейсе).
Что проверить: спросите себя: «Что будет, если на входе окажется пустышка?». Если ответ «warning в логах» — вы проиграли.
Как понять, что провалено: система продолжает цикл, несмотря на то, что данные на выходе не соответствуют бизнес-логике (например, меньше минимально допустимого размера).
Чем полечить: установите «жёсткий пол». Если результат меньше минимума — система должна упасть с критической ошибкой, а не пытаться «исправиться». Используйте подменный контент другого типа, чтобы сразу заметить подмену в дашборде.
4. Проверка «Внешнего сигнала»
Это самый болезненный урок. Агенты исправно постили контент, писали отчёты и генерировали красивые графики внутри системы. А внешний сигнал — реакции, подписчики, ответы людей — тихо падал, и ни один агент этого не видел: за ним никто не следил. Агенты были автономны, но оторваны от реальности.
Что проверить: есть ли у каждого цикла работы показатель, который живёт СНАРУЖИ системы?
Как понять, что провалено: отчёты внутри системы зелёные, а продажи или подписки падают. Вы строите «автономность-театр».
Чем полечить: раз в неделю цикл обязан привязать свой отчёт к внешнему KPI. Если за неделю нет корреляции между работой агента и изменением метрики — помечайте систему как неэффективную.
После того как в мае я обновил панель управления и получил 5655 рестартов за ночь, я добавил правило: бэкап всей инфраструктуры перед любым апгрейдом. Почитайте мой разбор системы целиком, чтобы не повторять моих ошибок в архитектуре. Улучшение не должно ломать то, что уже худо-бедно работает.
