Что дальше: твой путь в DevOps
Вы посмотрели, что такое DevOps, потрогали Docker, разобрались с пайплайнами и поняли логику автоматизации. Теперь главный вопрос: что учить и в каком порядке.
Порядок критичен. Каждый следующий шаг опирается на предыдущий: без Linux не понять Docker, без Docker не понять Kubernetes. Соблазн прыгнуть сразу в модный Kubernetes велик, но без фундамента вы там просто утонете.
И сразу про языки программирования. В каждом втором роадмапе они стоят первым пунктом. Наши ребята прошли больше двухсот реальных собеседований за последние месяцы. Знаете, сколько раз их спросили что-то про языки программирования? Раз пять. Задач на кодинг у DevOps мало, а если такая задача прилетает – открываете нейронку, пишете промпт, получаете скрипт и допиливаете. Глубокие знания языков для старта не нужны.
1. Git
Не самая популярная мысль, но стартовать лучше с Git, а не с Linux. Git учится быстро, и вы сразу входите в рабочий ритм. Все конфиги, пайплайны, манифесты, YAML-файлы – это код. Этот код должен где-то храниться и версионироваться. При этом неважно, GitHub, GitLab или BitBucket – все они строятся на одном и том же Git.
Пять базовых команд: git init, git add, git commit, git push, git pull. Плюс понимать, что такое ветки, теги и как между ними переключаться.
Как учить: заведите репозиторий и начните пушить туда конспекты в формате .md. Заодно научитесь оформлять маркдаун – в этом формате пишутся все README, вся документация к проектам. Когда дальше будете учить Linux, будете каждый день писать конспект, коммитить и пушить. К моменту, когда закончите с Linux, ваши пальцы уже будут набирать гитовые команды на автомате.
Что еще стоит изучить позже: git checkout, git merge, git rebase, git fetch, git revert, git diff. Стратегии ветвления: GitFlow, GitHub Flow, Trunk-Based Development.
На собеседованиях Git спрашивают редко – буквально раз на двести вопросов. Если спрашивают, то почти всегда: «Как перенести коммиты из одной ветки в другую?», «Что такое merge conflict и каковы причины?», «Как работает git pull под капотом?».
Готово, когда: спокойно работаете с ветками и не боитесь конфликтов слияния.
2. Linux
Самый большой блок. Сервера, виртуалки, Kubernetes – везде Linux. Многие компании выдают рабочие ноутбуки на Linux. Вся работа DevOps так или иначе с ним связана.
Самое важное действие – поставить Linux себе на компьютер. В идеале второй системой, если нет – хотя бы на виртуалку. И начать на нем жить: выполнять обычные задачи, ковыряться в настройках. Скорее всего, отвалится звук, слетят драйвера, разрешение экрана будет кривое. Пока будете гуглить, как все это починить, перелопатите кучу форумов, скопируете сотни команд в терминал – и сами того не заметите, как перестанете бояться черного экрана.
Базовые команды: cd, ls, mkdir, rm, touch, chmod, cp, mv, nano/vim. Навигация, создание и удаление файлов, редактирование в терминале.
Процессы – пожалуй, топ-1 тема по Linux на собеседованиях. ps aux – снимок всех процессов, PID – уникальный номер процесса, kill – завершить процесс. Нужно понимать состояния процессов (Running, Sleeping, Zombie, Stopped), знать что такое зомби-процесс и процесс-сирота. Отдельно – systemd: что это, как написать свой unit-файл, чем отличается от старой InitV. И OOM Killer – механизм, который убивает процессы при нехватке памяти (эта тема пересекается с Kubernetes).
Мониторинг ресурсов. Команда top (или htop) – таблица процессов в реальном времени. Тут нужно понимать, что означают параметры: Load Average (средняя нагрузка – самый популярный вопрос на собесах по Linux), wa (I/O Wait – процессор ждет диск), us/sy (пользовательские/системные процессы). Уметь найти процесс, который съел всю память (сортировка по колонке RES).
Диски. df -h – общая картина по дискам, du -sh * – что именно занимает место. Связка df + du – база для траблшутинга «кончилось место». Понимать, что такое inodes (когда df показывает, что место есть, а система говорит, что диск переполнен – закончились inodes). Типы файловых систем: ext4, xfs, tmpfs. Команда mount и файл /etc/fstab. Обзорно: RAID-массивы (RAID 1, RAID 10), LVM.
Работа с текстом: grep, sed, awk, cut, sort, uniq, wc. Пайпы (|) и перенаправление (>, >>, 2>&1). Без этого невозможно нормально читать логи и писать скрипты.
Bash-скриптинг: условия, циклы, функции, exit-коды. Не нужно становиться экспертом, но рабочий скрипт написать нужно уметь.
SSH: ключи (ssh-keygen, ssh-copy-id), конфиг ~/.ssh/config, отключение входа по паролю и root-логина.
Первичная настройка сервера: создать пользователя, настроить sudo, SSH по ключам, поставить файрвол (ufw или iptables).
Практика. Попросите нейронку сгенерировать код простого приложения: фронтенд + бэкенд + база данных. Условие: никакого Docker, голое приложение. Ваша задача – запустить это все на своем Linux руками. Тут вы хлебнете, но это полезно: разберетесь с зависимостями, пакетными менеджерами, конфигами. А когда дойдете до Docker – поймете, какую проблему он решает.
Готово, когда: можете с нуля настроить сервер, написать bash-скрипт и объяснить, что такое Load Average.
3. Сети
Сети – неотъемлемая часть работы DevOps. Тут два направления: практическое (что нужно в работе) и теоретическое (что спрашивают на собесах).
Практика. Утилиты диагностики: ping, traceroute/mtr, ss/netstat (какие порты открыты и кем заняты), dig (DNS), curl, tcpdump. Если вы делали практику из предыдущего блока – вы уже столкнулись с сетями: бэкенд не видит базу (порт закрыт), сайт не открывается (файрвол блочит).
Nginx – must have. Нужно уметь настроить его как reverse proxy (запрос приходит на Nginx, он перекидывает на приложение), понимать базовую структуру конфигов. И знать, что при изменении конфига нужен reload, а не restart – restart убивает соединения клиентов, reload перечитывает конфиг на лету.
Теория (для собеседований). Модель OSI – чуть ли не самый популярный вопрос по сетям. Особое внимание уровням 3 (IP-адреса, разница между белым и серым IP), 4 (TCP vs UDP, порты) и 7 (HTTP/HTTPS, DNS). Что происходит, когда вводите адрес в браузере и нажимаете Enter – классический вопрос, который затрагивает DNS, TCP, TLS и HTTP. TLS/SSL и сертификаты – сейчас сертификаты везде: Kubernetes, Kafka, Nginx.
Готово, когда: понимаете, что происходит от ввода адреса в браузере до ответа, и можете продиагностировать, почему сервис недоступен.
4. Docker
После мучений с Linux, ручной установкой зависимостей и настройкой Nginx – Docker покажется глотком свежего воздуха. Если честно, Docker – одна из самых простых тем на пути обучения DevOps.
Что нужно знать: docker build, docker run, docker ps, docker logs, docker exec, docker stop, docker push, docker pull. Написать Dockerfile – знать директивы FROM, RUN, COPY, WORKDIR, ENV, CMD, ENTRYPOINT, USER. Понимать слои и кеширование (почему порядок инструкций в Dockerfile влияет на скорость сборки).
В реальной работе DevOps не всегда пишет Dockerfile с нуля – часто это делают разработчики. Задача DevOps – проверить, что Dockerfile соответствует best practices, и оптимизировать: облегчить образ (Alpine вместо Ubuntu), убрать запуск от root, вычистить кеш, ускорить сборку. Multi-stage build – продвинутая техника для уменьшения размера образа.
Registry – хранилище образов. Собрали образ, запушили в registry, на проде скачали и запустили. В компаниях обычно свой registry: Nexus, GitLab Registry, Artifactory. Для практики хватит Docker Hub.
Docker Compose – инструмент для запуска нескольких контейнеров одной командой. В реальности приложение – это не один контейнер, а минимум приложение + база + кеш + nginx.
Сеть в Docker: типы сетей (bridge, host, none), как контейнеры общаются между собой.
Практика. Возьмите приложение из практики по Linux и оберните в контейнеры. Поднимите через Docker Compose и проверьте, что все работает. Отдельно: поднимите стек Prometheus + Grafana + Node Exporter через Compose – одновременно практикуетесь с Docker и знакомитесь с мониторингом.
На собеседованиях Docker спрашивают нечасто, обычно в контексте Kubernetes. Если спрашивают: «Чем контейнеризация отличается от виртуализации?», «За счет каких технологий ядра обеспечивается изоляция?», «Зачем multi-stage build?», «Разница CMD/ENTRYPOINT».
Готово, когда: можете упаковать любое приложение в контейнер и поднять связку из нескольких сервисов через Compose.
5. CI/CD
Картина складывается: мы умеем настраивать сервер, упаковывать приложение в контейнер. Но делать все руками – собирать, пушить, заходить на сервер, пулить – долго и ненадежно. CI/CD автоматизирует этот процесс.
CI (Continuous Integration) – код превращается в готовый артефакт. CD (Continuous Delivery) – артефакт выкатывается на сервер. Два главных инструмента: GitLab CI и Jenkins. Jenkins чаще встречается в старых проектах и банках, его пайплайны пишутся на Groovy. GitLab CI – стандарт индустрии, встроен в репозиторий, пайплайны описываются в YAML. Начинайте с GitLab CI.
Что нужно знать: pipeline, stage, job. Как написать .gitlab-ci.yml. Переменные и секреты. only/rules (когда job запускается). artifacts (передача файлов между job’ами). cache (кеширование зависимостей). when: manual (ручное подтверждение деплоя). GitLab Runner – сервер-агент, который выполняет команды из пайплайна.
Практика. Напишите пайплайн для вашего приложения: Build (собрать Docker-образ), Test (линтер – flake8 для Python, eslint для JS), Deploy (SSH на сервер, обновить контейнер). Потом усложните: три окружения (dev – автоматически по пушу, staging – по мержу в main, prod – manual).
На собеседованиях топ-1 вопрос: «Как бы ты построил идеальный пайплайн?». Это вопрос на понимание, не на синтаксис. Топ-2: «В чем разница Continuous Integration, Continuous Delivery, Continuous Deployment?».
Готово, когда: написали рабочий пайплайн, который сам собирает, проверяет и выкатывает приложение.
6. Ansible
Код летит на сервер через CI/CD, но сервер должен быть настроен. Кто туда поставил Docker, создал пользователя, обновил ядро? Если сервер один – зашли руками. Если серверов десятки – нужен Ansible.
Ansible – agentless: не нужно ничего ставить на целевые серверы, только SSH и Python (который на Linux есть по умолчанию). Работает декларативно и идемпотентно – запустили плейбук один раз, настроили сервер. Запустили второй раз – ничего не изменилось, потому что все уже в нужном состоянии.
Что нужно знать: inventory (список серверов), playbook (список задач в YAML), модули (apt, copy, template, service, user – готовые функции на каждое действие), handlers (действия по событию, например перезапуск после изменения конфига), переменные и шаблоны (Jinja2), роли (структурированный способ организации больших плейбуков).
Практика. Возьмите чистую виртуалку и не ставьте туда софт руками – напишите плейбук, который обновит систему, поставит Docker, создаст пользователя. Потом оформите это как роль.
На собеседованиях спрашивают нечасто: «Что такое плейбук?», «Что такое роль?», «Что такое handler?», «Что такое идемпотентность?», «Приоритеты переменных».
Готово, когда: можете одним плейбуком настроить чистый сервер до рабочего состояния.
7. Kubernetes
Самый важный и самый объемный блок. Kubernetes сейчас везде – большие компании давно на нем, маленькие переезжают. На собеседованиях это самая большая тема. Спросить могут что угодно, по любому аспекту, углубиться настолько, насколько хватит фантазии.
Архитектура. Control Plane: API Server, etcd, Scheduler, Controller Manager. Worker Node: kubelet, kube-proxy, container runtime. Понимать, как компоненты взаимодействуют и как через API Server проходят все запросы.
Основные сущности. Pod (минимальная единица), Deployment (управление подами, rolling update), StatefulSet (для баз данных и stateful-приложений – знать отличие от Deployment), DaemonSet (под на каждой ноде), Job/CronJob (разовые и периодические задачи). ConfigMap и Secret – конфигурация и секреты. Requests и Limits – лимиты ресурсов. Liveness и Readiness probes – проверки здоровья.
Сеть – самая сложная тема внутри Kubernetes. Типы сервисов (ClusterIP, NodePort, LoadBalancer), Ingress (маршрутизация HTTP-трафика). На понимание сети в кубере может уйти значительное время.
Хранилище. PersistentVolume, PersistentVolumeClaim, StorageClass – кто за что отвечает.
Helm – пакетный менеджер Kubernetes, как apt для Linux. Стандарт индустрии, знание Helm такое же обязательное, как знание того, что такое под. Charts, values, templates.
Практика. Поставьте кластер локально (Minikube или kind). Напишите манифесты руками: Deployment + Service + ConfigMap. Обновите версию образа, посмотрите rolling update, сделайте откат. Поиграйте с probes: сломайте readiness – под выпадет из Service, сломайте liveness – под перезапустится. Потом оберните манифесты в Helm chart и задеплойте через Helm.
Продвинутые темы (после освоения базы): RBAC, HPA (автомасштабирование), NetworkPolicy, Service Mesh (Istio), операторы, способы развертывания кластера (kubeadm, kubespray, managed Kubernetes).
Готово, когда: можете развернуть приложение в кластере, настроить сервис и обновить версию без простоя.
8. Мониторинг и логирование
На любом проекте есть (или должен быть) мониторинг и централизованное логирование.
Prometheus + Grafana – стандартная связка для метрик. Prometheus собирает метрики, Grafana визуализирует. Нужно понимать pull-модель (Prometheus сам ходит за метриками), разобраться с основами PromQL (язык запросов), поработать с экспортерами (node-exporter для серверов, postgres-exporter для баз). Grafana – дашборды, панели, алертинг.
Логирование. ELK-стек (Elasticsearch + Logstash + Kibana) или его форк OpenSearch – самый популярный стек для логов. Loki + Grafana – легковесная альтернатива, активно развивается. Самое главное тут – научиться логи читать и понимать, куда копать, основываясь на информации из них. Инструменты сбора: Fluentd, Filebeat, Fluent Bit.
9. Остальное
Поверх фундамента – то, что встречается на реальных проектах. Приоритет ниже, чем у предыдущих блоков, но знать нужно.
Базы данных. DevOps не пишет SQL-запросы, но поднимает базу, настраивает бэкапы, репликацию, мониторит производительность. PostgreSQL – основная база, которую нужно знать: установка, pg_hba.conf, postgresql.conf, бэкап и восстановление, репликация, базовый SQL. Обзорно: Redis (кеш), MongoDB, ClickHouse.
Terraform. Инструмент для создания инфраструктуры в облаке. Понимать концепции: провайдер, ресурс, стейт (.tfstate), модуль, план, apply. Стейт хранить в S3.
Облака. Большинство проектов живут в облаке. В России: Yandex Cloud, Timeweb, Selectel, Cloud.ru. Нужно понимать IaaS/PaaS/SaaS, уметь создать виртуалку, разобраться с VPC, подсетями, security groups, S3, managed-сервисами.
Очереди сообщений (обзорно). Kafka – распределенная платформа потоковой обработки. RabbitMQ – классический брокер сообщений. Нужно понимать концепции: брокер, топик, продюсер, консьюмер.
Vault – хранилище секретов. На зрелых проектах все пароли, ключи и токены лежат в нем.
GitOps (ArgoCD) – подход, при котором Git является источником правды для инфраструктуры. ArgoCD подтягивает конфигурацию из Git и деплоит в Kubernetes.
Как учить
Теория плюс практика сразу. Прочитали про Docker – тут же запустили контейнер. Знание без рук не закрепляется. Каждую тему трогайте руками в тот же день.
По порядку. Карта построена так, что каждый блок опирается на предыдущие. Прыгнете через ступеньку – застрянете.
Нейронки для практики. Просите нейронку генерировать задачки, выполняйте и скидывайте на проверку ей же. Они отлично принимают скриншоты и пишут требования.
Готовьтесь к собесам параллельно. По каждой теме есть типовые вопросы. Разбирайте их сразу при изучении блока, а не в панике перед поиском работы.
Сколько это займет
От полугода до полутора лет до первой работы, в зависимости от вложенного времени и стартового уровня. При плотных занятиях реально выйти на junior-позицию за 8-12 месяцев. Это марафон, не спринт.
Мост
Этот путь можно пройти самостоятельно. Материалов в интернете хватает. Но есть места, где самоучки буксуют месяцами: непонятно, что важно, а что второстепенно. Застрял на ошибке – не у кого спросить, теряешь дни. Нет реальных проектов – нечего показать на собесе. Нет понимания, как проходить собеседования.
Если хотите пройти этот путь не в одиночку – с менторами, практикой на реальных проектах и сопровождением до оффера – у нас есть программа, которая проводит от нуля до трудоустройства. Ссылка в описании.