Postmortem: як перетворити інцидент на поліпшення системи

Після інциденту сторінка знову відкривається, черга спорожніла, а черговий зміг перейти до іншої роботи. Але чи означає це, що команда вже зрозуміла подію? Можливо, відновлення лише приховало симптом. Можливо, інший клієнт за тих самих умов уже отримав неправильні дані, але ще не повідомив про проблему. А може, система справді повернулася до нормального стану, проте її слабкі місця залишилися незмінними.

У главах 62–63 ми розглянули реакцію під час інциденту й підготовлені процедури. Тут фокус зміщується на те, як після події зібрати перевірювану історію: що зачепило користувачів, які сигнали й рішення були доступні тоді, що допомогло або завадило виявленню й відновленню, а також які зміни мають зменшити ризик. Інцидент — це привід поставити запитання про роботу системи. Сам звіт не доводить причину й не виправляє її.

Навчальний результат. Після цієї глави читач може відрізнити факти від гіпотез і невідомого, скласти хронологію з часовими поясами й окремими часами події, виявлення та запису, описати кілька взаємопов’язаних чинників без зведення пояснення до «людина помилилася», а також перетворити висновки на конкретні дії з власником, пріоритетом, критерієм приймання й подальшою перевіркою ефекту.

У цій главі післяінцидентний розбір (postmortem) означає керований аналіз події після стабілізації системи. Його результатом є не тільки документ, а й зміни, виконання яких можна простежити та перевірити. У різних командах назва може охоплювати коротку нотатку, зустріч, детальний звіт або всі ці речі. Важливіше за назву заздалегідь домовитися про тригери, рівень глибини, аудиторію та те, як висновки переходять у роботу. Google Site Reliability Engineering (SRE — інженерія надійності сервісів) описує схожу практику як запис про вплив, дії з пом’якшення чи відновлення, причини й подальші дії; Google наголошує, що формат треба налаштовувати під організацію, а не копіювати як універсальний стандарт. Google SRE: Postmortem Culture

64.1. Визначте, коли й наскільки глибоко розбирати подію

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

Варто розбирати й майже інциденти (near miss): ситуації, в яких небезпечні умови вже виникли, але шкоди вдалося уникнути випадково, завдяки останньому ручному кроку або резервному контролю. Наприклад, команда могла помітити перед масовим імпортом, що файл має іншу кодувальну схему, і зупинити його до перезапису каталогу. Якщо аналізувати лише фактичні збої, команда не побачить сигналу про несправний запобіжник, поки той не пропустить помилку.

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

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

Глибокий розбір потрібний, коли кілька умов взаємодіяли, люди мали різні сигнали, відновлення саме створило нову небезпеку, шкода невизначена або попередні дії не зменшили ризик. Попросіть долучитися власників компонентів, підтримку чи інші ролі, чия інформація пояснює інший бік події. Не збирайте десятки людей «про всяк випадок»: надмірна зустріч може повторно перервати тих, кому потрібно зібрати докази. У Peopleware Том ДеМарко й Тім Лістер окремо розглядають час зосередженої роботи та переривання; у вибраному видавничому уривку вони обговорюють, чому розбивання роботи на короткі відрізки погіршує умови для складного мислення. Ми застосовуємо цю ідею до розслідування: дайте учасникам час на факти, зберіть короткі письмові внески та проведіть лише потрібну для узгодження зустріч. Це не твердження, що книга пропонує формат післяінцидентної процедури. Pearson: Peopleware, 3-тє видання, зміст і уривок розділу про зосереджену роботу

Розбір не є судом, дисциплінарною процедурою або виправданням команди. Водночас «blameless» не означає, що ніхто не має взяти на себе подальшу роботу. Тут беззвинувачувальний підхід означає: не підміняти пояснення системи пошуком винної людини; з’ясувати умови, інформацію, інструменти й обмеження, які зробили конкретну дію зрозумілою або ймовірною; призначити власників поліпшень. Питання «хто має змінити контроль і перевірити результат?» потрібне. Питання «хто заслуговує на сором?» не покращує технічний аналіз.

64.2. Відділяйте вплив і факти від припущень

Сильний звіт починається не з теорії причини, а з короткого опису того, що зараз можна підтвердити: яка функція працювала неправильно, у який період, яких користувачів або даних це могло зачепити, як команда дізналася про проблему й що зробила для стабілізації. Уникайте таких заяв, як «усі замовлення були неправильними», якщо перевірені лише три звернення в підтримку. Так само не пишіть «постраждалих не було», якщо вимірювання не охоплює всі маршрути й повтори.

Для кожного суттєвого твердження позначайте один із трьох станів:

Статус	Що він означає	Приклад формулювання
Підтверджений факт	Є джерело, з якого інша людина може повторити перевірку.	«Журнал обробки містить 18 відхилених записів із партії за 14:00 за координованим всесвітнім часом».
Оцінка або гіпотеза	Це найкраще пояснення доступних сигналів, але воно залежить від припущень.	«Ще до 40 записів могли повторно надійти, якщо провайдер виконав свої автоматичні повтори».
Невідоме	Наявних даних недостатньо, або зібрати їх уже неможливо.	«Ми не можемо встановити, чи всі користувачі повторили запит після тайм-ауту».

Вплив описуйте з межами вимірювання. Розділіть:

• Часовий інтервал: коли почався перший підтверджений неправильний стан, коли він перестав виникати і чи тривали наслідки після основного відновлення.
• Охоплення: користувачі, регіони, операції, типи записів, релізи або інтеграції, які реально перевірено.
• Наслідок: відмова дії, затримка, дублювання, неправильне значення, ризик безпеки, додаткова ручна робота або втрата довіри.
• Джерела й обмеження: метрики, журнали, базові записи, звернення підтримки, звірка з постачальником, прогалини зберігання чи приватності.

Якщо цифри неповні, назвіть інтервал оцінки та метод. «Відомі щонайменше 7 подвійних підтверджень; верхню межу не встановлено, бо журнал шлюзу видаляє запити через 24 години» інформативніше за удавано точне «було 7 інцидентів». Нуль у звіті може означати не відсутність наслідку, а відсутність сигналу.

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

64.3. Зберіть хронологію, яку можна перевірити

У таймлайні важливо не зливати в один час щонайменше три різні події:

1. Час події: коли система вперше перейшла в неправильний стан або виконала дію.
2. Час виявлення: коли сповіщення, користувач чи черговий побачив сигнал.
3. Час запису: коли хтось додав згадку про це до журналу, чату чи документа.

Наприклад, автоматична транзакція могла створити дубль о 10:14:02, перевірка цілісності знайшла його о 10:17, а черговий записав про знахідку в координаційний журнал о 10:20. Якщо документ показує лише «дубль знайдено о 10:20», команда може помилково оцінити тривалість впливу як шість хвилин замість трьох хвилин до виявлення плюс час до усунення наслідків.

Використовуйте один стандартний часовий пояс, наприклад Coordinated Universal Time (UTC — координований всесвітній час), але не видаляйте вихідні часові позначки, якщо вони важливі для перевірки. Зберігайте зону джерела й дату, щоб не помилитися під час переходу на літній час або при зіставленні логів із різних країн. Для приблизного часу пишіть «приблизно», «не раніше» чи інтервал, а не створюйте враження точності до секунди.

Корисні поля одного запису: час із зоною, тип часу (подія/виявлення/рішення/запис), джерело, спостережуваний факт або рішення, власник дії та впевненість у точності. Коли в різних джерелах час не збігається, збережіть обидва значення й поясніть розбіжність. Журнал має показувати, що люди знали в кожен момент, а не лише як подія виглядає після її повного аналізу.

Це допомагає уникати упередження заднього числа (hindsight bias): після того, як причина відома, люди схильні вважати, що її було легко передбачити й до події. Для кожного рішення запитайте: який сигнал був видимий тоді? Які альтернативи розглядали? Чи було зрозуміло, що один із варіантів небезпечний? Які обмеження часу, доступу, документації або інструментів діяли? Не приписуйте учаснику знання, які з’явилися тільки пізніше.

64.4. Описуйте причинні умови, а не одного винуватця

Слово причина може приховати різні рівні пояснення. Розрізняйте щонайменше:

• Дефект або небезпечна умова: стан коду, даних, конфігурації чи процесу, який уможливив неправильний результат.
• Тригер: подія або послідовність, що активувала дефект саме цього разу.
• Супутні чинники: умови, що підвищили шанс події, збільшили охоплення або затримали виявлення й відновлення.
• Захисні бар’єри: перевірки, обмеження, тестування, резервування чи сповіщення, які могли зупинити помилку або зменшити шкоду; також важливо, чому їх не було, вони не спрацювали або були обійдені.

У складній системі рідко корисно наполягати на одній «єдиній root cause» — головній першопричині. Фраза «перевірка доступності не атомарна» може бути правильною на рівні коду, але не пояснює, чому два запити могли одночасно підтвердитися, чому база не відхилила неможливий стан, чому повтор не був ідемпотентним, чому тест не відтворив гонку й чому оператор не отримав сигналу. Корисна причинна модель показує, як кілька конкретних умов зійшлися, а не видає першу знайдену слабкість за всю історію.

Вислів «людська помилка» — це опис дії, а не достатнє пояснення. Запишіть дію нейтрально: «оператор повторив запуск після тайм-ауту, бо не було видимого статусу першого виконання». Потім перевірте навколишню систему: чи була перша дія ще активною? Чи пояснював інтерфейс стан? Чи описувала процедура повтор? Чи захищала база інваріант? Чи мав оператор доступ до перевірки результату? Це не знімає відповідальності за поліпшення. Воно перетворює просту оцінку людини на можливі зміни контролю.

Blameless не дорівнює «без відповідальних». Якщо працівник порушив чітке, доступне й актуальне обмеження, а система мала дієві запобіжники, розбір усе одно може зафіксувати конкретне рішення й окремо спрямувати управлінське питання у відповідний приватний процес. Технічний звіт не має робити висновок про компетентність, мотиви чи характер. Власник кожної зміни повинен розуміти свою задачу, строк, необхідний доступ і шлях ескалації, якщо ресурсів бракує.

Така практика пов’язана з Peopleware через її увагу до умов роботи, координації й організаційного навчання. Це не означає, що всі інциденти виникають через робоче середовище або що людям не можна ставити вимог. Це означає, що навантаження, переривання, передавання зміни, нечітка відповідальність і страх повідомити про проблему — факти про систему роботи, якщо їх можна підтвердити. DevOps (Development and Operations — розробка й експлуатація) Research and Assessment (DORA — дослідження й оцінювання DevOps-практик) описує культуру високої довіри з відкритим рухом інформації як таку, що сприяє навчанню й кращому обміну ризиками; її матеріали розглядають «невдача веде до пошуку винного» та «невдача веде до дослідження» як різні культурні реакції. Це дослідницька узагальнена модель, а не обіцянка, що один постмортем автоматично змінить культуру. DORA: Generative Organizational Culture

64.5. Аналізуйте виявлення й відновлення окремо

Запитання «що спричинило дефект?» відрізняється від «чому ми дізналися про нього саме тоді?» та «чому відновлення тривало саме стільки?». Наприклад, помилковий запис міг виникнути під час імпорту, але сповіщення про відставання охоплювало лише середній вік черги. Середнє значення залишалося прийнятним, хоча одна клієнтська група не отримувала оновлень. Тут є прогалина у видимості охоплення, навіть якщо причина імпорту вже відома.

Для виявлення перевірте:

• який сигнал першим показав проблему: внутрішня метрика, зовнішня перевірка, підтримка, партнер чи самі користувачі;
• чи відображав сигнал користувацький результат, а не тільки стан процесу;
• коли з’явилася умова і коли її сповістили; чи були пороги придатними для цього типу шкоди;
• які перевірки мовчали, були вимкнені, показували середнє замість сегмента або не мали власника;
• чи спрацював контроль на «майже інциденті», який міг зупинити більший вплив.

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

Не оцінюйте якість реакції тільки тривалістю. Довше відновлення іноді є ознакою обережної звірки стану, яка запобігла незворотній шкоді. Так само швидке відновлення могло просто приховати проблему. Корисні питання: яке рішення зменшило вплив? Яке відклало відновлення і чому? Який тимчасовий крок треба прибрати? Яку додаткову перевірку виконано перед оголошенням завершення?

64.6. Перетворюйте висновки на перевірювані дії

Дія після інциденту (follow-up action) — це окрема задача з конкретною зміною або дослідженням, пов’язаним із виявленим ризиком. Слабка дія звучить як «додати більше тестів», «бути уважнішими», «поліпшити моніторинг» або «переписати складний сервіс». Вона не вказує, яку поведінку змінити, хто це зробить і як перевірити результат.

Для кожної дії запишіть:

1. Ризик: який конкретний механізм відмови або затримки має бути обмежено.
2. Результат: що буде інакше в системі або процесі після завершення.
3. Власник і помічники: хто відповідає за результат; які інші команди мають долучитися.
4. Пріоритет і причина: що станеться, якщо відкласти; який строк узгоджений із рівнем ризику й ресурсами.
5. Критерій приймання: що можна показати, щоб незалежний перевіряльник підтвердив зміну.
6. Критерій ефективності: який сигнал після випуску чи репетиції покаже, що ризик справді зменшився.

Пріоритети мають сенс лише в локальній домовленості. Наприклад, у звіті etcd P0 означав блокувальну для надійності гілки v3.5 роботу, P1 — критично важливий довший крок для випуску v3.6, P2 — ціль, що могла бути відкладена. Не копіюйте ці рівні в іншу команду, не визначивши, хто їх присвоює та що кожен рівень змінює на практиці.

Приклад слабкої дії: «Додати тест проти подвійного бронювання».

Перевірювана версія: «Власник сервісу бронювання додає інтеграційний сценарій, у якому два незалежні запити читають останнє вільне місце до підтвердження; після виконання обидва запити не можуть отримати підтвердження. Сценарій повторюють після тайм-ауту та після звільнення тимчасового резерву. Критерій приймання — у сховищі лишається не більше одного активного бронювання на місце, а інший запит отримує відмову або пропонує альтернативу. Після випуску команда перевіряє лічильник конфліктів бронювання й звіряє його з підтримкою за погоджений період».

Перша частина перевіряє, що конкретний клас дефекту не повернувся; друга — що тест справді ловить потрібну гонку; третя — що production сигнал не втрачає подібну проблему. Якщо тест не може показати, що ловить стару неправильну поведінку, спершу зробіть його чутливим до контрольного дефекту або іншого відтворюваного зламу. «Тест існує» не доводить, що він перевіряє потрібне.

Зв’язуйте постмортем із відстежуваним issue або запитом на зміну в GitHub, системі задач чи іншому сховищі роботи. У GitHub issue зазвичай фіксує проблему або обсяг роботи; Pull Request (PR — запит на внесення змін) пропонує конкретну зміну в репозиторії для перегляду й злиття. Саме посилання на задачу ще не доводить її ефективності. Потрібні статус, критерій приймання, власник і посилання на перевірку. Якщо задача закрита автоматично після PR, упевніться, що закриття означає завершену зміну, а не просто наявність документа.

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

Не прирівнюйте кількість закритих задач до надійності. Можна закрити десяток дрібних пунктів і лишити головний ризик; можна обґрунтовано відкласти дію, якщо вона стала недоречною, але зафіксувати нове рішення та прийнятий залишковий ризик. DORA нині описує п’ять метрик ефективності постачання програмного забезпечення й наголошує, що їх варто читати в контексті окремого сервісу, не ставити як цілі для змагання між командами й не зводити покращення до самої побудови вимірювання. Поточна п’ятиметрична модель відрізняється від чотирьох «ключових метрик», про які писали в первинному виданні Accelerate 2018 року, виданому IT Revolution (Information Technology — інформаційні технології). Метрики можуть підказати місце для дослідження; вони не замінюють підтвердження, що конкретний follow-up завершений і знизив ризик. IT Revolution: Accelerate, 2018; DORA: метрики ефективності постачання програмного забезпечення

64.7. Допомога агента: збір доказів, не вигадування історії

Агент зі штучним інтелектом (Artificial Intelligence, AI — штучний інтелект) може допомогти згрупувати часові позначки, знайти розбіжності між версіями документа, скласти список відкритих питань або перетворити перевірені факти на чернетку. Він також може додати переконливу, але не підтверджену причину; переплутати текст, який був у репозиторії, з текстом, який справді бачив агент; або вигадати точну цитату з неповного журналу. Спільні інструкції для Codex і Claude Code та їхні версійні й конфігураційні межі розглянуто в §65.8 і §65.12.

Тому розділяйте в результаті агента:

• витягнуті спостереження з посиланням на лог, commit, часову позначку або документ;
• висновок чи гіпотезу, що з’єднує кілька спостережень;
• питання до людей, чию інформацію не можна відновити з технічних артефактів;
• невідоме, яке агент не може заповнити власним правдоподібним текстом.

Якщо розбір стосується роботи агента, перевірте точну версію інструкції, область її дії, що саме було доступне в конкретному запуску, налаштування дозволів інструментів, викликані операції та подальшу перевірку людиною. Не прирівнюйте файл інструкцій у репозиторії до доказу, що він був у контексті цього запуску. У різних продуктах і середовищах правила завантаження відрізняються: документація Claude Code описує CLAUDE.md/AGENTS.md як механізм контексту про проєкт; документація OpenAI Codex описує власні правила для AGENTS.md. Це підтверджує, що слід перевіряти конкретне середовище й його записи, а не робити припущення про агента на основі назви продукту. Дату й правила доступності інструкцій у Claude Code та Codex перевірено 10 жовтня 2026 року; у кожному розборі звіряйте журнал конкретного запуску. Claude Code: How Claude remembers your project; OpenAI Codex: Custom instructions with AGENTS.md

OpenAI у настановах для створення застосунків із моделями радить обмежувати вихідні дані та перевіряти результат перед дією, особливо якщо помилка має важливі наслідки. Це рекомендація для сценаріїв OpenAI Application Programming Interface (API — програмний інтерфейс застосунку); її не слід автоматично переносити на Codex, Claude Code або інші агенти. Для будь-якого інструмента конкретна вимога залишається однаковою: кожен важливий висновок має бути звірений із першоджерелом або людиною, яка знає фактичний контекст. OpenAI: Safety best practices

Повністю розібрані приклади

Перші два приклади нижче вигадані для навчання. Усі числа, назви систем і часові позначки — частина сценаріїв, а не виміряні пороги чи факти про реальні продукти. Третій — публічний постмортем команди etcd; його факти відділені від нашого навчального висновку.

Приклад 1. Два клієнти отримали підтвердження одного місця

Ситуація. Це окремий вигаданий сценарій, не продовження §62.10: там команда перевіряла стан після тайм-ауту, коли тимчасовий резерв уже існував. У сервісі залишалося одне місце на вечірній сеанс. О 10:14 два запити майже одночасно отримали повідомлення «бронювання підтверджено». О 10:17 підтримка помітила, що обидва клієнти надіслали однаковий ідентифікатор місця. Черговий о 10:21 зупинив продаж цього сеансу й почав звіряти записи. Час у навчальному сценарії вказаний у UTC.

Що підтверджено. У таблиці бронювань є два активні рядки для одного місця й сеансу. Журнал показує, що обидва запити читали значення «вільно» перед записом. Інтерфейс підтвердив обидві спроби. Підтримка має два звернення. Команда ще не має достовірного підрахунку, чи обидва клієнти натиснули «підтвердити» один раз, чи один повторив запит після затримки. Тож звіт говорить про два підтверджені записи й окремо зазначає невідоме щодо повторів і потенційного охоплення.

Хронологія. 10:14:02 і 10:14:03 — дві події створення бронювання згідно з журналом сервера. 10:17 — підтримка отримує перше звернення; це час виявлення людьми, а не виникнення. 10:19 — черговий знаходить два активні рядки. 10:21 — нові бронювання для сеансу тимчасово зупинені. 10:32 — клієнтам запропоновано місце на іншому сеансі або повернення коштів; фінальне вирішення зафіксовано окремо. Якщо журнал не зберіг точні серверні секунди для одного запиту, хронологія має показати приблизний час, а не домислити його.

Причинна модель. Підтверджений технічний факт — два запити мали змогу прочитати залишок до того, як будь-який запис зробив місце зайнятим. Це пояснює шлях до дубля, але не весь механізм: команда ще перевіряє, чи операція мала виконуватися однією транзакцією, чи схема бази допускає два рядки за однаковим ключем, і яку роль зіграв повтор після тайм-ауту. Супутні умови — інтерфейс показав швидке підтвердження, а система не мала незалежної перевірки на друге активне місце. Не записуйте «клієнти надто швидко натискали» як причину. Швидкість двох запитів — очікувана поведінка конкурентних користувачів, яку система бронювання повинна обробляти.

Виявлення й відновлення. Сповіщення показувало загальну кількість місць, але не конфлікти на рівні окремого сеансу; проблему побачила підтримка. Зупинка продажу обмежила нові підтвердження, але не виправила вже створені. Після узгодження з двома клієнтами команда повернула одному бронювання на альтернативний сеанс і звірила оплату до оголошення інциденту завершеним. Даних недостатньо, щоб заявити про відсутність усіх інших конфліктів, тому команда шукає за тим самим ключем за період, де логи ще доступні.

Дії. У локальній шкалі цього вигаданого сервісу P1 означає, що захист від подвійного підтвердження має бути прийнятий до повторного відкриття продажу цього потоку; це рішення за ризиком бронювання, а не універсальна розшифровка P1. Власник сховища додає інваріант, який забороняє більше одного активного бронювання місця. Власник сервісу додає тест одночасного підтвердження й окремий сценарій повтору після тайм-ауту; критерій приймання — саме один запит може створити активне бронювання, інший бачить безпечну відмову. Власник спостереження додає сигнал на конфліктні ключі та перевіряє його на штучному контрольному випадку до випуску. Власник продукту погоджує повідомлення клієнту й спосіб звіряння платежу. Через погоджений час команда перевіряє, чи не з’являються конфліктні записи, але не вважає тишу достатнім доказом: тест має показати, що ловить старий клас дефекту.

Чому це краще. Опис стосується умов системи, а не передбачуваної поведінки користувачів. Звіт називає, що відомо, як це відомо, чого бракує і хто змінює різні бар’єри. Коли такий розбір неповний: якщо звірка виявить уже списані кошти, приховані бронювання або повідомлення, надіслані обом клієнтам, треба додати відповідні наслідки й коригувальні дії; не завершувати звіт лише тому, що зупинено нові запити.

Приклад 2. «Агент проігнорував інструкцію» — гіпотеза, яку треба перевірити

Ситуація. Після запуску нічного експорту звіт спершу стверджує: «агент не прочитав інструкцію, тому опублікував файл із персональними даними». Команда встигає зупинити публічне завантаження до того, як з’являється підтвердження доступу сторонніх людей. Сам експорт містив зайві поля. Небезпечна готовність даних — інцидент, хоча можливий витік ще треба з’ясувати.

Перша перевірка. Розбір не приймає речення про «непрочитану інструкцію» як факт. У цьому вигаданому сценарії служба запуску зберігає маніфест конкретного виконання: ревізію завдання, перелік контекстних файлів, результат дозволів інструментів і посилання на подію публікації. Маніфест показує, що чинне правило експорту було в іншому документі, якого цей запуск не отримав; він також показує, що агенту дозволили записувати у публічний каталог без перевірки схеми вихідного файлу. У реальному продукті такий маніфест треба спершу перевірити: не кожне середовище зберігає перелік контексту однаково.

Таймлайн і вплив. У цьому вигаданому сценарії всі часові позначки належать до 2026-09-23 і наведені в UTC. О 2026-09-23 02:10 UTC виконання починає експорт із новими полями. О 2026-09-23 02:14 UTC файл потрапляє в обмежене за часом публічне сховище. О 2026-09-23 02:16 UTC незалежна перевірка знаходить заборонене поле й сповіщає чергового. О 2026-09-23 02:18 UTC публічний доступ вимкнено; о 2026-09-23 02:25 UTC команда завершує первинну перевірку журналу доступу. Публічна доступність тривала чотири хвилини. Система зафіксувала три запити до об’єкта; журнал ще звіряють, щоб встановити час, результат і джерело кожного. Тривалість зберігання самого файла після вимкнення публічного доступу окремо не встановлена. Не називайте запити витоками чи безпечними переглядами, поки власник безпеки не звірив аудиторський журнал.

Що вплинуло. Сценарій містив розходження між актуальним правилом і тим контекстом, який отримав запуск. Вихідний файл не мав обов’язкової перевірки дозволених полів. Публікація відбулася до перегляду результату, хоча наслідком була зміна доступності даних. У звіті можна сказати, що агент сформував і передав файл із неприпустимими полями, бо це видно в артефактах. Не можна без доказу стверджувати, що агент «вирішив проігнорувати», «зрозумів ризик» або діяв неуважно. Ми не знаємо намір моделі й не замінюємо технічний запис оповіддю про характер.

Дії й перевірка. Власник експорту переносить допустимі поля до перевірки схеми на межі публікації; критерій — файл із будь-яким невідомим або забороненим полем не може стати публічним. Власник агентного запуску налаштовує явний перелік контексту та запис версії інструкції для кожного виконання; критерій — перевіряльник може відновити, яка ревізія була доступна в конкретній сесії. Власник доступу прибирає автоматичне публічне записування для цього типу операції, доки вихід не пройде схему й людську перевірку. Нарешті команда відтворює той самий випадок на тестовому середовищі й підтверджує, що бар’єр спрацьовує до публікації; потім перевіряє журнал доступу до початкового файлу.

Чому саме так. Агентна модель, інтерфейс командного рядка (Command-Line Interface, CLI), застосунок і серверний runtime — різні речі. Файл інструкції в Git не доводить, що кожен запуск отримав його, а текстова відповідь агента не є доказом того, що його файл опублікували. Тут твердження спираються на сценарний маніфест, журнал доступу та сам артефакт. Коли цього недостатньо: якщо маніфест не записував контекст або журнали доступу неповні, напишіть, що конкретне правило не підтверджено як доступне, а масштаб перегляду невідомий. Уточнюйте джерело, не заповнюйте прогалини впевненим стилем.

Приклад 3. Реальний розбір etcd і ланцюжок від висновку до PR

Ситуація. У звіті розробників etcd від 20 квітня 2022 року описано проблему узгодженості стану в гілці v3.5. Рефакторинг у v3.5.0 дозволяв записати індекс узгодженості так, що він міг випередити застосування відповідного запису із журналу попереднього запису (Write-Ahead Log, WAL — журнал змін, який зберігають до застосування). Якби процес незалежно аварійно зупинився у вузькому проміжку, під час відновлення база могла пропустити запис, вирішивши, що вже застосувала його. У системі з кількома учасниками це могло утворити різні стани; розбір зазначає, що команді не були відомі користувацькі повідомлення про реальне пошкодження даних у production. Вона називає довіру до надійності основним наслідком для спільноти, а не стверджує доведену масову втрату даних. Першоджерело: etcd v3.5 data inconsistency postmortem

Що звіт вважає чинниками. Причинний опис розділяє небезпечну зміну індексу й момент аварії. Окремо автори перелічують слабку перевірку узгодженості для повільних учасників та ущільнення журналу, недостатньо підтримувані й нестабільні функціональні тести, ручну кваліфікацію випуску, яка більше не була загальновідомою, і складність коду застосування змін. Це не синоніми «помилка рефакторингу»: одні чинники пояснюють дефект, інші — чому його було складно виявити, відтворити й безпечно виключити перед випуском.

Часова обережність. У таблиці подій самого постмортему один користувацький звіт для issue #13654 датований 28 січня 2021 року, хоча його поставлено після грудневого повідомлення 2021 року. GitHub показує, що issue створили 28 січня 2022 року; її опис повідомляє про неузгодженість revision у production, але не підтверджує пошкодження даних. Формулювання «звіт про пошкодження даних» у таймлайні постмортему сильніше за зміст цього issue; сам постмортем окремо каже, що авторам не були відомі користувацькі повідомлення про підтверджене пошкодження даних у production. Є й друга розбіжність: таймлайн постмортему датований 20 квітня зазначає, що v3.5.3 випущено 24 квітня, тоді як офіційна сторінка релізу показує 13 квітня 2022 року. У навчальному звіті треба показати обидві суперечності й відокремити повідомлений симптом від підтвердженого пошкодження; не копіювати жодну з дат мовчки. etcd issue #13654; etcd v3.5.3 release notes

Дії й подальший результат. У постмортемі це дві окремі дії. P0 пропонує відтворювати історичні неузгодженості; issue #14045 розбиває цю роботу на конкретні сценарії відтворення. Окремо P1 вимагає безперервної кваліфікації випусків. PR #14911, змерджений 7 грудня 2022 року, реалізує саме підпункт про нічний тривалий запуск тестів лінеаризовності: він прямо посилається на #14045, але не є доказом, що сам по собі додав історичний регресійний відтворювач. Спершу розклад охоплював лише головну гілку; в обговоренні також піднімали питання тривалості запуску й обсягу тестів. Так можна простежити окремий ланцюжок «висновок → відстежувана дія → зміна в репозиторії». Факт злиття PR не доводить, що покрито всі гілки або що інцидентний ризик зник. Для твердження про ефект треба окремо перевірити поточну конфігурацію, стабільність і результати цього запуску, а також подальші звіти про події. etcd issue #14045; etcd PR #14911

Реліз v3.5.3 оголосив виправлення критичних помилок коректності, які могли призвести до незастосування зафіксованої транзакції на всіх репліках після аварії сервера. Це підтверджує конкретний релізний результат, а не твердження, що після нього більше ніколи не могло бути проблем із узгодженістю даних. etcd v3.5.3 release notes

Чому це корисний приклад. Первинний звіт дає технічний механізм, межі впливу, рівень невідомого, недоліки виявлення й конкретні дії. Історія issue/PR дає незалежнішу перевірку, що принаймні частину плану справді реалізували та обговорили її ризики. Але це кейс конкретного розподіленого сховища, а не шаблон усіх інцидентів і не причинне дослідження, яке доводить ефективність усіх follow-up дій. Технічні деталі etcd, статуси задач і поведінка його тестів могли змінитися; їх перевірено 24 вересня 2026 року.

64.8. Що має бути в готовому звіті

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

1. Короткий підсумок: що сталося й що вже зроблено для обмеження шкоди.
2. Вплив: користувачі, функції, дані, інтервал, відомі межі та невідоме.
3. Хронологія: подія, виявлення, рішення, дія, результат і час запису.
4. Передумови й механізм: потрібні поняття, версії та взаємодія компонентів.
5. Причини, тригер і супутні чинники: кожне твердження прив’язане до доказу або позначене як гіпотеза.
6. Виявлення: сигнал, прогалина, затримка й перший надійний спосіб побачити вплив.
7. Відновлення: що спрацювало, що затримало, залишковий ризик і побічний ефект.
8. Що допомогло, що завадило й де пощастило: без драматизації, з конкретною підставою.
9. Дії: власники, пріоритет, критерії приймання й ефективності, зв’язок із ризиком.
10. Комунікація: кому вже повідомили, які дані приватні, хто має ухвалити зовнішній текст.
11. Перевірка після змін: дата, метод, фактичний результат і питання, що лишилися.

Рецензент може пройти короткий контрольний список: чи видно, що саме зачепило користувачів? Чи відокремлено факт від оцінки? Чи видно, що учасники знали на час рішення? Чи звірено час із зоною? Чи аналізують і виявлення, і відновлення? Чи не закінчується пояснення особистою помилкою? Чи має кожна важлива дія власника й критерій? Чи є прямий доказ її виконання? Чи перевірено зниження ризику окремо від закриття issue? Якщо відповідь «ні», додайте обмеження або дію; не маскуйте прогалину красивим висновком.

Підсумок. Якісний postmortem — це перевірювана модель того, як умови системи призвели до впливу, як люди побачили й обмежили його, і що зміниться далі. Беззвинувачувальний тон допомагає дістати точнішу інформацію, але не скасовує власника й виконання змін. Кількість написаних звітів або закритих задач не доводить зменшення ризику: дія має пройти власний критерій приймання та перевірку ефекту.

Джерела та подальше читання

• Google Site Reliability Engineering, John Lunney та Sue Lueder, Postmortem Culture: Learning from Failure, Site Reliability Engineering, розділ 15. Джерело для визначення postmortem, цілей, типових тригерів, беззвинувачувального аналізу, пріоритетних дій і поширення уроків. Сторінка не показує дату оновлення; доступ: 24 вересня 2026 року. Відкрити розділ
• Google Site Reliability Engineering, Daniel Rogers та ін., Postmortem Practices for Incident Management, The Site Reliability Workbook, розділ 10. Розгорнутий приклад звіту й відмінності між слабким і перевірюваним аналізом. Сторінка не показує дату оновлення; доступ: 24 вересня 2026 року. Відкрити розділ
• etcd-io, v3.5 data inconsistency postmortem, автор serathius, датований 20 квітня 2022 року. Первинний технічний опис механізму, впливу, меж виявлення, actions і timeline; факти в главі обмежені формулюваннями самого звіту. Перевірено: 24 вересня 2026 року. Відкрити звіт
• etcd-io, Introduce etcd robustness tests, issue #14045, відкрито 16 травня 2022 року. Перелік містить окремі підпункти для регресійного відтворення історичних неузгодженостей та для безперервної кваліфікації випусків. Перевірено: 24 вересня 2026 року. Відкрити issue
• etcd-io, Create a nightly job for linearizability tests, PR #14911, змерджений 7 грудня 2022 року. Приклад реалізованої подальшої зміни й обговорення меж частоти та охоплення; сам факт merge не є доказом повного усунення ризику. Перевірено: 24 вересня 2026 року. Відкрити PR
• etcd-io, etcd revision occurs Inconsistent, issue #13654, відкрита 28 січня 2022 року. Її опис повідомляє про неузгодженість revision у production, не встановлюючи підтверджене пошкодження даних. Використано для звірки дати й меж твердження в хронології postmortem. Перевірено: 24 вересня 2026 року. Відкрити issue
• etcd-io, Release v3.5.3, офіційна сторінка GitHub показує дату 13 квітня 2022 року; таймлайн постмортему від 20 квітня вказує 24 квітня, тож джерела суперечать одне одному. Release notes заявляють про виправлення критичних проблем коректності, які могли призвести до незастосування committed transaction після аварії сервера; це не твердження про відсутність будь-яких майбутніх дефектів. Перевірено: 24 вересня 2026 року. Відкрити release notes
• Tom DeMarco та Tim Lister, Peopleware: Productive Projects and Teams, 3-тє видання, Addison-Wesley Professional, 2013/2014. Сторінка видавця для бібліографічних даних і структури; безкоштовний уривок розділу 10 використано для обмеженого зв’язку між перериваннями та зосередженою роботою. Повний текст не переглядався. Доступ: 24 вересня 2026 року. Сторінка Pearson; уривок Pearson
• Nicole Forsgren, Jez Humble та Gene Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution, 2018. Сторінка видавця підтверджує авторство, дослідницьку основу та публікаційні дані. Книжку повністю не переглядав; актуальні твердження про п’ятиметричну модель перевірялися за DORA. Доступ: 24 вересня 2026 року. Сторінка видавця
• DORA, Learning culture та Generative organizational culture. Актуальні пояснення зв’язку навчання, відкритого потоку інформації та практик розбору; подано як узагальнення досліджень, не як гарантію причинності в окремому випадку. Доступ: 24 вересня 2026 року. Learning culture; Generative organizational culture
• DORA, DORA’s software delivery performance metrics. Актуальна п’ятиметрична модель, контекст застосування та застереження щодо цілей і порівняння різних систем. Доступ: 24 вересня 2026 року. Відкрити настанову
• Anthropic, How Claude remembers your project, офіційна документація Claude Code. Підтримує лише твердження про документацію проєктних інструкцій у Claude Code; не доводить доступність конкретного файлу в окремій сесії. Перевірено: 24 вересня 2026 року. Відкрити документацію
• OpenAI, Custom instructions with AGENTS.md, офіційна документація Codex. Джерело про механізм інструкцій Codex; його поведінку не переносимо на інші агенти. Перевірено: 24 вересня 2026 року. Відкрити документацію
• OpenAI, Safety best practices, документація OpenAI API. Використано як обмежену рекомендацію для застосунків на OpenAI API щодо перевірки результатів із важливими наслідками; це не продуктова гарантія й не інструкція для Codex або Claude Code. Перевірено: 24 вересня 2026 року. Відкрити настанову