DEVOPS В РОССИИ 2025: ЦИФРЫ, КОТОРЫЕ СТОИТ ЗНАТЬ 💳

Свежий опрос российских DevOps-инженеров. Разберём подробно, с цифрами, потому что за этими процентами реально видно, куда двигается индустрия.

1️⃣ Топовые команды оторвались от середняков

Доля Elite-команд выросла на 4%, High на 2%. Суммарно топ-профили прибавили 6% за год.

А вот что интересно: разрыв виден не только в релизах, но и в том, как разработчики оценивают свою же работу. Спросили инженеров, согласны ли они с утверждением "обратная связь оперативна, я всё ещё в контексте задачи":

Low — 70,0%
Medium — 80,8%
High — 83,3%
Elite — 85,1%

А с формулировкой "обратная связь информативна и помогает исправить ошибки":

Low — 76,4%
Elite — 89,6%

Разница в 13 процентных пунктов на одном и том же вопросе. Это не про мотивацию людей, это про то, как в команде устроены циклы обратной связи.

2️⃣ Инфобез это теперь часть пайплайна, а не отдельный отдел

75% инженеров используют метрики ИБ в работе, 40% говорят, что инструменты безопасности встроены прямо в CI/CD.

Но внедрение ИБ даётся не бесплатно. Топ проблем, с которыми сталкиваются команды:

45,5% — не хватает технической экспертизы у команды внедрения
42,3% — проблемы совместимости с текущими системами
41,0% — высокая стоимость
36,5% — обучение персонала
33,9% — избыточные алерты и ложные срабатывания
19,6% — vendor lock, зависимость от одного поставщика

Меньше всего боятся правовых и регуляторных требований (18%). Больше всего, буквально каждый второй, боится того, что команда просто не потянет внедрение технически.

3️⃣ ИИ используют 71,3%, но толку от него по-разному

Свой уровень в промпт-инжиниринге инженеры оценивают так:

Новичок — 21,8%
Любитель — 45,7%
Опытный — 27,8%
Гуру — 4,7%

Гуру, разумеется, меньшинство. Но именно они отмечают наибольший прирост личной и командной эффективности от ИИ. То есть навык работы с промптами буквально конвертируется в пользу, а не просто "у меня есть Copilot, стало быстрее".

Ловушка с собеса 🍑

Какие четыре метрики считаются мировым стандартом для оценки производительности DevOps-команды?

Deployment Frequency — частота деплоев
Lead Time for Changes — срок поставки изменений
Mean Time to Recovery — время восстановления после инцидента
Change Failure Rate — доля неудачных изменений

Это DORA-метрики. По ним, собственно, и делят команды на Low, Medium, High и Elite из первого пункта.

Индустрия взрослеет, а разрыв между теми, кто выстроил процессы, и теми, кто нет, увеличивается с каждым годом.

#devops #sre #dora #devopsинженер #ит #собес #ci_cd #backend #ии

ЧТО ДУМАЮТ О DEVOPS HR VS КАК ЭТО НА САМОМ ДЕЛЕ 🤔

Между тем, что пишет HR в вакансии, и тем, что реально происходит внутри компании, обычно пропасть в несколько этажей. Пройдёмся по всей воронке найма - от текста вакансии до оффера.

1️⃣ Текст вакансии

Кажется: ищут супергероя, который знает Kubernetes, Terraform, Ansible, Prometheus, три облака и Python на уровне синьора.

На самом деле: такую вакансию чаще всего пишет HR, который взял требования из трёх разных описаний и склеил их в одно, потому что не отличает DevOps от дата-инженера. Технический руководитель потом просто закрывает глаза на половину пунктов и смотрит на реальный опыт.

2️⃣ Отбор резюме

Кажется: резюме читает живой человек и оценивает опыт целиком.

На самом деле: в крупных компаниях первый фильтр — автоматическая система, которая ищет буквальные совпадения слов из вакансии. Если в вакансии написано «Kubernetes», а у тебя в резюме «k8s», система может тебя просто не увидеть.

Практический вывод: дублируй ключевые термины из вакансии дословно. Это не читерство, это работа с реальностью системы отбора.

3️⃣ Звонок с HR

Кажется: HR должен разбираться в том, что такое readinessProbe или Error Budget.

На самом деле: его задача — не техническая экспертиза, а проверка софт-скилов и базовых рамок: зарплата, формат работы, готовность к переезду. Если ты на этом звонке начинаешь спорить о деталях Kubernetes — просто теряешь время обоих.

4️⃣Техническое интервью

Кажется: чем больше лет опыта в резюме, тем сильнее кандидат.

На самом деле: технический интервьюер за десять минут разговора понимает реальный уровень, и цифра в резюме почти не влияет на решение. Видел кандидатов с пятью годами стажа, которые путают liveness и readiness probe. И видел человека с полутора годами опыта, который спокойно разбирает живой инцидент.

5️⃣Оффер и зарплата

Кажется: вилка в вакансии — это то, что ты гарантированно получишь.

На самом деле: вилка часто написана для привлечения откликов, а реальное число формируется по итогам технического интервью и иногда торга. Причём вилка может быть просто устаревшим шаблоном, который скопировали полгода назад и забыли обновить.

😵‍💫Отдельно про отказы

Отказ - это не приговор твоему уровню. Чаще всего это про несовпадение с конкретной командой прямо сейчас. Видел сильного кандидата, которого не взяли, потому что искали человека именно под легаси-зоопарк технологий, а не потому что он был плох.

Что реально решает на всех этапах 😵‍💫

Понятная история в резюме с ключевыми терминами из вакансии, чёткие ответы без воды на техническом интервью, и адекватность в общении. Все три вещи бесплатны и не требуют пятнадцати сертификатов.

А тебе попадались вакансии или отказы, которые явно писал не технарь?
#devops #hr #собес #devopsинженер #резюме #карьера #ит #трудоустройство

НАВЫКИ, КОТОРЫЕ РЕАЛЬНО ПРОДАЮТСЯ В DEVOPS В 2026 ГОДУ 🖐

Большинство девопс инженеров сейчас качают не те навыки. Разберём, что реально продаётся на рынке, а что уже почти ничего не стоит.

Что умерло👌

Просто уметь Docker это уже не навык, а гигиенический минимум, как уметь пользоваться почтой.
Jenkins как основной инструмент в резюме сегодня скорее красный флаг, чем плюс - индустрия давно ушла в GitHub Actions и GitLab CI.
Пачка сертификатов без единой реальной истории за спиной впечатляет только того, кто их выдал.
А знание пятнадцати инструментов по верхам работает против тебя — на собесе такого человека раскалывают за три вопроса вглубь.

А что реально продаётся 👏

➕ Kubernetes не на уровне туториала, а с пониманием, как он себя ведёт в проде. Сеть, хранилище, поведение под нагрузкой, апгрейд без даунтайма.

2️⃣ Observability. Не просто поставить Prometheus и Grafana, а собрать метрики так, чтобы по ним реально принимали решения, а не просто смотрели красивые дашборды.

3️⃣ GitOps. Компании физически устали от ручных деплоев через ssh и хотят декларативный подход через ArgoCD или Flux.

4️⃣ Terraform на серьёзном уровне - с модулями и нормальным управлением стейтом, а не один файл на триста строк.

5️⃣ Понимание надёжности: SLO, Error Budget, работа с постмортемами после инцидентов.

Показательный пример ☝️

Два кандидата с одинаковым стажем в три года.
Один пишет в резюме: знаю Docker, Kubernetes, Terraform, Ansible, Jenkins, Prometheus.
Второй пишет: снизил время деплоя с сорока минут до шести за счёт перехода на GitOps, и сократил количество инцидентов на треть после внедрения нормальных SLO.

Угадай, кого позовут на собес быстрее.
Дело не в списке технологий, а в том, что второй показал влияние на результат, а не просто перечислил стек.

Короче

Рынок устал от людей, которые всё попробовали, но ничего не довели до конца. Сейчас продаётся не ширина, а глубина плюс умение объяснить, что именно ты изменил.

А какой навык, по-твоему, уже потерял вес за последний год? Пиши в комментариях.


#devops #sre #kubernetes #gitops #devopsинженер #ит #собес #резюме #карьера

ГАРАНТИРОВАННЫЙ СПОСОБ НИКОГДА НЕ ПРОВАЛИТЬ СОБЕС 😎

Не отправлять резюме и не ходить на собеседования.

Работает в 100% случаев)

А если серьёзно, я постоянно вижу одну и ту же историю. Человек уже знает Linux, понимает сети, работал с Docker, разобрал Kubernetes, написал резюме и вроде бы готов искать работу.

Спрашиваю: «Сколько откликов сделал за неделю?»🤔

Ноль.

Почему?

«Мне бы ещё Kubernetes подтянуть. Там вопросы по сетям сложные бывают. Потом Terraform посмотреть. И Bash у меня слабоват. Вот ещё пару недель подготовлюсь и начну откликаться».

Проходит две недели. Откликов снова ноль.❔

Зато теперь появляется новая проблема: пока разбирался с Kubernetes, понял, что плохо знает Linux. Полез повторять Linux, наткнулся на systemd, namespaces, cgroups, iptables. Потом открыл очередную вакансию, а там Kafka, PostgreSQL, Ansible, Helm, ArgoCD и ещё половина зоопарка.

И в голове снова появляется мысль: «Бля, какой мне собес, я вообще ничего не знаю» 😅

Вот только есть одна проблема.👮

Ты НИКОГДА не будешь знать достаточно для всех вакансий.

Можно полгода готовиться к собеседованиям и на первом же интервью получить три вопроса, которые ты вообще не повторял. А можно выйти на рынок сейчас, провалить пару собесов и за неделю понять о своих пробелах больше, чем за месяц самостоятельной подготовки.

Потому что собеседование - это тоже часть подготовки.

Первый собес покажет, где ты плаваешь. Второй покажет, какие вопросы повторяются. На третьем ты уже начнёшь замечать паттерны. А через несколько интервью многие вопросы, от которых раньше бросало в холодный пот, будут восприниматься как обычный разговор.

И вот здесь происходит забавная вещь.

Часто человеку на самом деле не нужен ещё один курс по Kubernetes.

Ему нужен первый технический собес.

Потому что бесконечное обучение иногда очень удобно маскирует обычный страх: «А вдруг я пойду, и там поймут, что я ни хрена не знаю?»👏

Поймут? Возможно.

Завалишь собес? Тоже возможно.

Только после этого у тебя будет список конкретных вещей, которые нужно подтянуть. А не бесконечное ощущение, что нужно выучить вообще весь DevOps.

Именно поэтому на менторстве я иногда буквально останавливаю ребят: хватит учить очередную технологию, пора идти проверять себя об реальный рынок.
Мы проводим mock-собес максимально близко к настоящему, разбираем слабые места, исправляем их и дальше уже идём на реальные интервью.

Потому что моя задача не сделать из человека ходячую документацию Kubernetes.

Моя задача - довести его до состояния, когда он может открыть вакансию, отправить отклик и спокойно пойти разговаривать с техническим интервьюером.

А дальше начинается самое интересное: собес → разбор ошибок → подготовка → следующий собес.

И так до оффера.

Короче, если ты уже третий месяц «ещё немного готовишься», возможно, тебе пора перестать готовиться и наконец проверить, насколько ты на самом деле не готов 👎

Надоело гонять Linux, сети и Kubernetes по пятому кругу вместо реальных собесов - пиши в комменты

🔥 Кажется, я придумал, как сделать обучение DevOps намного интереснее.

Последнее время делаю одну большую штуку для вас - полноценную платформу для обучения DevOps.

И главная идея в том, что это НЕ очередной курс, где ты посмотрел 40 часов видео, закрыл вкладку и через неделю забыл половину.

Здесь обучение будет больше похоже на игру.

Получаешь задачу → идёшь выполнять её руками → ошибаешься → разбираешься → проходишь дальше.

При этом перед тобой будет понятный roadmap: от базы до тем, которые реально нужны DevOps-инженеру в работе и на собеседованиях.

Linux, сети, Docker, CI/CD, Kubernetes и дальше всё глубже 🤝🤝

Хочу сделать место, куда ты заходишь и тебе не нужно думать:

«А что мне учить дальше?»
«Я уже готов к Kubernetes?»
«Где взять нормальную практику?»
«Почему я третий месяц смотрю курсы, но ничего не умею руками?»

Платформа сама будет постепенно вести тебя по маршруту.

И самое важное - хочу сделать её в формате недорогой подписки, чтобы не нужно было отдавать 100-200к

Если идея платформы, где DevOps можно буквально ПРОХОДИТЬ как игру, вам интересна - накидайте 🔥

83 темы и 13 блоков 🖐

Друзья, уже совсем скоро моя платформа/тренажер будет готова

В программе сейчас 83 темы, объединённые в 13 блоков:
1. Вход в профессию
2. Linux
3. Сети
4. Git
5. Docker
6. CI/CD
7. Kubernetes Core
8. Kubernetes Operations
9. IaC и GitOps
10. Observability и SRE
11. Cloud и Production
12. DevSecOps
13. Собеседования и финальная проверка

Внутри 🤔

83 темы
498 теоритеческих карточек;
166 практических заданий;
1245 вопросов

Ждете? ❔

Кстати, учиться можно будет прямо с телефона

ЗАПУСТИЛ ТРЕНАЖЁР ДЛЯ ПОДГОТОВКИ К DEVOPS И SRE СОБЕСАМ 🐒

Собирал, тестировал и ломал сам, теперь можно пощупать. Показал в видео как это работает изнутри.

🎯 Диагностика

Шесть минут вопросов не на определения, а на реальные рабочие ситуации. В конце видишь свой уровень и с какой темы начинать именно тебе.

📚 83 темы

Linux, сети, Docker, Kubernetes, CI/CD, Terraform, Ansible, Observability, безопасность, Cloud, production troubleshooting. Каждая тема: теория короткими карточками, практическое задание с реальным разбором, квиз на трёх уровнях сложности.

🐒 Шпаргалка команд

200 карточек отдельно от основного маршрута, если нужно просто закрепить конкретные команды.

👨‍💻 Живой наставник

Застрял, написал вопрос прямо в боте, отвечаю лично в этом же чате.

Сразу честно: тренажёр не обещает оффер завтра. Он показывает где реально просели знания и даёт попрактиковаться на вопросах, которые спрашивают на настоящих собесах. Если нужна прицельная подготовка именно под твои будущие интервью, разбор конкретных вопросов от компаний, лучше индивидуальные занятия.

Часть тем бесплатно, полный доступ по подписке.

💲Стоимость подписки - 3590р (120 рублей в день, дешевле чем чашка кофе...)

Ссылку на бота пришлю завтра, кто хочет быть одним из первых напишите в комментарии, пришлю в личку

Если дошёл до конца поста, поставь 🔥, буду понимать что вообще кому-то интересно

🤠 DEVOPS IRON - тренажёр для подготовки к DevOps и SRE

Не знаешь, с чего начать или что именно подтянуть перед следующим собесом?
За 6 минут диагностика определит твой уровень и покажет слабые места. Дальше прокачиваешь их прямо в Telegram:

теория → практика → вопросы → прогресс

Внутри:

1️⃣ 83 темы - от Linux и сетей до Kubernetes, CI/CD, Terraform, Observability, Cloud и Security
2️⃣ 166 практических заданий
3️⃣ 1245 вопросов по техническим темам и ситуациям с собеседований
4️⃣ Прогресс по каждой теме - видно, что уже знаешь, а что стоит повторить
5️⃣Шпаргалка команд - Docker, Kubernetes, Ansible, Terraform и другое
6️⃣Живой наставник - если застрял или не понял тему, можно обратиться за помощью

Часть тренажёра доступна бесплатно можно пройти диагностику и попробовать формат перед покупкой.

🥰DevOps Iron Pro - 3 590 ₽ / 30 дней

Полный доступ ко всем 83 темам, практике, вопросам, прогрессу и до 50 обращений к наставнику в месяц.

Оплата доступна прямо внутри бота через Профиль → Открыть полный доступ.

Никаких обещаний «станешь Senior за неделю».

DevOps Iron показывает твои слабые места и даёт достаточно практики, чтобы следующий вопрос на собеседовании уже не застал врасплох.

👉 @devops_iron_mentor_bot

🔥Radar - open-source UI для Kubernetes от Skyhook (YC W23). Один бинарник на Go, без регистрации и аккаунта, бесплатный навсегда. Топология кластера, браузер ресурсов, timeline событий, менеджер Helm-релизов, GitOps для FluxCD, карта трафика, аудит безопасности, анализ impact'а перед апгрейдом K8s и даже встроенный MCP-сервер, чтобы ИИ-агенты могли смотреть кластер глазами Radar вместо сырого kubectl.

https://habr.com/ru/articles/1073566/

ДИСК ПОЛОН, А МЕСТО ЕСТЬ 🤔

Бывало у тебя такое? df показывает 40% свободного места. Но при попытке записать файл система пишет: нет места на устройстве

Пиши inode/диск/linux в комментариях, если сталкивался 👇🤔

Дело в том, что место на диске и количество файлов, которые на нём можно создать - это два разных лимита

Каждый файл описывается структурой данных - inode. В нём хранятся права доступа, владелец, размер, время изменения, указатели на блоки данных. А вот имя файла в inode не хранится вообще — оно лежит отдельно, в каталоге, который просто сопоставляет имя номеру inode

Количество inode фиксируется один раз при форматировании файловой системы и потом не меняется. Это как склад с полками и отдельным журналом накладных: на полках места ещё хватает, но если накладные в журнале закончились — новый товар принять уже некуда

Именно поэтому, если на сервере скопились миллионы мелких файлов (например в кэше или временных сессиях), inode заканчиваются раньше, чем место в байтах

Проверяется одной командой:

df -i

Если там 100% — вот и причина. А обычный df -h будет невинно показывать свободные гигабайты

😵 Ловушка с собеса

Точно такая же ошибка вылезает и по другой причине: файл удалили, но какой-то процесс всё ещё держит его открытым. Место физически не освобождается, пока живёт хотя бы один файловый дескриптор:

lsof | grep deleted

И ещё деталь для полноты: на ext4 inode выделяются заранее и жёстко ограничены. А вот на XFS эта проблема практически не встречается — там inode создаются динамически прямо из общего пространства

👮‍♀️ Полную диагностику по темам вроде этой можно пройти в тренажёре - бесплатная часть доступна сразу

👉 @devops_iron_mentor_bot

🙌 СБОРКА ОБРАЗОВ: GO, PYTHON, JAVA. ЧТО РЕАЛЬНО ВАЖНО

Одна и та же ошибка кочует из проекта в проект: берут официальный образ языка и просто копируют туда весь код

В итоге получаем образ на 800 МБ с компилятором, кэшем сборки и кучей мусора, который в проде вообще никому не нужен

Разберём, как собирать нормально 👇

1️⃣ GO

Go здесь почти идеален для multi-stage build. На этапе сборки нам нужен весь toolchain, а в финальный образ можно положить только бинарник

FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux \
    go build -ldflags="-w -s" -o app

FROM scratch
COPY --from=builder /app/app /app
ENTRYPOINT ["/app"]

CGO_ENABLED=0 убирает зависимость от системных C-библиотек

-ldflags="-w -s" убирает отладочную информацию

В итоге вместо огромного образа получаем scratch + бинарник, который часто весит всего 5-20 МБ

⚠️ Но есть нюанс. Если приложение ходит по HTTPS наружу, ему могут понадобиться CA-сертификаты. В scratch их нет. Тогда можно использовать distroless или отдельно добавить сертификаты

2️⃣ PYTHON

С Python так радикально уменьшить образ не получится. Интерпретатор всё равно нужен в runtime

Но это не значит, что нужно тащить туда всё окружение сборки

FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir \
    --user -r requirements.txt

FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
USER 1000
CMD ["python", "app.py"]

Здесь главное:

slim вместо полного Python-образа

--no-cache-dir, чтобы не хранить кэш pip

Отдельный build stage

И приложение не должно работать от root просто потому, что так получилось по умолчанию

3️⃣ JAVA

Здесь очень частая ошибка ещё проще.

Для СБОРКИ нужен JDK

Для ЗАПУСКА приложения обычно достаточно JRE

Но иногда в production тащат целый JDK просто по инерции

FROM maven:3.9-eclipse-temurin-21 AS builder
WORKDIR /app
COPY . .
RUN mvn clean package -DskipTests

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=builder \
    /app/target/app.jar app.jar
USER 1000
ENTRYPOINT ["java", "-jar", "app.jar"]

Разница между JDK и JRE может означать сотни лишних мегабайт в образе

А что насчёт Alpine?

Для Java я бы не использовал его автоматически только потому, что он меньше

Если есть нативные зависимости через JNI, рассчитанные на glibc, с musl могут начаться неприятные сюрпризы

При этом сам JRE всё равно занимает прилично места, поэтому выигрыш от Alpine зачастую не настолько огромный, чтобы ради него усложнять себе жизнь

Чистое Java-приложение без нативных зависимостей? Alpine вполне можно рассматривать

Есть JNI или уже ловили странные проблемы? Обычный JRE-образ зачастую спокойнее

А если хочется выжать Java-образ ещё сильнее, можно смотреть в сторону jlink. Он позволяет собрать минимальный runtime только из тех модулей JVM, которые реально нужны приложению

Ещё одна полезная штука для Spring Boot — это layertools. Можно разделить приложение и зависимости на разные Docker-слои, чтобы при изменении кода не пересобирать и не перекачивать зависимости каждый раз

Что в итоге общего у Go, Python и Java?

Multi-stage build, чтобы build-инструменты не попадали в production

USER, чтобы приложение не работало от root

`.dockerignore`, чтобы .git, локальные конфиги и мусор не летели в build context

И фиксированные версии базовых образов вместо latest

Самая простая мысль здесь такая:

BUILD IMAGE ≠ RUNTIME IMAGE

И чем раньше это становится привычкой, тем меньше потом вопросов в духе:

«Почему наш микросервис весит 1.2 ГБ?» 😂

Если хотите прокачать Docker, Kubernetes, Linux и другие DevOps-темы на практике, всё это есть в тренажёре DevOps Iron

Бесплатная часть доступна сразу ❔

@devops_iron_mentor_bot