Постмортем: як написати той, який справді читають

·7 хв читання

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

Мета постмортему — не задокументувати те, що сталося. Мета — зробити наступний інцидент менш імовірним або менш руйнівним. Усе в документі має цьому служити, а те, що не служить, — це церемонія.

Без винних — це механізм, а не манера

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

Структура, яка працює

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

Першопричина зазвичай є історією, а не рядком

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

ШарПриклад знахідки
ТригерБуло розгорнуто зміну конфігурації
Чому зламалосяЗміна була синтаксично правильна, але семантично хибна
Чому ніщо це не спіймалоЖодне staging-середовище не відповідало продакшн-конфігурації
Чому помітили аж за 40 хвилинАлерти стежили за CPU, а не за успішністю оплат
Чому відновлення було повільнимВідкат ніколи не тестували для змін тільки конфігурації

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

Дії: частина, що вирішує, чи мало це все сенс

  • Максимум три-п'ять пунктів — список із двадцяти це список із нуля
  • Кожен з іменним власником, а не з командою
  • Кожен із датою, у тій самій системі, що й звичайна робота
  • Віддавайте перевагу пунктам, які прибирають цілий клас відмов (запобіжник), а не одиничний випадок
  • Перегляньте їх на наступному постмортемі — незакриті пункти з минулого разу є найважливішим питанням порядку денного
Постмортем без жодної завершеної дії до наступного інциденту — це не процес. Це звичка підшивати папери.

Час і аудиторія

  • Чернетка протягом 48 годин — точність швидко втрачається
  • Зустріч на 30-45 хвилин, не довше; більшу частину роботи виконує документ
  • Запросіть усіх причетних плюс одну людину, якої там не було (вона ставить очевидні питання, що їх пропускають свої)
  • Поширюйте широко — внутрішня прозорість щодо невдач і є тим, як організації в цьому вдосконалюються

Перевіряйте виконання профілактичних дій

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

  1. Розділіть факти, гіпотези й супутні умови.
  2. Пов'яжіть дію з механізмом збою, який вона усуває.
  3. Підтвердіть результат тестом, перевіркою алерту або відновленням.

Часті запитання

Як скоро після інциденту має бути постмортем?

Чернетка протягом 48 годин, зустріч протягом тижня. Пам'ять про точну послідовність і міркування швидко тьмяніє, а найважливіші деталі — у що людина вірила на той момент і чому — зникають першими.

Що на практиці робить постмортем без винних?

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

Скільки дій має дати постмортем?

Три-п'ять, кожна з іменним власником і датою. Довші списки — надійна ознака того, що нічого не буде зроблено, а незакриті пункти мають бути першим питанням наступного перегляду.

Коли дія з postmortem вважається завершеною?

Коли погоджений результат надано й перевірено. Закрита задача чи оновлений документ самі по собі не доводять зміни поведінки системи.

Інциденти повторюються?

Це проблема процесу, а не невдачі. Ми аудитуємо практику доставки та інцидентів і лагодимо механізм.

Інженерія процесів →

Читати далі за темою

Як діяти під час падіння продакшену: плейбук для малих команд

Під час падіння технічна проблема рідко є складною частиною. Складна — координація. Ось послідовність, яка не дає малій команді зробити гірше.

Аудит інженерних процесів: на що ми дивимося і чому

Коли команда доставляє повільно, причина майже ніколи не в інженерах. Зазвичай це чотири-п'ять конкретних тертя, яких ніхто не виміряв.