Постмортемы без обвинений: как превратить инциденты в рост команды

3:47 утра. Суббота. Production лежит уже 4 часа. Команда из 6 человек сидит в Zoom. Глаза красные. В чате клиенты пишут гневные сообщения. Финансовый директор считает убытки: $87,000 и растёт.

9:00 утра. Понедельник. Совещание. CTO с красным лицом: "КТО допустил эту ошибку?!"

Senior молчит. Мидл смотрит в пол. Джун дрожит (это его код). Все молчат. Через неделю — точно такой же инцидент. И снова никто ничего не знает.

Я видел эту сцену много раз на разных проектах. И каждый раз она заканчивается одинаково: команда ничему не учится, инциденты повторяются, люди выгорают.

Альтернатива: Google, Netflix, Amazon. У них production тоже падает. Но они падают реже, восстанавливаются быстрее и не повторяют ошибки. Секрет? Культура постмортемов.

Я 15 лет работаю с инцидентами. Был в командах, где постмортем превращался в witch hunt. И в командах, где он становился лучшим инструментом роста. Разберём, как построить культуру, в которой ошибки делают команду сильнее, а не разрушают её.

Что такое постмортем (и почему 90% компаний делают его неправильно)

Определение, которое работает

Постмортем (Post-Mortem, Incident Review, Retrospective) — это структурированный анализ инцидента с целью:

1. Понять причины (не виноватых, а причины)
2. Предотвратить повторение (action items)
3. Улучшить систему (процессы, мониторинг, автоматизация)
4. Обучить команду (shared knowledge)

Это НЕ:

• ❌ Допрос ("кто виноват?")
• ❌ Формальность ("заполним шаблон для галочки")
• ❌ Наказание ("штраф за ошибку")
• ❌ Обвинение ("ты сломал production")

Это:

• ✅ Обучение (как избежать в будущем)
• ✅ Системное мышление (почему система позволила это)
• ✅ Рост (как стать лучше)
• ✅ Прозрачность (все знают, что произошло)

Почему 90% постмортемов не работают

Типичный сценарий:

1. Инцидент → все в панике
2. Исправление → быстро закрыли
3. Постмортем → кто-то написал документ за 30 минут
4. Документ улетает в Confluence → никто не читает
5. Через месяц → точно такой же инцидент
6. Все удивлены → "мы же писали постмортем!"

Что пошло не так:

• Постмортем написан для галочки, а не для действий
• Нет конкретных action items
• Нет ответственных за исполнение
• Нет follow-up (никто не проверяет, выполнено ли)
• Культура обвинения (люди боятся признавать ошибки)

Статистика Google SRE:

• 60% инцидентов повторяются, если не делать постмортем
• 30% инцидентов повторяются, если постмортем формальный
• 5% инцидентов повторяются, если постмортем с action items и follow-up

Blame-Free Culture: фундамент эффективных постмортемов

Что значит "blame-free" (без обвинений)

Плохой подход (blame culture):

CTO: "Кто задеплоил баг в production?"
Developer: "Я..."
CTO: "Почему не было тестов?!"
Developer: "Не успел, дедлайн..."
CTO: "Это твоя ответственность! В следующий раз штраф."

Результат:
- Разработчик демотивирован
- Команда боится признавать ошибки
- Инциденты скрываются или замалчиваются
- Никто не учится

Правильный подход (blame-free culture):

Tech Lead: "Что позволило багу попасть в production?"
Developer: "У меня не было времени на тесты из-за дедлайна."
Tech Lead: "Почему дедлайн не учитывал время на тесты?"
Product: "Мы не закладывали это в оценку."
Tech Lead: "Action items:
1. Изменить процесс оценки: +20% времени на тесты
2. Внедрить автоматические проверки в CI
3. Сделать staging обязательным перед production"

Результат:
- Системные улучшения
- Команда открыто обсуждает проблемы
- Инциденты не повторяются
- Все учатся

Как внедрить blame-free культуру

1. Начните с топ-менеджмента

Если CTO кричит "кто виноват?" — культуры не будет.

Правило для лидеров:

• Никогда не спрашивайте "кто виноват?"
• Всегда спрашивайте "что в системе позволило это?"
• Публично хвалите за честные постмортемы
• Сами признавайте свои ошибки

Пример от Amazon:

Jeff Bezos внедрил правило: "Ошибка — это данные для улучшения, а не причина для наказания." В Amazon есть внутренняя награда "Just Do It Award" — для команд, которые провели лучшие постмортемы после фейлов.

2. Постмортем для каждого серьезного инцидента

Критерии серьезности (когда нужен постмортем):

• Production downtime > 30 минут
• Потеря данных (любого объема)
• Security инцидент
• Финансовые потери > $1000
• Недовольство клиентов (> 10 обращений)
• Нарушение SLA

Даже если инцидент мелкий, но повторяется — делаем постмортем.

3. Обязательное правило: "Спасибо за честность"

Практика от Etsy:

Когда разработчик признаёт ошибку, первая реакция лидера: "Спасибо, что сказал честно. Давайте разберёмся, как это предотвратить."

НЕ: "Как ты мог?!"

Результат: в Etsy снизилось количество скрытых инцидентов на 70%.

4. Постмортемы для успешных проектов тоже

Не только для фейлов. Постмортем после успешного релиза:

• Что сработало хорошо?
• Что можно улучшить?
• Какие риски мы приняли и оказались правы?

Это показывает: постмортем — не наказание, а инструмент обучения.

Структура эффективного постмортема

Шаблон постмортема (проверенный на 100+ инцидентах)

# Постмортем: [Название инцидента]
 
**Дата инцидента:** 2025-12-15
**Время начала:** 22:47 UTC
**Время восстановления:** 03:15 UTC
**Длительность:** 4 часа 28 минут
**Серьезность:** Critical (P0)
**Автор постмортема:** [Имя]
**Участники:** [Список]
 
---
 
## Executive Summary (краткое резюме)
 
**Что случилось:** [1-2 предложения, понятные даже CEO]
 
Пример: "Production база данных упала из-за исчерпания дискового пространства.
Сервис был недоступен для всех пользователей 4 часа 28 минут."
 
**Impact (влияние):**
 
- Downtime: 4ч 28мин
- Затронуто пользователей: 100,000
- Финансовые потери: ~$87,000
- Репутационные потери: 247 негативных отзывов
 
**Root Cause (основная причина):**
[Одно предложение]
 
Пример: "Логи не ротировались, диск заполнился за 3 дня."
 
**Решение:**
[Что сделали для восстановления]
 
Пример: "Вручную очистили старые логи, перезапустили БД."
 
**Предотвращение повторения:**
[Ключевые action items]
 
Пример:
 
1. Включить автоматическую ротацию логов
2. Настроить алерты на заполнение диска > 80%
3. Добавить runbook для этого сценария
 
---
 
## Timeline (хронология)
 
| Время (UTC) | Событие                                    | Действие                 |
| ----------- | ------------------------------------------ | ------------------------ |
| 22:47       | Monitoring показал ошибки подключения к БД | -                        |
| 22:52       | On-call инженер получил alert              | Начал investigation      |
| 23:15       | Определили: диск заполнен на 100%          | Попытка очистить место   |
| 23:45       | Очистили temporary файлы — не помогло      | Escalation к DBA         |
| 00:30       | DBA определил: проблема в логах приложения | Начали очистку логов     |
| 01:15       | Освободили 50GB, перезапустили БД          | Сервис частично доступен |
| 02:00       | Полное восстановление репликации           | Мониторинг стабилен      |
| 03:15       | Объявили инцидент закрытым                 | Post-incident monitoring |
 
---
 
## Root Cause Analysis (анализ первопричины)
 
### Что произошло (технические детали)
 
[Подробное техническое описание]
 
Пример:
Приложение пишет логи в /var/log/app/application.log
Конфигурация logrotate была отключена после миграции на новый сервер 3 месяца назад
Логи накапливались со скоростью ~20GB/день
Диск на 300GB заполнился за 15 дней
PostgreSQL не смог создать WAL файлы → crash
 
### 5 Whys (метод 5 почему)
 
1. **Почему production упал?**
   - PostgreSQL не смог записать WAL файл (Write-Ahead Log)
 
2. **Почему PostgreSQL не смог записать WAL файл?**
   - На диске не было места (100% заполнено)
 
3. **Почему диск заполнился?**
   - Логи приложения не ротировались и накапливались
 
4. **Почему логи не ротировались?**
   - Конфигурация logrotate была потеряна при миграции сервера
 
5. **Почему потеря конфигурации не была обнаружена?**
   - Нет автоматической проверки критичных конфигов после миграции
   - Нет мониторинга заполнения диска
 
**Root Cause (корневая причина):**
Отсутствие автоматической проверки конфигураций после миграции серверов.
 
### Contributing Factors (способствующие факторы)
 
- Отсутствие алертов на заполнение диска
- Недостаточное тестирование процесса миграции
- Нет runbook для этого сценария
- DBA не был включен в on-call rotation сразу
 
---
 
## What Went Well (что сработало хорошо)
 
- ✅ On-call инженер ответил за 5 минут (SLA: 15 минут)
- ✅ Escalation к DBA был своевременным
- ✅ Команда работала синхронно в Slack
- ✅ Коммуникация с клиентами через status page была четкой
- ✅ Rollback plan был готов (хотя не понадобился)
 
---
 
## What Went Wrong (что пошло не так)
 
- ❌ Monitoring не покрывал дисковое пространство
- ❌ Нет автоматической проверки конфигов после миграции
- ❌ Логи не ротировались 3 месяца — никто не заметил
- ❌ DBA был привлечен через 1 час (должен быть сразу)
- ❌ Нет runbook для "disk full" сценария
 
---
 
## Action Items (план действий)
 
### Prevent (предотвратить повторение)
 
| #   | Action Item                                     | Owner   | Deadline   | Status         |
| --- | ----------------------------------------------- | ------- | ---------- | -------------- |
| 1   | Включить logrotate на всех серверах             | DevOps  | 2025-12-20 | ✅ Done        |
| 2   | Настроить алерт: disk usage > 80%               | SRE     | 2025-12-21 | ✅ Done        |
| 3   | Автоматическая проверка конфигов после миграции | DevOps  | 2025-12-30 | 🔄 In Progress |
| 4   | Добавить DBA в primary on-call rotation         | Manager | 2025-12-22 | ✅ Done        |
 
### Detect (улучшить обнаружение)
 
| #   | Action Item                                      | Owner     | Deadline   | Status         |
| --- | ------------------------------------------------ | --------- | ---------- | -------------- |
| 5   | Dashboard для мониторинга дискового пространства | SRE       | 2025-12-25 | 🔄 In Progress |
| 6   | Weekly review логов мониторинга                  | Tech Lead | Постоянно  | ✅ Done        |
| 7   | Алерт на аномальный рост логов (> 10GB/день)     | SRE       | 2025-12-28 | 📅 Planned     |
 
### Mitigate (ускорить восстановление)
 
| #   | Action Item                                | Owner  | Deadline   | Status     |
| --- | ------------------------------------------ | ------ | ---------- | ---------- |
| 8   | Runbook: "Disk Full Recovery"              | SRE    | 2025-12-23 | ✅ Done    |
| 9   | Автоматический скрипт очистки старых логов | DevOps | 2026-01-10 | 📅 Planned |
| 10  | Симуляция "disk full" на staging           | SRE    | 2026-01-15 | 📅 Planned |
 
### Learn (обучение команды)
 
| #   | Action Item                                         | Owner     | Deadline   | Status         |
| --- | --------------------------------------------------- | --------- | ---------- | -------------- |
| 11  | Воркшоп: "Disk Management Best Practices"           | DBA       | 2025-12-27 | 🔄 In Progress |
| 12  | Обновить onboarding: добавить раздел про мониторинг | Tech Lead | 2026-01-05 | 📅 Planned     |
 
---
 
## Lessons Learned (уроки)
 
1. **Мониторинг должен покрывать базовые метрики инфраструктуры** (CPU, RAM, Disk, Network)
2. **Критичные конфигурации должны быть под version control** (Infrastructure as Code)
3. **Runbooks экономят часы при инцидентах** (наш runbook сэкономил бы 2 часа)
4. **Тестируйте миграции на staging с полным набором проверок**
5. **On-call rotation должен включать экспертов для каждого компонента**
 
---
 
## References (ссылки)
 
- [Incident Slack Thread](https://company.slack.com/archives/incidents/p1734307620)
- [Monitoring Dashboard](https://grafana.company.com/d/incident-2025-12-15)
- [Database Logs](https://logs.company.com/query?incident=2025-12-15)
- [Status Page Updates](https://status.company.com/incidents/2025-12-15)
 
---
 
## Sign-off (подписи)
 
**Reviewed by:**
 
- [ ] Tech Lead
- [ ] SRE Lead
- [ ] DevOps Lead
- [ ] Engineering Manager
 
**Approved by:**
 
- [ ] CTO
 
**Post-Mortem Meeting:**
 
- Date: 2025-12-18
- Attendees: [Список]
- Recording: [Ссылка]

Процесс проведения постмортема

Фаза 1: Сбор данных (сразу после инцидента)

Сразу после восстановления сервиса:

1. Создайте постмортем документ (пока память свежа)
2. Соберите timeline из логов, Slack, мониторинга
3. Сохраните все артефакты:
   • Логи (до удаления)
   • Скриншоты dashboards
   • Slack threads
   • Git commits, связанные с инцидентом

Инструменты:

# Экспорт логов за период инцидента
kubectl logs deployment/api --since=6h > incident-logs.txt
 
# Скриншоты Grafana dashboards
# (сделайте вручную или через Grafana API)
 
# Экспорт Slack thread
# (используйте Slack Export или скриншоты)

Фаза 2: Подготовка к встрече (24-48 часов после инцидента)

Кто пишет постмортем:

• Лучший вариант: человек, который тушил пожар
• Альтернатива: Tech Lead или SRE, который участвовал
• НЕ: человек, который "виноват" (это создаст bias)

Что подготовить:

• Черновик постмортема по шаблону выше
• Timeline с данными из логов
• Список участников для встречи
• Вопросы для обсуждения

Фаза 3: Встреча (постмортем meeting)

Длительность: 60-90 минут

Участники:

• Все, кто участвовал в инциденте
• Tech Lead / Engineering Manager
• Представитель продакта (для контекста бизнес-impact)
• SRE / DevOps (для инфраструктурных вопросов)
• Опционально: CEO/CTO (для критичных инцидентов)

Повестка:

1. 0-10 мин: Executive Summary (что случилось, impact)
2. 10-30 мин: Timeline walkthrough (хронология событий)
3. 30-50 мин: Root Cause Analysis (5 Whys, диаграммы)
4. 50-70 мин: Action Items brainstorming (что делать)
5. 70-80 мин: Приоритизация action items
6. 80-90 мин: Назначение ответственных и дедлайнов

Правила встречи:

Фразы, которые нужно блокировать:

• ❌ "Это твоя вина"
• ❌ "Ты должен был проверить"
• ❌ "Как ты мог такое допустить?"

Фразы, которые нужно поощрять:

• ✅ "Что в процессе review позволило пропустить это?"
• ✅ "Почему у нас не было автоматической проверки?"
• ✅ "Как мы можем улучшить систему?"

Фаза 4: Финализация документа (в течение недели)

Кто:

• Автор постмортема обновляет документ по итогам встречи
• Добавляет все action items с owners и deadlines
• Отправляет на ревью всем участникам

Ревью:

• Tech Lead
• Engineering Manager
• SRE Lead
• CTO (для критичных инцидентов)

Публикация:

• Внутренняя wiki (Confluence, Notion, GitHub)
• Рассылка всей инженерной команде
• Для критичных: рассылка всей компании

Опционально (для продвинутых команд):

• Публичный постмортем (как у Google, AWS)
• Презентация на All-Hands meeting
• Запись в блог компании

Фаза 5: Follow-up (критично!)

Без follow-up постмортем бесполезен.

Процесс:

1. Еженедельный review action items (на команде или в Jira)
2. Статус-трекинг:
   • ✅ Done
   • 🔄 In Progress
   • 📅 Planned
   • 🚫 Blocked (с причиной)
3. Escalation: если action item блокируется > 2 недель → escalate к менеджеру

Метрики:

• % завершенных action items: должно быть > 80% через месяц
• Время закрытия action items: средний — 2-3 недели
• Повторение инцидента: 0 (если все action items выполнены)

Лучшие практики из Google SRE, Netflix, Amazon

1. Blameless Post-Mortem (Google)

Правило: Даже если человек явно ошибся, мы спрашиваем "почему система это позволила?"

Пример:

Разработчик случайно удалил production database командой:
rm -rf /data/postgres

Плохой постмортем:
"Разработчик выполнил опасную команду. Необходимо обучить команду."

Хороший постмортем:
"Система позволила выполнить rm -rf на production сервере.

Action items:
1. Разграничить SSH доступ: production только для SRE
2. Обязательная проверка при опасных командах (rm, drop, truncate)
3. Автоматические бэкапы каждые 6 часов
4. Immutable infrastructure: удаление сервера через Infrastructure as Code"

2. Chaos Engineering (Netflix)

После постмортема: проводим симуляцию инцидента на staging/production.

Зачем:

• Проверить, что action items реально работают
• Обучить команду работе с этим сценарием
• Найти новые проблемы до того, как они станут инцидентом

Пример:

# Симуляция "disk full"
# На staging сервере
dd if=/dev/zero of=/var/log/fill bs=1M count=10000
 
# Проверяем:
# 1. Сработал ли алерт?
# 2. Пришло ли уведомление on-call?
# 3. Сработала ли автоматическая очистка?
# 4. Есть ли runbook? Понятен ли он?

3. Public Post-Mortems (AWS, GitHub, GitLab)

Публикуйте постмортемы для клиентов.

Зачем:

• Прозрачность
• Доверие клиентов
• Ответственность перед бизнесом
• PR (хорошие постмортемы привлекают клиентов)

Пример публичных постмортемов:

• AWS S3 Outage 2017
• GitHub Outage 2018
• GitLab Database Incident 2017

Структура публичного постмортема:

• Краткое описание (что, когда, как долго)
• Impact (сколько пользователей)
• Root cause (упрощённо, без технических деталей)
• Что мы делаем, чтобы предотвратить

НЕ включаем:

• Имена людей
• Внутренние процессы
• Технические детали (которые могут быть использованы для атак)

4. Incident Severity Levels (Amazon)

Классификация инцидентов:

Почему важно:

• Приоритизация усилий
• Понятно, когда нужен постмортем
• Escalation процесс

5. Incident Commander Role (Netflix, PagerDuty)

Назначаем Incident Commander для каждого P0/P1 инцидента.

Роль Incident Commander:

• Координирует действия команды
• Принимает решения (rollback, escalation)
• Ведёт коммуникацию с бизнесом/клиентами
• Документирует timeline

НЕ Incident Commander:

• Не обязательно самый старший
• Не обязательно тот, кто чинит
• Это роль, не должность

Пример:

22:47 - Инцидент
22:50 - Назначен Incident Commander: Alice (SRE)
22:52 - Alice создаёт Slack канал #incident-2025-12-15
22:55 - Alice назначает роли:
  - Bob (Backend) - investigation
  - Charlie (DBA) - database recovery
  - David (DevOps) - infrastructure check
23:00 - Alice обновляет status page: "Investigating"
23:30 - Alice escalates к CTO (инцидент > 30 мин)

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

1. Action Items Tracking (самое важное)

Без трекинга action items постмортем бесполезен.

Инструменты:

• Jira/Linear: создаём задачи с label "postmortem"
• Notion/Confluence: таблица с статусами
• GitHub Issues: для open-source проектов

Пример Jira workflow:

[POSTMORTEM-123] Включить logrotate на всех серверах

Priority: Critical
Assignee: DevOps Team
Labels: postmortem, incident-2025-12-15
Due Date: 2025-12-20

Acceptance Criteria:
- [ ] Logrotate настроен на prod-01...prod-10
- [ ] Конфиг добавлен в Ansible playbook
- [ ] Проверено на staging
- [ ] Документация обновлена

Review процесс:

• Еженедельный sync: ревью всех открытых postmortem задач
• Monthly report: % завершенных action items
• Escalation: если задача не движется > 2 недель

2. Incident Database (база знаний)

Создайте централизованное хранилище всех постмортемов.

Структура:

/postmortems
  /2025
    /12-december
      /2025-12-15-disk-full.md
      /2025-12-10-api-timeout.md
  /2024
  /tags
    /database
    /performance
    /security

Метаданные для каждого постмортема:

---
incident_id: INC-2025-12-15
date: 2025-12-15
severity: P0
duration: 4h 28min
root_cause: Disk full
tags: [database, infrastructure, monitoring]
affected_services: [api, web, mobile]
financial_impact: $87,000
---

Зачем:

• Поиск по похожим инцидентам
• Анализ трендов (что ломается чаще всего)
• Onboarding новых членов команды

3. Trend Analysis (анализ трендов)

Каждый квартал: анализируем все постмортемы.

Вопросы:

• Какие инциденты повторяются?
• Какие системы/сервисы ломаются чаще всего?
• Какие root causes встречаются регулярно?
• Сколько action items выполнено?

Метрики:

Q4 2025 Incident Trends

Total incidents: 23
  - P0: 3 (13%)
  - P1: 8 (35%)
  - P2: 12 (52%)

Top Root Causes:
  1. Configuration errors: 8 (35%)
  2. Insufficient monitoring: 6 (26%)
  3. Deployment issues: 5 (22%)
  4. External dependencies: 4 (17%)

Most Affected Services:
  1. API Gateway: 9 incidents
  2. Database: 6 incidents
  3. Auth Service: 5 incidents

Action Items:
  - Total created: 87
  - Completed: 65 (75%)
  - In Progress: 15 (17%)
  - Blocked: 7 (8%)

Выводы:

• 35% инцидентов из-за конфигурации → нужно Infrastructure as Code
• 26% из-за плохого мониторинга → расширить coverage
• API Gateway часто падает → приоритетный кандидат на рефакторинг

4. Learning Sessions (обучение команды)

Раз в квартал: воркшоп по постмортемам.

Формат:

• 1 час
• Презентация топ-3 самых интересных инцидентов
• Обсуждение уроков
• Q&A

Пример повестки:

Q4 2025 Incident Learning Session

1. Инцидент: "Disk Full on Production DB"
   - Presenter: Alice (SRE)
   - Duration: 20 min
   - Key learnings: Monitoring, Automation, Runbooks

2. Инцидент: "API Timeout due to N+1 Query"
   - Presenter: Bob (Backend)
   - Duration: 15 min
   - Key learnings: Performance testing, Query optimization

3. Инцидент: "Security: Exposed S3 Bucket"
   - Presenter: Charlie (Security)
   - Duration: 15 min
   - Key learnings: IAM policies, Access control

4. Q&A: 10 min

Результат:

• Команда учится на ошибках других
• Культура открытости (не стыдно ошибаться)
• Cross-team knowledge sharing

5. Runbooks (процедуры восстановления)

Для каждого типичного инцидента создаём runbook.

Пример runbook: "Disk Full Recovery"

# Runbook: Disk Full Recovery
 
## Symptoms (признаки)
 
- Alert: "Disk usage > 95%"
- Database errors: "No space left on device"
- Application crashes
 
## Immediate Actions (первые действия)
 
1. Check current disk usage:
   ```bash
   df -h
   du -sh /var/log/* | sort -h
   ```

2. Identify large files:

   find / -type f -size +1G 2>/dev/null

3. Quick cleanup (if safe):

   # Clean old logs (> 7 days)
   find /var/log -name "*.log" -mtime +7 -delete
    
   # Clean temp files
   rm -rf /tmp/*

Investigation (расследование)

• Check logrotate status: systemctl status logrotate
• Check application log settings
• Review recent changes (deployments, configs)

Resolution (решение)

1. Enable logrotate:

   systemctl enable logrotate
   systemctl start logrotate

2. Configure log retention (7 days):

   /etc/logrotate.d/application
   

3. Restart affected services

Verification (проверка)

• Disk usage < 80%
• Application responsive
• Monitoring shows stable metrics

Post-Incident

• Create postmortem if not already exists
• Update this runbook if needed

**Где хранить runbooks:**

- Confluence / Notion
- GitHub repository
- PagerDuty (integration)

**Важно:** runbooks должны быть **доступны во время инцидента** (не только в production, который упал).

---

## Типичные ошибки при постмортемах

### Ошибка #1: Формальный подход

**Проблема:** Постмортем написан для галочки, никто не читает.

**Признаки:**

- Документ в Confluence с 0 просмотров
- Action items без owners
- Нет follow-up
- Шаблонные фразы ("надо быть внимательнее")

**Решение:**

- Обязательная встреча с командой
- Review всех action items на weekly sync
- Публикация результатов для всей компании

### Ошибка #2: Поиск виноватого

**Проблема:** Фокус на "кто виноват", а не "почему произошло".

**Признаки:**

- Вопросы "кто сделал?", "почему не проверил?"
- Атмосфера допроса на встрече
- Люди боятся признавать ошибки

**Решение:**

- Обучить менеджмент blame-free культуре
- Модератор на встрече блокирует обвинения
- Фокус на системных улучшениях

### Ошибка #3: Слишком много action items

**Проблема:** 30+ action items → ничего не сделано.

**Признаки:**

- Action items растут как снежный ком
- Нет приоритизации
- Всё просрочено

**Решение:**

- **Правило:** максимум 5-7 action items на постмортем
- Приоритизация по impact
- Остальное → в backlog как "nice to have"

<Callout type="warning">
  **Правило Парето для постмортемов:** 20% action items дадут 80% улучшений.
  Фокусируйтесь на критичном, остальное можно отложить.
</Callout>

### Ошибка #4: Нет метрик эффективности

**Проблема:** Не измеряем, работают ли постмортемы.

**Признаки:**

- Не знаем, сколько инцидентов повторяется
- Не знаем, сколько action items закрыто
- Нет visibility для менеджмента

**Решение:**

Измеряйте:

- **MTTR (Mean Time To Recovery):** среднее время восстановления
- **Incident Frequency:** количество инцидентов в месяц
- **Repeat Rate:** % повторяющихся инцидентов
- **Action Item Completion Rate:** % выполненных action items

### Ошибка #5: Постмортем через месяц

**Проблема:** Пишем постмортем через месяц после инцидента.

**Признаки:**

- Детали забыты
- Timeline неточный
- Логи удалены

**Решение:**

- **Deadline:** постмортем через 24-48 часов для P0/P1
- Сохраняйте артефакты сразу (логи, скриншоты)
- Черновик timeline пишите во время инцидента

---

## Метрики эффективности постмортемов

### 1. **MTTR (Mean Time To Recovery)**

**Что измеряет:** Среднее время от начала инцидента до полного восстановления.

**Формула:**

MTTR = Σ(Время восстановления) / Количество инцидентов

**Пример:**

Q4 2025:

• Incident 1: 4h 28min
• Incident 2: 1h 15min
• Incident 3: 35min

MTTR = (268 + 75 + 35) / 3 = 126 минут (2h 6min)

**Цель:** MTTR должен снижаться со временем.

**Почему:**

- Лучше runbooks → быстрее восстановление
- Лучше мониторинг → раньше обнаружение
- Опыт команды → эффективнее действия

### 2. **Incident Frequency (частота инцидентов)**

**Что измеряет:** Количество инцидентов за период.

**Метрика:**

Incidents per Month = Total Incidents / Months

**Тренд:**

Q3 2025: 12 incidents/month Q4 2025: 8 incidents/month ✅ (улучшение на 33%)

**Цель:** Снижение со временем (если постмортемы работают).

### 3. **Repeat Rate (% повторяющихся инцидентов)**

**Что измеряет:** Сколько инцидентов повторяется.

**Формула:**

Repeat Rate = (Повторяющиеся инциденты / Всего инцидентов) × 100%

**Пример:**

Q4 2025:

• Total incidents: 23
• Repeat incidents: 3 (disk full x2, API timeout x1)
• Repeat Rate: 3/23 = 13%

**Бенчмарки:**

- **< 10%:** Excellent (постмортемы работают)
- **10-20%:** Good
- **20-40%:** Poor (action items не выполняются)
- **> 40%:** Critical (культура постмортемов не работает)

### 4. **Action Item Completion Rate**

**Что измеряет:** % завершенных action items из постмортемов.

**Формула:**

Completion Rate = (Завершенные / Всего созданных) × 100%

**Пример:**

Q4 2025:

• Total action items created: 87
• Completed: 65
• In Progress: 15
• Blocked: 7

Completion Rate: 65/87 = 75%

**Бенчмарки:**

- **> 80%:** Excellent
- **60-80%:** Good
- **40-60%:** Poor
- **< 40%:** Critical (нет follow-up процесса)

### 5. **Time to Postmortem (скорость создания постмортема)**

**Что измеряет:** Сколько времени прошло от инцидента до публикации постмортема.

**Формула:**

Time to Postmortem = Дата публикации - Дата инцидента

**Бенчмарки:**

- **< 24 часа:** Excellent
- **24-48 часов:** Good
- **3-7 дней:** Acceptable
- **> 1 недели:** Poor (детали забываются)

---

## Инструменты для постмортемов

### 1. **Incident Management платформы**

#### PagerDuty

**Фичи:**

- Автоматические алерты
- On-call rotation
- Incident timeline (автоматически)
- Интеграция с Slack, Jira
- Постмортем templates

**Цена:** от $21/user/month

**Плюсы:**

- All-in-one решение
- Отличная интеграция с мониторингом

**Минусы:**

- Дорого для маленьких команд

#### Opsgenie (Atlassian)

**Фичи:**

- Аналогично PagerDuty
- Глубокая интеграция с Jira

**Цена:** от $9/user/month

### 2. **Документация и шаблоны**

#### Confluence / Notion

**Плюсы:**

- Знакомый инструмент
- Шаблоны постмортемов
- Поиск и таги

**Шаблон для Notion:**

```markdown
# Incident Post-Mortem Template

## Incident Details
- **ID:**
- **Date:**
- **Severity:**
- **Duration:**

## Executive Summary
[Brief description]

## Timeline
| Time | Event | Action |
|------|-------|--------|
|      |       |        |

## Root Cause
[5 Whys analysis]

## Action Items
- [ ] Item 1 (@owner, deadline)
- [ ] Item 2 (@owner, deadline)

GitHub / GitLab

Для tech-команд:

• Постмортемы как markdown файлы в репозитории
• Pull requests для ревью
• Issues для action items

Структура:

/postmortems
  /2025
    /Q4
      incident-2025-12-15-disk-full.md

3. Monitoring и логирование

Grafana / Prometheus

Для timeline:

• Экспорт графиков за период инцидента
• Аннотации на графиках (deploy, incidents)

Пример запроса:

# CPU usage во время инцидента
rate(cpu_usage[5m])
  and on() timestamp() > 1734307620
  and on() timestamp() < 1734323700

ELK Stack / Datadog

Для логов:

• Фильтрация по timestamp инцидента
• Экспорт логов для постмортема
• Визуализация ошибок

4. Incident Response Tools

Incident.io

Специализированный инструмент для incident management.

Фичи:

• Автоматическое создание Slack канала для инцидента
• Timeline автоматически из Slack
• Шаблоны постмортемов
• Follow-up на action items

Цена: от $1200/month

Подходит для: компаний с > 50 инженеров

FireHydrant

Аналог Incident.io.

Фичи:

• Incident Commander rotation
• Runbook management
• Retrospective facilitation

Кейсы: реальные постмортемы

Кейс #1: AWS S3 Outage (2017)

Что случилось:

• Инженер выполнил команду для остановки нескольких серверов
• Опечатка в команде → остановил ВСЕ серверы S3 в регионе US-East-1
• Downtime: 4 часа

Impact:

• Тысячи сайтов недоступны
• Финансовые потери: миллионы долларов
• Репутационный урон

Root Cause:

• Команда позволяла удалить слишком много серверов одновременно
• Нет защиты от human error

Action Items:

1. Изменили tooling: нельзя удалить больше определенного количества серверов
2. Добавили подтверждение для критичных операций
3. Улучшили процесс восстановления (теперь быстрее)

Публичный постмортем: https://aws.amazon.com/message/41926/

Урок: Даже в AWS ошибаются. Важно не скрывать, а учиться.

Кейс #2: GitLab Database Deletion (2017)

Что случилось:

• Администратор удалил production database вместо staging
• Backups не работали (обнаружили во время восстановления)
• Потеряли 6 часов данных

Impact:

• Downtime: 18 часов
• Потеря данных: 300GB

Root Cause:

• Отсутствие разграничения доступов
• Backups не тестировались
• Нет процедуры восстановления

Action Items:

1. Внедрили процесс регулярного тестирования backups
2. Разграничили доступ к production
3. Автоматизировали backup verification

Публичный постмортем: https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/

Урок: GitLab открыто опубликовал постмортем → клиенты оценили честность → доверие выросло.

Кейс #3: Knight Capital ($440M за 45 минут)

Что случилось:

• Trading software bug
• За 45 минут потеряли $440 миллионов
• Компания обанкротилась

Root Cause:

• Деплой в production без тестирования
• Старый код реактивировался из-за ошибки конфигурации
• Нет автоматического stop-loss

Lessons:

• Testing на production-like environment обязателен
• Автоматические safety checks критичны
• Incident response plan должен быть

Урок: Постмортем не был проведен (компания обанкротилась). Это урок всем: без постмортемов бизнес может умереть.

Внедрение культуры постмортемов: пошаговый план

Шаг 1: Получить buy-in от менеджмента (1 неделя)

Зачем: Без поддержки топ-менеджмента культура не приживётся.

Действия:

1. Презентация для CTO/CEO:

   • Статистика: Google, Netflix снижают инциденты на 60% с постмортемами
   • ROI: меньше инцидентов = меньше потерь
   • Публичные постмортемы = доверие клиентов

2. Pilot: выберите 1 недавний инцидент, сделайте постмортем по всем правилам

   • Покажите результаты
   • Покажите action items
   • Через месяц покажите, что инцидент не повторился

3. Получите одобрение:

   • Бюджет на инструменты (если нужны)
   • Время команды на постмортемы (это часть работы)

Шаг 2: Создать шаблон и процесс (1 неделя)

Действия:

1. Адаптируйте шаблон из этой статьи под свою компанию

2. Создайте страницу в Wiki:

   • Шаблон постмортема
   • Процесс проведения
   • FAQ

3. Назначьте Postmortem Owner:

   • Человек, который следит за процессом
   • Обычно: SRE Lead или Engineering Manager

Шаг 3: Обучить команду (2 недели)

Действия:

1. Воркшоп: "Blame-Free Postmortem Culture"

   • 1-2 часа
   • Объясните принципы
   • Разберите пример постмортема
   • Проведите mock postmortem встречу

2. Документация:

   • Руководство: "Как написать постмортем"
   • Руководство: "Как провести постmortem meeting"
   • Примеры хороших постмортемов

3. Назначьте ментора:

   • Кто-то опытный помогает первые 3 постмортема

Шаг 4: Первые постмортемы (1 месяц)

Действия:

1. Для первых 3 инцидентов:

   • Детальные постмортемы
   • Встречи с командой
   • Пример для остальных

2. Соберите feedback:

   • Что сложно?
   • Что непонятно?
   • Как улучшить процесс?

3. Итерируйте шаблон и процесс

Шаг 5: Автоматизация и масштабирование (3 месяца)

Действия:

1. Внедрите инструменты:

   • PagerDuty / Opsgenie для incident management
   • Jira для action items
   • Confluence для постмортемов

2. Автоматизируйте:

   • Автоматическое создание постмортема из incident
   • Timeline из логов и мониторинга
   • Напоминания о follow-up

3. Метрики:

   • Dashboard с MTTR, Incident Frequency, Repeat Rate
   • Monthly report для менеджмента

Шаг 6: Культурное укоренение (6-12 месяцев)

Действия:

1. Регулярные Learning Sessions (раз в квартал)
2. Public Postmortems (для клиентов)
3. Награды за лучшие постмортемы
4. Включите постмортемы в onboarding новых сотрудников

Чек-лист: Эффективный постмортем

✅ Перед написанием постмортема:

• Сервис полностью восстановлен
• Собраны все артефакты (логи, скриншоты, Slack threads)
• Определён автор постмортема (не тот, кто "виноват")
• Назначена дата meeting (24-48 часов после инцидента)

✅ В постмортеме должно быть:

• Executive Summary (понятно CEO)
• Timeline (точный, с timestamps)
• Root Cause Analysis (5 Whys или аналог)
• Что сработало хорошо
• Что пошло не так
• Action Items (конкретные, с owners и deadlines)
• Lessons Learned

✅ Встреча (postmortem meeting):

• Участвуют все, кто был в инциденте
• Модератор блокирует обвинения
• Обсуждение фокусируется на системных причинах
• Action items приоритизированы
• Назначены ответственные и дедлайны

✅ После постмортема:

• Документ опубликован в Wiki
• Рассылка всей инженерной команде
• Action items добавлены в Jira
• Еженедельный review action items
• Follow-up через месяц: всё ли выполнено?

✅ Культура:

• Постмортемы без обвинений (blame-free)
• Публичные постмортемы для клиентов (опционально)
• Learning sessions раз в квартал
• Метрики: MTTR, Frequency, Repeat Rate
• Награды за лучшие постмортемы

Главная мысль

Постмортем — это не вскрытие. Это вакцина.

Инциденты будут всегда. Никакая система не идеальна. Разница между зрелой командой и незрелой:

• Незрелая: повторяет одни и те же ошибки, обвиняет людей, скрывает проблемы
• Зрелая: учится на ошибках, улучшает систему, открыто делится знаниями

Постмортемы превращают инциденты из катастрофы в возможность роста.

Ключевые принципы:

1. Blame-free: не "кто виноват", а "почему система позволила"
2. Action items: конкретные задачи с owners и deadlines
3. Follow-up: без исполнения постмортем бесполезен
4. Transparency: открытость внутри команды и перед клиентами
5. Learning: постмортемы как инструмент обучения

Помните:

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

Что делать прямо сейчас

Если у вас ещё нет культуры постмортемов:

1. Возьмите последний инцидент (или следующий)
2. Используйте шаблон из этой статьи
3. Проведите встречу с командой (60 минут)
4. Создайте 3-5 action items с owners
5. Review через неделю: выполнено ли?

Если у вас уже есть постмортемы:

1. Проверьте последние 3 постмортема:
   • Есть ли конкретные action items?
   • Назначены ли owners?
   • Выполнены ли они?
2. Измерьте метрики:
   • MTTR
   • Repeat Rate
   • Action Item Completion Rate
3. Если > 20% инцидентов повторяются → проблема в follow-up

Если вы Tech Lead / Manager:

1. Внедрите правило: каждый P0/P1 инцидент = обязательный постмортем
2. Обучите команду blame-free подходу
3. Еженедельный review action items из постмортемов
4. Квартальная презентация: топ инциденты и уроки

Если вы разработчик:

1. Предложите менеджеру ввести постмортемы
2. Используйте шаблон из статьи для следующего инцидента
3. Будьте примером: честно признавайте ошибки, делитесь уроками

Полезные ресурсы

Книги:

• "Site Reliability Engineering" (Google) — классика, целая глава про постмортемы
• "The DevOps Handbook" — культура и процессы
• "Accelerate" — метрики эффективности DevOps команд

Статьи:

• Google SRE: Postmortem Culture
• Atlassian: Incident Postmortem Template
• PagerDuty: Postmortem Guide

Примеры публичных постмортемов:

• AWS Outages
• GitHub Incidents
• GitLab Incidents

Инструменты:

• PagerDuty — incident management
• Opsgenie — incident management
• Incident.io — специализированный инструмент
• Postmortem Templates (GitHub) — коллекция шаблонов

Делитесь опытом

Я собираю примеры постмортемов и лучшие практики. Если у вас есть интересный кейс — поделитесь:

• Самый сложный инцидент в вашей карьере?
• Как постмортемы помогли (или не помогли) вашей команде?
• Какие метрики вы используете для оценки эффективности?

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

Нужна помощь с внедрением культуры постмортемов? Напишите мне — проведу воркшоп для вашей команды, помогу настроить процессы, подберу инструменты. Первая консультация бесплатно.

Понравилась статья? Поделитесь с коллегой, который говорит "зачем нам эти постмортемы" или "у нас нет времени на документацию". Это может спасти его проект от повторяющихся инцидентов.

Подписывайтесь на обновления в Telegram — пишу про DevOps, SRE, incident management и культуру разработки. Только практика, без воды.