Сегодня обнаружил, что семь моих AI-агентов молча перестали работать. Не упали, не выдали ошибку. Просто замолчали. Пишу в чат "опубликуй пост" — бот отвечает "запускаю агента". И тишина. Ни ответа, ни ошибки. Как будто всё работает, но ничего не происходит. Полез в логи. Оказалось, внешний сервис, через который работали все агенты, начал отдавать ошибку перегрузки. Тихо, без уведомлений.
Что произошло
Архитектура выглядела так: мой бот отправляет запрос на внешний API, API обрабатывает, возвращает результат, я получаю результат и публикую. Все семь агентов зависели от этого одного API.
В определённый момент API перегрузилась. Она начала отдавать ошибку 503 (Service Unavailable). Но мой код был написан так: если API не отвечает быстро (timeout), мы просто пытаемся снова через 5 секунд. И снова. И снова. Но результата никогда не было.
Самое неприятное: система выглядела рабочей. Боты были онлайн, процессы крутились, сообщения принимались. Просто никто ничего не делал. И самое скверное — я об этом не знал, пока не заметил, что посты не публикуются.
Ужас скрытых сбоев
Это очень коварная ситуация в системном проектировании. Когда система сломана, но ломается молча. Есть три типа отказов:
- Loud failure (громкий отказ): система падает, ошибка выбрасывается, алерт срабатывает. Ты сразу видишь проблему.
- Loud hanging (зависание с попыткой): система пытается что-то сделать, заметно, что процесс идёт медленно. Ты видишь, что что-то не так.
- Silent failure (молчаливый отказ): система выглядит рабочей, но не делает то, что должна. Ты можешь это заметить спустя часы или дни.
Это был third case. Молчаливый отказ, который я мог не заметить довольно долго, если бы не проверил вручную.
Решение: резервная цепочка
Я переписал логику так: если основной API не отвечает за 30 секунд, автоматически переходим на второй, если второй не отвечает — на третий. У меня есть три разных провайдера API для одного типа задачи.
Попытка 1 (основной): API1 (timeout 30 сек)
Попытка 2 (резервный): API2 (timeout 30 сек)
Попытка 3 (резервный к резервному): API3 (timeout 30 сек)
Неудача: если все три не отвечают, выбрасываю ошибку и алертю
Теперь, если API1 сломалась — система автоматически переключится на API2. Если API2 упала — на API3. Это обеспечивает resilience. Я "платню" три разных провайдера, но моя система теперь может выдержать отказ одного из них.
Мониторинг отказов
Но резервная цепочка — это только часть решения. Главное — знать, когда это происходит.
Теперь, когда сработает переключение на резервный провайдер, я получаю уведомление: "Основной API не отвечает, переключился на резервный". Если все три API неработающие — получаю critical alert.
Логирование помощь: каждый вызов API логируется с timestamp, провайдером и результатом. Я могу потом проанализировать логи и сказать: "С 14:30 до 15:45 основной API был перегружен, система использовала резервные провайдеры."
Результаты
За месяц после внедрения этой системы:
- 3 раза основной API была перегружена
- Все 3 раза система автоматически переключилась на резервный провайдер
- 0 потерь публикаций из-за отказов API
- Я сразу узнал о проблемах, вместо того, чтобы узнать спустя часы
Практический вывод
Вот что я вынес из этого опыта: автоматизация без мониторинга хуже, чем без автоматизации. Когда человек не делает работу, ты это видишь. Когда бот не делает работу, он об этом не скажет, если ты это не настроил. Поэтому для каждого критичного процесса нужны: 1) основной способ выполнения, 2) резервный способ, 3) мониторинг, который告诉тебе, когда основной сломался.