девопс в программировании что такое

Зачем нужен DevOps и кто такие DevOps-специалисты

Когда приложение не работает, меньше всего хочется услышать от коллег фразу «проблема на вашей стороне». В итоге страдают пользователи – а им всё равно, какая часть команды несет ответственность за поломку. Культура DevOps появилась как раз затем, чтобы сплотить разработку и поддержку и объединить их вокруг общей ответственности за конечный продукт.

Какие практики входят в понятие DevOps и зачем они нужны? Чем занимаются DevOps-инженеры и что они должны уметь? На эти и другие вопросы отвечают эксперты из EPAM: Кирилл Сергеев, системный инженер и DevOps-евангелист, и Игорь Бойко, ведущий системный инженер и координатор одной из DevOps-команд компании.

Зачем нужен DevOps?

Раньше между разработчиками и поддержкой (т. н. operations) существовал барьер. Звучит парадоксально, но у них были разные цели и KPI, хотя они и делали общее дело. Целью разработки было как можно быстрее реализовать бизнес-требования и добавить их в работающий продукт. Поддержка отвечала за то, чтобы приложение стабильно работало – а любые изменения ставят стабильность под угрозу. Налицо конфликт интересов – DevOps появился, чтобы его решить.

Что такое DevOps?

Вопрос хороший – и спорный: окончательно в мире об этом пока не договорились. В ЕРАМ считают, что DevOps объединяет в себе технологии, процессы и культуру взаимодействия внутри команды. Это объединение нацелено на непрерывную доставку ценностей конечным пользователям.

Кирилл Сергеев: «Разработчики пишут код, тестировщики его проверяют, а администраторы устанавливают финальный продукт на производственное окружение. Долгое время эти части команды были несколько разрознены, а потом появилась идея объединить их общим процессом. Так появились DevOps-практики».

Настал тот день, когда разработчики и системные инженеры заинтересовались работой друг друга. Барьер между производством и поддержкой стал стираться. Так появился DevOps, в который входят практики, культура и порядок взаимодействия в команде.

В чем состоит суть DevOps-культуры?

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

Важнейшее положение DevOps-культуры – именно решать проблему, а не просто применять DevOps-практики. Более того, эти практики внедряют не «на чьей-то стороне», а в весь продукт. Проекту нужен не сам по себе DevOps-инженер – ему нужно решение проблемы, а роль DevOps-инженера может быть распределена по нескольким членам команды с разной специализацией.

Какие бывают DevOps-практики?

DevOps-практики покрывают все этапы жизненного цикла ПО.

Игорь Бойко: «Идеальный случай – когда мы начинаем использовать DevOps-практики прямо при инициации проекта. Вместе с архитекторами мы планируем, какой у приложения будет архитектурный ландшафт, где оно будет располагаться и как масштабироваться, выбираем платформу. Сейчас в моде микросервисная архитектура – для нее мы выбираем систему оркестрации: нужно уметь управлять каждым элементом приложения по отдельности и обновлять его независимо от других. Еще одна практика – это “инфраструктура как код”. Так называют подход, при котором инфраструктура проекта создается и управляется при помощи кода, а не через прямое взаимодействие с серверами.

Дальше мы переходим на этап разработки. Здесь одна из крупнейших практик – построение CI/CD: нужно помочь разработчикам интегрировать изменения в продукт быстро, мелкими порциями, чаще и безболезненней. CI/CD покрывает и проверку кода, и заливку мастера в кодовую базу, и разворачивание приложения на тестовых и продуктивных средах.

На этапах CI/CD код проходит через quality gates. С их помощью проверяют, чтобы код, который вышел с рабочей станции разработчика, соответствовал заданным критериям качества. Здесь добавляется юнит- и UI-тестирование. Для быстрого, безболезненного и фокусированного разворачивания продукта можно выбрать подходящий тип деплоймента.

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

Чем полезны DevOps-практики?

Если бы мы писали учебник по современным практикам DevOps, на его первой странице значились бы три пункта: автоматизация, ускорение релиза и быстрая обратная связь от пользователей.

Кирилл Сергеев: «Первое – это автоматизация. Все взаимодействия в команде мы можем автоматизировать: написали код – выкатили – проверили – установили – собрали фидбэк – вернулись в начало. Всё это – автоматически.

Второе – ускорение выхода релиза и даже упрощение разработки. Заказчику всегда важно, чтобы продукт вышел на рынок как можно скорее и начал приносить пользу раньше, чем аналоги конкурентов. Процесс доставки продукта можно бесконечно улучшать: сокращать время, добавлять дополнительные контрольные метки, совершенствовать мониторинг.

Третье – это ускорение обратной связи от пользователя. Если у него есть замечания, мы можем сразу же вносить корректировки и тут же обновлять приложение».

Как соотносятся понятия «системный инженер», «билд-инженер» и «DevOps-инженер»?

Они пересекаются, но относятся к немного разным сферам.

Системный инженер в ЕРАМ – это должность. Они бывают разных уровней: от джуниора до chief-специалиста.

Билд-инженер – это скорее роль, которую можно выполнять на проекте. Сейчас так называют людей, ответственных за CI/CD.

DevOps-инженером называют специалиста, который внедряет на проекте DevOps-практики.

Если суммировать всё это, получается примерно следующее: человек в должности системного инженера исполняет на проекте роль билд-инженера и занимается там внедрением DevOps-практик.

Чем именно занимается DevOps-инженер?

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

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

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

Что должен знать DevOps-инженер?

По большому счету, у него должны быть знания из разных областей: программирование, работа с операционными системами, базами данных, системами сборки и конфигураций. К ним добавляется умение работать с облачной инфраструктурой, системами оркестрации, мониторинга.

1. Языки программирования

DevOps-инженеры знают несколько базовых языков для автоматизации и могут, например, сказать программисту: «Давай ты будешь делать установку кода не руками, а с помощью нашего скрипта, который всё автоматизирует? К нему мы подготовим config-файл, его будет удобно читать и тебе, и нам – и мы в любой момент сможем его изменить. А еще мы будем видеть, кто, когда и для чего вносит в него изменения».

DevOps-инженер может выучить один или несколько из этих языков: Python, Groovy, Bash, Powershell, Ruby, Go. Знать их на глубинном уровне не требуется – достаточно основ синтаксиса, принципов ООП, умения писать несложные скрипты для автоматизации.

2. Операционные системы

DevOps-инженер должен понимать, на каком сервере будет установлен продукт, в какой среде будет запускаться, с какими сервисами будет взаимодействовать. Можно выбрать специализацию на Windows или Linux-семействе.

3. Системы контроля версий

Без знаний системы контроля версий DevOps-инженеру никуда. Git – одна из самых популярных систем в настоящий момент.

4. Облачные провайдеры

AWS, Google, Azure – особенно если мы говорим про Windows-направление.

Кирилл Сергеев: «Облачные провайдеры предоставляют нам виртуальные сервера, которые прекрасно ложатся на рельсы CI/CD.

Установка десяти физических серверов требует порядка ста ручных операций. Каждый сервер нужно вручную запустить, установить и настроить нужную операционную систему, установить наше приложение на этих десяти серверах, а потом десять раз всё перепроверить. Облачные сервисы заменяют эту процедуру десятью строчками кода, и хороший DevOps-инженер должен уметь ими оперировать. Так он экономит время, силы и деньги – и для заказчика, и для компании».

5. Системы оркестрации: Docker и Kubernetes

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

Раньше каждым приложением занимался отдельный сервер – любые изменения в его работе могли повлиять на исправность приложения. Благодаря контейнерам приложения становятся изолированными и запускаются по отдельности – каждое на своей виртуальной машине. Если происходит сбой, не нужно тратить время на поиск причины. Проще уничтожить старый контейнер и добавить новый».

6. Системы конфигураций: Chef, Ansible, Puppet

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

Какую карьеру может построить DevOps-инженер?

Развиваться можно и горизонтально, и вертикально.

Игорь Бойко: «С точки зрения горизонтального развития, у DevOps-инженеров сейчас самые широкие перспективы. Всё постоянно меняется, и наращивать навыки можно по самым разным направлениям: от систем контроля версий до мониторинга, от управления конфигурациями до баз данных.

Можно стать системным архитектором, если сотруднику интересно разобраться, как работает приложение на всех этапах своего жизненного цикла – от разработки до поддержки».

Как стать DevOps-инженером?

А также можно посмотреть актуальные тренинги по DevOps на сайте Тренинг-центра EPAM.

Больше информации о DevOps-направлении на сайте.

Источник

Кто такой девопс и что он делает

Это как системный администратор и программист в одном лице.

Как обычно пишут программы

Традиционный цикл разработки программ выглядит так:

Кажется, что всё так и должно быть. Но в крупных компаниях с большими проектами у такого подхода появляется много минусов.

Минусы поэтапной разработки

Всё дело в том, что с таким подходом есть чёткое разделение зон ответственности. Допустим, у нас простая разработка, которая разделена по отделам так:

Проблема в том, что у каждого из этих отделов своё рабочее окружение: они сами следят за своими библиотеками, фреймворками и операционной системой. Из-за этого то, что работает у одних, может не работать у других.

В итоге все тратят время на синхронизацию требований к коду, компонентам, фреймворкам и библиотекам. Работа стоит, код не пишется.

DevOps-подход к разработке

Изначально термином DevOps описывали только сам подход к разработке софта, но потом этим термином стали называть новую профессию. DevOps-подход в общих чертах можно описать так:

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

Кто такие девопсы и что они делают

Чтобы всё это работало на практике, появились девопс-инженеры, или просто девопсы. Основная задача такого специалиста — настройка и поддержание в рабочем состоянии нужного софта в компании, а также автоматизация каждого этапа разработки.

Вот что может делать девопс-инженер:

👉 Главная задача девопса — сделать так, чтобы автоматизации было как можно больше и чтобы она действительно ускоряла разработку.

Что нужно уметь

Чтобы стать девопсом, нужно освоить много разного:

Если при этом девопс будет знать хотя бы на уровне джуниора выбранный язык программирования в компании — будет вообще идеально. Так он сможет учесть особенности языка и подобрать под него нужные инструменты.

Деньги

По данным Хабр Карьеры, в первом полугодии 2021 года средняя зарплата девопс-инженера — 171 тысяча в месяц. Джуниоры получают в среднем 82 тысячи, а сеньоры — 230 тысяч.

Что дальше

Скоро поговорим о докере и системах управления виртуальными контейнерами. Они здорово экономят время при разработке и позволяют быстро решать разные задачи. Например, с ними можно развернуть и полностью настроить кастомный вордпресс и все нужные сервисы всего за 4 минуты.

Источник

Чистый девопс: как возникло и развивалось понятие «DevOps»

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

А разобравшись со всем этим, в итоге можно обнаружить, что теперь и на вопрос «что такое DevOps» отвечаешь себе более четко.

Предыстория: как не утонуть в водопаде?

До разговора непосредственно о DevOps вспомним, что ему предшествовало.

Как известно, главная идея DevOps в эффективном сотрудничестве разработки («Dev») и эксплуатации («Ops»). Конечно, эффективное сотрудничество разных специалистов — это всегда хорошо, но почему именно в этом случае ему уделяют столько внимания? Потому что здесь оно помогает бизнесу добиваться многих важных для него целей: быстрее выводить решения на рынок, оперативнее восстанавливаться при сбоях и так далее.

А эти цели люди преследовали задолго до того, как слова «development» и «operations» сошлись вместе. Обратимся к истории.

Можно сказать, что разработчики в современном понимании (они сидели за терминалом и писали код) появились после 1957 года, когда изобрели первый высокоуровневый язык программирования FORTRAN. До этого как таковых менеджерских подходов к разработке не было — написание программ для тех самых компьютеров размером с дом было штучным продуктом. Но затем все стало меняться.

К концу 1970-х и 1980-х разработчики могли уже регулярно сидеть за рабочими станциями, писать код, компилировать его и тестировать на одном компьютере. Развертывание состояло из компиляции и копирования на десятки дискет. Компании начали открывать вакансии программистов для написания «исходного кода» — термина, который только недавно вошел в лексикон. Начал расти рынок коммерческого ПО и массовой разработки.

В 1970 году мир узнал о водопадной (или каскадной) модели разработки. Она была предложена американцем Уинстоном Ройсом — директором центра Lockheed Software Technology. Описанный подход напоминал конвейерное производство — вся работа распределялась по стадиям (анализ, проектирование, написание кода, тестирование, релиз), к следующей стадии можно было переходить только после завершения предыдущей. Никакие поздние изменения не допускались.

Это был прорыв — наконец-то появилась какая-то система, позволяющая контролировать разработку. Проблема была в том, что такой подход не годился для сложных проектов, где требовалась итеративная разработка (о чем и говорил сам Ройс).

Как писал Роберт Мартин в Clean Agile: Back to Basics («Чистый Agile», Питер, 2020): «Крупная работа не выполняется большими командами. На самом деле крупная работа выполняется большим количеством маленьких команд, которые в свою очередь выполняют много небольших задач. В 1950-х и 60-х годах программисты понимали это на уровне инстинкта. Но в 1970-е годы про это просто-напросто забыли».

Водопадная модель: ожидание и реальность

До 1990 года разработчики работали в основном по водопадной модели, пытаясь ее как-то модифицировать. Но даже она не спасала от проблем — дедлайны все равно срывались, бюджеты оценивались неадекватно, а конечный результат не всегда был предсказуем. По сути, до конца проекта заказчик не знал, что в итоге получит. К концу 80-х оформилась так называемая итеративно-инкрементальная разработка.

А к середине 90-x сообщество через боль и слезы наконец осознало, что принципы разработки необходимо перезагрузить.

В 2001 году в городке Сноуберд был составлен Agile Manifesto. Про сам манифест вы наверняка слышали, но обращали ли вы внимание на то, насколько тезисы «12 принципов Agile-разработки» близки DevOps? «Deliver frequently», «continuous delivery» — кажется, если заменить заголовок на «12 принципов хорошего DevOps» и запостить на Хабр, многие не заметят никакого подвоха.

Позже авторы манифеста развивали его идеи. В числе авторов Agile Manifesto, помимо того же Роберта Мартина и других известных людей вроде Мартина Фаулера, был Алистер Кокберн — и в 2004-м он описал методологию разработки ПО Crystal Clear. А дальше идеи подхватывали и развивали уже другие люди: например, в 2006-м системный администратор Марсель Вегерманн написал эссе на немецком языке, посвященное использованию принципов разработки ПО Crystal Clear, Scrum и Agile в области системного администрирования. Можете посмотреть его короткое выступление 2008-го по мотивам этой работы на Chaos Communication Congress.

Обращение Марселя не стало особо популярным, но оно показывает существование спроса на «Agile в эксплуатации»: не только в разработке хотели всё улучшить. В том же 2008-м системный администратор и Agile-практик Патрик Дебуа выступил на Agile Conference в Торонто с докладом «Agile infrastructure and operations», и сыграл куда большую роль. Но об этом чуть позже.

Дорога в облака

А что, кроме Agile, способствовало появлению DevOps? Изменение IT-ландшафта: появление новых технологий и реакция индустрии на них.

Например, в 90-е стали бурно развиваться интернет и облачные технологии. Это меняло многое — стал необходим новый способ разработки и доставки. В 1995 году появилась также СУБД MySQL, помогавшая создавать динамические веб-сайты и приложения.

Виртуализация программных и аппаратных сред возникла еще в 1964 году, с началом разработки ОС IBM CP-40, но стала массово востребованной позже. Виртуализация вводила дополнительный уровень абстракции между исполняемым кодом и системным ПО, разделяя разработку и эксплуатацию.

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

Со всем этим «быстрая доставка софта» превратилась в насущную потребность. Теперь бизнес требовал, чтобы софт создавался быстро, но при этом качественно и с минимальными издержками.

Для этого мало было просто писать код, нужно было качественно обслуживать его. Степень автоматизации росла, но эксплуатация явно не поспевала за разработкой. И в итоге, хотя Agile возник со стороны разработки, DevOps породили в первую очередь люди, которым были хорошо видны проблемы с operations.

Дебуа и другие

Одним из таких людей и был Патрик Дебуа. Он помогал министерству Бельгии с миграцией дата-центров и работал в связке с несколькими Agile-командами. Дебуа должен был координировать действия между командами разработки приложений и эксплуатационными командами (сервер, сеть баз данных).

Патрик столкнулся с тем, что между командами не было понимания и согласованности. При этом команда разработки работала по Agile и показывала высокую производительность. Тогда Дебуа решил провести эксперимент и внедрить Скрам в работу команды эксплуатации.

На конференции Agile 2008 в Торонто он выступил с докладом «Agile Operations and Infrastructure: How Infra-gile are You?», где рассказал о своем опыте изменения эксплуатационной работы. Он говорил о применении принципов Agile в инфраструктуре, а не при написании кода. Но в Agile-сообществе доклад широкого отклика не получил.

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

Выступление Патрика Дебуа на конференции DevOops 2020

А дальнейшему развитию движение обязано курьезному случаю. Программист Эндрю Клэй Шафер, интересовавшийся проблемами в IT, предложил на той же конференции провести встречу-дискуссию по гибкой инфраструктуре (Agile Infrastructure). Однако тема настолько не привлекла внимание зрителей, что он даже сам не пошел на свое мероприятие, посчитав его никому не нужным. А вот Патрик Дебуа пришел. И для него эта «фан-встреча, куда никто не пришел» наоборот стала сигналом, что раз кто-то ее придумал, значит, кому-то все-таки это нужно! Он связался с Эндрю и продолжил обсуждение гибких методологий в инфраструктуре с ним напрямую.

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

На конференции Velocity Santa Clara 2009 Хэммонд и Оллспоу вместе представили доклад 10+ Deploys per Day: Dev and Ops Cooperation at Flickr. Как можно видеть, хотя в названии еще не было слова «DevOps», до него осталось буквально полшага. Вот этот доклад:

В докладе они описали основной конфликт Dev и Ops: разработчики посвящают свою жизнь внесению изменений, а для эксплуатации любое изменение — возможная причина отказов и сбоев. Однако изменения жизненно необходимы бизнесу, а значит, вместо ведения войн задача Ops — дать бизнесу возможность развиваться.

Хэммонд и Оллспоу предлагали создавать инструменты, снижающие риск изменений и инструменты для быстрого восстановления после сбоев.

Также они предлагали следующее:

Общий контроль версий как для разработки, так и для эксплуатации.

Настройку одноэтапной системы сборки.

Развертывание за один шаг.

Журнал развертывания (Кто? Когда? Что?).

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

Нельзя сказать, что этот доклад немедленно перевернул индустрию: слова про «10 деплоев в день» для многих звучали либо враньем, либо безумием, либо пустым бахвальством крупной компании («ну они там могут себе позволить такое, а нам-то с этого что»).

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

Он называет её DevOpsDays («потому что Agile System Administration было слишком длинно») и впервые проводит в 2009-м в Бельгии. После завершения конференции ее участники продолжили обсуждать поднятые темы в Твиттере, где название мероприятия сократилось до хэштега #DevOps. А в итоге слово, стихийно возникшее как хэштег, прижилось настолько, что сегодня гугл находит его на миллионах страниц. Так что этим названием мы обязаны Патрику, хотя сам он совершенно не ожидал такого эффекта.

В 2010-м конференция DevOpsDays впервые прошла в США, и там это тоже дало плодотворную почву для дискуссий. Дэймон Эдвардс и Джон Уиллис тогда придумали аббревиатуру CAMS (Culture, Automation, Measurement, Sharing) — культура, автоматизация, измерение и совместное использование. Джез Хэмбл позже добавил L (Lean) — бережливый. Так были обозначены ключевые принципы DevOps и появился фреймворк для оценки готовности к переходу в DevOps.

Кстати, Джон Уиллис стал одним из ключевых людей для всего явления (например, как соавтор книги «Руководство DevOps»), много выступал в связи с ним, и одно из таких выступлений было на нашей конференции DevOops:

Служить и доставлять

Бывший технический директор компании Tripwire Джин Ким в работе The Three Ways: The Principles Underpinning DevOps (иллюстрации ниже взяты из оригинальной статьи) пишет про так называемые «Три пути» (или три принципа), которые позволяют добиться устранения отсутствующих связей между Dev и Ops.

Позже Ким стал соавтором бизнес-романов The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win («Проект “Феникс”», Эксмо, 2015) и The Unicorn Project (IT Revolution Press, 2019), герои которых идут именно по этим трем путям. Первая книга стала основополагающей для погружения и понимания процесса внедрения DevOps в компании.

В итоге «три пути» в DevOps-контексте возникают регулярно: например, на нашей конференции DevOops 2020 Виталий Дмитриев из «Липтсофт» тоже попытался вернуться к основам и рассказал о своем опыте применения «Трех путей».

Итак, что же это за три пути?

Первый путь: системное мышление

Первый путь — рассматриваем производительности всей системы в целом и сосредотачиваемся на создании ценности. Формируем требования, которые проходят через разработку и передаются в эксплуатацию. Там клиенту предоставляется новая ценность в виде сервиса.

Второй путь: усиление обратной связи

Второй путь — создаем петлю обратной связи. По сути цель любой инициативы по улучшению процесса — сократить и усилить петли обратной связи, чтобы нужные исправления можно было вносить постоянно.

Третий путь: культура экспериментов и обучения

Третий путь — создаем культуру, способствующую двум вещам: постоянному экспериментированию и извлечению уроков из неудач. Люди должны понимать, что повторение и практика являются предпосылками к мастерству.

Герои книги «Проект “Феникс”» вот так справляются с этой задачей:

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

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

Так что, дело в культуре?

По данным Gartner, к 2023 году 90% инициатив DevOps не оправдают ожиданий. Почему? Из-за неверного понимания сути концепции и неправильного подхода к внедрению. Раджеш Сетху, директор DevOps в Replicon сказал в 2018 году: «Основная причина того, что DevOps внедряется сложнее, чем другие методологии, заключается в том, что он объединяет культурные изменения с эксплуатацией и разработкой. Изменение бизнес-культуры — особенно в крупных компаниях с устоявшимися процессами — совсем не то, что можно мгновенно преобразовать на уровне людей, процессов и информации».

Всё это порождает неправильные ожидания, которые потом выливаются в разочарование. Реальная эффективность теряется за внешними атрибутами, так как на первое место ставятся инструменты, а не культура процесса.

К 2015 году идеи DevOps становятся популярней — они сулят успех в поставке ПО, но из-за отсутствия четкого зафиксированного определения разные компании начинают эти идеи понимать по-своему.

Это DevOps?

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

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

Инструменты

Твиттер-аккаунт «DevOps Борат» сообщает нам, что просто совершить ошибку — это в природе людей, а вот для автоматического распространения ошибки на все сервера без #devops не обойдешься.

Несмотря на шуточный посыл, здесь кроется стереотипное восприятие практик DevOps как набора инструментов. Часто, когда люди говорят, что используют DevOps, то подразумевают под этим, что используют Puppet для управления конфигурацией серверов, Ansible — для развертывания версий приложений, Cloudify — для оркестровки и так далее.

Но еще сам Патрик Дебуа в 2012 году говорил, что DevOps — это человеческая проблема. И согласно такому взгляду, важно не то, какой инструмент для чего используется. DevOps — это не инструмент, а ситуация, когда:

Разработка и эксплуатация работают в тесном сотрудничестве.

Всем понятна работа друг друга: разработчики знают систему, для которой пишут код (и приспосабливаются к ней), а администраторы знают код, который развертывают (и понимают, как это влияет на систему).

Всё разрабатывается в короткие итерации и может быстро развертываться (как инфраструктура, так и приложения), чтобы можно было сразу устранять ошибки.

Дэймон Эдвардс сетовал, что слов о важности культуры было сказано достаточно («Все начинается с культуры», «DevOps — это культурное и профессиональное движение», «Культура важнее инструментов» и т. д.). Но как только все соглашаются с тем, что культура превыше всего, разговор переходит к инструментами и… снова к инструментам.

В 2012 году, когда DevOps был уже достаточно популярен, один из основоположников фреймворка CAMS Джон Уиллис опубликовал мрачный твит с хештегом #devopsdead, где заявил, что убирает букву C (culture) из аббревиатуры CAMS. В ответ Патрик Дебуа посоветовал ему не отчаиваться.

Культура — это все-таки самая сложная часть DevOps.

Команды DevOps

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

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

DevOps и Agile

Например, об этом неоднократно говорил Михаэль Хюттерманн — Java-чемпион, инженер по доставке и эксперт по Agile и DevOps. В своей книге DevOps for Developers он пишет, что Agile обязательно должен внедряться в отдел эксплуатации и это позволит устранить конфликт между Dev и Ops.

DevOps-инженеры

Логично предположить, что если DevOps — это культура и процесс, а не инженерная специальность, то и DevOps-инженеров быть не должно, об этом мы уже писали. Сторонники такой позиции говорят, что это словосочетание появилось от желания менеджеров и HR-ов упростить себе жизнь: если появилась какая-то потребность (в данном случае в DevOps), то можно просто ввести роль, которая эту потребность закроет!

Другие возражают на это: существует много задач «на стыке», кто-то их должен выполнять, и если в компании выделили отдельную роль для таких людей, почему бы тогда не назвать их «девопс-инженерами»?

Вне зависимости от того, считаете ли вы это словосочетание осмысленным, бессмысленно спорить с тем, что люди его активно используют:

Так росла популярность «DevOps-инженеров» (вне зависимости от того, существуют ли они)

Тогда вопрос в другом: что люди им обозначают в реальности? Похоже, что совершенно разные вещи в зависимости от ситуации. А если помониторить вакансии «DevOps-инженера», то список требований может оказаться колоссальным. Практически всё и сразу — и разработчик, и сисадмин, и специалист по безопасности!

А вот как в 2021 году говорит о своей роли один российский DevOps-инженер:

Программист пишет код, а девопс его внедряет. Естественно, в работе тех и других есть куча нюансов. Мало просто внедрить код, для этого нужны соответствующие инструменты, а их много, и настройкой этих инструментов тоже занимается девопс. Еще он немного админ, разработчик и тестировщик. Задачи могут сильно отличаться в зависимости от компании. Я бы сказал, что нет единого определения того, кто такой девопс и что он должен делать. Это не проблема конкретной профессии — просто ИТ-сфера стала усложняться и появилось много абстракций.

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

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

DevOps сейчас

Итак, что же такое DevOps в 2021 году? Инструменты, люди, процессы? Умение писать на Bash скрипты для кофемашины?

Как и многие фреймворки гибких методологий, DevOps не имеет четкого определения, и каждая компания будет объяснять его по-своему. Но его главная идея DevOps — это культура сотрудничества, и эта идея оставалась неизменной всегда. Об этом говорили Патрик Дебуа и Эндрю Клэй Шафер, Пол Хэммонд и Джон Оллспоу, а теперь об этом говорят люди вроде Баруха Садогурского.

А что тогда изменилось за 12 лет существования понятия? Во-первых, практики DevOps постепенно меняли общий подход к поставке ПО. Из новомодного слова все превращалось в общепринятую норму. Как в свое время Agile стал стандартом в разработке, так и DevOps становится стандартом в поставке.

А во-вторых, как и Agile в свое время, идея получает дальнейшее развитие. Например, в 2020 году Патрик Дебуа выступал на нашей конференции DevOops c докладом DevSecOps: More of the same — back to the roots, и в частности рассказывал про то, как важно вернуться к основам и посмотреть, что стоит за модным словом «Devops». А сейчас, уже практически из зрелой методологии вырастает новая — DevSecOps. Ее жизнеспособность покажет время и практика, а пока еще раз напомним, что самое важное в DevOps — это люди и культура.

А напоследок зададим такой вопрос: если с понятием «DevOps» всё так неоднозначно, то какой тогда должна быть DevOps-конференция? Как сделать, чтобы она не превратилась в набор технических фактов про Kubernetes и Terraform (мало связанный с исходным значением слова), но в то же время не превратилась в пустословие «наша культура культурнее вашей культуры», где можно сколько угодно лить воду?

Мы не первый год проводим DevOops и считаем так: на девопс-конференции нужен баланс между этими составляющими. Поэтому программа у нас делится на разные логические блоки: есть про процессы и культуру, есть про SRE (вот тут всякие кубернетесы-терраформы), есть про Cloud Native.

Если вы согласны с таким подходом, то вам наверняка будет интересно на следующем DevOops, который пройдет 8–11 ноября. А если захотелось повозражать, дополнить, поделиться своим взглядом — добро пожаловать в комментарии.

Источник