Настройте уведомления не одинаково для всех проверок, а по влиянию сбоя на клиентов и работу сайта. Для критичного URL сигнал должен сразу попасть человеку, который может организовать проверку; важные, но не аварийные события можно разбирать в рабочем порядке, а информационные — планово.
Самый практичный способ — составить небольшую матрицу: что проверяем, какой пользовательский путь нарушен, кто отвечает, когда подключается запасной исполнитель и какое событие закрывает тревогу. Такая схема уменьшает шум и не даёт действительно важному письму потеряться среди второстепенных сообщений.
Почему критичность нельзя определять только по коду ошибки
Одинаковый HTTP-код может иметь разное значение. Ошибка на странице оплаты мешает завершить заказ, а такая же ошибка в старой записи блога затрагивает лишь часть посетителей. Поэтому уровень задают для конкретной проверки и пользовательского действия, а не для кода ответа вообще.
Начните с трёх вопросов:
- Что посетитель не сможет сделать при сбое?
- Есть ли рабочий обходной путь?
- Кто способен проверить причину или принять решение о дальнейших действиях?
Если ответы неизвестны, уведомление пока не готово к работе: адрес контролируется, но команда не понимает, как реагировать.
Три уровня, которых обычно достаточно
Для небольшого сайта удобна схема из трёх уровней.
| Уровень | Когда применять | Реакция | |---|---|---| | Критичный | Не открывается сайт или недоступен ключевой путь: заявка, вход, корзина, начало оплаты | Сигнал сразу получает основной ответственный; при отсутствии реакции подключается запасной | | Важный | Нарушена заметная функция, но пользователь может продолжить работу другим способом | Проверка ответственным в установленное командой рабочее время | | Информационный | Сбой затронул второстепенную страницу либо быстро завершился восстановлением | Запись остаётся для планового разбора повторяемости |
Не назначайте критичность «на всякий случай»: если всё объявлено аварией, приоритетов фактически нет.
Как настроить матрицу уведомлений
Шаг 1. Выпишите точные URL и ожидаемый результат
Не ограничивайтесь строкой «сайт работает». Укажите главную, страницу заявки, вход, каталог или другой адрес, который отражает важный путь посетителя. Рядом запишите, что считается нормой: успешный ответ, нужный текст на странице или доступность конкретного раздела.
Шаг 2. Присвойте уровень каждой проверке
Оценивайте не техническую сложность ошибки, а её последствия. Страница с небольшим трафиком может быть критичной, если через неё приходят все заявки. Популярный информационный материал, наоборот, может допускать плановую реакцию, если остальные разделы работают.
Шаг 3. Назначьте основного и запасного ответственного
У уведомления должен быть один понятный владелец реакции. Это не значит, что он обязан сам чинить сервер: его задача — подтвердить проблему, собрать первые признаки и передать её тому, кто отвечает за хостинг, код, DNS или содержание страницы.
Для критичных проверок укажите запасного человека. Общая рассылка всей команде хуже явной ответственности: каждый может решить, что уже реагирует кто-то другой.
Шаг 4. Разделите падение, восстановление и повторяемость
Письмо о падении запускает проверку. Сообщение о восстановлении показывает, что срочная фаза закончилась, но не отменяет последующий разбор. Серия коротких сбоев может быть важнее одного длинного инцидента, если она регулярно мешает посетителям.
Не удаляйте краткие события только ради тишины. Лучше снизить их срочность и сохранить историю, чтобы увидеть повторяемость.
Шаг 5. Зафиксируйте правило эскалации
Правило должно отвечать на простой вопрос: что делать, если основной ответственный не увидел сигнал или не смог подтвердить состояние сайта. Для небольшой команды достаточно записать получателя, запасного и способ связи, который уже используется в работе.
Не переносите универсальное время реакции из чужого шаблона. Для сайта-визитки, интернет-магазина и внутреннего кабинета последствия различаются, поэтому допустимый срок определяет владелец процесса.
Как не превратить уведомления в шум
Проверьте настройку по короткому списку:
- критичность привязана к URL и пользовательскому действию;
- одно событие не рассылается людям, от которых не требуется действие;
- восстановление приходит отдельно от падения;
- краткий сбой сохраняется в истории, даже если не требует общей тревоги;
- отчётные сообщения отделены от аварийных;
- у критичной проверки есть основной и запасной ответственный.
Если несколько проверок одновременно сообщают об одной аварии, заранее выберите главный сигнал. Остальные используйте для подтверждения причины, а не как одинаковый повод тревожить всю команду.
Примеры для разных сайтов
Для интернет-магазина критичными могут быть главная, вход и начало оформления заказа. Страница отдельной акции может получить важный или информационный уровень: решение зависит от того, ведёт ли на неё активная реклама и есть ли другой путь к покупке.
Для сайта услуг критичными обычно становятся главная и страница заявки. Раздел с примерами работ можно проверять в рабочем порядке, если его сбой не мешает отправить обращение. Это не готовые нормативы: итоговую классификацию определяет реальный путь клиента.
Как проверить схему до первого инцидента
Не нужно намеренно отключать production-сайт. Проверьте, что адреса получателей актуальны, письма не попадают в спам, ответственный понимает первые действия, а запасной знает, когда подключаться. Отдельно проговорите, кто подтверждает восстановление и где фиксируется причина сбоя.
Мониторинг не заменяет диагностику и не определяет бизнес-приоритет за владельца. Он сообщает о наблюдаемом состоянии, а правила критичности превращают этот сигнал в управляемое действие.
Что сделать дальше
Если базовые письма ещё не настроены, сначала прочитайте как получать уведомления о падении и восстановлении сайта. Для аварийной реакции пригодится отдельный план эскалации при падении сайта.
Затем выберите один действительно критичный URL и добавьте его в Web-Puls: начните с понятного ответственного и только после проверки схемы расширяйте список. Так уведомления останутся заметными, а команда будет понимать, какое действие требуется после каждого сигнала.