Roadmap DevOps-инженера в 2026 году: что учить и в каком порядке

DevOps часто выглядит как бесконечный список инструментов: Linux, Git, Docker, CI/CD, Terraform, Kubernetes, облака, мониторинг, безопасность, GitOps. Из-за этого новички хватаются за самый громкий термин и быстро упираются в стену: без базы даже kubectl и terraform apply превращаются в магические заклинания.

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

Схема-подсказка: как двигаться по DevOps-слоям от базы и автоматизации к Kubernetes, наблюдаемости и платформенному слою.

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

Что входит в работу DevOps-инженера

DevOps-инженер не просто «настраивает Kubernetes». Его задача — делать путь от коммита до работающего сервиса быстрым, предсказуемым и безопасным. Это значит, что нужно уметь читать код, понимать инфраструктуру, автоматизировать рутину, наблюдать систему после релиза и быстро чинить её, когда что-то пошло не так.

На практике в работу входят пять больших зон: среда исполнения, доставка изменений, инфраструктура, эксплуатация и безопасность. Поэтому хороший план обучения всегда шире, чем набор из Docker, Kubernetes и Terraform.

• Среда исполнения: Linux, процессы, файлы, сеть, сервисы, контейнеры.
• Доставка: Git, pull request, CI/CD, артефакты, окружения, rollback.
• Инфраструктура: облако, сети, IAM, Terraform, Ansible, managed-сервисы.
• Эксплуатация: метрики, логи, трассировка, алерты, инциденты, SLA и SLO.
• Безопасность: секреты, права доступа, сканирование образов, supply chain, политики.

Шаг 1. База: Linux, терминал, сети и скрипты

Первый слой DevOps — это не облака и не кластеры. Это уверенная работа в Linux, понимание того, как живут процессы и сервисы, умение читать логи и свободно пользоваться терминалом. Если вы не понимаете, что делает systemd, чем отличается порт от сокета и почему DNS резолвится не туда, дальше будет очень много механики без понимания.

Сюда же относится базовое скриптование. Не нужно сразу становиться backend-разработчиком, но умение писать небольшие утилиты на Bash или Python на практике очень помогает: разбирать логи, чистить артефакты, собирать конфиги, запускать health-check, дёргать API. Без этого DevOps быстро превращается в бесконечное копирование команд из чужих README.

• Linux: файловая система, права, процессы, systemd, пакеты, сервисы, cron.
• Terminal: ssh, curl, grep, sed, awk, перенаправления, пайпы.
• Сети: DNS, HTTP/HTTPS, TLS, reverse proxy, firewall, балансировщик, NAT.
• Скрипты: Bash для короткой автоматизации, Python или Go для более сложных утилит.
• Результат этапа: вы можете зайти на сервер, понять, что на нём происходит, и автоматизировать простую рутину без GUI.

Для входа в этот слой пригодятся материалы 100 команд Linux для ежедневной работы и что такое Git и GitHub. Даже если ваша цель — Kubernetes, этот фундамент пропускать нельзя.

Шаг 1.2. Язык для автоматизации: Bash, Python или Go

В полной карте DevOps почти всегда есть отдельная ветка про язык программирования. Смысл не в том, чтобы срочно стать backend-разработчиком на новом стеке, а в том, чтобы уметь писать автоматизацию, разбирать данные, работать с API и не бояться внутренностей CI/CD-скриптов. Для старта почти всегда достаточно Bash и Python; позже во многих инфраструктурных командах всплывает Go, потому что на нём написано много облачных и Kubernetes-инструментов.

Лучший практический подход такой: короткие shell-скрипты и glue-логика делайте на Bash, утилиты посложнее и интеграции с API пишите на Python, а Go держите как полезный следующий слой для более серьёзной автоматизации и понимания экосистемы Kubernetes. Ruby, JavaScript или Rust тоже встречаются, но они уже зависят от конкретной команды и окружения.

• Bash нужен почти каждому DevOps-инженеру: shell-обвязка, команды, пайплайны, entrypoint-скрипты, быстрая диагностика.
• Python удобен для API-интеграций, генерации конфигов, внутренней автоматизации и небольших CLI-утилит.
• Go полезен как следующий шаг: Terraform-, Kubernetes- и cloud-экосистема часто живёт рядом с ним.
• Результат этапа: вы умеете не только запускать команды, но и собирать из них рабочую автоматизацию.

Шаг 1.5. Терминальные инструменты, редакторы и базовая диагностика

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

Сюда же относятся редакторы и инструменты для правки текста прямо на машине. Не обязательно фанатично жить в vim, но знать хотя бы один консольный редактор полезно. Если вы иногда работаете с Windows-средой, пригодится и базовый PowerShell. В некоторых командах встречаются Windows-узлы или BSD-системы, но для старта основным остаётся Linux-маршрут: сама идея одна и та же, вы умеете диагностировать систему без GUI.

• Диагностика процессов и ресурсов: ps, top, htop, lsof, ss, journalctl, free, df.
• Текст и данные: grep, sed, awk, cut, sort, uniq, jq.
• Редакторы: vim, nano, VS Code Remote или любой другой инструмент, которым вы реально можете править конфиг на сервере без паники.
• Результат этапа: вы можете диагностировать систему, править конфиг, фильтровать данные и не тонуть в логах и процессах.

Шаг 1.6. Прокси, веб-серверы, балансировка и сетевые протоколы

В полной карте навыков отдельно вынесены forward proxy, reverse proxy, firewall, load balancer, caching server и web server. Для DevOps это фундамент прикладной инфраструктуры. Даже если вы не будете администрировать почтовые системы или edge-инфраструктуру каждый день, вы должны понимать, где заканчивается приложение и начинается сетевой слой перед ним.

Минимум на старте — уверенно разбираться в DNS, HTTP/HTTPS, TLS и SSH. Полезно знать, зачем нужны Nginx, Caddy, Apache или IIS, чем reverse proxy отличается от forward proxy, как работает кеширование на уровне приложения и фронт-прокси, и что делает балансировщик перед несколькими инстансами сервиса. Если проект касается почты, пригодятся и базовые представления о SMTP, IMAP/POP3, SPF, DKIM и DMARC.

Отдельный практический навык на этом слое — troubleshooting сетевых сбоёв. Нужно хотя бы на базовом уровне понимать TCP/IP, TLS-handshake, как читать ответ curl -v, чем помогают dig, nslookup, traceroute, mtr и tcpdump. Без этого любой сбой быстро превращается в гадание между приложением, прокси, DNS и сертификатом.

• Протоколы: DNS, HTTP/HTTPS, TLS, SSH, FTP/SFTP; для почтовой инфраструктуры — SMTP, IMAP, POP3, SPF, DKIM, DMARC.
• Сетевые примитивы: OSI-модель на практическом уровне, порты, NAT, firewall rules, white- и graylisting там, где это действительно нужно.
• Серверы и прокси: Nginx, Caddy, Apache HTTP Server, Tomcat, IIS, reverse proxy, forward proxy, caching layer, load balancer.
• Результат этапа: вы понимаете, как трафик доходит до сервиса, где его можно завернуть, защитить, закешировать или распределить.

Шаг 1.7. Когда нужен Windows- и PowerShell-путь

Большая часть DevOps-маршрута действительно крутится вокруг Linux, но в реальной инфраструктуре периодически встречаются Windows-серверы, AD-среды, IIS, .NET-сервисы и корпоративная автоматизация через PowerShell. Поэтому полезно понимать, где заканчивается универсальный Linux-фундамент и начинается специфический Windows-путь.

Для первого входа в профессию не нужно строить отдельную карьеру вокруг Windows, если ваша цель — современный облачный стек. Но знать базовый PowerShell, устройство Windows-сервисов, права, scheduled tasks и особенности IIS полезно. Это даёт гибкость: вы понимаете, как жить не только в Linux-кластере, но и в смешанной корпоративной инфраструктуре.

• PowerShell пригодится там, где есть Windows-серверы, AD, IIS или корпоративная автоматизация.
• Linux остаётся основным путём для старта, но знание Windows-инструментов расширяет рынок и спектр задач.
• Если ваша цель — современный облачный стек, держите Windows как дополнительную ветку, а не как главный трек.
• Результат этапа: вы понимаете, когда PowerShell действительно нужен, а когда достаточно Linux-инструментов.

Шаг 2. Git, GitHub и командная разработка

Следующий обязательный слой — контроль версий и нормальная командная работа. DevOps живёт вокруг изменений: кто что поменял, где сломалось, как откатить, что именно уехало в релиз. Если Git для вас всё ещё сводится к git add . и git push, вы будете постоянно терять контекст.

Нужно уметь не только коммитить, но и читать diff, разбирать конфликты, работать с ветками, pull request и review. Отдельно полезно понимать, как устроены GitHub, GitLab и Bitbucket как платформы: secrets, actions или pipelines, registry, environments, protected branches, runners. Подробный разбор — в нашем полном путеводителе по Git.

• Минимум: commit, branch, merge, rebase, tags, releases, pull request.
• Командная часть: code review, правила ветвления, шаблоны PR, protected branches.
• Платформа: GitHub Actions, GitLab CI или Bitbucket Pipelines как часть экосистемы вокруг репозитория.
• Результат этапа: вы воспринимаете репозиторий как источник истины не только для кода, но и для процессов доставки.

Шаг 2.5. GitHub, GitLab и Bitbucket как платформы

Отдельная ветка в карте DevOps — это платформы вокруг репозитория. Репозиторий сегодня почти всегда живёт не в вакууме, а внутри сервиса, где рядом находятся pull request, трекинг задач, CI/CD, secrets, environments, registry, релизы и права доступа. Поэтому GitHub, GitLab и Bitbucket полезно воспринимать не просто как место для git push, а как управляющий слой вокруг разработки и доставки.

На старте не так важно, какой именно сервис вы выберете. Гораздо важнее понять общую модель: репозиторий связан с пайплайнами, секретами, защитой веток, код-ревью и артефактами. Если это уложилось в голове, переход между GitHub, GitLab и Bitbucket становится намного проще, потому что вы уже понимаете не кнопки, а саму логику платформы.

• GitHub часто удобен для старта и открытых проектов, GitLab силён как единая платформа, Bitbucket регулярно встречается в корпоративной среде.
• Общие сущности у них одни и те же: PR или MR, protected branches, runners, registry, secrets, environments, release-процесс.
• Полезный навык здесь — не “знать все вкладки”, а понимать, как VCS-платформа связывает код, review, CI/CD и доступы.
• Результат этапа: вы работаете не просто с Git, а с полноценной инженерной платформой вокруг репозитория.

Шаг 3. Контейнеры, Docker и повторяемое окружение

После Git начинается первый по-настоящему практический слой DevOps: повторяемое окружение. Здесь на сцену выходит Docker. Пока приложение нельзя одинаково запустить у разработчика, в CI и на сервере, разговоры про зрелую автоматизацию бессмысленны.

На этом этапе важно не просто уметь стартовать контейнер, а понимать, как он устроен: образ, слой, registry, volume, сеть, переменные окружения, multi-stage build. Полезно хотя бы на уровне ориентира знать, что рядом существуют и более низкоуровневые контейнерные технологии вроде LXC. Отдельный обязательный навык — собрать локальный стенд из нескольких сервисов: приложение, база данных, очередь, reverse proxy.

• Освойте Dockerfile, docker build, docker run и docker compose; как ориентир держите в голове и LXC как соседний класс технологий.
• Поймите разницу между образом, контейнером, volume, сетью и registry.
• Научитесь публиковать образы в registry и тянуть их в CI.
• Результат этапа: один и тот же сервис поднимается локально, в тестовой среде и в pipeline без разъезда зависимостей.

Шаг 4. CI/CD, артефакты и среды поставки

Когда код уже живёт в Git, а приложение работает в контейнере, логично автоматизировать доставку. CI/CD — это не «ещё один сервис ради галочки», а механизм, который собирает, проверяет и продвигает артефакт по средам без ручной рутины. Для старта достаточно понять модель pipeline, а не спорить о брендах.

На этом этапе кроме самого pipeline нужно разобраться ещё с тремя вещами: где лежат артефакты, как устроены окружения и как делается откат. Реальный CI/CD — это не только тесты и сборка, но и публикация образа, миграции, промоушен между dev, staging и production, ручные approvals и rollback.

• Базовый набор: job, stage, runner, cache, artifacts, variables, secrets.
• Инструменты для старта: CI/CD, GitHub Actions, GitLab CI, Jenkins, а как ориентир по рынку — CircleCI, TeamCity и Octopus Deploy.
• Артефакты: registry для образов, package registry для зависимостей, release-версии.
• Результат этапа: после коммита система сама собирает, тестирует и готовит сервис к выкладке.

Если на этом этапе пропустить тему артефактов и сред, дальше начнутся типичные проблемы: в production уехал не тот образ, staging живёт отдельно от CI, а rollback зависит от памяти одного человека. Поэтому этот слой нужно довести до реальной практики, а не до уровня демо-пайплайна из трёх шагов.

Шаг 4.5. Артефакты, registry и package-хранилища

Полный DevOps-путь почти всегда упирается не только в pipeline, но и в место, где живут артефакты. Docker image, release-архив, Helm chart, внутренний пакет библиотеки — всё это должно быть версионируемым, неизменяемым и доступным для доставки в нужную среду. Поэтому управление артефактами в DevOps выделяют в отдельный слой.

На старте достаточно понимать принцип и знать несколько типовых инструментов: реестр контейнеров, пакетное хранилище, а в более зрелой среде — Artifactory, Nexus или Cloudsmith. Важна не марка продукта, а дисциплина: артефакт собирается один раз, получает версию или digest, проходит проверки и дальше только продвигается между окружениями.

• Registry и репозитории нужны для образов, пакетов, chart-ов и бинарных артефактов.
• Immutable artefact важнее названия инструмента: пересобирать один и тот же релиз под каждой средой — плохая идея.
• Проверки на этом слое: digest, SBOM, provenance, политика хранения, очистка старых версий.
• Результат этапа: вы всегда знаете, какой именно артефакт уехал в staging и production.

Упрощённая цепочка: от коммита и CI до деплоя, метрик, логов и обратной связи в команду.

Шаг 5. Облака, сети, IAM и инфраструктура как код

После доставки встаёт вопрос: где всё это живёт и как этим управлять без ручного кликанья в панели облака. Здесь начинается инфраструктура как код. Нужно понимать не только Terraform и Ansible, но и сами строительные блоки: виртуальные машины, сети, балансировщики, объектные хранилища, управляемые базы данных, IAM, DNS, сертификаты и секреты.

Новички часто пытаются сразу выучить три облака, десять сервисов и все инструменты IaC. Это плохая стратегия. На старте достаточно одного облака и одной понятной связки: например, Terraform для описания ресурсов и Ansible для конфигурации машин или прикладной автоматизации поверх них.

Самый полезный первый сценарий здесь очень приземлённый: поднимите в одном облаке сеть, одну виртуальную машину, DNS-запись, сертификат, балансировщик или reverse proxy и выкатите туда свой контейнерный сервис. Если вы можете описать этот путь в Terraform, а потом воспроизвести окружение заново, слой уже перестаёт быть абстракцией.

• Terraform отвечает за ресурсы: VPC, подсети, серверы, балансировщики, DNS, managed-сервисы.
• Ansible помогает настраивать машины, пакеты, конфиги и прикладные роли после их создания.
• Обязательно понять IAM: роли, пользователи, политики, принцип наименьших привилегий.
• Освойте одно облако: AWS, GCP, Azure, DigitalOcean, Hetzner, Alibaba Cloud, Heroku, Contabo или другой провайдер, но не все сразу.
• Смотрите на стоимость с самого начала: тэги, бюджеты, права на выключение idle-ресурсов, размеры инстансов и storage lifecycle.
• Результат этапа: вы можете заново поднять окружение из кода и объяснить, кто к чему имеет доступ.

Terraform — не единственный путь. В больших облаках часто встречаются CloudFormation, AWS CDK и Pulumi: они помогают описывать инфраструктуру либо декларативно, либо через знакомый язык программирования. Полезно знать, что такие ветки существуют, но для старта одной модели достаточно: сначала понять сам принцип provisioning, а уже потом выбирать синтаксис и экосистему.

То же самое касается configuration management. В roadmap рядом с Ansible стоят Chef и Puppet — чаще они живут в старых enterprise-средах. Для новичка важно знать, что это класс инструментов для конфигурации машин и сервисов, но начинать проще с Ansible и одного облака, а не пытаться учить все подходы сразу.

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

Шаг 6. Kubernetes, Helm и оркестрация

Как правило, после контейнеров, pipeline и базовой инфраструктуры имеет смысл переходить к Kubernetes. Иначе оркестрация будет выглядеть как стена терминов: pod, deployment, service, ingress, configmap, secret, autoscaling, statefulset. Kubernetes не заменяет Docker и CI/CD, а строится поверх них.

На этом этапе важно научиться думать не «как запустить контейнер», а «как описать приложение как систему»: сервис, конфигурация, ingress, secrets, health probes, ресурсы, rollout и rollback. Сразу после этого почти неизбежно появляется Helm, потому что вручную копировать YAML по окружениям долго и опасно.

• Kubernetes: pod, deployment, service, ingress, configmap, secret, namespace, HPA.
• Helm: chart, values, templates, releases, upgrade, rollback.
• Не пропускайте управляемые кластеры: EKS, GKE, AKS помогают понять практику без раннего героизма с self-hosted-установками.
• Результат этапа: приложение описано как релиз в кластере, а выкладка перестаёт зависеть от ручного редактирования YAML.

Здесь же стоит впервые по-настоящему заняться секретами. Если секреты лежат рядом с конфигами, например прямо в values.yaml или в переменных на одном сервере без отдельного механизма управления, система остаётся хрупкой. DevOps-маршрут без secret management и нормального доступа к конфигам всегда упирается в безопасность и аудит.

Шаг 6.5. Когда вместо Kubernetes подходят serverless и managed-платформы

В полном DevOps-roadmap рядом с Kubernetes стоят не только managed-кластеры, но и альтернативы: ECS/Fargate, Docker Swarm, AWS Lambda, Azure Functions, Cloudflare Workers, Vercel, Netlify и другие платформы, где часть операционной сложности уже скрыта. Это важная ветка, потому что не каждому проекту нужен полноценный Kubernetes-кластер.

Практическое правило простое. Если у вас небольшой сервис, предсказуемая нагрузка и нет сложной платформенной инфраструктуры, managed-платформа или serverless могут дать более короткий путь в production. Kubernetes нужен там, где важны стандартизация, плотная оркестрация, множественные сервисы, сложные rollout-ы и контроль над платформой. Поэтому DevOps-инженеру полезно понимать и этот выбор, а не сводить всё к одной технологии.

• Managed orchestration: EKS, GKE, AKS, ECS/Fargate, Docker Swarm как разные точки на шкале контроля и сложности.
• Serverless и edge-платформы: AWS Lambda, Azure Functions, Cloudflare Workers, Vercel, Netlify.
• Вопрос выбора: сколько платформы вы хотите администрировать сами, а сколько готовы отдать провайдеру.
• Результат этапа: вы умеете выбирать модель запуска под задачу, а не тянуть Kubernetes туда, где он не нужен.

Сравнение четырёх моделей запуска: VM, Docker, Kubernetes и managed/serverless.

Шаг 7. Наблюдаемость, алерты и работа с инцидентами

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

Полезно научиться отвечать на четыре вопроса: что сломалось, насколько это критично, где искать причину и как быстро откатиться или стабилизировать систему. Для этого нужен не только дашборд, но и набор сигналов: технические метрики, бизнес-метрики, логи приложений, трассировка запросов, health-check и понятные пороги тревоги.

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

• Метрики и дашборды: Grafana, Prometheus, SLI и SLO.
• Логи: централизованный сбор, поиск по сервисам, correlation id, retention.
• Трассировка: OpenTelemetry и распределённые traces для сложных цепочек запросов.
• Инциденты: алерты, on-call, runbook, postmortem, rollback как нормальная часть процесса.
• Результат этапа: вы не просто релизите сервис, а умеете доказуемо поддерживать его в рабочем состоянии.

Шаг 7.5. Логи, трассировка и стек наблюдаемости целиком

Чтобы покрыть карту DevOps почти полностью, важно смотреть на observability как на стек, а не на один дашборд. В инфраструктурном мониторинге часто встречаются Prometheus, Grafana, Zabbix, Datadog и New Relic. Для логов — Elastic Stack, Graylog, Splunk, Papertrail, Loki. Для трассировки и мониторинга приложений — Jaeger и OpenTelemetry. В живой работе эти слои комбинируются, а не конкурируют лоб в лоб.

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

• Практика надёжности: SLI, SLO, error budget, profiling и явные критерии деградации.
• Инфраструктурный мониторинг: Prometheus, Zabbix, Datadog, New Relic, Grafana.
• Логирование: Elastic Stack, Graylog, Splunk, Papertrail, Loki.
• Трассировка и application monitoring: Jaeger, OpenTelemetry и смежные инструменты APM.
• Результат этапа: вы понимаете, какой класс сигналов отвечает за какой тип проблем.

Шаг 7.6. Инциденты, on-call и postmortem

Полный DevOps-маршрут не заканчивается на мониторинге. Когда система падает ночью или деградирует под нагрузкой, включается incident response: кто дежурит, где лежит runbook, кто принимает решение об откате, как фиксируется таймлайн и как команда разбирает причину после восстановления. Без этого даже хороший мониторинг остаётся просто шумом в Slack.

На старте не нужно строить идеальную SRE-организацию, но полезно привыкнуть к базовой дисциплине: алерт должен вести к понятному действию, у сервиса должен быть владелец, а после серьёзного сбоя команда делает короткий postmortem с выводами и задачами. Это и есть момент, где DevOps начинает становиться зрелой эксплуатацией, а не только автоматизацией деплоя.

• On-call и escalation: кто реагирует первым, кого будить дальше и где лежат контакты.
• Runbook: короткий рабочий документ с проверками, откатом, командами и здравыми fallback-действиями.
• Postmortem: что произошло, как обнаружили, как стабилизировали, что меняем в системе, чтобы не повторилось.
• Результат этапа: аварии превращаются из хаоса в управляемый процесс восстановления.

Эту идею жёстко сформулировала Charity Majors в статье для Honeycomb, опубликованной 15 января 2026 года. Её мысль хорошо ложится на практическую часть DevOps: если у команды нет короткой обратной связи между кодом и production, то инструменты сами по себе мало что дают.

a single feedback loop connecting devs with prod.

Charity MajorsCTO, Honeycomb

Шаг 8. Секреты, безопасность и supply chain

Безопасность не стоит оставлять «на потом», но и пытаться учить весь DevSecOps на старте тоже не нужно. Гораздо полезнее встроить базовые практики в уже знакомую цепочку: секреты не хранятся в репозитории, доступы выдаются по ролям, образы и зависимости сканируются, а pipeline умеет остановить поставку, если в артефакте есть критическая проблема.

Сюда же относится supply chain security: кто собрал образ, откуда приехала зависимость, чем подписан артефакт, где лежит SBOM, можно ли воспроизвести релиз. Для начинающего инженера это не означает десяток экзотических продуктов. Это означает нормальную дисциплину в CI/CD, registry и правах доступа.

Кроме секретов и supply chain, здесь обязательно появляются RBAC, least privilege, ротация доступов, image signing и правила policy enforcement. На практике это означает, что не каждый сервис и не каждый человек получает админские права, а pipeline и платформа умеют останавливать небезопасные деплои ещё до production.

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

Если нужен простой первый выбор, начинайте с нативного secret manager вашего облака или другого управляемого хранилища секретов. Поднимать Vault в учебном проекте полезно позже, когда вы уже понимаете ротацию, доступы и интеграцию с CI/CD. Для старта важнее усвоить сам принцип: секреты живут отдельно от кода и попадают в систему по контролируемому каналу.

• Секреты: KMS, Vault, cloud secret manager, Sealed Secrets — выбрать один понятный путь.
• Доступы и политика: RBAC, least privilege, ротация ключей, policy enforcement и admission checks.
• Доступы: роли вместо общих аккаунтов, least privilege, аудит действий.
• Артефакты: image scanning, dependency scanning, SBOM, подпись релизов там, где это нужно.
• Результат этапа: доставка становится не только автоматической, но и контролируемой с точки зрения риска.
• Supply chain на практике: image signing, provenance, сканирование зависимостей и контроль того, что именно уходит в production.

Шаг 9. GitOps, платформенный подход и зрелые практики

Когда контейнеры, инфраструктура, кластеры и наблюдаемость уже работают устойчиво, можно переходить к следующему уровню зрелости. Здесь появляются GitOps, декларативный деплой через ArgoCD, политики в коде, типовые шаблоны для сервисов и внутренняя платформа, которая упрощает жизнь всей команде, а не только одному DevOps-инженеру. В этой же ветке полезно знать, что кроме ArgoCD существует FluxCD, а рядом с платформенным слоем часто появляются service mesh-инструменты вроде Istio, Linkerd, Consul и Envoy.

Важно понимать, что эти практики не лечат хаос сами по себе. Если у вас ещё не собраны базовые процессы, GitOps превращается в ещё один слой сложности. Но когда фундамент готов, именно здесь начинается настоящее ускорение: Git становится источником истины для доставки, а платформа — продуктом для внутренних команд.

До первой junior-позиции обычно достаточно уверенно закрыть слои от Linux и Git до Docker, CI/CD, базовой инфраструктуры, деплоя и наблюдаемости. GitOps, платформенный подход, service mesh и глубокая стандартизация платформы чаще становятся следующей ступенью уже после реальной работы с несколькими сервисами и командами.

• GitOps нужен после устойчивого Kubernetes-процесса, а не вместо него.
• Политики в коде и типовые шаблоны полезны, когда в организации уже несколько сервисов и повторяющиеся правила.
• Платформенный подход — это следующий шаг после ручной поддержки одинаковых запросов от команд.
• Результат этапа: вы оптимизируете не только один деплой, а всю систему разработки и эксплуатации.

Шаг 9.5. Доступность, данные и FinOps-практики

В официальной карте рядом с GitOps и платформенными практиками идут cloud design patterns: availability, data management, design and implementation, management and monitoring. Это означает, что зрелый DevOps не заканчивается деплоем. Нужно думать о резервировании, отказоустойчивости, резервном копировании, восстановлении, хранении состояния, управлении квотами и стоимости платформы.

На практике сюда входят реплики и зоны доступности, стратегия backup и disaster recovery, различие между stateless и stateful-нагрузкой, контроль за ростом storage, бюджетами и неиспользуемыми ресурсами. Именно здесь DevOps начинает пересекаться с SRE, архитектурой и FinOps. Для первой работы не нужно становиться экспертом во всём сразу, но игнорировать эти темы уже нельзя. В зрелой команде FinOps — это не отдельная бухгалтерия, а часть инженерной обратной связи: сколько стоит сервис, где ресурсы простаивают и какой архитектурный выбор реально окупается.

• Availability: health-check, реплики, зоны, failover, rollback, disaster recovery.
• Data management: stateful workload, backup, restore, retention, object storage и managed database.
• Cost management: бюджеты, квоты, тэги, cleanup idle-ресурсов, размер инстансов и storage lifecycle.
• Результат этапа: вы думаете не только о запуске сервиса, но и о его цене, устойчивости и данных.

Шаг 9.6. Карьерные треки: DevOps, SRE, platform engineer, cloud engineer

Когда база уже собрана, полезно понимать, куда дальше растёт роль. DevOps-инженер чаще сильнее сидит на доставке, инфраструктуре и автоматизации; SRE делает больший акцент на надёжности, SLI/SLO и инцидентах; cloud engineer глубже уходит в облачную платформу и сервисы провайдера; platform engineer строит внутренние инструменты, шаблоны и единый путь для команд разработки.

На старте эти роли пересекаются почти полностью, поэтому учить их отдельно рано. Но как карьерная рамка это важно: вы начинаете понимать, почему один инженер копает в Kubernetes и Terraform, другой — в error budget и postmortem, а третий — во внутренний self-service для разработчиков.

• DevOps engineer: автоматизация доставки, инфраструктуры, CI/CD и операционных процессов.
• SRE: надёжность, доступность, SLI/SLO, on-call, incident response и postmortem.
• Cloud engineer: сервисы провайдера, IAM, сеть, storage, управляемые платформы и архитектурные паттерны.
• Platform engineer: внутренняя платформа, шаблоны, self-service и developer experience.

Шаг 9.7. Где в этой карте MLOps

MLOps логично стоит рядом с платформенным и облачным треком, а не вместо базового DevOps-маршрута. Сначала вам всё равно нужны Linux, Git, контейнеры, CI/CD, инфраструктура как код, наблюдаемость и безопасность. Только поверх этого появляется специфический слой машинного обучения: данные, обучение моделей, реестр моделей, feature store, воспроизводимые пайплайны и выкладка инференса.

Если говорить совсем просто, MLOps — это DevOps для систем, где кроме кода живут ещё модели и данные. Поэтому в этом треке к обычному деплою добавляются новые вопросы: как версионировать датасеты, как переобучать модель без хаоса, как проверять качество до и после релиза, как ловить drift и как откатывать не только код, но и модель.

• База та же самая: Docker, CI/CD, облака, Kubernetes, observability, secrets и права доступа.
• Специфика MLOps: versioning данных и моделей, training pipeline, model registry, feature store, offline и online evaluation.
• Инференс в production добавляет свои задачи: latency, стоимость GPU или CPU, batch и realtime-режимы, drift monitoring, rollback модели.
• Для старта это не обязательный слой каждому DevOps-инженеру, но если вы идёте в ML-команды, его стоит рассматривать как отдельную специализацию поверх крепкого DevOps-фундамента.

Что можно оставить на потом

Одна из главных ловушек DevOps — ощущение, что нужно знать вообще всё. Это не так. Есть темы, которые стоит трогать позже, когда уже есть реальная потребность: service mesh, то есть дополнительный сетевой слой между сервисами, multi-cloud, сложные self-hosted-кластеры, bare metal, внутренние PaaS, serverless на нескольких провайдерах и тонкая оптимизация FinOps.

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

• Service mesh нужен не каждому проекту и редко бывает стартовой темой.
• Multi-cloud — история про зрелую организацию, а не про первый учебный проект.
• Serverless полезно знать, но не как замену фундаменту из сетей, CI/CD и наблюдаемости.
• FinOps и оптимизация затрат раскрываются сильнее, когда у вас уже есть реальные счета и метрики нагрузки.

Практический план обучения на 6–9 месяцев

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

Какие учебные проекты реально помогают войти в DevOps

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

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

1. Поднять веб-приложение с базой данных через Docker Compose и опубликовать образ в registry.
2. Сделать CI-пайплайн, который тестирует проект, собирает образ и выкладывает его в staging.
3. Описать тестовую инфраструктуру через Terraform и накатить конфиг через Ansible.
4. Развернуть сервис в Kubernetes, вынести параметры в Helm и выполнить обновление с откатом.
5. Подключить Grafana и Prometheus, собрать дашборд по ошибкам и задержкам, добавить алерт на деградацию.
6. Убрать секреты из репозитория и перевести их в managed secret store или Kubernetes secrets с контролируемым доступом.

Как стать DevOps-инженером и что нужно уметь junior

Чтобы претендовать на первую DevOps-роль, не нужно знать весь рынок инструментов. Но нужно показать связный практический путь: вы умеете работать с Linux и Git, упаковывать сервис в Docker, собирать pipeline, поднимать тестовую инфраструктуру, читать метрики и не теряться при сбое. Работодатель обычно ищет не энциклопедические знания, а способность провести сервис от коммита до рабочего окружения.

Хороший junior-ready уровень выглядит так: у вас есть один или два проекта, которые можно открыть и показать. В них видно инфраструктуру, Dockerfile, pipeline, деплой, базовый мониторинг и понятные README с тем, как это запускается и как откатывается. Это намного сильнее, чем длинный список прочитанных курсов.

• Вы умеете поднять сервис локально, упаковать его в контейнер и опубликовать образ в registry.
• Вы можете настроить CI, который тестирует, собирает и публикует артефакт без ручной сборки.
• Вы понимаете базовые облачные сущности: сеть, VM, DNS, IAM, secret store, балансировщик.
• Вы можете развернуть сервис на сервере или в Kubernetes и объяснить, как его мониторить и откатывать.
• У вас есть портфолио из реального pet-проекта, а не только конспектов и скриншотов из лабораторных.

Дальше траектория обычно расходится на несколько направлений: DevOps-инженер с уклоном в доставку и инфраструктуру, SRE с акцентом на надёжность и инциденты, cloud engineer с фокусом на облачную платформу и platform engineer, который строит внутренние инструменты и шаблоны для разработчиков. На старте эти роли сильно пересекаются, поэтому базовый маршрут у них общий.

Как понять, что этап закрыт и можно идти дальше

Переход между этапами лучше проверять не ощущением «кажется, я уже почитал достаточно», а конкретными результатами. Если у вас нет практического артефакта на выходе, тема обычно ещё не закрыта. Для DevOps это особенно важно: знания быстро расслаиваются, если за ними не стоит работающий сервис, pipeline или окружение.

1. Linux и сети закрыты, когда вы можете зайти на машину по SSH, найти проблему в логах, проверить порты, DNS и сервисы без GUI-подсказок.
2. Git закрыт, когда вы спокойно работаете с ветками, pull request, конфликтами и понимаете, что именно уезжает в релиз.
3. Docker закрыт, когда ваш сервис стабильно собирается в образ, стартует вместе с зависимостями и одинаково работает локально и в CI.
4. CI/CD закрыт, когда после коммита автоматически проходят тесты, собирается артефакт, появляется версия и у вас есть понятный rollback.
5. Terraform и облако закрыты, когда вы поднимаете тестовое окружение из кода и можете заново воспроизвести его без ручного кликанья.
6. Kubernetes и Helm закрыты, когда вы выкатываете приложение в кластер, меняете конфигурацию по окружениям и обновляете релиз без редактирования YAML вручную на проде.

Как не запутаться в инструментах и не выгореть

DevOps широкий, а не линейный. Поэтому полезно думать не категориями «мне срочно нужен ещё один инструмент», а категориями «какую конкретную проблему я сейчас решаю». Если вы не умеете повторяемо запускать приложение, вам рано в service mesh и другие продвинутые сетевые надстройки. Если вы не понимаете IAM, не стоит спорить о multi-cloud-архитектуре. Если после релиза вы не видите метрик, не нужно начинать с GitOps.

Нормальный темп обучения — один слой за раз, с обязательной практикой и возвращением к предыдущим этапам. В реальной работе вы всё равно будете постоянно ходить назад: править Dockerfile после проблем в CI, улучшать Terraform после ошибок в доступах, менять алерты после неудачного инцидента. Это не откат, а нормальная сборка компетенции.

• Выберите один главный учебный сервис и не распыляйтесь на пять разных pet-проектов.
• Один инструмент на категорию лучше, чем поверхностное знакомство с тремя конкурирующими решениями.
• После каждого этапа задавайте себе вопрос: что я теперь умею делать руками, чего не умел неделю назад?
• Если новая тема не решает текущую боль, отложите её до момента, когда под неё появится практический контекст.

Выводы

План обучения DevOps работает только тогда, когда вы строите его слоями. Сначала система и сеть, потом контроль версий и контейнеры, затем CI/CD, инфраструктура и облака, после этого оркестрация, наблюдаемость, безопасность и только потом зрелые платформенные практики. Такой порядок помогает не просто выучить названия инструментов, а понять, какую проблему решает каждый из них.

Если хотите идти по этому маршруту через уже готовые материалы Tproger, используйте связку так: Git и GitHub → Docker → CI/CD → Kubernetes → Helm → GitOps → ArgoCD. Для инфраструктуры и наблюдаемости возвращайтесь к материалам про Terraform и Ansible и Grafana.

Когда дойдёте до конкретного инструмента, сверяйтесь уже с его официальной документацией: Docker, Kubernetes, Terraform, Argo CD. Так вы получите и общую картину, и правильные практические детали.