В мире IT наметилась чёткая тенденция — использовать структурные методологии и принципы в процессе разработки и в IT-управлении (такие, как Scum или Agile Software Development). Обратная связь в процессе разработки, удержание разработки в русле потребностей бизнеса, поэтапное внедрение продукта и многое другое — объединило в себе понятие DevOps.

В англоязычных странах тема DevOps стала настолько популярной, что некоторые IT специалисты пишут «DevOps» в своих резюме. А в рунете об этом никто ничего даже не слышал. На момент написания этой статьи, мы не смогли найти ни одного русскоязычного источника по этой теме в Интернете.
Поэтому, мы решили познакомить русскоязычного читателя с принципом DevOps, следовать которому в скором времени заставит сама жизнь.
В основу этой статьи был положен перевод статьи Дэмона Эдвардса (Damon Edwards) What is DevOps?. Кое-что к переведенной статье мы добавили, а кое-что вычеркнули. А вот и результат:
Что такое DevOps?
Вы, должно быть, уже слышали термин «DevOps», если интересуетесь IT управлением. Тег #DevOps регулярно встречается в Твиттере. Встречи(meetup) DevOps и конференции DevOpsDays набирают обороты по всему миру.
DevOps имеет отношение ко всему, что улучшает взаимодействие разработчиков и пользователей. Кроме того, за DevOps стоят и более глубокие идеи, которые могут вести нас дальше обозначенных здесь целей.
DevOps… о чём это мы?
DevOps возник в ответ на очевидный разрыв между традиционно понимаемой разработкой, и традиционно понимаемым пользованием. Этот разрыв проявляется в возникающих конфликтах и неэффективности.
Ли Томсон (Lee Thompson) и Эндрю Шафер (Andrew Shafer) изображают этот разрыв «Стеной Непонимания», стоящей между разработчиками и IT специалистами. Эта «Стена» возникает из-за того, что мотивация, процессы и используемые инструменты у обоих сторон различны, если не противоположны.



Ребята, ориентированные на разработку, приобретают такой стиль мышления, в котором изменение — это то, за что им платят. Бизнес нуждается в них, так как вынужден постоянно отвечать изменяющимся требованиям. Такое восприятие побуждает разработчиков производить настолько много изменений, насколько это возможно.
IT специалисты приобретают иной стиль мышления, в котором изменение — это враг. Бизнес нуждается и в них, так как именно они обеспечивают его работу, поддерживают предоставление услуг на нужном уровне, на котором они приносят деньги. Пользователи противятся изменениям, которые могут подорвать стабильную работу. Сколько раз мы уже слышали о том, что 80% времени простоя вызвано нововведениями?
Видение мира и своей роли в мире фундаментально различается у разработчика и у пользователя. Каждый из них верит в то, что работает правильно, принося пользу бизнесу. Действительно, взятые по отдельности, они оба правы и всё делают правильно!
Ситуацию усугубляет то, что команды разработчиков и IT специалистов, зачастую располагаются в разных структурах компании (часто с разными менеджерами и конкурирующей корпоративной политикой), а иногда вообще работают в разных точках Земли.



В добавок к Стене Непонимания, разработчики и IT специалисты используют разные инструменты. Посмотрите на популярные инструменты, которые ежедневно используют разработчики. А потом взгляните, какими инструментами пользуются системные администраторы. Кроме некоторых исключений, типа баг-трекеров и SCM, ни те, ни другие не интересуются инструментами друг друга, и интеграции между их инструментами нет. Даже если в чём-то их инструментарий и совпадает, то пользователи и разработчики используют его по-разному.



Настоящая конфронтация начинается тогда, когда разработчик вносит изменения в приложение пользователя. Кто-то называет это новым «релизом», а кто-то — «внедрением». Но и те и другие согласятся с тем, что после этого начинаются проблемы. Это обобщённый сценарий, но если вы когда-либо участвовали в подобном процессе, то наверняка вспомните, о чём идёт речь.



Разработчики «перебрасывают» новый релиз «через стену» к IT специалисту. IT специалист, получив релиз, начинает готовиться к его внедрению. IT-шники вручную взламывают скрипты для внедрения, которые поставляют им разработчики, или создают собственные скрипты. Они также редактируют конфигурационные файлы под своё окружение, которое значительно отличается от окружения разработчиков или QA. В лучшем случае, они дублируют работу, которая уже была сделана для предыдущего окружения, в худшем — добавляют или обнаруживают новые баги.
Пользователь отталкивается от собственного понятия о правильном процессе внедрения, поэтому и вносит изменения в скрипты и конфигурации. Однако, как правило, на каком-то этапе возникает проблема, и к разработчикам снова обращаются для её разрешения. Пользователи требуют от разработчиков исправить ошибки. Разработчики отвечают, что всё прекрасно работало на их окружении, поэтому ошибки вызваны неправильными действиями пользователя. Разработчики часто испытывают трудности при диагностике проблемы, так как конфигурации, расположение файлов, а также процедура, которая завела приложение в проблемное состояние, отличаются от тех, которые ожидает встретить разработчик (это вообще возможно только в том случае, если политика безопасности разрешает разработчикам доступ к серверам).
Время быстро меняет мир, поэтому вернуть старое окружение, в котором всё работало правильно, бывает невозможно. То, что должно было стать обычным внедрением, заканчивается всеобщим и срочным обучением, в процессе которого, методом проб и ошибок, окружение приводится в работоспособное состояние.



Внедрение, очевидно, всегда является слабым звеном. Но оно — только часть того, что охватывает DevOps. Как утверждает Джон Олспо (John Allspaw), потребность в кооперации разработчиков и операторов появляется задолго до начала внедрения, и продолжается после него.
Какая польза от DevOps?
DevOps — это мощная идея, которая находит отклик на разных уровнях IT мира.
С точки зрения и разработчиков, и IT-специалистов, DevOps освобождает жизнь от источника многих изнурительных разногласий. Конечно, это не является магической панацеей, но если вы будете работать по принципам и методам DevOps, вы уберёте препятствия, которые съедают время и являются источником нервных расстройств. DevOps делает работу сотрудников эффективнее, ускоряет работу, и облегчает психологическую нагрузку. Кто-то может сказать, что DevOps является слишком недостижимой целью, но я готов поспорить, что он всё равно будет пытаться работать в этом ключе.



DevOps работает на бизнес, так как он подразумевает реализацию двух стратегически важных для бизнеса качества — это «Гибкость бизнеса» и «IT регулировка». В мире IT этими терминами оперируют редко, но они заслуживают внимания исполнителей, которые одобряют бюджеты и подписывают чеки.
IT регулировка (IT alignment) это: «желаемое состояние, в котором бизнес-организация способна эффективно использовать информационные технологии для достижения своих бизнес-целей. Как правило, для увеличения прибылей и усиления конкурентоспособной позиции на рынке»
DevOps помогает реализовать IT регулировку, распределяя роли разработчиков и пользователей, и организует совместную работу над задачами, которые ставит бизнес. И разработчики, и IT специалисты должны понимать, что они являются частью единого бизнес-процесса. DevOps культивирует мышление, которое позволяет видеть, что личные решения и действия каждого должны быть направлены на осуществление единого бизнес-процесса, независимо от структуры организации.


Гибкость в бизнесе является мерой «способности организации быстро адаптироваться к рынку и изменениям окружающей среды за счёт малых затрат».
Правда, разработчики вкладывают в слово «гибкость» свой, особый смысл. Но назначение и того и другого одинаково. Гибкая методология разработки (Agile Develpoment Methodology) создана для того, чтобы удерживать ход разработки в рамках потребностей клиента или компании, а также на производство качественного программного обеспечения несмотря на меняющиеся требования. Для большинства организаций, Гибкость воплощается в итеративной методологии управления проектами Scrum



Гибкость подразумевает быстрое взаимодействие и принцип обратной связи между заказчиками, которые принимают решения, и разработчиками, которые реагируют на эти решения. Если посмотреть на результат правильно функционирующей «гибкой» группы разработчиков, то можно обнаружить устойчивый поток усовершенствований, которые постоянно производятся в соответствии с потребностями бизнеса.
Однако, если посмотреть на весь цикл от разработки до пользования с точки зрения предприятия, польза от такой гибкости не всегда очевидна. Стена Непонимания включает в себя различие взглядов на процесс разработки. Разработка происходит в одном темпе, а использование ПО — в другом. Длительные перерывы в процессе внедрения продукта, превращают всю «гибкость» организации в водопадный цикл, которого она так хотела избежать. Не важно, насколько гибкая организация разработчиков. Менять инертную природу бизнеса будет чрезвычайно сложно, до тех пор, пока существует Стена Непонимания.


Именно DevOps позволяет получить выгоду от гибкости процесса разработки. Это становится ясно видно на уровне руководства компании. DevOps предполагает постепенное предоставление пользователю стабильно работающего функционала, который добавляется в работу пользователя одновременно с его появлением в процессе разработки.
Если вы собираетесь начать DevOps проект в своей организации, не забывайте о терминах «IT регулировка» и «гибкость бизнеса».
Как вдохнуть в DevOps жизнь?
При обсуждении большинства тем, гораздо проще найти согласие по поводу проблемы, чем по поводу пути её решения.
Если послушать, какие обсуждения ведутся сегодня по поводу DevOps, то можно обнаружить, что в основном обсуждаются три области, которые относятся к сфере DevOps:
1. Измерение и стимулирование изменений культуры — изменение культуры и системы поощрений не даётся просто. Однако, если не менять организационную культуру, реализация DevOps будет трудной, если не невозможной. Если вы хотите повлиять на культуру в бизнес-организации, вам нужно будет обратить внимание на то, как вы измеряете и оцениваете производительность. То, что вы измеряете, влияет на поведение и стимулирует его. Все участники цикла от-разработки-до-пользования должны понимать, какую роль они играют в бизнес-процессе, частями которого являются. Успех отдельных исполнителей, как и группы, следует мерить успешностью всего цикла от-разработки-до-операций. Такой подход к измерению производительности, заключается в том, что каждая группа измеряет и оценивает объективную производительность, основанную на том, что имеет значение для этой конкретной группы.
2. Объединённые процессы — важная тема DevOps, посвящённая тому, что циклы от-разработки-до-операций должны рассматриваться как единый, сквозной процесс. Индивидуальные методологии могут применяться к индивидуальным сегментам этих процессов (таких, как гибкость с одной стороны, и Visible Ops с другой), до тех пор, пока эти процессы не будут сведены вместе для начала объединённого процесса.
3. Объединённые инструменты — это, пожалуй, самая обсуждаемая область DevOps. Это и неудивительно, ведь технарям свойственно, хорошо это или плохо, сразу переходить к обсуждению инструментов, когда нужно решить какую-либо задачу. Если вы следите за сообществами, посвящёнными инструментам, таким, как Puppet, Chef, или ControlTier, тогда вы, скорее всего, уже знаете, насколько важную роль сейчас играет инструментарий для обеспечения связи разработчиков и IT специалистов. «Инфраструктура как код (Infrastructure as code)», «автоматизация по образцу (model driven automation)» и «продолжительное внедрение (continuous deployment)» — это всё концепции, относящиеся к области DevOps.
Джейк Сорофман (Jake Sorofman) описал типы инструментария, необходимого для реализации DevOps:
1.Библиотека программного обеспечения с контролируемой версией, которая гарантирует, что все составляющие системы правильно определены, последовательно распределены (shared), и имеют последнюю версию релиза. Разработка и QA(Quality assurance) в организации тянутся с одной и той же версии платформы, а рабочие группы разворачивают одну и ту же версию, которая была сертифицирована QA.
2.Глубоко смоделированные системы — в которых структурированное версией объявление системы описывает все компоненты, правила и зависимости, относящиеся к системе программного обеспечения, упрощая воспроизводимость системы по требованию, а также предоставление изменений без конфликтов.
3.Автоматизация задач, выполняемых вручную — изъятие ручных усилий из таких процессов, как исследование зависимостей и разрешение, конструкция системы, обеспечение, обновление и откат. Автоматизация, а не накопление людей, становится основой быстрого управления и контроля, в том числе и крупномасштабного системного администрирования без конфликтов.
Очень важно, чтобы все индивидуальные инструменты подразумевались составными частями единой цепи инструментария, который охватывает весь цикл от-разработки-до-использования (даже если тесная техническая интеграция не является приоритетом). Выбор инструмента и воплощение решений (на уровнях и цепи инструментария, и индивидуальных инструментов) должно производиться в контексте их воздействия на конечный результат жизненного цикла.
То чем DevOps не является
На мероприятии OpsCamp Austin, Адам Якоб(Adam Jacob) из OpsCode/Chef выступил против того, чтобы некоторые системные администраторы изменяли название своей профессии на «DevOps». И действительно, на Западе сейчас находятся «продвинутые» IT-шники, которые в определённых случаях выражают желание переписать название своей профессии или вписать DevOps в своё резюме, словно это некоторый вид деятельности.
Опасно считать «DevOps» профессией или особым видом деятельности. Ведь это делает DevOps задачей кого-то одного: «Вы DBA? Не беспокойтесь о DevOps, это задача команды DevOps. Вы эксперт по безопасности? Не беспокойтесь о DevOps, это задача команды DevOps».
Подумайте в этом ключе. Будете ли вы говорить: «мне нужно нанять специалистов Гибкой методологии разработки»? Может вы скажете:«мне нужно нанять специалистов по управлению развитием информационных систем Scrum?». Нет, вам просто нужны разработчики, менеджеры проектов, тестеры и системные администраторы, которые понимают, что такое Scum и Гибкая методология разработки. То же самое можно сказать о DevOps.