Blameless culture: как перестать искать виноватых и начать чинить системы
На этой неделе обзора книги не будет, потому что я ещё не успел её дочитать (там почти 600 страниц по AI-инженерии, не самое лёгкое чтиво). Поэтому я решил поделиться подборкой материалов, которые накопал в своём недавнем рабочем процессе.
Передо мной стояла задача — запустить процесс Post Mortem. Для этого нужно было собрать небольшой гайд и шаблон, чтобы коллегам было проще стартовать. Для этого я прочитал и просмотрел кучу материалов. Делюсь теми, которые показались мне самыми полезными.
⭐️
https://youtu.be/HwZ7Pkr13XI
Очень хороший, добрый и местами пропитанный личной болью доклад моего дружочка-пирожочка Андрея. Послушать стоит, потому что этот человек ворочал огромными и крайне сложными инфраструктурами, в которых всегда что-то ломается.
Доклад не про сами post mortem, а про безобвинительную культуру, которая является фундаментом. Если на post mortem искать виноватых и раздавать наказания, то работать они не будут никогда.
➡️ Интересные идеи
🟡В больших системах всегда что-то ломается. Это их суть: сложные распределённые системы не могут работать без ошибок, и это нормально. Post Mortem нужны для того, чтобы больше узнавать о своей системе и делать её надёжнее.
🟡Виноваты процессы, а не люди. Если человек (даже сознательно) смог что-то критически сломать — это процессная проблема. Но чаще всего сбой вызывается непреднамеренным действием и раскрывает одно из слабых мест системы. Поэтому ругать людей бесполезно.
🟡Action Items с post mortem пробивают все бэклоги и имеют критический приоритет. Для команды инфраструктуры, от которой зависит целый огромный бизнес, такой подход — норма. Для обычных команд разработки некоторые action items могут быть менее приоритетными. Тем не менее кто-то должен следить за тем, чтобы они были выполнены.
⭐️ https://leaddev.com/reporting/how-run-great-software-incident-post-mortem
How-to по blameless culture — отличное продолжение предыдущего доклада. Автор по сути даёт простой фреймворк обсуждения на post mortem без поиска виноватых и взаимных обвинений.
Мне понравился подход «второй истории»: сначала говорим про очевидные ошибки, а потом закапываемся в системные штуки, которые эту ошибку допустили. Это позволяет копать глубже, чем просто «давайте ещё один алерт повесим».
⭐️ https://sre.google/sre-book/postmortem-culture/
Шикарная статья от Google о их философии проведения post mortem. В ней чётко видно, что организация использует post mortem для исправления ошибок и взаимного обучения (например, есть рубрика «post mortem месяца», в которой раз в месяц хорошо написанный документ распространяется на всю организацию).
Статья скорее предназначена для формирования правильного отношения к post mortem. Тем не менее она будет очень полезна на старте и даёт пачку классных идей для дальнейшего развития культуры.
Также у Google есть отличный https://sre.google/sre-book/example-postmortem/.
⭐️ https://www.atlassian.com/incident-management/handbook/postmortems#what-is-post-mortem
В целом handbook по управлению инцидентами от Atlassian очень крут, и в нём много чего полезного. Конкретно эта статья — прекрасная методичка того, как проводить post mortem. Она даёт ответы на конкретные вопросы: кто, что, где, как и так далее. В том числе в ней содержится довольно хороший (хоть и объёмный) шаблон post mortem, который можно использовать в своих проектах.
Для меня были особенно ценны примеры проведения анализа корневых причин инцидента. Atlassian используют метод «5 почему», и, судя по всему, он им помогает.
Всем желаю blameless post mortem и стабильных систем!
// Поделитесь, пожалуйста, в комментариях, как вам такой формат?
