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

Часть I. «Три пути»

Введение

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

Основные темы части I:

• принцип потока ценности, ускоряющий для клиентов доставку продукта от разработчиков к отделу эксплуатации;

• принцип обратной связи, позволяющий создавать безопасные системы;

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

Краткая история

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

DevOps – результат применения самых надежных принципов из области лидерства и производства материальных ценностей к потоку создания ценности IT. DevOps опирается на базовые понятия теории бережливого производства, теории ограничений, производственной системы компании Toyota, правила создания устойчивых систем, модель обучающихся организаций, культуру психологической безопасности и так далее. Другие важные особенности, которые используют в DevOps, – это управленческая культура высокого доверия, лидерство как служение и управление изменениями в организации. В результате стали возможными высочайшее качество, надежность, стабильность и безопасность, полученные меньшей кровью и за меньшие деньги, увеличение роста и стабильности за счет потока технологической ценности в подразделениях управления продуктом, разработки, тестирования, отделах управления IT-эксплуатацией и информационной безопасности.

Хотя можно сказать, что DevOps основывается на принципах бережливого производства, теории ограничений и распространенного в Toyota движения «ката», многие рассматривают его как логическое продолжение Agile-движения, зародившегося в 2001 г.

Принципы бережливого производства

Такие техники, как «управление созданием потока ценности» и «канбан-доски», были созданы в рамках производственной системы Toyota в 1980-х гг. В 1997 г. Lean Enterprise Institute начал изучать возможность применения принципов бережливого производства к другим вариантам потоков создания ценности, например к сфере обслуживания и здравоохранению.

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

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

Agile-манифест

В 2001 г. появился манифест Agile. Его создали 17 авторитетных специалистов в области разработки ПО. Они хотели создать легковесный набор ценностей и принципов в противовес тяжеловесным процессам разработки (например, метод водопада) и методологиям (например, так называемый RUR – рациональный унифицированный процесс).

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

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

Agile-инфраструктура и движение Velocity

В 2008 г. в рамках конференции Agile, проходившей в Торонто, Патрик Дюбуа и Эндрю Шафер провели встречу под названием «Птицы одного полета». Она была посвящена применению принципов Agile к инфраструктуре, а не написанию кода приложений. Поначалу они были единственными приверженцами этой идеи, но быстро обрели единомышленников, включая одного из авторов этой книги – Джона Уиллиса.

Позже, на конференции Velocity в 2009 г., Джон Оллспоу и Пол Хаммонд продемонстрировали новаторскую презентацию под названием «Десять развертываний в день: кооперация разработки и эксплуатации во Flickr». В ней они описали, как создали общие цели для разработчиков (Dev) и эксплуатация (Ops) и использовали методы непрерывной интеграции, чтобы сделать развертывание частью ежедневной работы. Как утверждали впоследствии участники презентации, они сразу же поняли, что присутствуют на историческом мероприятии, имеющем далеко идущие последствия.

Патрик Дюбуа не участвовал в презентации, но был настолько восхищен идеей Оллспоу и Хаммонда, что в том же 2009 г. организовал первую конференцию DevOpsDays в бельгийском Генте, где тогда жил. Так и появился на свет термин DevOps.

Непрерывная поставка

Внедряя непрерывную разработку, тестирование и интеграцию, Джез Хамбл и Дэвид Фарлей расширили концепцию непрерывной поставки. Это определило важность «конвейера разработки»: код и инфраструктура всегда готовы к развертыванию, весь код прошел проверку и может быть безопасно развернут в производственной среде. Идею впервые представили на конференции Agile в 2006 г. Затем, в 2009 г., Тим Фитц абсолютно независимо придумал то же самое и изложил свои мысли в блоге под заголовком «Непрерывное развертывание»[19]19
  DevOps также расширяет и усовершенствует принцип инфраструктура как код, впервые предложенный Марком Берджессом, Люком Канисом и Адамом Джекобом. При использовании этого принципа работа эксплуатации автоматизирована и трактуется как разработка кода приложений, так что все современные методики разработки могут быть применены ко всему потоку разработки и управления. Это увеличивает возможности ускорения потока разработки, включая непрерывную интеграцию (придумана Греди Бучем как один из 12 ключевых методов «экстремального программирования»), непрерывную поставку (впервые введена Джезом Хамблом и Дэвидом Фарли) и непрерывное развертывание (созданное компаниями Etsy и Wealthfront, а также Эриком Рисом из IMVU). Прим. авт.


[Закрыть].

Ката компании Toyota

В 2009 г. Марк Ротер написал книгу «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов»[20]20
  Издана: СПб.: Питер, 2014. Прим. перев.


[Закрыть], где изложил двадцатилетний опыт кодифицирования производственной системы Toyota. Будучи студентом, он принял участие в поездке руководителей компании General Motors на заводы компании Toyota. Затем ему довелось участвовать в разработке инструментария для внедрения бережливого производства. Он был очень удивлен, что ни одна из компаний, внедривших этот метод, не смогла достичь такого же уровня производительности, как Toyota.

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


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

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

Глава 1. Agile, непрерывная поставка и «три пути»

Здесь представлено введение в основы теории бережливого производства и «трех путей» – из этих принципов сформировалось современное состояние DevOps.

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

Производственный поток ценности

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

Карен Мартин и Майк Остерлинг в книге Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation определили поток создания ценности как «последовательность действий, предпринимаемых организацией с целью выполнить запрос клиента», или как «последовательность действий, необходимых для разработки, выпуска и доставки товаров клиенту, включая оба потока – и информационный, и материальный».

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

Технологический поток ценности

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

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

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

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

Фокус на времени развертывания

В остальной части книги сосредоточимся на такой составной части потока создания ценности, как сокращенное время развертывания. Начинается оно тогда, когда некий инженер[22]22
  Здесь и далее слово «инженер» означает любого человека, работающего в команде, производящей поток ценности, а не только разработчиков. Прим. авт.


[Закрыть] из команды потока создания ценностей (включающей разработчиков, тестировщиков, отделы эксплуатации и информационной безопасности) получает изменения от системы контроля версий. А заканчивается, когда изменение начинает успешно работать в производственной среде, создавая продукт для клиентов и генерируя обратную связь и телеметрию.

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

Мы не любители больших порций работы, последовательно проходящих через такие части потока создания ценности, как «проектирование и разработка», а затем через поток «тестирование и производство» (например, когда используется большой водопадный процесс или долго живущая функциональная ветвь кода). Напротив, мы стремимся, чтобы тестирование и производство выполнялись одновременно с проектированием и разработкой. Так обеспечиваются быстрый ход потока и высокое качество. Этот метод успешен, если исполнение осуществляется по небольшим частям и качество обеспечивается на каждом этапе потока создания ценностей[23]23
  По правде говоря, при использовании таких методик, как разработка через тестирование, тестирование может начинаться еще до того, как будет написана первая строка кода. Прим. авт.


[Закрыть].

Определения: «время выполнения заказа» и «время производства»

В Lean время выполнения заказа – одна из двух характеристик, обычно использующихся для измерения производительности потоков ценности. Другая характеристика – время производства (иногда его еще называют временем контактирования или временем выполнения задачи)[24]24
  В этой книге термин «время производства» будет использоваться по той же причине, о которой говорили Карен Мартин и Майк Остерлинг: «чтобы минимизировать возможную путаницу, мы избегаем использовать термин “время цикла”, поскольку он имеет несколько значений, в том числе синонимичное для времени производства и темпа или частоты выдачи результатов, и это только некоторые». Прим. авт.


[Закрыть].

Если отсчет времени выполнения заказа начинается в момент оформления и заканчивается при выполнении, то время производства отсчитывается с момента, когда мы начинаем работу над заказом, точнее, не засчитывается тот период времени, когда заказ стоял в очереди на выполнение (рис. 2).

Рис. 2. Время выполнения заказа и время производства

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

Обычный сценарий: развертывание требует месяцев

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

Рис. 3. Поток технологической ценности при продолжительности внедрения длиной в три месяца (пример взят из вышедшей в 2015 г. книги Дэмона Эдвардса DevOps Kaizen)

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

Идеал DevOps – развертывание за минуты

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

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

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

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

Рис. 4. Технологический поток создания ценности с развертыванием за минуты

Наблюдать за %C/A в качестве оценки необходимости доработок

Помимо времени выполнения заказа и времени производства для оценки технологического потока создания ценности применяется и третий показатель – доля завершенной и правильной работы (percent complete and accurate – %C/A). Этот показатель отражает качество выполнения на каждом этапе потока создания ценности. Карен Мартин и Майк Остерлинг утверждают: «показатель %C/A можно получить, опросив клиентов, как часто в количественном выражении они получали продукт, пригодный к использованию сразу. Подразумевается, что они используют результат без необходимости его корректировать, добавлять пропущенную информацию или пояснения к имеющейся, если она недостаточно понятна».

«Три пути»: принципы, лежащие в основе DevOps

В книге The Phoenix Project «три пути» представлены как основополагающие принципы. Из них выводится DevOps и его методы (рис. 5).

Рис. 5. «Три пути» (пример взят из текста Джина Кима The Three Ways: The Principles Underpinning DevOps, размещенного в блоге Revolution Press blog по адресу: http://itrevolution.com/the-three-ways-principles-underpinning-devops/, доступ осуществлен 9 августа 2016 г.)

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

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

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

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

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

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

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

Заключение

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

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