Миф: если сайт открывается, значит всё в порядке

MAATRIX

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

Почему ручная проверка вообще кажется достаточной

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

Дальше начинается зона, где интуиция подводит. «Сайт работает» на бытовом языке означает «страница отрисовалась». В инженерном смысле «сайт работает» означает «все критичные для бизнеса сценарии выполняются корректно и достаточно быстро» — а это совсем другое утверждение, и первое из второго не следует. Между ними зазор, в котором и живут самые дорогие инциденты: те, что незаметны при беглом взгляде, но вырубают конкретную функциональность или медленно убивают конверсию.

Главная страница — не показатель, а самый простой случай

Главная страница почти всегда самая нетребовательная часть сайта технически. Она чаще всего кешируется — либо на уровне CDN, либо Nginx/Varnish на самом сервере, либо плагином кеша в CMS. Кеш существует именно для того, чтобы не дёргать бэкенд и базу данных на каждый визит, и в норме это правильно. Но у этой экономии есть обратная сторона: если бэкенд или база данных за кешем уже не отвечают, кешированная главная страница продолжит отдаваться пользователю как ни в чём не бывало — с кодом 200 и корректным HTML, потому что сервер кеша вообще не обращался к упавшему бэкенду.

# Проверка curl покажет успех, даже если бэкенд лежит
curl -s -o /dev/null -w "%{http_code}\n" https://site.ru/
# 200

# А запрос к некешируемому эндпоинту вскроет реальную картину
curl -s -o /dev/null -w "%{http_code}\n" https://site.ru/api/cart/checkout
# 500 или таймаут

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

Это не гипотетический сценарий, а типичная причина ложного спокойствия на WordPress с плагинами кеша, на связках Nginx + PHP-FPM с fastcgi_cache, на сайтах за CDN вроде Cloudflare с агрессивным edge-кешированием статичных страниц. Чем лучше настроен кеш — тем дольше он способен маскировать мёртвый бэкенд.

Медленно — это тоже «не работает», просто по-другому

Второй слепой пятно ручной проверки — производительность. Когда вы открываете сайт руками, вы неосознанно оцениваете его в бинарной шкале: открылся / не открылся. Если страница загрузилась за 8 секунд вместо привычной секунды — вы всё равно мысленно ставите галочку «работает», потому что технически контент появился. Мозг не воспринимает деградацию как отказ, если результат в итоге получен.

Для бизнеса разница между секундой и восемью секундами — не нюанс, а обвал. Зависимость конверсии от скорости загрузки страницы неоднократно изучалась крупными игроками рынка (Google, Amazon и другие публиковали свои внутренние наблюдения на этот счёт) — конкретные цифры отличаются от исследования к исследованию и от проекта к проекту, поэтому не будем выдумывать точный процент, который применим именно к вашему сайту. Но направление устойчиво в любой методологии: чем дольше грузится страница, тем больше посетителей уходит, не дождавшись, и тем хуже позиции в поиске, потому что скорость страницы — один из факторов ранжирования.

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

# Разница между "открылся" и "открылся быстро"
curl -s -o /dev/null -w "connect: %{time_connect}s  ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://site.ru/

Именно поэтому нормальный мониторинг фиксирует не факт ответа, а время ответа — и умеет слать алерт не только на код 500, но и на превышение порога по времени, даже если код при этом 200.

Частичные сбои: работает не значит работает всё

Третий пробел — сайт как единое целое почти никогда не падает или не падает весь сразу. Гораздо чаще ломается одна конкретная функция при полностью исправной остальной части. Классические примеры: перестали отправляться email-уведомления о заказе (сломался SMTP-релей или закончилась квота у почтового сервиса), перестали проходить платежи (истёк API-ключ платёжного шлюза, изменился формат вебхука, эквайринг вернул новую ошибку, которую код не обрабатывает), сломался конкретный виджет — форма обратной связи, калькулятор стоимости, поиск по каталогу, авторизация через соцсети.

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

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

Для таких сценариев нужна не проверка «отвечает ли сайт», а проверка конкретного пути: реальная (или синтетическая тестовая) транзакция через платёжный шлюз в тестовом режиме, отправка тестового письма с проверкой доставки, программный клик по форме с проверкой, что запрос дошёл до бэкенда и вернул ожидаемый ответ. Подробнее о том, как строить такие проверки контента и конкретных сценариев, а не только кода ответа, разобрано в статье про инструменты мониторинга доступности сайта.

Человек не может смотреть на сайт 24 часа в сутки

Даже если закрыть глаза на первые три пункта и представить, что ручная проверка идеально ловит вообще все виды сбоев — остаётся фундаментальное ограничение: она разовая. Вы открыли сайт утром, увидели, что всё хорошо, и на этом основании делаете вывод о состоянии системы на весь день. Но между вашими проверками — часы или дни, а сбой может произойти в любую секунду.

Самый частый практический случай — ночь. Пик нагрузки на многие сайты в другом часовом поясе или ночная автоматическая задача (бэкап, обновление, ротация логов) может уронить сервис в три часа ночи, а обнаружится это только когда вы откроете ноутбук утром — то есть простой длится 5-8 часов, из которых первые несколько прошли в полной тишине, потому что смотреть было некому. За такое время сайт успевает потерять значимую часть суточного трафика, и часть посетителей, столкнувшихся с ошибкой, просто не вернётся.

Второй частый случай — отпуск, выходные, просто занятой день, когда открыть сайт руками банально забыли. Мониторинг не устаёт, не уходит в отпуск и не отвлекается на другие задачи — он проверяет сайт с постоянным интервалом (обычно от 30 секунд до нескольких минут, в зависимости от настройки) и присылает уведомление в течение минуты после обнаружения проблемы, а не через восемь часов, когда вы случайно вспомнили открыть вкладку. Разница между «узнали через минуту» и «узнали через восемь часов» — это разница между небольшим инцидентом и историей, которую потом обсуждают с клиентами.

Что мониторить вместо ручного открытия сайта

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

Практически это означает self-hosted панель вроде Uptime Kuma на отдельном сервере (не на том, где крутится сам сайт — иначе при падении сервера упадёт и мониторинг вместе с ним) либо внешний сервис с сетью точек проверки. Как именно настроить конкретные типы мониторов, интервалы и алерты в Telegram — пошагово разобрано в статье про настройку Uptime Kuma для сайта и сервера, а более полный обзор пошагового пути от простого скрипта до полноценной панели — в статье про мониторинг и алерт при падении сайта.

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

Частые вопросы