Александр Крылов, 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. 

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

1. Опыт работы и понимания принципов работы Linux.

2. Понимание работы сетей, хотя бы на уровне сетевых протоколов и уровней TCP/IP.

3. Понимание принципов работы виртуализации и умение работать с ней.

4. Понимание работы контейнеров, умение их готовить.

5. Понимание разницы между монолитной и микросервисой архитектурой. Набор паттернов при построении архитектуры, анти-паттерны.

6. Понимание культуры и принципов взаимодействия в команде на базе agile, devops. Понимание подходов к организации разработки: kanban, scrum.

7. Понимание подходов CI\CD как на уровне процесса разработки, так и набора инструментов, которые этот процесс могут сопровождать, дополнять и развивать.

8. Понимание принципов работы с репозиторием, версионирования кода, подходов к разработке, например, стандартный gitflow.

9. Понимание безопасности кода, как можно использовать подходы к нему, включить в pipeline.

10. Подходы к тестированию кода, виды тестирования, тулзы для АТ: mock, системное, нагрузочное, регресс.

11. Подходы к тестированию инфраструктурного кода и автоматизации этого тестирования.

12. Базовые принципы и виды мониторинга, алёртинга, какие есть тулзы. Что такое LogTracing, подходы OpenTracing, OpenTelemetry. 

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

И два бонуса из не совсем технической части: 

• Не бояться задавать вопросы и быть готовым всегда развиваться, не бояться перемен. 

• Системный подход к решению проблем.

В какие языки надо погружаться

Конечно, качество собственного кода на работу девопса влияет напрямую и непосредственно. Начиная от качества кода ПО, с которым работают 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-инженер

• Курс Soft Skills для руководителей

• Курс Project-менеджер