5 признаков, что ваш сайт скоро упадет
Титаник не утонул мгновенно. Сначала был удар, потом вода в трюмах, и только потом — катастрофа. С вашим сайтом то же самое. Он "кричит" о помощи задолго до того, как упасть. Умеете ли вы читать эти сигналы?
Главное. Сайт падает не внезапно: сначала TTFB, полный пул БД, swap, рост 5xx или тишина в логах. Алерты в Prometheus/Zabbix должны сработать раньше гневных сообщений клиентов.
Чек-лист: Симптомы скорой смерти
*Если вы видите это в логах — звоните в NineLab.
1. Рост TTFB (Time to First Byte)
Если сервер думает дольше ~200 мс до первого байта при норме 100–120 мс — код или БД уже на пределе. 800 мс TTFB — не «чуть медленно», а очередь перед сбоем: пользователь ещё не увидел страницу, а вы уже теряете конверсию.
2. "Too many connections" в базе
Каждый SQL-запрос держит соединение. Когда пул почти полный (например 98 из 100), новые сессии получают отказ, а не «чуть подождут». Это классический потолок масштабирования до 503 на пике рекламы.
3. Swap (Свопинг) диска
Когда RAM кончилась, диск становится «памятью» и работает на порядки медленнее. Сайт деградирует скачком: таймауты, 502, OOMKill postgres. Swap на сервере сайта — повод чинить память и пул, а не «добавить диск».
4. Рост ошибок 5xx
Одна ошибка 500 в день — случайность. Десять в час — закономерность. Доля 5xx около 1% трафика — уже пожар: Директ продолжает крутиться, качество объявлений падает, клиенты видят белый экран.
5. Тишина в логах (Log Silence)
Если логи резко пропали, часто кончилось место на диске: приложение «молчит», мониторинг врёт, инцидент уже идёт. Это тихая смерть — алерт на свободное место диска должен сработать раньше клиентов в чате.
Совет: Настройте алерты в Zabbix или Prometheus. Узнавайте о проблемах раньше, чем ваши пользователи напишут гневный твит.
Что дальше
Проверим систему до пика: нагрузочное тестирование, аудит производительности, доработка контура или оценка Discovery.
Сервисы и материалы по теме
Вопросы про признаки скорого падения сайта
Рост TTFB выше ~200 мс, пул соединений БД почти полный, swap вместо RAM, доля 5xx около 1% трафика и внезапная тишина в логах (часто кончился диск). Это сигналы до 503, а не «после того как легли».
Если сервер думает дольше ~200 мс до первого байта при норме около 100–120 мс — код или БД уже на пределе. 800 мс TTFB — не «чуть медленно», а очередь перед сбоем.
Когда RAM кончилась, диск становится «памятью» и работает на порядки медленнее. Сайт деградирует скачком: таймауты, 502, убитый postgres по OOM.
Не ждать пика рекламы: алерты в Zabbix/Prometheus, проверить пул БД, диск и память, затем аудит или нагрузочный тест. Десять 500 в час — уже закономерность, не случайность.
Если TTFB ушёл за 200 мс, пул БД почти полный или 5xx около 1% трафика — это до 503, не после. Аудит и стресс-тест дешевле утра простоя на Директе.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Все материалы: Аудит и тестирование
Как мы сменили рабочее место маркетолога и SEO: от десяти вкладок к ИИ в контуре
Для собственника и гендира: почему маркетолог прыгает по десяти инструментам, как выглядит один контур с ИИ-агентом, где остаётся контроль человека и зачем это бизнесу, а не «ещё один чат».
Читать статьюЛичный кабинет B2B или Битрикс24: когда свой контур дешевле
Личный кабинет B2B или Битрикс24: когда коробка CRM хватает, а когда нужен свой кабинет с ролями и 1С. Вилки от 350 000 ₽, чеклист для собственника.
Читать статьюАудит готовности сайта к ИИ: чеклист GEO без рерайта 40 статей
Аудит сайта для ИИ и ChatGPT: готовность к цитированию — robots, llms.txt, FAQ, факты о бренде. Чеклист для CEO: что чинить первым и когда звать инженеров, а не копирайтера.
Читать статьюАудит МИС сети клиник: −48% облака и p95 0,6 с за 6 недель
Кейс аудита МИС: подрядчик ушёл, код «как есть». Как за 6 недель закрыли 152-ФЗ, убрали падения БД в пик и срезали Yandex Cloud почти вдвое.
Читать статью