Честные вакансии: второму сезону быть

Весной мы с вами много говорили про карьеру в DevOps с экспертами из бигтеха и подробно разбирали требования индустрии со стороны работодателя.


🍀 Сейчас мы планируем запуск второго сезона, и хотим поговорить с вами — нашими студентами и подписчиками. Мы ищем DevOps-инженеров, которые готовы поделиться внутрянкой своей работы и рассказать про:

⭐️ грейд;
⭐️ обязанности;
⭐️ зарплатную вилку (можно с шагом 100 000₽).

Если вы не хотите или не можете по договору называть место своей работы, то и не нужно — для нас в первую очередь важна информация о зарплате и обязанностях.

➡️ Формат участия: короткое (примерно 15 минут) интервью под запись.
Ведущим второго сезона будет Сева Севостьянов, Staff engineer в Lokalise и спикер курсов Слёрма.

⭐️ Интервью пройдет в формате карьерной консультации — Сева будет задавать вам вопросы, подсветит ваши навыки и подскажет, куда двигаться дальше.

Интервью будут смонтированы и опубликованы на всех наших площадках.

Хотите стать частью проекта? Напишите Кате в телеграм, чтобы узнать подробности. Ждём ваших откликов!

#devops_middle

Зачем DevOps-инженеру мониторинг, если всё и так работает?

🍀 обсуждаем сегодня на бесплатном вебинаре!

Вместе со Станиславом Левиным, Senior DevOps\SRE, underlay kubernetes infra team мы обсудим:

➡️ Как выбрать мониторинг под свой проект
➡️ Что используют крупные компании
➡️ Нужен ли сложный мониторинг всем
➡️ Зачем DevOps-инженеру понимать, что важно бизнесу и как это мониторить
➡️ Типовые ошибки при внедрении мониторинга

Стартуем в 19:00. Ссылки на трансляцию, как всегда, будут в боте.

Всех жду!

⭐️Стартуем через 5 минут⭐️

Подключайтесь!

3 вопроса рекрутеру, которые спасут вас от токсичной компании в DevOps

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

👉 Как вычислить адскую текучку до того, как подпишете оффер? Задайте эти три вопроса:

1. «Как у вас проходит онбординг DevOps-инженеров?»
Если адаптация — это «разбирайтесь сами в наших 200 терраформ-модулях», бегите. В нормальных компаниях новичков не бросают в бой без подготовки.

🚩 Тревожные звоночки:

«У нас гибкий подход — коллеги помогут» (читай: никто ни за что не отвечает)

«Обычно инженеры быстро вливаются» (потому что те, кто не влился, ушли через месяц)

✅ Хороший ответ:
«Первые две недели — погружение в инфраструктуру и CI/CD, доступ к документации и ментору. Через месяц — проверочный проект (например, настроить мониторинг для тестового сервиса). Наставник сопровождает первые 3 месяца».

2. «Как изменился ваш DevOps-отдел за последний год?»
Резкий рост или сокращение — красный флаг.

🚩 Подозрительно:

«Команда выросла с 3 до 20 человек за квартал» → вероятно, админы превращаются в пожарных.

«Было 10 инженеров, осталось 4» → либо автоматизировали всё, либо бюджет режут, а выгорание растет.

✅ Адекватный вариант:
«Расширились с 5 до 8 человек — взяли еще двух SRE под нагрузку на k8s» или «Состав тот же, но перешли с самописных скриптов на ArgoCD и сократили рутину».

3. «Какие возможности для роста у DevOps в вашей компании?»
Если в ответе только «учитесь сами» — значит, карьера зависит только от вашего упорства (и везения).

🚩 Шляпа:

«У нас плоская структура, но можно прокачиваться» (но как? за чей счет? куда?)

«Карьера зависит от инициативы» (то есть никаких гарантий)

✅ Что хотим услышать:
«Раз в полгода — performance review с roadmap: например, переход от поддержки к архитектуре облака. Есть бюджет на сертификации (CKA, AWS) и внутренние митапы».

Если рекрутер туманно отвечает на эти вопросы — в компании либо хаос, либо менеджмент не ценит специалистов. А вам это надо?

🚨 Код красный: Аэрофлот атакован, небо — под вопросом

Работа авиакомпании «Аэрофлот» полностью парализована из-за взлома IT-систем. Отменены десятки рейсов, компьютеры в офисах и аэропортах выключены, корпоративные аккаунты заблокированы, работа идёт вслепую.

Группа хакеров Silent Crow взяла на себя ответственность, заявив, что они в течение года внедрялись в систему и устроили масштабную диверсию: уничтожили 7000 серверов и выгрузили более 22 Тб информации, от баз клиентов до внутренней почты, аудиозаписей совещаний и доступа к системам слежения за персоналом.

С момента падения прошло уже 4 часа, но критические сервисы до сих пор не ожили. Кажется, настало время задуматься о безопасности своих проектов…

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

⭐️ Видеокурс «Основы информационной безопасности»: учимся делать безопасный прод, обеспечивать секьюрность на самых начальных этапах и менять майндсет коллег.

Сейчас со скидкой 50% по промокоду LETO2025

⭐️ Интенсив «DevSecOps Bootcamp: безопасность для бизнеса»: 4 дня теории и неделя практики, чтобы выстроить единый подход к безопасности — от кода до эксплуатации — и внедрить его в процессы без потерь в скорости и качестве.
Старт интенсива — 11 октября.

Безопасность — это не набор инструментов для «галочки». Это культура и осознанный подход к выстраиванию процессов.

Сборка Docker-образов в 2025: Почему Kaniko уступает место другим инструментам

Эволюция сборки образов: Что изменилось?

Сборка Docker-образов давно вышла за рамки простого docker build. Требования к безопасности, мультиархитектурности (arm64/amd64), необходимость в скорости и воспроизводимости заставляют пересматривать инструменты. Kaniko, когда-то популярный за свою безопасность и то, что он не требует демона Docker, теперь теряет позиции. Почему?

Kaniko всегда имело определенные сложности:

➡️ Скорость сборки
Kaniko не поддерживает распределённое кеширование слоёв из коробки. При больших образах сборка выполняется дольше, чем у инструментов на базе BuildKit

➡️ Ограниченная мультиплатформенность
Для сборки под arm/amd нужны сложные костыли. В эпоху гибридных сред (AWS Graviton, Apple Silicon) это критично

➡️ Отладка
Логи Kaniko менее детализированы при ошибках

➡️ Сложность интеграций
Может требовать специфических настроек Kubernetes (например, монтирование Volume). В serverless-средах (GitHub Actions, GitLab CI) это избыточно.

Но появились новые сложности и репозиторий в архиве, почти 2 месяца назад.

Внедрять Kaniko на новые проекты смысла нет, и скорее всего лучше переводить с него старые.

Gitlab рекомендует использовать Dind (опять?) или использовать другие варианты.

🍀 Buildah — инструмент для бесдемонный сред.

В чем плюсы:

➡️ Безопастность
Не требудет docker демона, rootless сборка

➡️ Гибкость
Тонкий контроль работы над слоями. Монтирование контейнера при сборке

➡️ Совместимость
Работает и с Podman и в Kubernetes

Собирать мультиплатформенные сборки можно за счет ci. И тут можно посмотреть сам синтаксис.

Или рассмотрим другой интрумент:

Docker Buildx + BuildKit

➡️ Быстрая сборка
Кеширование слоев, параллельное выполнение инструкций

➡️ Мультиархитектурность
Один ключ
--platform linux/amd64,linux/arm6
создает мультиплатформенный образах

➡️ Безопастность
rootless режим, секреты при сборке

➡️ Экосистема
Инструмент Docker и нативная поддерка

Инструкции от gitlab и  отдельно как выполнить миграцию с Kaniko.

Это не все варианты которые работают несколько иначе. Есть Earthly, но тоже остановлена разработка. Можно использовать и Dagger. Но я так не пробовал, мне кажется в случае проблем с ним будет перейти сложнее чем с Kaniko.

Kaniko был революционным инструментом в 2018-2023, но в 2025 окончание его поддержки и наличие других инструментов изменили подходы

А расскажите что используете вы, на что перешли с Kaniko (если уже перешли).

DevOps про деньги: пилотный выпуск доступен к просмотру!

В первом сезоне я встречался с эйчарами и тимлидами из бигтеха. Теперь же мой коллега, Сева Севостьянов, поговорит про внутрянку со стороны сотрудников.

Специальный гость пилотного выпуска — Виталий Лихачев, SRE в крупнейшем голландском тревелтехе и эксперт по k8s. Что в интервью:

➡️ Какие навыки нужны SRE в бигтехе?
➡️ Требования в вакансии vs реальные рабочие задачи: есть ли разница?
➡️ Главный вопрос: сколько получает SRE в Амстердаме?

В дальнейшем Сева будет встречаться с другими экспертами, задавать им разные каверзные вопросы, чтобы в конце концов составить понимание о том, чего хотят компании от DevOps и SRE, и сколько готовы платить.

Посмотреть пилотный выпуск:
🪩YouTube
🪩Rutube
🪩VK Видео

Новости проекта, расписание встреч и полезные материалы от экспертов — как всегда, в боте.

Резюме в DevOps: как не слить свою эксперность еще до собеса

Обсуждали это с вами на лайве, хочу продублировать текстом, чтобы можно было сохранить.

Вы можете качать Kubernetes одной левой и разворачивать кластеры во сне, но если в резюме это выглядит как «участвовал в DevOps-процессах» — Ваш шанс сливается в /dev/null.

Рассказываю, что чаще всего убивает даже сильных кандидатов в DevOps:

↘️ «Участвовал в настройке CI/CD» → А что именно делали? Какие метрики улучшили? «Нам важно не просто действие, а результат: например, сократили время сборки с 15 до 2 минут»

↘️ Дыры в датах → Год фриланса без пояснений? Релокейт? Стартап? Без четкой истории — HR начнет копать

↘️ Шаблонные «скиллы» → «Ответственный, стрессоустойчивый» — это пустой шум. Лучше напишите, как Вы под дедлайном мигрировали продакшн без даунтайма или локализовали баг в Terraform за час

Как исправить?
↗️  Пишем только релевантный опыт. Нужны детали: «Оптимизировали AWS-инфраструктуру, сократив costs на 30%», а не «работал с облаками»
↗️  Без воды — клише вроде «командный игрок» не работают. Пишите действия и результат: «Автоматизировали деплой для 500+ сервисов, убрав 80% рутины»
↗️ Конкретика вместо абстракций → Не «пользовался мониторингом», а «настроили Prometheus + Grafana, снизив MTTR с 4 часов до 25 минут»
↗️ Использовать стандартную форму описания опыта: описание задачи → как решали → к какому результату пришли

Резюме — это Ваш helm chart на рынке труда. Если в нем хаос — что скажут о продакшене?

#карьера