воскресенье, 5 июня 2016 г.

Что такое DevOps?

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

DevOps схема

Определение DevOps

DevOps - новое понятие, являющееся объединением двух последних значимых трендов. Первый, так называемый "Agile в системном администрировании". Он поощряет применение практик Agile и Lean в области администрирования. Второй тренд - очень широкое для понимания значение, которое включает в себя взаимодействие между командой администрирования и программистами на всех стадиях разработки - от создания до обслуживания.
Другое определения дал Jez Hubmle :

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

Подобные определения, вполне понятны и просты, но довольно специфичны и применимы, только к проектам, вроде интернет startup'ов. Я убежден, что можно толковать DevOps более прагматично, как некоторые практики инженеров по администрированию и разработки. Взаимодействующие друг с другом на всем протяжении жизненного цикла сервиса. От проектирования, разработки и сопровождении в production'e. Основное отличие DevOps от других методологий состоит в использовании многих одинаковых техник, как для программистов, так и для инженеров администрирования.

Эти техники могут распространяться как на использования систем контроля версия для исходного кода, так и до участия в Agile процессе разработки.

Стоит уточнить, что DevOps не разделяется на две части: Ops - для релиз инженеров, специалистов по безопасности, системных администраторов, сетевых инженеров и администраторов баз данных (для краткости, буду называть их далее администраторы, а их работу администрированием) и Dev - для разработчиков, тестировщиков и пр.

agile схема

DevOps имеет сильное сходство с Agile и Lean методологиями. До его появления существовало четкое разделение на две сферы: Dev и Ops. К Dev относились те, кто пишет код и тестирует его. А к Ops - "люди, которые работали с продуктом, после его появления". Т.е. в индустрии эти два понятия были разрозненны, что и послужило основным вектором развития DevOps. Таким образом, его можно рассматривать, как ответвление Agile. Agile - это идеи, тесно объединяющие заказчиков, продукт менеджеров, разработчиков и (иногда) тестировщиков для быстрого, итеративного улучшения создаваемого продукта. DevOps говорит нам, что доставка продукта до конечных пользователей является такой же важной частью, как и разработка. Если присмотреться, то в DevOps можно разглядеть лишь простое дополнение Agile принципов, расширяя рамки их применения от "кода" до "процесса развертывания и обслуживания".

Более полное определение

agile manifesto
Как было сказано выше, DevOps включает множество различных идей в различных сферах, поэтому его обсуждение затрагивает множество областей. Бытуют мнения, что DevOps это - "объединении разработчиков и администраторов", или "взгляд на код, как на часть инфраструктуры", или "использование автоматизации", или "использование Kanban", или "применение определенного набора инструментов", или "культура". Таких определений множество и они показывают DevOps с различных сторон. Лучший путь дать более полное определение - это попытаться использовать такой же подход, как и при определение таких же схожих сложных понятий, как например, Agile. "Agile разработка", согласно wikipedia и Agile манифесту, содержит четыре уровня определений. Я добавил пятый, инструментальный - который, думаю, будет полезен и дополнит описание.

  • Agile ценности - философия и основные идеи. Они отражены в Agile манифесте. Собственно, они составляют "основной фундамент" для методологии.
  • Agile принципы - соглашения по применению Agile ценностей. В Agile манифесте их приведено около дюжины.
  • Agile методы - более специфичные реализации принципов. XP, Scrum, ваши собственные процессы - это то, что мы применяем в реальной жизни. Ничто из них не является базовым, они лишь возможные реализации.
  • Agile практики - высокоуровневые техники, используемые в сочетании с Agile реализациями. Совсем не обязательно, чтобы они относились к Agile, но многие Agile реализации обращают внимание на значимость их применения, например standup'ы, покер планирования, backlogs, CI и пр.
  • Agile инструменты - набор определенных инструментов, реализаций Agile практик, используемые командой для упрощения работы с Agile методами. Ими могут быть : JIRA Agile, planningpoker.com и т.д.

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

  • DevOps ценности - я убежден, что базовые ценности DevOps точно отражены в Agile манифесте, с незначительными поправками - фокус нужно перенести на весь сервис или программное обеспечение, включая и его доставку к пользователям. Некоторые предыдущие определения DevOps высказанные, например, в книге Alex Honor "People over Process over Tools" повторяли основные положения Agile манифеста с упором на взаимодействие Dev и Ops.
  • DevOps принципы - здесь, нет одного единого принятого списка, но есть несколько широко известных попыток их определить, наиболее известная из них - это
    Код, как часть инфраструктуры
    . Так же можно процитировать Agile манифест с поправкой на DevOps. Лично, я верю, что концептуальные принципы и ценности DevOps согласуются с Agile манифестом, расширяя его до систем и работой с ними, а не останавливаясь на проверке кода.
  • DevOps методы – приведу некоторые из них: использование SCRUM с администрированием, Kanban с администрированием, и пр. Несмотря на то, что большое внимание уделяется интеграции администрирования и разработки и тестирования, есть и ярко выраженные методы для администраторов. Например, контроль изменений в стиле Ops (Visible Ops-style change control) или использование командной системы инцидентов (Incident Command System) для инцидентных откликов. Стоит так же добавить, что количество таких методов постоянно растет.
  • DevOps практики - специфичные техники используемые, как часть реализации выше приведенных методов и идей. Непрерывная интеграция и непрерывный deploy, использование менеджеров конфигурации, метрик и схем мониторинга, набора инструментов для использования и т.д.Список практик достаточно большой. Даже применение виртуализации или облачного вычисления является общими практиками ускорения внесения изменений в современном инфраструктурном мире.
  • DevOps инструменты - инструменты позволяющие реализовывать DevOps принципы. В мире DevOps произошел бурное развитие инструментов для выпуска релизов (Jenkins, Travis, Teamcity), конфигурационных менеджеров (Puppet, Chef, Ansible, Cfengine), координации (Zookeeper, Noah, Mesos), мониторинга, виртуализации и контейнеризации (AWS, Openstack, Vargrant, Docker) и многое другое. Говоря про "DevOps инструменты", нужно четко понимать, что это не тоже самое, что и "Agile инструменты". Их принадлежность к DevOps может оказаться совсем неочевидна. Однако, для "инструментов DevOps" (так и для Agile), справедливо, следующее - они не принесут в вашу организацию магическим образом DevOps (или Agile).Это произойдет, только в связке с приведенными выше методами, принципами и практиками, а так же с целостным пониманием DevOps.

DevOps немного размытое понятие, подобно своему старшему брату Agile. Но оно от этого не делается хуже. Когда у нас есть только теоретические уровни, мы сталкиваемся с пустотой. Появляются возгласы вида: "Что мне конкретно нужно сделать, чтобы улучшить мою работу?". И напротив, если мы будем использовать только одну практику без теории, тогда все это сведется к «карго культу».

Я использую Chef, значит ли это, что мы работаем в стиле DevOps?
Для успешного применения Agile или DevOps, необходимо понимание всех, без исключения, уровней. Следовательно, какие то инструменты могут содержаться в данной DevOps реализации, а какие то нет. Подытожим, DevOps принес в Agile понимание того, что работающий без ошибок продукт еще не конечная цель, пока он не был успешно внедрен и им не стали пользоваться. При этом, должны оправдаться пользовательские ожидания. А именно продукт/сервис должен быть доступен, иметь заявленную производительность и пр.

История возникновения DevOps

Причиной зарождения DevOps послужила необходимость в увеличении количества внесения изменений в продукт. DevOps стал наследником движений "Agile Системное администрирование" (Agile System Administration) и "Управление Промышленными системами" (Enterprise Systems Management, далее, для краткости, буду называть ESM) ESM, появилась в середине 2000 года. Импульсом её создания могла послужить фраза:

Эй, наши методологии по созданию систем, спустя годы, все еще в довольно примитивном виде. Давайте, начнем говорить о том, как сделать её лучше
John Willis и Mark Hinkle взялись за это. Я думаю, во время этого этапа, начались процессы улучшения ITIL, как структуры управления до уровня "ITIL Lite", подхода DevOps. Так же, сместился фокус от больший поставщиков (HP, IBM и CA), производящих значимые законченные решения в сфере систем управления, к более простым и открытым, вроде SpiceWorks, Hyperic, Zenoss и другие.

devOpsDays логотип
Так же в 2008 году, состоялась первая Velocity конференция, основанная O'Reilly, фокусирующая на производительности веб приложений и администрировании. Она являлась местом активного обмена информаций о лучших практиках и методах администрирования. В 2009 году на ней выступили с рядом важных презентацией. Темой докладов была объединение разработчиков и администраторов в больших online магазинах и их влияние на безопасное и быстрое внесение изменений в веб окружение. Появившийся инструменты, например Puppet и Chef, там тоже были продемонстрированы. Все больше людей начало задумываться об этих идеях и задаваться вопросом их использования.

В тоже время, в среде программистов, набирала популярность "Agile разработка". Это спровоцировало к выделению общих идей в отдельное направление Agile системное администрирование. Gordon Banner, впервые рассказал о нем в презентации на Velocity конференции. В ней, много внимания уделялось адаптированию в сфере системного администрирования Kanban и Lean производственных процессов. Затем в 2009 году, Patrick Debois из Бельгии и Andrew Shafer из Соединенных штатов впервые заговорили о DevOps. Затем, Patrick организовал первое DevOpsDays мероприятие. Новые идеи бурно обсуждались в Европе и быстро проникли в Соединенные штаты. С точки зрения, Partick Debois, DevOps появился, как:

ответная реакция на застой и окостенелость существующих практик
Появление DevOps застало бурное развитие автоматизации и появления обширного набора вспомогательных инструментов. Большие и громоздкие ITSM/ITIL больше не удовлетворяли текущим потребностям в объединении "Dev" и "Ops" и реализации Agile процессов.

Чем DevOps не является?


Это не отказ от администрирования «NoOps»

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

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

разработчик и администратор

Это только инструменты

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

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

Не является только культурой

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

Охватывает не только разработку и администрирование.

Понятие DevOps не исключает другие области. Некоторые люди задаются вопросами "А как же специалисты по безопасности? И сетевые администраторы! Почему они остались в не удел!?!?!". Важный момент, все люди участвующие в создании продукта или системы должны объединиться с самого начала - сторона заказчика, разработчики, администраторы (системные, сетевые), специалисты по безопасности и кто либо еще. В Agile процессах принято объединение бизнеса и разработки. Ошибочно полагают, что DevOps объединяет разработчиков и администраторов. На самом деле, она объединяет всех людей, каким либо образом, участвующих в создании продукта.

Это не (только) название специальности.

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

Как внедрить DevOps?

Здесь нет какого то универсального правила. Все специфично, сугубо для каждой организации. Успешный DevOps процесс может быть налажен между разработчиками и командой администраторов, сверху вниз, или в направлении от недр компании, наружу к консультантам. Довольно сложно дать практические рекомендации, как реализовывать DevOps. Наиболее верно, я думаю, начать с себя, изучить основные принципы, практики, ценности DevOps и рассказать о них своим коллегам. Начните сами реализовывать какие то вещи в стиле DevOps, и результат не заставит себя ждать. Люди делятся своими успешными внедрениями DevOps, но такие советы очень конкретны для каждой компании. Изучите, как другие популярные вещи были внедрены в вашей организации и попробуйте, таким же образом, внедрить и новые. Так же, не переставайте изучать DevOps.


исходная статья на английском