Максим Дорохов 
Как настроить уведомления о падении сайта, чтобы не пропустить инцидент
Мониторинг, который просто «видит», что сайт упал, но не может достучаться до нужного человека вовремя, почти бесполезен. Разбираем, как настроить уведомления так, чтобы о падении узнали за минуты, а не когда об этом напишет клиент в поддержку.
Из чего состоит цепочка уведомления
От момента падения сайта до реакции человека проходит несколько шагов, и на каждом можно потерять время: сайт перестал отвечать → мониторинг это заметил на следующей проверке → отправил уведомление → человек его увидел → начал разбираться. Настройка уведомлений — это работа именно с третьим и четвёртым шагом: как быстро сигнал доходит и насколько он заметен.
Что писать в уведомлении, а что — нет
Хорошее уведомление о падении — короткое и однозначное: что именно проверялось, какой адрес, когда зафиксировано изменение состояния. Задача — дать человеку решить за секунды, стоит ли бросать текущие дела и разбираться прямо сейчас.
Уведомление сообщает о смене состояния — «стало недоступно» или «снова доступно», а не выдуманные подробности вроде точного времени отклика или причины сбоя, которых система на самом деле не знает. Причину падения всё равно выясняют по логам и метрикам сервера — уведомление лишь указывает, что и когда стоит проверить.
Один канал — точка отказа
Если уведомления идут только на один канал — например, только на почту — у этого есть явный риск: письмо может потеряться в спаме или остаться непрочитанным часами, если человек не проверяет ящик постоянно. Для инцидента, который считают на минуты, это недопустимая задержка. Разбор того, какой канал для чего подходит и как выстроить резервирование — отдельная тема, здесь остановимся на самой цепочке настройки.
Кому и что должно приходить
Дежурному инженеру или ответственному за сайт — все инциденты сразу, по самому быстрому каналу.
Руководителю или владельцу бизнеса — не каждое короткое колебание, а только продолжительные или повторяющиеся инциденты: иначе поток уведомлений начнут игнорировать все получатели, включая того, кому действительно нужно реагировать.
Общему рабочему чату команды — уведомления о восстановлении, чтобы все видели, что инцидент закрыт, а не гадали, чинят ли его ещё.
Частая ошибка — настроить и забыть
Контакты меняются: сотрудник, который отвечал за сайт, увольняется, номер телефона меняется, доступ к почте теряется. Уведомления, настроенные однажды и не пересмотренные полгода, рискуют улетать в никуда именно в момент реального падения. Стоит раз в квартал сверять список получателей с тем, кто реально сейчас отвечает за сайт.
Пруфен отправляет уведомления сразу по нескольким каналам: Telegram, Макс, Email и звонком — можно назначить свою комбинацию под разные типы проверок и разных получателей. Уведомление приходит при смене состояния («стало недоступно» / «снова доступно») по всем настроенным типам проверок из 13 точек мониторинга.
Частые вопросы
Сколько времени должно пройти перед тем, как считать сайт упавшим? Зависит от выбранного интервала проверки: чем короче интервал, тем быстрее приходит первое уведомление. Обычно достаточно одного неудачного опроса, если проверка идёт из нескольких точек одновременно и недоступность подтверждается большинством из них, а не одной случайной.
Нужно ли уведомление о восстановлении отдельно от уведомления о падении? Да, и это часто забывают настроить. Без уведомления о восстановлении команда либо продолжает разбираться с уже решённой проблемой, либо узнаёт о факте восстановления только вручную, зайдя на сайт проверить.
Как избежать усталости от уведомлений? Разделяйте критичные и некритичные проверки по разным каналам и получателям, и не отправляйте одно и то же сразу всей команде без надобности — точечная адресация уведомлений работает лучше, чем рассылка всем и по всем поводам.
Что делать, если ответственный человек недоступен? Здесь и нужен резервный канал и второй получатель — если основной способ связи не сработал за разумное время, уведомление должно уйти дальше, а не остаться без ответа до утра.