Назад до блогу

Postmortem без пошуку винних: RCA, action items і як перетворити інциденти на покращення

Як робити postmortem так, щоб він підвищував надійність: таймлайн, root cause, contributing factors, “що зробимо і коли”, runbooks, і як уникнути повторів.

11 бер. 2026 р.

Інцидент — це дані для покращення системи

Якщо після інциденту ви просто “відкотили і забули”, він повториться. Postmortem потрібен, щоб знизити ймовірність повтору і скоротити час відновлення наступного разу.

1) Структура postmortem

  • Impact: кого зачепило і яка шкода (час, гроші, репутація).
  • Timeline: що сталося по хвилинах (детекція → діагностика → фікс).
  • Root cause і contributing factors (процес/люди/система).
  • Action items: конкретні, з owner і дедлайном.

2) Action items, які реально працюють

  • Автотести/перевірки, які ловлять клас проблеми.
  • Алерти під SLO (менше шуму, більше сигналу).
  • Runbook: “що перевірити” і “як відкотити” для типових сценаріїв.

3) Без пошуку винних

Фокус на системі: які умови дозволили помилці пройти. Це підвищує відкритість і швидкість навчання команди.

Підсумок

Сильна підтримка — це цикл: інцидент → аналіз → action items → runbooks/алерти → менше інцидентів. Так SLA стає реальністю, а не документом.

Релевантні статті