Честно говоря, Иван часто посмеивался над тщетными усилиями коллег из отдела мониторинга. Они прилагали огромные усилия для реализации метрик, которые им заказывало руководство компании. Они были настолько заняты, что больше никому ничего не хотели делать.
А руководству всё было мало – оно постоянно заказывало всё новые и новые метрики, очень быстро переставая пользоваться тем, что были сделаны ранее.
Последнее время все только и говорили про LeadTime – время поставки бизнесовых фич. Метрика показала сумасшедшее число – 200 дней на поставку одной задачи. Как же все охали, ахали и воздевали руки к небу!
Через некоторое время шум постепенно затих и от руководства поступил заказ на создание еще одной метрики.
Ивану было совершенно понятно, что и новая метрика точно также тихонько помрёт в тёмном уголке.
Действительно, размышлял Иван, знание числа совершенно никому ни о чём не говорит. 200 дней или 2 дня – нет никакой разницы, потому что по числу невозможно определить причину и понять, хорошо это или плохо.
Это типичная ловушка метрик: кажется, что новая метрика расскажет суть бытия и объяснит какой-то тайный секрет. Все так на это надеются, но ничего почему-то не происходит. Да потому что секрет надо искать вовсе не в метриках!
Для Ивана это был пройденный этап. Он понимал, что
метрики – это просто обычная деревянная линейка для измерений, а все секреты надо искать в
объекте влияния, т.е. в том, что эту метрику формирует.
Для интернет-магазина объектом влияния будут его клиенты, приносящие деньги, а для DevOps – команды, создающие и раскатывающие дистрибутивы с использованием конвейера.
Однажды, устроившись в холле в удобном кресле Иван решил как следует продумать как бы он хотел видеть метрики DevOps с учётом того, что объектом влияния являются команды.
Цель метрик DevOps
Понятно, что всем хочется уменьшить время поставки. 200 дней – это, конечно, никуда не годится.
Но как, вот в чем вопрос?
