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

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

Работает в 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