Преподаватель Хекслета, инженер с 15-летним опытом и популяризатор идеи DevOps Антон Маркелов рассказывает, зачем программисту вообще использовать практики DevOps, почему нет двух одинаковых вакансий по девопсу и в какие мифы верят HR, компании и кандидаты.
DevOps — это подход, который упрощает работу между разработкой (development) и эксплуатацией (operations). Эти подразделения очень разные, и поэтому для их совместной работы нужны не только технологии, но и здоровая коммуникация.
Несмотря на то, что DevOps — именно набор практик, у меня в резюме все же написано «DevOps-инженер». Этому есть довольно простое объяснение — просто на рынке не принято писать «платформенный инженер» или «инженер эксплуатации с хорошим знанием DevOps-практик».
Хотя многие компании до сих пор не до конца понимают DevOps, во многом именно благодаря ему уровень инженерной культуры существенно вырос за последние 15-20 лет. В тексте я расскажу, в чем проблема старой модели разработки — после этого станет понятно, зачем нам действительно нужен DevOps.
Ничего не работает, виноваты все
Разработчики что-то разрабатывают, тестировщики что-то тестят, в какой-то момент они отдают готовое приложение админам. И тут появляется первая проблема: эксплуатация — это совершенно другое подразделение.
В серверной сидят себе бородатые дядьки. К ним приходят разработчики, показывают новое приложение. Если в комплекте с ним есть какая-то документация — это еще повезло, но зачастую ее нет. Тогда админы идут обратно к разработчикам и возмущаются: «Как это вообще развернуть?».
В итоге ребята из эксплуатации кое-как заталкивают приложение на продакшен, но потом все равно начинаются проблемы. Например, когда разработчики добавляют новую зависимость, никого не предупредив. При этом у них локально все продолжает работать, пускай и на тестовом стенде. Где не работает? На продакшене. Кто работает на продакшене? Админы. Значит админы — нехорошие люди.
И тут начинается то, что на русский язык чаще всего переводят как «колодец» (по-английски silo, силос). Колодец — это коммуникационная дыра.
У разработчиков есть сфера обязанностей — создавать новый функционал продукта, у админов — делать так, чтобы на продакшене все работало быстро и хорошо. Обычно сложности начинаются, когда какие-то штуки находятся на стыке разработки и эксплуатации, как в нашем примере.
Как сделать так, чтобы новый функционал попал на продакшен и работал там быстро и хорошо? Кто за это отвечает? Ведь это продукт разработчиков, но при этом именно админы ответственны за продакшен.
DevOps придумали как раз для устранения этого коммуникационного колодца — вся команда должна работать заодно, а не спихивать друг на друга ответственность. До изменения инженерных практик так все и происходило: команда работала по разные стороны баррикад и не могла поделить ответственность. Современная же разработка совсем другая.
Читайте также: DevOps — что это такое и почему эти практики меняют мир разработки уже сейчас
DevOps в современной разработке
Для решения проблемы с коммуникацией есть несколько путей. Например, можно заставить админов углубиться в разработку, а разработчиков — в эксплуатацию. Но чтобы глубоко не ковыряться в смежных областях ни админам, ни разработчикам, инженеры сделали отдельную абстракцию (и Kubernetes для этого отлично подошел). Она выше уровнем, и это помогает подняться и над архитектурой, и над способом запуска приложения.
То есть разработчик, выкатывая приложение в Kubernetes, вообще не задумывается о том, как оно будет запускаться на серверах: он манифест написал, запустил. А потом все как-то само на облаке с помощью магии запустилось.
Аналогично и со стороны админов: они знают, что к ним придет приложение, упакованное в Docker-образ. И им не надо больше думать, как его запускать, какие зависимости ставить. Docker-образ — очень самодостаточная история, и если образ правильно собран, то он запустится вообще везде.
Возня в стиле «разработчики добавили новую зависимость, а нам не сказали, что надо поставить ее на сервер» в итоге уходит. Ведь DevOps строится через дополнительный слой абстракции. При этом на самом деле DevOps всегда начинается на уровень выше: с общения, с коммуникации. С выработки общих механизмов, инженерных и культурных.
Конкретно под коммуникационными практиками можно записать культуру постмортемов, knowledge sharing — когда разработчики учат админов поглубже залезать в кишки приложения, а админы учат разработчиков, как что-то сделать на продакшене, поэксплуатировать.
Соответственно, совместное планирование и общий пул задач — это не столько про инструменты, сколько про инженерную культуру в целом. Почему я заостряю на этом внимание? Потому что сейчас под DevOps чаще всего понимается набор инструментов: «Девопс — это тот, кто занимается CI/CD, мониторингом, выкаткой». Но коммуникационную и инженерную проблему, хоть это и является основной проблемой — одними инструментами не решить.
Но не все это понимают, поэтому случаются истории, про которые я расскажу дальше.
Читайте также: «Мы будем получать много удовольствия и совсем не будем страдать». Интервью с преподавателем интенсива «DevOps для программистов» Алексеем Шараповым — про новый курс на Хекслете
Когда Kubernetes есть, а DevOps — нет
Вот пример. У нас есть какой-то кластер из 10 машин. Если один сервер отказал, то вся рабочая нагрузка автоматически переезжает на живые тачки. Или если приложение упало, Kubernetes его автоматически перезапускает.
Kubernetes — эта штука, которая хорошо помогает в обеспечении высокой доступности и отказоустойчивости. Потому что Kubernetes — это self-healing system, которая умеет самовосстанавливаться.
Но это все надо настраивать. Чтобы кубер понимал, что приложение упало, оно должно отдавать метрики. И их для этого кто-то должен сначала внедрить в наше приложение.
Приложение в случае аварии может спокойно переезжать с одной тачки на другую. Соответственно, оно не должно использовать никаких файлов на локальной файловой системе: сегодня оно запустилось на одном сервере, а завтра — на другом.
Проблема начинается тогда, когда разработчики пытаются запихать Kubernetes любой ценой — без понимания, как все это работает. Тут и начинаются костыли — если не смогли отвязать приложение от локальных файлов, то просто прибивают его намертво к одному серверу, чтобы постоянно с этой папочкой на сервере работать. Если все же сервер падает, то уже тогда ничего не сделать — приложение переехать никуда не может и тоже падает.
Происходит обычный диалог: «Зачем вы поставили Kubernetes, если все работает точно так же, как раньше! Как падало, так и падает, только дополнительная непонятная сущность появилась».
Это происходит, когда DevOps спускается сверху, по палочной системе: «Все, через две недели начинаем работать по-другому».
Но еще хуже, если DevOps — это про выделенную роль: то есть мы посадим еще одного человека — девопса. Вместо одной проблемы получаем две: вместо «разработчики-админы» появляется конфликт «разработчики-девопсы» и «девопсы-админы».
К нам пришел девопсер
Чаще всего, DevOps — это просто еще один админ, который занимается CI/CD и мониторингом. Но ведь разработчики как не понимали, что как работает, так и не понимают. Админы как не понимали, что разработчикам надо, так и не понимают.
Классический миф звучит так: «Мы наймем девопса, и он нам сделает хорошо». Под словом «хорошо» понимается все что угодно: «Мы начнем чаще выкатываться», «У нас перестанет все падать», «Мы будем стабильно работать» и все в таком духе.
Раз появляется DevOps-инженер с выделенной ролью, то он внезапно становится ответственным за все вышеперечисленное. Хотя это неправильно, потому что DevOps — это про коллаборацию, про коллективную работу.
Когда компания решает нанять одного DevOps-инженера, то он становится узким местом в процессах. Такой человек-снежинка, на котором завязаны все процессы. Тогда как основной смысл в DevOps — противоположный. Вообще, в идеале роль девопса должна быть у всех членов команды: разработчики поглубже разбираются в эксплуатации, админы поглубже разбираются в разработке, и все они — мультифункциональные специалисты.
Появилось даже такое понятие — «T-shaped specialist». Это специалист, который глубоко знает свою основную сферу (ножка буквы T), но помимо этого обладает широкими, пусть и не супер-глубокими, знаниями в смежных областях.
Читайте также: История успеха и благодарность. Как из сисадмина я ушёл в PHP-разработку, а потом — в DevOps
Помимо подхода с попыткой нанять специального человека, есть и второй путь. Спускается десант ребят, задача которых заинтересовать всех практиками DevOps и настроить процессы внутри команды. Они называются enabling team, команда по внедрению инноваций.
DevOps-инженеры из enabling team приходят к другим командам и показывают им, как делать правильно. Убеждаются, что практика прижилась, после чего уходят в закат — наносить пользу уже следующей команде.
Понятно, что как раз в таких случаях DevOps-инженеры — это специалисты с выделенной зоной ответственности.
Если компания большая, это кто-то из своих, а если нет — это аутсорс. Во втором случае минус в том, что команду надо заинтересовать, а людям снаружи это сделать нелегко. По словам моих знакомых из консалтинга, большинство их клиентов делают откат уже в первый год после попытки ввести DevOps-культуру.
У нас в компании практики внедрялись со стороны админской команды. То есть мы ребятам все настраивали и показывали: «Смотрите, как классно!». Раньше наши разработчики тратили два дня на то, чтобы написать админам и объяснить, как выкатить новое приложение. Сейчас даже не надо создавать заявку: можно выкатить новое приложение на продакшен с нуля за два часа. И два часа — довольно пессимистичная оценка.
Интенсив Хекслета про DevOps во многом на это направлен: он показывает, что есть инструменты, при помощи которых можно очень легко выкатить на продакшен новое приложение.
И сейчас, к счастью, разработчики все больше понимают, что DevOps упрощает работу. Даже сам подход расширяется на все айтишные сферы: DevSecOps (developers security operations), DevTestOps (developers testing operations), и так далее.
DevOps перестает быть черной магией
В прошлом нам было трудно внедрить DevOps у себя в компании: разработчики просто не понимали, зачем все это нужно. Сейчас ситуация изменилась, как это когда-то произошло с тестированием.
То есть когда-то отношение к тестированию у многих разработчиков было негативное: «Зачем я буду писать тесты, у нас же тестировщики свои есть». А сейчас программисты понимают, что продукт они знают лучше, а значит, лучше напишут тесты. С DevOps теперь получается точно так же.
Если суммировать, то DevOps — это набор практик, упрощающих коммуникацию и совместную работу подразделения разработки и эксплуатации. Для этого потребуются навыки на стыке: надо знать и эксплуатацию, и разработку.
Начинать обучение программированию с DevOps сложно, надо в любом случае иметь определенный опыт и знания. А еще навыки коммуникации с людьми, чтобы объяснять, зачем это все нужно, продавать идею команде. Поэтому от девопса требуется не только знание инструментов, но и умение выстраивать коммуникацию между командами — в современном IT навыки общения ценятся очень высоко.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
