Як написати пост-мортемний / інцидентний звіт англійською мовою

Коли виробництво припиняють о 3 годині ночі, сам інцидент - це лише половина історії. Друга половина - та, що запобігає наступному відключенню - це пост-мртовий звіт, який ви пишете після того, як хаос заспокоїться.

Для інженерних команд, для яких англійська мова не є рідною, написання пост- мортему представляє дві проблеми одночасно: вам потрібно точно передати технічні деталі * і * використовувати правильний професійний регістр. Якщо ви неправильно введете одну з цих позначок, документ втрачає своє значення.

Цей посібник охоплює структуру, словниковий запас і фрази бездоганних пост-мортемів — стандартний формат, який використовується в Google, Atlassian, PagerDuty і більшості сучасних інженерних організацій.

---

Що таке аутопсія?

Post-mortem (також: звіт про інцидент, ретроспектива інциденту або PIR — Перегляд після інциденту) — це структурований документ, який аналізує значний інцидент після його вирішення. Відповідь:

• Що відбувається і коли (timeline)
• Чому це сталося (аналіз кореневої причини)
• Скільки користувачів було вражено і на який час (вплив)
• Які дії запобігтимуть повторенню (елементи дій). @ info: whatsthis

Цель - научить, а не обвинять. Культура безвинності, вперше запропонована командою SRE Google, базується на принципі, що інциденти спричинені системними збоями і прогалинами в процесах, а не індивідуальною некомпетентністю. Мова вашого пост-морту повинна це відображати.

---

Анатомія пост-морта

1. Європа Заголовок і метадані

Title:      Checkout Service Outage — 2026-03-15
Severity:   SEV-1
Duration:   47 minutes (14:22–15:09 UTC)
Author:     Jane Smith, Sr. SRE
Reviewers:  Backend Lead, CTO
Status:     Draft → In Review → Closed

** Підказки щодо мови: **

• Використовуйте формат [Service Name] Outage / Degradation / Incident — [Date] для заголовка
• Рівні тяжкості залежать від організації: SEV-1/SEV-2, P0/P1, Критичний/Головний
• Завжди використовувати штампи часу UTC у звітах про події, щоб уникнути плутанини з часовими поясами

---

2-й. Резюме (англ. Executive Summary)

3-5-речення огляд написаний для не-технічного читача. Включає в себе те, що не вдалося, коли, вплив і ключову причину.

Шаблон:**

[дата], [служба/система] пережила [тип погіршення] починаючи з [час UTC]. Інцидент тривав [тривалість] і вплинув приблизно на [N% користувачів / N користувачів / певну функціональність]. Основною причиною було [короткий опис]. Інциденту було попереджено [за допомогою заходів зменшення ризику].

** Реальний приклад: **

2026-03-15, Checkout Service пережила повний відключення, починаючи з 14:22 UTC. Інцидент тривав 47 хвилин і не дозволив всім користувачам завершити покупки. Основною причиною був неправильно налаштований пул підключення до бази даних, доданий під час розгортання 14: 18. Службу було відновлено шляхом повернення до попередньої версії.

** Ключовий словник: **

• ** відбувся перерив** — служба була повністю недоступною
• ** переживав погіршення якості ** — служба частково працювала (повільніше, помилки для деяких користувачів)
• ** affected ** — які користувачі або функціональні можливості були вплинуті
• ** коренева причина була ** — основна причина (а не лише ближній тригер)
• ** розв’ язано за ** — дія, яка відновила службу

---

3. Графік

Хронологія - це хронологічний запис того, що сталося, коли і хто діяв. Це найбільш фактична частина — уникайте інтерпретації тут.

** Формат: **

14:18 UTC  Deployment of version 2.4.1 started (engineer: J. Smith)
14:22 UTC  Error rate on /checkout endpoint rose above 5%
14:23 UTC  PagerDuty alert fired: "Checkout error rate > 1%"
14:27 UTC  On-call engineer paged and acknowledged the alert
14:31 UTC  Database connection pool exhaustion confirmed as likely cause
14:44 UTC  Decision taken to roll back to version 2.4.0
14:47 UTC  Rollback deployment started
15:02 UTC  Rollback complete; error rate returned to baseline
15:09 UTC  Incident declared resolved; monitoring verified stable

** Підказки щодо мови для графіка часу: **

Використовуйте простий минулий час і пасивне слово для подій — це зберігає фокус на тому, що сталося, а не на тому, хто це зробив:

Blameful ❌	Blameless ✅
“John deployed broken code"	"Version 2.4.1 was deployed"
"The on-call engineer ignored the alert"	"The alert went unacknowledged for 4 minutes"
"Someone misconfigured the pool"	"The connection pool was misconfigured with a value of 5 (expected: 50)”

Загальні дієслова на часовій шкалі:

• розпочато / розпочалося / було розпочато
• було викликано / викликано / було піднято (для попереджень)
• було підтверджено / було ескальовано
• було виявлено / було підтверджено / було відтворено
• було зменшено / було вирішено / було відновлено
• було оголошено (інциденту оголошено розв’ язаним)

---

4-й. Аналіз ключових причин (англ. Root Cause Analysis, RCA)

Це найтехнічно складніший розділ — і найважливіший. В нем объясняется, почему произошел инцидент, а не только то, что произошло.

Техника 5 причин:

Цель - проследить цепь причинно-следственных связей от симптома обратно к системной коренной причине.

** Чому ** служба оплати зазнала невдачі? → Оскільки рівень з’ єднань з базою даних був вичерпано.

• Нет, не надо ** Чому ** резерв з’ єднань вичерпано? → Тому що він був налаштований з max_connections: 5 замість 50.
• Нет, не надо Чому він неправильно налаштований? → Тому що типове значення у новому шаблоні налаштування було змінено без документації.
• Нет, не надо Чому він був не задокументований? → Оскільки не передбачено обов’ язкового кроку перегляду типових змін налаштувань.
• Нет, не надо ** Корінь проблеми: ** * Шаблони налаштування можна змінювати без обов’ язкового кроку перегляду, який перевіряє критичні параметри на відповідність очікуваним діапазонам.*

** Корисні фрази для розділу RCA: **

• «Причина була…»
• «Близькою причиною було [X]; основною причиною було [Y]»
• “Це було викликано… і ускладнено…”
• «Режим невдачі був…»
• «Система не мала захисту, щоб запобігти…»
• «Не існувало попередження для…»
• «Зміна конфігурації пройшла не виявлена, тому що…»

** Фактори, що сприяють ** (також: ** причини, що сприяють **):

«Кілька факторів, що сприяли посиленню впливу: (1) середовище стаджування використовує базу даних в пам’яті і не відтворює поведінку пулу з’єднань; (2) розгортання відбулося під час годин пікового трафіку»

---

Вплив

Визначте радіус вибуху. Будь чесним — заниження звітів шкодить вірності.

** Розміри для покриття: **

• ** Тривалість ** — точно скільки часу тривала проблема
• ** Вплив на користувачів ** — відсоток або кількість задіяних користувачів; конкретні можливості, на які впливає
• ** Вплив на бізнес ** — прибуток, порушення SLA, скарги клієнтів, втрата даних (якщо є)
• ** Географічний / сегментний вплив ** — всі користувачі чи лише підмножина?

Шаблон:**

Перерва тривала 47 хвилин (14:22–15:09 UTC). Під час цього вікна ** 100% спроб отримання зазнали невдачі ** у всіх регіонах. За оцінками середнього обсягу транзакцій, приблизно 1900 транзакцій було заблоковано. Немає втрати даних. Інцидент викликав повідомлення про порушення SLA для трьох корпоративних клієнтів.

** Ключовий словник: **

• ** радіус вибуху ** — обсяг впливу; наскільки широко поширюється проблема
• вплинула на N% користувачів / вплинула на N користувачів
• ** всі регіони / всі користувачі / користувачі у [регіон] **
• ** 100% рівень помилок ** / ** часткова деградація **
• ** не було втрати даних ** / ** цілісність даних була збережена **
• ** Порушення SLA ** — інцидент перевищив визначені пороги угоди про рівень обслуговування
• ** customer- facing ** — видимий для кінцевих користувачів (на відміну від внутрішнього)

---

6. Елементи дій

Найбільш дійсний розділ. Кожен елемент має бути конкретним, призначеним для певної особи і обмеженим часом.

** Формат: **

Action	Owner	Priority	Due
Update config template defaults and add inline comments for all critical parameters	J. Smith	High	2026-03-22
Add automated validation step in CI to check connection pool config ranges	DevOps team	High	2026-03-29
Create staging database that mirrors production connection limits	Platform team	Medium	2026-04-05
Add metric and alert for connection pool utilisation > 80%	SRE	Medium	2026-03-25
Schedule incident review presentation for the full engineering team	EM	Low	2026-03-20

** Мова для елементів дій: **

Завжди використовуйте форму ** імперативу (команда) ** для описів елементів дій — це інструкції, а не спостереження:

Observation (wrong register)	Action item (correct register)
“The config template was confusing."	"Rewrite the connection pool config template with inline documentation."
"There was no alert."	"Add a PagerDuty alert for pool utilisation > 80%."
"Staging didn’t match production."	"Configure staging to use connection pool limits that match production.”

---

Мова: мова мовлення: мова мовлення

Найскладнішою частиною пост-мртового письма для носіїв мови, яка не є рідною, часто є культурне очікування безвинності. У багатьох інженерних культурах, пряме приписування невдачі людині («X поламав Y») є нормальним. У західній пост-мёртвенной культурі це розглядається як контрпродуктивно.

Принцип: Люди не викликають інцидентів - системи, процеси і недостатні заходи безпеки.

Переписати ці фрази:

Blameful ❌	Blameless ✅
“The developer pushed untested code."	"The code reached production without adequate test coverage."
"The DBA dropped the wrong table."	"A DROP TABLE command executed on the production database without a dry-run check."
"The engineer forgot to update the runbook."	"The runbook had not been updated to reflect the new deployment process."
"Nobody noticed the alert."	"The alert was not acknowledged within the escalation window."
"She made a mistake."	"The configuration contained an error that was not caught by pre-deployment validation.”

Суб’єкт змінюється з особи на процес, систему, конфігурацію або практику.

---

Швидкий довідник словників

Term	Definition
post-mortem	Document that analyses an incident after resolution; can also be a meeting
incident	An unplanned event that disrupts normal service operation
outage	Complete unavailability (100% failure rate)
degradation	Partial reduction in service quality (elevated error rate, high latency)
root cause	The underlying systemic reason for the incident
proximate cause	The immediate trigger (the thing that actually broke)
contributing factor	A condition that made the incident worse or more likely
mitigation	A temporary action that reduces impact before the root cause is fixed
remediation	The permanent fix that addresses the root cause
rollback	Reverting to a previous version of code or configuration
blast radius	The scope of who or what was affected
on-call	The engineer responsible for responding to alerts during a given rotation
SLA / SLO / SLI	Service Level Agreement / Objective / Indicator — contractual and operational availability targets
MTTR	Mean Time to Restore — the average time to resolve an incident
MTTD	Mean Time to Detect — the average time to discover an incident
blameless	Without attributing fault to individuals; focused on systems and processes
action item	A specific, assigned, time-bounded task resulting from the post-mortem

---

Template

Скопіювати і адаптувати цей шаблон для вашої команди:

# [Service Name] [Outage / Degradation / Incident] — [YYYY-MM-DD]

**Severity:** SEV-1 / SEV-2
**Duration:** [N] minutes ([HH:MM]–[HH:MM] UTC)
**Author:** [Name]
**Status:** Draft

---

## Summary
[3–5 sentence overview of what failed, when, the impact, and the key cause.]

---

## Timeline

| Time (UTC) | Event |
|---|---|
| HH:MM | [Event description in past tense] |
| HH:MM | [Event description] |

---

## Root Cause Analysis
The root cause was [description].

**5 Whys:**
1. Why did [symptom] occur? → [Reason 1]
2. Why did [Reason 1] occur? → [Reason 2]
...
Root cause: [Systemic gap]

**Contributing factors:**
- [Factor 1]
- [Factor 2]

---

## Impact
Duration: [N] minutes
Users affected: [N% / all users / users in region X]
Features affected: [specific features or API endpoints]
Data loss: None / [description]
SLA breach: Yes / No

---

## Action Items

| Action | Owner | Priority | Due |
|---|---|---|---|
| [Specific action in imperative form] | [Name] | High/Medium/Low | [Date] |

---

## Lessons Learned
- [What we learned about our system]
- [What we learned about our process]
- [What went well during response]

---

Что общего у хороших аутопсий

✓ Конкретний, а не неочевидний — « резерв з’ єднань вичерпано о 14: 31 UTC з 0/ 5 доступними з’ єднаннями » корисніше, ніж « проблеми з базою даних »

✓ Кількісне значення — « 47 хвилин », « 1900 заблокованих транзакцій », « 3 сповіщення SLA » перевершують « значний час простою »

** ✓ Системна коренева причина ** — зупиняє роботу на « не існує кроку перевірки », а не на « налаштування було неправильним »

✓ Реалізовані елементи — «Додати перевірку CI для діапазонів налаштувань пулу до 2026-03-29 (Власник: DevOps)», а не «пізнайомити з процесом розгортання»

✓ Безвинний тон — системи і процеси провалюються, а не люди

✓ Запис, коли пам’ ять свіжа — починається протягом 24 годин, завершується протягом 48- 72 годин

---

Написання ретельного огляду тіла - це одна з найважливіших робіт, яку може виконати старший інженер. Це перетворює болісний інцидент на інституційно-знання. Чим ясніше твоя англійська, тим більше знань передаватимеш всій команді.