Developer

Кто такой Middle DevOps: ожидания, зона ответственности, стек, переход из бэкенда

↑ Этап 9 · Собес Middle DevOps: вопросы, практика, деплой систем

Обязательно~5 мин чтенияУровень: final

Зачем это на собесе

Понимание ожиданий помогает готовиться: что от вас хотят на уровне Middle и как показать переход из разработки в DevOps.

Роль DevOps

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

Вариации названий: DevOps Engineer, SRE (упор на надёжность и SLO), Platform Engineer (внутренняя платформа), Cloud Engineer, Release/Build Engineer, DevSecOps.

Ожидания по уровням

УровеньЧто делаетОжидания
Juniorвыполняет задачи по инструкциям: поддержка пайплайнов, деплой, мелкие скрипты, мониторингбазовый Linux, Git, Docker, понимание CI/CD
Middleсамостоятельно проектирует и ведёт сервисы/пайплайны/окружения, решает инциденты, оптимизируетуверенные Linux/сети, Docker/compose, CI/CD (GitLab), Nginx/TLS, IaC (Ansible/Terraform), основы Kubernetes, мониторинг (Prometheus/Grafana/логи), скрипты (Bash/Python), безопасность
Seniorархитектура платформы, надёжность (SLO), безопасность, стандарты, наставничество, влияние на несколько командHA/DR, GitOps, Kubernetes в проде, Vault, FinOps, процессы, выбор технологий
Lead/Headстратегия платформы, люди, бюджет

Middle DevOps должен: объяснить, как работает то, что использует (а не «нажал кнопку»); диагностировать проблемы по слоям; написать и отладить пайплайн; описать инфраструктуру кодом; обосновать выбор; думать о безопасности и надёжности; автоматизировать рутину; общаться с разработчиками и командой.

Зона ответственности

  • Сборка и доставка: CI/CD, артефакты, окружения, релизы, откат;
  • Инфраструктура: серверы/облако, сети, хранилища, конфигурация (Ansible/Terraform);
  • Контейнеры и оркестрация: Docker, compose, Kubernetes, Helm;
  • Наблюдаемость: метрики, логи, трейсы, дашборды, алерты;
  • Надёжность: бэкапы, HA/DR, инциденты, on-call, SLO;
  • Безопасность: секреты, доступы, сканирование, hardening, TLS;
  • Эффективность и стоимость: ресурсы, оптимизация, FinOps;
  • Поддержка разработчиков: окружения, инструменты, документация, консультации.

Технический стек (типичный)

ОбластьТехнологии
ОС и сетиLinux (Ubuntu/Debian/RHEL), systemd, Bash, SSH, TCP/IP, DNS, firewall, TLS
КонтейнерыDocker, docker-compose, registries (GitLab Registry, Harbor), Makefile
CI/CDGitLab CI (основной), GitHub Actions, Jenkins
Web/проксиNginx, reverse proxy, TLS (Let’s Encrypt), балансировка
ОркестрацияKubernetes, Helm, Kustomize, Ingress
IaCAnsible, Terraform
НаблюдаемостьPrometheus, Grafana, Loki/ELK, OpenTelemetry, Alertmanager
ДанныеPostgreSQL, Redis, ClickHouse, Kafka/RabbitMQ (эксплуатация), MinIO
БезопасностьKeycloak, Vault, Trivy, SOPS
ЯзыкиBash, Python, YAML/HCL, Go (плюс)

Переход из бэкенда/разработки

Сильные стороны разработчика: знание приложений и их поведения, код, тестирование, отладка, архитектура, CI — это преимущество (понимаете, что нужно коду в проде).

Что подтянуть: Linux и сети на уровне «под капотом», диагностика, инфраструктурные инструменты (IaC, оркестрация), эксплуатация (мониторинг, инциденты, on-call), безопасность, процессы; мышление «эксплуатации»: всё падает, автоматизируй, измеряй, минимизируй ручной труд.

План перехода:

  1. Закрепить основу: Linux, сети, Bash, Git (этап 1).
  2. Контейнеры и compose для своих сервисов (этап 2).
  3. CI/CD для собственных проектов (этап 3), GitLab CI.
  4. Nginx, TLS, деплой на VPS (этап 4) — настоящий сервер в интернете.
  5. IaC: Ansible для настройки сервера, Terraform для облака (этап 6).
  6. Kubernetes — на уровне уверенного пользователя (этап 5).
  7. Мониторинг и логи — подключить к своему проекту (этап 7).
  8. Проект-портфолио (homelab, см. следующую тему) и рассказ о нём.
  9. Практика инцидентов: разбирать сбои, писать постмортемы.
  10. Сертификации по желанию (CKA/CKAD, Terraform Associate, AWS/Yandex) — подтверждают знания, но не заменяют опыт.

Как выглядит собеседование

  1. Знакомство и опыт: рассказ о проектах, зоне ответственности, инструментах.
  2. Теория: Linux, сети, Docker, CI/CD, Nginx, Kubernetes, мониторинг, IaC, безопасность.
  3. Практика: разбор сценария («сайт не открывается», «диск заполнен», «под падает»), написание Dockerfile/compose/пайплайна/Ansible-плейбука, чтение логов/конфигов.
  4. Проектирование: развернуть сервис с нуля, построить CI/CD, спроектировать мониторинг, план миграции в Kubernetes.
  5. Поведенческие вопросы: инциденты, конфликты, ответственность, работа в команде/с разработчиками.
  6. Вопросы кандидата.

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

Как готовиться

  • делать руками: поднять VPS/VM, развернуть стек (приложение + БД + nginx + TLS + мониторинг), сломать и починить;
  • отвечать вслух на вопросы (объяснять для новичка);
  • готовить истории по STAR (инцидент, оптимизация, автоматизация);
  • читать чужие конфиги и инциденты (публичные постмортемы);
  • знать свой проект вдоль и поперёк (схема, решения, проблемы, метрики);
  • быть честным про границы знаний, демонстрировать способ рассуждения.

Типичные ошибки кандидатов

  • перечисление инструментов без понимания принципов;
  • «ручные» решения вместо автоматизации;
  • игнорирование безопасности и отката;
  • нет примеров из практики, только теория;
  • неумение объяснить, почему выбран инструмент;
  • не связывают инфраструктуру с продуктом и пользователями.

Вопросы с ответами

Вид графа

Обратные ссылки