Переход из технической поддержки или системного администрирования в 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.
Как писать резюме: заголовок и пули
Заголовок не «специалист поддержки». На время поиска: «Junior DevOps / эксплуатация» или «Support engineer → DevOps (Linux, CI, инциденты)». Одна роль. Не «открыт к разработке, тесту и облакам».
Пули, которые доказывают переход, а не намерение:
- Автоматизировал ежедневную проверку стендов: bash-скрипт, cron, отчёт в канал команды; ручная проверка сократилась с 40 минут смены до запуска по расписанию.
- Собрал CI для учебного сервиса: lint, сборка Docker-образа, выкладка на стенд по пушу в main; откат — предыдущий тег образа.
- Разобрал инцидент недоступности API: по логам сузил до заполненного диска на лог-хосте, описал шаги и добавил алерт по inode/диску.
- Выкладка по чек-листу: 2–3 релиза в неделю, проверка после деплоя, эскалация в разработку с шагами и окружением, не с «у пользователя не работает».
- Terraform: поднял и уничтожил учебный контур (сеть + инстанс + security group), state в файле, в README — как повторить.
Плохо: «изучал Docker, Kubernetes, AWS, Terraform, Ansible, Prometheus». Это список желаний. Навыки подтверждают пули, не строка skills. Как собрать каркас: как составить резюме и навыки в IT-резюме.
Если коммерческого DevOps-стажа нет, проекты и внутренние задачи оформляйте как опыт, не как «хобби внизу». Принцип тот же, что в резюме без опыта: артефакт и роль в нём.
Как говорить о переходе на собеседовании
Вас будут проверять не на любовь к DevOps, а на то, умеете ли вы объяснить, почему пайплайн упал. Держите три истории:
- Рутина, которую автоматизировали: было руками, стало скриптом, что сломалось по пути.
- Инцидент: симптомы, гипотезы, что отсекли, чем закрыли, что изменили после.
- Релиз или пайплайн: как собираете, как откатываете, где секреты, чего сознательно нет.
Скрипт ответа на «почему уходите из поддержки»:
Не убегаю от пользователей. Хочу отвечать за то, чтобы сервис поднимался без ручного чек-листа. За квартал автоматизировал проверки стендов и собрал пайплайн учебного сервиса — ссылка. Инциденты и смены оставляю как сильную сторону: я уже видел, как система ведёт себя ночью, а не только на демо.
Не говорите «поддержка выгорает, хочу больше денег». Это может быть правдой, но нанимающий услышит «уйдёт и отсюда». Деньги обсуждаются отдельно, после задачи.
Частые ошибки
- Кидать поддержку в резюме вниз, как стыдный этап. Это ваш фонд инцидентов. Переведите на язык эксплуатации.
- Учить Kubernetes до скрипта и CI. Оркестрация без пайплайна — декорация.
- Пять курсов, ноль репозиториев. Сертификат не заменяет README с откатом.
- Внутренний переход «когда-нибудь» без разговора с руководителем. Напишите зону, часы, критерий через 90 дней.
- Отклик на senior SRE с нуля. Сначала junior DevOps, эксплуатация, platform assistant, intern в инфраструктуре. Смотрите задачи в junior-вакансиях, не только слово DevOps.
Частые вопросы
Нужно ли увольняться, чтобы войти в DevOps?
Сначала внутренний путь: 20–30% времени на пайплайны, релизы, дежурство тенью. Уход имеет смысл, когда за квартал вам не дают зону и не называют причину. Тогда рынок, а не обида.
Сисадмин и L1-чат — это один маршрут?
Нет. Админ ближе к Linux и сети. L1 ближе к процессу инцидента. Обоим нужен скрипт и пайплайн. Админу часто быстрее закрыть Linux, чату — быстрее закрыть дисциплину разбора, но Linux всё равно придётся добрать.
Стоит ли идти в DevOps через QA или разработку?
Если вам ближе код продукта — смотрите переход из QA в разработку. DevOps — если тянет инфраструктура, релизы и «почему прод лёг», а не фича в интерфейсе.
Какой облачный провайдер выбрать?
Тот, который уже есть у работодателя, или один, где вы реально поднимете и уничтожите контур. Три провайдера в skills без одного живого стенда хуже, чем один.
Берут ли на DevOps без коммерческого кода?
Берут на junior и intern, если есть эксплуатация плюс артефакт. Без артефакта — редко. Стажировки в инфраструктуре ищите так же жёстко, как любые другие: срок, ментор, задачи — см. стажировку в IT. Если коммерческого DevOps нет, доказательства оформляйте как в поиске без опыта: ссылка и роль в задаче, не список курсов.
Нужен ли английский сразу?
Для чтения документации и логов — да, хотя бы пассивно. Для первой роли в русскоязычной команде это не барьер сильнее отсутствия пайплайна. Для удалёнки на зарубежную команду — уже барьер.
Что сделать сейчас
На этой неделе выберите одну рутину из смены и превратите её в скрипт с README. Параллельно заведите один репозиторий под пайплайн и контейнер — не под «когда-нибудь Kubernetes». Перепишите четыре пули опыта языком инцидентов и автоматизации и прогоните верх через разбор резюме.
Если внутреннего перехода нет в разговоре — откройте DevOps-вакансии и пять junior-ролей с Linux и CI в задачах. Откликайтесь только туда, где ваш скрипт и пайплайн закрывают первую обязанность, а не «в DevOps вообще».