От «стесняшки» до «архитектора»: какими бывают DevOps и как стать одним из них

Какими бывают девопсы: опыт классификации специалистов

Градация среди инженеров по уровню задач, которые они решают, безусловно, есть. Это, конечно, стандартная база: junior, middle, senior. Но мои наблюдения показывают, что даже на этих уровнях различия между специалистами очень большие.

Junior

Начинающий специалист, который либо только пришёл в профессию, либо имеет минимальный набор знаний. Моя личная классификация джуниоров:

• «Студент» — имеет теорию без практики, легко обучаем.
• «Увалень» — владеет минимальным тулсетом и считает себя мидлом, при этом не развивается и может выполнять только минимальный набор задач. Чаще всего закрывает текучку.
• «Стесняшка» — за таким нужно внимательно следить: он может знать теорию, но боится задавать вопросы, ему всегда необходим опытный коллега.
• «Админ» — человек из админов, со знаниями, готов развиваться в автоматизацию, разработку и коллаборацию с другими подразделениями. Чаще всего такие быстро становятся мидлами, но не всегда доходят до сеньоров.

Middle

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

• «Разработчик-интроверт» — он может быть хорошим специалистом, иметь прекрасные hard skills, но минимальный уровень гибких навыков, а потому над ним всегда должен быть сеньор или менеджер, который будет ему помогать.
• «Любитель поговорить» — обладает хорошими гибкими навыками и чуть выше уровня junior hard skills, на чём и выезжает. Активен, участвует во всех встречах, летучках, созвонах, сборах требований. Очень часто такие специалисты становятся менеджерами.
• «Проджект» — человек, обладающий неплохими гибкими навыками, неплохими hard skills, умеет делать проекты «от и до». Очень близок к сеньору.
• «Агрессор» — обладает хорошими hard skills и уверенно ими пользуется. Проблемы начинаются, если его часто отвлекают джуны: он открыто проявляет недовольство. К такому специалисту нужен особый подход: «агрессор» может решать сложные задачи, и задача его руководителей — минимизировать общение подчинённого с любознательными джунами и несознательными пользователями.

Senior DevOps

Это люди с огромным опытом, способные обучать начинающих специалистов, вести проекты от и до. Я общался с разными сеньорами:

• «Архитектор» — занимается проектированием hardware и app уровнями систем, которые только начинают или планируют внедряться. За счёт опыта и развитых навыков, жёстких и гибких, может один сделать проект от идеи до продакшена.

• «Активист» — говорлив, активен, энергичен. Часто посещает конференции, слушает подкасты, читает разные порталы. Такие девопсы очень часто участвуют в пилотах новых продуктов, предлагают продукты для внедрения и пилотов. Входят в различные инициативные группы и комитеты, помогая выстроить процесс. Чаще всего являются лидами.

• «Суперразработчик» — мог прийти из разработки или руководить ею. Версионирует код, следит за бранчами, занимается ревью. Могут решать низкоуровневые специализированные вопросы.

Начинайте составлять индивидуальный план развития с того, что лучше получается

Невозможно придумать универсальный ИПР: кто-то силён в разработке, кто-то в аналитике или архитектуре. Начинайте изучать программы и решать проблемы, используя свои сильные стороны, постепенно наращивая и компенсируя слабы, где-то взаимодействуя с коллегами, а где-то проходя курсы.

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

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. В проекты, которые используют что-то из них, идти стоит исключительно на свой страх и риск: себя в таких проектах найдут только инженеры с большим опытом или любители FreeBsd.

Лучшее обучение — это практика

DevOps, конечно, очень практическая штука. Задачи и инструменты у всех компаний разные. Но теория всё равно нужна, работать, не зная банальной терминологии и основ linux — сложно и не принесёт пользы. Есть множество бесплатных практикумов, разборов установки тулсетов и решения проблем на YouTube, статьи на Хабре. Чтобы разобраться, нужно брать различные кейсы развёртывания систем и пробовать: берите репы github и разворачивайте, настраивайте, ломайте, смотрите, что будет, лечите.

Но рано или поздно вам понадобится наставник — коллега, тимлид, который бы придумывал вам задания. Тут без практического навыка в работе либо ментора, который его имеет, дальше вы не пройдёте. Теория теорией, но практика, да ещё и в крупном enterprise — это небо и земля. Поэтому навыки и минимальный набор тулсетов развиваем на свободных, бесплатных, cloud free площадках, а остальное — либо у наставников, либо работая в этой сфере. Чем раньше вы начнёте это делать, тем лучше.

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

Когда включать в план обучения гибкие навыки

Всем всегда рекомендую начать с прикладных навыков и развития hard skills, поэтому советую следующие книги:

• Уорд Брайан, «Внутреннее устройство Linux»;
• Арнольд Роббинс, «Bash — карманный справочник для системного администратора»;
• Лорин Хоштейн, «Запускаем Ansible»;
• Michael Duffy, «DevOps Automation Cookbook»;
• Марко Лукша, «Kubernetes в действии».

Только после этого отправляйтесь учиться проджекту, гибким навыкам, процессам:

• Ким Джин, Бер Кевин, Спаффорд Джордж, «Проект „Феникс“. Как DevOps устраняет хаос и ускоряет развитие компании»;
• Kim Gene, Debois Patrick, Willis John, «The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations»;
• Авинаш Диксит, «Теория игр»;
• Эбихард Вольф, «Continuous delivery. Практика непрерывных апдейтов».