Як написати безглуздої постмортем в англійській мові: структура, мова і приклади
A practical guide to writing blameless postmortems in professional English — structure, timeline language, passive voice for neutrality, and a complete example outline. (англійською).
Післясмертний аналіз є письмовим аналізом інциденту — виробничого переривання, події втрати даних, значної помилки у виробництві. Слово походить від латинського «після смерті», і в інженерії воно відноситься до структурованого відображення, що слідує за значною невдачею. Найкращі постмортіми ** безвинні **: вони зосереджені на системних помилках, процесних прогалинах і факторах навколишнього середовища, а не на окремих помилках. Написання хорошого бездоганного постмортму англійською мовою вимагає розуміння як структурних конвенцій, так і конкретного вибору мови, що зберігає документ нейтральним, конструктивним і корисним.
Що таке «недолік» і чому він важливий
** Безвинний ** не означає, що люди не несуть відповідальності. Це означає, що післясмертна експертиза зосереджена на тому, чому система дозволила помилки, а не на тому, хто зробив помилку. Ця відмінність важлива з двох причин:
- Культурна безпека: Інженери, які бояться звинувачення, будуть приховувати проблеми, відкладати ескалацію і уникати ризикованої, але необхідної роботи. Безвинні постмортіми створюють середовище, де про події можна повідомляти і обговорювати чесно.
- ** Практична ефективність: ** Корінні причини інцидентів майже завжди системні - прогалини в моніторингу, недостатнє тестування, відсутні заходи безпеки, неясні процеси. Приписування вини індивіду не вирішує ці прогалини і не запобігає повторенню.
Безвинна постмортальна відповідь: * “Що наші системи, процеси і середовище не змогли запобігти?” *
Помер після смерті
Стандартний документ післясмертної перевірки складається з таких розділів:
Резюме
Короткий (2- 4 речення) опис того, що сталося, коли це сталося, вплив і як це було вирішено. Це має бути зрозумілим для нетехнічного користувача.
2. Удар
Кількісний опис того, хто і що постраждали: кількість користувачів, на яких впливає, тривалість перерви, прибуток або наслідки SLA, зачеплені служби.
3. Графік
Хронологічна послідовність подій — коли почався інцидент, коли він був виявлений, коли були виконані різні дії, коли він був розв’ язаний.
4. Причинні фактори
Умови, які дозволили інциденту статися або ескалуватися. Це системні — відсутні тести, недостатній моніторинг, нечіткі runbooks, складність налаштування.
5-й. Аналіз причинного зв’язку
Основна причина(и). Часто не існує єдиної кореневої причини; існує ланцюг факторів, що сприяють.
6. Елементи дій
Конкретні, власні, обмежені часом завдання для запобігання повторення або зменшення майбутнього впливу. Це найважливіший розділ.
Мова хронології
У розділі « Графік » використовуються певні англійські правила для чіткого позначення часу і послідовності.
Фрази посилання на час
- О 14:32 UTC**, перше попередження викликало підвищений рівень помилок в платіжному сервісі
- Приблизно о 14:35 інженер на черзі підтвердив попередження
- «До 14:40, рівень помилок досяг 45% на кінцевій точці замовлення»
- «О 14:52, інженерна команда розпочала відновлення розгортання 14:20.»
- О 15:04:04, рівень помилок повернувся до базового і інцидент був оголошений зменшеним
Послідовність слів
Використовуйте ці для поєднання подій:
- «Незабаром після розгортання, показники затримки почали зростати.»
- «Після приблизно 10 хвилин, були отримані перші скарги користувачів.»
- «Одночасно, команда бази даних досліджувала насиченість бази даних з’єднань.»
- «** Після відновлення **, команда підтвердила, що рівень помилок нормалізувався. »
- «Тим часом, сторінка статусу була оновлена, щоб відобразити триваючий інцидент.»
Причини виникнення ревматизму
Багато інженерів використовують «коренева причина» і «причинні фактори» взаємозамінно, але вони мають різне значення в постмортному письмі.
** Фактори, що сприяли ** це умови, які зробили інцидент можливим або погіршили його:
- «Нове розгортання не було фіксовано функцією, тобто воно було розгорнуто для 100% користувачів одночасно»
- «Стежинне середовище не відображало завантаження виробничої бази даних, тому регресія продуктивності не була виявлена під час тестування»
- «Не було автоматичного тригера відновлення на підвищених ступенях помилок»
** Корінь причини ** — це основна умова, без якої ця подія не сталася б:
- «Головною причиною було неправильне обмеження на пул з’єднань, введене в зміну конфігурації, розгорнутої о 14:20 UTC»
Якщо ви не можете впевнено визначити одну корінну причину, можна сказати: « Корінна причина була поєднанням факторів » і перерахувати їх. Примусити до єдиної кореневої причини, де не існує є формою оповіді спотворення.
Використання пасивного голосу для нейтралітету
Пасивний голос — зазвичай не рекомендується в звичайному англомовному письмі — є відповідним і корисним в безвинних постмоментах. Це дозволяє вам описати дії без приписування особистої провини.
| Active (avoid in postmortems) | Passive (preferred for neutrality) |
|---|---|
| “John deployed the wrong config." | "An incorrect configuration was deployed." |
| "The team missed the alert." | "The alert was not actioned within the expected time window." |
| "Maria approved the PR without running tests." | "The pull request was merged without the full test suite passing.” |
Це не про прикриття того, що сталося — розділ « Часова лінія » буде документувати послідовність подій у деталях. Пасивний голос використовується для запобігання тому, щоб розділи, що стосуються факторів, що спричиняють помилки, і аналізу причин, які спричиняють помилки, виглядали як список окремих помилок.
Формат елементів дій
Елементи дій є вихідними даними, які дають довгострокове значення після смерті. Неясні елементи дій («пізнайтеся більше», «додати більше моніторингу») є поширеними і майже безглуздими. Ефективні елементи дій є специфічними, належать власнику і обмежені часом.
Format
Action item: [Specific task]
Owner: [Name or team]
Due: [Date or sprint]
Priority: [P1 / P2 / P3]Examples
Action item: Add an automated rollback trigger to the deployment pipeline
that fires when error rate exceeds 10% within 5 minutes of a deployment.
Owner: Platform Engineering
Due: 2026-07-01
Priority: P1
Action item: Update the staging environment configuration to mirror the
production connection pool settings.
Owner: Infrastructure team
Due: 2026-06-30
Priority: P1
Action item: Add a load test to the CI pipeline for the payment service
that validates performance under 2x expected traffic.
Owner: Payments team
Due: 2026-07-15
Priority: P2Приклад постмортемного опису
Нижче наведено короткий план пост-мртового розслідування вигаданого інциденту.
Процитовано 2016-06-15. (англ.)
** Серйозність: ** P1
** Тривалість:** 32 хвилини (14:22 UTC — 14:54 UTC)
** Резюме: ** Зміна налаштувань, розгорнута о 14: 20 UTC, встановила обмеження на кількість з’ єднань до бази даних до 5, а не до 50. Це спричинило насичення з’єднання під час нормального трафіку, що призвело до 35-45% рівня помилок по всій касі і платіжних API протягом 32 хвилин. Інцидент було вирішено шляхом відновлення розгортання.
Вплив: Приблизно 12 000 користувачів не змогли завершити вихід під час вікна інциденту. Оцінений вплив доходів: £ 48,000.
Временная шкала:
- 14:20 — Зміна конфігурації розгорнута до виробництва.
- 14:22 — Латенція попереджає про пожежу в платіжному сервісі.
- 14:25 — Дежурний інженер починає розслідування.
- 14:32 — Насиченість бази даних з’єднання визначено як ймовірну причину.
- 14:52 — Ініціалізація відновлення.
- 14:54 — Частота помилок повертається до базисного рівня. Інциденту уникнути не вдалося.
- 15:30 — Інцидент оголошено вирішеним. Вскрытие назначено.
** Фактори, що впливають на це:**
- Зміна налаштувань не була переглянута на вплив на інфраструктуру як частина процесу звантаження.
- Не було автоматичного механізму відновлення для піків помилок після розгортання.
- Середовище стаджування не відображає виробничі шаблони трафіку, тому вплив не спостерігався під час тестування перед розгортанням.
** Корінь проблеми: ** У виробничих налаштуваннях було вказано неправильне значення (5) для DB_MAX_CONNECTIONS, що призвело до перевантаження пулу з’ єднань під час звичайного навантаження.
** Елементи дій: ** (див. формат вище)
Ключеві моменти
- Без винуватості означає зосередження на системних прогалинах, а не на окремих помилках.
- Використовуйте ** пасивний голос ** у розділах про фактори, що сприяють і кореневі причини, щоб зберегти нейтралітет.
- Розрізняти ** фактори, що сприяють ** (умови) від ** кореневої причини ** (основної причини).
- Мова часової шкали використовує ** специфічні часові штампи UTC ** і послідовні слова, такі як « незабаром після », « приблизно », « одночасно ».
- Елементи дій повинні бути ** специфічними, належати власнику і обмежені часом **, щоб їх варто було записувати.