Что делать, если упал сайт: пошаговый план для владельца

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

Владельцу сайта или дежурному инженеру в такой момент нужен короткий план: подтвердить сбой, оценить масштаб, быстро локализовать уровень проблемы, восстановить работу и зафиксировать выводы. Даже без полноценной SRE-команды такой порядок сокращает время простоя и помогает не повторять одну и ту же аварию.

Ниже — практический сценарий для владельцев сайтов, разработчиков и DevOps-инженеров. Он подходит для интернет-магазина, корпоративного сайта, SaaS-сервиса, API и личного проекта на VPS.

Сначала подтвердите, что сайт действительно упал

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

1) Проверьте сайт из нескольких точек — откройте его с телефона через мобильный интернет, из другого браузера, с домашней сети или через внешний сервис проверки доступности. Если сайт не открывается только у вас, дело может быть в локальном DNS, VPN, корпоративном прокси или кеше браузера.

2) Посмотрите, что именно видит пользователь — белый экран, ошибка браузера, код 500, 502, 503, бесконечная загрузка, предупреждение о сертификате, редирект по кругу. Формулировка ошибки сразу сужает область поиска.

3) Проверьте HTTP-ответ — используйте curl, чтобы увидеть статус, заголовки и время ответа:

curl -I https://example.com

Если сайт отвечает 200, но пользователь видит сломанную страницу, проблема, скорее всего, на фронтенде, в JavaScript, CDN-кеше или конкретном маршруте. Если ответа нет или есть 5xx, смотрите сервер, прокси, приложение и базу данных. Подробнее о диагностике через curl — в статье «Что такое curl и как им пользоваться».

4) Сравните домен и прямой IP — если по IP сервер отвечает, а по домену нет, вероятна проблема DNS, SSL, виртуального хоста или CDN. Если не отвечает даже IP, смотрите сервер, сеть, фаервол или хостинг.

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

Оцените масштаб и срочность инцидента

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

1) Полный простой или частичная деградация — сайт не открывается вообще, открывается только главная, не работает личный кабинет, сломана оплата, недоступна админка, падает только API. Полный простой нужно устранять немедленно. Частичная деградация тоже критична, если затрагивает ключевой путь пользователя: заказ, оплату, авторизацию, регистрацию.

2) Все пользователи или отдельный сегмент — проблема может проявляться только в одном регионе, у абонентов конкретного провайдера, в мобильной версии, у пользователей за Cloudflare или на IPv6. Поэтому полезно проверять сайт из разных сетей и точек.

3) Постоянный сбой или периодические ошибки — если сайт то работает, то падает, ищите перегрузку, лимиты соединений, OOM, проблемы с базой, DNS-кеширование, нестабильный upstream или сетевые потери. Разовые короткие сбои сложнее расследовать без логов и метрик.

4) Были ли недавние изменения — деплой, обновление CMS, смена DNS-записей, продление SSL, миграция базы, изменение настроек Nginx, новая версия API, обновление плагина, настройка CDN. Последнее изменение не всегда виновато, но это первая гипотеза.

Зафиксируйте начало инцидента, симптомы и затронутые компоненты — достаточно сообщения в рабочем чате или карточки инцидента. Главное — не держать всё в голове.

Быстрая диагностика: DNS, сеть, SSL, веб-сервер, приложение

Большинство падений укладывается в несколько уровней. Двигайтесь сверху вниз: домен → сеть → TLS → прокси → приложение → база и внешние зависимости.

1) DNS — если браузер пишет DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED или домен не резолвится, проверьте записи:

dig example.com A

dig example.com NS

dig www.example.com CNAME

Смотрите, не удалена ли A/AAAA-запись, не истёк ли домен, не изменились ли NS-серверы, не указывает ли запись на старый IP. Подробный разбор утилиты — в материале «dig: как проверить DNS-записи и отладить домен».

2) Сеть и доступность порта — если DNS в порядке, проверьте, отвечает ли сервер на 80 и 443. ERR_CONNECTION_TIMED_OUT обычно говорит о сетевой недоступности, фаерволе, маршрутизации или перегруженном сервере. ERR_CONNECTION_REFUSED значит, что порт доступен, но на нём никто не слушает или соединение отклоняется.

3) SSL/TLS — если сайт открывается по http, но не по https, проверьте сертификат, цепочку доверия, срок действия, SNI и настройки прокси. Частые причины: истёк сертификат, не сработало автообновление Let’s Encrypt, сертификат выпущен не на тот домен, CDN не доверяет origin-сертификату.

4) Nginx, Apache, Caddy или балансировщик — ошибки 502, 503, 504 часто возникают между reverse proxy и приложением: Nginx может работать, а upstream уже упал, перегружен или недоступен по локальному порту.

Проверьте статус сервиса:

systemctl status nginx

systemctl status apache2

systemctl status your-app

Посмотрите ошибки:

journalctl -u nginx -n 100 --no-pager

journalctl -u your-app -n 100 --no-pager

5) Приложение — если веб-сервер жив, но приложение возвращает 500, ищите исключения, нехватку переменных окружения, проблемы с миграциями, зависимостью, очередью, файловыми правами, кешем, сессиями. Симптомы у Node.js, Python, Go, PHP и Java разные, но логика одна: приложение должно стартовать, слушать порт и отвечать на health check.

6) База данных и внешние сервисы — сайт может «упасть», хотя веб-сервер и приложение работают: закончились соединения к PostgreSQL/MySQL, база ушла в read-only, диск заполнен, внешний API оплаты недоступен, Redis недостижим, очередь задач забита.

Более широкий обзор причин — в материале «Почему не работает сайт: 7 распространённых причин сбоев».

Что можно сделать быстро, чтобы вернуть сайт в работу

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

1) Снимите факты до вмешательства — зафиксируйте время, ошибку, последние строки логов, нагрузку, свободное место, статус сервисов. Минимум: uptime, df -h, free -m, systemctl status, последние логи приложения и Nginx. Перезапустите всё сразу — и причина может исчезнуть вместе со следами.

2) Откатите последний деплой — если падение началось после релиза, самый быстрый путь — вернуть предыдущую стабильную версию. Не пытайтесь срочно чинить код в продакшене, если есть рабочий rollback. Хороший деплой должен иметь понятную команду отката и список миграций, которые нельзя безопасно откатить.

3) Перезапустите только нужный компонент — упал процесс приложения — перезапустите приложение, а не весь сервер. Завис Nginx — перезапустите Nginx. Проблема в контейнере — перезапустите конкретный контейнер. Грубая перезагрузка VPS допустима, когда нет доступа к процессам или сервер в тяжёлом состоянии, но это крайний вариант.

Для Docker-проектов проверьте контейнеры:

docker ps

docker logs --tail=100 container_name

docker restart container_name

4) Освободите диск — заполненный диск ломает базы, логи, сессии, загрузку файлов и даже выпуск сертификатов. Проверьте df -h. Если заняты логи, не удаляйте активный файл вслепую: лучше настроить ротацию и очистить старые архивы, временные файлы, кеши, ненужные Docker-образы.

5) Снизьте нагрузку — включите кеш, временно отключите тяжёлые фоновые задачи, остановите импорт, закройте дорогие отчёты, увеличьте число воркеров, ограничьте ботов, включите rate limiting на уровне Nginx/CDN. Если сайт падает от всплеска трафика, иногда достаточно вернуть контроль над очередями и соединениями.

6) Переключитесь на резервный вариант — статическая заглушка, read-only режим, запасной сервер, maintenance page, CDN-кеш, резервная база. Лучше честная страница «сервис временно недоступен», чем бесконечная загрузка или случайные ошибки.

Если пользователи видят конкретные коды 502, 503 или 504, полезно свериться с отдельными разборами: например, причины 502 Bad Gateway часто лежат между прокси и upstream-приложением — что значит эта ошибка и как её исправить.

Как общаться с пользователями и командой во время сбоя

Молчание во время аварии почти всегда хуже короткого честного сообщения. Пользователи всё равно видят проблему, а команда тратит время на одинаковые вопросы от клиентов, менеджеров и руководителей.

1) Назначьте одного ответственного за коммуникацию — инженер или владелец продукта должен обновлять статус, чтобы разработчики не отвлекались каждые пять минут. Для маленькой команды достаточно одного канала: рабочий чат, Telegram, почта, статус-страница.

2) Скажите, что известно — не обещайте точное время восстановления, если не знаете его. Лучше написать: «Сайт недоступен для части пользователей. Мы проверяем проблему на стороне веб-сервера. Следующее обновление — через 20 минут».

3) Обновляйте статус регулярно — даже если новостей нет. Сообщение «продолжаем восстановление, причина локализована в базе данных» снижает число обращений и показывает, что инцидентом занимаются.

4) Разделяйте внутренний и внешний язык — внутри можно писать «упал upstream, Nginx отдаёт 502, подозрение на пул соединений». Снаружи лучше: «Часть страниц временно недоступна. Мы восстанавливаем работу сервиса».

5) Закройте инцидент финальным сообщением — когда сайт снова работает, сообщите об этом и укажите, продолжаете ли наблюдение. Если сбой затронул оплату, заказы или данные, отдельно проверьте последствия.

Статус-страница полезна не только крупным сервисам: простой публичный статус сайта, API и панели управления уменьшает хаос во время аварии, а вместе с внешним мониторингом фиксирует точное время начала и завершения сбоя.

После восстановления найдите корневую причину

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

1) Соберите хронологию — время первого симптома, время уведомления, кто начал реагировать, какие команды выполнялись, когда сервис восстановился. Если есть мониторинг, возьмите график доступности и метрики за период до, во время и после инцидента.

2) Отделите симптом от причины — «Nginx отдавал 502» — это симптом. Причина может быть в том, что приложение упало из-за нехватки памяти, база перестала принимать соединения, новый релиз изменил переменную окружения или истёк сертификат.

3) Проверьте логи вокруг начала сбоя — не только последние строки после перезапуска, а логи за 10–30 минут до первого алерта: приложение, веб-сервер, база, systemd, контейнеры, CDN, балансировщик. Если логи потерялись после рестарта, настройте их сохранение.

4) Найдите триггер — деплой, рост трафика, бот-атака, плановая задача, истечение сертификата, переполнение диска, долгий SQL-запрос, истечение лимита API. Триггер не всегда совпадает с корневой причиной, но объясняет, почему сбой случился именно сейчас.

5) Проверьте, почему сбой не был пойман раньше — не было алерта, алерт пришёл не тому человеку, проверялась только главная страница, health check возвращал 200 даже при недоступной базе, уведомления заглушили из-за шума.

6) Сформулируйте конкретные действия — не «следить внимательнее», а: добавить проверку /health, настроить алерт на 5xx, включить ротацию логов, добавить лимит соединений, обновить runbook, настроить бэкапы, изменить деплой, добавить rollback.

Если сайт «не открывался», но причина неочевидна, пригодится чеклист пошаговой диагностики недоступного сайта.

Как подготовиться, чтобы следующий сбой был короче

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

1) Настройте внешний мониторинг — проверяйте сайт не только изнутри, но и глазами пользователя: HTTP-статус, время ответа, SSL, домен, ключевые страницы. Такой uptime monitoring показывает, доступен ли сервис снаружи, а не просто «жив ли процесс». Подробнее — в статье «Что такое uptime monitoring и как он работает».

2) Проверяйте критические сценарии — главная страница может отвечать 200, а оформление заказа падать. Добавьте проверки для логина, API, корзины, формы заявки, webhook-endpoint, страницы оплаты или админки — не все проверки должны быть сложными, но они должны покрывать бизнес-критичные пути.

3) Сделайте нормальные health checks — endpoint /health должен отражать состояние приложения и зависимостей. Иногда достаточно проверить, что процесс жив; для серьёзного сервиса нужен отдельный /ready, который учитывает подключение к базе, кешу, очередям и внешним сервисам.

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

5) Подготовьте runbook — короткий документ «что делать, если сайт упал»: доступы, команды диагностики, ссылки на панели, порядок rollback, контакты хостинга, инструкция по статус-странице, список критичных зависимостей. Runbook экономит минуты, когда все нервничают.

6) Регулярно проверяйте бэкапы — бэкап, который ни разу не восстанавливали, — это гипотеза, а не гарантия. Настройте автоматическое копирование баз данных и периодические тесты восстановления. Для PostgreSQL см. инструкцию по автоматическому бэкапу.

7) Документируйте инфраструктуру — домены, DNS, CDN, серверы, контейнеры, переменные окружения, cron-задачи, сертификаты, внешние API. Часто сайт долго лежит не из-за сложной поломки, а потому что никто не знает, где настроен домен или кто имеет доступ к панели хостинга.

8) Репетируйте откат — rollback должен быть привычной операцией. Если каждый откат — уникальный эксперимент в продакшене, время восстановления будет расти. Для критичных сервисов стоит применять blue-green deployment, canary-релизы или хотя бы деплой с быстрым возвратом предыдущей версии.

Короткий чеклист: что делать, если упал сайт

Сохраните этот список в runbook или закрепите в рабочем чате.

1) Подтвердить сбой — проверить сайт из другой сети, через мобильный интернет, внешним мониторингом, командой curl -I.

2) Зафиксировать симптомы — код ошибки, время начала, затронутые страницы, регионы, браузеры, пользователей.

3) Проверить недавние изменения — деплой, DNS, SSL, настройки сервера, обновления CMS, миграции базы, CDN.

4) Пройти уровни диагностики — DNS через dig, доступность портов, SSL, Nginx/Apache, приложение, база, внешние API.

5) Снять данные до перезапуска — логи, df -h, free -m, uptime, статус сервисов, метрики.

6) Восстановить работу — rollback, перезапуск конкретного сервиса, освобождение диска, отключение тяжёлой задачи, включение заглушки или резервного режима.

7) Сообщить пользователям — признать проблему, описать масштаб, дать время следующего обновления, закрыть инцидент после восстановления.

8) Разобрать причину — составить хронологию, найти корневую причину, добавить конкретные профилактические задачи.

FAQ

Что делать в первую очередь, если сайт упал?
Подтвердите сбой из внешней сети и определите симптом: нет DNS, не открывается порт, ошибка SSL, 5xx, таймаут или проблема только на одной странице. Не перезапускайте всё до минимального сбора фактов.

Можно ли сразу перезагрузить сервер?
Можно, если сервер полностью завис и другого доступа нет. Но лучше сначала сохранить логи и состояние системы. Перезагрузка часто восстанавливает сайт, но скрывает причину.

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

Как понять, что сайт восстановился полностью?
Проверьте не только главную страницу. Откройте ключевые сценарии: вход, каталог, корзину, оплату, API, админку. Посмотрите, снизились ли ошибки в логах и вернулись ли метрики к нормальному уровню.