Postmortem Database

«У нас есть папка в Confluence с постмортемами» — это не postmortem database. Это свалка. Я регулярно вижу команды, где архив формально существует: Confluence space, Notion database, каталог в git. Никто, кроме автора, оригинал второй раз не открывает. Через год архив зарастает: одни и те же факторы вклада всплывают в новых инцидентах, потому что прошлый урок никто не нашёл. Postmortem database — это систематический архив с поиском, тегированием и регулярным пересмотром, который превращает стопку разборов в знание, которым можно пользоваться. Граница с Postmortem Culture явная: тот лист — про норму разбора (как мы говорим про ошибки); этот — про систему хранения и извлечения уроков из того, что норма уже произвела.

Я считаю, что без базы постмортемная практика теряет бо́льшую часть своей ценности, и теряет её не сразу, а тихо. Сам разбор полезен в моменте: команда учится, задачи закрываются, runbook’и обновляются. Дальше начинается ротация. Через два-три года люди, которые были в том инциденте, работают в другом месте, а новый инженер смотрит на нечитаемый список прошлых аварий и не догадывается, что нужный ему ответ там уже лежит. База с тегами и поиском — это временной интерфейс к опыту команды: уроки доступны и тем, кто пришёл через два года.

Что должен уметь

Главный навык на уровне L5 — проектировать схему тегирования так, чтобы поиск работал. Тега «сервис» мало: через год поиск по слову «база» вернёт сорок документов, и не прочитает их никто. Рабочая схема держится на нескольких осях: сервис, тип отказа (потеря данных / недоступность / деградация / безопасность / расхождение конфигурации), категория фактора вклада (деплой, конфигурация, ёмкость, зависимость, человек, пробел в мониторинге) и severity. По ним запрос «потеря данных из-за расхождения конфигурации на сервисе X за последние два года» отдаёт три документа, а не сорок.

Знает, где живёт postmortem database команды; умеет искать прошлые постмортемы по тегам или симптому. Перед написанием нового постмортема проверяет похожие в архиве.
В каждом новом постмортеме явно ссылается на похожие из архива: «конфигурация на сервисе X расходится четвёртый раз за год». Один документ так превращается в сигнал о закономерности.

Тегирует свой постмортем по командной схеме: service, failure category, contributing factors, severity. Не «забыли тег» — без тега postmortem не находится через год.
Регулярно, например раз в месяц, перечитывает свежие постмортемы команды и отмечает повторяющиеся сценарии отказа; формулирует выводы, которые шире одного инцидента.

Проектирует схему тегирования для команды или функции: какие оси, насколько дробные, как схема меняется со временем. Без явного замысла она расползается за полгода.
Раз в квартал перечитывает базу целиком: какие категории преобладают, какие факторы вклада повторяются, где видна системная проблема. Это вход для приоритетов на следующий период — куда вкладывать в надёжность.
Использует database как источник сценариев для Game Day / Chaos Drills: прошлые инциденты — лучший материал для тренировки команды.

L6+

Налаживает обмен постмортемами между командами, чтобы выводы расходились дальше границы одной команды.
Отстаивает публичные постмортемы как норму для значимых инцидентов, по модели GitLab, Cloudflare и Stripe. Ведёт переговоры с юристами и PR в спорных случаях.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 15. Раздел «Sharing Postmortems Openly» — фундамент всей практики распространения разборов; Google здесь пример компании с многолетней внутренней базой. Про схему тегирования конкретики почти нет, но дисциплина обмена описана.
John Allspaw — Each Necessary, But Only Jointly Sufficient (Kitchen Soap, 2012). Не про архив, а про подход NBJS, который превращает стопку разборов в набор данных, где видны закономерности. Накопительный анализ работает только тогда, когда факторы вклада сформулированы в этой логике.

Статьи и доклады

Cloudflare Outage Reports — рубрика постмортемов Cloudflare, размеченная тегом в корпоративном блоге. Ровно тот случай, когда публичный архив собран через tagging, а не через отдельный продукт. Полезно как образец глубины разбора.
GitLab: Postmortem of database outage of January 31 — их самый цитируемый постмортем. Отдельной рубрики «postmortem» в блоге GitLab нет, документы лежат вперемешку с остальными постами — и это само по себе показательно: даже у компании с сильной культурой разбора архив не обязательно организован.
Dan Luu — Post-mortems (GitHub). Собранный сообществом указатель публичных постмортемов разных компаний. По моим наблюдениям, самый полезный единичный источник, когда нужен реальный случай нужной категории. Отсюда же берут сценарии для game day и материал для обучения.

Инструменты

Markdown в репозитории git с frontmatter — самый простой и работающий формат. Один постмортем — один файл, в frontmatter лежат теги (сервис, severity, категории, дата), поиск через grep или поиск GitHub. По моим наблюдениям, для команды до тридцати человек этого хватает.
Notion / Confluence database — структурированная база с полями и фильтрами. Имеет смысл, когда команда уже живёт в этих инструментах и не хочет миграции в git. Главная ловушка — расхлябанность в тегах: богатый редактор провоцирует писать свободным текстом, а не заполнять поля.
Incident.io / FireHydrant / Rootly — платформы управления инцидентами со встроенным учётом постмортемов и тегами. По моим наблюдениям, оправданы от полусотни инженеров и при инцидентах не реже раза в неделю. Главный выигрыш — автоматическая связка «инцидент → разбор → задачи».
Схема тегов в git как первый артефакт — простой файл postmortems/tagging.md со списком допустимых значений для каждого поля. Без него разметка расползается за полгода и поиск перестаёт работать.

Best practices

Главный публичный кейс — публичные постмортемы Cloudflare. Разборы значимых инцидентов лежат в корпоративном блоге под тегом outage, то есть архив собран ровно тем механизмом, который я описываю в этом листе: не отдельный продукт, а последовательная разметка. Читатель приходит по ссылке из чужой статьи, видит рубрику и уходит читать соседние разборы. Это и есть работающая database, только публичная. Ценность здесь не в том, что документы идеально написаны, а в том, что они доступны и используются: их цитируют, инженеры читают их перед похожими миграциями, авторы новых постмортемов смотрят на старые как на образец.

Контрпример из той же лиги — GitLab. Их постмортем database outage 31 января 2017 — вероятно, самый цитируемый публичный разбор в индустрии, но отдельной рубрики для постмортемов в блоге у GitLab нет: документы лежат вперемешку с продуктовыми анонсами и находятся только через внешний поиск. Сильная культура разбора и организованный архив — разные вещи, и второе не появляется автоматически из первого.

Короткие правила:

База без тегов — свалка. Папка в Confluence и поиск по всему тексту работают ровно до первого года: дальше запрос «база» возвращает сорок страниц, и не читает их никто. Нужна явная схема — сервис, тип отказа, категории факторов вклада, severity, — и проверка разметки на ревью, иначе схема остаётся пожеланием.
Квартальный пересмотр — обязательная часть практики. Без него база превращается в чулан, где ценное лежит вперемешку со всем остальным. Раз в квартал команда перечитывает сводку свежих разборов, ищет повторы и формулирует выводы поверх отдельных инцидентов. Так учится команда, а не только участники конкретной аварии.

Отдельно про публичность. «Постмортем — внутренний документ» звучит осторожно и безопасно, а стоит за этим простая арифметика: команда учится только на своих инцидентах, а индустрия — на коротких новостях, из которых ничего не следует. Разумный вариант по умолчанию — публиковать значимое: заметный клиентам простой длиннее оговорённого порога, потерю данных, инциденты безопасности. Тогда закрытый разбор становится обоснованным исключением, которое кто-то принимает решением, а не молчаливой привычкой. Так живут GitLab, Cloudflare и Stripe.

Подробнее:

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

Разбор как материал для game day. Лучший источник сценариев для Game Day / Chaos Drills — собственные прошлые постмортемы. Сценарий реальный, команда та же, runbook’и те же: дыры однажды нашли, осталось проверить, что их закрыли, а не просто записали. Архив перестаёт быть архивом. По моим наблюдениям, там, где постмортемы идут в учения, база живее: её открывают и правят, а не держат для отчётности.

Схема тегов растёт, но не самотёком. На старте достаточно 3-4 категорий, через год их станет больше — это нормальный рост, схема догоняет то, что команда научилась различать. Ненормально другое: каждый инженер заводит свои теги на ходу, и через полгода схемы просто нет. Лечится дёшево. Схема живёт отдельным документом в репозитории, правки идут через ревью, и на каждый запрос «добавьте тег» кто-то спрашивает: это новая категория или синоним существующей? Иначе через год в базе живут «db-incident», «database-incident», «db-failure» и «database-failure» как четыре разные вещи.

Обмен между командами — следующий шаг после своей базы. Команда А научилась. Команды B и C продолжают наступать на те же грабли, и на уровне организации выигрыша нет никакого. Механизм, который я наблюдаю работающим, до неприличия прост: ежемесячная рассылка на одну страницу — короткие выжимки значимых разборов всех команд и ссылки на оригиналы. Пятнадцать минут чтения в месяц окупаются одним неповторённым инцидентом у соседей.

Связанные листья

Postmortem Culture — норма разбора (как мы говорим про ошибки); этот лист — система хранения и извлечения уроков из того, что норма уже произвела. Без нормы разбора база наполняется отписками в духе «причина: человеческий фактор».
Blameless Postmortem — процедура разбора, которая и порождает документы для базы; качество шаблона определяет качество разметки.
Action Items Tracking — постмортем без задач — незаконченный документ; база связывает разбор с задачами и показывает, какие из них систематически не закрываются.
Runbooks — каждый разбор тянет за собой правку runbook; база — место, где видно, какой runbook открывали в каком инциденте.
Playbooks — правки playbook — частый результат разбора; закономерности, найденные в базе, чаще всего и превращаются в новые точки решения.
Game Day / Chaos Drills — постмортемы из database — главный источник сценариев game day; реальные инциденты лучше любых вымышленных.
Communities of Practice — сообщество по надёжности — естественное место для обмена разборами между командами; ежемесячная выжимка обычно живёт там же.
Incident Response — платформы управления инцидентами сами связывают инцидент, разбор и базу; это инструментальная сторона той же практики.

Открытые вопросы

Автоматический поиск закономерностей — ассистент, который читает все разборы и сам предлагает повторы: одни и те же факторы вклада, сервисы с регулярными проблемами, задачи, которые никогда не закрываются. На начало 2026 года активная область (incident.io AI Postmortem, FireHydrant Signals), но рабочих кейсов в публичной литературе пока мало.
Публикация по умолчанию в B2B — Cloudflare, GitLab и Stripe показали, что публичные разборы совместимы и с доверием клиентов, и с их удержанием. Я не уверен, как это переносится на B2B в регулируемых отраслях — финтех, медицина, — где договор с клиентом закрывает детали инцидента соглашением о неразглашении. Если есть рабочая модель — расскажите PR’ом.
Срок хранения — нужен ли разбор 2018 года про сервис, который давно выключен? Публичной литературы по этому вопросу я не нашёл. Скорее всего, правило жизненного цикла — хранить вечно, убирать в архив через N лет или удалять вместе с сервисом — каждая команда придумывает себе сама.