Джин Ким - Руководство по DevOps

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

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

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

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

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

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

Другими словами, организации, внедрившие DevOps, могут увеличивать количество развертываний в день пропорциональным увеличением числа разработчиков, как это уже сделали компании Google, Amazon и Netflix [17].

Одна из наиболее авторитетных книг по бережливому производству — «Цель. Процесс непрерывного совершенствования» [18] — написана доктором Элияху Голдраттом в 1984 г. Под ее влияние попало целое поколение руководителей предприятий во всем мире. Это рассказ о директоре завода. Он должен был сократить расходы и наладить выполнение поставок всего за 90 дней, потому что иначе предприятие пришлось бы закрывать.

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

Книга Джина Кима, Кевина Бера и Джорджа Слаффорда «Проект “Феникс”. Роман о том, как DevOps меняет бизнес к лучшему» (год выпуска — 2013-й) очень похожа на «Цель…». Это повесть о руководителе IT-организации, столкнувшемся с проблемами, типичными для такого рода компаний: перерасход бюджета, нарушение графика, хотя его соблюдение жизненно важно для компании. Развертывание проекта происходит из рук вон плохо, возникают сложности с доступностью, безопасностью, соответствием требованиям и так далее. В конечном счете он и его команда начинают использовать методы и принципы DevOps, чтобы справиться с этими проблемами и дать организации возможность выдержать конкуренцию на рынке. Помимо этого, показано, как методы DevOps улучшают рабочую атмосферу в команде, способствуют снижению стресса, повышают удовлетворенность результатами вследствие большей вовлеченности сотрудников в процессы организации в целом.

Как и в случае с «Целью…», в «Проекте “Феникс”…» имеются серьезные доказательства универсальности описанных в книге проблем и решений. Приведем некоторые отзывы, взятые с сайта Amazon: «Я обнаружил сходство между собой и героями этой книги… Вполне возможно, что я встречал таких людей на всем протяжении моей карьеры». «Если вам доводилось работать в любом качестве в IT, эксплуатации или в сфере информационной безопасности, вы, безусловно, почувствуете связь с описанным в этой книге». «В книге “Проект «Феникс»…” нет такого персонажа, которого я не смог бы сравнить с собой или с кем-то, кого знаю в реальной жизни… не говоря уж о проблемах этих персонажей».

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

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

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

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