DevOps — что это такое и почему эти практики меняют мир разработки уже сейчас
2026-02-26 22:27 Diff
https://ru.hexlet.io/blog/posts/devops-chto-eto-takoe-i-pochemu-eti-praktiki-menyayut-mir-razrabotki-uzhe-seychas

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:

— Что такое 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-инженер:

  1. Понимает, что в индустрии «что-то происходит», нужно быть в тренде и пора изучать «какой-то там DevOps»
  2. По сравнению с классическим сисадмином больше задумывается об автоматизации и умеет программировать
  3. Начинает (ооочень медленно и потихоньку) думать о клиентах и бизнесе.

Куда расти 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 для программистов»