DevOps — одно из самых обсуждаемых явлений на технологическом рынке в последние годы, а вакансии, имеющие эту приставку, стали одними из самых дорогостоящих. При этом многие компании до конца не понимают, что означает DevOps, как с этим работать и для чего вообще можно использовать. Мы подробно рассказываем о том, чем сервисный подход к IT отличается от продуктового, о практиках использования DevOps, культуре внедрения и технологиях, которые сделают взаимодействие инженеров разработки и эксплуатации намного эффективнее.
- Александр Титов, управляющий партнер Экспресс 42, основатель сообщества DevOps Moscow: Я живу в понимании DevOps как набора практик по организации целиком всей разработки
- Владимир Утратенко, Head of Technology Platform в Сравни.ру, со-организатор сообщества DevOps Moscow: Многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке
- Виталий Рыбников, Lead Site Reliability Engineer в Tinkoff.ru: Компаниям нужен 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:
— Что такое DevOps
— Базовая книга по инженерным практикам
— Базовые вещи от гуру сферы
— Командные топологии и роли
— Все про SRE
Владимир Утратенко, 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 на нашем интенсиве «DevOps для программистов»
