Из системного администратора в DevOps: кому это надо и как совершить переход?
В последнее время в IT-сфере наблюдается серьезная заинтересованность DevOps-инженерами. Так рынок отреагировал на потребность, по сути, в системных администраторах, отвечающих за поставку. А все потому, что ИТ-сектор начал активно вникать в процессы быстрой разработки, Continuous Integration (дословно «непрерывная интеграция»), максимально быстром выпуске версий приложений и их обновлений. Так, девопс — это более узкая специализация системного администратора на ряду с сетевым или администратором базы данных, в которую можно развиться System Engineer.
Как и зачем это делать, рассказал Кирилл Штрыков, DevOps Lead международной финтех-компании ID Finance. Почти 6 лет назад Кирилл пришел системным администратором в команду рефакторинга и благодаря специфике работы стал интересоваться автоматизацией и выстраиванием процессов Continuous Integration Delivery. Через несколько лет он начал выполнять DevOps-задачи. Сегодня он возглавляет девопс-команду ID Finance и является ментором Laboratatory 2.0 для DevOps-джуниоров.
— Кирилл, расскажи, чем отличается DevOps Engineer от System Administrator?
— Нельзя забывать, что DevOps, это все же методология и любой администратор, как и разработчик, может придерживаться ее. Если же говорить конкретно про DevOps Engineer, то у него сильнее «прокачана» ветка разработчика, и он чуть больше делает упор на «автоматизировать все». Также DevOps Engineer должен быть в курсе продукта компании, знать его немного изнутри, хотя бы понимать, как оно там все собирается и взаимодействует «под капотом», что для системного администратора может быть не обязательно.
— Тогда чему нужно обучиться админу, чтобы стать DevOps’ом?
— В первую очередь нужно изучить методологию DevOps, вникнуть в такие понятия, как Continuous Integration и Continuous Delivery. Затем подтянуть «Dev», так как у System Engineer обычно все хорошо по части «Ops», а вот разработка чаще всего сводится к bash-скриптам. Также неплохо узнать какие-нибудь инструменты DevOps, если не сталкивался с ними раньше — Ansible, Terraform, GitLab CI, Jenkins, TeamCity.
— Тогда расскажи про свой опыт перехода?
— Я в эту тему заходил немного «сбоку». Будучи системным администратором, я попал в отдел рефакторинга, где крутые ребята делали крутые вещи. Я и до этого любил изучать новые технологии, смотреть во всякие интересные инструменты автоматизации и изучать языки. На тот момент я уже имел представление про Puppet, Chef, Ansible и успел немного с ними поработать. Знал, что такое Jenkins и имел опыт написания пайплайнов. Также немного знал PHP, Perl, Ruby и Python. Единственное чего я не знал, что такое «девопс». Оказалось, что уже некоторое время я, если не двигался, то «лежал» в сторону DevOps. В рефакторинге же все происходило очень стремительно — только успевай впитывать новые знания.
— Что бы ты посоветовал тем, кто тоже хочет «двигаться» в сторону DevOps?
— Наверное, в первую очередь, учите языки программирования. Как правило, у системных администраторов есть сложности с Dev при очень серьезном бэк Ops. Поэтому нужно прокачивать скиллы разработки. А еще важно мыслить с точки зрения «если тебе нужно будет сделать это еще раз — опиши это кодом».
— А что насчет софт скиллов?
— Тут у администраторов обычно тоже все очень хорошо. Особенно у тех, кто начинал в роли L1 и саппорта. Я имею в виду коммуникации, так как задачи девопсов состоят не только из написания кода, но и общения: понять, что хотят получить в итоге, для кого этот результат важен и кто может сказать в конце концов, что все сделано верно и задача была правильно понята.
— Сейчас ты ведешь первый поток DevOps в Laboratory 2.0 — проекте ID Finance. Как я понимаю, с ней процесс перехода может получиться в разы легче и быстрее. Но обо всем по порядку. Кого и как сейчас готовишь ты?
— В этот раз в «Лабу» мы взяли ребят после DevOps-курсов без админовского бэкграунда. Проанализировав, что происходит у нас на рынке курсов подготовки девопсов, я увидел большой пробел в практических знаниях. Выпускники приходят с очень размытым понимаем, чем они будут заниматься и вообще, что это за направление. Поэтому в Laboratory 2.0 мы делаем основной упор на практические занятия и задания из реального мира и нашего опыта. При этом я стараюсь дать понимание «Зачем?» и исходить из того, какую проблему мы решаем.
В целом, лаборанты за время работы и обучения проходят все этапы отдела рефакторинга и постепенно подходят к написанию своего небольшого проекта, который работает точно так же, как проекты ID Finance. А по дороге им будут попадаться те кейсы, с которыми сталкивались мы, чтобы понимать, почему у нас используется то или иное решение.
Открывая «Лабу» DevOps мы рассчитывали на то, что все успешно пройдут расширенный онбординг, поэтому довольно долго собеседовали, отбирали ребят, которые останутся в компании и присоединятся к реальным проектам.
Но уже сейчас я готовлю материал следующего потока для системных администраторов, чтобы обучить их разработке по методологии DevOps. Прогнозирую, что это ускорит процесс подготовки хороших девопс-специалистов для нашей компании. Поэтому следите за новостями ID Finance!
