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

Какие события нужно отслеживать

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

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

• сайт недоступен или отдаёт 5xx
• сайт восстановился после сбоя
• TTFB выше нормального порога
• SSL скоро истечёт или уже истёк
• сервер перестал присылать heartbeat

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

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

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

• владелец получает критичные события и восстановление
• технический специалист получает статус, TTFB и контекст
• поддержка получает события по клиентским сайтам
• несколько получателей снижают риск пропустить инцидент

Как избежать лишнего шума

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

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

• подтверждайте инцидент несколькими проверками
• разделяйте критичные и обычные URL
• не дублируйте одно и то же событие каждую минуту
• отправляйте восстановление отдельным событием

Что должно быть внутри уведомления

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

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

• название сайта или сервера
• проверяемый URL или метрика
• статус, TTFB, SSL или порог
• время начала и восстановления
• краткая подсказка, что проверить

Как проверить, что уведомления работают

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

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

• проверьте доставку до каждого получателя
• убедитесь, что сообщение понятно без дополнительных объяснений
• проверьте событие восстановления
• пересмотрите правила после реальных инцидентов

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

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

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

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

• назначьте владельца реакции на каждый тип события
• разделите технические и клиентские уведомления
• фиксируйте восстановление и комментарии к инциденту
• используйте историю как основу для отчётов поддержки