Сайт «мигает»: как поймать кратковременные сбои, которые не видно

Клиент пишет «у вас сайт не работал», вы открываете — работает. Через день то же самое. Кратковременные сбои — самый неприятный класс проблем: к моменту расследования всё уже в порядке, логи молчат, а осадок у клиентов остаётся. Разбираем, откуда берётся «мигание» и как поймать его за руку.

«Мигающий» сайт — это сайт, который падает на секунды или минуты и восстанавливается сам, раньше, чем кто-то успевает продиагностировать проблему. Формально аптайм остаётся приличным — 99% с лишним. Фактически часть посетителей регулярно натыкается на ошибку, и каждый такой контакт стоит заказов и доверия: посетитель из рекламы не будет обновлять страницу, он уйдёт к следующему в выдаче.

Почему сайт мигает: шесть типовых причин

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

2. Перезапуски процессов. Приложение съедает всю память, система убивает процесс, менеджер процессов его поднимает. Цикл занимает секунды и повторяется часами — в логах это видно, но только если знать, куда и в какое время смотреть.

3. Проблемный узел за балансировщиком. Из нескольких бэкендов один нездоров. Посетители, чьи запросы попадают на него, видят ошибку; остальные — нет. Сайт «мигает» не во времени, а в пространстве: постоянно, но не для всех.

4. Нестабильный DNS. Один из авторитативных серверов домена подтормаживает или недоступен — часть запросов резолвится, часть нет. Симптомы рваные и бессистемные; подробнее — в разборе о том, как работает DNS.

5. Сбоящая нода CDN или проблемы маршрута. Сайт жив, но путь до него из конкретного региона или сети провайдера периодически рвётся. Из офиса всё отлично, у клиентов из другого города — ошибки через раз.

6. Агрессивная защита. Анти-бот система или файрвол периодически принимает обычных посетителей за атаку — особенно из «подозрительных» сетей. Мы разбирали похожий механизм в статье про WAF и мониторинг.

Почему вы этого не видите

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

Как поймать: три настройки

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

Второе — проверки из многих точек и взгляд «по локациям». Если сбой видят все 13 точек разом — проблема в сервере или приложении, ищите по времени. Если стабильно сбоит одна-две локации, а остальные зелёные — проблема в маршруте, CDN-ноде или гео-фильтре, ищите по месту. История запусков по каждой локации в Пруфене показывает это одним экраном: у «мигания» появляется география, а вместе с ней и диагноз. Настройка точек — в справке о локациях мониторинга.

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

Мигание или деградация: важное различие

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

Различить их помогает время ответа в истории проверок: у мигания график ровный с провалами в ошибку, у деградации — ошибок нет, но время ответа периодически взлетает в разы. Деградация коварнее: она не создаёт инцидентов в примитивном мониторинге «жив/мёртв», хотя теряет вам тех же клиентов. Если по истории видно систематическое распухание времени ответа — начните со статьи про TTFB: там разобраны типовые причины медленного ответа сервера.

Чек-лист охоты на мигающий сбой

Что делать с уловом

Через несколько дней частых проверок у вас будет журнал: даты, время, длительность, локации каждого сбоя. Дальше — сопоставление. Сбои в одно и то же время суток — ищите крон, бэкап, соседей по хостингу с регулярной нагрузкой. Сбои в пики трафика — ресурсы; пора оптимизировать или переезжать, наш разбор VPS против виртуального хостинга поможет с выбором. Сбои из отдельных регионов — разговор с CDN или хостингом о маршрутах, с журналом инцидентов в руках этот разговор идёт заметно быстрее.