Ситуация: в пятницу вечером падает payment service, error rate > 5%, 12 000 пользователей не могут завершить оплату. Команда тушит пожар 47 минут. Причина — connection pool исчерпан, потому что при деплое увеличили число воркеров, но забыли обновить конфиг pgBouncer. Через месяц — тот же симптом. Эта ситуация знакома многим SRE-инженерам. Без рабочего post-mortem процесса инциденты повторяются в 60% случаев. Мы помогаем внедрить blameless post-mortem культуру, чтобы такие ошибки не повторялись.
Key principle: blameless post-mortem culture — не про поиск виновных, а про улучшение системы. Наш опыт: без post-mortem инциденты повторяются в 60% случаев; с post-mortem — менее 20%. Время на расследование сокращается на 30–50%. Снижение SEV1 достигает 60% за полгода.
Почему важен blameless post-mortem?
Blameless — не про поиск виноватых. Если инженер допустил ошибку, причина — в системе, которая позволила эту ошибку совершить без защитных механизмов. Правильный подход — спросить, почему система позволила ошибке произойти, а не кто нажал не ту кнопку. Культура blame приводит к сокрытию инцидентов и нежеланию признавать ошибки — это хуже самого инцидента. Мы предлагаем готовый шаблон и процесс, который встраивается в вашу incident management систему.
Когда и как проводить post-mortem
Определение инцидентов для разбора
- SEV1 инциденты — всегда, в течение 48 часов
- SEV2 инциденты — всегда, в течение 72 часов
- SEV3 — по решению команды, если инцидент выявил системную проблему
- Повторяющиеся SEV4 — стоит провести, если один и тот же симптом третий раз
Структура post-mortem документа
Каждый документ содержит хронологию, корневую причину, что пошло не так, что сработало хорошо, и action items. Пример хронологии:
| Время | Событие |
|---|---|
| 14:23 | PagerDuty алерт: error rate > 5% на payment service |
| 14:28 | Инженер принял алерт, начал расследование |
| 14:35 | Обнаружено: БД не принимает новые подключения |
| 14:42 | Выявлена причина: connection pool исчерпан |
| 14:55 | Применено временное решение: restart connection pool manager |
| 15:10 | Сервис восстановлен, ошибки ушли |
Ход встречи
Участники: все, кто участвовал в ответе на инцидент + технический лид + при необходимости product owner. Длительность: 60-90 минут. Этапы: обзор хронологии (10 мин), анализ корневых причин (20-30 мин) с помощью техники 5 Why, обсуждение улучшений (15 мин), что сработало хорошо (5 мин), формирование action items (15 мин) с ответственными и сроками.
Техника 5 Why
Пример: Connection pool исчерпан → почему? число соединений превысило max_client_conn → почему? число воркеров увеличилось при деплое → почему? нет процесса проверки DB-конфига при изменении масштаба → почему? deployment checklist не охватывает зависимости конфигов. Корневая причина: отсутствие процесса проверки конфигурационных зависимостей при деплое.
Категории причин
Документы хранятся с тегами: severity, service, cause-category. Основные категории: Configuration, Deployment, Dependency failure, Capacity, Human error. Ежеквартальный обзор помогает направить инвестиции в надёжность.
Какие результаты дает внедрение?
Сравнение без post-mortem и с post-mortem:
| Критерий | Без post-mortem | С post-mortem |
|---|---|---|
| Повторяемость инцидентов | Высокая (60% повторяются) | Низкая (менее 20%) |
| Время на расследование | Большое (нет шаблона) | Сокращается на 30–50% |
| Ответственность за исправление | Размыта | Закреплена за конкретными людьми |
| Культура команды | Страх и сокрытие | Прозрачность и доверие |
Снижение частоты SEV1 на 60% экономит до $60,000 в год для команды из 10 человек (средний SEV1 инцидент стоит $10,000). Сокращение времени расследования на 30–50% экономит 10+ человеко-часов в неделю.
Как гарантировать выполнение action items?
Post-mortem бесполезен, если action items никто не выполняет. Обязательные условия:
- Конкретный ответственный (не «команда», а имя)
- Чёткий срок
- Тикет в Jira/Linear создаётся сразу на встрече
- Обзор выполнения на следующей post-mortem встрече
Для аналитики используйте дашборд с категориями причин, чтобы выявить системные проблемы. Настройка интеграции с PagerDuty помогает автоматизировать сбор метрик.
Процесс внедрения post-mortem
- Аудит текущего процесса управления инцидентами и выявление зон роста
- Разработка шаблона post-mortem под вашу инфраструктуру и стек
- Обучение команды: workshop по blameless культуре и технике 5 Why
- Пилотный post-mortem на реальном инциденте с наставничеством
- Интеграция с тикет-системой (Jira/Linear) и настройка автоматического сбора метрик
- Ежеквартальный обзор результатов и корректировка процесса
Что входит в работу
- Готовый шаблон post-mortem документа в Confluence/Notion
- Обучение команды (до 2 часов)
- Интеграция с Jira/Linear: автоматическое создание action items
- Настройка дашборда для аналитики причин
- Поддержка в течение месяца после внедрения
Сроки ориентировочно
- Базовое внедрение: от 3 до 5 дней
- Полный цикл с обучением и настройкой: от 5 до 10 дней
Стоимость рассчитывается индивидуально. Чтобы получить консультацию и точную оценку, свяжитесь с нами. Закажите пилотный проект — мы проведём анализ одного инцидента и покажем результат.