Мониторинг оборудования: тревога, которая не теряется

Разбор по мотивам реального производственного проекта — без названия компании, поставщика оборудования и цифр. Для руководителей, у которых датчики есть, а реакции на них нет.

Проблема не в датчиках

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

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

1. Тревога с кнопкой «Принял»

Событие от контроллера уходит ответственным в Telegram. У сообщения — кнопка «✅ Принял». Нажали — у всех получателей сообщение обновляется: видно, кто взял. Никаких «а кто-нибудь посмотрел?» в общем чате.

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

2. Эскалация по рабочим часам, а не по календарю

Если тревогу никто не взял за оговорённое время, она уходит руководителю вместе с историей: кому ушла, когда, что случилось. Важная деталь — считать рабочие часы, а не календарные. Тревога в пятницу вечером не должна будить директора ночью субботы из-за того, что «прошло 3 часа». Правило задаётся явно: например, будни 8:00–17:00 и 3 рабочих часа на реакцию.

Одно событие эскалируется один раз — повторные напоминания каждые 10 минут быстро превращаются в шум.

3. Кратковременное превышение ≠ авария

Если каждое короткое превышение держать «открытым» до ручного закрытия, журнал к утру забит, и люди перестают смотреть. Поэтому события делятся на два вида:

• кратковременные — фиксируются, попадают в сводку, но не висят открытыми;
• аварии — открыты, пока их не закрыли вручную или пока система не увидела восстановление.

4. Сверка с системой поставщика

Уведомления от оборудования ненадёжны: что-то не доставляется, а о восстановлении система часто вообще не сообщает. Поэтому раз в несколько минут идёт сверка через API системы мониторинга (только чтение):

• закрывает восстановившиеся события и правит исходное сообщение у всех: «🟢 Закрыто автоматически — причина, время», кнопки убираются;
• добирает события, которые система не доставила, и отправляет их тем же путём, что и обычные;
• пишет последние показания для сводки и приложения.

Два предохранителя, без которых авто-закрытие опасно: не закрывать совсем свежие события (первые минуты данные ещё «гуляют») и не закрывать ничего, если сам блок мониторинга не на связи — отсутствие аварии в данных ещё не значит, что аварии нет.

5. Мониторинг, который проверяет сам себя

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

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

6. Повторяющиеся проблемы и гипотезы причин

Отдельные тревоги не показывают картину. Раз в день журнал прогоняется через простые детекторы:

• узел часто теряет связь;
• аварии повторяются в одно и то же время суток (часто это плановый цикл оборудования, пересменка или график нагрузки);
• частота заметно выросла по сравнению с прошлыми месяцами;
• событие висит без реакции слишком долго;
• раньше было часто, а теперь стихло — стоит понять, почему.

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

7. Люди тоже часть системы

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

Кейс на сайте: Мониторинг оборудования на производстве. Смежный гайд: интеграция 1С с ИИ.