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

Внедрение DevOps — не просто хорошая идея, это бизнес-необходимость.

Чтобы получать максимум отдачи от технологий сегодняшнего дня — от серверов с виртуальными машинами и контейнерами до облаков, в которых все это работает — вам надо, чтобы ваши системные администраторы работали в связке с вашими разработчиками. Отсюда и возникли принципы и практики, соединяющие процессы разработок (development) и операций (operations) и обозначаемые комбинированным словом DevOps.

Чем DevOps может вам помочь? Ответ очень прост — DevOps укорачивает время разработки и операционного развертывания вашего ПО с месяцев до дней.

DevOps: что такое Agile и для чего это нужно?

Патрик Дебуа, по специальности ИТ-консультант, создал DevOps, чтобы замостить брешь между проектами и операциями посредством гибких принципов организации программирования Agile. Agile заменяет традиционные медленные методы программирования, такие как каскадная модель Waterfall.

В Waterfall деятельность групп разработчиков разбивается в последовательность нескольких сменяющих друг друга этапов: анализ требований, проектирование, спецификация, кодирование и тестирование. Несмотря на свою популярность, Waterfall имеет множество проблем. Во-первых, 80% всей работы осуществляется на последних 20% времени реализации проекта. На практике это означает, что когда проект приближается к дате своего завершения, программисты трудятся по 18 часов в день, тестирование осуществляется с головокружительной быстротой, а про контроль качества вспоминается лишь в последние минуты. Во-вторых, трудно исправлять программу, когда начальство просит внести в нее изменения. Возвращаться к истокам Waterfall-проекта, чтобы добавить новую функцию или изменить спецификацию, чрезвычайно мучительное дело.

В Agile этот подход заменяется четырьмя базовыми принципами:

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

В Agile с самого начала проекта в команды ответственных за программирование людей включаются пользователи, управленцы и системные администраторы. При этом из всех участников проекта часто формируются небольшие группы, которые проводят ежедневные совещания. Одним из самых популярных механизмов такой работы является Scrum, но существуют и другие методологии, например, Extreme Programming (XP). В DevOps для усиления эффективности этих подходов используются разнообразные DevOps-программы, такие как Ansible, Chef, Puppet или SaltStack.

DevOps: перешагнуть стену между разработками и операциями

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

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

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

По словам Джеймса Эркьюхарта, главного управляющего учебными сервисами Amazon Web Services, возможным DevOps делает «прежде всего виртуализация серверов, за которой последовали виртуализация хранения данных и сетей, что привело нас к идее разделения работы физических систем и цифровых функций, которых поверх них выполняются. ОС уже не прикованы к физическим серверам. Файловые системы уже не привязаны к конкретным вращающимся дискам. Для соединения между серверами уже не используются статически зафиксированные порты физических коммутаторов».

Раньше для работы систем постоянно требовалось непосредственное внимание к каждому отдельному серверу. Сегодня в ИТ почти все виртуализовано, и благодаря DevOps-программам разработчикам и администратором становится проще работать совместно. Одним словом, в этом новом программно-определяемом ИТ-мире компании могут двигаться вперед со скоростью разработки ПО.

DevOps: почему это важно?

Использование DevOps для вселения в программно-определяемый ИТ-мир несет много преимуществ.

Скорость

По данным опроса 4600 ИТ-специалистов, проводившегося в 2016 г. компанией Puppet, ИТ-департаменты с сильными процессами DevOps развертывают программные продукты в 200 раз чаще, чем малоуспешные ИТ-департаменты. Более того, они в 24 раза быстрее восстанавливаются в случае сбоев, и в три раза реже сталкиваются с неудачами при осуществлении изменений. Вместе с тем эти компании тратят вполовину меньшее время на решение проблем безопасности и на 22% меньше времени на незапланированные работы.

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

Это важно далеко не только для приложений на смартфонах. Скажем, если вы сможете ускорить производительность своего веб-сайта всего на секунду, вы сможете увеличить свои продажи на 9%.

Ананд продолжает: «Это означает потребность в легко доступной инфраструктуре, которую можно предоставлять по запросам; потребность в приложениях и коде, которые можно обновлять еженедельно или каждый день, а не раз в год. Стратегии цифровой трансформации эволюционируют, поскольку при великом множестве технологических изменений требуется быстрое реагирование. DevOps имеет критическую важность для цифровой трансформации, но скорее как движущая сила, чем как категорическое условие — вы становитесь более динамичными, быстрее создаете ценности и быстрее реагируете на рыночную обстановку».

Безопасность

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

Коллективная спаянность

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

Большой бизнес осознал значение всех этих факторов. Ежегодный отчет State of the Cloud компании RightScale показал, что уровень внедрения DevOps вырос с 54% в 2013 г. до 78% в 2017 г. Крупные предприятия всякий раз опережают в освоении DevOps средний и малый бизнес.

В то же время недавний опрос State of Application Delivery компании F5 Networks показал, что лишь 20% респондентов считают, что DevOps имеет стратегический эффект. По сравнению с более ранними опросами эта цифра выросла очень мало.

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

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

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

DevOps: какие инструменты потребуются?

Хотя DevOps является ИТ-философией бизнеса, требуются три сорта инструментов, чтобы все это заработало. Это программы для непрерывной интеграции и непрерывной разработки (CI/CD), ПО DevOps и программы для оркестровки контейнеров. Все это, в свою очередь, базируется на виртуальных машинах, контейнерах и облаках.

CI/CD-программы, такие как Jenkins, Atlassian Bamboo и Microsoft Visual Studio Team Services (VSTS), позволяют разработчикам регулярно передавать свои изменения кода в центральный репозиторий. Каждая регистрируемая порция кода далее проверяется путем автоматизированной сборки. Это позволяет рабочим группам обнаруживать ошибки на гораздо более ранних стадиях процесса разработки.

Согласно AWS, «главными целями непрерывной интеграции является ускорение поиска и исправления ошибок, улучшение качества ПО и сокращение времени, необходимого для валидации и выпуска обновлений ПО». Как отмечает Мартин Фаулер, главный научный сотрудник ThoughtWorks, «непрерывная интеграция не избавляет от ошибок, но значительно облегчает их обнаружение и устранение». CD соединяет все это с идеей, что весь принятый код должен быть готовым к продуктивному использованию.

У каждой CI/CD-программы есть своя определенная аудитория. Jenkins, старейший и самый популярный CI-продукт, представляет собой Open Source-программу, работающую на многих ОС и платформах. Ее популярность сделала Jenkins Open Source-стандартом для управления dev-стороной DevOps, от управления исходным кодом до передачи кода в продуктивную эксплуатацию.

Предметом гордости Bamboo является встроенная интеграция с Git через Bitbucket Server и JIRA Software. VSTS естественно служит хорошим выбором для компаний, которые в DevOps полагаются на Windows Server и Azure.

DevOps-программы, такие как Ansible, Chef, Puppet или SaltStack, решают одну задачу — управление серверной инфраструктурой в масштабе предприятия с минимальным вкладом сисадминов и разработчиков. ПО этого типа автоматизирует конфигурационное управление. При экономии рабочего времени это позволяет эксплуатировать сотни, если не тысячи серверов в расчете на одного сисадмина.

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

Каждая из этих программ работает несколько по-своему.

  • Ansible, самая новая из этих программ, упрощает сложные задачи оркестровки и конфигурационного управления. Ansible, ныне принадлежащая Red Hat, хорошо работает с ее Linux и ее облачными программами. Это позволяет администраторам писать командные скрипты в YAML.
  • Chef превращает инфраструктуру в код. На этом методе строится управление как облачными, так и внутренними ресурсами. В конечном счете Chef представляет собой фреймворк для автоматизации и управления инфраструктурой и приложениями. Более конкретно, Chef транслирует задачи системного администрирования в многократно используемые дефиниции, оформляемые в виде «справочников» (cookbook) и «рецептов» (recipe). Все это пишется на узкоспециализированном языке (DSL), являющемся диалектом Ruby. Поскольку рецептурный DSL являет собой Ruby DSL, все, что может делаться с помощью Ruby, можно делать и в рецепте.
  • Puppet выполняет аналогичную работу, предоставляя сервисы управления конфигурациями. Этот продукт использует клиент-серверный подход. Инструкции Puppet написаны на собственном DSL, тоже называющемся Puppet. Как и в Chef, он основан на Ruby. Считается, что Puppet более дружествен системным администраторам, чем другие DevOps-программы.
  • SaltStack тоже предоставляет вам возможности для инсталляции, управления и обслуживания вашей серверной конфигурации с помощью модели инфраструктуры как кода. То есть вам потребуется писать код для развертывания, управления конфигурациями и задания правил автоматического предоставления инфраструктуры. Это не сводится к YAML-скриптам, хотя они и составят часть этого кода. Вместо этого вы будете использовать практики разработки ПО, такие как контроль версий, тестирование, тестовые развертывания и шаблоны проектирования, для создания воспроизводимых, легко управляемых моделей.

В целом все эти программы позволяют вам создавать мастер-копии софтверных стеков и серверов, которые нужны для вашей работы. Отшлифовав их, вы сможете запускать в эксплуатацию тысячи идентичных экземпляров. Если вам надо что-то изменить — скажем, использовать для сервера баз данных MariaDB вместо MySQL — все эти программы позволят вам легко заменить СУБД на множестве серверов. Конечный результат — громадная экономия времени при развертывании серверов и ПО.

Хотя эти DevOps-программы хорошо работают для серверов и серверных виртуальных машин, они не предназначены для управления контейнерами. Вот тут вступают в игру Docker Swarm mode, Kubernetes и Mesosphere Marathon.

Контейнеры быстро становятся доминирующей технологией в использовании облаков, говорится в отчете 451 Research, в первую очередь потому, что для контейнеров требуется гораздо меньше системных ресурсов, чем для виртуальных машин. С точки зрения финансового директора суть дела состоит в том, что вы можете эксплуатировать на том же серверном оборудовании в 4–10 раз больше экземпляров серверов, чем с виртуальными машинами.

Управлять контейнерами непросто. Как указывает в своем отчете по внедрению Docker в реальном мире компания DataDog, занимающаяся мониторингом облаков, «краткость жизненного цикла и рост плотности контейнеров имеют существенные последствия для мониторинга инфраструктуры. Количество вещей, для которых нужен индивидуальный мониторинг, возрастает на порядок величины».

Конкретно, программы управления контейнерами содержат четыре сервиса:

  • Предоставление: эти инструменты могут предоставить нужные контейнеры или запланировать их выделение в контейнерном кластере и затем их запустить.
  • Конфигурационные скрипты: применение скриптов позволяет загружать в контейнеры ваши специальные конфигурации приложений точно так же, как вы, возможно, уже используете Juju Charms, Puppet Manifests или рецепты Chef. Скрипты пишутся в YAML или JavaScript Object Notation (JSON).
  • Мониторинг: эти инструменты следят за состоянием контейнеров и хостов в кластере. При отказе контейнера средство мониторинга запускает его новый экземпляр. При отказе сервера оно перезапускает контейнеры на другом хосте. Эти средства также выполняют проверки работоспособности систем и сообщают о неполадках в контейнерах, их виртуальных машинах и серверах.
  • Развертывание обновлений и откат: Когда вы выпускаете в работу новую версию контейнера или приложений, запускаемых из контейнеров, инструменты управления контейнерами автоматически их обновляют по всему вашему контейнерному кластеру. Если что-то пойдет не так, вам будет позволено совершить откат к последним известным работоспособным конфигурациям.

Каждая из этих программ работает на свой лад. В Docker Swarm mode, появившемся в Docker 1.12, контейнерная нагрузка распределяется по множеству хостов. Это, в частности, позволяет сформировать кластер (называемый словом swarm) на разнообразных хост-платформах. Docker является ведущей контейнерной компанией.

Kubernetes, самая популярная программа для оркестровки контейнеров по данным 451 Research и CoreOS, предлагает высокий уровень интероперабельности, а также функции самоисправления, автоматизированного развертывания и отката и оркестровки хранения данных. В плане самовосстановления возможности программы превышают всяческие ожидания. Kubernetes не имеет себе равных в автоматическом исправлении проблем. Если в контейнере происходит аварийный сбой, контейнер перезапускается настолько быстро, что зачастую вы сможете узнать про факт сбоя только при внимательном просмотре логов.

Наконец, Mesosphere Marathon представляет собой платформу оркестровки контейнеров для DC/OS (Datacenter Operating System) компании Mesosphere и проекта Apache Mesos. DC/OS является распределенной ОС на базе ядра распределенных систем Mesos. А Mesos — это система управления кластерами с открытым исходным кодом. Marathon использует свою партнерскую программу Chronos для интеграции управления унаследованными приложениями, сохраняющими текущее состояние, и контейнеризованными приложениями, не обладающими таким свойством.

DevOps: использование ИТ для успеха

Все это может показаться сложным, но служит единственной цели — перейти от старого стиля использования ИТ к новым упрощенным и легким в управлении программно-определяемым системам.

Рыночные победы сегодня достаются не самым зрелым и опытным компаниям, а тем, кто способен быстрее всего меняться и развиваться. Для многих предприятий это подразумевает внедрение DevOps.

Версия для печати