Запись постмортемов: как превратить инциденты в знания команды

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

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

Зачем записывать постмортем

• Доказательства сильнее описаний: графики, трейсы и логи визуальны по своей природе — скриншот теряет динамику «до и после», которая делает всплеск очевидным
• Быстрее в подготовке: прокомментировать то, что уже открыто на экране, быстрее, чем написать выверенный текст
• Полезно новичкам: шестиминутный разбор объясняет сценарии отказов системы гораздо быстрее, чем страница вики
• Сохраняет ход мысли: документы фиксируют, что произошло; записи показывают, почему дежурный рассуждал так на каждом шаге
• Удобно для асинхронной работы: распределённая команда разберёт ревью, не собирая ещё одну встречу через часовые пояса

Что записывать, а что нет

Запись постмортема — это не повтор всего инцидента. Оставьте то, где смотреть важнее, чем читать:

Записывайте:

• Момент обнаружения — алерт, дашборд, первое обращение пользователя
• Ключевой график с влиянием на протяжении окна инцидента
• Шаги расследования, которые сузили круг (включая тупики)
• Точный код, конфигурацию или запрос, вызвавший сбой
• Применение исправления и восстановление метрик

Пропускайте:

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

Подготовка перед записью

В инструментах реагирования много того, чему не место в общем видео. Потратьте пять минут:

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

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

Работающая структура

Держите запись в пределах пяти-десяти минут. Надёжная структура:

1. Сначала влияние (30 секунд): кого затронуло, как долго и насколько сильно. Начните с этого — именно ради этого и смотрят
2. Разбор хронологии (2–3 минуты): обнаружение, эскалация, смягчение, устранение — на реальном дашборде
3. Первопричина (2–3 минуты): покажите настоящий путь в коде, изменение конфигурации или запрос. Приблизьте конкретные строки
4. Что осложнило работу (1 минута): отсутствующие алерты, запутанные логи, неясная зона ответственности — то, что документ обычно сглаживает
5. Задачи (1 минута): проговорите каждую вслух с ответственным и добавьте ссылки в описание

Как сделать материал читаемым в редакторе

Сырой материал инцидента очень плотный. Редактор Recorded превращает его в понятный рассказ:

• Эффекты зума: дашборды и строки логов мелкие. Приближайте всплеск, сообщение об ошибке, спорный диф — не заставляйте зрителя щуриться
• Скоростные участки: ускорьте пайплайны деплоя и выполнение запросов, вернитесь к обычной скорости в момент, когда проявляется первопричина
• Текстовые наложения: нанесите метки времени (02:14 UTC — первый алерт), чтобы видео соотносилось с документом
• Обрезка: уберите фальстарт, где вы поняли, что дашборд показывал не тот интервал
• Эффекты курсора: подсвечивайте клики, когда демонстрируете точный путь воспроизведения

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

Как сохранить безобвинительный тон в кадре

Видео передаёт интонацию иначе, чем текст. Одна и та же фраза звучит как анализ или как обвинение — в зависимости от подачи.

• Говорите «этот деплой привнёс», а не называйте, кто его выкатил
• Описывайте решения в контексте, который был доступен тогда: «на этом этапе у нас ещё не было метрики глубины очереди»
• Показывайте тупики без извинений: они доказывают, что систему было трудно диагностировать, а это само по себе задача на улучшение
• Перепишите вступление, если в первом дубле слышно раздражение. Две минуты работы задают тон всем зрителям

Видео вместе с письменным документом

Запись дополняет документ, а не заменяет его. Документ можно искать, цитировать и бегло просматривать — видео нельзя.

Хорошая связка:

• Документ остаётся источником истины по хронологии, задачам и ответственным
• Запись встроена в начало документа с одной строкой о её содержании
• Метки глав в описании позволяют сразу перейти к разделу о первопричине
• Задачи живут в трекере, а не только в видео

Собираем библиотеку инцидентов

Отдельные записи полезны. Коллекция гораздо ценнее.

• Единый принцип именования: 2026-09-28-checkout-latency-postmortem хорошо сортируется и ищется
• Теги по системам: группируйте по затронутому сервису, чтобы передать новому дежурному сразу всё по одному компоненту
• Поквартальный просмотр: если посмотреть записи квартала подряд, повторяющиеся сценарии отказов становятся очевидны
• Используйте при онбординге: три-четыре отобранных инцидента — самый быстрый способ показать новичку, как система ломается на самом деле

Частые ошибки

• Запись во время инцидента: сначала устраните проблему. Разбор записывайте потом, когда сможете рассказывать спокойно
• Публикация сырого материала: несмонтированная 40-минутная демонстрация экрана — не постмортем, её никто не смотрит
• Утечка клиентских данных: перед публикацией обязательно просмотрите запись целиком, специально выискивая персональные данные в логах и дашбордах
• Пропуск резюме о влиянии: тот, кто посмотрит только первую минуту, всё равно должен узнать главное
• Замена документа: через полгода, когда начнётся похожий инцидент, по видео поиск не сделаешь

Заключение

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

Запишите следующий постмортем, а не только напишите его, и посмотрите, насколько больше людей действительно им займутся.