Для чего программисту вообще использовать DevOps
2026-02-26 18:20 Diff
https://ru.hexlet.io/blog/posts/dlya-chego-programmistu-voobsche-ispolzovat-devops

Преподаватель Хекслета, инженер с 15-летним опытом и популяризатор идеи DevOps Антон Маркелов рассказывает, зачем программисту вообще использовать практики DevOps, почему нет двух одинаковых вакансий по девопсу и в какие мифы верят HR, компании и кандидаты.

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

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

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

Содержание

Ничего не работает, виноваты все

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

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

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

И тут начинается то, что на русский язык чаще всего переводят как «колодец» (по-английски silo, силос). Колодец — это коммуникационная дыра.

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

Как сделать так, чтобы новый функционал попал на продакшен и работал там быстро и хорошо? Кто за это отвечает? Ведь это продукт разработчиков, но при этом именно админы ответственны за продакшен.

DevOps придумали как раз для устранения этого коммуникационного колодца — вся команда должна работать заодно, а не спихивать друг на друга ответственность. До изменения инженерных практик так все и происходило: команда работала по разные стороны баррикад и не могла поделить ответственность. Современная же разработка совсем другая.

DevOps в современной разработке

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

То есть разработчик, выкатывая приложение в Kubernetes, вообще не задумывается о том, как оно будет запускаться на серверах: он манифест написал, запустил. А потом все как-то само на облаке с помощью магии запустилось.

Аналогично и со стороны админов: они знают, что к ним придет приложение, упакованное в Docker-образ. И им не надо больше думать, как его запускать, какие зависимости ставить. Docker-образ — очень самодостаточная история, и если образ правильно собран, то он запустится вообще везде.

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

Конкретно под коммуникационными практиками можно записать культуру постмортемов, knowledge sharing — когда разработчики учат админов поглубже залезать в кишки приложения, а админы учат разработчиков, как что-то сделать на продакшене, поэксплуатировать.

Соответственно, совместное планирование и общий пул задач — это не столько про инструменты, сколько про инженерную культуру в целом. Почему я заостряю на этом внимание? Потому что сейчас под DevOps чаще всего понимается набор инструментов: «Девопс — это тот, кто занимается CI/CD, мониторингом, выкаткой». Но коммуникационную и инженерную проблему, хоть это и является основной проблемой — одними инструментами не решить.

Но не все это понимают, поэтому случаются истории, про которые я расскажу дальше.

Когда Kubernetes есть, а DevOps — нет

Вот пример. У нас есть какой-то кластер из 10 машин. Если один сервер отказал, то вся рабочая нагрузка автоматически переезжает на живые тачки. Или если приложение упало, Kubernetes его автоматически перезапускает.

Kubernetes — эта штука, которая хорошо помогает в обеспечении высокой доступности и отказоустойчивости. Потому что Kubernetes — это self-healing system, которая умеет самовосстанавливаться.

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

Приложение в случае аварии может спокойно переезжать с одной тачки на другую. Соответственно, оно не должно использовать никаких файлов на локальной файловой системе: сегодня оно запустилось на одном сервере, а завтра — на другом.

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

Происходит обычный диалог: «Зачем вы поставили Kubernetes, если все работает точно так же, как раньше! Как падало, так и падает, только дополнительная непонятная сущность появилась».

Это происходит, когда DevOps спускается сверху, по палочной системе: «Все, через две недели начинаем работать по-другому».

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

К нам пришел девопсер

Чаще всего, DevOps — это просто еще один админ, который занимается CI/CD и мониторингом. Но ведь разработчики как не понимали, что как работает, так и не понимают. Админы как не понимали, что разработчикам надо, так и не понимают.

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

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

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

Появилось даже такое понятие — «T-shaped specialist». Это специалист, который глубоко знает свою основную сферу (ножка буквы T), но помимо этого обладает широкими, пусть и не супер-глубокими, знаниями в смежных областях.

Помимо подхода с попыткой нанять специального человека, есть и второй путь. Спускается десант ребят, задача которых заинтересовать всех практиками DevOps и настроить процессы внутри команды. Они называются enabling team, команда по внедрению инноваций.

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

Понятно, что как раз в таких случаях DevOps-инженеры — это специалисты с выделенной зоной ответственности.

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

У нас в компании практики внедрялись со стороны админской команды. То есть мы ребятам все настраивали и показывали: «Смотрите, как классно!». Раньше наши разработчики тратили два дня на то, чтобы написать админам и объяснить, как выкатить новое приложение. Сейчас даже не надо создавать заявку: можно выкатить новое приложение на продакшен с нуля за два часа. И два часа — довольно пессимистичная оценка.

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

И сейчас, к счастью, разработчики все больше понимают, что DevOps упрощает работу. Даже сам подход расширяется на все айтишные сферы: DevSecOps (developers security operations), DevTestOps (developers testing operations), и так далее.

DevOps перестает быть черной магией

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

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

Если суммировать, то DevOps — это набор практик, упрощающих коммуникацию и совместную работу подразделения разработки и эксплуатации. Для этого потребуются навыки на стыке: надо знать и эксплуатацию, и разработку.

Начинать обучение программированию с DevOps сложно, надо в любом случае иметь определенный опыт и знания. А еще навыки коммуникации с людьми, чтобы объяснять, зачем это все нужно, продавать идею команде. Поэтому от девопса требуется не только знание инструментов, но и умение выстраивать коммуникацию между командами — в современном IT навыки общения ценятся очень высоко.