“Быстро поднятое упавшим не считается”: как мы строили работу с техническими инцидентами Подходы к измерению инженерных экспериментов
У нас было 30 команд, все пилили свои сервисы — иногда они падали, цепляли друг друга по пути … “Быстро поднятое упавшим не считается”, — слышали мы и продолжали падать снова. Мы не знали, сколько денег теряем, и надеялись, что “виновные” сами разберутся в Slack.
В начале 2020-го мы стали собирать статистику по инцидентам. Столкнулись с кучей проблем по ходу внедрения общего процесса работы с ними. И уже смогли найти и исправить несколько системных проблем с важными для бизнеса сервисами. Я хочу рассказать про этот опыт:
- как мотивируем команды не хоронить инциденты в чатах, а фиксировать их. И какой лайфхак используем, если команды не хотят “выносить сор из избы”;
- как мы проводим анализ инцидентов, чтобы точечно “отлавливать” системные ошибки, решение которых принесет максимальную пользу;
- и какие результаты это приносит.
Мог бы быть продактом, но Dev Unit Lead.
На данный момент руковожу командами разработки маркетинга и продаж (конверсия в заявку, конверсия в оплату, прозвон клиентов, системы аналитики, журнал).
В разработке более 12 лет. За это время поработал не только в разных компаниях, но и в разных странах, что дало возможность впитать в себя их культуру и подходы к организации разработки.
Сейчас я применяю свой накопленный опыт для построения эффективных и прозрачных процессов в Skyeng.
https://t.me/kuznetsovdy
https://facebook.com/kuznetsovdy