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.
Статьи по теме
Все материалы: Аудит и тестирование
Разработка и внедрение ИИ-агентов для бизнеса: пилот за 2–4 недели, не demo-бот
ИИ-агенты для бизнеса: чем отличаются от чат-бота и RAG-виджета, что входит в пилот 2–4 недели, on-prem, интеграции CRM/1С/API, оркестрация и KPI. Чеклист перед заказом.
Читать статьюСвой веб-кабинет или облачный SaaS: когда on-prem выгоднее
Свой веб-кабинет или облачный SaaS: сравнение on-prem и подписки для бизнеса — данные, TCO на 3 года, риски вендора и чеклист выбора кабинета.
Читать статьюИнтеграция 1С и ERP с веб-приложением: что заложить в ТЗ до подписания
Как связать 1С/ERP с порталом, CRM или системой заявок без двойного ввода: master data, REST/OData, частота обмена, конфликты и ориентиры по бюджету интеграции для CEO и CTO.
Читать статьюIT-проект для руководства: 10 вопросов до подписания контракта
Чеклист для гендиректора, CFO и совета директоров: измеримый результат, владелец со стороны бизнеса, IP, SLA, выход из контракта и красные флаги подрядчика — без жаргона про микросервисы.
Читать статью