Содержание
Мониторинг доступности сайта это автоматическая проверка, которая каждые несколько минут убеждается, что сайт открывается и работает, и сразу сообщает ответственному, если что-то сломалось. Хороший мониторинг проверяет не только главную страницу, но и то, на чём бизнес зарабатывает: корзину, оплату, формы заявок, обмен с 1С. Его задача простая: вы должны узнавать о сбое раньше клиентов. Базовые проверки настраиваются за час, остальное можно добавлять постепенно.
Почему проверки главной страницы мало
Самый простой мониторинг раз в минуту открывает главную страницу и проверяет, что сервер ответил кодом 200. Это лучше, чем ничего, но такой мониторинг пропустит большую часть реальных сбоев:
- главная открывается, а оплата падает с ошибкой у платёжного шлюза;
- сайт работает, а заявки с формы не доходят до почты и CRM;
- каталог показывает товары, а обмен с 1С остановился три дня назад, и цены устарели;
- страница отдаёт код 200, но вместо содержимого на ней сообщение об ошибке базы.
О таких сбоях обычно сообщают клиенты, и часто через несколько часов или дней. Всё это время бизнес теряет деньги.
Пять уровней мониторинга
- Доступность. Сайт отвечает, время ответа в норме, на странице есть ожидаемый текст, а не сообщение об ошибке.
- Ключевые сценарии. Робот проходит путь клиента: ищет товар, кладёт в корзину, доходит до оплаты, отправляет тестовую заявку.
- Ошибки приложения. Рост ошибок в логах, сбои запросов к внешним сервисам. Для этого есть системы сбора ошибок, которые присылают каждую новую ошибку с подробностями.
- Сервер и ресурсы. Место на диске, память, нагрузка на процессор, очередь фоновых задач, статус бэкапов.
- Бизнес-метрики. Число заказов и заявок в час. Если в рабочее время их ноль, что-то сломано, даже если все технические проверки зелёные.
Что проверять: чек-лист
Минимальный набор проверок для сайта, который приносит деньги:
| Проверка | Как часто | Зачем |
|---|---|---|
| Главная и 2-3 ключевые страницы открываются, на них есть нужный текст | Каждые 1-5 минут | Сайт доступен и показывает содержимое |
| Время ответа | Каждые 1-5 минут | Медленный сайт теряет клиентов раньше, чем падает |
| Срок SSL-сертификата | Раз в день | Предупреждение за 14-30 дней до истечения |
| Срок регистрации домена | Раз в день | Предупреждение за 30-60 дней |
| Форма заявки и оплата | Каждые 15-60 минут | Деньги и заявки идут через них |
| Обмен с 1С, CRM, складом | После каждого запуска | Тихие сбои интеграций самые дорогие |
| Место на диске и память | Каждые 1-5 минут | Предупреждение при заполнении на 80% |
| Бэкап прошёл | После каждого бэкапа | Без этого о проблеме узнают в день аварии |
| Заказы или заявки в час | Каждый час | Последняя линия: ловит то, что пропустили остальные |
Инструменты мониторинга
Выбор инструмента вторичен: главное, что именно вы проверяете и кто получает сигналы.
| Инструмент | Что умеет | Кому подходит |
|---|---|---|
| Внешние сервисы проверки доступности | Проверяют сайт из разных точек, присылают уведомления | Быстрый старт для любого сайта |
| Uptime Kuma | Открытая система, ставится на свой сервер, проверки и уведомления в мессенджеры | Тем, кто хочет держать мониторинг у себя |
| Zabbix | Мониторинг серверов, сервисов и сайтов, гибкие триггеры | Компаниям с несколькими серверами |
| Prometheus, Grafana, Alertmanager | Метрики, графики, правила оповещений | Сервисам с серьёзной нагрузкой |
| Sentry и аналоги | Сбор ошибок приложения с подробностями | Сайтам и сервисам на собственном коде |
Важная деталь: внешний мониторинг должен работать не на том же сервере, что и сайт. Иначе при падении сервера упадёт и мониторинг, и вы не узнаете о проблеме.
Как настроить оповещения, чтобы их не игнорировали
Плохо настроенный мониторинг хуже отсутствующего: если алерты приходят по десять раз в день без причины, их перестают читать, и настоящая авария тонет в шуме.
- Пороги с запасом. Алерт только после двух-трёх неудачных проверок подряд, а не после одной.
- Уровни важности. Критичное (сайт лежит, оплата не работает) будит дежурного ночью. Предупреждения (диск заполнен на 80%) ждут утра.
- Конкретный получатель. Не общий чат, а дежурный инженер с понятным сроком реакции.
- Эскалация. Если дежурный не подтвердил алерт за 15 минут, сигнал уходит следующему.
- Разбор ложных срабатываний. Каждый ложный алерт повод поправить проверку.
Что делать, когда пришёл алерт
Срок, за который дежурный реагирует на алерт, должен быть записан в договоре на поддержку. В SLA это называется временем реакции, подробнее в статье «SLA: что это простыми словами». После восстановления каждый серьёзный сбой разбирают до первопричины, чтобы он не повторился. Как это делать, читайте в статье про root cause analysis.
Мониторинг в поддержке ИнТерраТех
На нашей поддержке мониторинг ставится в первые дни после подключения: доступность, ключевые сценарии, сертификаты, ресурсы сервера и бэкапы. Критичный инцидент берём в работу в течение 2 часов. Если вам нужен только присмотр без регулярных доработок, есть формат базового сопровождения: мониторинг доступности, бэкапы и реакция на инциденты.
Частые вопросы
Что такое мониторинг доступности сайта?
Это автоматическая проверка, которая регулярно открывает сайт и его ключевые страницы и сообщает ответственному, если сайт не отвечает, работает медленно или показывает ошибку.
Как часто проверять доступность сайта?
Для сайтов, которые приносят деньги, каждые 1-5 минут. Сроки сертификата и домена достаточно проверять раз в день, а сложные сценарии вроде оплаты раз в 15-60 минут.
Можно ли настроить мониторинг бесплатно?
Да. Есть бесплатные тарифы внешних сервисов и открытые системы вроде Uptime Kuma и Zabbix, которые ставятся на свой сервер. Сам мониторинг стоит недорого, основные расходы приходятся на людей, которые реагируют на алерты.
Сайт не работает: что делать?
Проверьте, открывается ли он с другого устройства и через мобильный интернет. Если нет, сообщите подрядчику или хостингу и проверьте, не истёк ли домен и SSL-сертификат. Если такое повторяется, нужен мониторинг и поддержка со сроками реакции в договоре.
Чем мониторинг отличается от технической поддержки?
Мониторинг только замечает проблему. Поддержка реагирует на неё, восстанавливает работу и устраняет причину. Одно без другого работает плохо, поэтому их обычно объединяют. Подробнее в статье «Техническая поддержка сайта: что входит и сколько стоит».
