Как перейти в DevOps-инженерию из другой области?

Честная отправная точка

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

Большинство людей, которые приходят в DevOps, двигаются с одного из двух направлений: из разработки программного обеспечения (написание кода, работа в команде, которая регулярно выпускает продукт, освоение конвейеров развёртывания по ходу дела) или из системного администрирования и инфраструктуры (управление серверами, сетями, позже облачными аккаунтами и освоение кода и автоматизации по ходу дела). Если вы приходите из совершенно другой области — службы поддержки, QA без автоматизации, нетехнической роли — переход возможен, но он займёт дольше, и вам следует планировать это честно, а не предполагать, что шести месяцев хватит.

Что действительно переносится

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

• Основы Linux. Если вы умеете ориентироваться в командной оболочке, управлять пользователями и правами доступа, читать логи и понимать процессы и службы (systemd в большинстве современных сред), это реальная, переносимая база. Большая часть работы в DevOps происходит на Linux, даже когда интерфейс — это консоль облака.
• Написание скриптов. Bash и Python — два языка, которые встречаются чаще всего: Bash для связующих задач и быстрой автоматизации, Python для всего, что требует больше логики (или Go в некоторых инфраструктурных командах). Если вы писали скрипты для автоматизации повторяющихся задач в любой работе, этот опыт считается, даже если сама работа не была технической.
• Система контроля версий. Git, используемый правильно — ветки, pull request'ы, разрешение конфликтов — а не просто «я использовал GitHub, чтобы что-то скачать». Это предполагаемое знание, а не преимущество, так что изучите это как следует, прежде чем подавать заявку.
• Основы сетей. DNS, HTTP, балансировка нагрузки, файрволы на концептуальном уровне. Вам не нужна сертификация по сетям, но вы должны уметь объяснить, почему запрос может не пройти между балансировщиком нагрузки и backend-сервисом.
• Работа в среде с производственными последствиями. Если вы поддерживали живую систему, были в графике дежурств или разбирались с отказом системы под давлением времени в любой технической роли, этот опыт ближе к реальности DevOps, чем многие теоретические курсы.
• Любой опыт работы с облаком. Даже базовое использование AWS, Azure или GCP — развёртывание личного проекта, управление хранилищем и вычислениями для хобби — стоит больше, чем может показаться, потому что такая большая часть работы сейчас происходит внутри одной из этих трёх платформ.

Что не переносится, независимо от вашего уровня в предыдущей области: опыт управления проектами, общее «я хорошо разбираюсь в технологиях» и использование инструмента как потребителя, а не его настройка или автоматизация. Менеджер по найму, читающий резюме на DevOps, может отличить того, кто запускал terraform apply на инфраструктуре, которую сам написал, от того, кто наблюдал, как это делает кто-то другой.

Путь сертификации и квалификации

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

• Сертификации облачных платформ — AWS Certified DevOps Engineer – Professional, Microsoft Azure DevOps Engineer Expert или Google Professional Cloud DevOps Engineer. Это самое близкое к признанной квалификации в этой области. Они непростые и предполагают, что у вас уже есть практический опыт работы с платформой, а не только учебные материалы — экзамены включают вопросы по сценариям, которые сложно сдать только на теории.
• Certified Kubernetes Administrator (CKA) от Cloud Native Computing Foundation. Kubernetes появляется в большой доле объявлений о вакансиях DevOps сейчас, и CKA — одна из немногих сертификаций в этой сфере, которая действительно практическая: вы администрируете реальный кластер во время экзамена, а не отвечаете на вопросы с вариантами ответов.
• HashiCorp Certified: Terraform Associate. Инфраструктура как код теперь почти универсальна в этой роли, и Terraform — инструмент, который называют в большинстве объявлений конкретно.

Ни одна из этих сертификаций не заменяет портфолио. Работодатели, нанимающие DevOps-инженеров, обычно хотят видеть работу, а не только полномочия — профиль GitHub с реальным инфраструктурным кодом, задокументированную домашнюю лабораторию, пост в блоге с объяснением того, как вы построили CI/CD-конвейер для личного проекта. Если вы можете сделать только одно перед началом поиска, создайте что-то, что можете показать и подробно обсудить, затем получите сертификацию, которая соответствует этому.

С чем должна справиться ваша заявка

Заявка на DevOps при смене карьеры сталкивается с конкретным, повторяющимся возражением: читатель предполагает, что вы универсал, посмотревший несколько уроков, а не тот, кому можно доверить производственную инфраструктуру и график дежурств. Вы должны ответить на это возражение напрямую, потому что одно резюме не справится.

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

Вторая проблема — глубина против широты. Те, кто меняет карьеру, часто перечисляют каждый инструмент, к которому прикасались один раз (Docker, Jenkins, Ansible, Prometheus, Grafana, Kubernetes), не будучи способными углубиться хотя бы на два вопроса в любом из них. Интервьюеры в этой области задают вопросы типа «расскажите, что происходит, когда запускается этот конвейер» или «что вы проверите первым, если это развёртывание упадёт в 2 часа ночи» — вопросы, которые отделяют людей, настроивших что-то один раз, от тех, кто это понимает. Выберите меньше инструментов и знайте их как следует, вместо того чтобы перечислять всё, на что бегло взглянули.

Третья проблема — история. Вам нужен внятный ответ на вопрос «почему DevOps, почему сейчас», и он должен быть о работе, а не о побеге из старой области. «Я был тем, кто автоматизировал всё, что моя команда делала вручную» — это реальный ответ. «Я хочу перемен, и DevOps хорошо платит» — правда для многих, но не выдерживает собеседования.

Сколько это реально займёт

Нет достоверных опубликованных данных о том, сколько времени занимает смена карьеры на DevOps, и относитесь скептически к тем, кто приводит цифры, потому что это огромно зависит от вашей отправной точки. Что можно сказать честно:

Если вы уже разработчик программного обеспечения, переход в сторону DevOps или platform engineering реалистично занимает месяцы — вы расширяете навыки, которые уже есть, и многие компании нанимают разработчиков на эти роли именно потому, что они умеют программировать.

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

Если вы приходите из нетехнической области, будьте реалистичны: это обычно проект на один-два года, а не результат выходного буткемпа, если вы строите почти с нуля — изучаете Linux, язык скриптов, основы облака и портфолио, вероятно работая на текущей работе. Буткемпы и короткие курсы существуют, и некоторых людей действительно нанимают после них, но рынок вакансий уровня junior с меткой «DevOps» узок; большинство объявлений о вакансиях, использующих этот титул, ожидают некоторого предварительного опыта в инфраструктуре или разработке, потому что роль находится ниже по течению от обеих дисциплин, а не является точкой входа для новичков ни в одну из них.

Что делать дальше

Честно определите, к какой из двух отправных точек вы ближе — разработчик или инфраструктура — и намеренно стройте недостающую половину: разработчикам нужны Linux, сети и инфраструктура-как-код; системным администраторам нужна глубина в скриптинге и опыт работы с CI/CD-конвейерами. Создайте один реальный проект, который можете подробно обсудить, сдайте сертификацию, которая ему соответствует, и перепишите резюме так, чтобы релевантные доказательства находились в первой трети страницы, а не в последней. Когда будете готовы подавать заявки, jobmarket.pro сравнивает каждое объявление с вашим реальным профилем и сообщает вам, ещё до того как вы что-то отправите, где вы действительно подходите, а где нет.