Из сисадмина в DevOps: что у вас уже есть, чего не хватает и план на 3–6 месяцев
Команда KAI Lab · · 9 мин чтения
Из сисадмина в DevOps переходят без смены профессии: Linux, сети, бэкапы и ночные инциденты у вас уже есть, а не хватает обычно шести вещей — Git, CI/CD, контейнеров, инфраструктуры как кода, Kubernetes и привычки проводить каждое изменение через код-ревью. При 8–10 часах практики в неделю эту базу реально закрыть за 3–6 месяцев, если учиться на задачах своей текущей работы, а не только на видео.
Ниже — что из опыта админа засчитывается, чего не хватает, помесячный план с домашним стендом и как переписать резюме. Общая карта переходов для сисадминов, сетевиков и helpdesk — в статье куда расти сисадмину и helpdesk. Здесь один переход разобран подробно.
Кто так переходит
Путь «сисадмин → DevOps» — не экзотика. Мы разобрали резюме 33 студентов KAI (сентябрь 2026): 30 из них уже работали в IT, 17 — сисадмины, сетевики и специалисты helpdesk, медианный стаж — 5 лет. При этом 20 из 33 до учёбы с DevOps не работали.
Типичный человек на этом пути — инженер с опытом, которому не хватает конкретных инструментов, а не «основ IT». Это важно для плана: учить заново Linux и сети не нужно, нужно переложить то, что вы уже умеете, на новый способ работы.
Что у вас уже есть
| Опыт сисадмина | Где он нужен в DevOps |
|---|---|
| Linux: systemd, журналы, права, диски | Контейнер — это процесс Linux. Упавший сервис или под читается теми же логами и кодами выхода |
| Сети: DNS, маршруты, firewall, сертификаты | Service, Ingress и сетевые политики в Kubernetes, TLS на балансировщике, «не резолвится» внутри пода |
| Бэкапы и восстановление | Данные сервисов в кластере, проверка восстановления, допустимые потери и время простоя |
| Мониторинг: Zabbix, Nagios | Prometheus и Grafana, алерты на симптомы, а не на каждую метрику |
| Инциденты и звонки в три ночи | Дежурства, эскалации, постмортемы |
| Скрипты Bash или PowerShell | Шаги пайплайна, автоматизация рутины |
Главное, что вы приносите, — понимание прода. Вы знаете, чем заканчивается переполненный диск и что проверять первым, когда «всё упало». Этому трудно научить на курсе, а в DevOps об этом спрашивают на каждом собеседовании.
Чего не хватает: шесть пробелов
Git и merge request
Не «знать команды», а работать так, чтобы любое изменение инфраструктуры было коммитом с понятным сообщением. Минимум: ветки, merge request, разрешение конфликтов, откат через git revert. Проверка: ваши скрипты и конфиги лежат в репозитории, и вы можете показать, кто и зачем поменял строку полгода назад.
CI/CD
Пайплайн, который на каждый коммит проверяет код, собирает артефакт и выкатывает его. Начните с GitLab CI или GitHub Actions — принципы переносятся между ними. Проверка: образ собирается и публикуется без ваших рук, а сломанный коммит до прода не доходит.
Контейнеры
Dockerfile, слои, образы, тома, сети, docker compose для локального стенда. Отдельно — почему контейнер перезапускается и что значит код выхода 137. Проверка: внутренний сервис с работы запускается одной командой на чистой машине.
Инфраструктура как код
Ansible — для настройки серверов, Terraform — для создания ресурсов в облаке или в системе виртуализации. Ключевое слово — идемпотентность: повторный запуск ничего не ломает и ничего не меняет, если всё уже в нужном состоянии. Проверка: новый сервер доводится до рабочего состояния прогоном роли, а не по вики.
Kubernetes
Pod, Deployment, Service, Ingress, ConfigMap и Secret, requests и limits, пробы. Для админа Kubernetes — ещё один слой поверх Linux и сети, поэтому его учат последним. Проверка: вы выкатили свой сервис в кластер и сами разобрали CrashLoopBackOff и под, застрявший в Pending.
Код-ревью
Самая непривычная часть. Сисадмин часто чинит на месте: зашёл по SSH, поправил, работает. В DevOps изменение сначала описывают кодом, потом его смотрит второй человек, потом его выкатывает пайплайн.
Учиться нужно и отдавать свои изменения на ревью, и ревьюить чужие. На что смотреть в чужом merge request: нет ли секретов в коде, что будет при повторном запуске, как откатить изменение и сколько серверов заденет ошибка.
План на 3–6 месяцев
Ориентир — 8–10 часов в неделю. Если на работе уже есть DevOps-задачи или вы готовы уделять больше времени, первые строки сжимаются, и за три месяца вы доходите до Ansible и основ Kubernetes. Если времени меньше — растягивайте, но не меняйте порядок.
| Месяц | Фокус | Практика | Что остаётся на руках |
|---|---|---|---|
| 1 | Git, Bash | Перенести свои скрипты и конфиги в репозиторий, менять их только через ветку и merge request | Репозиторий infra с историей |
| 2 | Docker | Упаковать в образ внутренний сервис или утилиту, поднять стенд через compose | Dockerfile и compose.yaml |
| 3 | CI/CD | Пайплайн: shellcheck и yamllint, сборка образа, публикация в registry | .gitlab-ci.yml или workflow GitHub Actions |
| 4 | Ansible | Роль базовой настройки сервера: пользователи, SSH, пакеты, агент мониторинга | Роль с README и прогоном в --check |
| 5 | Kubernetes | k3s или kind, выкатить свой сервис, сломать и починить | Манифесты или Helm-чарт, заметки о поломках |
| 6 | Terraform, мониторинг, инциденты | Ресурсы через Terraform, алерты, учебная авария и постмортем | Модуль Terraform, дашборд, постмортем |
Самые ценные строки плана — те, что сделаны на работе. Перенести конфиги nginx в Git, написать роль для типовой настройки серверов, поставить CI для внутреннего инструмента — это уже опыт, который можно честно вписать в резюме. Почти в любой компании такие задачи есть, до них просто не доходят руки. Предложите руководителю одну конкретную задачу с понятной пользой, а не «хочу поучиться DevOps».
Рабочий цикл с первого месяца выглядит так, даже если вы в репозитории один:
git switch -c fix/nginx-logrotate
git add roles/nginx/templates/logrotate.j2
git commit -m "nginx: ротация логов раз в сутки, хранить 14 дней"
git push -u origin fix/nginx-logrotate
# дальше — merge request, ревью и слияние в mainДомашний стенд
Для стенда хватает ноутбука или старого ПК: пара виртуальных машин, Docker и лёгкий Kubernetes. k3s по документации требует для сервера минимум 2 ядра и 2 ГБ памяти, kind поднимает кластер прямо в контейнерах Docker.
# Kubernetes на одной виртуальной машине
curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get nodes
# или кластер в Docker на ноутбуке
kind create cluster --name lab
kubectl get nodesСтенд полезен, только если на нём что-то ломается. Заполните диск, остановите DNS, дайте контейнеру лимит памяти меньше, чем ему нужно, просрочьте сертификат — и чините, записывая, что проверяли и в каком порядке. Эти записи потом превращаются в истории для собеседования.
Если хочется пройти тот же путь на готовых задачах, есть симулятор DevOps KAI Lab: год работы DevOps-инженером в выдуманной компании, 9 месяцев от Linux и Docker до Kubernetes, мониторинга и Terraform, тикеты от коллег, дежурства и постмортемы. Консоль в браузере воспроизводит реальные выводы команд, ставить ничего не нужно.
Как описать опыт в резюме
Работодатель ищет в резюме не слово DevOps, а следы работы с продом и автоматизации. Поэтому не прячьте админский опыт — переведите его на язык результатов.
| Было | Стало |
|---|---|
| Администрирование серверов Linux | Сопровождал N серверов Ubuntu; перевёл базовую настройку на Ansible-роль, новый сервер готов за час вместо дня |
| Настройка резервного копирования | Автоматизировал бэкапы PostgreSQL, добавил алерт на провал и ежемесячную проверку восстановления |
| Участие в устранении аварий | Дежурил в графике; после сбоев писал разборы, по ним внедрены конкретные изменения |
| Работа с Docker | Упаковал внутренний сервис в образ, сборка и публикация идут в GitLab CI |
Цифры в правой колонке — ваши, не выдумывайте их: на собеседовании по каждой строке зададут уточняющий вопрос.
Ещё три правила:
- Добавьте раздел «Проекты» со ссылкой на репозиторий: пайплайн, Dockerfile, роль или модуль, README с тем, что и зачем сделано.
- Пишите только те инструменты, с которыми работали руками. «Знаком с Kubernetes» после одного видео не переживёт вопроса про пробы.
- Смотрите на смешанные вакансии. 25 сентября 2026 года на hh.kz было три вакансии со «системным администратором» и DevOps в названии. Все просят 3–6 лет опыта, а в задачах там Linux-серверы, Docker и Nginx рядом с Kubernetes, GitLab CI и Ansible. Для админа со стажем это самый короткий мост.
Для сравнения: в тот же день на hh.kz было 35 вакансий DevOps по Казахстану, и 21 из них требовала опыт от трёх лет. Даже вакансия Junior DevOps Engineer в Алматы (опубликована 21.09.2026) просит от полутора лет коммерческого опыта DevOps и полгода с Kubernetes. Но в плюсах там назван опыт работы с большим парком физических серверов. Админский опыт засчитывают, если вы умеете о нём рассказать. Как это делать, разбираем в статьях про вопросы на собеседовании DevOps и тестовое задание.
Частые вопросы
Сколько времени занимает переход из сисадмина в DevOps? Базу — Git, Docker, CI/CD, Ansible и основы Kubernetes — при 8–10 часах практики в неделю реально собрать за 3–6 месяцев. Смена должности — отдельный срок: он зависит от рынка и от того, сколько DevOps-задач вы успели сделать на текущей работе.
Нужно ли сисадмину учить программирование? Нужны скрипты: Bash для обвязки и Python для всего, что сложнее десяти строк. Писать продукт не придётся, но читать код приложения, которое вы выкатываете, и понимать его логи — придётся.
Можно ли перейти в DevOps из Windows-админа? Можно, но Linux обязателен: контейнеры и Kubernetes в проде почти всегда работают на нём. PowerShell, Active Directory и Windows Server остаются плюсом в компаниях со смешанным парком серверов — такие требования встречаются и в DevOps-вакансиях.
Обязательно идти на позицию джуна? Нет. Со стажем админа разумнее смотреть на смешанные роли и на внутренний переход в команду эксплуатации или разработки. Чем эти роли отличаются по задачам и ответственности, разобрали в статье сисадмин или DevOps, а порядок изучения инструментов — в DevOps roadmap.
Какой сертификат помогает при переходе? RHCSA подтверждает Linux: экзамен EX200 практический, задачи решаются руками. CKA подтверждает Kubernetes: два часа практических задач в командной строке, 30% веса — поиск и устранение неисправностей. Но сертификат не заменяет репозиторий и истории с работы.
Источники
- hh.kz, поиск по названию вакансии, весь Казахстан, 25.09.2026: DevOps — 35 вакансий; по опыту: без опыта 3, 1–3 года 11, 3–6 лет 20, более 6 лет 1 (параметр
experience); системный администратор DevOps — 3 вакансии. - hh.kz. Junior DevOps Engineer, ТОО Emerging Travel Group, опубликована 21.09.2026.
- Данные о студентах — внутренний разбор KAI «Кто покупает — факт по 33 резюме и 12 кастдевам», 11.09.2026.
- K3s. Requirements и Quick-Start Guide.
- Kubernetes SIGs. kind.
- The Linux Foundation. Certified Kubernetes Administrator (CKA).
- Red Hat. Red Hat Certified System Administrator (RHCSA).