➡️ Лайв через 15 минут ⬅️

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

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

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

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

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к?🙃

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