DevOps изнутри: мой путь, работа и собеседования

Если хочешь сначала увидеть сам разговор о профессии, открой моё техническое собеседование DevOps или собеседование в VK. Подробный учебный маршрут с нуля есть отдельно на Dev0pser.

Что для меня стоит за словом DevOps

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

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

Особенно мне не нравится образ инженера, который обязан первым просыпаться при любой проблеме просто потому, что он DevOps. Дежурства, ответственность и доступность — условия конкретной работы. Их стоит обсуждать, а не принимать как пожизненную подписку на ночные инциденты.

Работа — не весь список из вакансии каждый день

В вакансии могут перечислить Linux, Kubernetes, Terraform, Ansible, облака, базы и мониторинг. Это ещё не значит, что рабочий день состоит из экзамена по всему списку. После выхода появляются конкретные задачи и ограничения.

• Выкатить изменение. Понять, что собирается, что проверяется, куда попадёт результат и как откатиться.
• Разобраться, почему не работает. Посмотреть сигналы, логи, сеть, состояние окружения — а не просто вспомнить определение инструмента.
• Убрать ручную возню. Найти повторяющееся действие и сделать его воспроизводимым.
• Сделать систему понятнее. Не только починить сейчас, но и оставить возможность разобраться в следующий раз.

Это примеры задач, а не описание каждого моего рабочего дня. Для меня главное отличие от собеса — контекст. На интервью вопрос можно получить из ниоткуда. В работе есть конкретная система, коллеги, история изменений и время на исследование.

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

Деньги, о которых есть записи

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

Для меня сумма интересна вместе с тем, что за неё покупают. Нормальная нагрузка, удалёнка, постоянные дежурства, количество созвонов — всё это меняет сделку. Название Senior само по себе не расскажет, сколько жизни останется после работы.

Если нужны ориентиры для первого выхода, смотри зарплаты новичков на Dev0pser. Если уже работаешь — зарплаты и уровни на IT-Para. А интервью на другом языке можно сравнить в моём разборе валютной удалёнки: иностранная компания не становится автоматически лучшей только из-за страны.

Я не ждал, пока выучу весь стек

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

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

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

Где практика начинает быть настоящей

Небольшой стенд полезен: можно развернуть приложение, настроить сборку, поменять конфигурацию и увидеть, что сломалось. Не ради красивой галочки «есть pet-проект», а чтобы получить вопросы, с которыми дальше разбираться.

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

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

После выхода на новую роль учёба становится частью задачи. Документация, чужой код, история изменений, тестовая среда — всё это уже под рукой. Как я отношусь к этому периоду, описал в статье про испытательный срок.

Как я смотрю на переход из администрирования

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

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

И я не предлагаю ограничивать себя словом junior только потому, что следующая роль новая. Можно смотреть требования middle, разбирать их и пробовать технические разговоры. Успешное интервью не выдаётся за смелость, но отказ от попытки вообще ничего не проверяет.

Для подготовки есть банк вопросов DevOps и банк Linux-администратора. Большую часть вопросов задавали мне, часть добавлена для подготовки. Это хороший ориентир, не точный сценарий того, что обязательно спросят. Как я вообще вошёл в индустрию — моя история после ПТУ.

Что видно на SRE, MLOps и других собеседованиях

Меня интересовало, что находится за пределами одной привычной роли. На канале есть MLOps-собеседование с вопросами про RAG и LLM и собеседование на технического директора. Участие в таком разговоре не означает, что я занимал каждую из этих должностей.

В смежных направлениях меняется акцент: в SRE больше внимания надёжности и инцидентам, в MLOps — данным, моделям и их эксплуатации, в платформенной работе — инструментам для других инженеров. Полезно смотреть не только на новое название, но и на то, чего потребуют от тебя в задачах.

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

Что посмотреть и где искать обсуждения

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

Ниже — тематическая подборка: вакансии, практика и обсуждения. Выбирай то, что помогает разобраться с текущей задачей:

• Вакансии: @devops_jobs, @devopssjob, @jobGeeks.
• Новости и практика: @i_DevOps, @devops_fm, @flant_ru.
• Kubernetes: @kubernetes_ru, @devopsbrain, @kubernative.
• Мониторинг и логи: @monitorim_it, @metrics_ru, @ru_logs.
• Безопасность: @k8security, @sec_devops.
• Конференции и юмор: @DevOpsConfChannel, @devops_memops.

Частые вопросы

Видео по теме

Техническое собеседование DevOps DevOps собеседование в VK MLOps собеседование: RAG и LLM