DevOps — одно из самых обсуждаемых явлений на технологическом рынке в последние годы, а вакансии, имеющие эту приставку, стали одними из самых дорогостоящих. При этом многие компании до конца не понимают, что означает DevOps, как с этим работать и для чего вообще можно использовать. Мы подробно рассказываем о том, чем сервисный подход к IT отличается от продуктового, о практиках использования DevOps, культуре внедрения и технологиях, которые сделают взаимодействие инженеров разработки и эксплуатации намного эффективнее.
Александр Титов управляющий партнер Экспресс 42, основатель сообщества DevOps Moscow: Я живу в понимании DevOps как набора практик по организации целиком всей разработки
У термина DevOps довольно много определений — что же это такое и какую проблему решает DevOps?
— Я бы обратился тут к основам — откуда вообще появился DevOps. Он появился в 2009 году — когда компании, которые занимаются продуктовой IT-разработкой, поняли, что они не могут это делать в рамках сервисных подходов к IT, которые были сформированы в индустрии на тот момент. Стало понятно, что в бизнес-процессах не работает эта сервисная история — когда разработчики работают отдельно от администраторов, которые поддерживают системы в классическом их понимании.
Патрик Дебуа, слушая доклад Джона Асплоу о продуктовой разработке в компании Flickr об организации работы, сказал, что основная проблема — в объединении разработчиков и администраторов. В итоге из этой проблемы и пошло название DevOps — это про то, как правильно организовать продуктовую разработку внутри компании. Когда команда делает продукт, а не IT-системы, которые просто поддерживают бизнес-процессы.
В целом я живу в понимании DevOps как набора практик по организации целиком всей разработки — и это не про сисадминов, и не про то, как Kubernetes выстраивается. Это про общее формирование подхода к продуктовой разработке. Тут ключевым моментом является формирование практики совместного сотворчества.
В сервисном подходе к IT это сотворчество было не обязательно — там все фокусируются просто на поддержке отдельных бизнес-функций. Сейчас же все сообщество ищет подходы в формировании творческой продуктовой разработки — в соединении производства и творчества. Для меня именно это является определением термина DevOps.
Какие практики входят в DevOps?
— Организация работы в команде, организация инструментов совместной работы, организация передачи опыта между разными специалистами в команде, инженерные практики по непрерывной поставке программного обеспечения. Плюс это практики observability — не мониторинг и логирование, а скорее понимание того, что происходит с процессом, и как пользователь взаимодействует с продуктом.
Как бизнес начинает использовать эти практики?
— В первую очередь компании нужно понять, что IT-направление — не сервисная история, а основная производственная функция. Нужно перевести IT из поддерживающей истории в зарабатывающую. Это первый шаг на уровне ментальности с точки зрения бизнеса. Дальше — нужно понять, каких компетенций тебе для этого не хватает, посмотреть на другие компании, которые в эту игру уже играют. Например, посмотреть на Google и Facebook — и увидеть, как они строят свои рабочие процессы, сравнить с производственными процессами в вашей компании.
После этого станут видны те компетенции, которых в принципе не хватает компании и продукту, который она делает. Их придется отстраивать каждой компании индивидуально — как организован процесс поставки ПО, как организована вокруг этого команда. Это те задачи, которые каждая компания решает только самостоятельно. По сути, решения этих проблем нельзя просто взять и скопировать — такая модель пришла из сервисного подхода, который мы стараемся изменить.
При сервисном подходе к IT компании берут лучшие практики с рынка и начинают их использовать — не задумываясь о причинах появления тех или иных решений. Внутри же продуктового подхода нужно выстраивать собственные кастомизированные процессы — искать то, что действительно нужно бизнесу, чтобы увеличивать ценность своего цифрового продукта.
Кто тогда такие DevOps-инженеры?
— К ним я отношусь как к временному эффекту. Мы сейчас находимся на водоразделе: моменте перехода IT из сервисной модели в продуктовую. В сервисной модели всегда такой подход, нужно закрывать функцию — для этого нужен специалист. Появилась странная штука DevOps? Не проблема, нужна роль, которая это закроет. И так появляется DevOps-инженер, который как Ops-инженер, но еще умеет что-то. Это мышление из старой модели, но уже про новые вещи. Люди еще не научились думать, как это делают настоящие продуктовые команды. Поэтому они ищут специалистов вот так — и просто не понимают до конца набор компетенций, который им нужен.
Читайте также
Как устроен функциональный диалект Лиспа Clojure и почему использующие его программисты восхищаются им
Если посмотреть на описание вакансий DevOps-инженеров, то там всегда указываются абсолютно разные требования — это и системной администрирование, и поддержка сложных платформенных вещей, и описание платформы в виде кода, и взаимодействие с продуктовой командой в сфере доставки кода, и еще многие и многие процессы. Это очень большое количество компетенций в одном специалисте.
Я могу сравнить это с периодом начала интернета — тогда была позиция веб-мастера, который и почтовые сервера настраивал, и верстку на HTML делал, и продукт курировал, и дизайн создавал. Сейчас каждая компетенция ушла отдельному специалисту. Точно так же произойдет и DevOps-инженером.
Зачастую в этом DevOps-инженере соединены все противоречия и недостатки текущей сервисной модели. Как только в компанию приходит DevOps-инженер, то у руководства сразу можно спросить — чем он будет заниматься. Окажется, что это либо фулстек веб-мастер, либо специалист с четко выраженными компетенциями — например, сисадмин. Тогда его так и нужно называть — инженер, например, по Continuous Integration. Однако пока в головах менеджеров, которые занимаются управлением в IT, это направление еще не разделилось, и они продолжают существовать в сервисной парадигме, а не думать продуктом и потребностями клиента или пользователей.
Думаю, что пройдет еще несколько лет, и DevOps-инженеры уйдут в историю, как веб-мастера. На их место придут отдельные инженеры по Continuous Integration, продакшн-инженеры, платформенные инженеры, которые работают с Kubernetes, специалисты, работающие с большими бэкенд-системами, такими как базы данных, и так далее. Так разделится эта профессия.
Что будет с DevOps в ближайшие годы?
— Все будет хорошо. В том смысле, что будут прописываться более четкие компетенции, появятся сформированные новые профессии внутри продуктовой разработки. Появятся организационные схемы — сейчас даже продуктовую разработку описывают таким образом: есть команда, внутри которой работают несколько DevOps-инженеров. Они помогают продуктовой команде выводить фичи в прод. Но на самом деле ключевым моментом является то, что все работают вместе, вместе несут ответственность за ошибки и отвечают за весь процесс — и продуктовая команда, которая делает код, и сервисные инженеры. Платформа, на которой идет разработка — принадлежит всем. И разделение, что если код не выкатывается, то виноват какой-то определенный инженер или команда — вредит всему подходу разработки цифрового продукта и взаимодействию с клиентом.
С точки зрения технологий у нас все уже есть, а вот с точки зрения культурных и организационных парадигм IT ждут серьезные перемены.
Важные ссылки про DevOps:
— Базовая книга по инженерным практикам
— Базовые вещи от гуру сферы
— Командные топологии и роли
Владимир Утратенко, Head of Technology Platform в Сравни.ру, со-организатор сообщества DevOps Moscow: Многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке
У термина DevOps много определений. Что это такое и какую проблему он решает?
— Исторически у нас существует стена непонимания между ребятами, которые занимаются разработкой, и ребятами, которые занимаются эксплуатацией. DevOps — это как раз соединение development и operations. Соответственно, девелоперы хотели пилить фичи, поставлять свежий функционал, а ребята из эксплуатации — болели за надежность и стабильность и, соответственно, не очень любили новые фичи.
Так происходит не везде, но это достаточно распространенная картина в индустрии. В 2009 году на одной из конференции ребята из компании Flickr рассказали, что смогли подружить разработку с эксплуатацией, и в итоге деплоить свой сервис больше десяти раз в день.
Буквально следом за этим Патрик Дебуа — один из идеологов DevOps-движения, собрал конференцию, на которую пришло неожиданно много людей — и из разработки, и из эксплуатации. Пришли те, у кого это тоже болело — и с тех пор пошло, что DevOps скорее история про то, как им работать вместе, про организационные изменения, которые для этого нужны, про софт, помогающий ускорить эти процессы. Во многом это именно про людей, культуру и то, как они делают свою работу.
Наиболее подходящим определением будет, что DevOps — это путь разработки программного обеспечения в технологических компаниях. Именно путь — то есть, непрерывный процесс. Внедрить DevOps нельзя — его можно разве что вырастить внутри компании, стать DevOps.
А что такое тогда DevOps-инженер?
— DevOps-инженер — это исторически сложившийся HR-термин. Когда история с DevOps начала распространяться, многие компании захотели применять эти практики, но начали использовать неверный подход. Условно, приходит начальник компании к HR и говорит, что нужно внедрять DevOps, но для этого нужно найти человека, который умеет с этим работать. В итоге HR начинает искать DevOps-инженера — так термин и появился. В целом это совсем некорректно, но, несмотря на наше отношение, термин сложился, им пользуются на рынке — и просто так отмахнуться от него мы уже не можем.
Люди, которых называют DevOps-инженерами, чаще всего представляют собой сисадминов — людей из эксплуатации, которые занимаются поддержкой и обслуживанием сервисов информационных систем и инфраструктуры. По сути, эта та же самая позиция сисадмина, но названная иначе — и с другой зарплатой.
То есть разницы между системным инженером и DevOps-специалистом особой быть не должно?
— И да, и нет. Существуют DevOps-евангелисты, которые несут эту практику и культуру — они помогают компаниям проводить организационные изменения. Таким образом, чтобы компания начала использовать DevOps — не нужно нанимать DevOps-инженера, бизнесу самому нужно становиться DevOps-ориентированным. Люди в компании начинают работать таким образом, чтобы сложилась эта синергия, а организационная культура должна измениться до того уровня, чтобы специалисты начали друг с другом взаимодействовать более эффективно.
Единственные настоящие DevOps-специалисты — это DevOps-евангелисты, которые несут в себе культуру, практики и организационные изменения. А тех, кого сейчас в сфере обычно называют DevOps-инженерами — сисадмины, на которых свалили все что можно, от поддержки продакшна, до построения процесса поставки и релиза программного обеспечения. При этом такие инженеры очень быстро выгорают — они не чувствую себя комфортно на своем месте, они не занимаются какими-то конкретными вещами.
Кто в компании должен внедрять DevOps?
— В первую очередь руководство компании по IT и технологиям. DevOps — это вещь, которая в первую очередь идет именно с этой стороны. Конечно, иногда запросы на DevOps приходят со стороны инженеров, которых что-то не устраивает. Но без непосредственного участия людей, которые управляют разработкой и эксплуатацией, ничего не заведется. DevOps во многом основан на организационных изменениях и процессах коммуникации людей из разных департаментов. Поэтому наиболее эффективным методом внедрения DevOps является задействование людей из IT-менеджмента, чем рядовых специалистов.
Как технически устроен DevOps?
— Одна из ключевых вещей в DevOps — практики Continuous delivery и все, что с ними связано. Принципиальная разница по сравнению со стандартными подходами к эксплуатации здесь в том, что мы к любой задаче относимся как к программному решению, которое можно реализовать с помощью написания кода: не важно, это вещь с которой работают внешние пользователи, это внутренний сервис или инфраструктура. В дополнение к этому важны архитектурные вещи, например, слабо связная архитектура, смысл которой, в первую очередь, в уменьшении количества зависимостей насколько это возможно, практики бережливого производства, вроде визуализации потока создания ценности и управления им. Кроме того, важны выполнение работы минимально возможными частями, практики мониторинга, а также культурных аспектов вроде поддержки взаимодействия между командами или продвижения идей трансформационного лидерства.
Каким будет будущее DevOps?
— Сейчас становится понятно, что все больше и больше бизнеса использует DevOps. Было какое-то исследование, что многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке. Это очень вероятно, учитывая, что темпы производства программного обеспечения растут и необходимы новые эффективные способы взаимодействия между участниками процесса разработки и процесса поставки ПО.
Виталий Рыбников, Lead Site Reliability Engineer в Tinkoff.ru: Компаниям нужен DevOps чтобы выживать, расти и развиваться в современном мире
У термина DevOps достаточно много определений. Что же всё-таки такое DevOps и какую проблему он решает?
— Верно, определений довольно много. В настоящее время есть определённая путаница с терминологией. Да и однозначного чёткого ответа нет, каждый эксперт скажет свою интерпретацию. Хотя с самим термином «DevOps» плюс-минус всё понятно и есть на кого ссылаться. DevOps — набор практик и культурное движение, которое позволяет сократить Time-to-Market и доставлять стабильный и качественный продукт клиентам.
Зачем компаниям нужен DevOps? Чтобы выживать, расти и развиваться в современном мире. Мир меняется, и теперь уже нельзя пройти прямой путь от точки А к точке В по чёткому ТЗ. Клиенты каждый день хотят разного и нового. Точка В постоянно убегает (привет, Agile) и мы не знаем, как к ней прийти наиболее быстро. Поэтому важны итеративные маленькие шаги (частые релизы), регулярные тесты гипотез, быстрая обратная связь от клиентов и регулярная корректировка нашего курса, а также право на ошибки и эксперименты. Тогда у нас будет наибольшее число клиентов, довольных нашим продуктом. А значит, наша компания получает наибольшую прибыль и бизнес работает!
Всем ли это нужно? Конечно, нет. DevOps имеет смысл внедрять преимущественно технологическим компаниям, которые разрабатывают цифровой продукт и для которых важен Time-to-Market в своей нише (время от начала разработки идеи, до того момента, как её увидят пользователи).
Можно подумать: «А что, собственно, не так? Почему нельзя просто взять и релизить чаще, ничего не меняя?»
Ну, вот нельзя. В классической схеме без использования практик DevOps все основные стадии разработки продукта (аналитика, разработка, тестирование, эксплуатация) проходят линейно, друг за другом, что крайне медленно. Сюда же мы добавляем организационные проблемы:
- изоляция между отделами, благодаря которой нет обмена информацией и необходимой глубины коммуникаций и доверия
- отсутствие ответственного за весь продукт
- разные KPI и приоритеты у dev, qa и ops команд, благодаря чему каждый «тянет одеяло на себя» и делает так, как ему лучше
- каждая команда изобретает свой велосипед, в котором понимает только она (крайне трудно переиспользовать опыт).
В итоге у нас релизы раз в пару месяцев, и те периодически откатываем. Новые фичи и гипотезы доезжают до пользователей прода ещё реже. Никто постоянно не следит за продакшеном, а восстановление после сбоев затягивается на дни или недели.
В случае же DevOps — все стадии разработки продукта идут одновременно и максимально быстро, потому что структура всех коммуникаций и разработки направлены именно на это. Корректно будет сказать, что DevOps — это не конечная чётко определённая цель, это движение, по которому идёт вся компания. Это способ разработки программного обеспечения. DevOps — это когда люди, технологии и процессы объединяются ради одной миссии — клиент-ориентированности.
Чтобы разобраться, какие конкретно принципы, практики и подходы рекомендуются в DevOps, есть несколько фреймворков:
- Три пути: принцип потока, принцип непрерывной обратной связи, принцип непрерывного обучения и экспериментирования
- CALMs
- Accelerate
Чем занимается DevOps-инженер в команде?
— В самой культуре и концепции DevOps, в её практиках и подходах нет такой сущности и выделенной единицы как DevOps-инженер. То есть или вся компания идёт по пути DevOps, или там и говорить не о чем. Но... есть теория, описывающая конечное состояние, а есть суровая реальность.
В жизни переход от «без DevOps» к «у нас DevOps» не бывает бинарным. Это длительный процесс, который в разных компаниях занимает разное время. Компания должна пройти этапы от «зарождения и прорастания идеи», к «DevOps-трансформации» и затем к финальному «непрерывному улучшению». Так вот, устоялось, что компании на первом и втором этапах называют «DevOps-инженерами» всех людей, использующих (или только начинающих) DevOps-инструменты.
Их можно понять, альтернативных терминов никто не предложил. Это не то, что бы «хорошо», но это реальность. Эдакий рудимент затянувшейся трансформации в российских реалиях. Все боятся и не хотят меняться, а чем крупнее компания — тем тяжелее и длительнее процесс. Однако я не замечал, чтобы компании, достигшие финала, продолжали «грешить» DevOps-инженерами. Куда-то они всё-таки деваются по мере взросления компании.
Чем занимается DevOps-инженер? Если проанализировать вакансии на hh.ru, то заниматься предстоит всеми ops-ролями сразу: сборка, деплой, CI/CD, развёртывание серверов, тюнинг ОС, поддержка приложений, поддержка баз данных, мониторинг, безопасность.
Набор ролей, которые ожидают на этой должности, варьируется от компании к компании. В маленьких компаниях, скорее всего, придётся заниматься всем и сразу. И это может быть как один человек, так и несколько, и даже целый DevOps-отдел. Неясно, что конкретно нужно, потому что нужно всё и сразу.
Ясность приходит позже. По мере взросления компании и смены парадигмы коммуникаций и вообще процессов, каждую роль занимает отдельный человек/люди с конкретной специализацией. И вот у нас уже появляются build-инженер, релиз-инженер, инженер платформы, DBA, Linux-инженер, SRE, специалист по безопасности и так далее.
Читайте также
Почему нумерация должна начинаться с нуля
Может ли программист стать DevOps-инженером? Как вообще становятся DevOps?
— Поговорим не совсем про реальность, но про идеальный случай, раз уж имеем дело с подобным собирательным образом. В идеальном случае DevOps-инженер, помимо глубокой технической экспертизы, разбирается в теме этого самого DevOps, и помогает распространять знания и практики, компетенции внутри компании (часть enabling team).
Стать таким персонажем может любой инженер: системный администратор, разработчик, инженер автоматизации, инженер платформы и т.д. Достаточно серьёзно углубить soft-skills, hard-skills, изучить культуру и практики.
Программист в некотором роде — идеальный кандидат, так как он изначально ближе всех к продукту и процессу разработки. Ему легче всех понять новые концепции, подходы и понять боль как Dev, так и Ops. You code it, you build it, you run it, you own it.
Как же приходят к DevOps? Это вот когда человек получил некий опыт работы в IT, затем начитался книжек, наслушался докладов, и в нём это откликается. Человек понимает, что больше нельзя жить как раньше! Хватит это терпеть! У него появляется жгучее желание сделать эту компанию лучше, изменить процессы, инструменты и подходы к работе и избавить коллег вокруг от регулярной боли и рутины!
Что стоит прочитать в первую очередь:
- Проект «Феникс»
- DevOps HandBook
- Accelerate
В чём разница между DevOps-инженером и системным администратором?
— В зарплате. Если серьёзно, могу предположить, что DevOps-инженер:
- Понимает, что в индустрии «что-то происходит», нужно быть в тренде и пора изучать «какой-то там DevOps»
- По сравнению с классическим сисадмином больше задумывается об автоматизации и умеет программировать
- Начинает (ооочень медленно и потихоньку) думать о клиентах и бизнесе.
Куда расти DevOps-инженеру?
— На самом деле — куда угодно. Самый популярный вектор — в SRE. Однако можно расти и в разработчика продуктовой команды, разработчика/инженера платформенной команды, архитектора, возглавить центр-компетенции, заняться развитием внутренних сообществ или перейти в enabling team. Всё очень зависит от кругозора, желаний и конкретной ситуации в конкретной компании. Каких-то конкретных ограничений нет, просто каждая из ролей подразумевает углублённую специализацию в ту или иную сторону.
Какие инструменты и технологии должен знать DevOps-инженер?
— Он однозначно должен знать базу и иметь хотя бы представление о многих вещах. Полноценный Ж-shape person. ОС/linux, сети, git, Docker, навыки разработки, базы данных, SQL, SDLC, CI, мониторинг и т.д. и т.п. Вот, кстати, довольно популярный универсальный «DevOps-roadmap» по инструментам и технологиям для изучения. А дальше нужно углубляться в конкретные инструменты под конкретные задачи, выполнения которых от тебя ожидают. Как мы помним, DevOps-инженер в разных компаниях будет заниматься абсолютно разным. Но ему точно потребуются soft-skills и навыки общения, так как общаться предстоит очень много.
Порекомендую пару известных сайтов для подбора инструмента под конкретную сферу/задачу, так как нынче их слишком много: раз, два.
Какие подходы и практики в своей работе используют DevOps-инженеры?
— Все принципы, подходы и практики трудно описать «коротко» и понятно. Перечислю основные технические практики:
- Быстрое и надёжное автоматизированное тестирование
- Динамические тестовые стенды
- Непрерывная поставка (CI, CD, TBD)
- IaC и версионирование всего как подход
- Непрерывный мониторинг и обратная связь
- Использование PaaS
- Кросс-функциональные команды
- Слабосвязанная архитектура
- Общая ответственность всех за свои решения
- Распространение знаний по командам и компании
- Привлечение команды безопасности на всех этапах SDLC
- и другие
Какое будущее ждет сферу DevOps?
— 2020 год наглядно показал, что переход в онлайн и цифровая трансформация для многих компаний не то что неизбежны, а жизненно необходимы. А значит, и перестройка на рельсы DevOps как часть цифровой трансформации – лишь вопрос времени, и останутся и выживут те, кто это осилит.
Сейчас на Хекслете сейчас нет курсов по DevOps, однако вы можете пройти курс «Основы Ansible», почитать наш гид по Docker, посмотреть о нем стрим, узнать чек-лист хороших инженерных практик в компаниях.
