Postmortem
Тема дорожной карты · Observability
Постмортем (также называемый постинцидентным разбором или бесплатной ретроспективой) — это структурированный анализ, проводимый после инцидента для понимания того, что произошло, почему это произошло и как предотвратить повторение. «Бесплатный» постмортем — базовая практика SRE: он фокусируется на системных сбоях и пробелах в процессах, а не на ошибках отдельных людей, создавая психологически безопасную среду, в которой инженеры делятся полной информацией без страха наказания. Хороший документ постмортема включает временну́ю шкалу инцидента, восстановленную из дашбордов Grafana, запросов логов Loki и распределённых трассировок; чёткое описание масштаба последствий (затронутые пользователи, израсходованный бюджет SLO, потери дохода); анализ первопричины по методу «пяти почему»; и конкретный список задач с исполнителями и сроками. Постмортемы, выявляющие пробелы в наблюдаемости — отсутствующие метрики, недостаточное покрытие трассировками, неясные runbook, — непосредственно движут улучшениями стека мониторинга и алертинга. Публикация постмортемов внутри компании (и снаружи, когда это уместно) укрепляет доверие, делится знаниями и накапливает поисковую историю паттернов отказов, которая помогает будущим дежурным инженерам реагировать быстрее.
Как это работает
Postmortem — практика обнаружения + диагностики + разрешения проблем сервиса. Процесс: алерт срабатывает → on-call подтверждает → triage (impact, severity) → mitigate (rollback, scale, restart) → исследование root cause → postmortem (blameless, lessons learned, action items). Инструменты: PagerDuty / OpsGenie (paging), Slack / Discord (war room), Statuspage (для клиентов), Jira / Linear (action items). Практикуйте game days — учения без реальных инцидентов.
Когда применять
Стройте incident response с первого реального outage — postmortem на каждый, даже минорный. Поддерживайте шаблон incident-runbook (impact summary, timeline, mitigation, root cause, action items). Game days раз в квартал — поддельный outage в staging, run response. Трекайте time-to-acknowledge + time-to-mitigate как SLI для on-call команды.
Типичные ошибки
Ловушки Postmortem: blameful postmortems (инженеры прячут будущие инциденты); postmortems без action items (уроки не учены); on-call ротации без нормального handoff (knowledge silos); нет statuspage (клиенты долбят support при outage); не тестируете алерты (день, когда они нужны = день, когда они сломаются).