200 OK — не признак жизни
На Хабре реализовали, как проверка доступности сайтов может вводить в заблуждение. Даже ответ 200 OK не гарантирует, что сайт работает для клиента — и это уже не техническая ошибка, а упущенная выручка.
Сайт отвечает 200, но форма заявки не работает. Цены исчезли из карточек. На экране — «Сайт на техническом обслуживании». И всё это с кодом 200. Всё, что нужно, — проверить, что отдаёт сервер, а не только статус. Мы в Cetera видим это как системную уязвимость: бизнес теряет клиентов, потому что система не понимает, что сайт уже не тот, что был.
Самый простой способ проверки — код ответа. Он ложится. И не потому, что система сломана, а потому, что она не умеет отличать «работает» от «выглядит, как работает». Когда клиент видит «всё работает», он не знает, что его запрос не дошёл. И не возвращается.
Считаю, что это ключевая проблема для интернет-магазина: если вы полагаетесь только на статус 200, вы не видите, что клиент уже ушёл. Не потому, что сайт упал, а потому, что он стал неработоспособным.
Что значит «работает» в реальности
Сайт не просто должен ответить. Он должен отдать то, что нужно клиенту. Это может быть форма, цена, кнопка, текст. Проверка, которая смотрит только на код, не видит разницы между «всё в порядке» и «всё в порядке, но не то, что нужно». Пример из практики — страница, которая отдаёт 200, но содержит заглушку хостинга. Для сервера — всё нормально. Для клиента — конец пути.
Важно не только, отвечает ли сервер, но и что он отдаёт. В том же коде 200 может быть пустое тело, битый HTML, или просто текст, который не соответствует ожиданиям. Проверка должна искать не только наличие ответа, но и его содержание. И делать это не в лоб, а с учётом того, что страница может быть большой, а фраза — в начале.
Когда мы проектируем мониторинг для клиентов, мы не ограничиваемся статусом. Мы задаём ключевые элементы: заголовок, кнопку, текст в верхней части. Проверяем их не только в ответе, но и в нормализованном виде — с учётом пробелов, регистра, переносов. Иначе фраза «Оставить заявку» может быть пропущена из-за одного пробела.
Раньше — статус, теперь — поведение
Раньше проверка была простой: 200 — работает, всё остальное — упал. Теперь понятно, что это упрощение. Сайт может быть «в сети», но не выполнять свою задачу. Ошибка — не в том, что он не отвечает, а в том, что он отвечает неправильно.
Сейчас проверка выделяет не только статус, но и тип сбоя. Есть «fail» — когда сервер ответил, но плохо: 5xx, 4xx, пустое тело. Есть «infra_error» — когда сбой у монитора, а не у сайта. Есть «unknown» — когда неясно, что происходит. Такой подход позволяет не реагировать на ложные тревоги, но не пропускать настоящие.
Ключевое изменение — понимание, что «не ответил» не всегда значит «упал». Сеть могла моргнуть, прокси — упасть, DNS — задержаться. Но сайт, возможно, стоял. И если мы будем реагировать на каждый сбой, мы сами станем источником шума. Поэтому проверка должна быть умной: повторять, но не ждать, и не отправлять уведомления без смены состояния.
Кто это касается — и как понять, что про ваш бизнес
Это касается любого, кто зависит от сайта как от канала продаж. Не только тех, кто мониторит, но и тех, кто считает, что «всё работает, если 200». Если у вас есть интернет-магазин, маркетплейс, сайт красоты — вы не просто «сайт», вы — точка входа клиента.
Если вы не проверяете, что отдаёт сайт, вы не знаете, когда клиент уже ушёл. И не можете это исправить. Каждый момент, когда сайт «работает» по 200, но не отвечает на запрос, — это потеря клиента.
Понять, что это про ваш бизнес, можно по вопросу: «А что, если сайт отдаёт 200, но клиент не может оформить заказ?» Если вы не задавали этот вопрос — значит, вы ещё не проверяете, что сайт на самом деле делает.
Что с этим делать — порядок действий
Не полагайтесь только на статус 200. Проверка должна включать не только ответ сервера, но и содержание. Укажите ключевые элементы: заголовок, кнопку, текст, который видит клиент.
Используйте нормализацию: приводите текст к одному виду — убирая лишние пробелы, переносы, приводя к нижнему регистру. Иначе проверка не сработает даже на простых фразах.
Обрабатывайте таймауты правильно. Не полагайтесь на внутренние лимиты — устанавливайте общий таймаут для всего запроса. Иначе сайт, который отдаёт по байту в секунду, будет «работать» бесконечно.
Не отправляйте уведомления за каждый сбой. Привяжите их к смене состояния: «упал» — уведомить, «восстановлен» — уведомить. И не отправляйте «восстановлен» без предшествующего «упал».
Что мы с этим делаем — и почему это важно
Мы работаем с клиентами более чем в 30 отраслях. И в каждом случае понимаем: сайт — это не сервер, это канал продаж. Если он не работает для клиента, он не работает вообще.
Когда мы проектируем систему мониторинга, мы не ограничиваемся статусом. Мы проверяем, что отдаёт сайт, и как это воспринимает пользователь. Мы учитываем таймауты, нормализацию, контент, поведение. Потому что 200 OK — не признак жизни. Это только сигнал, что сервер открыл дверь.
Именно поэтому мы не просто «отслеживаем» сайт. Мы проверяем, что он делает. И если он не делает то, что нужно — мы это видим. А значит, можем исправить до того, как клиент уйдёт. Если хотите понять, как это выглядит у вас, — давайте обсудим вашу задачу.
Это часть нашей работы — Администрирование. Поддерживаем сайты всех типов на CMS и фреймворках: Cetera CMS, Laravel, Yii2, InSales, «1С-Битрикс», Bitrix24, WordPress, WooCommerce, Ecwid, OpenCart, Drupal, Joomla, Magento2, Shopify и самописные системы на PHP и Python. Инфраструктура, развитие и продвижение включены. Администрирование
Автор: Святослав Семенов из Cetera Labs