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

Ключевой принцип — «частая поставка работающего программного обеспечения, от нескольких недель до нескольких месяцев, чем быстрее — тем лучше». Два других важных принципа гибкой разработки — небольшие, целеустремленные команды, работающие по модели управления с высоким уровнем доверия, и предпочтение небольшим объемам работы. С гибкой методологией разработки также связаны такие наборы инструментов и методики, как Scrum, Stand-up [181]и так далее.

Конференция Velocity, впервые проведенная в 2007 г., была создана Стивом Судерсом, Джоном Оллспоу и Джессом Робинсом как место, где инженеры эксплуатации и производительности web-сервисов могли бы чувствовать себя как дома. На конференции в 2009 г. Джон Оллспоу и Пол Хэммонд представили основополагающий доклад 10 Deploys per Day: Dev and Ops Cooperation at Flickr («Десять развертываний в день: сотрудничество разработки и эксплуатации во Flickr»).

В 2008 г. на конференции гибкой методологии разработки в Торонто Патрик Дюбуа и Эндрю Шейфер провели сессию единомышленников, посвященную применению принципов гибкой разработки к инфраструктуре, а не только к коду. У них быстро появились последователи, например Джон Уиллис. Позже Дюбуа был настолько впечатлен докладом Оллспоу и Хэммонда 10 Deploys per Day: Dev and Ops Cooperation at Flickr, что провел первую конференцию DevOpsDays в Генте, Бельгия, в 2009 г., где впервые прозвучал термин DevOps.

Развивая идеи непрерывной сборки, тестирования и интеграции разработки ПО, Джез Хамбл и Дэвид Фарли придумали концепцию непрерывной поставки. В нее входит понятие «конвейер развертывания». Суть в том, что код и инфраструктура всегда готовы к развертыванию и что в развертывание всегда уходит весь код в основной ветке.

Эта идея впервые была представлена на конференции Agile в 2006 г., кроме того, независимо описана Тимом Фитцем в блоге в статье под названием Continuous Deployment («Непрерывное развертывание»).

В 2009 г. Майк Ротер написал книгу Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results [182]. В ней был обобщен его двадцатилетний опыт по анализу и приведению в систему причинных механизмов производственной системы компании Toyota. В книге описываются «невидимые управленческие практики и способы мышления, определяющие успех Toyota в непрерывном улучшении процессов и в адаптации… и то, как другие компании используют похожие методики и способы мышления в своей работе».

Его вывод: сообщество упустило самую важную методику бережливого производства, описанную как «ката улучшения». Ротер объясняет: в каждой организации есть свои привычные способы организации работы, и важнейший фактор в Toyota — то, они сделали улучшение повседневным процессом и встроили его в ежедневную работу всех сотрудников. Тойота Ката декларирует постепенный, повторяющийся, научный подход к решению проблем. Главная цель — достижение целей компании.

В 2011 г. Эрик Рис написал книгу The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses [183], обобщив опыт работы в IMVU, стартапе в Кремниевой долине, организованном в соответствии с принципами Стива Бланка, которые описаны в книге The Four Steps to the Epiphany, и использовавшем методики непрерывного развертывания. Эрик Рис также сформулировал такие важные методики и понятия, как минимально жизнеспособный продукт, цикл «создать — измерить — сделать выводы» и большое число шаблонов непрерывной поставки.

В 2013 г. Джефф Готельф написал книгу Lean UX: Applying Lean Principles to Improve User Experience. В ней описывалось, как улучшить «туманный front-end» и как собственники продукта могут формулировать гипотезы, проводить эксперименты и убеждаться в верности этих гипотез до того, как вкладывать время и ресурсы в возможные компоненты функциональности. Благодаря Lean UX у нас теперь есть инструменты, чтобы полностью оптимизировать поток между выдвижением гипотез, разработкой функциональности, тестированием, развертыванием и предоставлением сервиса пользователям.

В 2011 г. Джошуа Кормэн, Дэвид Райс и Джефф Уильямс изучили кажущуюся бесполезность обеспечения безопасности приложений и среды на поздних этапах жизненного цикла. В ответ на подобные заявления они создали принцип прочной разработки (Rugged Computing), благодаря чему формируется понимание таких нефункциональных требований, как стабильность, масштабируемость, доступность, выживаемость, устойчивость, безопасность, поддерживаемость, управляемость и защищенность.

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

В теории ограничений широко используется метод облака ключевых конфликтов (core conflict cloud, C 3). Вот пример облака конфликтов для IT-компаний (рис. 46).

Рис. 46. Ключевой хронический конфликт в любой IT-организации

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

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

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

Принципы шаблонов работы DevOps — те же самые, совершившие переворот в промышленном производстве. Они позволяют оптимизировать поток создания ценности и трансформируют потребности бизнеса в возможности и сервисы, удовлетворяющие нужды клиентов.