Текст книги "Ускоряйся! Наука DevOps"

Подводя итог, в 2017 году мы обнаружили, что по сравнению с низкоэффективными компаниями лидеры отрасли показывают следующие результаты:

● в 46 раз более частое развертывание кода;

● в 440 раз меньшее время выполнения от коммита до развертывания;

● в 170 раз меньшее среднее время восстановления после простоя;

● в 5 раз более низкий показатель отказов изменений (1/5, скорее для того, чтобы изменение не состоялось).

По сравнению с результатами 2016 года разрыв между компаниями с высокими и низкими показателями сократился по скорости (частоте развертывания и времени внедрения изменений) и увеличился по стабильности (среднее время восстановления и уровень отказов при внедрении изменений). Мы предполагаем, что это происходит из-за низкой производительности команд, работающих над увеличением скорости, но недостаточно инвестирующих в выстраивание качественных процессов. Результатом являются более крупные сбои развертывания, которые требуют больше времени для восстановления работы. Компании с высокими показателями эффективности понимают, что им не нужно жертвовать скоростью ради стабильности или наоборот, потому что, создавая качество, они получают и то и другое.

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

Глава 2
Измерение эффективности

Существует много концепций и методологий, направленных на улучшение способа создания программных продуктов и услуг. Мы хотели выяснить, что работает, а что нет, в научном смысле, начиная с определения того, что означает «хорошо» в этом контексте. В этой главе представлены структура и методы, которые мы использовали для достижения этой цели, и, в частности, ключевые результаты измерений, применяемые на протяжении всей этой книги.

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

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

НЕДОСТАТКИ ПРЕДЫДУЩИХ ПОПЫТОК ИЗМЕРЕНИЯ ЭФФЕКТИВНОСТИ

Было много попыток измерить эффективность команд по разработке ПО. Большинство этих измерений было сосредоточено на производительности. В общем они страдают от двух недостатков. Во-первых, они сосредоточены на производстве, а не на конечных результатах. Во-вторых, они фокусируются на индивидуальных или локальных измерениях, а не на коллективных или глобальных. Возьмем три примера: строки кода, скорость и загрузка.

Измерение эффективности с точки зрения строк кода имеет долгую историю в программном обеспечении. Некоторые компании даже требовали от разработчиков записывать строки кода, зафиксированные в в течение недели[5]5
  Есть хорошая история о том, как руководство команды Apple Lisa обнаружило, что строки кода были бессмысленными в качестве показателя производительности: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt


[Закрыть]. Однако в реальности мы предпочли бы 10-строчное решение задачи 1000-строчному. Вознаграждение разработчиков за написание строк кода приводит к раздутому программному обеспечению, что влечет увеличение затрат на обслуживание и более высокую стоимость изменений. В идеале мы должны вознаграждать разработчиков за решение бизнес – задач с минимальным количеством кода. И даже лучше, если мы можем решить проблему без написания кода вообще или путем удаления кода (возможно, путем изменения бизнес-процесса). Однако минимизация строк кода также не является идеальным параметром. В крайнем случае она тоже имеет свои недостатки: выполнение задачи в одной строке кода, которую никто другой не может понять, менее желательно, чем написание нескольких строк кода, которые легко понять и поддерживать.

С появлением методов Agile для разработки программного обеспечения появился новый способ измерения эффективности: скорость. Во многих школах сторонников Agile задачи разбиваются на истории. Истории, в свою очередь, оцениваются разработчиками, и им присваивается определенное количество очков, которые означают относительное количество усилий, требующихся, чтобы выполнить эти задачи. В конце итерации общее количество очков при сдаче работы заказчику записывается – это и есть скорость команды. Показатель скорости предназначен для использования в качестве инструмента планирования ресурсов; например, он может быть использован для экстраполяции, сколько времени потребуется команде, чтобы выполнить все, что запланировано и подсчитано. Тем не менее некоторые менеджеры также использовали его как способ измерения производительности команды или даже для сравнения команд.

Использование скорости в качестве показателя эффективности имеет несколько недостатков. Во-первых, скорость является относительной величиной и зависимым от команды параметром, а не абсолютным значением. Команды обычно работают в значительно различающихся условиях, которые делают их скорости несоизмеримыми. Во-вторых, когда скорость используется в качестве меры производительности, команды неизбежно стремятся к тому, чтобы увеличить показатели своей скорости. Они завышают свои оценки и сосредотачиваются на завершении как можно большего количества историй за счет сотрудничества с другими командами (что может уменьшить их скорость и увеличить скорость другой команды, заставляя их выглядеть плохо). Это не только нарушает использование скорости по назначению, но и препятствует сотрудничеству между командами.

Наконец, многие организации измеряют загрузку как показатель эффективности. Проблема с этим методом заключается в том, что высокая загрузка хороша только до определенного момента. Как только параметр использования становится выше определенного уровня, нет никакой запасной мощности (или резерва), чтобы поглотить незапланированную работу, изменения в плане или работу по улучшению. Это приводит к более длительным срокам выполнения работ. Теория очередей в математике говорит нам, что по мере того, как загрузка приближается к 100 %, время производственного цикла приближается к бесконечности. Другими словами, как только вы достигаете очень высоких уровней загрузки, командам требуется экспоненциально больше времени на выполнение любой задачи. Поскольку время выполнения заказа, то есть то, как быстро может быть выполнена работа, – это показатель продуктивности, не страдающий от недостатков, присущих другим показателям, которые мы рассмотрели, важно, чтобы мы управляли загрузкой, сбалансировав ее со временем выполнения экономически оптимальным способом.

ИЗМЕРЕНИЕ ЭФФЕКТИВНОСТИ ДОСТАВКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Успешное измерение эффективности должно обладать двумя ключевыми характеристиками. Во-первых, оно должно сосредоточиться на глобальном результате, чтобы команды не сталкивались друг с другом. Классический пример – награждение разработчиков за скорость, а техподдержки – за стабильность; это главный кирпич в «стене путаницы», через которую разработка перебрасывает код низкого качества техподдержке, а та инициирует болезненные процессы управления изменениями как способ подавления изменений. Во-вторых, наша оценка должна фокусироваться на конечных, а не промежуточных результатах. Она не должна вознаграждать людей за то, что они проделывают большое количество работы, которая на самом деле не помогает достичь организационных целей.

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

Время выполнения заказа как метрика является ключевым элементом теории бережливого производства. Это время, необходимое для перехода от клиента, делающего запрос, к удовлетворенному запросу. Однако в контексте разработки продукта, где мы стремимся удовлетворить множество клиентов, есть две составляющие времени выполнения заказа: время, необходимое для разработки и проверки продукта или функции, и время для доставки функции клиентам. В проектной части времени выполнения бывает неясно, когда запускать часы, и часто присутствует высокая вариативность. По этой причине Райнертсен называет эту часть времени выполнения «нечетким входным интерфейсом» (Райнертсен, 2009). Тем не менее часть времени, относящуюся к доставке, то есть время, необходимое для внедрения и тестирования работ, легче измерить, и оно имеет меньшую вариативность. Таблица 2.1 (Ким и соавторы, 2016) показывает различие между этими двумя областями.

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

● менее одного часа;

● менее одного дня;

● от одного дня до одной недели;

● от одной недели до одного месяца;

● от одного месяца до шести месяцев;

● более шести месяцев.

Второй показатель, который следует учитывать, – это размер пакета. Его сокращение является еще одним важным элементом парадигмы бережливого производства – кстати, это был один из ключей к успеху производственной системы Toyota. Уменьшение размеров партии сокращает время цикла и изменчивость потока, ускоряет обратную связь, снижает риски и накладные расходы, повышает эффективность, мотивацию и срочность, а также снижает затраты и риск нарушения сроков (Райнертсен, 2009, глава 5). Однако в программном обеспечении размер пакета трудно измерить и сообщить в разных контекстах, поскольку нет никакого видимого инвентаря. Поэтому мы остановились на частоте развертывания в качестве показателя для определения размера пакета, поскольку она проста в измерении и обычно имеет низкую изменчивость[6]6
  Строго говоря, частота развертывания обратно пропорциональна размеру пакета – чем чаще мы развертываем, тем меньше размер пакета. Дополнительные сведения об измерении размера пакета в контексте управления ИТ-сервисами см. Форсгрен и Хамбл (2016).


[Закрыть].

Под развертыванием мы подразумеваем развертывание программного обеспечения в производство или в магазин приложений. Выпуск версии ПО (изменения, которые будут развернуты), как правило, состоит из нескольких коммитов в контроле версий, если организация не достигла единичного потока, где каждый коммит может быть запущен в производство (практика, известная как непрерывное развертывание). Мы спросили наших респондентов, как часто их организации развертывают код для основного сервиса или приложения, над которым они работают, предлагая следующие варианты:

● по требованию (несколько развертываний в день);

● от одного раза в час до одного раза в день;

● от одного раза в день до одного раза в неделю;

● от одного раза в неделю до одного раза в месяц;

● от одного раза в месяц до одного раза в шесть месяцев;

● реже одного раза в полгода.

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

Наконец, ключевым показателем при внесении изменений в систему является процент отказов в производстве (включая, например, выпуски программного обеспечения и изменения конфигурации инфраструктуры). В контексте бережливого производства это то же самое, что и процент полноты и точности для процесса доставки продукта, то есть ключевой показатель качества. Мы спросили респондентов, какой процент изменений основного приложения или сервиса, над которыми они работают, приводит к ухудшению обслуживания или впоследствии требует исправления (например, приводит к ухудшению обслуживания или отключению, требует пакета исправлений, отката системы, доработки или патча). Четыре выбранных параметра показаны на рис. 2.1.

Для анализа эффективности доставки по всей обследованной группе мы использовали метод, называемый кластерным анализом. Кластерный анализ – это основополагающий метод статистического анализа данных, который пытается сгруппировать ответы таким образом, чтобы ответы в одной и той же группе были более похожи друг на друга, чем на ответы в других группах. Каждое измерение помещается в отдельное пространство, и алгоритм кластеризации пытается минимизировать расстояние между всеми членами кластера и максимизировать различия между кластерами. Этот метод не имеет никакого представления о семантике ответов – другими словами, он не знает, что считается хорошим или плохим ответом[7]7
  Более детальную информацию по кластерному анализу смотрите в Приложении B.


[Закрыть].

Этот основанный на данных подход, который классифицирует данные без какого-либо смещения в сторону хорошего или плохого, позволяет нам просматривать тенденции в отрасли, не искажая результаты априори. Использование кластерного анализа также позволило нам выявить категории эффективности доставки программного обеспечения, наблюдаемые в отрасли: есть ли лидеры и отстающие и какими характеристиками они обладают?

Мы применяли кластерный анализ в течение всех четырех лет нашего исследовательского проекта и обнаружили, что каждый год в отрасли возникают заметно отличающиеся категории эффективности доставки программного обеспечения. Мы также обнаружили, что все четыре показателя эффективности доставки ПО являются хорошими классификаторами и что группы, которые мы определили в анализе: лидеры, средние и отстающие, – существенно различаются по всем четырем показателям.

В таблицах 2.2 и 2.3 приведены подробные сведения об эффективности доставки программного обеспечения за последние два года нашего исследования (2016 и 2017).

Удивительно, но эти результаты показывают, что нет никакого компромисса между повышением эффективности и достижением более высоких уровней стабильности и качества. Скорее, мы можем говорить о том, что лидеры лучше справляются со всеми этими показателями. Это именно то, что прогнозируют движения Agile и Lean, но главная догма в нашей отрасли все еще основывается на ложном предположении, что двигаться быстрее означает принести в жертву скорости другие цели эффективности.

Кроме того, за последние несколько лет мы обнаружили, что высокоэффективный кластер отрывается от всех остальных. Мантра DevOps о непрерывном совершенствовании является одновременно захватывающей и реальной, подталкивая компании к тому, чтобы быть лучшими, и оставляя позади тех, кто не улучшается. Очевидно, что то, что было современным три года назад, просто недостаточно хорошо для сегодняшней бизнес-среды.

По сравнению с 2016 годом участники опроса с высокими показателями сохранили или улучшили их в 2017 году, постоянно наращивая темп и стабильность. С другой стороны, участники с низкими показателями поддерживали тот же уровень пропускной способности в 2014–2016 годах и начали расти только в 2017 году, вероятно, осознав разрыв со всей остальной отраслью. В 2017 году мы зафиксировали у участников с низкими показателями потерю в стабильности. Мы подозреваем, что это связано с их попытками увеличить темп («работай усерднее!»), что не позволяет устранить основные препятствия на пути повышения общей эффективности (например, решить задачи реархитектуры, совершенствования процессов и автоматизации). Данные тенденции показаны на рис. 2.2 и 2.3.

Сюрприз!

Наблюдательные читатели заметят, что у средних участников показатель уровня отказов при внесении изменений в 2016 году хуже, чем у отстающих. 2016 год – это первый год нашего исследования, когда мы видим несколько несистемную эффективность по всем нашим показателям в каждой из групп, включая средних и отстающих. Наше исследование не дает окончательного объяснения этому явлению, но у нас есть несколько идей о том, почему это может быть.

Одно из возможных объяснений заключается в том, что средние участники работают над своей технологической трансформацией и решают задачи, связанные с крупномасштабными проектами по перестройке архитектуры, такие как, например, переход с устаревших баз кода. Это также соответствовало бы другой части данных из исследования 2016 года, где мы обнаружили, что средние тратят больше времени на незапланированную переработку, чем отстающие, потому что они тратят большую часть времени на новую работу.

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

Мы нашли достоверный, надежный способ измерения эффективности доставки программного обеспечения, который удовлетворяет изложенным нами требованиям. Он фокусируется на глобальных, системных целях и измеряет конечные результаты, над улучшением которых различные функциональные команды должны работать совместно. Следующий вопрос, на который мы хотели бы ответить: имеет ли значение эффективность доставки программного обеспечения?

ВЛИЯНИЕ ЭФФЕКТИВНОСТИ ДОСТАВКИ НА ОРГАНИЗАЦИОННУЮ ЭФФЕКТИВНОСТЬ

Для оценки эффективности работы организации респондентам было предложено оценить относительную эффективность своей организации по нескольким параметрам: прибыльность, доля рынка и производительность. Это шкала, которая была многократно проверена в предыдущем исследовании (Уайденер, 2007). Было также установлено, что этот показатель эффективности деятельности организации в значительной степени коррелирует с показателями рентабельности инвестиций (ROI) и устойчив к экономическим циклам, – отличный показатель для наших целей. Анализ, проводимый в течение нескольких лет, показывает, что высокоэффективные организации неизменно в два раза чаще превышали свои цели, чем низкоэффективные. Это показывает, что возможности организации по доставке программного обеспечения могут фактически обеспечить конкурентное преимущество для вашего бизнеса.

В 2017 году мы в нашем исследовании также изучили, как ИТ-эффективность влияет на способность компании достигать организационных целей в широком смысле, то есть целей, которые выходят за рамки простых показателей прибыли и дохода. Независимо от того, стремитесь вы получать прибыль или нет, любая организация сегодня зависит от технологий достижения своей миссии и обеспечения ценности для своих клиентов или акционеров быстро, надежно и безопасно. Какова бы ни была миссия, эффективность работы технологий в организации влияет на ее общую эффективность.

Для измерения некоммерческих целей мы использовали шкалу, которая была многократно проверена и особенно хорошо подходит для этой цели (Кавалуццо и Иттнер, 2004). Мы обнаружили, что лидеры также в два раза чаще превышают цели по количеству товаров и услуг, операционной эффективности, удовлетворенности клиентов, качеству продуктов или услуг и достижению целей организации. Мы покажем эту взаимосвязь на рис. 2.4.

Как читать рисунки в этой книге

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

● Когда вы видите серое прямоугольное поле, – это конструкция, которую мы измерили. (Подробно о конструкциях см. в Главе 13.)

● Стрелки, связывающие поля, указывают на предиктивное отношение. Вы правильно прочитали: исследование в этой книге включает выводы, которые выходят за рамки корреляции и переходят в разряд прогнозов. (Подробнее см. Главу 12, посвященную прогнозированию на основе умозаключений.) Вы можете прочитать эти стрелки, используя слова «управляет», «прогнозирует», «влияет» или «оказывает воздействие». Это все положительные связи, если не указано иное.

Например, рис. 2.4 можно прочитать как «эффективность доставки программного обеспечения влияет на организационную и некоммерческую эффективность».

В софтверных компаниях способность работать и поставлять небольшие пакеты ПО особенно важна, поскольку она позволяет быстро собирать отзывы пользователей с помощью таких методов, как A/B-тестирование.

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

Тот факт, что эффективность доставки программного обеспечения имеет большое значение, является убедительным аргументом против аутсорсинга разработки стратегического для вашего бизнеса ПО вместо внедрения этой возможности в ядро организации. Даже федеральное правительство США через такие инициативы, как Цифровая служба США и Служба трансформации технологий при Администрации общих служб, инвестировало в создание собственной разработки программного обеспечения для решения стратегических задач. Напротив, большинство программ, которые используют предприятия (например, офисные приложения и системы начисления заработной платы), не являются стратегическими и во многих случаях должны приобретаться по модели «программное обеспечение как услуга». Определение того, какое программное обеспечение является стратегическим, а какое нет, и управление ими соответствующим образом имеют огромное значение. Эта тема подробно рассматривается Саймоном Уордли, создателем метода отображения Уордли (Уордли, 2015).

УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ

Теперь, когда мы определили эффективность доставки программного обеспечения строгим и измеримым способом, мы можем принимать основанные на фактических данных решения о том, как улучшить производительность команд, создающих программные продукты и услуги. Мы можем сравнить и оценить команды с более крупными организациями, в которых они работают, и с отраслью в более широком смысле. Мы можем измерить улучшение их показателей – или отставание – с течением времени. И, возможно, самое волнующее – мы можем выйти за рамки корреляции и начать тестировать прогнозирование. Мы можем проверить гипотезы о том, какие методы – от управления работой в процессе до автоматизации тестирования – на самом деле влияют на эффективность доставки и силу своего воздействия. Мы можем оценить другие конечные результаты, которые нам важны, такие как командное выгорание и «боль развертывания». Мы можем ответить на такие вопросы, как: «Действительно ли советы по управлению изменениями улучшают эффективность доставки?» (Осторожно, спойлер: нет, они отрицательно коррелируют со скоростью и стабильностью.)

Как мы покажем в следующей главе, можно также моделировать и измерять командную культуру количественными параметрами. Это позволяет нам оценить влияние DevOps и практик непрерывной доставки на культуру и, в свою очередь, влияние культуры на эффективность доставки ПО и организационную эффективность. Наша способность измерять деятельность, культуру и результаты является невероятно мощным инструментом, который может быть использован для достижения огромного положительного эффекта в погоне за высокой эффективностью.

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

Тем не менее важно осмотрительно использовать эти инструменты. В организациях с культурой обучения они невероятно сильны. Но в патологических и бюрократических организационных культурах оценка используется как форма контроля и люди скрывают информацию, которая бросает вызов существующим правилам, стратегиям и структурам власти. Как сказал Деминг, «всегда, когда есть страх, вы получаете неправильные цифры» (Хамбл и соавторы, 2014, с. 56). Прежде чем вы будете готовы применить научный подход к повышению эффективности, вы должны сначала понять и развить свою культуру. Именно к этой теме мы сейчас и обратимся.