Дорожная карта навыков DevOps-инженера на 2026 год

DevOps в 2026 году — это платформенный инжиниринг плюс SRE плюс остаточная репутация «человека по CI/CD», которая у некоторых компаний всё ещё держится. Эта дорожная карта охватывает современный стек — Kubernetes, Terraform, observability, SLO, секреты — и план на 12 месяцев, чтобы стать DevOps/платформенным инженером, которого нанимают.

Многие компании перестали называть роль «DevOps» и теперь называют её «платформенный инженер», «SRE» или «инфраструктурный инженер». Работа сильно пересекается. Если вы умеете эксплуатировать Kubernetes-кластер, писать Terraform, который не утекает учётными данными, выкатывать CI/CD, который разработчикам действительно нравится, и отвечать на пейдж в три часа ночи, не ухудшая ситуацию, — вы найдёте роль хотя бы под одним из этих названий.

Кто такой DevOps-инженер в 2026 году

DevOps/платформенный инженер владеет путём от кода до production. Конкретно:

• Проектирует и поддерживает CI/CD-пайплайны, которыми разработчики могут пользоваться без заведения тикетов.
• Владеет облачной инфраструктурой как кодом — Terraform/Pulumi, с ревьюабельными PR и хранилищем состояния, которое не теряет данные.
• Эксплуатирует production Kubernetes-кластер (или serverless-эквивалент) и дежурит за него on-call.
• Владеет observability: метрики, логи, трейсы, алерты, runbook'и, бюджеты ошибок.
• Управляет секретами, IAM, сетевыми политиками и скучными частями безопасности, за которые больше никто не вызывается.

Junior DevOps: пишет GitHub Action, дебажит пайплайн. Middle: владеет инфраструктурой сервиса целиком, включая его дашборды. Senior: проектирует платформу, на которой строят несколько команд, задаёт SLO, ведёт процесс разбора инцидентов.

Базовый стек — что действительно учить

Soft skills и системное мышление

• Эмпатия к разработчику. Платформа, которую вы строите, — для других инженеров. Если они заводят тикеты, чтобы ею воспользоваться, вы построили не ту платформу.
• Дисциплина безвинных постмортемов. Сбои системны. Подавайте пример: признайте свою часть отказа, фокусируйтесь на системных фиксах.
• Осознание стоимости. Облачные счета быстро выходят из-под контроля. Senior DevOps-инженер срезает 20–30% со счёта в течение месяцев после прихода в большинство компаний.
• Скучное — это хорошо. Скучная инфраструктура — надёжная инфраструктура. Сопротивляйтесь желанию использовать новейший инструмент.
• Документация как привычка. Runbook'и, архитектурные диаграммы, decision records. Инженер, который документирует, владеет слоем.

Рекомендуемый план на 3 / 6 / 12 месяцев

Месяцы 1–3: Linux + Docker + основы облака

• Освойтесь в командной строке. Настройте homelab или аккаунт облака на бесплатном тарифе.
• Изучите Docker как следует: multi-stage builds, сети, тома, Compose.
• Выберите одно облако. Задеплойте небольшой сервис вручную. Изучите IAM, VPC и базовые сети.

Месяцы 4–6: Kubernetes + IaC

• Запустите Kubernetes-кластер (k3s, kind или managed). Задеплойте реальное приложение с ingress, секретами и persistent volumes.
• Изучите Terraform. Управляйте кластером, DNS, хранилищем секретов кодом.
• Настройте CI/CD-пайплайн (GitHub Actions или GitLab CI), который собирает, тестирует и деплоит в ваш кластер.
• Прочитайте «The Phoenix Project» и «Google SRE Book» (бесплатно онлайн).

Месяцы 7–12: observability, SRE, собеседования

• Настройте Prometheus + Grafana + Loki + Alertmanager на своём кластере. Постройте один реальный дашборд.
• Определите SLO для своего приложения и бюджет ошибок. Проведите chaos-эксперимент, который его исчерпывает.
• Практикуйте DevOps system design: спроектируйте CI/CD-платформу, спроектируйте пайплайн логирования, спроектируйте мультирегиональный деплой.
• Откликайтесь с портфолио, в котором есть один GitHub-репозиторий с полной IaC, CI/CD и скриншотами дашбордов.

Пет-проекты для портфолио

• Полная GitOps-платформа в одном репозитории. Terraform для кластера, ArgoCD для приложений, стек Prometheus для observability. Демонстрирует всё вместе.
• Мультисредовый IaC-layout. Dev/staging/prod с разделением по workspace или директориям, детектирование дрейфа, plan-on-PR. Показывает реальную структуру.
• Kubernetes-оператор (небольшой). Напишите контроллер для кастомного ресурса. Демонстрирует глубину за пределами поверхностного kubectl.
• Разбор оптимизации стоимости. Возьмите реальный или симулированный счёт и покажите шаги, как срезать его на 30%. FinOps всё больше становится частью роли.

SLO, бюджеты ошибок и здравый смысл on-call

Практики SRE, которые отделяют senior DevOps-инженеров от «строит пайплайны», происходят из одного ментального сдвига: нельзя одновременно максимизировать надёжность и скорость поставки функций, поэтому компромисс нужно делать явным.

• Выберите один SLI на сервис. Доступность для API. Сквозная задержка для критичного пользовательского флоу. Доля успешных задач для воркера. Выбирайте тот, что отражает пользовательский опыт, а не внутренние метрики.
• Задайте SLO на правильном уровне. 99,9% звучит разумно, пока вы не осознаете, что это 43 минуты бюджета простоя в месяц. 99,99% — это 4 минуты в месяц, и при таком уровне нельзя деплоить еженедельно.
• Используйте бюджет ошибок. Если у вас 30 минут бюджета простоя в этом квартале, потратьте 20 из них на рискованные деплои. Если вы исчерпали бюджет, заморозьте деплои функций до следующего окна.
• Runbook'и бьют героев. Каждый алерт ведёт на runbook с первыми тремя диагностическими командами. Дежурный инженер, который никогда не касался этого сервиса, не должен пейджить эксперта в три часа ночи.
• Пейджите по делу, не информативно. Алерт, не требующий человеческого действия, не должен пейджить. Переведите его в дашборд, еженедельный отчёт или удалите. Усталость от пейджера — тихий убийца качества on-call.
• Безвинные постмортемы. Action items фокусируются на системе, а не на человеке. «Инженер X задеплоил без staging» — это не первопричина; «пайплайн позволил деплой в prod без зелёного staging» — да.
• Game days. Запланируйте один раз в квартал, специально сломайте что-то в staging, проведите инцидент. Навык incident command быстро деградирует без практики.

На senior-собеседованиях вопрос редко звучит как «знаете ли вы K8s». Он звучит так: «разберите со мной последний production-инцидент, который вы вели». Имейте наготове таймлайн, шаги диагностики, немедленный фикс и системное изменение.

Как получить роль DevOps-инженера

• Ключевые слова в резюме. Kubernetes, Terraform, AWS или GCP, инструмент CI/CD, Prometheus, Grafana, OpenTelemetry, Helm, GitHub Actions, ArgoCD если применимо.
• Один репозиторий со всем настроенным. Единственный самый сигнальный артефакт — деплоябельная, задокументированная платформа.
• Раунды собеседования: диагностика Linux/сетей, system design (постройте CI/CD или observability-пайплайн), behavioral с историями on-call, иногда take-home (напишите Terraform-модуль).
• Раунд диагностики. Часто вживую: «вот сломанный Kubernetes-деплой, почините его». Практикуйте на специально сломанных кластерах.
• История on-call. Имейте наготове 4–5 историй об инцидентах. Что сломалось, как нашли, что изменили, какой системный фикс последовал.

FAQ