Постмортем готовится из таймлайна, а не по памяти

Вопрос, на который отвечает эта карточкаПочему постмортем стоит инженеру ещё одного вечера, когда сбой уже устранён?

Кому подходит: инженерным командам с 5–50+ инцидентами в месяц, алертингом в PagerDuty, Datadog, Grafana или New Relic, деплоями в GitHub или GitLab и постмортемом, который кто-то должен написать потом.

Не подходит: командам с одним инцидентом в квартал, где отчёт — редкая и взвешенная работа, — и не для анализа корневой причины, который остаётся за инженером.

Типичный день

Как этот участок выглядит сегодня

Типичная картина по плейбуку software — не день конкретного клиента. От пяти до пятидесяти инцидентов в месяц — диапазон плейбука для операции среднего размера. Срабатывает алерт в PagerDuty или Datadog; дежурный инженер разбирается, соотносит логи с тем, что деплоили, находит причину, применяет исправление — и тут начинается вторая работа: восстановить таймлайн из канала инцидента, написать постмортем, обновить ранбук. Это делается последним, поздно и самым уставшим человеком. В плохую неделю отчёты сползают, и следующий дежурный встречает тот же сбой без записей.

Что меняется

Как выглядит понедельник после

Утро после инцидента. Дежурный инженер открывает постмортем, у которого уже есть скелет: таймлайн от первого алерта до разрешения, деплой, который ему предшествовал, применённая запись ранбука. Написать остаётся то, что знает только он — почему система повела себя так и что нужно изменить, — при дневном свете, а не в полночь. Стейкхолдеры получают сводку тем же утром, отправленную человеком. Видно, у каких инцидентов постмортем завершён и какие ранбуки обновлены. Atlassian (2023) измерил 2–3 часа экономии на инцидент; исправление и архитектурное решение всё так же принимают те же люди.

Типичная картина, не измеренный результат клиента. Каждая цифра — из источника плейбука, названного ниже.

2–3 ч

на инцидент уходит на сборку разбора — Atlassian (2023)

Было: кто-то восстанавливает таймлайн инцидента из чат-канала в полночь. Стало: Atlassian (2023) сообщает о 2–3 часах экономии на черновик постмортема, PagerDuty (2023) — о 25–40% от корреляции с AI — корневая причина остаётся за человеком.

Как собрана эта карточка

Atlassian «IT Service Management» (2023) сообщает, что автоматический черновик постмортема экономит 2–3 часа на инцидент; PagerDuty «State of Digital Operations» (2023) сообщает, что корреляция с AI сокращает MTTR на 25–40%. Опубликованные цифры, нами не измерены; диапазон плейбука 30–50%. Исправление остаётся инженерной работой.

Что мы ставим

Что мы ставим перед системами, которые у вас уже есть

Алертинг продолжает срабатывать из PagerDuty, Datadog, Grafana или New Relic; график дежурств не меняется, GitHub или GitLab и Jira остаются на месте. Вокруг них мы добавляем шаг корреляции и черновика через их API:

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

Начинаем с ваших самых объёмных источников алертов.

Что остаётся за человеком — и чего этот процесс не сделает

Корневая причина сбоя, которого никто раньше не видел. Исправление. Архитектура. Разговор со стейкхолдерами при крупном инциденте.

Что может пойти не так — и что мы с этим делаем

Корреляция зависит от тегирования: сервисы, названные по-разному в разных инструментах, дают таймлайны с дырами, и первые недели уходят на именование, а не на черновики. Предлагаемая категория корневой причины — предложение; принятая за ответ, она делает постмортем хуже, чем никакого, поэтому она подписана как догадка, а раздел о причине остаётся пустым для инженера. Старые инструменты мониторинга без API означают частичные таймлайны — с пометкой на черновике, а не с домыслами. Диапазон 30–50% покрывает сборку и корреляцию; цифра MTTR PagerDuty — про время разрешения, а не про отчёты; корневая причина нового сбоя вне и того и другого.

Сколько это занимает и что нужно от вас

Аудит, около двух недель (€1.5–3K): читаем инциденты и постмортемы за последний квартал, считаем, сколько было написано и с каким опозданием, и проверяем API ваших инструментов алертинга, контроля версий и чата. Пилот, 4–6 недель (€10–20K) — средняя сложность по плейбуку software, в основном чистая корреляция источников: один источник алертов, каждый черновик проверяет дежурный инженер, ничто не уходит наружу без человека. Продакшен: все сервисы, предлагаемые обновления ранбуков. От вас: доступ по API к PagerDuty, GitHub или GitLab, каналу инцидентов и ваш шаблон.

Путь: бесплатная оценка за 60 секунд → бесплатный 20-минутный разбор → платный аудит одного этого процесса (€1.5–3K, обычно две недели) → пилот, где ваши люди остаются в контуре (€10–20K, недели, а не кварталы). Никакой «программы трансформации». Цены открыты, на странице услуг →

Это про вас, если…

Инциденты поднимают алерты в PagerDuty, Datadog или Grafana, с чат-каналом на каждый?
Дежурный инженер восстанавливает таймлайн и пишет постмортем потом?
Деплои и тикеты лежат в GitHub, GitLab, Jira или Linear, которые система могла бы прочитать?

Сколько это в евро для вашей компании?

Это зависит от ваших объёмов и стоимости труда — эта страница не станет выдумывать цифру. Бесплатная 60-секундная оценка считает её по вашим ответам, с источником у каждого множителя.

Получите бесплатную оценку экономии 60 секунд · без созвона с продавцом Или сначала напишите → Составить карту операционного процесса — как в этой карточке: бесплатно, за 60 секунд → Анкета — на английском.

Это не именованный клиент Aperanda. Карточка процесса · Операции.

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

Все карточки процессов