Прошла неделя с тех пор как Иван в первый раз задумался над метриками DevOps и понял, что управлять с их помощью надо временем поставки продукта (Time-To-Market).
Даже на выходных он думал про метрики: «Ну и что, что я измерю время? Что оно мне даст?»
Действительно, что даст знание времени? Допустим, поставка занимает 5 дней. И что дальше? Это хорошо или плохо? Даже если это плохо, то нужно же как-то уменьшать это время. Но как?
Эти мысли не давали ему покоя, но решение не приходило.
Иван понимал, что подошёл к самой сути. Бесчисленные графики метрик, виденные им до этого, давно убедили его, что стандартный подход не сработает, и что если просто построить график (пусть даже когортный), толку от него будет ноль.
Как же быть?...
Метрика — это как обычная деревянная линейка. Измерения, сделанные с её помощью, не скажут причину, почему измеряемый предмет именно той длины, которую она показал. Линейка просто покажет его размер, и не более. Она не философский камень, а просто деревянная доска, которой измеряют.
«Крыса из нержавеющей стали» его любимого писателя Гарри Гаррисона всегда говорила: мысль должна достичь дна мозга и там отлежаться, поэтому безрезультатно промучившись несколько дней Иван решил заняться другой задачей…
Через пару дней, читая статью про интернет-магазины, Иван вдруг понял, что величина денег, которую получает интернет-магазин, зависит от того как ведут себя посетителя сайта. Именно они, посетители/клиенты, отдают магазину свои деньги и являются их источником. На итоговую величину денежных средств, получаемых магазином, влияют изменения в поведении клиентов, а ни что-то иное.
Получалось, что для изменения измеряемой величины нужно было влиять на тех, кто это значение формирует, т.е. для изменения количества денег интернет-магазина надо было влиять на поведение клиентов этого магазина, а для изменения времени поставки в DevOps надо было влиять на команды, которые это время «создают», т.е. используют DevOps в своей работе.
Иван понял, что метрики DevOps должны представлять вовсе не графики. Они должны представлять из себя инструмент поиска «выдающихся» команд, формирующих итоговое время поставки.
Никакая метрика никогда не покажет причину, почему та или иная команда долго поставляла дистрибутив, думал Иван, ведь в реальности причин может быть миллион и маленькая тележка, и они вполне могут быть не техническими, а организационными. Т.е. максимум, что можно рассчитывать получить от метрик – это показ команд и их результатов, а затем всё равно придётся в эти команды идти ногами и выяснять, что у них стряслось.
С другой стороны, в компании Ивана существовал стандарт, обязывающий все команды проверять сборки на нескольких стендах. Команда не могла перейти на следующий стенд до тех пор, пока не будет пройден предыдущий. Получалось, что если представить процесс DevOps как последовательность прохождения стендов, то метрики могли бы показывать время, затрачиваемое командами на этих стендах. Зная стенд и время команды, можно было более конкретно говорить с ней о причинах.
Не долго думая Иван поднял телефонную трубку и набрал номер человека, хорошо разбирающегося во внутренностях DevOps:
— Денис, подскажи, пожалуйста, а можно ли как-то понять, что команда прошла тот или иной стенд?
— Конечно. Наш Jenkins отбрасывает флаг, если сборка успешно раскатилась (прошла проверку) на стенде.
— Супер. А что такое флаг?
— Это обычный текстовый файлик типа «стенд_OK» или «стенд_FAIL», который говорит, что сборка прошла или не прошла стенд. Ну ты понял, да?
— В принципе да. Он пишется в ту же папку в хранилище, где лежит сборка?
— Да
— А что будет, если сборка не прошла стенд? Нужно будет делать новую сборку?
— Ага
— Ну ок, спасибо. И еще вопрос: я правильно понимаю, что в качестве даты прохождения стенда я смогу использовать дату создания флага?
— Абсолютн!
— Супер!
Воодушевленный, Иван положил трубку и понял, что всё встало на свои места. Зная дату создания файла сборки и даты создания флагов можно было с точность до секунды посчитать, сколько времени команды тратят на каждый стенд и понять где они тратят больше всего времени.
«Понимая где уходит больше всего времени мы точечно найдём команды, пойдём к ним и прокопаем проблему». Иван улыбнулся.
На завтра он поставил себе задачу набросать архитектуру прорисовывающейся системы.
Продолжение следует…
Даже на выходных он думал про метрики: «Ну и что, что я измерю время? Что оно мне даст?»
Действительно, что даст знание времени? Допустим, поставка занимает 5 дней. И что дальше? Это хорошо или плохо? Даже если это плохо, то нужно же как-то уменьшать это время. Но как?
Эти мысли не давали ему покоя, но решение не приходило.
Иван понимал, что подошёл к самой сути. Бесчисленные графики метрик, виденные им до этого, давно убедили его, что стандартный подход не сработает, и что если просто построить график (пусть даже когортный), толку от него будет ноль.
Как же быть?...
Метрика — это как обычная деревянная линейка. Измерения, сделанные с её помощью, не скажут причину, почему измеряемый предмет именно той длины, которую она показал. Линейка просто покажет его размер, и не более. Она не философский камень, а просто деревянная доска, которой измеряют.
«Крыса из нержавеющей стали» его любимого писателя Гарри Гаррисона всегда говорила: мысль должна достичь дна мозга и там отлежаться, поэтому безрезультатно промучившись несколько дней Иван решил заняться другой задачей…
Через пару дней, читая статью про интернет-магазины, Иван вдруг понял, что величина денег, которую получает интернет-магазин, зависит от того как ведут себя посетителя сайта. Именно они, посетители/клиенты, отдают магазину свои деньги и являются их источником. На итоговую величину денежных средств, получаемых магазином, влияют изменения в поведении клиентов, а ни что-то иное.
Получалось, что для изменения измеряемой величины нужно было влиять на тех, кто это значение формирует, т.е. для изменения количества денег интернет-магазина надо было влиять на поведение клиентов этого магазина, а для изменения времени поставки в DevOps надо было влиять на команды, которые это время «создают», т.е. используют DevOps в своей работе.
Иван понял, что метрики DevOps должны представлять вовсе не графики. Они должны представлять из себя инструмент поиска «выдающихся» команд, формирующих итоговое время поставки.
Никакая метрика никогда не покажет причину, почему та или иная команда долго поставляла дистрибутив, думал Иван, ведь в реальности причин может быть миллион и маленькая тележка, и они вполне могут быть не техническими, а организационными. Т.е. максимум, что можно рассчитывать получить от метрик – это показ команд и их результатов, а затем всё равно придётся в эти команды идти ногами и выяснять, что у них стряслось.
С другой стороны, в компании Ивана существовал стандарт, обязывающий все команды проверять сборки на нескольких стендах. Команда не могла перейти на следующий стенд до тех пор, пока не будет пройден предыдущий. Получалось, что если представить процесс DevOps как последовательность прохождения стендов, то метрики могли бы показывать время, затрачиваемое командами на этих стендах. Зная стенд и время команды, можно было более конкретно говорить с ней о причинах.
Не долго думая Иван поднял телефонную трубку и набрал номер человека, хорошо разбирающегося во внутренностях DevOps:
— Денис, подскажи, пожалуйста, а можно ли как-то понять, что команда прошла тот или иной стенд?
— Конечно. Наш Jenkins отбрасывает флаг, если сборка успешно раскатилась (прошла проверку) на стенде.
— Супер. А что такое флаг?
— Это обычный текстовый файлик типа «стенд_OK» или «стенд_FAIL», который говорит, что сборка прошла или не прошла стенд. Ну ты понял, да?
— В принципе да. Он пишется в ту же папку в хранилище, где лежит сборка?
— Да
— А что будет, если сборка не прошла стенд? Нужно будет делать новую сборку?
— Ага
— Ну ок, спасибо. И еще вопрос: я правильно понимаю, что в качестве даты прохождения стенда я смогу использовать дату создания флага?
— Абсолютн!
— Супер!
Воодушевленный, Иван положил трубку и понял, что всё встало на свои места. Зная дату создания файла сборки и даты создания флагов можно было с точность до секунды посчитать, сколько времени команды тратят на каждый стенд и понять где они тратят больше всего времени.
«Понимая где уходит больше всего времени мы точечно найдём команды, пойдём к ним и прокопаем проблему». Иван улыбнулся.
На завтра он поставил себе задачу набросать архитектуру прорисовывающейся системы.
Продолжение следует…
