Більшість постмортемів — це археологія: точний запис того, що ніхто не змінить. Корисний дає невелику кількість речей, які справді робляться.
Мета постмортему — не задокументувати те, що сталося. Мета — зробити наступний інцидент менш імовірним або менш руйнівним. Усе в документі має цьому служити, а те, що не служить, — це церемонія.
Без винних — це механізм, а не манера
Постмортеми без винних часто пояснюють як прояв доброти. Це їх недооцінює. Вони існують тому, що люди, які очікують звинувачень, приховують інформацію — і саме прихована інформація запобігла б повторенню.
Структура, яка працює
- Резюме — три речення: що зламалося, на скільки, кого зачепило. Більшість читачів зупиняється тут, тож воно має бути самодостатнім.
- Вплив — тривалість, зачеплені користувачі, наслідки для виручки чи даних, у цифрах де можливо
- Хронологія — факти з мітками часу, від першого симптому до вирішення, включно з моментом, коли люди дізналися
- Сприятливі чинники — у множині й чесно про процесні, а не лише про технічний тригер
- Що спрацювало добре — справді корисно, щоб підсилити виявлення чи реакцію, які спрацювали
- Дії — кожна з власником і датою
Першопричина зазвичай є історією, а не рядком
«Розгортання спричинило падіння» — місце, де аналіз зупиняється, коли зустріч поспішає. Справжні чинники зазвичай виглядають так:
| Шар | Приклад знахідки |
|---|---|
| Тригер | Було розгорнуто зміну конфігурації |
| Чому зламалося | Зміна була синтаксично правильна, але семантично хибна |
| Чому ніщо це не спіймало | Жодне staging-середовище не відповідало продакшн-конфігурації |
| Чому помітили аж за 40 хвилин | Алерти стежили за CPU, а не за успішністю оплат |
| Чому відновлення було повільним | Відкат ніколи не тестували для змін тільки конфігурації |
Чотири з цих п'яти — процесні проблеми. Виправте лише тригер, і той самий клас інцидентів повернеться в іншому вбранні.
Дії: частина, що вирішує, чи мало це все сенс
- Максимум три-п'ять пунктів — список із двадцяти це список із нуля
- Кожен з іменним власником, а не з командою
- Кожен із датою, у тій самій системі, що й звичайна робота
- Віддавайте перевагу пунктам, які прибирають цілий клас відмов (запобіжник), а не одиничний випадок
- Перегляньте їх на наступному постмортемі — незакриті пункти з минулого разу є найважливішим питанням порядку денного
Постмортем без жодної завершеної дії до наступного інциденту — це не процес. Це звичка підшивати папери.
Час і аудиторія
- Чернетка протягом 48 годин — точність швидко втрачається
- Зустріч на 30-45 хвилин, не довше; більшу частину роботи виконує документ
- Запросіть усіх причетних плюс одну людину, якої там не було (вона ставить очевидні питання, що їх пропускають свої)
- Поширюйте широко — внутрішня прозорість щодо невдач і є тим, як організації в цьому вдосконалюються
Перевіряйте виконання профілактичних дій
Postmortem має змінювати контроль або рішення. Кожна дія потребує доказу завершення, а не лише дедлайну.
- Розділіть факти, гіпотези й супутні умови.
- Пов'яжіть дію з механізмом збою, який вона усуває.
- Підтвердіть результат тестом, перевіркою алерту або відновленням.
Часті запитання
Як скоро після інциденту має бути постмортем?
Чернетка протягом 48 годин, зустріч протягом тижня. Пам'ять про точну послідовність і міркування швидко тьмяніє, а найважливіші деталі — у що людина вірила на той момент і чому — зникають першими.
Що на практиці робить постмортем без винних?
Питання про те, як система дозволила відмову, а не хто її спричинив. На практиці: жодних імен біля помилок у документі, питання про механізми замість рішень і дії, що додають запобіжники, замість прохань бути уважнішими.
Скільки дій має дати постмортем?
Три-п'ять, кожна з іменним власником і датою. Довші списки — надійна ознака того, що нічого не буде зроблено, а незакриті пункти мають бути першим питанням наступного перегляду.
Коли дія з postmortem вважається завершеною?
Коли погоджений результат надано й перевірено. Закрита задача чи оновлений документ самі по собі не доводять зміни поведінки системи.
Інциденти повторюються?
Це проблема процесу, а не невдачі. Ми аудитуємо практику доставки та інцидентів і лагодимо механізм.
Читати далі за темою
Як діяти під час падіння продакшену: плейбук для малих команд
Під час падіння технічна проблема рідко є складною частиною. Складна — координація. Ось послідовність, яка не дає малій команді зробити гірше.
Аудит інженерних процесів: на що ми дивимося і чому
Коли команда доставляє повільно, причина майже ніколи не в інженерах. Зазвичай це чотири-п'ять конкретних тертя, яких ніхто не виміряв.