Почему аптайм 200 OK ничего не значит

Клиент звонит и говорит, что сайт не работает. Вы открываете мониторинг: за сутки ни одного инцидента, доступность 100 %, время ответа 240 мс. Открываете сайт — и видите то же, что клиент: пустую белую страницу, красный экран браузера или чужой текст на главной.

Противоречия здесь нет. Аптайм-мониторинг отвечал на свой вопрос честно: веб-сервер был жив и отдавал двухсотый код всё это время. Просто вопрос «отвечает ли сервер» и вопрос «работает ли сайт» — это разные вопросы, и совпадают ответы на них далеко не всегда.

Что на самом деле означает 200 OK

Код ответа выдаёт веб-сервер, а чаще — приложение за ним. Это утверждение ровно об одном: запрос принят и обработан без ошибки, ответ прилагается. Что именно в ответе, код не сообщает.

Отсюда весь список случаев, когда двухсотый код приходит с неработающего сайта:

• страница отдаёт шаблон с пустым содержимым, потому что отвалилась база или кэш;
• на месте главной висит заглушка хостинга — она тоже отвечает 200;
• сайт открылся, но через секунду редиректит на чужой домен скриптом, а не заголовком;
• вместо страницы отдаётся ошибка PHP в теле ответа, а код при этом двухсотый, потому что вывод ошибок включён, а обработчик — нет;
• отдаётся кэшированная копия недельной давности с ценами, которых уже нет.

Ни один из этих случаев не отличим от нормальной работы, если смотреть только на код и время ответа.

Пять поломок, которые пройдут мимо аптайма

Истёк сертификат

Самый частый и самый дорогой случай. HTTPS перестал работать — браузер показывает предупреждение во весь экран и не пускает дальше. При этом сервер отвечает: по HTTP он ответит 200 или редиректом, а проверка, которая ходит без разбора цепочки сертификата, поломки не увидит вовсе.

Автопродление тут не спасает, потому что ломается оно тихо. Сменился адрес, закрылся порт, обновился веб-сервер и потерялся хук — certbot отработал с ошибкой в лог, который никто не читает. Проверять надо не задание планировщика, а то, какой сертификат сайт отдаёт прямо сейчас.

Сайт закрыт от индексации

Строка Disallow: / в robots.txt — нормальная практика на тестовом стенде и катастрофа на боевом. Вместе с релизом она уезжает на боевой сайт регулярно; то же самое делает <meta name="robots" content="noindex">, забытый в шаблоне.

Сайт при этом работает идеально. Он открывается, отвечает быстро, заказы проходят. Просто через две недели он пропадает из выдачи, а ещё через месяц об этом узнаёт клиент — по выручке.

Микроразметка перестала разбираться

После обновления шаблона в JSON-LD попала лишняя запятая. Разметка не разбирается, расширенные сниппеты исчезают из выдачи, кликов становится меньше при тех же позициях. Ошибок в логах нет, потому что для сайта это не ошибка — это просто текст внутри тега script.

Замечают такое обычно через квартал и списывают на сезон.

Подмена содержимого

На главной появился блок с чужой рекламой, или в шапке — скрытые ссылки, или в футере — незаметный текст про казино. Это результат взлома, а не поломки, и сайт после него работает даже лучше обычного: злоумышленнику нужно, чтобы никто ничего не заметил как можно дольше.

Код ответа — 200. Время ответа — прежнее. Отличается только содержимое, и сравнивать его надо с тем, что было вчера.

Форма молча перестала отправлять

Обновился плагин, сменился SMTP-пароль, кончилась квота на отправку — и форма обратной связи показывает «спасибо», но письмо никуда не уходит. Для сайта это штатная работа: страница отдана, скрипт отработал, ответ двухсотый.

Это самая дорогая из поломок в списке, потому что теряются не посетители, а уже готовые заявки, и заметить пропажу можно только по их отсутствию.

Почему доступность 99,9 % может быть неправдой

Второй слой той же проблемы — как считается сама цифра.

Если сервис считает доступность по «общему статусу проверки», то любая несрочная находка — не оптимизированная картинка, отсутствующий canonical, предупреждение в разметке — роняет процент за сутки, когда сайт исправно отвечал. Клиент видит 96 % и требует объяснений, которых нет.

Обратная ошибка встречается чаще. Доступность считают по количеству удачных проверок, не глядя на то, сколько их было: сутки с тремя проверками весят столько же, сколько сутки с тремя сотнями. Одного дня с редкими проверками достаточно, чтобы вытянуть месячную цифру на приличную.

Правильный ответ скучный: считать надо по одному явному признаку «сайт отвечал», складывать счётчики попыток, а не проценты, и понимать, что доступность — это отчётная цифра для клиента, а не инструмент диагностики.

Что проверять вместо кода ответа

Список короткий, и он же — ответ на вопрос, зачем мониторингу что-то, кроме пинга:

Ни одна из этих проверок не заменяет пинг — они его дополняют. Смысл в том, что «сайт работает» — утверждение из десятка условий, а аптайм-мониторинг проверяет одно.

Что с этим делать студии на поддержке

Три практических вывода.

Первое. Разделите в голове две вещи: уведомление об аварии и отчёт клиенту. Первое должно приходить по узкому набору признаков и почти никогда — иначе его начнут игнорировать через месяц. Второе — раз в месяц, с цифрой доступности, и в нём не место предупреждениям о картинках.

Второе. Сроки — сертификата, домена, оплаты хостинга — выносите в отдельный список с датами. Это единственная категория поломок, которые известны заранее и происходят строго по расписанию, и единственная, которую стыдно пропустить.

Третье. Проверяйте то, что видит посетитель, а не то, что отдаёт сервер. Формально это разные точки наблюдения: изнутри всё всегда хорошо.