Инцидент под нагрузкой ломает не сервис, а вашу способность видеть причину

Инцидент под нагрузкой ломает не сервис, а вашу способность видеть причину

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

Делите реакцию на два контура:
— containment: изоляция узла, очереди, сегмента сети или учетной записи;
— preservation: фиксация volatile-данных, дампов, запросов, срезов очередей, конфигурации и актуального состояния доступа.

Под высокой нагрузкой запрещено полагаться на интерактивную диагностику как на основной метод. Команды, которые создают I/O, конкурируют с продакшеном за те же ресурсы. Для сбора используйте заранее подготовленные скрипты с лимитами по CPU, памяти и времени выполнения, а сами артефакты складывайте в неизменяемое хранилище с отдельным доступом. Иначе вы получите не форензику, а вторичный инцидент.

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

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