Обновление AUTOMATA CRM: мониторинг сайтов и дежурный агент, который сам разбирает инциденты

Сайт упал — и узнаёшь об этом не от клиента, а от попапа на своём рабочем столе. Через полторы минуты в CRM уже лежит тикет с причиной, а через пятнадцать — отчёт агента: что проверил, что нашёл, что нужно от тебя. Именно так теперь выглядит дежурство в AUTOMATA CRM.

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

Что изменилось

Обновление затрагивает три слоя, и каждый можно использовать отдельно.

Мониторинг. Все 17 сайтов — свои проекты и клиентские — переехали на Uptime Kuma, который мы держим на собственном сервере. Проверка раз в 60 секунд, два ретрая на сетевую ошибку, отдельно контролируются срок сертификата и срок домена. История проверок хранится у нас, а не в чужом облаке: видно, что было позавчера в три ночи, а не только «сейчас всё хорошо».

Дашборд. В CRM на вкладке «Сегодня» появился блок «Мониторинг»: статус, uptime за последние сто проверок, время ответа, дни до истечения SSL и домена — по каждому сайту, включая клиентские. Ушла простыня из чужого интерфейса: смотреть надо туда, где ты и так работаешь.

Инциденты. Каждое падение превращается в тикет с клиентом, приоритетом и SLA. Но тикет — это только половина. Вторая половина — автодиагностика и агент-дежурный, о которых ниже.

Как это работает: путь одного падения

Схема проста настолько, что её можно пересказать одной фразой: монитор заметил — демон записал — CRM завела тикет — агент разобрал.

1. Обнаружение. Uptime Kuma проверяет сайт раз в 60 секунд. Сетевые сбои не считаются падением сразу: два ретрая отсекают случайные таймауты и мусорные ответы.
2. Переход. Демон на рабочей машине держит постоянное соединение с монитором и в момент смены состояния «работает → не отвечает» пишет событие в ленту. Никакого опроса «а живой ли сайт» — только переходы, поэтому ложных уведомлений нет.
3. Тикет. Событие обрабатывает CRM: создаёт критический тикет на домен, прикрепляет текст ошибки (timeout, ENOTFOUND, 502), ставит SLA на час, отправляет событие в ленту и показывает системное уведомление на рабочем столе. Если по домену уже открыт инцидент — второй не создаётся.
4. Автодиагностика. Через несколько секунд после тикета к нему дописывается таблица фактов: DNS локально и с сервера, HTTP с ноутбука и с сервера, сколько дней сертификату, свободное место на диске, состояние веб-сервера, последние строки ошибок по домену. Скрипт делает пять-девять проверок и формулирует гипотезу: «DNS», «сервер/приложение», «VPS недоступен», «истекает сертификат», «диск», «локальный канал».
5. Агент. Каждые пятнадцать минут в рабочие часы дежурный агент смотрит, есть ли новые инциденты. Если есть — уточняет причину по логам, дописывает в тикет разбор, пишет запись в журнал и, если требуется действие человека, звонит попапом. Если нет — завершается одной строкой и не тратит ресурсы.
6. Закрытие. Сайт поднялся — CRM сама закрывает тикет и снимает инцидент с разбора. Ручных действий не требуется.

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

Что именно проверяет автодиагностика

Смысл в том, чтобы к моменту, когда человек открыл тикет, не нужно было начинать с нуля. Набор проверок подобран по типовым сбоям, которые мы видели на своих и клиентских сайтах:

Проверка	Что выявляет
DNS локально и с сервера	домен истёк, NS сменились, парковка, ошибка в зоне
HTTP с ноутбука и с сервера	сайт лежит для всех или только для одного канала
SSL и дни до истечения	сертификат не продлился, цепочка не собирается
Свободное место	диск забит логами или бэкапами — классика ночного падения
Состояние nginx и failed-юниты	упавший сервис, застрявший certbot, сломанный туннель
Выжимка error.log по домену	connect() failed, 502 от апстрима, таймауты PHP

Дальше — правило: если HTTP с сервера отвечает, а с ноутбука нет, проблема не в сайте, а в локальном канале. В этом случае агент не запускается вовсе: незачем будить человека и создавать тикет из-за упавшего домашнего интернета. Обратная ситуация — сайт не отвечает с обеих точек — сразу даёт гипотезу «сервер/приложение» и сужает поиск до логов.

Агент с границами

Главный вопрос к любому «ИИ-дежурному»: а что он сделает без спроса? У нас ответ жёсткий. Агент имеет право читать логи, диагностировать, повторять проверки и делать только безопасные действия. Рестарты сервисов, правки конфигурации веб-сервера, любые денежные решения и письма клиентам — запрещены без подтверждения владельца. Если для устранения нужен рестарт, агент не делает его сам: он пишет в тикет «требуется действие владельца» и показывает критическое уведомление.

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

Почему попап, а не Telegram

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

Это не значит «никаких мессенджеров». Это значит: мессенджер — удобный дополнительный канал, а не единственный. Оповещение об аварии не должно иметь единой точки отказа.

Что это даёт бизнесу

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

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

Третье — масштаб без роста рутины. Восемнадцать сайтов глазами не проверишь. При этом добавить девятнадцатый — это одна строка в мониторинге, а не новый процесс. Именно поэтому клиентские сайты входят в тот же контур: мониторить своих клиентов мы обязаны, а не «по возможности».

И четвёртое — честный SLA. У тикета есть срок, у инцидента — причина, у закрытия — время. Когда через месяц спросят «что было в ночь на среду», ответ находится за десять секунд, а не в переписке.

Чего это не заменяет

Мониторинг проверяет доступность, а не смысл. Сайт может отдавать 200 и при этом показывать нулевые цены, пустой каталог или не пропускать заказ. Это — бизнес-логика, и её ловят другим инструментом: push-проверками. Скрипт синхронизации остатков с 1С отработал — отправил сигнал в мониторинг; не отправил за сутки — инцидент «синхронизация не запускалась». Так же контролируются бэкапы, продление сертификатов и публикация контента. Следующий шаг обновления — как раз этот класс проверок.

Как повторить у себя

Схема не требует коробочного продукта и подписки:

1. Поставьте Uptime Kuma на свой сервер (Docker, один контейнер) и заведите все сайты с интервалом 60 секунд.
2. Включите уведомления о сроке домена и сертификата — это бесплатные проверки, которые чаще всего спасают репутацию.
3. Напишите маленький демон, который держит websocket к мониторингу и фиксирует только переходы «вверх → вниз»; на переходах создавайте задачи в своей системе.
4. Добавьте автодиагностику из таблицы выше — даже без всякого ИИ она снимает половину рутины.
5. Если добавляете агента, сначала опишите запреты: что он не делает без человека. Скорость появляется от разрешённых действий, а доверие — от запрещённых.

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

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