Работает ли сайт: мониторинг uptime и управление инцидентами
Как быстро бизнес сам замечает, что его сайт упал; как настроить мониторинг uptime, цепочку оповещений и разбор инцидента, который реально прочитают.
Команда rabbitclipПубликация: 4 мин чтения
Коротко
Мониторинг uptime — это внешняя проверка, которая работает по расписанию и фиксирует, отвечает ли сайт или приложение на самом деле. Простая проверка смотрит только, загружается ли главная страница; более надёжная настройка тестирует реальную операцию, оплату, вход, отправку формы, по тому же расписанию. Смысл в том, чтобы заметить сбой раньше клиента, а это работает только если оповещение заранее определено: кому оно приходит, по какому каналу, за какое время.
Если страница оплаты у производителя рабочей одежды начинает выдавать ошибки в воскресенье утром, это может остаться незамеченным часами, если первым сигналом становится жалоба клиента. Проверка, которая следит за самим процессом оплаты, ловит ту же неисправность за несколько минут и уведомляет нужного человека; разница именно между многочасовой потерей и реакцией за несколько минут.
Что на самом деле измеряет мониторинг uptime?
Мониторинг uptime — это запись того, отвечает ли сервер или страница, опрашиваемая с внешней контрольной точки по расписанию, обычно раз в одну-пять минут, вообще хоть что-то. Ответ должен и существовать, и нести ожидаемое содержимое, правильный код статуса, конкретный текст на странице; просто доступности сервера самой по себе недостаточно, страница должна реально работать.
Такая проверка хорошо ловит сервер, который полностью упал или перестал отвечать, но не всегда замечает замедление, частичную ошибку или проблему, которая проявляется только в одном браузере. Поэтому мониторинг uptime дополняет отслеживание ошибок и мониторинг производительности, а не заменяет их.
Какая проверка ловит какую проблему?
Разные типы проверок покрывают разные риски; выбор одной не делает остальные ненужными.
- ping/HTTP проверка: отвечает ли сервер вообще, за несколько секунд
- проверка содержимого: правильно ли загрузилась страница, по конкретному тексту или коду статуса
- синтетическая проверка: работает ли многошаговый процесс вроде оплаты, входа или отправки формы от начала до конца
- проверка SSL сертификата: сколько времени осталось до истечения срока сертификата
Как выстроить цепочку оповещений
Оповещение, которое не доходит ни до кого, или доходит до всех сразу так, что никто не берёт ответственность, это место, где мониторинг чаще всего подводит на практике. Ступенчатая эскалация снижает этот риск.
- первичное обнаружение: автоматическая проверка подтверждает сбой за 2-3 подряд идущие попытки, чтобы разовый сетевой сбой не приняли за настоящую аварию
- 0-5 минут: мгновенное уведомление дежурному, в приложении или по почте
- 5-15 минут: если ответа нет, приходят СМС или звонок, и уведомляется второй человек
- после 15 минут: подключается руководитель, обновляется страница статуса
Что происходит во время сбоя?
Первая задача, как только сбой замечен, не устранить его, а понять масштаб: упал весь сайт или только часть, сколько пользователей затронуто, когда это началось. Действия без этой информации рискуют исправить не то место, упустив реальную причину.
Публичная страница статуса окупается именно в этот момент; она позволяет поддержке направлять каждого клиента на одну актуальную страницу вместо ответа каждому по отдельности. Страницу нужно обновлять до конца сбоя и закрывать после его устранения.
Почему разбор после инцидента нельзя пропускать
После устранения сбоя пишется короткий разбор: что произошло, когда это заметили, сколько времени заняло исправление, что изменится, чтобы это не повторилось. Документ существует для предотвращения повтора, а не для поиска виноватых.
Если система бронирования сети спа-салонов падает подряд дважды по одной и той же причине, проблема не техническая, а процессная; то, что первый разбор требовал исправить, так и не было применено на деле. Второй сбой по той же причине заслуживает более серьёзного отношения, чем первый, а не менее серьёзного.
Частые ошибки
Мониторинг uptime может превратиться в инструмент, который однажды настроили и забыли; это случается почти так же часто, как сбои, которые он должен ловить.
- следить только за главной страницей, оставляя оплату или вход без наблюдения
- отправлять оповещения только одному человеку, из-за чего его отсутствие никто не замечает
- проверять слишком редко, например раз в тридцать минут, полностью упуская короткие сбои
- переходить сразу к следующему кризису, не сделав разбор после инцидента
Мониторинг uptime не предотвращает сбой; он делает так, чтобы его заметили раньше клиента и справились с ним организованно. Хорошо выстроенная цепочка оповещений и привычка к короткому разбору после инцидента сокращают длительность следующего сбоя. Первый разговор с rabbitclip хорошее место, чтобы вместе пересмотреть вашу текущую настройку мониторинга.
Частые вопросы
Можно ли настроить мониторинг uptime бесплатными инструментами?
Да, базовую ping/HTTP проверку покрывают многие бесплатные тарифы. Синтетический мониторинг и более частые проверки обычно доступны в платных тарифах.
Как часто должны запускаться проверки?
Для критичных страниц обычна частота от одной до пяти минут. Более частые проверки замечают проблемы раньше, но добавляют нагрузку и на сервер.
Нужна ли страница статуса каждому сайту?
Она оправдана для сайтов с большим взаимодействием с клиентами и для интернет-магазинов. Сайт-визитка с низким трафиком может обойтись без неё.
Разбор после инцидента нужен для поиска виноватых?
Нет. Цель, предотвратить повтор; разбор изучает процесс и систему, а не человека.
