Переход из технической поддержки или системного администрирования в DevOps выглядит логичным, пока вы не открываете вакансию. Там уже не «разбирает тикеты и знает Linux», а пайплайн, инфраструктура как код, облако и ответственность за то, что релиз не развалит прод. Опыт эксплуатации есть. Не хватает доказательств, что вы умеете автоматизировать, а не только тушить.
Ниже — рабочий маршрут без смены индустрии с нуля: что из поддержки уже продаётся, какой разрыв закрыть за 90 дней и за полгода, какой пет-проект считать достаточным и как сформулировать пули, чтобы резюме читалось как junior/middle DevOps, а не как «саппорт, который выучил Docker».
Коротко:
- Инциденты, доступы, деплои руками и ночные смены — это уже эксплуатация. Их нужно переписать языком надёжности, а не вычёркивать.
- Разрыв почти всегда в автоматизации: скрипт, пайплайн, контейнер, IaC, алерт — не в «ещё одном курсе Kubernetes».
- Самый короткий путь — внутренний переход: одна зона ответственности рядом с текущей сменой, а не резкий уход «в DevOps вообще».
- Пет-проект нужен один, воспроизводимый, с README и тем, что ломается. Три репозитория без пайплайна слабее.
- На рынке смотрите junior/middle DevOps и SRE с задачами, не с модным стеком. Требования сверяйте по DevOps-вакансиям.
Что из поддержки уже считается опытом
Работодатель покупает вероятность, что вы не растеряетесь, когда сервис ляжет в пятницу вечером. У поддержки и сисадмина это часто сильнее, чем у джуна с курсом. Переносится не должность, а класс задач.
- Инциденты. Приняли сигнал, сузили зону, эскалировали, зафиксировали. Если вы умеете писать постмортем в пять строк — это уже наблюдаемость, даже если Grafana не ваша.
- Доступы и окружения. VPN, SSH, стенды, «у меня локально работает». Это гигиена, без которой CI и облако бесполезны.
- Релизы руками. Выкладка по чек-листу, откат, проверка после деплоя. DevOps как раз автоматизирует то, что вы уже делаете вручную.
- Давление и смены. Умение не обещать лишнего пользователю и не чинить прод наугад.
Не обесценивайте это в резюме фразой «просто отвечал в чате». Если вы год закрывали тикеты продукта — у вас уже есть карта слабых мест. Это ближе к эксплуатации, чем пет-проект «интернет-магазин». Смежная рамка входной роли: удалённая работа в поддержке.
Чего не хватает на junior DevOps-вакансиях
Откройте десять объявлений. Повторяется одно и то же, даже если названия инструментов разные:
- Linux не как «пользовался Ubuntu», а как процессы, права, systemd, сеть, диск.
- Скрипт, который кто-то другой может запустить без вас.
- CI/CD: сборка, тест, выкладка, артефакт, откат.
- Контейнер: образ, тома, сеть, почему контейнер не равен виртуалке.
- Инфраструктура как код хотя бы на одном провайдере или на локальном аналоге.
- Логи, метрики, один осмысленный алерт — не дашборд «для портфолио».
Kubernetes в junior-вакансии часто означает «мы хотим человека, который не боится YAML и понимает поды». Это не приглашение учить сертификации полгода вместо пайплайна. Сначала автоматизация того, что вы уже деплоите руками. Оркестрация — поверх.
План на 90 дней
Цель квартала — не «стать DevOps». Цель — один воспроизводимый контур: код лежит в git, по пушу собирается, выкатывается, пишется лог, есть инструкция отката. Пока этого нет, отклики на DevOps будут тишиной.
Дни 1–30. Linux и скрипт на своей работе.
- Каждую неделю автоматизируйте одну рутину из смены: бэкап конфига, проверка диска, массовый рестарт сервиса, выгрузка логов за инцидент.
- Скрипт в git, README на десять строк: зачем, как запустить, какие права, что будет, если упадёт.
- Разберитесь с journalctl, ss/netstat, df, top, правами и systemd unit на уровне «могу объяснить коллеге».
Дни 31–60. Пайплайн.
- Возьмите учебный сервис или свой скрипт. GitHub Actions, GitLab CI или аналог, который уже есть у компании.
- Стадии: lint или простой тест → сборка артефакта → выкладка на стенд. Даже если стенд — виртуалка в домашней сети.
- Сломайте пайплайн нарочно и опишите в README, как читаете лог джобы.
Дни 61–90. Контейнер и один инцидент «как в проде».
- Упакуйте сервис в Docker. Проброс порта, volume, healthcheck, почему не root в проде.
- Соберите короткий разбор: сервис не отвечает → где смотреть → как откатить.
- Если в компании есть тестовый стенд — попросите доступ «посмотреть, как у вас собирается». Это сильнее любого курса.
К концу квартала у вас должно быть: репозиторий, пайплайн, контейнер, два скрипта с работы (даже обезличенных) и черновик резюме с четырьмя пулями. Не сертификат.
План на полгода
Второй квартал закрывает то, без чего вас не зовут дальше junior: IaC, облако на базовом уровне, наблюдаемость и одна зона, за которую вас можно спросить на созвоне.
- Месяц 4. Terraform или аналог. Поднимите маленький контур: сеть, одна машина или serverless-заглушка, security group, state в файле. Уничтожьте и поднимите заново. Если облако дорого — локальный аналог плюс один бесплатный тир, но с тем же принципом: декларативно, не кликами.
- Месяц 5. Наблюдаемость. Метрика «жив ли сервис», лог с корреляцией по запросу, один алерт, который не орёт на всё подряд. Напишите runbook на полстраницы.
- Месяц 6. Kubernetes или аналог оркестрации — только если пайплайн уже живой. Деплоймент, сервис, конфигмап, как смотреть логи пода, как откатить реплику. Не кластер «на всё». Одна нагрузка.
Параллельно копите внутренние задачи: дежурство рядом с SRE, релиз под присмотром, «почини вот этот джоб». Полгода без контакта с живым контуром компании почти всегда длиннее, чем полгода с одной зоной ответственности внутри.
Пет-проект, который можно показать
Рекрутер не откроет пять репозиториев. Нужен один. Формат, который читают:
- Репозиторий с приложением-заглушкой (API или статика + backend).
- Dockerfile и compose или манифесты.
- CI: по пушу в main — тесты и сборка образа.
- IaC на минимальный стенд или скрипт выкладки с явным откатом.
- README: как поднять локально, как выглядит пайплайн, что не сделано (секреты, прод-кластер, мультирегион).
- Папка incidents: один вымышленный, но реалистичный разбор — симптомы, гипотезы, что проверили, чем закрыли.
Честно напишите, что это учебный контур. Притворяться продом вреднее, чем маленький честный стенд. Ссылка должна открываться без пароля.
Пример: внутренний переход за квартал
Сценарий: L2-поддержка SaaS, Linux по SSH, выкладка по инструкции в Confluence, тикеты в Jira. Kubernetes в проде есть, но это зона другой команды.
Месяц 1. Автоматизировал проверку диска и ротацию логов на трёх стендах — скрипт в git команды поддержки, README, запуск из cron. Перестал делать это руками в конце смены.
Месяц 2. Попросил 4 часа в неделю «смотреть, как собирается фронт». Добавил в пайплайн шаг, который падает, если в образе нет healthcheck. Починил два ложных падения джобы.
Месяц 3. Дежурство тенью с дежурным SRE по субботам. Один инцидент: упёрлись в диск на лог-сервере. Написал постмортем на страницу: симптомы, что смотрели, что поставили в мониторинг.
Разговор с руководителем: хочу 30% времени на релизы и пайплайны, готов остаться на части смен ещё квартал. Либо внутренний junior DevOps, либо зона «релизы поддержки» с понятным названием в оргструктуре.
Это продаётся. «Прошёл курс Kubernetes и хочу в DevOps» — нет. Если внутреннего пути нет, тот же контур собираете снаружи и идёте на рынок. Как искать первую IT-роль системно: как найти работу в IT.