Портал №1 по управлению цифровыми
и информационными технологиями

Больше отчётов хороших и разных

Опубликовано 26 августа 2019
Рубрики: DevOps, Аналитика: точка зрения, Обо всём на свете
Комментарии

Помимо уже ставшего привычным ежегодного отчёта о том, что происходит в мире DevOps «State of DevOps Report» от компании Puppet (см., например, обзор последнего отчёта) подобный отчёт выпускает и компания DORA (DevOps Research and Assessment). Отчёты называются (сюрприз-сюрприз) «State of DevOps».

Те, кто наблюдает за происходящим в мире DevOps, возможно помнят, что в 2018 году компания DORA была приобретена компанией Google. А основали DORA Николь Форсгрен (Nicole Forsgren), Джез Хамбл (Jez Humble), автор книг «Непрерывная поставка ПО» («Continuous Delivery»), «Lean Enterprise», соавтор «Руководство по DevOps» («The DevOps Handbook») и Джин Ким (Gene Kim), автор книг «Проект Феникс» «Руководство по DevOps» («The DevOps Handbook») и пр. Втроем они, кстати, выпустили в 2018 году книгу со скромным названием «Accelerate. The Science Behind DevOps». В общем, за брендом DORA стоят заметные люди с средства.

Причём на сайте DORA размещены ссылки на отчёты Puppet. А Puppet в своих отчётах ссылается на DORA. Что неудивительно, поскольку, в частности, Джез Хамбл поучаствовал и там, и там. Более того, в последнем отчете DORA «ACCELERATE. State of DevOps 2019» говорится о шестилетнем периоде наблюдений и более тридцати тысячах респондентов. Хотя цифры эти на самом деле Puppet-овские. А во вводной части отчёта 2018 Puppet говорит о «последующих совместных с DORA отчётах». Тем не менее, отчёты за 2018 у двух компаний различаются. 

Нам же это не так важно. Очевидно, что компания DORA, которая создана для того, чтобы заниматься аналитикой и консалтингом, может дать дополнительную интересную информацию. В частности, отчет от Puppet «State of DevOps Report 2019» ещё не вышел (хотя сбор данных уже закончен), а отчёт DORA уже доступен.

Огромным как у Puppet количеством респондентов DORA (пока?) похвастаться не может. Речь идёт о «почти тысяче» участниках опроса. Но по географии и размеру компаний картина выглядит внушительно. Например, статистика по количеству сотрудников компаний, представители которых участвовали в опросе, выглядит так:

Подход к представлению данных схож с тем, что используется у Puppet – ответы на различные вопросы кластеризованы по группам «передовики производства», «середняки» и «отстающие» (всего четыре категории: low, medium, high, elite). Ключевые метрики:

Разрыв между передовиками (elite performers) и отстающими (low performers) впечатляет:

  • в 208 раз более частые развёртывания,
  • в 106 более короткий lead time,
  • в 2604 раза более быстрое решение инцидентов,
  • в 7 раз меньше доля изменений, приводящих к сбоям.

Кстати, динамика распределения по группам «молодцы» и прочие довольно позитивная:

Некоторые выводы.

  • Передовики используют облака.
  • А ещё они более активно используют решения с открытым кодом.
  • Крупным компаниям (более 5000 сотрудников) сложнее достигать производительности сопоставимой с производительностью более мелких компаний.
  • В первые за историю наблюдения проявилась зависимость от индустрии. Ритейл в передовиках по производительности и стабильности. Ранее зависимости от индустрии не наблюдалось.

В заключительном разделе представлены результаты анализа стратегий DevOps-трансформации различных компаний. Из вполне предсказуемых результатов – подход «big bang» («большой взрыв») не подходит. DevOps требует взращивания и вызревания (а не привнесения и уж тем более насаждения).

Отчёт довольно объёмный (восемьдесят две страницы). Ознакомиться с оригиналом можно здесь.

ИНТЕНСИВ С ТРЕНЕРОМ
Трансформация ИТ в традиционных компаниях
Учебный курс о кратном ускорении за счёт новой организации работы

Также по теме:

Комментариев: 7

  • Андрей другой

    К вопросу о показателях – “в 208 раз более частые развёртывания,
    в 106 более короткий lead time,
    в 2604 раза более быстрое решение инцидентов,” Все это мне напоминает историю с продовольствием в СССР. Было с ним туго и вот умные головы сказали, что для увеличения урожая надо повышать механизацию сельского хозяйства и в качестве показателя выбрали количество тракторов в стране. Вроде все логично, но в результате количество тракторов в СССР в некоторое время превышало количество оных в США в несколько раз, а жрать все равно было нечего.

    • Игорь Гутник

      Андрей, приведённые метрики позволяют оценивать то, насколько быстро (и без нанесения вреда) ИТ приносит пользу. А также то, как быстро устраняет вред.
      Вроде бы это классические варианты оценки (не хватает только cost optimization). Т.е. в Вашей аналогии эти показатели как раз про наличие еды.
      А какие критерии оценки эффективности ИТ предложили бы Вы?

      • Андрей другой

        Игорь, приведенные метрики показывают потенциал системы, ее производительность. Т.е. на сколько она способна обеспечивать большие объемы изменений. А вот приносится ли при этом польза – эти метрики про это ничего не говорят. И такой подход приводит к проблеме, когда изменения делаются ради изменений. Всем же хочется поощрение за выполнение KPI.
        Реальные критерии те, которые отражают реальную пользу. Поскольку в современном мире польза оценивается исключительно в деньгах, то и критерии должны сводиться к ним же. На пример – соотношение затрат на изменения к полученному росту прибыли. Если вы в течении месяца сделали 5 изменений стоимостью 1000 0000, которые привели к росту прибыли на 20 000 000, то это значительно лучше чем 208 изменений стоимостью 10 000 000, которые привели к росту прибыли на 11 000 000. Как-то так.

        • Игорь Гутник

          Мне нравится. Даже несмотря на то, что не всё измеряется деньгами, такой подход кажется весьма разумным.
          Андрей, поделитесь, пожалуйста, результатами исследования, в котором приводятся такие данные.
          Совсем хорошо бы данные в динамике (как у puppet/DORA). Но и на один подобный отчёт с удовольствием бы посмотрел.

          • Андрей другой

            Игорь, у меня нет результатов исследования. Для меня все это пока на уровне идеи. Источников данных именно в таком ключе очень мало, поскольку тема достаточно интимная и компании не очень делятся информацией. Но идея, что называется, витает в воздухе. Тут недавно наш Сбер обращался ко мне на эту тему. Пока конечно не в полном объеме, но тенденция уже есть. Они интересовались решением, которое в условиях шустрого проектирования позволит им планировать ресурсы и оценивать затраты на каждый Спринт, а это уже первый шаг в данном направлении. По поводу отдачи все сложнее. Важна методология определения полученных результатов – что именно стало причиной успеха/провала. В одной умной книге описан случай – в кабинет руководителя крупной компании в начале 80-х купили персональный компьютер, он тогда стоил как паровоз, но ни разу его даже не включали. Так вот по мнению компании он все равно окупился с лихвой, поскольку формировал правильный имидж компании во время переговоров.
            Вообще тема оценки эффективности в ИТ меня последнее время сильно интересует. Я даже небольшую статейку на тему эффективности в контексте KPI и SLA написал. Пока не знаю куда выложить.

            • Игорь Гутник

              Андрей, понял.
              Спасибо за уточнение!
              Тогда пока буду пользоваться тем, что есть.
              Мне кажется, в завершение этого интересного обсуждения имеет смысл ещё один момент зафиксировать.
              Всякий раз, когда мы строим систему измерения и оценки чего-либо (подразделения, организации, процесса и т.п.), мы сталкиваемся со следующей проблемой.
              С одной стороны, нам хотелось бы получить инструмент, который показывает конечный результат (outcome в терминах ITIL4 или даже value).
              С другой стороны, понятно, что этот результат (outcome) очень часто появляется не только в силу деятельности объекта нашего измерения. Т.е. сложность такого измерения и оценки заключается не только в сложности измерения результата, но и в том, что сложно оценить наш вклад в получение этого результата. Поэтому неплохо бы иметь возможность измерить и так называемый output (позволяющий создавать outcome).
              В примере с тракторами и едой это означает следующее.
              Если мы хотим измерять эффективность машиностроения (допустим, только в части сельскохозяйственной), то мы, конечно, можем пытаться оценить эту эффективность через количество еды. Но только ли машиностроение в этом участвует?
              Кроме того, а почему количество/объём еды? А как же качество? А как же моральное удовлетворение и эстетическое наслаждение (это я всё ещё про еду 🙂 )?
              В общем, довольно быстро оказывается, что знать количество тракторов (с оценкой их ключевых характеристик типа TCO и пр.) не так уж бесполезно.

              • Андрей другой

                Игорь, измерение и оценка – это действительно не простая задача. Для сравнения все надо приводить к общему знаменателю и именно по этой причине возникают деньги. Мне тоже не нравится, что все измеряется деньгами, но пока другого общего знаменателя нет. По поводу качества – его нельзя измерить физическими величинами. Поэтому для оценки качества применяют декомпозицию с целью дойти все таки до штук, килограммов, метров и т.д. На пример качество жизни. Один из параметров – питание. Для него вывели потребительскую корзину, в которую по идее должен входить набор продуктов для полноценного питания. И уже этот набор можно померять в штуках и килограммах. Но такой подход не всегда возможен. На пример – художественная ценность произведения. Её как не декомпозируй, все равно к килограммам не придешь. Тогда только экспертный совет. Касаемо тракторов – да, их количество присутствует в формуле расчета конечной с/х продукции, но это не единственный и не самый главный показатель. Сейчас аналогичные ошибки присутствуют в проектах BigData. Используя статистические методы ребята выявляют зависимость между двумя показателями, но какого рода зависимость понять не могут. Один показатель влияет на другой или они оба зависят от третьего, а может более чем от одного и они про них даже не знают.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.