English translation is not available yet. Showing Russian content.

Создать blameless postmortem культуру

ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Создать blameless postmortem культуру

1. Цель задачи

Научиться внедрять культуру безобвинительного (blameless) анализа инцидентов в команде. Разработать шаблон postmortem, настроить процесс его ведения и провести пилотный разбор реального или смоделированного инцидента. Главный результат — инженеры перестают бояться сообщать об ошибках и начинают видеть в postmortem инструмент для улучшения системы, а не для поиска виноватых.

Ключевой результат Команда использует единый blameless postmortem шаблон для всех инцидентов уровня P0–P2, а количество добровольно сообщённых ошибок (self-reported incidents) увеличивается на 30% в течение месяца после внедрения.

2. Исходные данные

Что нужноОткуда взять
Доступ к репозиторию команды (Git)Существующий проект или создать новый репозиторий postmortems/
Примеры реальных или учебных инцидентовЛоги, дашборды, тикеты за последние 2 недели (или симулировать)
Шаблон postmortem (черновик)Open-source шаблоны (Atlassian, Google SRE, PagerDuty)
Канал коммуникации (Slack / Teams)Рабочий чат команды
Инструмент для хранения и ревьюGit + Markdown (или Confluence / Notion)
Метрики культуры (опрос)Google Forms / Typeform (опционально)

Если нет реального инцидента — симулируем:

  1. Выберите одну из типовых проблем: деградация retrieval, падение accuracy LLM, сбой в CI/CD, утечка данных.
  2. Опишите гипотетический сценарий: время, симптомы, влияние, временные метки.
  3. Подготовьте «сырые» данные: логи ошибок, графики метрик, сообщения в чате.
  4. Используйте этот сценарий для пилотного postmortem.

3. Технологический стек

КомпонентИнструментыНазначение
Хранилище postmortemGit + Markdown / Obsidian / NotionВерсионирование, ревью, поиск
ШаблонMarkdown (YAML frontmatter)Единая структура документа
CI-линтерGitHub Actions / GitLab CIПроверка заполнения обязательных полей
УведомленияSlack webhook / EmailОповещение о новом postmortem
ОпросыGoogle FormsИзмерение психологической безопасности
ФасилитацияMiro / Mural (опционально)Визуальная ретроспектива

4. Этапы выполнения

Этап 1: Исследование и дизайн шаблона (1.5 часа)

Действия

  1. Изучите принципы blameless culture: прочитайте главу из книги «Site Reliability Engineering» (Google) или статью «Blameless Postmortems» от Atlassian.
  2. Составьте список обязательных разделов blameless postmortem:
    • summary|Executive Summary (для менеджеров)
    • Timeline (хронология событий)
    • Impact (влияние на пользователей и метрики)
    • Root Cause (корневая причина, без указания имён)
    • Action Items (конкретные шаги с ответственными и сроками)
    • Lessons Learned (что пошло хорошо, что можно улучшить)
  3. Создайте файл template.md в репозитории postmortems/ со следующей структурой:
---
id: PM-{YYYY}-{MM}-{DD}-{NNN}
severity: P0/P1/P2/P3
status: draft/review/closed
author: 
reviewers: []
date: 
duration: 
tags: []
---

# POSTMORTEM: {Краткое название}

## Executive Summary
(2–3 предложения для не-технической аудитории)

## Timeline
| Время (UTC) | Событие |
|-------------|---------|
|             |         |

## Impact
- Затронутые пользователи: X%
- Упавшие метрики: ...
- Финансовые потери (если применимо): ...

## Root Cause
(Техническое описание, без обвинений)

## Action Items
| # | Действие | Ответственный | Срок | Статус |
|---|----------|---------------|------|--------|
| 1 |          |               |      | open   |

## Lessons Learned
- Что сработало хорошо:
- Что можно улучшить:
- Как предотвратить повторение:

## Appendix
(Ссылки на логи, дашборды, PR, тикеты)
  1. Добавьте в шаблон инструкцию по заполнению (комментарии в markdown).

Ожидаемый результат этапа Готовый шаблон template.md, принятый командой (минимум 2 ревью).

Этап 2: Интеграция с инструментами (1 час)

Действия

  1. Настройте Git-репозиторий postmortems/ с правами на запись для всех инженеров.
  2. Создайте GitHub Action (или GitLab CI), который при создании нового postmortem:
    • Проверяет заполнение обязательных полей (severity, timeline, root cause).
    • Отправляет уведомление в Slack-канал #incidents.
  3. Настройте автоматическое создание issue в Jira/Linear для каждого action item из postmortem (опционально).
  4. Добавьте в README репозитория ссылку на шаблон и краткую инструкцию.

Ожидаемый результат этапа Рабочий пайплайн: инженер создаёт PR с postmortem → CI проверяет → уведомление в чат.

Этап 3: Пилотный запуск (2 часа)

Действия

  1. Выберите инцидент (реальный или симулированный). Если симулируете — подготовьте сценарий и «сырые данные».
  2. Назначьте фасилитатора (не руководителя команды) — его задача следить за blameless атмосферой.
  3. Проведите встречу (30–45 мин) по следующему плану:
    • Фасилитатор зачитывает Executive Summary.
    • Команда вместе заполняет Timeline (каждый добавляет свои наблюдения).
    • Определяют Root Cause методом «5 почему» (без имён).
    • Генерируют Action Items (не более 5, конкретных и измеримых).
  4. После встречи автор оформляет postmortem в шаблоне и отправляет PR.
  5. Назначьте ревьюеров (2 человека из команды, не участвовавших в инциденте).

Ожидаемый результат этапа Опубликованный postmortem для пилотного инцидента, принятый командой.

Этап 4: Ретроспектива процесса (1 час)

Действия

  1. Соберите анонимный опрос среди участников пилота:
    • «Чувствовали ли вы себя в безопасности во время разбора?» (1–5)
    • «Помог ли postmortem найти настоящую причину?» (да/нет)
    • «Что бы вы изменили в процессе?» (свободный ответ)
  2. Проведите 30-минутную встречу для обсуждения результатов опроса.
  3. Внесите изменения в шаблон и процесс (например, добавьте раздел «Благодарности» или упростите timeline).
  4. Зафиксируйте версию шаблона (v1.0 → v1.1).

Ожидаемый результат этапа Улучшенный шаблон v1.1 и документ «Процесс проведения postmortem».

Этап 5: Документирование и обучение (1 час)

Действия

  1. Напишите короткий гайд (2–3 страницы) «Как проводить blameless postmortem»:
    • Когда проводить (после каждого P0/P1, раз в неделю для P2).
    • Кто участвует (автор, фасилитатор, ревьюеры).
    • Правила blameless (не искать виноватого, фокус на системе).
  2. Проведите 15-минутное демо для всей команды (запись можно сохранить).
  3. Добавьте ссылку на гайд в README репозитория и в wiki команды.

Ожидаемый результат этапа Гайд и запись демо, команда знает процесс.

5. Критерии приемки (Definition of Done)

  • Создан и утверждён шаблон postmortem (template.md) с минимум 6 обязательными разделами.
  • Настроен Git-репозиторий для хранения postmortem с CI-линтером.
  • Проведён пилотный postmortem (реальный или симулированный) с участием не менее 3 инженеров.
  • Опубликован хотя бы один postmortem в репозитории.
  • Проведён опрос психологической безопасности, результат >4 из 5.
  • Написана и распространена инструкция по процессу (гайд).
  • Все action items из пилотного postmortem имеют ответственных и сроки.
  • Команда знает, как создать новый postmortem (проверено через quick poll).

6. Ожидаемый результат

Основной артефакт Репозиторий postmortems/ с:

Дополнительные результаты

  • Гайд «Как проводить blameless postmortem» (PDF или wiki-страница).
  • Запись демо-сессии (опционально).
  • Метрика: количество self-reported incidents за месяц после внедрения (можно отследить через тикеты).

7. Возможные сложности и их решение

СложностьРешение
Сопротивление культуре: инженеры боятся, что postmortem используют для наказанияПровести отдельную встречу, объяснить принципы blameless; показать примеры из индустрии (Google, Etsy). Фасилитатор должен пресекать обвинения.
Нет реальных инцидентов для пилотаИспользовать симулированный сценарий (см. Этап 3). Важно, чтобы сценарий был правдоподобным и вызывал обсуждение.
Шаблон слишком сложный или длинныйНачать с минимального набора разделов (Executive Summary, Timeline, Root Cause, Action Items). Упрощать после ретроспективы.
Action items не выполняютсяНазначить ответственного за трекинг (например, тимлида). Использовать автоматическое создание задач в Jira.
Postmortem пишут только после крупных инцидентовВвести правило: postmortem обязателен для всех P0/P1 и рекомендуется для P2. Напоминать в еженедельном дайджесте.

8. Бюджет времени (оценка)

ЭтапВремя
Этап 1: Исследование и дизайн шаблона1.5 часа
Этап 2: Интеграция с инструментами1 час
Этап 3: Пилотный запуск2 часа
Этап 4: Ретроспектива процесса1 час
Этап 5: Документирование и обучение1 час
Итого6.5 часов

Примечание Для первого раза может потребоваться до 8 часов, если команда не знакома с blameless культурой. Рекомендуется выделить отдельный день (например, «Postmortem Day»).

9. Связанные вопросы из базы знаний

ВопросТема
101Что такое blameless postmortem и чем он отличается от традиционного?
102Как определить severity инцидента (P0–P3)?
103Какие метрики использовать для оценки влияния инцидента?
201Как проводить «5 почему» без обвинений?
301Как настроить CI-линтер для markdown-документов?
401Как интегрировать postmortem с PagerDuty/Incident.io?
501Как измерить психологическую безопасность в команде?
601Примеры успешных blameless postmortem из open-source (GitLab, Google).
701Как автоматически создавать action items в Jira из postmortem?
801Как проводить ретроспективу процесса postmortem?

10. Чек-лист самопроверки

  • Я изучил(а) принципы blameless культуры и могу объяснить их коллегам.
  • Я создал(а) шаблон postmortem и получил(а) минимум два ревью от команды.
  • Я настроил(а) CI-линтер и уведомления в Slack.
  • Я провёл(а) пилотный postmortem с симулированным или реальным инцидентом.
  • Я собрал(а) обратную связь и улучшил(а) шаблон/процесс.
  • Я задокументировал(а) процесс и провёл(а) демо для команды.
  • Я убедился(ась), что все action items из пилота имеют ответственных и сроки.