Как Иван метрики DevOps делал. Начало

    Однажды Ивана позвали на совещание, чтобы обсудить метрики DevOps.

    Каждый участник подготовил к встрече перечень неких метрики, которые на его взгляд, стоило бы реализовать.

    Слушая доклады Иван попытался подсчитать сколько метрик было предложено: 5,10, опять 10, и еще около десятка. Получилось 30 с чем-то.

    Почему-то неожиданно пришла мысль о том, что собравшиеся люди просто погуглили и выписали те, названия которые показались им интересными. О сути метрик, судя по всему, никто не думал.

    Наблюдая со стороны Иван задавал себе вопросы: зачем? Почему именно эти метрики? Что они вам дадут? Стало вдруг очевидно, что на совещании собрались люди, совершенно далекие от реального понимания природы метрик, и что всё закончится как обычно, потерей огромного количества времени и выбрасыванием наработок в мусор.

    Стало грустно и обидно. Обидно за то, что время и деньги компании просто уходят в никуда, и грустно от того, что полезное дело так и не будет сделано.

    Иван уже длительное время изучал метрики и давно понял, что тема это очень серьезная и сложная, и подходить к ней с бухты-барахты нельзя ни в коем случае.

    В тот день совещание закончилось всем и ничем – решили реализовать всё разом (никто не хотел брать на себя ответственность отказа, т.к. не понимал зачем эти метрики нужны другому человеку).

    Иван решил подготовить своё видение метрик DevOps, причём сделать так, чтобы каждая метрика была в нём обоснована, имела конкретную цель, несла пользу и была понятна.
    Вот, что у него получилось…

    Чем Вы хотите управлять?


    Первым делом Иван решил подумать о ГЛАВНОЙ ЦЕЛИ, ради которой метрики делаются.
    Прочтенные книги «Lean Analytics» и «Практика Дао Тойота» подсказали: в качестве главной метрики выбери число, которым хочешь управлять. Далее в качестве метрик выбери компоненты этого числа, на которые ты сможешь повлиять.

    Целью DevOps на прошедшей встрече декларировалось «качество ПО», однако понятие качества было очень размытым. Что такое качество? Как выразить его одним числом? Какие компоненты на него влияют?

    К сожалению, качество ПО невозможно выразить одним числом.

    Да и вообще, действительно ли целью использования DevOps является именно качество?
    Пару лет назад Иван работал ИТ-директором в небольшой компании, производящей собственное ПО, и там он успешно запустил и использовал DevOps. И целью этого DevOps на самом деле было вовсе не качество. Вернее, и качество тоже. Главной и единственной целью было устранение ручного труда при деплоях в пром.

    Убрав ручной труд он тогда добился такого ускорения и сокращения количества ошибок, что доработки стало возможным релизить в хоть раз в минуту.

    Таким образом получалось, что в качестве ЦЕЛЕВОЙ МЕТРИКИ DevOps само собой напрашивалось

    Время поставки


    Именно его уменьшение или увеличение показывало бы эффект от принятых управленческих решений.

    Время поставки (Time To Market, TTM) увеличилось – плохо. Уменьшилось – отлично.
    Но время поставки зависит и от объема задачи и от длительности тестирования и от множества других факторов! Да, верно.

    И именно поэтому Иван сознательно решил начать отсчет времени не с момента кодирования и анализа, а с момента, когда сборка (дистрибутив) уже создана и находится в хранилище и всё что осталось – провести ряд проверок и развернуть её на промышленной среде (т.н. Continious Delivery, CDL).

    Тут важно сначала выработать принцип, концепцию, думал Иван, и уже дальше распространить её на другие неохваченные участки, ведь кодирование, сборка и все остальные шаги разработки точно также влияют на время поставки как и этап CDL. Сделаем в одном – сделаем и в другом.

    В большой компании, где работал Иван, метрики были жизненно важны. Тысячи разработчиков пилили код и ежедневно делались сотни сборок, но никто, ни один человек в компании не знал, сколько же времени в реальности тратят команды на DevOps.

    Со всех сторон сыпались жалобы: DevOps фигня, он не работает, он всё ужасно замедлил, от него нет никакого толку. Но ни у кого не было реальных цифр на руках, и доказать или опровергнуть заявления команд было попросту невозможно.

    Именно эту цель поставил перед собой Иван – посчитать время, которое команды тратят на DevOps, и в частности на этап поставки сборки.

    Такого не может быть, думал Иван, если я в своё время запустил DevOps и он дал мгновенный эффект, то почему здесь этого нет?

    Создание системы метрик стало для Ивана делом чести.

    Управляйте тем, чем можете управлять


    Как управлять временем поставки? Возможно ли это? – задался вопросом Иван.
    Если рассмотреть время поставки как число, то становится ясным, что есть места в процессе DevOps, которые существенно влияют на это число.

    В компании Ивана был стандарт: каждая сборка перед выходом в пром должна была проходить три тестовых стенда, на которых тестировались различные аспекты ПО.

    Естественно, сборки на них «отваливались» из-за ошибок, и вместо них создавались новые.
    Получалось, что именно стенды являются ключевыми элементами итогового времени поставки, и именно они влияют на итоговое время, увеличивая его.

    Время поставки = Время на стенде 1 + Время на стенде 2 + Время на стенде 3

    Влияя на время, затраченное командами на каждом из стендов, можно будет повлиять на итоговое время поставки.

    Оставались два простых вопроса:

    1. как физически посчитать затраты команд на стенды и
    2. как быть с простоями между стендами (простои тоже являются составляющими времени поставки)?

    Ивану ничего не оставалось как погрузиться в дебри Jenkins и Nexus (ПО, используемое при CDL).

    Jenkins и Nexus помогают


    «Раскатка» сборки на стенде осуществлялась с помощью Jenkins. По сути, Jenkins — это обычный шедулер, наподобие crontab, но с расширенными функциями.

    Jenkins умеет выдавать логи всех запущенных джобов (заданий на раскатку сборки на стенде) в виде RSS, и там есть время запуска, окончания и ссылка на конкретную сборку.

    Получалось, что в распоряжение Ивана попадали данные о точном времени начала и окончания работ по сборкам, т.е. можно было без труда и с точностью до секунды посчитать чистое время, затраченное командами на стенды.

    А если данные со всех стендов свалить в одну базу, то можно было посчитать и простои между стендами. Это было великолепно!

    Из Nexus (сетевого хранилища файлов) Иван собирался доставать дату создания самой сборки и т.о. определять момент её появления и точку отсчета.

    Всё встало на свои места. Почти.

    — А как этим управлять, подумал Иван?..

    Продолжение. Объект влияния
    Поделиться публикацией

    Комментарии 3

      +1
      Слишком короткая статья как мне кажется, но пишите интересно…
        0
        Спасибо.
        Просто тема большая. По моей задумке в каждой статье будет раскрываться одна мысль или один вывод.
        Следующую статью планирую после НГ выпустить
          0

          Действительно, пишите. Оценка для DevOps, system да и для Dev — весьма нетривиальная задача. Всегда хотел понимать, хоть в каком-то приближении, насколько хорошо работаю я и коллеги.
          Все внедрения метрик, которые наблюдал, были в большой степени неадекватны.
          Единственный вариант, который был хоть как-то рабочим, это время закрытия тикета у System.
          И то приходилось как-то отделять тикеты с условной починкой от внедрений и разработки новых решений.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое