Как жить, если ты девопс?

esq1vb2hyrossyx8vcs8c73toha.jpeg

Я уже лет 10 занимаюсь, в основном, менеджерской работой, но недавно решил освежить свои технические навыки и поближе познакомиться со стеком современных DevOps-инструментов. Я взял на себя исполнительскую работу с несколькими клиентами компании и, имея понимание, как исполнителя обычно видит менеджер, получил любопытный опыт, которым хочу поделиться.
Статью можно дополнить прослушиванием моего доклада на DevOpsConf — в нём чуть больше историй и провокаций.

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

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

image-loader.svg

То есть DevOps-инженеров, конечно, не существует, зато есть ожидания, чем должен заниматься человек, который занимается DevOps.

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


Это действительно происходит, но большая часть работы девопса в реальности немного другая.

Если посмотреть те самые две с лишним тысячи вакансий, то в 9 из 10 перечислены примерно такие обязанности:

  • настройка и поддержка инфраструктуры на Kubernetes;
  • развёртывание и мониторинг релизов;
  • настройка пайплайнов сборки, тестирования и деплоя;
  • автоматизация процессов и помощь команде разработки;
  • сопровождение и администрирование стендов;
  • траблшутинг и решение инфраструктурных инцидентов;
  • обеспечение CI/CD-процессов и т.д.


А ещё мы знаем, что на одного девопса в компании обычно приходится 20–30 разработчиков. Из это складывается ощущение, что девопс — такая же сервисная роль, какая раньше была у админа. Но админу было проще, потому что он делал что-то своё, а иногда к нему приходили разработчики и просили выложить их код. То есть админ строил свою серверную-сервисную архитектуру и периодически помогал программистам.

А теперь, кто такой девопс-инженер? Это человек, который настраивает пайплайн, а если он ломается, то исправляет. А если деплой сломался, то делает так, чтобы деплой наладился. А если выложилось что-то не то, то разбирается, что произошло. По сути, девопс выполняет задачи для людей, которые что-то создают.

При этом ситуация на рынке разработчиков такая, что зарплата middle Node.js-разработчик составляет 300 тысяч рублей в месяц. Что заставляет сомневаться, есть ли интерес работать девопсом. Почему не поучиться полгода в онлайн-школе на программиста, еще год поработать джуном, а потом сказать, что я middle, и претендовать на зарплату в 250–300 тысяч — айтишный опыт уже же есть…

Мне кажется важным понимать, в чём смысл продолжать заниматься DevOps, а не выучиться на программиста и не стать за год крутым и высокооплачиваемым middle-разработчиком. Я пытаюсь рассуждать об этом не теоретически и за других людей, а примерив на себя роль админа-исполнителя. Вот я — сотрудник американской компании, у которой в штате как раз 30 Node.js программистов, я выкладываю их код и делаю прочие подобные задачи. Зачем я это делаю? Почему не заняться чем-нибудь другим? И если всё-таки я решу, что хочу заниматься именно этим, то как сделать свою жизнь комфортнее?

А может, в разработчики?


Если я устал строить пайпплайны, если только 10% времени занимаюсь интересной работой, а остальные 90% — это рутина, то, может быть, мне пойти в разработчики? Говорят, у них крутые творческие задачи, меньше рутины и больше всего интересного, а еще и зарплата выше.

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

Получается, что хорошо там, где нас нет?

В общем — да. Потому что среди разработчиков, например, есть те, кто пилит фичу, существующую последние 5 лет. Всё, что нужно — это перепиливать и перепиливать одну и ту же фичу. И новое им не светит, потому что их наняли именно для работы с этой долгоживущей фичей.

Но они хотя бы видят результат своей работы в проде. Другие несколько человек сказали мне, что, конечно, всё классно, но они уже 3 года делают стартап-проект, который никому не нужен. Все, что они сделали за 3 года, до сих пор не зарелизилось, и есть вероятность, что по решению бизнеса их упорная многолетняя работа ляжет в стол.

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

Еще одна причина моего заблуждения о радужной жизни разработчиков связана с тем, что я, конечно, воображал работу в продуктовой компании. Но продуктовых компаний на самом-то деле не очень много. Body shop, аутсорс и аутстаф — существенная часть рынка программистов. И там уже может быть менеджмент, который, например, не заинтересован в программистах, который говорит релизить прямо сейчас и ругается, почему до сих пор не готово. Зарплаты в таких компаниях тоже высокие, но в них, как правило, нет ни свободы выбора технологии, ни творчества, а есть рамки производительности и рентабельности.

Поэтому программисты и говорят, что быть девопсом классно. Ок. Давайте подумаем, почему.

Что хорошего в DevOps?


Этот вопрос я тоже задавал коллегам и думал над ним со своей точки зрения.

Во-первых, девопс — это, действительно, инженерная работа. Например, несколько моих знакомых программистов перешли в DevOps, потому что хотели заниматься созданием архитектур. Какой шанс у рядового программиста в большой компании проектировать архитектуры решений? А если перейти из девопса в разработку, то такая возможность появится вообще лет через 5. У девопса гораздо больше полномочий и влияния на инфраструктурные решения, особенно в команде, где на одного девопса 30 человек программистов. Чаще всего именно девопсы продумывают архитектуру процесса выкладки кода, его работы в продакшене, систем отказоустойчивости и т.д. Девопсы влияют на процессы, и это классно.

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

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

Окей, жить, если ты девопс, можно — и даже интересно. Но тогда возникает следующий вопрос.

Что такое жизнь девопса?


Жизнь девопса не похожа на сказку. Потому что, хотя мы и можем заниматься инженерной работой, выбором инструментария, у нас всё равно много рутины. Девопсу нужно: выкладывать софт, мониторить, настраивать инфраструктуру, пайплайны и прочее.

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

За время работы в качестве исполнителя у меня было несколько тяжелых, бесячих ситуаций. Я хочу поделиться с вами тем, как я пробовал их разрулить, потому что, кажется, они достаточно типовые и, возможно, мой опыт вам пригодится.

Им всем что-то надо, и прямо сейчас


Как мы говорили, часто в компании на 300 разработчиков работает 10–30 девопсов/админов. Команды разработки обращаются к девопсам по мере необходимости и иногда делают это все одновременно. Приходят одни, говорят: «У нас релиз, нам надо выложиться, срочно». У вторых тоже релиз, и тоже срочный. А третьи говорят: «Мы тут сервис написали, про который вам никогда не говорили, который тестили у себя локально. Через два дня хотим релиз, напишите нам пайплайн и выложите это всё».

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

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

  • С самим собой — вести трекер задач таким образом, чтобы была видна текущая нагрузка. Конечно, трекать все задачи, вести чек-листы и прочее бесит — меня всегда бесило. Но с горящей работой это необходимо, для того чтобы иметь возможность показать нагрузку и объяснить, что всё и сразу сделать невозможно. Имея хорошую трекинговую систему, можно доходчиво объяснить руководителю: «Вот есть бэклог, вот такие задачи сейчас в работе, вот 3 одновременных критических задачи по релизу в очереди. Объективно сделать все 3 за день не получится. Решите, в какой последовательности будем их делать». Так вы сможете и сами увидеть и показать реальное положение дел.
  • С коллегами — сказать о проблеме, предупредить о возможных вариантах решения. Коллеги, которые пришли срочно релизиться, конечно, не ожидают, что со стороны девопсов могут быть какие-то блокеры. Это происходит из-за проблем с коммуникацией, которую мы должны налаживать, в том числе, со своей стороны. Мы говорим, что DevOps — это построение культуры, но не все 2000 компаний, которые хотят нанять девопсов в России, уже построили эту культуру, и надо с чего-то начинать. Поэтому нам надо самим взаимодействовать с коллегами и рассказывать: «У нас есть 3 критичных проекта, и я не начну над ними работать, пока не выясню их приоритеты, иначе получится каша и ничего хорошего не выйдет. Вам придётся подождать».
  • С руководством — о том, что работы по доставке могут быть объёмными и являются частью разработки ПО (удивительное дело), их надо закладывать в планы. Развёртывание занимает время исполнителей, которых, к тому же, ограниченное количество. При планировании сроков релиза надо учитывать не только время, собственно, разработки, но время и ресурсы на доставку программного обеспечения. Если в процессе меняется архитектура, то потребуется изменить пайплайны, и это тоже нужно заложить в планы. Культура DevOps об этом и говорит: разработка, тестирование и эксплуатация не должны быть изолированными процессами. И донести до всех участников, что CI/CD такая же важная часть, как разработка, — это большая и сложная задача, которую, однако, придется выполнить, иначе в перспективе проект будет сложно развивать.


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

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

Но давайте все же исходить из того, что в компании люди готовы прислушиваться, когда им говорят о проблемах. Главное — эти проблемы заметить, обсудить и придумать, как избегать в будущем. Понять, что невозможно всё сделать одновременно, и научиться прогнозировать время на релиз мне помогли две вещи, которые раньше я ненавидел: трекать задачи и (что еще больше бесит) трекать время на них.

Таск-трекер, о котором я уже говорил, нужен, чтобы отдавать себе отчет в реальной загрузке. Я начал с Trello, куда записывал все подряд задачи. А дальше из этого бэклога перетаскивал сколько-то из них на текущий день. Это такой классический способ, основанный на идее, что когда ты понимаешь, сколько и каких задач нужно сделать, тебе проще начать их выполнять. Меня в нём угнетало количество задач: я знаю, что мне нужно сделать очень много всего, от того, что я их запишу, задач меньше не станет, зато я увижу масштаб проблемы, впаду в уныние и вообще ничего не сделаю. Тем не менее, трекер помог мне самому понять, что задач действительно много, и использовать это как аргумент в моей девопс-работе.

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

Можно, конечно, планировать день в 8 рабочих часов, можно хоть в 16, но через несколько дней такого графика скорее всего окажется, что как-то ничего не нравится и не хочется работать эту вашу работу. Когда в таск-трекере на день появляется 4 задачи по 2 часа, то к вечеру чаще всего оказывается, что все успеть не получилось.

Мы в ITSumma в оценке внутренних сроков считаем, что человек по-настоящему работает 4 часа в день. Это очень сложная тема для разговора с руководством, потому что во многих компаниях, особенно западных, считают, что человек реально работает 8 часов в день. Не могу дать конкретного рецепта, но хотя бы для себя нужно знать, когда вы устаёте и больше не можете работать по-прежнему эффективно и без вреда для себя на длинной дистанции.


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

Вставай, мы всё уронили


Второй тип раздражающих ситуаций в работе девопса обычно происходит либо потому, что часто выкладывают, либо потому, что быстро выпустили продукт на кривой архитектуре, да так и не нашли времени её исправить. А вакансии девопс-инженера достаточно часто предполагают не просто доставку ПО, а работу SRE. В таких вакансиях даже честно предупреждают, что иногда придется быть on-call. Ловушка, в которую я попался, заключается в том, чтобы определить, что такое «иногда».

Хорошо бы обсудить, насколько часто вам придётся срочно реагировать на инциденты в нерабочее время, когда вы только устраиваетесь в новую компанию. Иначе потом можно неприятно удивиться, когда вас разбудят ночью пятый раз за неделю. Возможно, в компании есть статистика по нештатным ситуациям, или вам озвучат ожидания, которые в последующем смогут стать отправной точкой в переговорах, если вам слишком часто придется быть on-call.

Речь не о том, чтобы никогда не соглашаться на on-call — если вакансия и компания вам нравятся, это не обязательно плохо. Просто надо постараться договориться на берегу и узнать не только, сколько часов придётся работать по ночам, но и как часто это будет происходить. Ведь дело же не в том, чтобы получить за внеурочную работу больше денег. А в том, что кого угодно достанет каждую пятницу работать до утра субботы, потому что всё время что-то падает.

Я бы использовал такую договорённость как метрику того, что пора остановиться и починить процесс. Если приходится тушить пожар каждую ночь в конце недели в течение двух месяцев, то, кажется, с проектом и архитектурой какая-то беда. Надо остановиться и что-то сделать: или не выкладываться по ночам, или починить деплой и заранее готовиться к ночным релизам.

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

Конечно, шантаж — не лучший способ, но, возможно, если напомнить о положении дел на рынке труда в IT, это заставит руководство задуматься и всё-таки найти ресурсы на причесывание архитектуры. Потому что иначе придется 3 месяца искать нового девопса — и, вероятно, платить ему больше.

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

Когда мы приведем в порядок архитектуру?


Самое смешное, что этот вопрос чаще всего исходит от других команд, а не от девопсов. То есть вы живёте в условиях, когда инфраструктура по ряду причин построена на соплях. Возможно, пришлось быстро релизиться, может быть, приходили постоянно с какими-то другими «более приоритетными» делами или вам она просто досталась в наследство. А потом что-нибудь серьёзно падает, и вас спрашивают: «Чем ты занимаешься, если оно снова упало? Напиши roadmap, как и когда мы исправим архитектуру!» Ты садишься за roadmap и проектирование, но те же люди приходят и просят срочно помочь выложиться, потому что они вчера написали код и уже обо всем договорились.

Это, конечно, всё не парадигме DevOps-культуры. Но далеко не во всех 2k+ компаниях, которые разместили вакансии девопс-инженеров, идеальная культура: потребность в ней уже есть, а сама культура еще не выросла, и надо с этим как-то жить.

У меня была именно такая ситуация, когда сначала «сделай с этим что-нибудь», а потом «всё бросай, надо выкладываться». Первое, что можно сделать, — это поговорить с непосредственным руководителем, если он у вас есть. Понимающий руководитель оценит нагрузку и объем бэклога (в этом как раз поможет таск-трекинг) и, вооружившись данными о частоте прилетающих срочных задач, сможет пойти договариваться с соседними отделами. Либо вам самим в какой-то момент придётся сказать: «Извините, но вам придётся не релизиться, например, две недели, пока мы не приведем архитектуру в порядок. Причем, в течение этих двух недель, скорее всего, будут падения, потому что мы будем менять архитектуру и что-то может развалиться. Но если этого не сделать, то следующие три года проект будем падать каждые две недели. Поэтому давайте сейчас остановимся и попробуем с этим что-то сделать».

Совершенно нормально, если бизнес не согласится остановить выкатку фич на две недели и подождать, пока вы наладите процесс. Тогда это стоит зафиксировать и убедиться, что все всё правильно поняли. Что именно сейчас мы не можем позволить себе взять паузу и продолжаем жить с архитектурой, построенной на соплях. Интересы бизнеса важны, поэтому в данном случае нужно просто зафиксировать: живём с тем что есть, потому что приоритетнее другое.

Разумное руководство поймёт и примет риски и, рано или поздно, найдёт ресурсы на глобальное исправление ситуации. А если не поймёт и через месяц скажет: «Вы опять всё уронили, где ваш roadmap по починке архитектуры?», то вы уже знаете, что делать — разговаривать жёстко, не забывая, что рынок на вашей стороне.

И опять же, планируя большое изменение, нужно не забывать, что в рабочем дне не 8 часов. Если вы запланируете в ближайший месяц заниматься архитектурой по 4 часа в день, а 4 часа в день задачами по поддержке, то, скорее всего, вы либо не будете заниматься архитектурой, либо помрёте. Поэтому, если планировать долгосрочную задачу, то стоит исходить из того, сколько вы реально можете работать в комфортном и продуктивном режиме. И понимать, что планы так или иначе будут сдвигаться. Я, например, договаривался что 2 часа занимаюсь выкладкой и прочим, а 2 часа — архитектурой. И всё равно пришлось сдвигать сроки, потому что иногда случаются непредвиденные ситуации.

Универсальные советы самому себе в прошлом


То, что я хотел бы знать, когда был не менеджером, а исполнителем:

  • Стоит разобраться с ведением задач и тайм-трекингом, как бы это ни бесило. В неидеальном мире девопс — сервисная роль, программисты и менеджмент разработки — ваши клиенты. Таск-трекер поможет сделать для них вашу работу более прозрачной, вас будут меньше пушить без необходимости.
  • В рабочем дне НЕ 8 часов, чаще всего — 4. Это надо учитывать в планировании. Нельзя заложить 4 часа на архитектуру и 4 часа на support — быстро кончишься.
  • Если что-то не нравится — надо сказать. Особенно, в 2021 году. Вы можете сказать, когда вас что-то не устраивает в работе, и если изменить ситуацию не удастся, то уволиться. И, в крайнем случае, пойти работать джуном на Node.js:)
  • Если в компании постоянные пожары, то, скорее всего, это никогда не пройдет. Если всё равно всё время сваливается что-то горящее, несмотря на любые ваши усилия, то, скорее всего, это в культуре компании и один человек не может её изменить.


А ещё я веду свой телеграм-канал, где немного чаще удаётся делиться размышлениями и идеями, чем здесь. Подписывайтесь :-)

© Habrahabr.ru