Что делать когда сайт упал: план действий

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

Первые 5 минут: подтверждение и эскалация

Шаг 1: Подтвердите инцидент

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

• Временный сетевой сбой между мониторингом и вашим хостингом
• Блокировка IP мониторинга файрволом
• Изменение ожидаемого ответа (например, редирект на другую страницу)

Действия:

1. Откройте сайт в браузере (лучше в режиме инкогнито)
2. Проверьте с мобильного интернета (исключить проблемы локальной сети)
3. Используйте сервисы проверки доступности: downforeveryoneorjustme.com, isitdownrightnow.com
4. Проверьте статус хостинга и CDN в их статус-панелях

Если сайт открывается у вас, но мониторинг показывает ошибку — возможно, проблема на стороне мониторинга или региональная (сайт недоступен из определённых регионов).

Шаг 2: Оцените масштаб

Определите, что именно недоступно:

Симптом	Возможная причина
Сайт не открывается вообще	DNS, хостинг, сеть
Ошибка «Ваше соединение не защищено»	SSL-сертификат
Ошибка 502/503	Сервер приложений, перегрузка
Ошибка 500	Ошибка в коде, база данных
Медленная загрузка	Перегрузка, DDoS
Часть страниц не работает	Конкретный сервис, API

Шаг 3: Уведомите команду

Если инцидент подтверждён — немедленно уведомите ответственных. Чёткий канал коммуникации (Telegram-чат, Slack) критичен. Укажите:

• Что произошло (сайт недоступен / ошибка 503 / и т.д.)
• Когда обнаружено
• Что уже проверено

Не тратьте время на поиск виноватых. Сначала — восстановление.

Диагностика: дерево решений

После подтверждения инцидента переходите к диагностике. Ниже — последовательность проверок от внешних слоёв к внутренним.

Уровень 1: DNS

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

Проверка через DNS Lookup:

1. Введите домен сайта
2. Проверьте записи A и AAAA — указывают ли они на правильные IP
3. Проверьте TTL записей — не аномально ли низкий (может указывать на недавние изменения)
4. Сравните результат с разных DNS-серверов (Google 8.8.8.8, Cloudflare 1.1.1.1)

Типичные проблемы DNS:

Проблема	Симптом	Решение
Истёк домен	DNS не резолвится	Продлить домен у регистратора
Неверные NS-записи	Домен указывает на несуществующие NS	Исправить NS у регистратора
DDoS на DNS	Медленный или нестабильный резолв	Перейти на защищённый DNS (Cloudflare, etc.)
Кэш устарел	Часть пользователей видит старый IP	Подождать TTL или снизить TTL заранее

Быстрая проверка из терминала:

dig example.com +short
nslookup example.com 8.8.8.8

Уровень 2: Сеть и доступность хоста

Если DNS резолвится корректно, проверьте доступность сервера.

Проверки:

ping example.com
traceroute example.com
curl -I https://example.com

Интерпретация:

• ping не отвечает — сервер выключен, файрвол блокирует ICMP, или сеть недоступна
• traceroute обрывается на определённом узле — проблема на участке сети или у хостинга
• curl возвращает таймаут — сервер не отвечает на HTTP(S)
• curl возвращает 5xx — сервер доступен, но приложение падает

Уровень 3: SSL/TLS

Ошибка «Ваше соединение не защищено» или «Certificate has expired» — проблема с сертификатом.

Проверка через SSL Checker:

1. Введите домен
2. Проверьте срок действия сертификата
3. Проверьте цепочку сертификатов (нет ли обрывов)
4. Проверьте соответствие домена сертификату (SAN)

Типичные проблемы SSL:

Проблема	Причина	Решение
Сертификат истёк	Забыли обновить	Установить новый сертификат, перезапустить веб-сервер
Неверная цепочка	Промежуточные сертификаты не установлены	Добавить полную цепочку
Несоответствие домена	Сертификат для другого домена	Выпустить сертификат для правильного домена
Смешанный контент	Часть ресурсов по HTTP	Исправить ссылки на HTTPS

Срочное обновление Let's Encrypt:

certbot renew --force-renewal
systemctl reload nginx

Уровень 4: Веб-сервер и приложение

Сервер отвечает, но возвращает 5xx. Проблема в приложении или конфигурации.

502 Bad Gateway — веб-сервер (Nginx, Apache) не может получить ответ от бэкенда (PHP-FPM, Node, etc.):

• Бэкенд упал — перезапустить сервис
• Таймаут — бэкенд перегружен или завис
• Неверный upstream в конфиге

503 Service Unavailable — сервис временно недоступен:

• Перегрузка — слишком много запросов
• Плановое обслуживание (если настроено)
• База данных недоступна

500 Internal Server Error — ошибка в коде приложения:

• Проверить логи приложения
• Проверить логи PHP/Node/Python
• Возможен недостаток памяти, падение БД

Проверка логов:

# Nginx
tail -f /var/log/nginx/error.log

# PHP-FPM
tail -f /var/log/php-fpm/error.log

# Системные логи
journalctl -u nginx -f
journalctl -u php-fpm -f

Уровень 5: База данных

Многие падения сайтов вызваны проблемами с БД.

Симптомы: 500/503, таймауты, «Error establishing database connection»

Проверки:

# MySQL/MariaDB
mysql -u user -p -e "SELECT 1"

# Проверка подключений
mysqladmin processlist

# Проверка диска (БД может не писать при полном диске)
df -h

Типичные проблемы: исчерпан диск, MySQL упал, исчерпаны соединения, долгие запросы блокируют БД.

Уровень 6: DDoS и перегрузка

Сайт медленный или периодически недоступен при высокой нагрузке.

Симптомы:

• Резкий рост трафика
• Много запросов с ограниченного числа IP
• Высокая загрузка CPU/памяти на сервере

Действия:

1. Включить режим «Under Attack» в Cloudflare (если используется)
2. Ограничить rate limiting на уровне веб-сервера
3. Заблокировать подозрительные IP на файрволе
4. Связаться с хостингом — они могут включить DDoS-защиту

Временные меры в Nginx:

limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
limit_req zone=one burst=20 nodelay;

Коммуникация во время инцидента

Внутренняя коммуникация

• Один канал — все обновления в одном чате/треде
• Регулярные статусы — каждые 10–15 минут краткое обновление: что сделано, что в процессе
• Роли — кто диагностирует, кто исправляет, кто коммуницирует с пользователями

Внешняя коммуникация

Если сайт недоступен долго (более 15–30 минут), пользователи ищут информацию.

Где публиковать статус:

• Страница статуса (status.example.com) — если есть
• Социальные сети (Telegram, VK)
• Email для B2B-клиентов при длительных инцидентах

Что писать:

• Кратко: «Мы знаем о проблеме, работаем над решением»
• Без технических деталей
• Ориентировочное время восстановления (если можно оценить)
• Благодарность за терпение

Пример:

«В настоящее время сайт испытывает технические трудности. Наша команда работает над устранением. Ожидаем восстановление в течение часа. Приносим извинения за неудобства.»

Восстановление и валидация

После внесения исправлений:

1. Проверьте доступность — откройте сайт, проверьте ключевые страницы
2. Проверьте функциональность — формы, авторизация, оплата
3. Проверьте мониторинг — алерты должны перейти в статус OK
4. Дождитесь стабилизации — 10–15 минут без повторных ошибок

Постмортем: что делать после инцидента

Постмортем — разбор инцидента с целью предотвращения повторения.

Структура постмортема

1. Хронология — что произошло и когда (обнаружение, диагностика, исправление)
2. Корневая причина — что именно привело к инциденту
3. Влияние — длительность, количество затронутых пользователей, потери
4. Действия по исправлению — что сделано для восстановления
5. Action items — что изменить, чтобы не повторилось (с владельцами и сроками)

Вопросы для анализа

• Как быстро мы обнаружили проблему? Если от пользователей — нужен ли более частый мониторинг?
• Как быстро локализовали причину? Есть ли пробелы в документации или навыках?
• Были ли готовы runbook'и для типичных сценариев?
• Что можно автоматизировать (автоперезапуск, алерты на метрики)?

Документирование

Сохраните постмортем в доступном месте. При повторении похожего инцидента он сэкономит время.

Чек-лист быстрой диагностики

Распечатайте или сохраните в закладках:

[ ] Сайт не открывается у меня / у других?
[ ] DNS резолвится? (dig, nslookup)
[ ] Ping доходит до сервера?
[ ] SSL-сертификат валиден? (браузер, ssl-checker)
[ ] Какой HTTP-статус возвращает? (curl -I)
[ ] Логи веб-сервера — что пишут?
[ ] Логи приложения — ошибки?
[ ] База данных доступна?
[ ] Диск не заполнен? (df -h)
[ ] CPU/память не перегружены?

Инструменты для диагностики

Uptime Monitor — мониторинг доступности. Чем раньше вы получите алерт, тем быстрее начнёте диагностику. Рекомендуемый интервал проверки — 5 минут.

SSL Checker — проверка SSL-сертификата. Используйте при подозрении на проблему с HTTPS. Для профилактики — SSL Monitor с уведомлениями об истечении срока.

DNS Lookup — проверка DNS-записей. Первый инструмент при «сайт не открывается».

Предотвращение: подготовка к инцидентам

1. Настройте мониторинг до первого инцидента. См. «Мониторинг доступности сайта: зачем нужен и как настроить».

2. Ведите runbook — документы с пошаговыми инструкциями для типичных сценариев (SSL истёк, MySQL упал, диск заполнен).

3. Рассчитайте стоимость простоя — это мотивирует инвестировать в надёжность. См. «Сколько стоит простой сайта: расчёт потерь от даунтайма».

4. Проводите учебные инциденты — раз в квартал имитируйте падение и отрабатывайте реакцию команды.

5. Держите контакты под рукой — хостинг, регистратор, CDN. В момент инцидента искать контакты в почте — потеря времени.

Runbook: типовые сценарии

Готовые инструкции ускоряют реакцию. Ниже — шаблоны для частых сценариев.

Сценарий: SSL-сертификат истёк

Симптомы: Ошибка «Ваше соединение не защищено», «Certificate has expired».

Действия:

1. Подключиться к серверу по SSH
2. Проверить путь к сертификатам (обычно /etc/letsencrypt/live/domain/)
3. Выпустить новый сертификат: certbot renew --force-renewal
4. Перезагрузить веб-сервер: systemctl reload nginx (или apache2)
5. Проверить доступность сайта
6. Настроить SSL Monitor для предотвращения повторения

Сценарий: Диск заполнен

Симптомы: 500/503, ошибки в логах «No space left on device».

Действия:

1. Проверить: df -h
2. Найти крупные файлы: du -sh /* | sort -rh | head -20
3. Очистить логи: truncate -s 0 /var/log/nginx/access.log (или ротация)
4. Удалить временные файлы, старые бэкапы
5. При необходимости расширить диск или перенести данные
6. Настроить мониторинг использования диска

Сценарий: MySQL/MariaDB не отвечает

Симптомы: «Error establishing database connection», 500 на всех страницах с БД.

Действия:

1. Проверить статус: systemctl status mysql
2. Перезапустить: systemctl restart mysql
3. Проверить логи: tail -100 /var/log/mysql/error.log
4. Проверить использование памяти: free -h
5. При OOM — увеличить лимиты или оптимизировать запросы

Сценарий: Высокая нагрузка (CPU 100%)

Симптомы: Медленный сайт, таймауты.

Действия:

1. Определить процесс: top или htop
2. Если веб-сервер — проверить логи на аномальные запросы (DDoS, боты)
3. Временно ограничить rate limiting в Nginx
4. При необходимости — заблокировать IP на файрволе
5. Связаться с хостингом для включения DDoS-защиты

Коммуникационные шаблоны

Внутреннее уведомление (Telegram/Slack)

[ИНЦИДЕНТ] Сайт example.com недоступен
Время: 14:35
Статус: Диагностика
Ответственный: @username

Обновление во время инцидента

[ОБНОВЛЕНИЕ] example.com
Проблема: SSL-сертификат истёк
Действия: Обновляем сертификат
Ожидаемое восстановление: 15–20 минут

Завершение инцидента

[РЕШЕНО] example.com
Восстановлено: 14:52
Причина: Истёк SSL-сертификат
Длительность: 17 минут
Постмортем: в течение 48 часов

Публичное сообщение (соцсети, статус-страница)

В настоящее время сайт example.com испытывает технические трудности. Наша команда работает над устранением. Приносим извинения за неудобства. Обновления: [ссылка на статус]

Метрики эффективности реагирования

Отслеживайте показатели для улучшения процесса:

Метрика	Описание	Целевое значение
MTTD (Mean Time To Detect)	Время от начала инцидента до обнаружения	< 5 минут с мониторингом
MTTI (Mean Time To Identify)	Время до определения причины	< 15 минут
MTTR (Mean Time To Resolve)	Время до восстановления	Зависит от типа инцидента
Количество инцидентов	За месяц/квартал	Тренд к снижению

Регулярные постмортемы и обновление runbook'ов снижают MTTI и MTTR.

Подготовка до инцидента

Чек-лист готовности

• Настроен Uptime Monitor с интервалом 5 минут
• Настроен SSL Monitor для критичных доменов
• Есть runbook для типовых сценариев (SSL, диск, БД)
• Контакты хостинга, регистратора, CDN — в доступном месте
• Определён канал экстренной коммуникации (чат, телефон)
• Команда знает, кто первый реагирует на алерты
• Проведена учебная тренировка (хотя бы раз)

Документация

Ведите документ с:

• Архитектурой сайта (серверы, БД, CDN, DNS)
• Учётными данными для доступа (в защищённом хранилище)
• Контактами ответственных и подрядчиков
• Историей инцидентов и постмортемов

---

Сайт упал — это не вопрос «если», а «когда». Готовность команды к инцидентам определяет разницу между 30 минутами простоя и 4 часами. Используйте этот план как основу для своего плейбука и адаптируйте под вашу инфраструктуру.