Запишись на курс или получи консультацию
Отправляя заявку, вы соглашаетесь с политикой конфиденциальности и условиями обработки персональных данных
Days
Hours
Minutes
Seconds
DevOps
Полезный контент
IT-специальность
Путь в DevOps: из админов, из разработки или с нуля
Команда TeachMeSkills
IT-специальность с 0 до трудоустройства
Вы администрируете серверы третий год или пишете бэкенд и всё чаще ловите себя на том, что вам интереснее, как код доезжает до продакшена, чем сам код или сами серверы. Путь в DevOps из такой точки короче, чем кажется по вакансиям, но у каждой роли он свой.
14 октября 2026 · 11 минут чтения
Администратору засчитывается почти вся эксплуатация, и не хватает кода. Разработчику засчитывается код, git и понимание сборки, и не хватает всего, что происходит после релиза. Тот, кто приходит с нуля, добирает оба пласта сразу, и это честно самый длинный путь.
Работодатели это видят. 13 октября 2026 года на rabota.by по Беларуси в роли DevOps было открыто 43 вакансии. Мы прочитали все и оставили 33, которые относятся к DevOps, SRE, MLOps и платформенной инженерии. Опыт от трёх лет требуют в 22 из них, без опыта готовы взять в двух.
Работодатели это видят. 13 октября 2026 года на rabota.by по Беларуси в роли DevOps было открыто 43 вакансии. Мы прочитали все и оставили 33, которые относятся к DevOps, SRE, MLOps и платформенной инженерии. Опыт от трёх лет требуют в 22 из них, без опыта готовы взять в двух.
Из системного администрирования
Что уже есть. Linux на уровне, когда вы чините его без поисковика. Сети: DNS, маршрутизация, балансировка, файрволы. Понимание железа и виртуализации. И главное, опыт эксплуатации: вы знаете, как сервис ведёт себя ночью под нагрузкой, что такое восстановление из бэкапа и почему изменения в пятницу вечером плохая идея. Этому дольше всего учиться, и это у вас уже есть. Неслучайно в части вакансий роль прямо называется DevOps-инженер или системный администратор, а близкая к админам профессия SRE подробно разобрана в нашей статье SRE-инженер: твой самый надёжный карбюратор.
Чего не хватает. Кода и привычек разработчика. Bash-скрипты на сотню строк у многих админов есть, но DevOps ждёт большего: Python или Go для автоматизации, git с ветками и ревью, CI-пайплайн, который собирает и проверяет изменения сам. И инфраструктура как код: сервер описывается в Terraform или Ansible и создаётся из репозитория, руками в консоли его никто не настраивает. По вакансиям видно, что это не мелочь: инструменты CI/CD названы в 31 вакансии из 33, Terraform в 21, Ansible в 19, Python в 21.
Чего не хватает. Кода и привычек разработчика. Bash-скрипты на сотню строк у многих админов есть, но DevOps ждёт большего: Python или Go для автоматизации, git с ветками и ревью, CI-пайплайн, который собирает и проверяет изменения сам. И инфраструктура как код: сервер описывается в Terraform или Ansible и создаётся из репозитория, руками в консоли его никто не настраивает. По вакансиям видно, что это не мелочь: инструменты CI/CD названы в 31 вакансии из 33, Terraform в 21, Ansible в 19, Python в 21.
План добора. Ориентир для админа с опытом при восьми-десяти часах в неделю: от четырёх до шести месяцев.
Типичная ошибка администраторов. Автоматизировать старый ручной процесс один в один. Скрипт, который по SSH заходит на десять серверов и правит конфиг, остаётся ручной работой, только быстрее. DevOps-подход начинается там, где конфиг лежит в репозитории, изменение проходит ревью и пайплайн, а сервер можно пересоздать с нуля одной командой.
Как подать опыт в резюме. Рекрутер DevOps-вакансии ищет в резюме автоматизацию, и администраторы часто её прячут. Строка о сопровождении серверов компании говорит о нагрузке и ничего не говорит о подходе. Сильнее работают формулировки с результатом: перевёл настройку серверов на Ansible, и новый сервер разворачивается из репозитория без ручных шагов; собрал мониторинг на Prometheus, и о заполнении дисков команда узнаёт раньше пользователей. Если таких строк пока нет, это и есть первая задача на текущей работе.
- Месяц 1: git каждый день, все свои скрипты в репозиторий, ветки и merge request даже для себя.
- Месяц 2: Python для автоматизации, переписать два-три своих Bash-скрипта, работа с API и JSON.
- Месяц 3: Docker, собрать образ своего сервиса, docker compose для стенда из нескольких контейнеров.
- Месяц 4: CI на GitLab CI или GitHub Actions: сборка образа, тесты, выкладка на тестовый сервер.
- Месяцы 5 и 6: Terraform для облака или виртуализации, Ansible для конфигурации, основы Kubernetes.
Типичная ошибка администраторов. Автоматизировать старый ручной процесс один в один. Скрипт, который по SSH заходит на десять серверов и правит конфиг, остаётся ручной работой, только быстрее. DevOps-подход начинается там, где конфиг лежит в репозитории, изменение проходит ревью и пайплайн, а сервер можно пересоздать с нуля одной командой.
Как подать опыт в резюме. Рекрутер DevOps-вакансии ищет в резюме автоматизацию, и администраторы часто её прячут. Строка о сопровождении серверов компании говорит о нагрузке и ничего не говорит о подходе. Сильнее работают формулировки с результатом: перевёл настройку серверов на Ansible, и новый сервер разворачивается из репозитория без ручных шагов; собрал мониторинг на Prometheus, и о заполнении дисков команда узнаёт раньше пользователей. Если таких строк пока нет, это и есть первая задача на текущей работе.
Из разработки
Что уже есть. Код, git, ревью, понимание сборки, зависимостей и тестов. Вы знаете, как приложение устроено изнутри, и это ценнее, чем кажется: половина инцидентов в продакшене начинается с изменения в коде, и DevOps, который умеет читать этот код, находит причину быстрее. Писать пайплайны и скрипты автоматизации для разработчика тоже несложно.
Чего не хватает. Эксплуатации. Linux глубже уровня запуска команд из инструкции: процессы, память, файловые системы, systemd, права. Сети: что происходит между браузером пользователя и вашим сервисом, где может сломаться и как это проверить. Мониторинг и алерты: Prometheus или Grafana упомянуты в 23 вакансиях из 33. И дежурства, то есть готовность отвечать за сервис ночью.
О дежурствах стоит знать заранее, как их устраивают в зрелых командах. В книге Google Site Reliability Engineering описаны правила, по которым живут SRE в Google: на чисто операционную работу у SRE уходит не больше 50% времени, на дежурства из этого не больше 25%. Норма нагрузки там же: не больше двух инцидентов за 12-часовую смену, потому что на разбор одного инцидента с поиском причины, исправлением и последующими задачами в среднем уходит 6 часов. В небольших компаниях такого порядка может не быть, и это стоит спрашивать на собеседовании.
План добора. Ориентир для разработчика: от четырёх до шести месяцев.
Типичная ошибка разработчиков. Относиться к инфраструктуре как к ещё одному проекту с кодом и недооценивать эксплуатацию. Красивый модуль Terraform ничего не стоит, если вы не знаете, что делать, когда в три часа ночи кончилось место на диске. Опыт дежурств у разработчиков обычно самый слабый пункт на собеседовании.
Что вынести в резюме. У многих разработчиков DevOps-опыт уже есть, просто он не записан. Dockerfile для своего сервиса, правки в пайплайне команды, настройка алертов для своего модуля, участие в разборе инцидента после неудачного релиза. Всё это стоит описать отдельными строками с конкретикой: что сделали, какой инструмент, что изменилось. На собеседовании по каждой такой строке спросят подробности, поэтому писать стоит только то, что вы делали руками.
Чего не хватает. Эксплуатации. Linux глубже уровня запуска команд из инструкции: процессы, память, файловые системы, systemd, права. Сети: что происходит между браузером пользователя и вашим сервисом, где может сломаться и как это проверить. Мониторинг и алерты: Prometheus или Grafana упомянуты в 23 вакансиях из 33. И дежурства, то есть готовность отвечать за сервис ночью.
О дежурствах стоит знать заранее, как их устраивают в зрелых командах. В книге Google Site Reliability Engineering описаны правила, по которым живут SRE в Google: на чисто операционную работу у SRE уходит не больше 50% времени, на дежурства из этого не больше 25%. Норма нагрузки там же: не больше двух инцидентов за 12-часовую смену, потому что на разбор одного инцидента с поиском причины, исправлением и последующими задачами в среднем уходит 6 часов. В небольших компаниях такого порядка может не быть, и это стоит спрашивать на собеседовании.
План добора. Ориентир для разработчика: от четырёх до шести месяцев.
- Месяц 1: Linux как администратор, поставить сервер с нуля, разобраться с systemd, логами, правами, дисками.
- Месяц 2: сети, TCP, DNS, HTTP, TLS, nginx как обратный прокси, диагностика через curl, dig, ss, tcpdump.
- Месяц 3: Docker и CI, это пойдёт быстрее за счёт опыта разработки.
- Месяц 4: мониторинг, Prometheus и Grafana на своём стенде, алерты по симптомам пользователя.
- Месяцы 5 и 6: Terraform, Ansible, Kubernetes и разбор чужих постмортемов.
Типичная ошибка разработчиков. Относиться к инфраструктуре как к ещё одному проекту с кодом и недооценивать эксплуатацию. Красивый модуль Terraform ничего не стоит, если вы не знаете, что делать, когда в три часа ночи кончилось место на диске. Опыт дежурств у разработчиков обычно самый слабый пункт на собеседовании.
Что вынести в резюме. У многих разработчиков DevOps-опыт уже есть, просто он не записан. Dockerfile для своего сервиса, правки в пайплайне команды, настройка алертов для своего модуля, участие в разборе инцидента после неудачного релиза. Всё это стоит описать отдельными строками с конкретикой: что сделали, какой инструмент, что изменилось. На собеседовании по каждой такой строке спросят подробности, поэтому писать стоит только то, что вы делали руками.
DevOps с нуля: как стать DevOps-инженером без опыта в IT
Этот путь самый длинный, и смягчать это нечестно. Новичок добирает одновременно эксплуатацию, которой админы учатся годами, и код, который разработчики пишут каждый день. Рынок это отражает: из 33 вакансий две готовы взять без опыта, ещё девять просят от одного до трёх лет. Обе стажёрские вакансии ждут Linux, git и Docker. В одной к этому добавлены сети и веб-серверы на уровне не ниже среднего, в другой Ansible и базовый Kubernetes. Обе просят разговорный английский от B1.
Поэтому для большинства DevOps с нуля начинается со смежной роли: техподдержка второй линии, младший системный администратор, инженер по тестовым средам. Там за год-полтора набирается тот самый опыт эксплуатации, после которого переход идёт по пути администратора из первого раздела. Подробнее о шагах в профессию мы писали в статье Как стать DevOps-инженером.
Что можно собрать дома и показать на собеседовании. Небольшое веб-приложение в Docker, nginx перед ним, база данных в отдельном контейнере. Пайплайн в GitHub Actions или GitLab CI, который собирает образ, прогоняет тесты и выкладывает на виртуальную машину. Сама машина создаётся из Terraform, настраивается Ansible. Prometheus и Grafana с двумя-тремя алертами. И описание в README: как развернуть стенд одной командой, что сломается первым и как это заметить. Такой проект показывает больше, чем список курсов в резюме, потому что на собеседовании по нему можно задать любой вопрос.
Поэтому для большинства DevOps с нуля начинается со смежной роли: техподдержка второй линии, младший системный администратор, инженер по тестовым средам. Там за год-полтора набирается тот самый опыт эксплуатации, после которого переход идёт по пути администратора из первого раздела. Подробнее о шагах в профессию мы писали в статье Как стать DevOps-инженером.
Что можно собрать дома и показать на собеседовании. Небольшое веб-приложение в Docker, nginx перед ним, база данных в отдельном контейнере. Пайплайн в GitHub Actions или GitLab CI, который собирает образ, прогоняет тесты и выкладывает на виртуальную машину. Сама машина создаётся из Terraform, настраивается Ansible. Prometheus и Grafana с двумя-тремя алертами. И описание в README: как развернуть стенд одной командой, что сломается первым и как это заметить. Такой проект показывает больше, чем список курсов в резюме, потому что на собеседовании по нему можно задать любой вопрос.
Словарь
Пайплайн. Цепочка автоматических шагов от коммита до выкладки: сборка, тесты, проверка безопасности, деплой. Описывается файлом в репозитории.
Контейнер. Приложение вместе со всем, что нужно для его запуска, упакованное в образ. Запускается одинаково на ноутбуке и на сервере.
Оркестратор. Система, которая запускает контейнеры на множестве серверов, перезапускает упавшие и распределяет нагрузку. Самый распространённый оркестратор Kubernetes.
Деплой. Выкладка новой версии в рабочее окружение. Хороший деплой можно откатить за минуты.
Алерт. Автоматическое оповещение дежурному, когда метрика вышла за порог. Полезный алерт срабатывает на то, что заметит пользователь, и требует действия.
Инфраструктура как код. Описание серверов, сетей и настроек в файлах, которые лежат в git и применяются инструментом вроде Terraform или Ansible. Изменения проходят ревью, как обычный код.
Пайплайн. Цепочка автоматических шагов от коммита до выкладки: сборка, тесты, проверка безопасности, деплой. Описывается файлом в репозитории.
Контейнер. Приложение вместе со всем, что нужно для его запуска, упакованное в образ. Запускается одинаково на ноутбуке и на сервере.
Оркестратор. Система, которая запускает контейнеры на множестве серверов, перезапускает упавшие и распределяет нагрузку. Самый распространённый оркестратор Kubernetes.
Деплой. Выкладка новой версии в рабочее окружение. Хороший деплой можно откатить за минуты.
Алерт. Автоматическое оповещение дежурному, когда метрика вышла за порог. Полезный алерт срабатывает на то, что заметит пользователь, и требует действия.
Инфраструктура как код. Описание серверов, сетей и настроек в файлах, которые лежат в git и применяются инструментом вроде Terraform или Ansible. Изменения проходят ревью, как обычный код.
Если нужен структурированный путь с ментором, посмотрите программу курса DevOps-инженер TeachMeSkills: Linux, Bash, Python, Docker, Ansible, Terraform, Kubernetes и мониторинг за семь месяцев.
Собеседование на DevOps-инженера: что там проверяют
Интервью на DevOps-инженера обычно состоит из нескольких технических блоков, и их набор почти не зависит от компании.
Linux. Процессы и сигналы, память и swap, файловые системы и inode, systemd, права, диагностика через top, ss, journalctl, strace. Типичный вопрос: сервер тормозит, что вы проверите и в каком порядке.
Сети. Что происходит от ввода адреса в браузере до ответа сервера: DNS, TCP, TLS, HTTP, балансировщик. Чем отличаются коды ответа 502 и 504.
Контейнеры и оркестрация. Как устроен образ и его слои, чем контейнер отличается от виртуальной машины, что делать с упавшим подом в Kubernetes.
CI/CD. Как устроен пайплайн, где хранить секреты, как откатить неудачный релиз.
Вопросы по контейнерам часто проверяют, работали ли вы с ними руками. Пример: образ приложения весит больше гигабайта, как его уменьшить. Хороший ответ называет многоэтапную сборку, лёгкий базовый образ, порядок слоёв, при котором зависимости кешируются, и файл .dockerignore. Слабый ответ ограничивается словом оптимизировать. Интервьюер обычно продолжает уточнениями, пока не дойдёт до границы ваших знаний, и это нормально: важно, как вы рассуждаете у этой границы.
Разбор инцидента. Самый показательный блок. Интервьюер описывает симптом и смотрит, как вы рассуждаете.
Пример такого вопроса: пользователи жалуются, что сайт открывается через раз, ваши действия.
Слабый ответ: перезагружу сервер и посмотрю, пройдёт ли. Перезагрузка может временно убрать симптом, но причина останется, а заодно пропадут данные для диагностики: состояние процессов, открытые соединения, содержимое памяти.
Хороший ответ начинается с уточнения масштаба: у всех пользователей или у части, с какого момента, что менялось перед этим, был ли деплой. Дальше проверка от пользователя внутрь: какой код ответа отдаёт сайт, что пишет балансировщик, все ли экземпляры приложения живы, что в логах и метриках за последний час. И отдельно: если причина найдена не сразу, сначала восстановить работу, например откатом последнего релиза, а разбирать причину уже на работающей системе. Интервьюеру важен порядок рассуждений, точный ответ на конкретную поломку здесь вторичен.
Если опыта эксплуатации ещё нет, честно скажите об этом и разберите инцидент на своём домашнем стенде: что вы ломали, как заметили, как чинили. Это сильнее выдуманного боевого опыта, который раскроется на втором уточняющем вопросе. Больше типовых вопросов собрано в нашем экспресс-гайде по собеседованиям для тестировщиков, девопс-инженеров и Java-разработчиков.
Linux. Процессы и сигналы, память и swap, файловые системы и inode, systemd, права, диагностика через top, ss, journalctl, strace. Типичный вопрос: сервер тормозит, что вы проверите и в каком порядке.
Сети. Что происходит от ввода адреса в браузере до ответа сервера: DNS, TCP, TLS, HTTP, балансировщик. Чем отличаются коды ответа 502 и 504.
Контейнеры и оркестрация. Как устроен образ и его слои, чем контейнер отличается от виртуальной машины, что делать с упавшим подом в Kubernetes.
CI/CD. Как устроен пайплайн, где хранить секреты, как откатить неудачный релиз.
Вопросы по контейнерам часто проверяют, работали ли вы с ними руками. Пример: образ приложения весит больше гигабайта, как его уменьшить. Хороший ответ называет многоэтапную сборку, лёгкий базовый образ, порядок слоёв, при котором зависимости кешируются, и файл .dockerignore. Слабый ответ ограничивается словом оптимизировать. Интервьюер обычно продолжает уточнениями, пока не дойдёт до границы ваших знаний, и это нормально: важно, как вы рассуждаете у этой границы.
Разбор инцидента. Самый показательный блок. Интервьюер описывает симптом и смотрит, как вы рассуждаете.
Пример такого вопроса: пользователи жалуются, что сайт открывается через раз, ваши действия.
Слабый ответ: перезагружу сервер и посмотрю, пройдёт ли. Перезагрузка может временно убрать симптом, но причина останется, а заодно пропадут данные для диагностики: состояние процессов, открытые соединения, содержимое памяти.
Хороший ответ начинается с уточнения масштаба: у всех пользователей или у части, с какого момента, что менялось перед этим, был ли деплой. Дальше проверка от пользователя внутрь: какой код ответа отдаёт сайт, что пишет балансировщик, все ли экземпляры приложения живы, что в логах и метриках за последний час. И отдельно: если причина найдена не сразу, сначала восстановить работу, например откатом последнего релиза, а разбирать причину уже на работающей системе. Интервьюеру важен порядок рассуждений, точный ответ на конкретную поломку здесь вторичен.
Если опыта эксплуатации ещё нет, честно скажите об этом и разберите инцидент на своём домашнем стенде: что вы ломали, как заметили, как чинили. Это сильнее выдуманного боевого опыта, который раскроется на втором уточняющем вопросе. Больше типовых вопросов собрано в нашем экспресс-гайде по собеседованиям для тестировщиков, девопс-инженеров и Java-разработчиков.
Практическое задание: разберите инцидент
Сценарий учебный, тексты сообщений в логах в том виде, в каком их пишут nginx, Python и Linux.
В 03:20 приходит алерт: доля ответов с кодом 502 на сайте магазина выше 50%. Сайт работает так: nginx принимает запросы и передаёт их приложению на Python, которое слушает порт 8000 на том же сервере. Вчера вечером выкатили релиз. Вот что вы видите.
В 03:20 приходит алерт: доля ответов с кодом 502 на сайте магазина выше 50%. Сайт работает так: nginx принимает запросы и передаёт их приложению на Python, которое слушает порт 8000 на том же сервере. Вчера вечером выкатили релиз. Вот что вы видите.
$ curl -sI https://shop.example/api/orders | head -1
HTTP/1.1 502 Bad Gateway
$ tail -1 /var/log/nginx/error.log
2026/10/13 03:19:41 [error] 812#812: *48213 connect() to 127.0.0.1:8000 failed (111: Connection refused) while connecting to upstream, client: 10.0.4.17, server: shop.example, request: "GET /api/orders HTTP/1.1", upstream: "http://127.0.0.1:8000/api/orders", host: "shop.example"
$ tail -2 /var/log/shop/app.log
2026-10-13 03:17:02 ERROR Unhandled exception in worker
OSError: [Errno 28] No space left on device
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 40G 40G 0 100% /Сформулируйте гипотезы, расставьте их по вероятности и напишите порядок проверок. Отдельно ответьте на два вопроса: как вернуть сайт в работу в ближайшие десять минут и что изменить, чтобы это не повторилось.
Разбор для сверки. Код 502 и сообщение nginx Connection refused означают, что на порту 8000 никто не слушает: приложение упало или не запустилось. Лог приложения называет причину: на диске нет места, и df это подтверждает. Следующий шаг: найти, что занимает место. Это делает команда du -xh / --max-depth=2 | sort -h | tail. Потом стоит проверить, связан ли рост со вчерашним релизом. Частая причина в такой ситуации: в релиз попал отладочный уровень логирования, а ротации логов для нового файла нет. Восстановление: освободить место, например сжать или обрезать разросшийся лог через truncate, перезапустить приложение и убедиться, что 502 пропали. Удалённый файл, который ещё держит открытым какой-нибудь процесс, место не освободит, это проверяется через lsof. После этого постмортем. В книге Google SRE он описан как письменный отчёт об инциденте, его влиянии, действиях по устранению, причинах и задачах, которые не дадут инциденту повториться, без поиска виноватых. Задачи здесь очевидные: алерт на заполнение диска до 100%, ротация для всех логов приложения, проверка уровня логирования в пайплайне. Хороший ответ начинается с восстановления работы, а причину разбирает уже на живом сайте.
Разбирать такие инциденты на учебных стендах с ментором можно на курсе DevOps-инженер TeachMeSkills. Как преподаватель курса смотрит на профессию, можно прочитать в интервью Открываем мир DevOps.
Разбор для сверки. Код 502 и сообщение nginx Connection refused означают, что на порту 8000 никто не слушает: приложение упало или не запустилось. Лог приложения называет причину: на диске нет места, и df это подтверждает. Следующий шаг: найти, что занимает место. Это делает команда du -xh / --max-depth=2 | sort -h | tail. Потом стоит проверить, связан ли рост со вчерашним релизом. Частая причина в такой ситуации: в релиз попал отладочный уровень логирования, а ротации логов для нового файла нет. Восстановление: освободить место, например сжать или обрезать разросшийся лог через truncate, перезапустить приложение и убедиться, что 502 пропали. Удалённый файл, который ещё держит открытым какой-нибудь процесс, место не освободит, это проверяется через lsof. После этого постмортем. В книге Google SRE он описан как письменный отчёт об инциденте, его влиянии, действиях по устранению, причинах и задачах, которые не дадут инциденту повториться, без поиска виноватых. Задачи здесь очевидные: алерт на заполнение диска до 100%, ротация для всех логов приложения, проверка уровня логирования в пайплайне. Хороший ответ начинается с восстановления работы, а причину разбирает уже на живом сайте.
Разбирать такие инциденты на учебных стендах с ментором можно на курсе DevOps-инженер TeachMeSkills. Как преподаватель курса смотрит на профессию, можно прочитать в интервью Открываем мир DevOps.
Частые вопросы
Сколько занимает переход в DevOps?
Ориентир для администратора или разработчика при восьми-десяти часах в неделю: от четырёх до шести месяцев на добор недостающего. С нуля дольше: сначала год-полтора в смежной роли с эксплуатацией, потом переход.
Нужен ли DevOps-инженеру английский?
Английский указан в требованиях 15 из 33 вакансий DevOps на rabota.by в октябре 2026 года. Документация, сообщения об ошибках и большая часть материалов по инструментам на английском, поэтому читать придётся в любом случае.
Обязателен ли Kubernetes на входе?
Желателен. Kubernetes упомянут в 8 из 11 вакансий с опытом до трёх лет, в стажёрской вакансии на базовом уровне. Начинать с него рано: сначала Linux, сети и Docker, без них Kubernetes не понять.
Берут ли в DevOps администраторов без кода?
Редко. Bash или Python упомянуты в 25 из 33 вакансий DevOps на rabota.by в октябре 2026 года. Администратору стоит начать перевод своих рутинных задач в код и в репозиторий ещё на текущей работе.
Что учить первым, если начинаю с нуля?
Linux и сети. На них держится всё остальное: Docker, CI, Kubernetes и мониторинг. После этого git и один скриптовый язык, лучше Python.
Ориентир для администратора или разработчика при восьми-десяти часах в неделю: от четырёх до шести месяцев на добор недостающего. С нуля дольше: сначала год-полтора в смежной роли с эксплуатацией, потом переход.
Нужен ли DevOps-инженеру английский?
Английский указан в требованиях 15 из 33 вакансий DevOps на rabota.by в октябре 2026 года. Документация, сообщения об ошибках и большая часть материалов по инструментам на английском, поэтому читать придётся в любом случае.
Обязателен ли Kubernetes на входе?
Желателен. Kubernetes упомянут в 8 из 11 вакансий с опытом до трёх лет, в стажёрской вакансии на базовом уровне. Начинать с него рано: сначала Linux, сети и Docker, без них Kubernetes не понять.
Берут ли в DevOps администраторов без кода?
Редко. Bash или Python упомянуты в 25 из 33 вакансий DevOps на rabota.by в октябре 2026 года. Администратору стоит начать перевод своих рутинных задач в код и в репозиторий ещё на текущей работе.
Что учить первым, если начинаю с нуля?
Linux и сети. На них держится всё остальное: Docker, CI, Kubernetes и мониторинг. После этого git и один скриптовый язык, лучше Python.
Выводы
Быстрее всего в DevOps переходят администраторы: эксплуатация у них есть, не хватает кода. Разработчикам код даётся легко, а принять ответственность за прод и дежурства сложнее. Тем, кто приходит с нуля, приходится добирать оба пласта, и честнее заложить на это время со смежной ролью.
Следующие шаги: разберите инцидент из задания, составьте личный план добора по своему пути и поднимите учебный стенд, который не жалко ломать.
Переход оправдан тем, кто готов отвечать за прод и дежурить. Тому, кто ищет спокойную работу строго по задачам, в DevOps будет тяжело. Если нужна структура и наставник, посмотрите программу курса DevOps-инженер TeachMeSkills.
Следующие шаги: разберите инцидент из задания, составьте личный план добора по своему пути и поднимите учебный стенд, который не жалко ломать.
Переход оправдан тем, кто готов отвечать за прод и дежурить. Тому, кто ищет спокойную работу строго по задачам, в DevOps будет тяжело. Если нужна структура и наставник, посмотрите программу курса DevOps-инженер TeachMeSkills.
Запишись на курс или получи консультацию
Отправляя заявку, вы соглашаетесь с политикой конфиденциальности и условиями обработки персональных данных
- В жизни каждой уважающей себя IT-конторы наступает момент, когда пора собирать собственный отдел тестирования. Исторически сложилось, что разработчики обладают огромным ЧСВ и не видят за собой никаких ошибок. Но когда их «идеальный» продукт попадает в руки к кастомеру (или что хуже — к конечному юзеру), наступает момент фееричной раздачи тульских пряников.
- Фронтенд-разработчик — это специалист по созданию сайтов и веб-приложений, на которых постоянно что-то кряхтит, сопит, хрюкает и радостно ржет. В отличие от других бородатых и страшных прогеров в свитерах, он чаще всего молод, опрятен и чертовски красив. Да и зарплата у экспертов такого профиля приличная. По данным dev.by, в среднем за месяц белорусские фронтенд-мастера получают $2 500.
- Думаешь, что вкатиться в IT сложнее, чем распилить пластиковым ножом баобаб? Вот и нет! По крайней мере, если начать учебу в школе TeachMeSkills с курсов «Питона». По индексу TIOBE он становился самым популярным языком программирования в 2020, 2021 и 2024 годах. А по данным портала dev.by медианная зарплата «питониста» в Беларуси составляет 2 000 американских рублей!