«Если у вас нету политики проведения разборов инцидентов, то вы будете совершать одни и те же ошибки снова и снова, просто меняя исполнителей. Это не культура безопасности, а театр».
Зачем нужны разборы инцидентов
Каждый сбой, утечка или взлом, это дорогостоящий урок. Потраченные на восстановление человеко-часы, упущенная выгода, репутационные потери — всё это уже случилось. Единственный способ оправдать эти затраты — извлечь из них максимум знаний. Разбор полётов (post-incident review, PIR) превращает разовый ущерб в структурные улучшения системы. Без него инциденты превращаются в циклическую историю: вы тушите пожары, но не ищете причины возгорания.
Ошибочно считать, что цель PIR — найти и наказать виновного. Это верный путь к «культуре молчания», где инженеры будут скрывать инциденты или минимизировать их последствия. Истинная цель — понять системные причины, которые позволили ошибке человека, сбою в коде или уязвимости в конфигурации привести к реальным последствиям.
Подготовка: собрать улики, пока они не остыли
Проводить разбор нужно быстро, пока детали свежи в памяти участников, но не в горячей фазе, когда все ещё на взводе. Оптимально — в течение 1-3 рабочих дней после стабилизации ситуации.
Перед самой встречей модератор (это не обязательно руководитель, часто это ведущий инженер или архитектор) должен собрать первичные данные. Это основа для конструктивного разговора:
- Хронология событий. Логи серверов, метрики мониторинга, записи систем тикетов, переписка в рабочих чатах. Нужно восстановить таймлайн с точностью до минут.
- Артефакты. Скриншоты ошибок, дампы логов с критичных узлов, конфигурационные файлы (очищенные от чувствительных данных).
- Список вовлечённых. Кто обнаружил проблему, кто принимал решения, кто выполнял действия по восстановлению.
Без этой подготовительной работы встреча рискует скатиться в обмен эмоциями и субъективными воспоминаниями.
Правила встречи: безопасность вместо поиска крайнего
В начале разбора модератор должен чётко озвучить и зафиксировать правила. Это критически важно для создания атмосферы психологической безопасности.
- Мы расследуем систему, а не людей. Обсуждаются действия и решения, а не личные качества.
- Допущение добрых намерений. Каждый участник в момент инцидента действовал, исходя из своей лучшей оценки ситуации и доступных ему знаний.
- Фокус на фактах. Предположения отмечаются как таковые и верифицируются данными.
- Конфиденциальность. Обсуждаемое в комнате не используется для персональных оценок или вне контекста улучшения процессов.
Модератор следит за соблюдением этих правил, пресекая обвинительные формулировки («ты недосмотрел») и переводя их в системные вопросы («почему сигнал тревоги не был виден?»).
Структура разговора: от симптомов к корням
Хороший разбор идёт по чёткому сценарию, напоминающему расследование.
1. Восстановление таймлайна
Вместе с участниками детально восстанавливается последовательность событий: первый симптом, первые реакции, ключевые точки принятия решений, момент стабилизации. Используются собранные артефакты. Цель — создать единую, разделяемую всеми картину произошедшего, без пробелов и противоречий.
2. Анализ воздействия
Чётко и количественно (где возможно) оценивается ущерб. Сколько пользователей затронуто? Какова длительность простоя? Каков финансовый ущерб (если можно оценить)? Каков ущерб репутации? Это нужно не для отчёта перед начальством, а для понимания серьёзности системных пробелов.
3. Поиск коренных причин: методика «5 почему»
Это ключевой этап. Нельзя останавливаться на первой, очевидной причине (например, «разработчик задеплоил баг»). Нужно копать глубже, задавая вопрос «почему это произошло?» последовательно, обычно 3-5 раз.
- Почему 1: Сервис упал. Потому что исчерпалась память на инстансе.
- Почему 2: Почему исчерпалась память? Потому что новый код содержал утечку памяти.
- Почему 3: Почему код с утечкой попал в прод? Потому что тесты на нагрузку не выявили проблему.
- Почему 4: Почему нагрузочные тесты не выявили утечку? Потому что они не моделируют 48-часовую беспрерывную работу сервиса под пиковой нагрузкой.
- Почему 5: Почему мы не тестируем на длительных интервалах? Потому что инфраструктура для таких тестов считается слишком дорогой, а требования к стабильности сервиса формально не включают такие сценарии.
Видно, как поверхностная техническая причина (утечка памяти) выводит на глубинные системные и процессуальные проблемы (бюджет на тестирование, неполные требования).
4. Генерация корректирующих действий
На этом этапе переводят выявленные коренные причины в конкретные, измеримые и назначенные задачи. Важно разделять их на два типа:
| Тип действия | Цель | Пример |
|---|---|---|
| Исправляющее (remediation) | Ликвидировать последствия *этого конкретного* инцидента. | Откатить проблемный релиз, починить сломанный сервер. |
| Предотвращающее (prevention) | Устранить коренную причину, чтобы это *не повторилось* в будущем. | Добавить в CI/CD нагрузочный тест на 48+ часов. Внести правки в политику тестирования. |
Фокус должен быть на предотвращающих действиях. Каждое действие получает ответственного и срок. «Улучшить мониторинг» — не действие. «Добавить в дашборд Zabbix график потребления памяти контейнером X с алертом при достижении 80% за 1 час — ответственный Иванов, к 15.04» — действие.
Документирование: отчёты, которые будут читать
Итогом разбора становится документ. Он не должен быть километровым описанием. Его структура:
- Краткое резюме (Executive Summary). 3-5 предложений: что случилось, когда, какое основное воздействие и ключевая коренная причина.
- Детальный таймлайн. Для тех, кто будет разбираться в деталях.
- Коренные причины. Список, выведенный методом «5 почему».
- Корректирующие действия. Таблица с типом действия, описанием, ответственным, сроком и статусом.
- Извлечённые уроки (Lessons Learned). Самая ценная часть. Выводы общего характера, которые можно применить к другим системам. Например: «Наши нагрузочные тесты не покрывают сценарии длительной работы. Необходимо провести аудит всех критичных сервисов на этот риск».
Этот документ — не отчёт для архива. Он должен быть публичным (в рамках компании) и живым. Статусы по действиям регулярно обновляются.
Типичные ошибки, которые обесценивают процесс
- Пропуск фазы подготовки. Встреча без данных превращается в дискуссию.
- Модератор-обвинитель. Если ведущий ищет виноватых, процесс разрушается.
- Фокус на исправляющих, а не предотвращающих действиях. Залатали дыру, но не починили протекающую крышу.
- Отсутствие follow-up. Запланированные действия забываются, через полгода инцидент повторяется.
- Слишком формальный, бюрократический язык в отчёте. Документ пишется для галочки, а не для инженеров.
Интеграция с регуляторными требованиями
Для специалиста ИБ в России процесс PIR, это не просто best practice. Он напрямую связан с выполнением требований 152-ФЗ и документов ФСТЭК. Например, Приказ ФСТЭК №17 требует наличия политики обработки инцидентов ИБ, которая должна включать этап анализа причин и выработки мер по недопущению в будущем. Грамотно проведённый разбор с документально зафиксированными корректирующими действиями является прямым доказательством выполнения этих требований для внутреннего аудита или проверки регулятора.
Более того, уроки, извлечённые из технических инцидентов (сбоев доступности), часто выявляют слабости, которые в ином сценарии могли бы привести к инциденту информационной безопасности. Универсальность метода в его фокусе на системных, а не человеческих ошибках.