Александр Крылов, DevOps-инженер, поделился своим опытом и личным взглядом на профессию. Он рассказал, чем девопсы отличаются друг от друга и что нужно включить в индивидуальный график обучения, чтобы стать одним из них.
В теории DevOps-инженером может стать любой, кто этого пожелает. Это не та профессия, где играет роль физическая предрасположенность к какому-то делу, как, допустим, у космонавта. Всё зависит от тяги к знаниям и способности обучаться, не лениться, не бояться задавать вопросы коллегам.
Александр Крылов
Крылов Александр, Lead DevOps services ПАО СК Росгосстрах, гик по жизни вокалист группы Terror Inside, любитель фантастики и всего, что связано с Unix.
Другой вопрос — сколько сил придётся потратить на новую специализацию. DevOps — методика на стыке технологий, поэтому прийти с улицы и внезапно стать сеньором не получится. Надо накопить теоретический и практический багаж.
Понятно, что лучше, когда есть опыт системного администрирования или разработки, это даёт на старте хороший трамплин. Но не у всех такой есть. Кроме того, DevOps — это не только технологии. Это культура взаимодействия, поэтому гибкие навыки тут тоже важны. Речь не про способность много говорить или любить тусовки, как часто воспринимают soft skills. Я считаю, что на DevOps-инженера можно обучиться в части теоретических знаний и использования инструментов, но культуру и процессы можно понять и прочувствовать, только работая в команде.
Увалень, интроверт, агрессор: опыт классификации девопсов
Градация среди инженеров по уровню задач, которые они решают, безусловно, есть. Это, конечно, стандартная база: junior, middle, senior. Но мои наблюдения показывают, что даже на этих уровнях различия между специалистами очень большие.
Junior — начинающий специалист, который либо только пришёл в профессию, либо имеет минимальный набор знаний. Моя дополнительная классификация джуниоров:
Студент — имеет теорию без практики, легко обучаем.
Увалень — владеет минимальным тулсетом и считает себя мидлом, при этом не развивается и может выполнять только минимальный набор задач. Чаще всего закрывает текучку.
Стесняшка — за такими нужен глаз да глаз. Они могут знать теорию, но боятся задавать вопросы, таким всегда необходим опытный коллега.
Админ — человек из админов, со знаниями, готов развиваться в автоматизацию, разработку и коллаборацию с другими подразделениями. Чаще всего такие быстро становятся мидлами, но не всегда доходят до сеньоров.
Middle — люди, имеющие опыт, побывали джунами. Не боятся задавать вопросы, могут быть автономными, в некоторых случаях сами ставить себе задачи. Но и среди них есть градации:
Разработчик-интроверт — он может быть хорошим специалистом, иметь прекрасные hard skills, но минимальный уровень гибких навыков, а потому над ним всегда должен быть сеньор или менеджер, который будет ему помогать.
Любитель поговорить — обладает хорошими гибкими навыками и чуть выше уровня junior hard skills, на чём и выезжает. Активен, участвует во всех встречах, летучках, созвонах, сборах требований. Очень часто такие специалисты становятся менеджерами.
Проджект — человек, обладающий неплохими гибкими навыками, неплохими hard skills, умеет делать проекты «от и до». Очень близок к сеньору.
Агрессор — обладает хорошими hard skills и уверенно варится в этом котле. Его часто отвлекают джуны от порой важных, а порой не очень, задач, отчего он всегда ворчит и ругается. Просто к нему нужен подход. Такие специалисты могут решать сложные задачи, и задача их руководителей — минимизировать общение с любознательными джунами и несознательными пользователями.
Ну и самое интересное — senior DevOps. Это люди, которые повидали такое на свете, о чём не стоит говорить в приличном обществе. Могут менторить, вести проекты от и до. Я общался с разными сеньорами:
Архитектор — занимается проектированием hardware и app уровнями систем, которые только начинают или планируют внедряться. За счёт опыта и сплита навыков hard и soft может один сделать проект от сотворения вселенной до продакшена.
Активист — этот в каждой бочке затычка. Он говорлив, активен, энергия бьёт ключом. Часто посещает конференции, слушает подкасты, читает разные порталы. Такие очень часто участвуют в пилотах новых продуктов, предлагают продукты для внедрения/пилотов. Входят в различные инициативные группы и комитеты, помогая выстроить процесс. Чаще всего являются лидами.
Суперразработчик — они могли прийти из разработки или руководить ею. Версионируют код, следят за бранчами, занимаются ревью. Поэтому часто погружаются в код и архитектуру ПО, из которого, порой, не вылезают. Могут решать низкоуровневые специализированные вопросы.
Главное, что можно сказать о переквалификации в DevOps — всё индивидуально.
В принципе, про любое образование и про любую карьеру можно так сказать. Вы можете тратить по восемь часов в день, бороздить просторы интернета и читать статьи по теме, но так ни к чему и не прийти за два года. А можете полгода по вечерам поработать над базой пару часов и стать неплохим джуниором. Безусловно, есть уникальные люди, которые всё схватывают на лету и являются хорошими специалистами-самоучками, но таких — малый процент.
Тут я рекомендую не искать серебряную пулю, а составить личный график саморазвития.
Так называемый ИПР, или индивидуальный план развития. Затем разделить его на временные рамки и далее следовать ему. Постепенно, двигаясь по вашему личному ИПР, вы будете набирать экспертизу и получать левел-апы. Опять же, такой подход работает в любом обучении.
С чего начать составлять индивидуальный график
Начинать всегда следует с того, что лучше всего получается. Каждому своё, ведь кто-то силён в разработке, кто-то в аналитике или архитектуре. Начинайте изучать программы и решать проблемы, используя свои сильные стороны, постепенно наращивая и компенсируя слабые. Где-то взаимодействуя с коллегами, где-то проходя курсы или практику из community.
Существует множество статей, докладов, выступлений на конференциях на тему того, что же должен знать девопс. Единого госэкзамена нет, но есть часть, которую можно объединить и выделить:
Опыт работы и понимания принципов работы Linux.
Понимание работы сетей, хотя бы на уровне сетевых протоколов и уровней TCP/IP.
Понимание принципов работы виртуализации и умение работать с ней.
Понимание работы контейнеров, умение их готовить.
Понимание разницы между монолитной и микросервисой архитектурой. Набор паттернов при построении архитектуры, анти-паттерны.
Понимание культуры и принципов взаимодействия в команде на базе agile, devops. Понимание подходов к организации разработки: kanban, scrum.
Понимание подходов CI\CD как на уровне процесса разработки, так и набора инструментов, которые этот процесс могут сопровождать, дополнять и развивать.
Понимание принципов работы с репозиторием, версионирования кода, подходов к разработке, например, стандартный gitflow.
Понимание безопасности кода, как можно использовать подходы к нему, включить в pipeline.
Подходы к тестированию кода, виды тестирования, тулзы для АТ: mock, системное, нагрузочное, регресс.
Подходы к тестированию инфраструктурного кода и автоматизации этого тестирования.
Базовые принципы и виды мониторинга, алёртинга, какие есть тулзы. Что такое LogTracing, подходы OpenTracing, OpenTelemetry.
Умение понимать, какие задачи стали рутинными, чтобы можно было их автоматизировать и перестать на них тратить время.
И два бонуса из не совсем технической части:
Не бояться задавать вопросы и быть готовым всегда развиваться, не бояться перемен.
Системный подход к решению проблем.
В какие языки надо погружаться
Конечно, качество собственного кода на работу девопса влияет напрямую и непосредственно. Начиная от качества кода ПО, с которым работают DevOps инженеры и покрытия этого кода тестами, заканчивая кодом, который они сами пишут и покрытия его тестами, например, инфраструктурного кода или ansible. Поэтому следует самому покрывать код тестами и проверками и стремиться внедрять в pipeline автоматизированные тесты проверки исходного кода приложения. А ещё лучше иметь и то, и другое, и QG на них, чтобы, если код не соответствует правилам, его нельзя было влить в релизную ветку. Чем при этом пользоваться?
Python — модно, молодёжно, используется в машинном обучении и нейросетях, а также всевозможной автоматизации. Работать с подходами MLOps, DataOps крайне интересно, но для них нужен большой багаж знаний.
Java, Kotlin, Spring boot — мир корпоративного ПО, где много интересных технологий, микросервисов и взаимодействия со всеми участниками процесса. Лучше всего подходит для начинающих, чтобы быстро втянуться в основные технологии CI\CD и того, что есть у многих крупных компаний.
Go — ещё более модно и молодёжно, но порой сыровато, и надо скушать много известной субстанции, чтобы приготовить некоторое ПО, написанное на нём, а также выстроить цикл разработки.
C# — чистые шарпы — это тоже модно и корпоративно, но дважды подумайте, прежде чем захотите связываться с windows-стеком разработки всего, что с ним связано. Часто на нём идёт какое-либо легаси или монолит.
C# net core — несколько лучше, чем чистый C#, больше новых технологий, используется далеко не во всех компаниях, кроссплатформенный, но не забывайте, что это windows, который приготовить на linux порой бывает крайне беспощадно. Часто используется либо в смешанных системах из монолита и микросервисов, либо в микросервисах. Если у вас крепкие нервы, то вам сюда.
Ну и замкнём круги ада некоторым легаси: C, C++, plsql, Delphi. В проекты, которые используют что-то из них, вы идёте исключительно на свой страх и риск. Вы окунётесь в тонну легаси, вендерлока и страданий. Только матёрые инженеры идут в этот путь, либо любители free bsd.
Как находить практику для обучения
DevOps, конечно, очень практическая штука. Задачи и инструменты у всех компаний разные. Но теория всё равно нужна, вариться в практике, не зная банальной терминологии и основ linux. — бессмысленно и беспощадно. Есть множество бесплатных практикумов, разборов установки тулсетов и решения проблем на YouTube, статьи на Хабре. Берите различные кейсы развёртывания систем и пробуйте. Берите репы githab и разворачивайте, настраивайте, ломайте, смотрите, что будет, лечите.
Но рано или поздно вам понадобится наставник — коллега, тимлид, который бы придумывал вам задания. Тут без практического навыка в работе либо ментора, который его имеет, дальше вы не пройдёте. Теория теорией, но практика, да ещё и в крупном enterprise — это небо и земля. Поэтому навыки и минимальный набор тулсетов развиваем на свободных, бесплатных, cloud free площадках, а остальное — либо у наставников, либо работая в этой сфере. Чем раньше вы начнёте это делать, тем лучше.
Говоря о людях, у которых есть теоретические знания, но нет практического опыта — всё индивидуально, и кто-то быстро выработает подходы к решению проблем, а кто-то будет буксовать и без менторства встанет на месте. Поэтому, возвращаясь к порогу входа в профессию DevOps, могу сказать, что он минимален, и почти каждый может им стать, но надо уметь работать в команде, не прокрастинировать и быть открытым новому.
Когда включать в план обучения гибкие навыки
Всем всегда рекомендую начать с прикладных навыков и развития hard skills, поэтому начинаем по следующим книгам:
Уорд Брайан. Внутреннее устройство Linux.
Арнольд Роббинс. Bash — карманный справочник для системного администратора.
Лорин Хоштейн. Запускаем Ansible.
Michael Duffy. DevOps Automation Cookbook
Марко Лушка. Kubernetes в действии.
Только после этого отправляйтесь учиться проджекту, гибким навыкам, процессам:
Проект «Феникс». Как DevOps устраняет хаос и ускоряет развитие компании. Ким Дж., Бер К., Спаффорд Дж.
The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. Kim Gene, Debois Patrick, Willis John.
Теория игр. Авинаш Диксит.
Практика непрерывных апдейтов – Continius Delivery. Эбихард Вольф.
Дополнение от редакции:
Александр рассказал, как построить самостоятельный путь обучения в DevOps. Но если вам нужна помощь, заходите.
Курс DevOps-инженер
Курс Project-менеджер