«Индустрия научилась автоматизировать деплой и мониторинг, но культура работы с ошибками всё ещё живёт по законам совета старейшин. Страх наказания за сбой превращает разбор в формальный ритуал, где ищут не слабое звено в системе, а человека на роль виноватого. В итоге команда учится не предотвращать проблемы, а лучше их прятать. Реальная практика post‑mortem — это не протокол, а способ перестроить мышление: сбой это не ЧП, а плановый сигнал для эволюции инфраструктуры.»
Чего вы на самом деле ждёте от постмортема?
Когда система ломается, первая реакция — найти точку приложения силы. Кто нажал кнопку? Кто недосмотрел? Этот поиск даёт иллюзию контроля: проблема решена, если наказан человек. Но такой подход работает только с механистическими сбоями, которые больше не повторятся. В сложной ИТ-среде, где сотни сервисов и тысячи зависимостей, единичная ошибка — это симптом, а не болезнь.
Если команда знает, что разбор закончится персональными выводами, инженеры начинают работать в оборонительном режиме. Они перестанут вносить рискованные, но необходимые изменения, будут избегать ручного вмешательства даже в критичных ситуациях, а мелкие аномалии в логах останутся без внимания. Система становится хрупкой: формально процессы соблюдены, но фактическая надёжность падает, потому что люди боятся её трогать.
Цель постмортема — перепрошить эти инстинкты. Вместо вопроса «кто виноват?» — «какие условия позволили ошибке пройти до производства?». Вместо «как наказать?» — «какие инструменты или проверки могли остановить цепочку?» Это сдвиг с человеческого фактора на фактор системный. Команда перестаёт быть источником проблем и становится главным ресурсом для их обнаружения.
Подготовка к разбору: правила игры
Психологическую безопасность нельзя включить по желанию в день встречи. Её создают заранее, формализуя правила в регламенте и показывая на практике, что они работают.
Правило первое и незыблемое: постмортем — зона, свободная от обвинений. Все формулировки должны описывать поведение систем и процессов. Фраза «администратор забыл добавить диск» превращается в «процедура развёртывания не включает обязательную проверку прогноза роста данных, полагаясь на память сотрудника». Это не игра в слова, а переключение фокуса с единичного действия на тиражируемый процесс.
Правило второе: состав участников. В разборе участвуют только те, кто был непосредственно вовлечён в инцидент или работу с системой: инженеры, дежурные, разработчики. Руководители, не связанные с операционной деятельностью, на встречу не приглашаются. Их присутствие, даже при молчании, меняет динамику: обсуждение превращается в доклад. Менеджмент получает готовый отчёт с выводами и планом действий.
Правило третье: основа — данные, а не воспоминания. Ответственный за проведение (часто это инженер ИБ или архитектор) до встречи собирает все артефакты: логи систем и приложений, алерты мониторинга, записи из чатов инцидента, историю изменений в Git и конфигурациях. Задача — построить объективную временную шкалу событий. Эта шкала станет единственным источником истины во время обсуждения.
Проведение встречи: от хронологии к первопричинам
Ведение встречи — это следование собранной хронологии, но не пассивное её зачитывание. На каждом значимом этапе задаётся цикл вопросов:
- Что зафиксировано в данных? Констатация: «В 11:34:05 лог-агрегатор перестал получать события с кластера А». Это факт, с ним нельзя спорить.
- Какое поведение мы ожидали от системы? Ожидание: «Health‑check балансировщика должен был обнаружить недоступность ноды за 15 секунд и исключить её из ротации».
- Какое поведение мы увидели фактически? Реальность: «Health‑check сработал через 4 минуты, 90% трафика ушло в ошибку».
- Почему возник разрыв? Здесь начинается анализ: «Настройка таймаута health‑check была увеличена месяц назад для другой задачи и забыта, документация не обновлялась».
Метод «пяти почему» — основной инструмент на этом этапе. Его цель — пройти путь от симптома до системной причины.
- Почему упал критичный микросервис? — Исчерпал память (OOM Kill).
- Почему исчерпал память? — В новой версии появилась утечка при обработке специфичного запроса.
- Почему это не выявили в тестировании? — Нагрузочное тестирование проводилось на устаревшей версии стенда, не полностью повторяющей прод.
- Почему стенд устарел? — Нет автоматизированного процесса синхронизации конфигураций тестового и продуктивного окружений.
- Почему такого процесса нет? — Потому что задачи по инфраструктуре тестирования всегда проигрывают в приоритете задачам по разработке нового функционала.
Коренная причина найдена: это приоритизация, заложенная в процесс планирования. Винить тестировщика или разработчика бессмысленно — система принятия решений не ставила надёжность тестового окружения в приоритет.
Документирование: форма, которая защищает суть
Отчёт о постмортеме — это не отписка для начальства, а рабочий инструмент. Его структура заставляет держать фокус на системных улучшениях и исключает возврат к поиску виноватых.
| Раздел | Содержание | Цель |
|---|---|---|
| Краткое резюме | Суть, длительность, бизнес-воздействие (например, «частичная недоступность личного кабинета на 47 минут, потеряно ~200 сессий»). | Дать контекст любому читателю за минуту. |
| Детальная хронология | Таблица с метками времени, источниками данных (ссылки на логи, скриншоты дашбордов) и описанием событий. | Создать неопровержимую основу для будущего анализа. |
| Коренные причины | Список, сформулированный через призму процессов. Пример: «Процесс обновления ПО не включает этап проверки влияния на все зависимые cron-задачи». | Чётко указать на системные точки отказа. |
| Принятые меры (исправление) | Что уже сделано, чтобы вернуть систему в рабочее состояние («расширен лимит памяти», «откат версии»). | Зафиксировать временные решения. |
| План предотвращения (предупреждение) | Конкретные задачи с владельцами и сроками, направленные на устранение коренных причин. Формат: «Владелец: Сидоров А.В., срок: 20.05, задача: Внести в регламент change management обязательный чек-лист проверки системных демонов после обновления ОС». | Превратить выводы в обязательные к исполнению улучшения. |
| Открытые вопросы | Темы для дальнейшего изучения («Почему бэкап на этом этапе восстановления оказался битым?»). | Не оставлять «подвисшие» темы. |
Такой документ — актив для команды и защита при взаимодействии с регулятором. Для ФСТЭК и в рамках 152-ФЗ он демонстрирует не факт сбоя, а зрелость процессов управления инцидентами и их непрерывного улучшения.
Типичные ошибки и как их избежать
Даже понимая теорию, на практике команды часто попадают в одни и те же ловушки.
- Размытые выводы и планы. Пункт «усилить мониторинг» не имеет ценности. В плане должно быть: «До 30.05 внедрить алерт на аномальный рост количества TCP-соединений на шлюзе API, порог — 10 000, ответственный — команда платформы». Конкретика — это измеримый результат.
- Игнорирование удачных действий. Постмортем должен фиксировать не только сбои, но и сильные стороны. «Браузер отправил пустой ответработе».
- Игнорирование того, что сработало. Если команда быстро восстановила данные благодаря отлаженной процедуре бэкапа, или мониторинг корректно отследил второстепенную метрику, предсказавшую сбой — это надо зафиксировать. Это укрепляет правильные практики и показывает, что система защиты не сломана полностью.
- План-призрак. Задачи из плана предотвращения должны вставать в общий бэклог продукта с нормальным приоритетом. Если их постоянно откладывают, ритуал постмортема становится циничной игрой. Один из способов — привязать часть бонусов или KPI команды к закрытию таких «упреждающих» задач.
- Страх регулятора. Многие считают, что любой задокументированный инцидент привлечёт лишнее внимание проверяющих. На деле всё наоборот. Регулятор (ФСТЭК) в рамках 152-ФЗ оценивает не отсутствие сбоев, а зрелость системы защиты информации. Грамотный постмортем, показывающий анализ и работу над ошибками, — прямое доказательство действенности СУИБ. Сокрытие же инцидента — это нарушение, которое при обнаружении нанесёт куда больший репутационный и финансовый ущерб.
Культура, а не ритуал
Итоговая эффективность постмортема определяется не качеством одного отчёта, а тем, как изменилось поведение команды в промежутках между инцидентами. Признаки работающей культуры:
- Инженеры сами инициируют разбор мелких аномалий, не дожидаясь серьёзного простоя.
- В чатах инцидентов появляются не только сообщения о проблемах, но и ссылки на прошлые похожие случаи и их решения.
- Новые сотрудники быстро усваивают, что честное описание своей ошибки — это не карьерный риск, а способ улучшить систему для всех.
Такая культура не строится приказами. Она начинается с первого разбора, на котором руководитель, вместо требования «предоставить объяснительную», задаёт вопрос: «Что в наших процессах нужно изменить, чтобы эта ошибка стала невозможной?». Это сложный переход от культуры контроля к культуре обучения, но именно он создаёт команды и системы, способные не просто гасить пожары, а постоянно становиться надёжнее.