Как настроить уведомления о падении сайта

Минимальный набор событий для сайта: недоступность, HTTP 5xx, высокий TTFB, истечение SSL, проблема с доменом, восстановление после сбоя. Для серверов добавляются heartbeat, CPU, RAM, диск и другие инфраструктурные метрики. Важно не смешивать все события в один поток, потому что у них разные ответственные.

Для бизнеса особенно важны события, которые влияют на заявки, продажи и доступ в личный кабинет. Если сломалась второстепенная страница, это неприятно. Если не работает форма заявки или оплата, это уже критичный инцидент, который должен прийти быстрее и нужным людям.

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

Если сайт обслуживает веб-студия или подрядчик, уведомления помогают не узнавать о падении от клиента. Но важно, чтобы уведомление содержало достаточно контекста: какой сайт, какой URL, статус, время, что изменилось и есть ли восстановление.

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

Шум также возникает, когда один и тот же инцидент отправляется много раз. Лучше группировать повторяющиеся события, показывать текущее состояние и отправлять отдельное уведомление о восстановлении. Так команда видит жизненный цикл проблемы, а не поток одинаковых сообщений.

Хорошее уведомление отвечает на вопросы: что случилось, где случилось, когда началось, насколько это критично и что проверить дальше. Сообщение “сайт упал” полезно меньше, чем “URL вернул 502, TTFB недоступен, проверка не прошла 3 раза подряд, последний успешный ответ был 2 минуты назад”.

Для SSL полезно показывать дней до истечения. Для TTFB — фактическое значение и интерпретацию. Для сервера — метрику и порог. Для восстановления — сколько длился инцидент. Чем меньше нужно открывать дополнительных систем, тем быстрее реакция.

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

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

Уведомления работают лучше, когда они связаны с понятным процессом. Нужно заранее договориться, кто реагирует в рабочее время, кто подхватывает критичные события вечером, какие инциденты требуют связи с клиентом, а какие остаются внутренней технической задачей. Без этого даже точное уведомление может зависнуть без реакции.

Для веб-студии или команды поддержки полезно вести историю по каждому клиентскому сайту. Тогда при разговоре с клиентом можно показать не только факт сбоя, но и длительность, восстановление, повторяемость и принятые меры. Это повышает доверие и снижает количество хаотичных сообщений в чатах.

Отдельно стоит описать правила эскалации. Например, недоступность главной страницы дольше нескольких минут уходит техническому специалисту и менеджеру, ошибки оплаты — владельцу продукта, а предупреждение по SSL — ответственному за домен и инфраструктуру. Чем конкретнее маршрут уведомления, тем меньше вероятность, что критичный сигнал потеряется. Это особенно важно ночью, в праздники и при распределённой команде.