Первые 60 минут после сбоя: сценарий технического реагирования

До таймера: определите, действительно ли это серьёзный инцидент

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

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

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

0–10 минут: остановите хаос и сохраните факты

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

Запишите время обнаружения, симптомы, последние успешные операции и известные изменения перед сбоем. Сохраните сообщения ошибок, идентификаторы событий, графики и состояние мониторинга. Используйте единый журнал, доступный команде даже при отказе основной инфраструктуры.

1. Подтвердить влияние независимой проверкой, а не только одним алертом.
2. Назначить координатора, технических исполнителей и ответственного за коммуникацию.
3. Остановить несогласованные изменения и автоматические задачи, способные ухудшить состояние.
4. Создать временную шкалу: факт, источник, время и выполненное действие.
5. Оценить угрозу безопасности людей, данных и инфраструктуры.

10–20 минут: локализуйте слой отказа

Идите от пользовательского симптома к зависимостям: клиент, DNS и сеть, балансировщик, приложение, служба каталогов, СУБД, хранилище, гипервизор и питание. Проверяйте факты с двух сторон. Успешный ping не доказывает работоспособность приложения, а высокая загрузка CPU может быть следствием, а не причиной.

Сравните время начала сбоя с журналом изменений, развертываниями, обновлениями сертификатов и событиями мониторинга. Корреляция полезна, но не доказывает причинность. Если последнее изменение обратимо и явно связано с симптомом, используйте утверждённый откат. Не меняйте сразу несколько параметров.

• Какой минимальный синтетический запрос воспроизводит отказ?
• Есть ли здоровый экземпляр или доступен ли сервис из другого сегмента?
• Какая общая зависимость есть у всех пострадавших компонентов?
• Продолжается ли запись данных и может ли она ухудшить целостность?
• Что изменилось непосредственно перед началом симптомов?
• Есть ли достаточные ресурсы и свободное место на критичных томах?

20–30 минут: ограничьте влияние без необратимых действий

Цель локализации — остановить расширение ущерба и выиграть время. Это может быть вывод неисправного узла из балансировки, остановка проблемного задания, перевод приложения в режим обслуживания, блокирование записи или изоляция сетевого сегмента. Выбирайте минимальное действие, которое снижает влияние и сохраняет диагностические данные.

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

30–45 минут: выберите восстановление, обход или резервный контур

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

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

1. Сформулировать гипотезу, подтверждающие факты и неизвестные.
2. Сравнить варианты по времени, риску данным, обратимости и доступным специалистам.
3. Выбрать стратегию и зафиксировать критерий успеха и предельное время попытки.
4. Подготовить возврат, если выбранное действие ухудшит состояние.
5. Выполнить одно изменение, проверить технический и пользовательский результат.

Не восстанавливайте копию только потому, что она есть. Сначала проверьте её дату, целостность, совместимость версии и отсутствие признаков компрометации.

45–60 минут: подтвердите сервис и задайте следующий цикл

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

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

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

• Подтверждена ключевая операция от имени обычного пользователя.
• Ошибки и задержки не растут после восстановления.
• Данные сверены на минимально необходимом бизнес-наборе.
• Мониторинг и резервное копирование снова работают.
• Временные изменения задокументированы и имеют владельца.
• Назначено время следующего статуса и состав участников.

Коммуникация: сообщайте факты, влияние и следующий срок

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

Технический канал и бизнес-коммуникацию разделяют. В техническом журнале остаются гипотезы, команды и подробные ошибки; пользователям нужны влияние и доступный обход. Юридические уведомления о персональных данных, регуляторах или договорных нарушениях определяются применимыми требованиями и договорами — инженерная команда фиксирует факты, но не придумывает правовую квалификацию.

После стабилизации: не потеряйте уроки первого часа

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

Разбор проводите по фактам временной шкалы. Ищите не виновного, а условия: почему отказ повлиял на сервис, почему мониторинг заметил его поздно, какой шаг занял больше времени и какая защита не сработала. Корректирующие действия должны иметь владельца и срок; общая формулировка «усилить контроль» ничего не меняет.

• Обновить runbook реальными командами и временем выполнения.
• Добавить мониторинг симптома, который обнаружили пользователи.
• Проверить отказоустойчивость и восстановление на учении.
• Закрыть временные доступы, правила сети и режимы диагностики.
• Отдельно оценить технические, процессные и договорные последствия.