Философия DevOps ー относительно новая концепция, которая включает в себя черты нескольких подходов. В современном IT-сообществе DevOps набирает все большую популярность. Вместе с тем продолжаются споры относительно определения DevOps, из которых рождаются противоречивые расшифровки этого термина. Но суть DevOps заключается как раз в том, чтобы качественно и гибко сочетать разные концепции и инструменты. Сложно однозначно сформулировать, что обозначает этот термин. DevOps ー гибкая философия, поэтому предлагаем рассмотреть все области, которые охватывает DevOps определение, и найти для себя наиболее оптимальное.
Определение DevOps
Понятие DevOps возникло на стыке двух взаимосвязанных тенденций. Первая подразумевала синергию Agile и Lean в операционной работе и фокус на гибких операциях. Вторая концепция имела более широкий охват ー взаимодействие между командами разработчиков и эксплуатацией на всех этапах создания и использования продукта или услуг (Operations: The New Secret Sauce). Джез Хамбл определяет DevOps как «междисциплинарное сообщество специалистов, занимающихся изучением создания, развития и эксплуатации быстро изменяющихся отказоустойчивых систем любого масштаба».
Такое определение DevOps все же довольно обширное и довольно расплывчатое. Например, в мире стартапов это пояснение DevOps, как и термин «DevOps разработчик», будет звучать слишком эзотерически.
Предлагаем рассмотреть более точную формулировку направления DevOps:
DevOps ー практика, в которой операционный менеджмент и разработчики взаимодействуют на протяжении всего жизненного цикла продукта или сервиса, от проектирования до разработки и поддержки продукта.
В отличие от других подходов в результате внедрения DevOps появляется такая характерная черта: Операционные сотрудники используют инструменты и практики, которые применяют разработчики и программные инженеры в разработке программного обеспечения. Эти практики охватывают и использование систем контроля версий продукта, и тестирование, и участие в оптимизации методологии Agile.
Интересно, что DevOps не слишком разграничивает субдисциплины системного администрирования. Что такое Опс? Понятие «Ops» включает в себя системных инженеров, системных администраторов, операционный персонал, администраторов баз данных, инженеров по качеству, релиз-инженеров. Определение «Dev» по большей части относится к разработчикам, но по сути охватывает всех специалистов, вовлеченных в разработку.
Подход DevOps тесно переплетен с Agile и Lean. Раньше те, кто входил в «Dev», считались создателями продукта или услуги. А «Ops» были теми, кто продолжал растить продукт или услугу. Со временем такой взгляд разрознил участников жизненного цикла продукта. Подход DevOps появился, чтобы наоборот усилить взаимодействие специалистов на разных этапах разработки и релиза программного обеспечения.
Можно сказать, что понятие DevOps эволюционировало из Agile, привнеся больше эффективности бизнесу. Теперь разработка программных продуктов подразумевает тесное сотрудничество и с бизнесом, и с клиентами, и с девелоперами, и с тестировщиками посредством DevOps. Таким образом, DevOps расширяет сферы применения Agile, выходя за пределы доставки кода.
Углубляемся в понятие DevOps
Термин DevOps охватывает слишком много методов и практик, чтобы иметь однозначное толкование. Одни утверждают, что DevOps ー это сотрудничество между разработчиками и операциями, или что DevOps касается принципа «инфраструктура как код». Другие дают отсылку к Agile-manifesto, использованию методов Kanban и Scrum, а также практики автоматизации во всех ее проявлениях. Есть мнение, что DevOps ー это практики использования эффективных инструментов на протяжении всего жизненного цикла продукта. На более высоком уровне DevOps можно рассматривать как культуру бизнеса.
Чтобы найти оптимальное определение DevOps, рассмотрим один из принципов ー гибкая разработка. Согласно Agile-манифесту, зафиксированному в Wikipedia, подход Agile состоит из четырех уровней вовлеченности (ценности, принципы, методы, практики). Добавим в этот список пятый уровень ー инструменты. Возможно, одержимость инструментами в DevOps уже выходит за рамки приличия, но упускать из виду этот уровень некорректно.
- Ценности Agile ー ценности и философия высокого уровня, заложенные в Agile Manifesto. Основные культурные особенности Agile.
- Принципы Agile ー стратегические подходы Manifesto, которые усиливают уровень ценностей. Необязательно использовать все принципы, но если не использовать их совсем, то это не про Agile-manifesto.
- Методы Agile ー процессы, с помощью которых реализуются принципы Agile. Это может быть XP, Scrum или ваш собственный процесс, разработанный внутри команды. Это уровень, на котором мы видим воплощение философии через практики. Нет обязательных методов Agile, но можно ориентироваться на возможные способы реализации принципов.
- Практики Agile ー тактические решения и приемы, которые применяются в гибкой реализации. Практики ー это Continious Integration, покер планирования, бэклоги, стендапы, различные артефакты, которые используются в разработке, и т.д.
- Инструменты Agile ー технические решения для реализации Agile-практик. Используются командами для оптимизации и облегчения работы в соответствии с методами Agile-manifesto. Например, GreenHopper, Jira, PlanningPoker и другие.
В идеале в схеме Agile-manifesto информация исходит от более верхних уровней к тем, что расположены ниже. Команды, которые применяют методы и практики DevOps или Agile не понимая, зачем это нужно, могут не видеть общей картины. Предлагаем рассмотреть уровни непосредственно DevOps культуры.
- Ценности DevOps очень схожи с Agile. Можно сделать поправку на то, что фокус DevOps ー на комплексном продукте или услуге, доставляемым заказчику, а не только на работающем программном обеспечении.
Высказывание о DevOps Алекса Хонора «Люди важнее процессов, а процессы важнее инструментов» перекликается с ценностями Agile и также призывает к взаимодействию между разработкой и операционными процессами.
- Принципы DevOps ー нет четкого списка принципов, хотя были неоднократные попытки из описать. Например, Джон Уиллис и его «CAMS», или Джеймс Тернбулл с его собственным определением. «Инфраструктура как код» часто упоминается как один из базовых принципов этой философии.
Многие перекладывают принципы Agile-манифеста на DevOps. На концептуальном уровне можно сказать, что DevOps ー расширение набора принципов Agile и выход их на все уровни, охватывающие доставку готового продукта заказчику.
- Автоматизация инфраструктуры. Создание систем, конфигураций, приложений в виде кода.
- Непрерывная доставка. Быстрое и автоматизированное создание и тестирование приложений.
- Инжиниринг надежности сайта. Удобное проектирование, управление, мониторинг и оркестрация системам.
Можно сделать вывод, что одна из ключевых идей DevOps ー понимание, что программное обеспечение не считается созданным до момента, пока оно не попадет к конечному пользователю продукта и не будет соответствовать его ожиданиям.
История DevOps
Направление DevOps начало развиваться как ответ на рост системных технологий и потребность в инновациях. В его основе лежат принципы администрирования Agile System Administration и практики движения Enterprise Systems Management (ESM).
ESM, возникшая в середине 2000-х, несмотря на годы усилий находилась в примитивном состоянии, и начали возникать попытки ее улучшения среди команд разработчиков. Джон Уиллис (он же whurley) и Марк Хинкль из Zenoss поддержали эту идею и проспонсировали BarCamp, посвященный ESM. На этом этапе было опровергнуто изначальное значение ITIL (ранее Information Technology Infrastructure Library) через подход «ITIL Lite» Visible Ops. Также на развитие концепции повлияло смещение фокуса от крупных корпораций (HP, IBM и CA) на менее масштабные компании, выпускающие продукты с открытым исходным кодом (напр., Spiceworks, Hyperic, Zenoss).
К тому же в 2008 году O’Reilly провели первую конференцию Velocity, посвященную производительности работы в Интернете. Конференция стала площадкой для обмена знаниями об инновационных практиках работы и администрировании. В 2009 были выпущены презентации о взаимодействии разработчиков и операций в крупных магазинах (напр., Flickr) и о том, как это способствует гибким и безопасным изменениям в веб-окружении. Такие инструменты как Puppet и Chef неплохо себя зарекомендовали в создавшихся условиях. Все больше специалистов Agile и DevOps стали задумываться о реализации новых Agile концепций.
Параллельно с этим Agile достиг пика в гибкой разработке и начал выходить из ниши к более распространенной практике. Это также дало толчок размышлениям над принципами администрирования Agile System Administration. Великобританец Гордон Баннер как раз сделал акцент на этом в своей презентации. В центр внимания встали процессы ー от Kanban до Lean и администрирования IT-систем.
В 2009 Патрик Дебуа и Эндрю «Clay» Шафер придумали термин DevOps, после чего Патрика провел первые DevOpsDays в Генте. Это дало мощный толчок развитию направления, и теперь, имея свое название, концепция стала быстро распространяться (OpsCamp Austin, Velocity и DevOpsDays в штатах). По мнению Патрика DevOps стал ответной реакцией на негибкость и разрозненность в имеющихся практиках. В статье Джона Уиллиса об истории движения DevOps хорошо описаны нити, которые переплелись в создании подхода.
Культура DevOps появилась в результате «идеального шторма», когда Agile и другие практики объединились в одно целое. Развивающаяся автоматизация, базовые и новые инструменты в администрировании, необходимость гибких процессов, совместная работа разработчиков и операций, а также провал тяжело реализуемых практик, таких как ITSM / ITIL, воплотились в гибкой разработке, и процесс развития DevOps ускорился. Чуть позже, благодаря лидерам мнений, сюда добавились принципы и подхода Lean.
Это не NoOps
А что если девопс подразумевает под собой выражение «Они забирают нашу работу!»? В IT-комьюнити есть мнение, что в DevOps разработчики пытаются перетянуть на себя задачи Operations. Отчасти в таком мнении о DevOps есть доля правды, но только доля. Не беспокойтесь, NoOps ー это не про подход DevOps.
Подобные мысли часто исходят от операций, которые считают, что разработчики с помощью DevOps хотят «свести на нет» все операции. Хотя на самом деле, первоначальные идеи DevOps исходят как раз не от разработки, а от людей, вовлеченных в Operations. Причина такого настроения в том, что в Operations процессы и практики развиваются не так быстро, как в разработке. Команды операций, в отличие от команд разработчиков, не успевают угнаться за технологическими тенденциями, внедрение которых необходимо для постоянного развития и успеха. Поскольку глобальный бизнес-климат становится быстрее и динамичнее, компаниям и командам необходимо больше практик и инструментов, в том числе и автоматизации, которые несут гибкость и помогают автоматизировать процессы. Это правило касается и Operations, которым необходимо искать и использовать эффективные способы решения операционных задач, включая автоматизацию рутинных процессов.
Исходя из такого подхода, и понимая, что операции просто необходимо ускорить и автоматизировать (и не только разработчикам) с помощью DevOps, Operations занимаются разработкой ускорения операционных процессов. Или разработчики пишут код, призванный помочь автоматизировать процессы в Operations. Некоторые изменения, касающиеся как разработчиков, так и операций, которые несет применение DevOps на практике, пугают. Но они и являются основой и катализатором развития сотрудничества между разработчиками и «опсами».
В командах, практикующих DevOps, есть специалисты, владеющие навыками как в разработке, так и операциях, и взаимодействие направлено на совместное создание лучшего продукта. Вытекающее последствие этого ー в операционной модели задачи низкого уровня можно автоматизировать. А, значит, квалифицированные технические специалисты уделят больше времени задачам высокого приоритета. И это положительное последствие DevOps.
Это не (просто) инструменты
Концепция DevOps подразумевает не только использование инструментов. Причина, почему необходимо развернутое определение DevOps, ー вероятность того, что многие пройдут мимо теории, сосредоточившись только на уровне инструментов автоматизации. Такой подход, без следования принципам культуры DevOps, будет ошибочным, антипаттерном концепции. Автоматизация в данном контексте ー это, скорее, проявление сильных сторон. Неразумная автоматизация может принести такой же вред, как и разумная ー пользу.
Такая же ситуация и в Agile. Работа по итерациям или применение подобных практик без взаимодействия, не даст высоких результатов. В командах, которые применяют методы Agile, не рассматривая принципы гибкой разработки, показатели будут ниже желаемых. Инструменты автоматизации полезны как в Agile, так и DevOps. Но без понимания, с какой целью их использовать, это напоминает ситуацию, когда неподготовленному человеку выдают оружие и заставляют идти в бой. В итоге возникает вопрос: «Что такое DevOps и можно ли использование инструментов называть применением DevOps» или говорить «инструменты DevOps»? Например, можно ли назвать метод покерного планирования гибким, потому что его использование делает вас гибким? Нельзя. Но этот инструмент часто используется в гибких методологиях, поэтому его уместно называть «гибким инструментом».
Совокупность инструментов, специально разработанных для применения в DevOps, без использования принципов мышления DevOps, не имеют ценности.
Это не (просто) культура
Давайте разберем, можно ли говорить о DevOps как о культуре. Некоторые считают, что девопс ー это культура, и применять это понятие к конкретному принципу или практике неверно. Такой подход тоже преувеличен. Например, Agile не помог тысячам разработчиков в момент, когда работа над ним остановилась на «культурном уровне» с призывами объединиться и начать применять практики. Как уже упоминали, DevOps ー это совокупность уровней, описанных выше в статье. И культурные ценности, и принципы бесполезны без применения практик, методик и инструментов. Конечно, можно постигать практику передовых технологий самостоятельно, много экспериментировать. Но лучше внедрять практические способы в совокупности с принципами, которые несет в себе культура. И в этой части обмен информацией и знаниями ー это то, что двигает к развитию и прогрессу.
Это не (просто) «девы» и «опсы»
Некоторые ребята продолжают говорить с долей обиды, что DevOps ー это не только разработчики и оперейшенс, но и специалисты по безопасности сайтов, и системные администраторы. На самом деле, все, кто участвует в разработке продукта, должны взаимодействовать и сотрудничать с самого начала. Это касается и менеджеров, и разработчиков, и операционных специалистов. Сюда относятся представители бизнеса, включая стейкхолдеров, и, к примеру, дизайнеры ー список вовлеченных сотрудников неограничен. Изначально разработчики, практиковавшие Agile, были заинтересованы в сотрудничестве с бизнесом. Позже встал вопрос взаимодействия на уровне «разработка – операции». С развитием DevOps сотрудничество стало охватывать все уровни создания и выпуска продукта. В этом случае девопс выступает в роли культуры, которая объединяет все уровни организации, а не только разработчиков и оперейшенс.
Это не (просто) должность
Нельзя просто взять команду Operations и назвать командой DevOps ー это делу не поможет. Равно как и от одной должности DevOps Engineer или DevOps/Agile специалист мало что изменится без принятия культурных ценностей и принципов, о которых уже достаточно поговорили в этой статье. Только изменения на уровне организации, а не выделение отдельной должности, помогут ощутить преимущества DevOps.
Но отказываться от названия позиции DevOps Engineer тоже не стоит. Использование такого понятия поможет выделить новый способ мышления, например, разработчика или системного инженера (сотрудничество, автоматизация, CI-запуск). Некоторые люди ограничиваются только своими прямыми обязанностями. Другие же готовы расширять круг деятельности, так как им не все равно, как развивается компания и какой вклад можно внести в развитие. На такие нюансы стоит обращать внимание рекрутерам и HR-менеджерам.
DevOps не значит «все»
Возможно, вы встречали и заявления типа DevOps ー это «все и везде!». Подход DevOps действительно должен быть применен на всех структурных уровнях, особенно в компаниях, которые исповедуют принципы Agile и Lean. Процессы гибкой разработки и применение DevOps-практик могут проходить параллельно в разных департаментах. Но в то же время, полностью перекраивать действия не должно быть первоначальной задачей DevOps. Принципы DevOps ー часть общей корпоративной культуры Agile, но в основе он несет то, как именно оперейшенс вовлекаются в гибкую разработку.
Некоторые перегибают палку, превращая DevOps в смешанную версию Agile и Lean или философию «всеобщей любви» в организации. Такой подход идеален на уровне визии, но по мере того, как внедрение DevOps технологий движется вниз по иерархии, видим, что в итоге имеем дело с интеграцией операционных процессов. Нельзя упускать из виду нерешенные проблемы с доставкой программного обеспечения и услуг, а также с надежностью и безопасностью. Если кто-то пытается использовать знания, полученные в результате применения DevOps, с целью консультирования других, это нормально. Но не стоит забывать, что большинство DevOps ー это технические специалисты-практики, которые постоянно в поиске новых удобных инструментов для своей работы.
Agile подразумевает собой гибкую разработку программного обеспечения, эволюцией чего стала гибкая организационная работа не только команд разработчиков. Поэтому DevOps лучше всего определить как «гибкая поставка программного обеспечения и гибкие операции». И поэтому понятие DevOps должно охватывать глобальные организационные инициативы, несущие ценностное предложение для компании.
Начало работы с DevOps
Нет четкого ответа, какой путь у DevOps. Есть оптимальное направление, которое работает в конкретной компании. Инициативы и практики DevOps применяются как сверху вниз, так и снизу вверх по оргструктуре, как специалистами компании, так и привлеченными консультантами по DevOps.
Сложно описать четкий план действий реализации DevOps. Он начинается с небольших изменений, которые постепенно распространяются по организации, как и в Agile. И это касается не только программного продукта. К примеру, вы узнали о принципах, ценностях или методах DevOps, которые оптимизируют работу, и делитесь этой информацией с коллегами из других департаментов. И так, постепенно, DevOps начинает вырисовываться в понятную схему.
