Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

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

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

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

5 <h2>Содержание</h2>

6 <ul><li><a>Ничего не работает, виноваты все</a></li>

7 <li><a>DevOps в современной разработке</a></li>

8 <li><a>Когда Kubernetes есть, а DevOps - нет</a></li>

9 <li><a>К нам пришел девопсер</a></li>

10 <li><a>DevOps перестает быть черной магией</a></li>

11 </ul><h2>Ничего не работает, виноваты все</h2>

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

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

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

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

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

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

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

19 <h2>DevOps в современной разработке</h2>

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

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

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

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

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

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

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

27 <h2>Когда Kubernetes есть, а DevOps - нет</h2>

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

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

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

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

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

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

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

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

36 <h2>К нам пришел девопсер</h2>

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

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

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

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

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

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

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

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

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

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

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

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

49 <h2>DevOps перестает быть черной магией</h2>

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

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

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

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