Что делать, если сайт стал недоступен

Это минимальный план действий для on-call, чтобы быстро вернуть сайт, уменьшить простои и подготовить данные для разработчиков. Делается так, чтобы даже человек без глубоких знаний мог выполнить базовые шаги по инструкции.

Первые 30 минут - шаги по минутам

  • 0–2 мин - оповещение: отправьте в чат команду «site-down» с ссылкой и временем обнаружения.

  • 2–6 мин - проверка внешнего статуса: используйте curl или монитор в облаке - 200/500/timeout.

  • 6–10 мин - проверьте последние деплои и коммиты в CI; откат если был проблемный релиз за 10–20 минут.

  • 10–15 мин - перезапуск сервисов: nginx, app-процессы, очередь - по checklist.

  • 15–20 мин - проверьте логи ошибок (последние 500 строк) и наличие пиков по ресурсам (CPU/Memory).

  • 20–25 мин - если не помогло - включите read-only режим (статическая страница «мы скоро вернёмся») и уведомите сторонние интеграции.

  • 25–30 мин - собрать минимальный пакет для postmortem: лог, env, commit, время, кто делал deploy.

Короткие правила решений

  • если проблема после деплоя - откатить;

  • если проблема в инфраструктуре (DB/Redis) - переключиться на резерв/replica;

  • если нет быстрого решения - включить read-only и продолжать расследование.

4 лайка

Для удобства автоматизируйте уведомления: webhook из мониторинга шлёт краткую форму в чат с кнопками «позвать инженера», «выполнить откат», «включить read-only». Это экономит 3–5 минут на координации и снижает человеческие ошибки. Если у вас нет автоматизации, положите в чат короткие команды и шаблоны, это почти так же эффективно.

3 лайка

Для платёжного сайта отдельно проверьте очереди платежных провайдеров и webhook-и, иногда проблема только в нотификациях и внешние клиенты платят, а вы не видите.

1 лайк

На первом этапе не пытайтесь всё починить идеально, задача 30 минут: вернуть сервис в рабочее состояние. Углублённое расследование оставьте на потом.

Делайте скриншоты ошибок

1 лайк

Оповещайте ключевых клиентов/партнёров, честная короткая нотификация снижает репутационные риски.

После восстановления делайте быструю сессию 15 минут с участием dev/ops/QA, фиксируйте факты и действия