«Компенсація зросла на 150%». Як перейти із розробки в DevOps і чи варто

Найчастіше у DevOps переходять системні адміністратори. А як щодо розробників? Вони інколи теж. Ми розпитали ексрозробників, а нині девопсів про їхній перехід у нову професію, труднощі в роботі та компенсацію.

Цим матеріалом DOU розпочинає нову серію про перехід між спеціальностями всередині IT. Пишіть у коментарях, про кого хочете ще прочитати.

«Коли працював розробником, майже не відчував, що робота може завершитись»


Валентин Зайков, DevOps Engineer в Intrasystems. Три роки у розробці та п’ять — у DevOps

Розробником я пропрацював три роки. Працював у ядерній енергетиці, де ми писали усілякі сервери для станцій. Був у проєктах зі збору даних. Ще рік займався фронтенд-розробкою. А потім я почав працювати з Oracle ADF. І там потрібно було мати не лише навички розробника, а й адміністрування, налаштування серверів тощо. Тож довелося розбиратись.

Вивчився і став, окрім розробника, вправним системним адміністратором. І мені потроху стали давати специфічні завдання: щось налаштувати, конфігурувати. А от завдань із розробки надходило все менше.

Тож для мене перехід відбувся дуже плавно та в межах однієї компанії. Мотивації чи наміру ставати DevOps у мене не було. Ба більше, моя позиція досі називається Java Developer. Але, по суті, я вже повністю виконую обов’язки DevOps.

У новій ролі мені спокійніше. Пам’ятаю, коли був розробником, зробив реліз, і вже наступного дня треба виправляти хиби. І майже ніколи не відчував, що робота може завершитись.

А тут інфраструктуру збудував, усе налаштував. І, власне, все. Вільний час є чи на новий проєкт, чи на додаткову сертифікацію. Раніше цього дуже бракувало.

Щодо компенсації, то відколи я почав виконувати обов’язки DevOps, вона зросла відсотків на 150. Зараз вартість роботи DevOps взагалі шалена. Але це таке, сезонне. Колись так само полювали на Java-розробників.

Щодо подальшого розвитку, то пройду ще сертифікацію з Amazon, думаю, рухатимусь до системного архітектора. Бо я хоч не сертифікований, але вже архітектор. Проєктую системи на Amazon і про перехід абсолютно не шкодую.

«Можете спокійно йти на зарплату $4–6 тисяч з двома-трьома роками досвіду, і вас заберуть»


Даніель Акінфієв, DevOps у Dragonslake (R8 group). Понад два роки у розробці та близько чотирьох — у ролі DevOps

До того, як стати DevOps, я був Full Stack розробником. Здебільшого у вебі — PHP для бекенду і зв’язка HTML/CSS тощо. Проблема з Full Stack полягає в тому, що у вашому стеку зв’язка технологій, які ви ніби і знаєте, але на середньому рівні. Тож на рівень Senior не претендуєте.

Я тоді лише кілька років як випустився з університету і все ще шукав себе в IT. Веброзробка вже не особливо цікавила, а перевчатися на Java, C++ чи будь-яку іншу мову бажання не було. Можливо, мені просто не подобалося постійно писати код.

А 2013 року з’явився Docker. Я спробував з ним працювати, і це зачепило мене куди більше, ніж класична розробка. Розумів, що час звичайних dedicated service, PPS та локальних серверів під столами розробників підходить до завершення і все це буде оптимізуватися. Тож я зробив ставку на ті технології, які активно розвивалися на західному ринку, і почав їх вивчати.

На той момент жодних спеціалізованих курсів не було. Вчився я здебільшого сам. Використовував закордонні ресурси або документацію із самих технологій. В роботі набуті знання фактично не використовував — тоді це було більше хобі, та й в Україні не так багато компаній застосовували західні новинки. Навіть клаудом у 2013–2015 роках мало хто користувався.

Просувався поступово. Ту ж контейнеризацію вносив у свій тодішній проєкт. Приходив, пояснював розробникам: «От якщо у вас впаде контейнер з беком, ви можете його однією кнопкою підняти». Звісно, я трохи перебільшую. Але все-таки не потрібно заходити на сервер, щось там сіпати. Всім сподобалось.

Коли змінював роботу, вакансії саме DevOps мені не траплялися. Бачив здебільшого SRE (Site Reliability Engineering). Тож спочатку з розробника я перейшов на Linux-адміністратора. Однак моє резюме висіло на сайтах для пошуку роботи, і в певний момент мені написала хостинг-компанія. Мовляв, ходіть до нас адміністратором. І я погодився.

У них ще була продуктова компанія з повним циклом розробки проєктів. І вийшло так, що вечорами я адмінив сервери хостинг-компанії, а основна моя робота була як Linux-адміністратора в цій продуктовій компанії. Але, по суті, DevOps — це хороший Linux-адміністратор, який розуміє сучасні тенденції. Потроху розібрався глибше. Почав вносити у проєкти повноцінну контейнеризацію, використовувати оркестрацію. Писав пайплайни. І так закрутилося.

Колишній досвід в IT теж допоміг. Якщо ви були розробником, то точно розумієте, як має працювати контейнер з беком, база, чи потрібно робити реплікацію, як її налаштувати, як деплоїться сам продукт. Тож після кількох років розробки перехід був досить комфортним.

Я про це не шкодую. Щоправда, є нюанси. DevOps потрібно знати гігантський стек, адже тенденції в тих же клаудах постійно змінюються. Загалом вчити нове доводиться постійно — це цікаво і прикольно, але професія дуже динамічна.

Потреба в програмуванні з переходом не зникає: все одно доводиться писати код. Я часто використовую інструменти для розробників у своїй роботі, починаючи від Bash і закінчуючи Groovy для Jenkins. Треба писати пайплайни, скрипти для автоматизації. Але, звісно, коду не так багато, як у тому вебі з версткою сайтів.

Щодо компенсації, то можна спокійно йти на зарплату $4–6 тисяч з двома-трьома роками досвіду. Це середня зарплата по ринку. Якщо у вас дві роботи на парт-тайм, можете спокійно отримувати до 10 тисяч.

Якщо думаєте навернутися у DevOps, то основний стек на 2022 рік приблизно такий: Linux, Docker, Kubernetes, контейнеризація та оркестрація, GitHub. Ansible, Chef та Puppet, які допомагають оптимізувати розгортання. Хоча б один клауд. Розуміння Jenkins — він хоч і застарів трохи, але його багато хто використовує. Базові знання Security. Останнє дуже важливе, особливо протягом останніх кількох років, коли ламається фактично все і треба знати, як закривати дірки у коді. Це вже більше компетенції DevSecOps, але й класичним девопсам вони потрібні. А далі йдуть специфічні штуки, які варіюються від продукту до продукту і компанії. Там у кожного свої потреби.

«Если ты переходишь из разработки в DevOps, то на курсах найдешь мало полезного»


Олександр, DevOps в AnchorFree. Десять лет в разработке, пять — в DevOps

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

Потом на первом или втором курсе знакомый по локальной сети предложил мне работу. За 300 долларов писать сервисы на PHP. Я тогда еще ничего не знал, работал под его началом год. Последующие лет семь занимался в основном веб-разработкой в куче разных компаний. А потом так сложилось, что начал больше внимания уделять тестированию. Соответственно, нужно было чуть больше работать над серверной частью. И для меня переход в DevOps был постепенным и органическим.

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

В какой-то момент перешел в команду релизеров. Сейчас они называются SRE, а тогда, в 2013 году, такой термин еще не был распространен. На этой работе я 50% времени уделял разработке и еще 50% поддержанию серверов и помощи другим разработчикам. И вот последние лет восемь я так или иначе этим занимаюсь.

В предыдущей компании в США (а я переехал в 2013 году), несмотря на совмещенные обязанности, моя позиция называлась просто Software Engineer. В какой-то момент я договорился, чтобы мою должность поменяли на DevOps или SRE. Но я при этом даже из-за стола не встал.

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

Если говорить про обучение, то все курсы, которые я проходил, касались сферы разработки, а не DevOps. Знания в новой профессии я больше перенимал у коллег. Вообще «выучиться на DevOps» толком не получиться. То, с чем вы работаете сегодня, изобрели, по сути, два года назад. И вы все время чему-то учитесь, читаете документацию.

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

Опыт разработки для DevOps полезен. Девопсам в работе придется решать инфраструктурные или интеграционные проблемы. Например, между десктопными и мобильными командами. И опыт разработки поможет лучше или быстрее разобраться в вопросе.

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

Если вы DevOps, то ваши непосредственные клиенты — разработчики. И вот они могут подойти к столу и рассказать вам, в чем вы ошиблись и так далее. Для меня это единственная разница. А в остальном вы также пишете софт. И если вы Senior, то так или иначе обслуживаете своих коллег по работе, при этом часто можете использовать практики и технологи DevOps.

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

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

Если хотите в DevOps, советую прочесть Time Management for System Administrators Томаса Лимончелли, «Руководство администратора Linux» Эви Немета, Гарта Снайдера и Трента Хейна. А также SCRUM and XP from the trenches Хенрика Книберга.

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

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

«До зарплати Front-end додалося приблизно 120%»


Віталій Глембоцький, DevOps у Netframe. Півтора роки у розробці та шість місяців на посаді DevOps

До переходу в DevOps я близько року був Front-end розробником, поєднував роботу з навчанням. З технологій використовував React.js, CSS, LESS, HTML, JS. Згодом звільнився та ще довго не міг знайти новий проєкт.

Вирішив вивчати гейміндустрію та прийшов у компанію Netframe. Там мені запропонували спробувати себе у DevOps. До того я й не знав, що це таке. Коли почав вивчати галузь, то збагнув, що мені подобається.

Я навчався на внутрішніх курсах компанії, де мене менторив Team Lead з великим бекграундом. Там протягом двох місяців опановував Linux, Bash, Jenkins, Git, Kubernetes, Terraform, AWS, CI/CD, Pipeline, Datadog. Спочатку теорію, а протягом другого місяця нам вже давали практичні завдання під наглядом. Попередній досвід розробника допоміг зрозуміти взаєзв’язок усіх компонентів.

Я працюю як Junior DevOps вже близько шести місяців і вчуся на практиці. Дуже мотивований розвиватися далі. Стек технологій, якими може оперувати DevOps, великий, ви постійно берете до уваги щось нове.

Якщо фронтенд-розробнику для виконання задач подекуди може бути достатньо знати CSS, HTML та JS, то DevOps потрібно проаналізувати, який підхід буде кращий, і підібрати для нього відповідні інструменти. Крім того, тут ви займаєтеся різними проєктами та краще розумієте їхню структуру.

Щодо компенсації, то до зарплати Junior Front-end Developer після переходу додалося приблизно 120%.

Якщо ви плануєте перехід у DevOps, поміркуйте, чи подобається вам працювати з серверною частиною і чи хотіли б ви повністю розуміти інфраструктуру проєкту для подальшої оптимізації. Якщо так — пробуйте сміливіше.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному8
Підписатись на автора
LinkedIn



12 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

У меня был путь наоборот: из девопса в разработчики.

Про перехід до iOS з будь якого напрямку

Пам’ятаю, коли був розробником, зробив реліз, і вже наступного дня треба виправляти хиби. І майже ніколи не відчував, що робота може завершитись.

А тут інфраструктуру збудував, усе налаштував. І, власне, все. Вільний час є чи на новий проєкт, чи на додаткову сертифікацію.

Відколи перейшов з маркетингу в DevOps, усе дивувався, від чого такого непідйомного розробники вигорають в ІТ. Тепер ясно.

Тем, кто идет из разработки в DevOps рекомендую сделать акцент в сторону инфраструктуры, высоких нагрузок и безопасности. Также помните — ваши непосредственные клиенты это не только разработчики, но еще и CFO, который может придти с вопросом «почему у нас так выросли косты?».

Щодо компенсації, то відколи я почав виконувати обов’язки DevOps, вона зросла відсотків на 150. Зараз вартість роботи DevOps взагалі шалена.
Щодо компенсації, то до зарплати Junior Front-end Developer після переходу додалося приблизно 120%.

Хвилинка романтики на ДОУ! А то все гроші та й гроші :-)

Цікаво, чи бувають переходи з QA в DevOps :)

Бывают, но реже, потому что навыки реже совпадают. В слове DevOps таки dev. QAOps наверное что-то более экзотическое, но не думаю что нереальное

Бывают. QA — AQA — DevOps.

Я с сисадмина перешёл в QA. Не понравилось сразу, свичнулся в девопс.

Не бувають. DevOps — це методологія, а QA — процес. QA — це частина DevOps

Підписатись на коментарі