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

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

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

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

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

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

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

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

У нас немало убедительных доказательств ценности методов DevOps для бизнеса. В «Докладе о состоянии DevOps» компании Puppet Labs (в создании участвовали Джез Хамбл и Джин Ким) представлены данные за 2013–2016 гг., полученные примерно от 25 000 технических специалистов. Это помогает лучше понять уровень работоспособности и особенности организаций на всех этапах внедрения DevOps.

Прежде всего, эти данные продемонстрировали высокую (по сравнению с прочими) эффективность компаний, использующих DevOps. Сравнивались следующие характеристики:

• показатели пропускной способности;

• развертывание кода и внесение изменений (чаще в 30 раз);

• время, необходимое на разработку кода и внесение изменений в него (в 200 раз меньше);

• показатели надежности;

• развертывание в производство (коэффициент успешности в 60 раз выше);

• среднее время восстановления после сбоя (в 168 раз быстрее);

• показатели эффективности организации;

• производительность, доля на рынке и рентабельность (вероятность улучшить эти показатели в два раза выше);

• рост капитализации рыночной стоимости компании (за три года на 50 % больше).

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

Кроме того, у более производительных компаний имелось в два раза больше шансов повысить прибыльность, долю на рынке и эффективность. А у тех, кто сообщил нам свои биржевые символы, рост капитализации за три года оказался выше на 50 %. Текучка кадров в них ниже, а сотрудники чувствуют удовлетворенность и в 2,2 раза чаще рекомендуют компанию друзьям как отличное место работы[14]. Организации с высокой эффективностью лучше обеспечивают такой показатель, как «информационная безопасность». Достижение целей по безопасности интегрировано во все стадии процессов разработки и эксплуатации, поэтому на исправление соответствующих проблем уходит вдвое меньше времени.

Когда число разработчиков увеличивается, производительность каждого нередко снижается из-за потери времени на коммуникации, интеграцию и избыточное тестирование. Этот феномен подробно описан в книге Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы»[15]. В ней он объясняет: когда работа над проектом не выполняется в срок, увеличение количества разработчиков снижает продуктивность не только каждого в отдельности, но и команды в целом.

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

В «Докладе о состоянии DevOps в 2015 г.» изучался не только показатель «количество развертываний в день», но и «количество развертываний в день на одного разработчика». Мы выдвинули гипотезу, что высокопроизводительные инженеры могут увеличивать количество развертываний по мере роста численности команды.

Действительно, мы обнаружили такую зависимость. На рис. 1 показано, что при низкой производительности разработчиков количество развертываний в день уменьшается по мере роста численности команды, при средней – остается постоянным, а при высокой – растет пропорционально числу разработчиков.

Рис. 1. Количество развертываний в день в зависимости от числа разработчиков (источник: «Доклад о состоянии DevOps в 2015 г.», компания Puppet Labs)[16]