Когда падает прод, ломается интеграция или пользователи теряют доступ, первая реакция команды — найти виноватого. Но такой подход почти всегда вредит: люди начинают скрывать ошибки, а реальные причины инцидента остаются без внимания.
Постмортем без обвинений — это разбор инцидента, цель которого не наказать, а понять, почему система позволила ошибке случиться и как не допустить повторения.
Главный принцип
Ошибка сотрудника — это не финальная причина. Важно смотреть глубже: процессы, мониторинг, тестирование, документация, доступы, автоматизация, коммуникация.
Что дает blameless postmortem
- ✅ снижает страх ошибок в команде
- ✅ помогает быстрее находить корневые причины
- ✅ улучшает процессы, а не только поведение людей
- ✅ повышает надежность сервисов ⚙️
Как правильно разбирать инцидент
- 1. Зафиксируйте факты
Соберите таймлайн: когда началась проблема, какие были симптомы, кто заметил, какие действия предпринимались, когда восстановили сервис.
Без оценок и эмоций — только наблюдаемые события. - 2. Опишите влияние
Ответьте на вопросы:- сколько длился инцидент
- какие сервисы пострадали
- сколько пользователей затронуто
- были ли финансовые или репутационные потери
- 3. Найдите корневые причины
Не останавливайтесь на формулировке «инженер ошибся». Полезнее спрашивать:- почему система допустила ошибочное действие
- почему алерт не сработал вовремя
- почему изменение попало в прод без нужной проверки
- почему не было rollback-сценария
- 4. Разделите причины по слоям
Обычно инцидент — это цепочка факторов:- технические — баг, отказ инфраструктуры, слабый мониторинг
- процессные — нет code review, регламента, чек-листа
- организационные — перегруз команды, размытая ответственность, нехватка знаний 📚
- 5. Сформулируйте action items
Итог постмортема — не документ “для галочки”, а конкретные улучшения:- добавить алерты
- автоматизировать проверки
- обновить runbook
- внедрить feature flags
- пересмотреть процесс релиза 🚀
- владелец
- срок
- ожидаемый результат
Каких формулировок избегать
❌ «Разработчик сломал прод»
❌ «DevOps не уследил»
❌ «Кто-то забыл проверить»
Чем заменить
✅ «Изменение попало в прод без автоматической валидации»
✅ «Система мониторинга не сигнализировала о деградации»
✅ «В процессе релиза отсутствовал обязательный шаг проверки»
Такой язык помогает улучшать систему, а не усиливать токсичность в команде 🤝
Хороший постмортем отвечает на 3 вопроса:
- что произошло
- почему это стало возможным
- что мы изменим, чтобы риск повторения снизился
Сильные IT-команды не те, у кого не бывает инцидентов, а те, кто умеет превращать сбои в улучшения 🔧
Подборку каналов про IT — с практикой, кейсами и полезными наблюдениями — стоит посмотреть ниже.