Postmortem інциденту — це не звіт про провал, а інструмент перевірки гіпотез про те, як працює система на межі своїх обмежень. Якщо ви читаєте або пишете такий документ, ваша мета — зрозуміти ланцюжок подій, відрізнити безпосередній збой від структурної вразливості та оцінити, чи призвели висновки до реальних змін. Нижче — методологія, яка працює незалежно від конкретної мережі.
Структура postmortem: хронологія, причини, наслідки
Якісний postmortem будується навколо трьох стовпів, кожен із яких має власну логіку перевірки.
Хронологія. Це не перелік подій із часовими мітками, а відновлена послідовність станів системи. Кожен крок має відповідати на питання: «Що саме змінилося в системі між попереднім і поточним станом?». Корисний критерій якості хронології — можливість програти її механічно, без залучення авторів. Якщо для розуміння події потрібно знати, «що розробник мав на увазі», хронологія недороблена.
Причини. Тут важливо розділяти безпосередній тригер (наприклад, аномальний спам транзакцій) і фактори, які перетворили тригер на інцидент (відсутність пріоритезації черги, недостатній моніторинг навантаження на конкретний модуль). Одна з найпоширеніших помилок — зупинятися на тригері й не заглиблюватися в фактори.
Наслідки. Оцінка впливу має бути конкретною: тривалість недоступності, діапазон уражених вузлів, обсяг скасованих транзакцій, вплив на залежні сервіси. Уникайте формулювань на кшталт «система працювала нестабільно» — вони не дозволяють порівняти інциденти між собою чи оцінити ефективність реагування.
Як відрізнити технічну причину від системної
Це ключове розрізнення, яке визначає, чи буде postmortem корисним за межами поточного інциденту.
Технічна причина пов’язана з конкретною реалізацією: помилка в коді консенсусу, некоректна обробка крайового випадку в сериалізації, перевищення ліміту пам’яті в конкретному модулі. Виправлення технічної причини зазвичай має форму патчу з чітко визначеною областю застосування.
Системна причина стосується процесів, архітектурних рішень або організаційних угод, які зробили технічний збій можливим або значущим. Наприклад: відсутність інтеграційного тестування для сценарію масового відхилення транзакцій; розподіл відповідальності між командами без чіткої зони перетину; архітектурне рішення, яке зменшує ізоляцію між підсистемами.
Практичний критерій: якщо виправлення вимагає зміни не лише коду, а й процесу тестування, моніторингу, комунікації або архітектурного принципу — ви маєте справу зі системною причиною. І саме ці причини визначають, чи повториться подібний інцидент в іншій формі.
Реакція мережі: час відновлення, комунікація
Оцінка реакції на інцидент вимагає окремої уваги, оскільки вона часто розмивається в postmortem на користь технічного розбору.
Час відновлення (MTTR). Сам по собі цей показник мало що каже. Корисніше розбити його на компоненти: час від початку аномалії до першого сигналу (час виявлення), час від сигналу до початку діагностики, час діагностики, час впровадження виправлення, час поширення виправлення по мережі. Кожен компонент вказує на своє вузьке місце.
Комунікація. Оцінюйте за трьома критеріями: своєчасність (чи були попередні сигнали до повної зупинки), точність (чи не створювали оновлення статусу хибного враження про стан справ) і структура (чи було зрозуміло, що саме порушено й які дії очікуються від учасників мережі). Типовий дефект — комунікація, яка описує дії команди («ми працюємо над вирішенням») замість стану системи («транзакції не обробляються, консенсус зупинений»).
Уроки та зміни після інциденту
Цей розділ — найслабший ланка більшості postmortem. Перевірте його за кількома критеріями.
Конкретність. «Покращити моніторинг» — не урок, це побажання. Урок звучить так: «Додати алерти на зростання черги невалідних транзакцій у модулі X із порогом Y і каналом сповіщення Z».
Відстежуваність. Кожен урок має бути прив’язаний до конкретного таска, PR або коміту. Якщо postmortem містить уроки без прив’язки до артефактів розробки, є високий ризик, що вони залишаться на папері.
Перевірка ефективності. Найцінніша частина — опис того, як буде перевірено, що зміна працює. Це може бути симуляція навантаження, хаос-тест або конкретний метрик моніторингу, який мав би спрацювати під час попереднього інциденту.
Щоб перевірити реальність змін після інциденту в Solana, звертайтеся до офіційних репозиторіїв на GitHub і звітів інженерних команд — саме там фіксуються конкретні зміни, а не лише декларації.
Типові помилки в аналізі postmortem
- Єдина причина. Пошук «того самого бага» замість аналізу ланцюжка факторів. Складні інциденти рідко мають єдину причину — зазвичай це збіг кількох умов, кожна з яких недостатня для інциденту окремо.
- Кореляція замість причинності. «Після оновлення версії стався збій» не означає «збій стався через оновлення». Потрібна механічна зв’язок: який саме шлях виконання змінився й як це призвело до спостережуваної поведінки.
- Ігнорування near-miss. Інциденти, які «майже сталися» але були локалізовані, часто не розбираються. Проте вони містять ту саму інформацію про вразливості, але без ціни простою.
- Аналіз без контексту навантаження. Опис збою без вказування рівня навантаження на мережу в момент інциденту робить висновки неповними. Система може бути стабільною при звичайному навантаженні й вразливою при піковому — це різні проблеми з різними рішеннями.
- Змішування опису інциденту з його оцінкою. Хронологія має бути нейтральною. Оцінка («це було помилкою», «це було неадекватним») належить до окремого розділу й має спиратися на раніше визначені критерії.
Межі: не звинувачення, а навчання
Принцип «безвинуватного» postmortem (blameless postmortem) часто розуміють неправильно — як відмову від відповідальності. Насправді це методологічне обмеження: фокус аналізу спрямовується на умови, за яких помилка стала можливою, а не на те, хто її зробив.
Практична межа: якщо ви можете видалити імена конкретних людей з postmortem без втрати змісту — документ ймовірно побудований правильно. Якщо ж після видалення імен текст втрачає сенс, це сигнал, що аналіз зійшов на особистий рівень.
Це не означає, що індивідуальна відповідальність не існує. Вона існує, але вирішується в інших процесах — перформанс-оглядах, зміні процесів доступу, перерозподілі зон відповідальності. Postmortem служить іншій меті: зробити систему стійкішою незалежно від того, хто конкретно буде в ній працювати завтра.
Читати postmortem варто як інженерний текст: із скепсисом до пояснень, що зводять інцидент до однієї причини, увагою до невидимих процесів і очікуванням конкретних артефактів змін. Саме такий підхід дозволяє витягти з кожного інциденту максимум користі для розуміння мережі.