Как провести постмортем запуска и получить план улучшений

Как сделать это с Искрой

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

1. Определите границы разбора. Укажите запуск, версию, период и ожидаемый результат. Решите, разбираете ли конкретный инцидент или весь запуск. Заранее задайте вопросы: влияние, обнаружение, восстановление, принятые решения и повторение ситуации.
2. Соберите свидетельства. Подготовьте журнал развёртывания, события мониторинга, обращения поддержки и заметки участников. Для каждого факта сохраните источник, время и часовой пояс. Если сведения расходятся, оставьте обе версии и назначьте проверку.
3. Восстановите хронологию. Отделите событие от момента, когда команда о нём узнала. Включите запуск, первые симптомы, обнаружение, решение о восстановлении и контроль результата. Не заполняйте неизвестные интервалы правдоподобными действиями.
4. Посчитайте влияние с ограничениями. Выберите единицу: запрос, попытка, уникальный пользователь или денежный результат. Покажите числитель, знаменатель и окно. Не называйте число ошибок числом пострадавших людей и не переводите несостоявшиеся действия в потерянную выручку без данных.
5. Разделите причины и гипотезы. Подтверждённую связь опишите через свидетельство или воспроизведение. Для остальных объяснений укажите проверку, владельца и недостающий факт. Рассмотрите условия, которые позволили ошибке пройти проверку или остаться незамеченной, без оценки личности участника.
6. Назначьте действия и возврат к ним. Для каждой меры задайте владельца, срок и наблюдаемый критерий готовности. Разделите восстановление, предотвращение и улучшение обнаружения. На следующей встрече проверяйте выполнение и результат, а не только статус «закрыто» в задаче.

Готовый промпт - скопируйте и вставьте

Замените подсказки в квадратных скобках своими данными. Проверьте, какие материалы разрешено передавать в вашу установку Искры.

Подготовь черновик постмортема запуска по данным ниже. Запуск и ожидания: [версия, дата, целевой результат]. Источники: [безопасная хронология, журналы, метрики с определениями, заметки команды]. Известные ограничения данных: [список].
Структура: краткое резюме; ожидание и результат; влияние с формулами; хронология с источниками; что помогло и что затруднило восстановление; доказанные причины; отдельные гипотезы; действия; открытые вопросы.
Не ищи виноватого, не приписывай мотивы и не придумывай события. Факты помечай источником. Если причинная связь не подтверждена, называй её гипотезой и укажи проверку. Не считай ошибки уникальными людьми. Для действий дай таблицу: мера, тип, владелец, срок, критерий и способ проверки. Сначала перечисли противоречия и недостающие сведения. Не объявляй запуск успешным или провальным без заданного критерия. Финальные выводы согласует команда.

Что можно сделать дальше

Что важно учесть перед использованием результата

Постмортем является документом для обучения команды на произошедшем событии. Он должен сохранять проверяемую историю и объяснять, какие изменения уменьшают вероятность или последствия повторения.

Зачем это нужно

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

Как получить полезный результат

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

Где пригодится результат

Искра помогает свести разрозненные материалы и проверить структуру отчёта. Она не наблюдала запуск и не знает скрытых причин; техническую проверку и принятие мер выполняют ответственные специалисты.

Учебный запуск: ошибка отправки формы

Учебный редакционный пример. Данные вымышлены; это не запись реального запуска Искры.

Полный вход

Скачать текст

Редакционный пример с вымышленными данными, без запуска Искры. Все времена UTC+3. Журнал: 10:00 развёрнута версия 2.4; 10:05 мониторинг сообщил об ошибках формы; 10:10 дежурный начал откат; 10:20 восстановлена версия 2.3 и выполнена успешная проверка. За окно 10:00-10:20 записано 200 попыток отправки, 40 завершились ошибкой E42. Уникальные пользователи и денежное влияние не измерены. Стендовый тест после инцидента воспроизвёл E42 в версии 2.4 при пустом необязательном поле; в версии 2.3 при том же входе ошибка не возникла. В контрольном списке перед релизом такого случая не было. Поддержка предполагает влияние старого браузера, данных о версиях браузера нет. Дата разбора 12 ноября.

Пример результата

Скачать текст

Резюме: после запуска версии 2.4 зафиксированы ошибки формы, восстановление подтверждено в 10:20. Хронология: запуск 10:00; обнаружение 10:05; начало отката 10:10; контроль восстановления 10:20, источник всех четырёх событий: журнал. Окно влияния 20 минут; задержка обнаружения от запуска 5 минут. Ошибки: 40 / 200 = 20% попыток; это не доля уникальных пользователей. Подтверждённый дефект: сценарий с пустым необязательным полем воспроизводит E42 в 2.4. Сопутствующий пробел: сценарий отсутствовал в контрольном списке. Гипотеза о старом браузере не подтверждена. Действия: разработчик до 14 ноября исправляет обработку поля и подтверждает тестом; тестировщик до 14 ноября добавляет регрессионный сценарий, проверяет пустое и заполненное значение; аналитик до 15 ноября проверяет доступность данных браузера и фиксирует вывод. Деньги и число пострадавших людей не оценены.

Как проверить пример

• 10:20 минус 10:00 = 20 минут; 40 / 200 = 20% попыток.
• Четыре события взяты из журнала, гипотеза браузера не названа установленной причиной.
• У каждой меры есть роль, срок и проверяемый результат; поиск виноватого отсутствует.

Ошибки, которые стоит проверить

Одна причина на всё

Не сводите сложный запуск к последнему нажатию кнопки. Отдельно проверьте дефект, обнаружение и процесс допуска изменений.

Расчёт выручки из числа ошибок

Попытки могут повторяться и не соответствовать покупкам. Без связки с пользователями и платежами денежный эффект остаётся неизвестным.

План из пожеланий

«Стать внимательнее» нельзя проверить. Запишите конкретное изменение, ответственного и сценарий приёмки.

Связанные материалы

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

Все статьи о работе в Искре →