Как оценить компанию по вакансии?

Вчерашний лайв натолкнул меня на мысль об очередном посте с тегом #карьера

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

1. Описание компании

Чем проще и яснее описан продукт или сервис — тем лучше.
✅ «Разрабатываем SaaS-платформу для CI/CD с Kubernetes» — ок.
🚩 «Инновационные IT-решения для цифровой трансформации» — мутно.

Проверьте: есть ли у компании нормальный сайт, стек технологий в открытых источниках (GitHub, LinkedIn, Хабр Карьера). Если гуглится только реклама и шаблонные фразы — тревога.

2. Задачи в вакансии

Хорошая компания знает, какой именно инженер ей нужен.
✅ «Настройка Terraform, автоматизация развертывания в AWS, мониторинг через Prometheus/Grafana» — конкретно.
🚩 «Работа с облачными сервисами и поддержка инфраструктуры» — слишком размыто.

Даже если задачи засекречены под NDA (например, из-за специфики продукта), описание в общих чертах все равно должно быть.

3. Этапы отбора

Прозрачность = признак отлаженных процессов.
✅ «Скрининг → тех. интервью → тестовое → финал с CTO» — ок.
🚩 «Сначала поговорим, потом посмотрим» — хаос.

Для DevOps это особенно важно: если в найме бардак, вероятно, и в инфраструктуре тоже.

4. Зарплатная вилка

Компания, которая сразу пишет «от $3000 до $5000» — редкий бриллиант.
🚩 «Зарплата по результатам собеседования» = «Попробуем вас прожать».

DevOps-роли требуют конкретики: вы же не настраиваете сервера «как договоримся».

5. Сроки обратной связи

✅ «Дадим ответ в течение 7 дней» — уважение к кандидату.
🚩 «Если не перезвонили — значит, не подошли» — плохой тон.

Хорошая вакансия — как хороший CI/CD-пайплайн: прозрачный, предсказуемый и без скрытых ошибок.

Всех, кто ответил неправильно (или колебался при выборе ответа), приглашаю на курс Слёрма «Docker для админов и разработчиков».

Чему вы научитесь:

➡️ Использовать Docker для разработки микросервисов
➡️ Упаковывать в Docker образы приложения, основанные на разных языках
➡️ Управлять сетями в Docker
➡️ Обеспечивать безопасность ваших контейнеров
➡️ Контролировать контейнеры и образы с помощью Docker CLI

В конце курса вы попробуете себя в роли дежурного инженера, отвечающего за внутренний Docker-сервер компании.

Это не продакшен, но задачи — вполне реальные: обеспечить рабочую среду для разработчиков, разобраться с контейнерами, восстановить процессы, если что-то пошло не так.

Старт — 21 июля. Подробности ➡️ на странице курса.

Почему возникает путаница с auth_config.json?

Да, коллеги, я тоже ошибся. Спасибо, что заметили! Подумаю насчет курса по докеру 😅

Термин auth_config часто упоминается в документации Docker API как структура данных (не файл!). В Docker SDK (Python/Go) объект auth_config используется для передачи логина/пароля программно.

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

➡️ В итоге:
Для повседневного использования (CLI): данные хранятся только в ~/.docker/config.json. Правильный вариант — третий.

Файл auth_config.json — это всегда ручная кастомная реализация (например, для скриптов или CI). Docker CLI его автоматически не создаёт и не читает.

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

В проектах вопросы мониторинга часто откладываются на потом, но по важности эти процессы точно одни из первых. Мы делаем мониторинг и логирование не для того, чтобы узнать о проблеме ночью и быстрее починить, а для того чтобы коллеги SRE и разработчики быстрее получали фидбек о том, что приложение изменило свое поведение.

⭐️ 23 июля приглашаю вас на вебинар, на котором будем обсуждать:

➡️ Как выбрать мониторинг под свой проект: от простых решений до продвинутых систем — поэтапный разбор на реальных кейсах

➡️ Что используют крупные компании: подход к мониторингу в распределённых командах и на общих ресурсах (по опыту спикера)

➡️ Нужен ли сложный мониторинг всем: обсуждаем, кому подойдёт простой стек, а где без Kafka, Prometheus и алертов не обойтись

➡️ От логов к бизнес-индикаторам: зачем DevOps-инженеру понимать, что важно бизнесу и как это мониторить

➡️ Типовые ошибки при внедрении мониторинга: что ломает стабильность, и как не утонуть в алертах

Специальный гость: Станислав Левин, Senior DevOps\SRE, underlay kubernetes infra team

Когда: 23 июля в 19:00 мск

➡️ Занять место на вебинаре — через бота.

Неочевидные проблемы Kubernetes, которые вы могли пропустить

↘️ бесплатный вебинар через 15 минут.

Ведущий: Виталий Лихачев, SRE в крупнейшем голландском тревелтехе
Спикер: Руслан Гайнанов, главный инженер DevOps, T1 Иннотех

Вместе они разберут типовые ошибки, которые можно допустить при деплое сервисов в кластер, от некорректной настройки лимитов ресурсов, до более сложных кейсов с admission webhooks.

🟠 В конце вебинара — рекомендации по настройке вашего кластера и приложений для безотказной работы.

Когда: 16 июля в 19:00 мск

➡️ Занять место на вебинаре — через бота.

Если пайплайн всегда зеленый, это не значит, что он эффективный.

На что стоит смотреть в первую очередь:

🪩 Узкие места

Сколько длится build? Какие тесты можно распараллелить? Какие шаги убрать?

🪩 Скрытые риски

Есть ли rollback на случай, если прод рухнет? Что будет, если закончатся лимиты раннеров?

Другие важные нюансы:
➡️ Сборка и деплой должны быть отделены
➡️ Переменные окружения и секреты не должны хардкодиться
➡️ Конфиги должны быть читаемы и понятны
➡️ Обязательно присутствие промежуточных проверок, а тесты должны запускаться без полного прогона пайплайна

В хорошем пайплайне новый разработчик разберется без месячного онбординга.

Как сделать пайплайн поддерживаемым, а процесс быстрым и предсказуемым, рассказываю на CI/CD-практикуме — начать учиться можно в любой момент.

Подробности — по ссылке.

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

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

➡️ О работе и проектах
- Как выглядит типичный день 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) и внутренние митапы».

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