Аудит автоматизации: как 3 системы сломались тихо и что я сделал

18 мая 2026 года я провёл плановый аудит автоматизации и обнаружил, что 3 системы из 19 работающих агентов молча перестали выполнять свои функции. Не упали с ошибкой, не прислали алерт — просто тихо прекратили делать то, для чего были созданы. На момент обнаружения суммарный простой составил 22 дня для одной системы, 9 дней для второй и 11 дней для третьей. Всё это время я был уверен, что автоматизация работает.

Это не история о технической катастрофе — данные не удалены, бизнес ~16 активных вилл не встал. Это история о более опасной вещи: иллюзии работающей системы. Пока поллер писал нули, пока диктовки копились в очереди, пока лиды из Telegram уходили в никуда — я принимал решения на основе неполной информации. Именно поэтому тихие поломки опаснее громких.

Три поломки, которые никто не заметил

Instagram-поллер: 22 дня нулей

Instagram-поллер — бот, который раз в 4 часа проверяет комментарии и DM по ключевым словам, связанным с арендой вилл. Когда кто-то пишет «хочу забронировать» или «аренда в апреле» — бот фиксирует лид и передаёт его в CRM-цепочку. Система работала стабильно с ноября 2025 года.

26 апреля 2026 года Instagram незаметно изменил формат ответа своего внутреннего API — поле с текстом комментария переехало с одного уровня JSON-вложенности на другой. Поллер перестал находить текст, начал записывать пустые строки вместо содержания и фильтровать их как «не содержащие ключевых слов». Никаких исключений, никаких ошибок в логах — только нули в таблице лидов. За 22 дня было пропущено предположительно 15-20 потенциальных обращений. Обнаружил случайно, когда сравнивал статистику за апрель и май: апрель — 34 лида из Instagram, май к 18-му числу — 0. Это физически невозможно при нормальной работе.

Исправление заняло 40 минут: обновил путь к полю в парсере, добавил логирование сырого JSON при нулевом результате выборки. Теперь если за 48 часов поступает ноль записей — бот автоматически логирует структуру последнего ответа API для диагностики.

Аккаунт Claude: протух 9 мая, 304 диктовки в никуда

Я диктую голосовые заметки в Telegram — задачи, мысли, черновики постов. Специальный агент забирает аудио, транскрибирует через Whisper и отправляет в Claude для обработки: структурирует задачи, выделяет идеи для блога, добавляет в базу знаний. Система работала с января 2026 года и обрабатывала в среднем 8-12 диктовок в день.

9 мая истёк session token для Claude API. Агент начал получать ошибку 401, но был написан с жадным обработчиком исключений: при любой ошибке обработки он помещал задачу обратно в очередь и двигался дальше. Очередь росла. К 18 мая в ней накопилось 304 необработанных аудиофайла. Транскрипция продолжала работать (Whisper отдельный), но результаты никуда не уходили — складывались в буфер. Я не замечал отсутствия выходных данных, потому что не проверял систематически выход системы, только изредка смотрел на отдельные диктовки.

Токен обновили за 15 минут. Очередь из 304 файлов обработалась за 3 часа в пакетном режиме. Потери данных нет, но 9 дней контекста ушло без обработки. Теперь агент пишет в отдельный лог количество успешно обработанных задач за час — если час прошёл и счётчик ноль, в Telegram летит алерт.

Главный урок из этой поломки: жадный обработчик исключений — антипаттерн для продакшн-систем. Если агент получает ошибку 401 и просто кладёт задачу обратно в очередь без уведомления, он превращает разовый сбой в хронический. Правильная логика: 1-2 попытки с retry, затем — движение задачи в очередь ошибок и немедленный алерт. Тихое накопление в очереди должно быть явно запрещено архитектурой.

Webhook Telegram: 11 дней пустых форм

Третья система — webhook-обработчик входящих заявок из Telegram-бота для потенциальных арендаторов. Человек заполняет форму в боте (даты, количество гостей, бюджет), данные уходят на webhook, который записывает заявку в Airtable и уведомляет о ней менеджера. Простой и надёжный пайплайн.

7 мая при обновлении сервера был перезапущен Nginx, и конфигурация webhook-endpoint сбросилась на старый URL. Новые заявки из бота уходили на несуществующий адрес и получали 404. Telegram при этом не показывает пользователю ошибку — бот отвечал «Заявка принята, мы свяжемся с вами», хотя данные нигде не сохранились. За 11 дней было потеряно 7 реальных заявок на аренду — это мы восстановили только частично, связавшись с теми, чьи контакты остались в истории бота.

После исправления добавил мониторинг: раз в 6 часов тестовый скрипт отправляет синтетическую заявку через webhook и проверяет её появление в Airtable. Если тест не прошёл — немедленный алерт. Это классический подход end-to-end мониторинга, и странно, что его не было с самого начала.

Эта поломка дорогостоящая не только в деньгах. 7 человек написали в Telegram, получили подтверждение «заявка принята», ждали обратной связи — и не дождались. С точки зрения пользователя — бизнес просто игнорирует их. Репутационный ущерб от такого молчания иногда хуже потери самой сделки. Поэтому для каждого пользовательского флоу обязательна проверка: а что случается с данными после нажатия «отправить»? Не «система приняла запрос», а «данные появились там, где должны».

Почему тихие поломки опаснее громких

Громкая поломка — это когда система падает с ошибкой 500, сервер недоступен, пользователи жалуются. Её невозможно не заметить. Тихая поломка — это когда система продолжает казаться работающей, но перестаёт давать результат. Именно здесь кроется главная опасность.

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

Реальный ущерб от 3 тихих поломок в нашем случае: 15-20 пропущенных Instagram-лидов за 22 дня (при среднем чеке аренды виллы 2000-3500 долларов за неделю — это потенциально серьёзные деньги), 9 дней без обработки голосовых заметок (потеря операционной эффективности, несколько идей так и не были зафиксированы должным образом), 7 потерянных заявок из Telegram за 11 дней. Это не катастрофа, но это реальная цена иллюзии работающей автоматизации.

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

Есть и психологический аспект, который редко обсуждают. После того как обнаруживаешь тихую поломку, возникает соблазн «всё проверить прямо сейчас» — и потратить 8 часов на ревизию всех 19 систем одновременно. Это контрпродуктивно. Правильный ответ — систематический протокол, а не паника. Именно для этого нужен структурированный чек-лист: он трансформирует тревогу в предсказуемый процесс с конкретным результатом за 2 часа.

Протокол ежемесячного аудита: 15 чекпоинтов

После этого инцидента я формализовал протокол аудита, который теперь запускаю в первый понедельник каждого месяца. Вот 15 конкретных проверок с примерами команд.

1. Количество событий за период. Для каждой системы проверяю, сколько записей создано за последние 30 дней. Нулей или аномально низких значений не должно быть без очевидной причины. SELECT COUNT(*), DATE(created_at) FROM events WHERE created_at > NOW() - INTERVAL 30 DAY GROUP BY DATE(created_at);
2. Статус всех cron-задач. Проверяю, что каждая задача выполнялась в ожидаемое время. grep CRON /var/log/syslog | grep -E "(error|failed)" | tail -100
3. Актуальность API-токенов. Список всех внешних интеграций с датами истечения токенов. За 7 дней до истечения — обновление. cat /etc/bots/tokens.json | python3 -c "import json,sys,datetime; [print(k, v['expires']) for k,v in json.load(sys.stdin).items()]"
4. Проверка webhook-endpoint'ов. Curl-запрос на каждый webhook с тестовыми данными, проверка появления записи в БД. curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/webhook/test -d '{"test":true}'
5. Размер очередей задач. Если у агента есть очередь — проверяю, не накопилось ли там необработанных задач старше 24 часов. redis-cli LLEN task_queue
6. Логи ошибок за месяц. Не просто наличие ошибок, но и их динамика — резкий рост числа ошибок конкретного типа сигнализирует о проблеме. grep -c "ERROR" /var/log/bots/*.log | sort -t: -k2 -rn | head -20
7. Проверка парсеров на актуальность формата. Если бот парсит внешний сайт или API — ручная проверка, что структура данных не изменилась. Запускаю парсер в режиме отладки и смотрю на сырые данные.
8. Тест end-to-end флоу. Для критических пайплайнов — прохожу весь путь вручную: создаю тестовую заявку, проверяю, что она появилась на каждом этапе. Это занимает 5-10 минут, но выявляет разрывы в цепочке.
9. Проверка дискового пространства. Логи и временные файлы могут заполнить диск, что приведёт к отказу записи в БД. df -h / && du -sh /var/log/* | sort -rh | head -10
10. Актуальность SSL-сертификатов. За 30 дней до истечения — обновление. for domain in yourdomain.com api.yourdomain.com; do echo -n "$domain: "; echo | openssl s_client -servername $domain -connect $domain:443 2>/dev/null | openssl x509 -noout -dates | grep notAfter; done
11. Проверка баз данных. Нет ли таблиц с аномально быстрым ростом или, наоборот, с застывшим счётчиком там, где должна идти запись. SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema = 'your_db' ORDER BY table_rows DESC;
12. Работоспособность внешних зависимостей. Проверяю доступность всех внешних API, которые используют боты. Если API вернул 429 (rate limit) или 503 — это объясняет странности в логах. curl -s -o /dev/null -w "%{http_code}" https://api.anthropic.com/v1/messages -H "x-api-key: $CLAUDE_KEY"
13. Актуальность зависимостей и библиотек. Устаревшие библиотеки часто ломаются при обновлении внешних API. pip list --outdated | grep -E "(requests|anthropic|openai|aiohttp)"
14. Проверка резервных копий. Бэкап БД должен создаваться ежедневно и быть восстанавливаемым. Раз в месяц — тестовое восстановление на отдельном сервере. ls -la /backups/ | tail -5
15. Обзор метрик производительности. Сравниваю среднее время ответа ботов с прошлым месяцем. Рост latency на 200%+ — признак проблемы с зависимостью или кода. awk '/response_time/ {sum+=$NF; count++} END {print "avg:", sum/count "ms"}' /var/log/bots/metrics.log

Весь аудит занимает около 2 часов. Это кажется много, но 7 потерянных заявок на аренду — это гораздо дороже 2 часов времени.

Автоматический мониторинг логов и алерты

Ежемесячный аудит — это необходимо, но недостаточно. Между проверками может пройти 30 дней молчаливой поломки. Для критических систем нужен автоматический мониторинг с алертами в реальном времени. Подробнее об архитектуре мониторинга AI-агентов я писал в отдельной статье про мониторинг AI агентов — здесь остановлюсь на практических примерах.

Базовый принцип — heartbeat-мониторинг: каждая система регулярно сообщает «я жив и обработал N задач». Если сообщение не пришло в ожидаемое время или N равно нулю при ожидаемом ненулевом значении — алерт.

Пример простого heartbeat-скрипта для Telegram-алерта при аномалии:

#!/bin/bash
# check_bot_health.sh — запускать через cron каждые 2 часа

BOT_TOKEN="your_telegram_bot_token"
CHAT_ID="your_chat_id"
DB_HOST="localhost"
DB_NAME="bots_db"

# Проверяем количество событий за последние 2 часа
COUNT=$(mysql -h $DB_HOST $DB_NAME -se "SELECT COUNT(*) FROM instagram_leads WHERE created_at > NOW() - INTERVAL 2 HOUR")

# Час дня (рабочие часы — с 8 до 22)
HOUR=$(date +%H)

# Если рабочие часы и ноль событий — алерт
if [ $HOUR -ge 8 ] && [ $HOUR -le 22 ] && [ "$COUNT" -eq 0 ]; then
  MESSAGE="⚠️ Instagram-поллер: 0 событий за последние 2 часа. Проверить парсер."
  curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
    -d "chat_id=$CHAT_ID" \
    -d "text=$MESSAGE"
fi

Этот скрипт работает в cron каждые 2 часа и занимает 15 строк. Аналогичный паттерн применяю для всех критических систем: проверяю не статус процесса, а факт появления результата.

Для более сложных сценариев использую многоуровневые алерты: INFO (аномалия зафиксирована, но не критична), WARNING (система работает, но с отклонением), CRITICAL (система не работает, немедленное вмешательство). Только WARNING и CRITICAL уходят в Telegram — иначе уведомлений слишком много и они перестают восприниматься серьёзно.

Также важно мониторить не только нули, но и аномально высокие значения. Если Instagram-поллер вдруг присылает 500 лидов за час — это тоже проблема (скорее всего, цикл или дублирование). Устанавливаю пороги и снизу, и сверху.

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

Мониторинг сообщает о проблеме. Self-healing пытается её устранить до того, как она потребует ручного вмешательства. Это не серебряная пуля — автономно восстанавливаются только типовые, предсказуемые отказы. Но именно такие отказы составляют 60-70% инцидентов. О более сложных случаях, включая каскадные отказы, я писал в статье тихий отказ 7 ботов опаснее, чем громкий.

Автоматический перезапуск сервиса. Самый простой случай: процесс упал. systemd с директивой Restart=always перезапустит его автоматически. Для более умного перезапуска используем supervisord с настройкой autorestart=unexpected и стратегией экспоненциальной задержки — чтобы не создавать циклы при системной ошибке.

[program:instagram_poller]
command=python3 /opt/bots/instagram_poller.py
autorestart=unexpected
startretries=3
stopwaitsecs=10
redirect_stderr=true
stdout_logfile=/var/log/bots/instagram_poller.log

Ротация токенов. Для систем с истекающими токенами пишем скрипт, который за 7 дней до истечения запрашивает новый токен через API (если провайдер поддерживает) или отправляет напоминание с инструкцией. Для Claude API, где токены обновляются вручную, настроил cron-напоминание с точной датой истечения:

# crontab: проверять каждый день в 9 утра
0 9 * * * /opt/scripts/check_token_expiry.sh

Скрипт читает файл с датами истечения всех токенов и присылает алерт, если до истечения осталось меньше 7 дней. Простое решение, которое предотвращает повторение ситуации с 9 мая.

Fallback на резервный канал. Для критических пайплайнов держу резервный путь обработки. Если основной Claude-агент недоступен — задача помечается флагом «требует ручной обработки» и я получаю уведомление. Это лучше, чем тихое накопление в очереди на 9 дней. Если недоступен основной webhook — есть резервный endpoint на другом сервере.

Автоматическая диагностика при нулевом результате. После инцидента с Instagram-поллером добавил в него режим диагностики: если за цикл найдено 0 событий — поллер сохраняет сырой ответ API в отдельный лог-файл. Это позволяет за 2 минуты понять, изменился ли формат ответа, вернул ли API пустой массив или произошла другая аномалия. Система не чинит себя сама, но предоставляет все данные для быстрого ручного исправления.

Чек-лист для ежемесячной проверки автоматизации

Структурированный список из 15 пунктов для быстрого прохождения аудита. Копируйте в свой таск-менеджер и запускайте раз в месяц.

• ☐ Счётчики событий — для каждой системы: нет ли нулей или аномально низких значений за последние 30 дней?
• ☐ Cron-задачи — все ли запускались в ожидаемое время? crontab -l && grep CRON /var/log/syslog | tail -50
• ☐ API-токены — даты истечения всех токенов, обновить те, что истекают в следующие 14 дней
• ☐ Webhook-тест — ручной curl на каждый webhook, проверка появления записи в БД
• ☐ Очереди задач — нет ли накопленных необработанных задач старше 24 часов
• ☐ Логи ошибок — динамика ошибок за месяц, новые типы ошибок
• ☐ Формат внешних API — ручная проверка парсеров в режиме отладки
• ☐ End-to-end тест — пройти критический флоу вручную от начала до конца
• ☐ Дисковое пространство — df -h, очистить устаревшие логи
• ☐ SSL-сертификаты — обновить те, что истекают в следующие 30 дней
• ☐ Рост таблиц БД — нет ли аномального роста или застывших счётчиков
• ☐ Доступность внешних зависимостей — статус всех используемых внешних API
• ☐ Зависимости и библиотеки — pip list --outdated, обновить критические
• ☐ Резервные копии — проверить наличие свежих бэкапов, раз в квартал — тестовое восстановление
• ☐ Метрики производительности — latency ботов, сравнение с прошлым месяцем

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

Три тихие поломки за один аудит — это много для 19 агентов. Но лучше находить их планово раз в месяц, чем случайно через квартал при сравнении статистики. Автоматизация без мониторинга — это не автоматизация, а доверие вслепую. Вы можете построить самую умную систему из AI-агентов, но если вы не проверяете, что она делает то, что должна — вы работаете с иллюзией. Ежемесячный аудит по этому чек-листу и heartbeat-мониторинг превращают иллюзию в реальность.

Парадокс автоматизации: чем больше систем работает без участия человека, тем важнее человеческий контроль над тем, что они производят. 19 агентов — это не 19 причин расслабиться, это 19 точек, каждая из которых требует подтверждения результата. Дата следующего аудита уже стоит в календаре — первый понедельник июня. Это 15 минут на проверку счётчиков и 90 минут на полный прогон. Дешевле, чем ещё одна тихая поломка на 3 недели.