Что спросить у работодателя на интервью?

Подготовил чек-лист вопросов, которые помогут понять, насколько компания и команда вам подходят.

➡️ О работе и проектах
- Как выглядит типичный день DevOps-инженера у вас?
- Какие актуальные боли в инфраструктуре или процессах нужно закрыть в первую очередь?
- Можете показать примеры задач, которые будут в моем бэклоге? (Например: поднять кластер k8s, настроить мониторинг, перевести деплой на GitOps?)

➡️ О развитии и грейдах
- Какие хардскиллы критичны для этой роли? (Terraform? Ansible? Golang?)
- Выделяется ли бюджет на курсы/сертификации (AWS, Kubernetes, etc.)?
- Есть ли карьерный трек от мидла до сеньора/архитектора?

➡️ О метриках и испытательном сроке
- Какие KPI будут в первые 3/6/12 месяцев? (Например: снижение downtime на 20%, автоматизация N% деплоев?)
- Что закроет испытательный срок? (Реальный пример: «Настроите CI/CD для двух сервисов»)

➡️ О команде и процессах
- Кто будет моим тимлидом/ментором?
- Сколько человек в команде? Как распределены зоны ответственности?
- Как устроен онколл? Есть ли компенсация за дежурства?

➡️ О культуре
- Как принимаются решения по инфраструктуре? (Советы архитекторов, голосование, единолично CTO?)
- Dev vs Ops — есть ли конфликты? Как вы их решаете?

➡️ Финал
- Нужны ли вам дополнительные данные от меня? (Ссылки на пет-проекты, разбор кейса?)
- Какие следующие шаги? Когда ждать фидбек?

Сохраните себе и не забудьте задать эти вопросы на следующем собеседовании.

#карьера

Коллеги, приветствую!

Вижу среди вас много новых подписчиков — добро пожаловать! Как насчет добить 5к?🙃

Хочу лучше узнать, кто находится по ту сторону экрана — чем вы занимаетесь, и на каком сейчас этапе. Ниже короткий опрос, жмите на свой вариант или напишите пару слов в комментариях ⬇️

Как развернуть HashiCorp Vault в Yandex Cloud

HashiCorp Vault — инструмент, который многие применяют, и сегодня я расскажу вам, как можно легко его развернуть в Yandex Cloud. Да, там его уже можно развернуть в ваш k8s просто выбрав из маркетплейса, но иногда хочется лучше.

➡️ В чем проблема развертывания Vault в k8s?

Vault хранит критичные секреты в зашифрованном виде, но после перезапуска требует ручную разблокировку (unseal). В k8s это рушит преимущества и наши любимые подходы автоматизации. Поэтому для того, чтобы автоматизировать этот процесс есть вариант развертывания еще одного «распечатывающего» Vault, и так можно значительно все усложнить. В Yandex Cloud есть KMS, и это поможет нам решить эту проблему.

🍀 За основу возьмем инструкцию для развертывания из маркетплейса:

1. Создаем сервис аккаунт
2. Создаем kms ключ
3. Назначаем сервис аккаунту роль для работы с kms

Чтобы поставить Vault из маркетплейса, нам больше ничего не нужно. Но так он развернется без души, то есть, без UI.

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

🍀 Чего в инструкции нет:

➡️ Нам потребуется заранее развернуть ALB контроллер, если он еще не был развернут в вашем кластере. Про это можно обсудить отдельно, но пока пропустим.

➡️ Создаем кластер postgres любым удобным способом: Если у вас terraform, то и пункты выше надо будет делать там, или можно к консоли сделать. Если у вас действительно стабильное решение и k8s уже распределен в разные зоны доступности, сделаем такой же postgres. Создаем также пользователя, базу.

➡️ Дальше по вкусу можно добавить сервис, чтобы вносить конкретный хост в конфиг, или что вам еще захочется. Добавим в секрет сертификат или возможно он там уже есть.

Сделал чарт, который может решить простую задачу: развернуть в Yandex Сloud HashiCorp Vault в отказоустойчивом варианте. Для этого взял чарт, который лежит в маркетплейсе, он является чуть измененным чартом для Yandex Cloud. Структуру немного поменял, убрал чарт в папку — мне так больше нравится, делать это необязательно.

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

1. Добавляю настройки для работы с ALB, так-же tls. Выключаю ненужное, включаю нужное. Настраиваю на использование с postgres.

2. Отдельным коммитом добавил ci — он совсем уж простой. Можете сделать любой удобный.

А теперь проверим вашу внимательность. Что я специально упустил? И какие еще решения можно считать спорными?

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

Весной мы с вами много говорили про карьеру в 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 на рынке труда. Если в нем хаос — что скажут о продакшене?

#карьера