Система оповещений умирает одинаково: сначала включают всё подряд, потом поток становится фоном, потом пропускают важное. Лечится это не фильтрами, а тремя обязательными атрибутами у каждого правила — приоритет, владелец и срок реакции.
Назначьте приоритеты
Больше трёх уровней не нужно — их перестают различать.
- Критично: работа остановлена или остановится в ближайшие часы. Машина не выходит на связь, на диске меньше 5%, отказ основного сервиса. Реакция — сразу.
- Важно: проблема гарантированно проявится, но не сегодня. Диск меньше 15%, устойчивая высокая нагрузка. Реакция — в течение рабочего дня.
- К сведению: полезно знать, действия не требует. Такие вещи лучше не отправлять оповещением вовсе, а смотреть в сводке раз в неделю.
Правило, которое не попадает ни в первый, ни во второй уровень, скорее всего не должно быть оповещением.
Добавьте владельца и срок
У каждой машины — ответственный человек. У каждого уровня — срок, после которого срабатывает эскалация. Без владельца оповещение адресовано всем, а значит никому: каждый считает, что посмотрит другой.
Эскалация не должна быть сложной. Достаточно правила: критичное, не взятое в работу за 30 минут, уходит руководителю; важное, висящее сутки, попадает в еженедельный разбор.
Кто владеет какой машиной — вопрос инвентаризации, и он решается раньше оповещений. Как её выстроить, разобрано в статье о заведении устройств в парк.
Боритесь с усталостью от оповещений
Усталость наступает, когда большинство срабатываний не требует действий. Дальше человек начинает закрывать их не читая — и однажды закроет важное.
- Раз в месяц смотрите статистику: какие правила срабатывали чаще всего и сколько раз это привело к работе.
- Правило, давшее десять срабатываний и ноль действий, меняйте или выключайте. Оставлять его «на всякий случай» — значит обесценивать все остальные.
- Группируйте однотипные срабатывания в одно уведомление: сорок машин, одновременно ушедших в offline, — это одно событие про сеть, а не сорок событий про машины.
- Добавляйте длительность к реактивным метрикам, чтобы не ловить каждый пик нагрузки.
- Планируйте окна обслуживания: оповещения во время известного обновления — чистый шум.
Улучшайте правила по факту
Каждый пропущенный инцидент — повод спросить, какое правило поймало бы его раньше. Каждое надоевшее оповещение — повод спросить, что с ним не так. Это единственный способ прийти к набору правил, который читают. Как выбирать сами пороги, разобрано отдельно в статье о значениях CPU, памяти и диска.
Пороги, по которым оповещение вообще возникает, задаются там же, где ведётся наблюдение за парком — в кабинете RMM.
Куда лучше отправлять оповещения — в почту или в мессенджер?
Туда, где человек их действительно прочитает, и это зависит от команды. Важнее канала другое: критичные и информационные сообщения должны идти разными путями. Когда всё падает в один поток, важное тонет в рутинном независимо от того, насколько удобен канал.
Что делать с оповещениями в нерабочее время?
Заранее решить, какие из них вообще имеют право разбудить человека, — и таких должно быть мало. Всё остальное копится до утра. Если ночью приходит оповещение, по которому всё равно ничего не сделают до начала рабочего дня, оно не должно приходить ночью.