Что делать в первые 15 минут после алерта о недоступности сайта

В 10:02 монитор прислал сообщение: https://example.com/checkout — timeout. Дежурному нужны три результата к 10:17: сохранённый исходный сигнал, оценка масштаба и решение о следующем действии. Установить первопричину за это время удаётся редко. Зато можно избежать случайного рестарта, собрать данные, которые быстро исчезают, и передать инцидент нужному специалисту.

0–2 минуты: сохраните событие

Скопируйте из алерта точный URL, время с часовым поясом, точку проверки, текст ошибки, длительность запроса и число попыток. Если сообщение содержит конечный IP, HTTP-статус, цепочку переходов или фрагмент ответа, сохраните и их. Скриншот красного индикатора без этих полей мало поможет через час.

Убедитесь, что монитор проверял действующий боевой адрес. Старый поддомен, закрытая акция и удалённая тестовая страница иногда остаются в конфигурации дольше своего срока. Затем проверьте историю этой точки: единичное событие, серия ошибок или чередование успешных и неуспешных ответов требуют разной срочности.

Создайте карточку инцидента уже сейчас. Минимальный заголовок содержит время, домен и симптом: 10:02 MSK — checkout — timeout внешней проверки. Для координации крупного сбоя используйте роли и канал из руководства по реакции на инцидент.

2–5 минут: повторите тот же запрос извне

Проверяйте полный адрес из сообщения. Переход на главную может скрыть отказ отдельного маршрута. Выполните запрос через другую внешнюю сеть или независимую точку и сохраните статус, конечный URL, время ответа и первые строки содержимого. Браузер покажет пользовательский результат, HTTP-клиент — точнее обозначит ошибку соединения и переходы.

Сделайте два-три повтора с небольшим интервалом. Такая серия выявит краткий сетевой сбой или чередование backend-узлов. Десятки одновременных запросов не нужны: во время деградации они добавят нагрузку и могут включить ограничение частоты.

Результаты записывайте рядом, не выбирая заранее «правильную» точку:

Активный VPN может провести офисный и мобильный запросы через один выход. Если маршрут важен для вывода, укажите его явно. Основы настройки независимых точек есть в статье про uptime-мониторинг.

5–8 минут: установите границу сбоя

Откройте соседние публичные точки: главную, один статический файл, URL того же шаблона и критичный API, если он доступен для безопасного чтения. Не запускайте реальный платёж и не отправляйте клиентскую форму. Нужна грубая карта масштаба.

Четыре сочетания дают первый маршрут:

• все адреса домена недоступны — проверить общий публичный путь и инфраструктуру;
• главная работает, один раздел отвечает 5xx — перейти к приложению или сервису этого раздела;
• HTML загружается, изображения и скрипты нет — проверить домен статики и CDN;
• ошибка видна одной сети или по одному протоколу — исследовать DNS, IPv4/IPv6, региональный edge и фильтрацию.

Ответ 200 тоже сравните с ожидаемым содержимым. CDN или аварийная заглушка способны вернуть успешный код со страницей ошибки. Для контрольной точки полезен устойчивый текст, связанный с функцией страницы; рекламный блок для этого слишком изменчив.

После этой проверки присвойте предварительный уровень влияния: заблокирован основной бизнес-сценарий, деградировал отдельный раздел или пока есть один неподтверждённый сигнал. Уровень можно изменить по новым данным.

8–12 минут: сопоставьте время с изменениями

Посмотрите журнал релизов, переключение feature flags, DNS, сертификаты, правила CDN/WAF и плановые работы за ближайший интервал. Совпадение по времени создаёт гипотезу. Подтверждением станет различие версий, журнал ошибки или воспроизводимый результат после безопасного отката.

Одновременно проверьте готовые панели: частоту 5xx, задержку, насыщение ресурсов и статус внешних зависимостей. Не уходите в подробное исследование каждого графика. Цель первых минут — понять, какой специалист и какой runbook нужен дальше.

Соберите строку доказательств в карточке:

10:02 внешний timeout; 10:04 мобильная сеть 502;
10:05 офис 200; другие страницы каталога 200;
09:58 выпущена версия catalog-2026.08.14.3;
следующий шаг: сравнить узлы каталога и журналы прокси.

Если браузер сообщает именно об ошибке защищённого соединения, используйте отдельный пошаговый маршрут из статьи про ошибки SSL-сертификатов. В этот момент не следует наугад менять сертификат или конфигурацию прокси.

12–15 минут: выберите вмешательство или эскалацию

Изменение допустимо, когда найден конкретный слой, известен ожидаемый эффект и предусмотрен способ отмены. Один backend систематически отвечает 502 — его можно вывести из балансировки по штатной процедуре. Ошибка появилась только в новой версии — возможен предусмотренный откат. Для неисправной DNS-записи потребуется восстановление проверенного значения с учётом TTL.

Если доказательств мало, сохраните состояние и передайте диагностику. Эскалация должна содержать:

• пользовательский эффект и предварительный масштаб;
• время первого и последнего подтверждения;
• результаты независимых запросов;
• последние связанные изменения;
• уже выполненные действия;
• владельца следующего шага и время обновления статуса.

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

Не расширяйте смысл исходного сигнала

Если событие пришло из uptime-монитора reChecker, оно относится к GET-запросу одного URL из одной внешней точки. Сервис не разделяет время DNS, TCP и TLS, а статус ниже 500 считает достижимым ответом; нежелательную страницу отличает ожидаемый текст. Поэтому timeout подтверждает ошибку конкретной проверки, но ещё не доказывает недоступность всем пользователям.

Эта граница влияет на формулировку карточки. Запись «внешняя проверка подтвердила timeout выбранного URL» точна. Вывод «сайт был недоступен всем пользователям» потребует дополнительных источников.

Карточка к пятнадцатой минуте

К моменту первого статусного обновления заполните семь полей:

После восстановления добавьте начало, обнаружение, вмешательство и момент устойчивого успеха. Причину помечайте как подтверждённую только при наличии связанной цепочки фактов. Если данных не хватило, так и запишите и добавьте измерение, которого не было в этом инциденте.