Всем привет!

Мы допечатали книгу «Философия DevOps», а также планируем делать и новую книгу на эту тему.


Немало копий сломано по поводу того, чем является и чем не является DevOps, а также о соотношении DevOps и непрерывной интеграции. Поэтому мы просим вас максимально объективно высказаться, разделяете ли вы точку зрения сегодняшнего автора Адама Маккея (Adam Mackay) относительно сути DevOps — либо, на ваш взгляд, предложенная им картина в чем-то неполна или ангажирована?

Читаем и комментируем!

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

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



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

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

У нас в компании прослеживается несколько ключевых DevOps-тем: ценности, принципы, методы, практики и инструменты.



Ценности

Любой инженер заточен на поиск решения, и такая устремленность порой выливается в неприятие новых технологий, нежелание экспериментировать с новыми вещами, что выражается по-разному: от синдрома «неприятия чужой разработки» до контрпродуктивных попыток защищать свою нишу. Чтобы по-настоящему перейти на DevOps, эти предубеждения нужно сначала признать, а затем преодолеть. Ни одна технология, ни Docker, Kubernetes или Amazon Web Services не решит ваших проблем, если вы не понимаете, в чем заключается ценностное предложение.



«Возьмемся за руки, друзья!» Снимок пользователя rawpixel с сайта Unsplash

Принципы

Принципы нашей компании основаны на модели Трех Путей. Ее разработали Джин Ким, автор “Visible Ops” и “The Phoenix Project” и Майк Орзен, автор “Lean IT.” Рекомендуем выстраивать такую среду, в которой стимулируется системное мышление, усиливаются циклы обратной связи, прививается культура непрерывного экспериментирования и обучения.
Постоянно думайте обо всей системе целиком. Спросите себя: «Как наладить еще больше циклов обратной связи?» Мониторинг, метрики и логирование – вот три таких цикла, которые помогают администраторам участвовать в проектировании. В здоровой DevOps-среде стимулируются процессы, способствующие созданию коротких и эффективных циклов обратной связи, примеры таких процессов – управление инцидентами, объективный анализ постмортемов, обеспечение прозрачности…



“Рукопожатие перед MacBook Pro”, снимок пользователя rawpixel с сайта Unsplash

Методы

Гибкое управление

Гибко = просто. Подразделяйте ваш проект на небольшие участки работы, ведите сборку, ограничивая незавершенность работы (progress limit), внедряйте циклы обратной связи и добивайтесь визуализации. Это – мой любимый элемент любого проекта; гибкие приемы управления дают более результативный выход, в том числе, улучшают пропускную способность и стабильность системы; сотрудники испытывают на работе не такой сильный стресс, получают больше удовлетворения от работы.

Сначала люди, затем процессы, затем инструменты

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

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

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

Управление изменениями



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

Инфраструктура в коде (Конфигурация в коде… Все в коде)

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

Практики

Во всех предыдущих IT-организациях, где мне доводилось работать, подход к проектам был таким: «давайте что-нибудь напишем… а потом поручим кому-нибудь это тестировать и развертывать». Такой метод плохо согласуется с планами Сроки сдвигаются, а когда команда разработчиков переходит к следующему проекту, эксплуатационные издержки становятся неподъемными.



“Американские горки под голубым небом и белыми облаками”, снимок пользователя Priscilla Du Preez с сайта Unsplash

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

Инструменты

Мы любим наши инструменты! Они помогают инженеру программировать, собирать, тестировать, упаковывать, выпускать, конфигурировать и отслеживать как системы, так и приложения. Мы мастерски владеем нашими инструментами и знаем весь спектр интересующих нас решений – как опенсорсных, так и коммерческих. До того, как начала развиваться парадигма DevOps, инновации и инструментарий пребывали в стагнации. Я долго пользовался тем же самым инструментарием, что и в самом начале карьеры (программирую с 2000 года). Многие инструменты, применяемые в DevOps, поразительно многофункциональны и помогают совершенно по-новому организовать жизненный цикл сервиса.



“Всевозможные столярные инструменты в мастерской” из подборки Barn Images с сайта Unsplash

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

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

Что дальше…

Скачайте образ docker и начинайте экспериментировать. Сделайте форк чужого кода и начинайте его надстраивать. Раскрутите сервер или кластер серверов при помощи Kubernetes. Вот вы и делаете DevOps. Начинайте на собственном компьютере, а затем переходите в облако.



“Мальчик, стоящий на лестнице и дотягивающийся до облаков”, снимок Samuel Zeller с сайта Unsplash

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