После одного инцидента на работе, один из моих сотрудников задал вопрос: “Нафига мы вообще сейчас роемся во всех логах? Мы же отремонтировали все.” Его вопрос ввел меня в ступор. Мне показалось что это просто очевидная-очевидность, что “Это база! Это знать надо!”. Но оказалось со стороны взгляда джуна, мы вместо того что бы работать уже пол дня сидим и разбираем каждый лог и лезем во все щели. После того как моя оторопелость прошла, я крепко задумался над тем как же мне объяснить что мы делаем и зачем это нужно. Сейчас будут мои размышления о Postmortem в айтишке.
Проведение Postmortem (или же Post-Incident Review) — это супер важный этап управления инцидентами, который ни что иное как возможность для улучшения системы. Если просто “потушить пожар” и забыть, есть риск столкнуться с той же проблемой снова, но уже с большими потерями.
Почему это необходимо:
- Предотвращение рецидивов
Obviously huh? Postmortem позволяет докопаться до коренной причины (Root Cause) инцидента. Часто то, что кажется причиной (например, “сервер упал”), является лишь симптомом. Настоящая причина может крыться в ошибке конфигурации, логике кода или недостатке ресурсов. Устранив корень проблемы, можно почти гарантировать, что именно этот сценарий больше не повторится. - Улучшение мониторинга и снижение времени простоя
Анализ показывает не только то, почему все сломалось, но и как мы на это отреагировали.
MTTD (Mean Time To Detect): Как быстро мы узнали о проблеме? Если о сбое сообщили пользователи, а не мониторинг, значит, ваши аллерты настроеныхерово и через жопуневерно.
MTTR (Mean Time To Recovery): Как быстро мы все починили? Postmortem помогает найти инструменты или инструкции, которых не хватало для более быстрого восстановления (А еще дает точку для давления на начальство что бы выделили бюджеты). - Обмен знаниями и обучение команды
В сложных системах один человек редко знает всё, а если он говорит что знает все то скорее всего онпизЛукавит. Инцидент часто вскрывает “серые зоны” в архитектуре. Документирование инцидента помогает передать опыт всей команде, чтобы в следующий раз любой инженер знал, куда смотреть. Это снижает зависимость от конкретных “героев”, которые единственные знают, как чинить ту или иную подсистему. - Культура без вины (Blameless Culture)
Эффективный Postmortem должен быть Blameless (без поиска виноватых!!!). Если целью разбора является наказание сотрудника, люди начнут скрывать ошибки. Если же цель — улучшить процесс, люди будут открыто говорить о том, что пошло не так (например, “я нажал кнопку, потому что инструкция была неясной”). Это позволяет чинить процессы, а не людей. В целом я активный противник идеологии “НАЙТИ И НАКАЗАТТ!”. Все мы люди, и никто не застрахован от ошибок. Скрывать свои ошибки в современном мире бессмысленно и бесполезно, а вот учится на них это единственно верное действие. - Приоритизация технического долга
Бизнес часто требует новых фич, отодвигая рефакторинг на второй план. Postmortem дает вам фактические данные (потери денег, времени, репутации), которые можно использовать как аргумент для выделения времени и бюджетов на устранение технического долга и повышение стабильности.
Вывод
Без Postmortem-а мы обречены наступать на одни и те же грабли. С ним — каждый сбой делает вашу инфраструктуру надежнее. Ведь что нас не убивает, делает нас нервознее сильнее!
Добавить комментарий