Форензика под нагрузкой ломается первой — если не готовить её до инцидента

Форензика под нагрузкой ломается первой — если не готовить её до инцидента

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

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

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

Отдельно проверьте, что observability не становится точкой отказа: лимиты на объём, backpressure, очередь доставки, резервный канал экспорта. Если лог-агент ест CPU и диск вместе с атакованным сервисом, это не телеметрия, а ускоритель отказа.

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