DevOps – это буквальное и фигуральное слияние процессов разработки и эксплуатации. Многие годы соответствующие группы в компаниях были разделены культурными и информационными барьерами, особенно типичным такое положение дел было в крупных корпоративных отделах ИТ.
Это разделение основывалось на простом принципе: разработчики занимались только кодом, специалисты по эксплуатации принимали код и следили за тем, чтобы он выполнялся. Отсутствие связи между двумя группами приводило к длительным циклам контроля качества и максимально редким рабочим развертываниям, что было обусловлено страхом простоев и нарушений работы.
Из-за внутриорганизационных границ, стремления избежать рисков и последовательных, основанных на принципе «водопада» методов поставки ПО, между масштабными обновлениями систем мог пройти целый год, а то и больше. Во многих крупных организациях такие методы применяются и по сей день.
Однако в последнее десятилетие ландшафт ИТ резко меняется. Разработчики, устав ждать, пока у отдела эксплуатации дойдут руки установить обновление, начали писать ПО, автоматизирующее эксплуатационные задачи. А специалисты по эксплуатации, в свою очередь, начали делиться знаниями и опытом с программистами.
В результате некогда четкие границы между разработкой и эксплуатацией начали размываться. Это привело к ускорению жизненных циклов приложений, к сокращению сессий контроля качества и к резкому повышению количества развертываний. Появились такие новые процессы, как непрерывная интеграция и непрерывное развертывание. Многие крупномасштабные приложения, созданные по методам DevOps, вводятся в рабочую среду несколько раз в день, а не в год, как раньше.
И это не мимолетная «мода». Тенденция автоматизации постепенно развивается уже около десяти лет, и сегодня соответствующее ПО и процессы достигли высокого уровня зрелости, а потому игнорировать приход DevOps в корпоративные отделы ИТ невозможно.
Организации, где все еще не понимают важности DevOps и не готовы к соответствующим изменениям, окажутся в отстающих.
Как DevOps влияет на разработчиков
Корни DevOps – в таких инструментах, как Puppet, который появился в 2005 году, еще до самого термина DevOps. Его автор Люк Канис, программист на Ruby, решил покончить с необходимостью постоянно вручную менять конфигурационные файлы Linux. Он хотел добиться того, чтобы можно было готовить к работе и конфигурировать Unix-подобные системы автоматически с возможностью повторения соответствующих процессов. Эту задачу Канис решил, написав на Ruby скрипт, который он и назвал Puppet.
Позднее появились другие похожие инструменты: Chef, Ansible, SaltStack и пр., – и вокруг каждого из них сформировались свои сообщества. Разработчики и специалисты по эксплуатации делятся знаниями, добавляя их в виде «рецептов» (recipe) в «поваренные книги» (cookbook), помогающие конфигурировать ПО нужным образом независимо от используемого дистрибутива Linux.
Конфигурационный инструмент позволяет разработчику программировать выполнение своего приложения. При этом система сама включает все необходимые зависимости, обеспечивая с помощью соответствующих скриптов их настройку и запуск в различных диалектах Unix. То, что раньше требовало недель ручного конфигурирования силами высококвалифицированных специалистов, теперь выполняется за считанные часы при помощи скрипта.
Хотя разработчики теперь могут развертывать код быстрее и проще, чем раньше, появилась новая проблема. Покончив с зависимостью от специалистов по эксплуатации, программисты вынуждены сами нести ответственность за сопровождение работающих приложений.
В связи с этим появился еще один класс инструментов – платформы в виде сервиса (PaaS). Провайдерами первых систем такого рода стали компании Salesforce и Google, но от разработчиков требовалось написание кода, привязывающего к конкретной платформе. PaaS достигли популярности, лишь когда компания Heroku предложила сервис, который давал возможность выполнять код и на других платформах с минимальными изменениями.
Системы PaaS базируются на принципах автоматизации DevOps – соответствующие инструменты применяются для настройки и выполнения кода на большинстве таких платформ. Но отличие в том, что приложения, работающие на PaaS, полностью управляемы: пользуясь интерфейсами программирования, можно запускать приложение, останавливать, масштабировать и следить за его работой. В рамках классического подхода DevOps вы сами создаете инструментарий для управления своими приложениями, а в PaaS необходимые для этого инструменты уже есть.
Говоря о DevOps, нельзя не упомянуть Docker и контейнеры. Главный недостаток PaaS в том, что платформа жестко задает архитектуру приложения. Если разработчику нужно больше контроля над средой, добиться этого, сохранив скорость и гибкость, можно с помощью контейнеров. Настройка среды с помощью Chef или Puppet с нуля может занять несколько часов, и при этом вы можете не получить точной копии исходной среды. А воспользовавшись контейнером, программист может воспроизвести среду Linux или Windows меньше чем за секунду, и это будет абсолютно идентичная копия оригинала.
За годы своего развития инструменты DevOps начали приносить разработчикам колоссальные преимущества с точки зрения продуктивности. Дни, когда программисты не задумывались об эксплуатации и проблемах масштабирования, уходят, а искусство выполнения приложений целиком автоматизируется с помощью кода.
Как DevOps влияет на эксплуатацию
Хотя революцию DevOps начали разработчики, распространилась она все-таки благодаря сисадминам и специалистам по эксплуатации, ведь соответствующие инструменты помогают повысить эффективность и их работы тоже. Именно средства DevOps резко изменили ландшафт корпоративной службы ИТ, так как способствовали появлению современных высокоадаптивных отделов эксплуатации.
До DevOps именно сисадмины отвечали за работоспособность крупномасштабных приложений. Им приходилось настраивать СУБД и веб-серверы, конфигурировать балансировщики нагрузки, управлять безопасностью, системами кэширования и т. п.
Принципы DevOps обеспечили высокую степень стандартизации, предложив эффективные методы развертывания, конфигурирования и эксплуатации множества серверов с использованием лишь нескольких инструментов, требующих минимального участия человека.
Роль группы эксплуатации сегодня состоит в том, чтобы развернуть и сопровождать предоставляемый по требованию сервис приложений – PaaS либо кластер для контейнеров Linux или Windows. Разработчики же развертывают приложения в готовой среде, а за ее обслуживание и масштабирование отвечает отдел эксплуатации.
Платформы и средства DevOps создали буфер, благодаря которому команды разработки и эксплуатации могут действовать независимо друг от друга. До появления таких инструментов существовал последовательный конвейер выпуска приложения. Перед тем как новое приложение развертывали, нужно было делать массу запросов в отделы эксплуатации и закупок, а затем дожидаться конфигурирования серверов.
С появлением средств DevOps разработчики получили возможность, пусть и с определенными ограничениями, самостоятельно развертывать приложения по мере необходимости в любое время. Группам эксплуатации больше не нужно заботиться о развертывании каждого приложения. Они по-прежнему отвечают за закупки оборудования и администрирование серверов, но соответствующие задачи решаются в более крупных масштабах, чем на уровне отдельных приложений. На специалистах по эксплуатации теперь лежит обязанность управлять автоматизированной средой DevOps, к которой у разработчиков есть прямой доступ.
Этот технологический буфер позволил разорвать последовательный жизненный цикл приложения, дав разработчикам и специалистам по эксплуатации возможность более тесно взаимодействовать. Возможно, выглядит противоречием то, что разрыв зависимости позволил сблизить соответствующие команды, но ведь главное здесь – не допустить ситуацию, когда «у семи нянек дитя без глаза». Если позволить работать программистам в рамках четко заданной системы (писать код для готовой к его приему среды), а команде эксплуатации – за пределами «контейнера», то между «няньками» будет четкое разделение ответственности.
Сами инструменты DevOps, то есть то, что сближает группы разработки и эксплуатации, стали экосистемой взаимодействия, где разграничение обязанностей размывается. Специалисты по эксплуатации очень хорошо знают оптимальные методы администрирования и сопровождения сложных программных систем. А разработчики умеют «обучать» компьютеры применению этих знаний без участия человека.
Работодателям сегодня все чаще нужны программисты с опытом эксплуатации и сисадмины с навыками разработки. Но в целом наибольшее воздействие DevOps на команды эксплуатации состоит в том, что их обязанностью все чаще становится контроль за работой среды выполнения приложений, которая предоставляет автоматизированные средства развертывания разработчикам.
«Добродетельный» круг
Знаменитое высказывание Марка Андриссена, инженера, инвестора и предпринимателя, одного из сооснователей Netscape Communications, о том, что «программное обеспечение пожирает мир» справедливо для сборки и выполнения приложений так же, как для вызова такси или бронирования гостиничного номера. На протяжении десятилетий сопровождение приложений лежало на плечах элитной группы высококвалифицированных сисадминов, а сегодня этим могут заниматься любые сотрудники отдела ИТ.
Большая часть соответствующих знаний не документировалась и передавалась устно, подобно фольклору – «из поколения в поколение». У конфигурационных файлов были форматы со своими особенностями, иногда настолько сложными, что приходилось отдельно держать специальные конфигурационные файлы, которые компилировались в окончательный формат. Знания о том, как и почему нужно менять те или иные настройки, были уделом избранных.
Использование DevOps стало превращать все эти «эзотерические практики» в открытые стандарты, подробно документируемые вместе со всеми изменениями. Соответствующие знания теперь можно превратить в программную логику, на основе которой строятся платформы в виде сервиса и кластеры Linux-контейнеров и которую можно дублировать, чтобы делиться с другими.
По мере того как разработчики осваивают знания об эксплуатации, а сисадмины совершенствуются в программировании, их роли объединяются. Границы уже сегодня стираются, и появляются все новые инструменты взаимодействия между группами, сотрудничество которых некогда было минимальным.
Docker, лидирующая платформа управления контейнерами, стала типичным плодом этой эволюции. Сервис GitHub дает разработчикам открытую среду обмена кодом и упрощенного взаимодействия. Docker Hub обеспечивает такую же простоту взаимодействия для сисадминов, запуская очередную волну перерождения методов развертывания инфраструктуры и управления ею.
DevOps продолжит развиваться. Всегда будет место для новых инструментов, фреймворков, тенденций, но главной путеводной нитью останется программная автоматизация. И если прежде благодаря ей появились непрерывная интеграция и поставка ПО, то сегодня группы эксплуатации получают полностью программируемую инфраструктуру.
– Lucas Carlson. How devops changes both dev and ops. InfoWorld. October 4, 2017