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