Считается, что методы Agile способны значительно увеличить продуктивность организаций-разработчиков. И, что интересно, многие из ключевых моментов в истории DevOps соответствуют аналогичным ситуациям, происходившим в сообществе Agile или на конференциях, посвященных этому методу.
В 2008 г. в рамках конференции Agile, проходившей в Торонто, Патрик Дюбуа и Эндрю Шафер провели встречу под названием «Птицы одного полета». Она была посвящена применению принципов Agile к инфраструктуре, а не написанию кода приложений. Поначалу они были единственными приверженцами этой идеи, но быстро обрели единомышленников, включая одного из авторов этой книги — Джона Уиллиса.
Позже, на конференции Velocity в 2009 г., Джон Оллспоу и Пол Хаммонд продемонстрировали новаторскую презентацию под названием «Десять развертываний в день: кооперация разработки и эксплуатации во Flickr». В ней они описали, как создали общие цели для разработчиков (Dev) и эксплуатация (Ops) и использовали методы непрерывной интеграции, чтобы сделать развертывание частью ежедневной работы. Как утверждали впоследствии участники презентации, они сразу же поняли, что присутствуют на историческом мероприятии, имеющем далеко идущие последствия.
Патрик Дюбуа не участвовал в презентации, но был настолько восхищен идеей Оллспоу и Хаммонда, что в том же 2009 г. организовал первую конференцию DevOpsDays в бельгийском Генте, где тогда жил. Так и появился на свет термин DevOps.
Внедряя непрерывную разработку, тестирование и интеграцию, Джез Хамбл и Дэвид Фарлей расширили концепцию непрерывной поставки. Это определило важность «конвейера разработки»: код и инфраструктура всегда готовы к развертыванию, весь код прошел проверку и может быть безопасно развернут в производственной среде. Идею впервые представили на конференции Agile в 2006 г. Затем, в 2009 г., Тим Фитц абсолютно независимо придумал то же самое и изложил свои мысли в блоге под заголовком «Непрерывное развертывание»[19].
В 2009 г. Марк Ротер написал книгу «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов»[20], где изложил двадцатилетний опыт кодифицирования производственной системы Toyota. Будучи студентом, он принял участие в поездке руководителей компании General Motors на заводы компании Toyota. Затем ему довелось участвовать в разработке инструментария для внедрения бережливого производства. Он был очень удивлен, что ни одна из компаний, внедривших этот метод, не смогла достичь такого же уровня производительности, как Toyota.
Марк сделал вывод: сообщество Lean упустило из вида наиболее важную часть метода — улучшение ката[21]. Он пояснил: каждая организация имеет свои рабочие процедуры, и улучшение ката требует создания структуры для ежедневного, рутинного совершенствования, поскольку повседневный опыт — это и есть то, что повышает результаты. Постоянно действующий цикл, то есть желаемое будущего состояния, еженедельное формулирование целей и непрерывное совершенствование повседневной работы, и составлял основу улучшений в компании Toyota.
Выше мы описали историю DevOps и связанных с ним течений. На их основе и возник метод DevOps. Далее в первой части мы рассмотрим потоки создания ценности, то, как к потокам технологической ценности можно применить принципы бережливого управления и «трех путей», обратной связи и непрерывного обучения и экспериментирования.
Глава 1. Agile, непрерывная поставка и «три пути»
Здесь представлено введение в основы теории бережливого производства и «трех путей» — из этих принципов сформировалось современное состояние DevOps.
Внимание уделено в первую очередь теории и принципам, выработанным за несколько десятилетий изучения рабочих сред, организации его высокой надежности, создания моделей управления с высоким уровнем доверия, положенных в основу методов DevOps. Получившиеся в результате принципы и схемы действий, а также их практическое применение для создания потока технологической ценности описаны в остальных главах книги.
19
DevOps также расширяет и усовершенствует принцип инфраструктура как код, впервые предложенный Марком Берджессом, Люком Канисом и Адамом Джекобом. При использовании этого принципа работа эксплуатации автоматизирована и трактуется как разработка кода приложений, так что все современные методики разработки могут быть применены ко всему потоку разработки и управления. Это увеличивает возможности ускорения потока разработки, включая непрерывную интеграцию (придумана Греди Бучем как один из 12 ключевых методов «экстремального программирования»), непрерывную поставку (впервые введена Джезом Хамблом и Дэвидом Фарли) и непрерывное развертывание (созданное компаниями Etsy и Wealthfront, а также Эриком Рисом из IMVU).
21
Ката — формализованная последовательность движений, связанных принципами ведения поединка с воображаемым противником или группой противников. По сути, является квинтэссенцией техники конкретного стиля боевых искусств.