«Компенсація зросла на 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 та локальних серверів під столами розробників підходить до завершення і все це буде оптимізуватися. Тож я зробив ставку на ті технології, які активно розвивалися на західному ринку, і почав їх вивчати.
На той момент жодних спеціалізованих курсів не було. Вчився я здебільшого сам. Використовував закордонні ресурси або документацію із самих технологій. В роботі набуті знання фактично не використовував — тоді це було більше хобі, та й в Україні не так багато компаній застосовували західні новинки. Навіть клаудом у
Просувався поступово. Ту ж контейнеризацію вносив у свій тодішній проєкт. Приходив, пояснював розробникам: «От якщо у вас впаде контейнер з беком, ви можете його однією кнопкою підняти». Звісно, я трохи перебільшую. Але все-таки не потрібно заходити на сервер, щось там сіпати. Всім сподобалось.
Коли змінював роботу, вакансії саме 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 я пришел еще в школе, в
Потом на первом или втором курсе знакомый по локальной сети предложил мне работу. За 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, поміркуйте, чи подобається вам працювати з серверною частиною і чи хотіли б ви повністю розуміти інфраструктуру проєкту для подальшої оптимізації. Якщо так — пробуйте сміливіше.
