Культура написания постмортемов и диванная аналитика факаповDevOps-трансформация
С 2008 года программировал в Яндексе (Пробки, спортивные спецпроекты, тимлид бэкенда Такси). С 2014 года занимается DevOps и инфраструктурой в Контуре — делает инструменты, которые облегчают жизнь разработчиков.
Во времена, когда умами людей впервые завладело слово DevOps, лидеры движения писали основополагающие тексты. Джин Ким писал «Проект Феникс», Джез Хамбл — книгу «Continuous Delivery», а John Allspaw — статьи в блог Code as Craft. Они объясняли нам, как правильно устроить процесс разработки, доставки кода в продакшн и мониторинга. Мне особенно запомнилась статья «Blameless PostMortems and a Just Culture» (https://codeascraft.com/2012/05/22/blameless-postmortems/).
Спустя 6 лет её начало звучит очень естественно:
Anyone who’s worked with technology at any scale is familiar with failure. [...] failure happens. This is a foregone conclusion when working with complex systems. But what about those failures that have resulted due to the actions (or lack of action, in some cases) of individuals? What do you do with those careless humans who caused everyone to have a bad day? Maybe they should be fired. Or maybe they need to be prevented from touching the dangerous bits again. [...] We don’t take this traditional view at Etsy. We instead want to view mistakes, errors, slips, lapses, etc. with a perspective of learning. Having blameless Post-Mortems on outages and accidents are part of that.
...но тогда для меня это было откровением. Из статьи было очевидно, какую пользу несут постмортемы. Но в статье не было ни слова о том, как убедить разработчиков в своей команде их писать.
Как удалось внедрить культуру написания постмортемов в Контуре. Как за несколько лет было написано 600 с лишним отчетов об инцидентах, больших и маленьких? И, самое главное, получилось ли у нас извлечь пользу из этой практики?