TCP ПРОТИВ UDP: ЧТО РЕАЛЬНО СПРАШИВАЮТ🐸🐸

Видео грузится рывками, но никогда не виснет намертво. Файл либо скачался целиком, либо не скачался вообще. Это не совпадение, это два разных протокола под капотом

Пиши tcp/udp/handshake в комментариях, если работаешь с сетями 👇

1️⃣Тройное рукопожатие TCP

Перед передачей данных TCP устанавливает соединение. Клиент отправляет SYN, сервер отвечает SYN ACK, клиент подтверждает ACK. Только после этого стартует передача

2️⃣Надёжность и порядок

Каждый пакет TCP пронумерован. Пакет потерялся, получатель узнает и запросит его заново. Порядок всегда восстанавливается на приёмнике, даже если пакеты пришли вразнобой

3️⃣ Как работает UDP

Никакого рукопожатия. Отправитель просто шлёт пакеты. Потерялся пакет, никто его не пересылает

4️⃣ Кто что использует

Видеозвонок использует UDP, задержка важнее полноты. Скачивание файла использует TCP, там каждый байт обязан дойти

⚠️ Ловушка с собеса

У TCP есть контроль перегрузки сети, при перегрузке канала отправитель сам снижает скорость. У UDP такого контроля нет вообще

🍌 Заголовки: TCP примерно 20 байт, UDP всего 8 байт. Меньше служебных данных, меньше задержка


Практика: смотрим рукопожатие TCP вживую🥰

🔥Команда для перехвата трафика на порту 443, только флаги TCP, без данных:

tcpdump -i any -n 'tcp port 443' -c 20

Что увидишь в выводе:

IP client.54321 > server.443: Flags [S], seq 100
IP server.443 > client.54321: Flags [S.], seq 200, ack 101
IP client.54321 > server.443: Flags [.], ack 201

🔥Расшифровка флагов
[S] это SYN, [S.] это SYN ACK (точка после S как раз и означает ACK), [.] это чистый ACK без данных

Ровно три строки, ровно три пакета рукопожатия, prямо как в видео

Для сравнения, если перехватить UDP трафик:

tcpdump -i any -n 'udp port 53' -c 5

Там сразу пойдут пакеты с данными, без единого флага рукопожатия, потому что UDP его просто не делает

Ну что ж, июль получился очень продуктивным. 🚀

За этот месяц мои ребята получили 5 офферов с зарплатами от 250 000 ₽ до 465 000 ₽ net.

Самое приятное - практически все уже нашли работу и вышли на новые позиции. Очень рад за каждого. 💪

В августе хочу взять в работу ещё 5 человек и помочь им подготовиться к собеседованиям, собрать сильную легенду, подтянуть техническую базу и получить свой оффер.

Если давно хотел сменить работу или выйти на новый уровень по зарплате - напиши «➕»в чате. Посмотрим, смогу ли помочь именно тебе.👇

БЕСПЛАТНО ВОЗЬМУ 10 ЧЕЛОВЕК И ДОВЕДУ ДО ОФФЕРА 🎁

Повелся? 😆
Каждый раз, когда открываю сообщения, вижу одно и то же:

“А есть что-нибудь бесплатное?”

“А можно сначала попробовать?”

“А подешевле есть?”

И знаешь, что самое интересное?

Очень часто именно эти люди через год снова пишут:

“Я всё ещё не могу найти работу.”

Совпадение?

Не думаю.

Проблема не в деньгах.

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

Давай посмотрим на это с другой стороны.

Что ты покупаешь на самом деле?

Не видеозаписи.

Не созвоны.

Не чат.

Ты покупаешь возможность выйти на новую зарплату.

Ты получаешь:

• понятный маршрут без бесконечных “что учить дальше”;

• практику на задачах, максимально похожих на реальные проекты;

• подготовку к техническим собеседованиям;

• ревью резюме;

• поддержку человека, который уже прошёл этот путь и знает, где обычно ошибаются.

Если после этого ты начинаешь получать даже на 100-200 тысяч рублей больше, то стоимость обучения становится просто инвестицией.

Есть ещё один момент.

Я не заинтересован просто продать обучение.

Большую часть оплаты я получаю только тогда, когда ты доходишь до результата и получаешь оффер.

Получается, у нас одна цель.

Мне выгодно, чтобы ты устроился как можно быстрее.

Поэтому главный вопрос вообще не в цене.

Вопрос в другом.

Ты действительно хочешь изменить свою карьеру?

Или продолжаешь искать место, где обещают результат бесплатно?

Если ты готов работать, а не искать волшебную таблетку, пора решаться и не искать бесплатную помощь

Набор открыт до 5-ого августа.

SSH: ТЫ ЖМЁШЬ "YES" НА ПРЕДУПРЕЖДЕНИЕ, НЕ ПОНИМАЯ ЧТО ПРОИСХОДИТ 🍑

Заходишь на новый сервер. Терминал спрашивает про подлинность хоста. Ты жмёшь yes на автомате, как делают 99% инженеров

А зря. ⚡️Именно в этот момент SSH делает то, что защищает тебя от подмены сервера целиком

1️⃣ Как рождается общий секрет из воздуха

Клиент и сервер договариваются об общем секретном ключе по абсолютно незащищённому каналу. Каждая сторона независимо вычисляет одинаковый секрет. Подсмотревший обмен снаружи вычислить его физически не может

2️⃣ То самое предупреждение - не формальность

The authenticity of host '192.168.1.10' can't be established.
ED25519 key fingerprint is SHA256:xk3Jf9K7dQpL9mNc4Xr2vY8zQwEr...
Are you sure you want to continue connecting (yes/no)?

Это единственный момент, где ты доверяешь серверу наощупь. Отпечаток сохраняется здесь:

cat ~/.ssh/known_hosts

⚠️Ловушка с собеса

Если при повторном подключении отпечаток вдруг изменился, увидишь вот это:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Это не баг. Это SSH кричит, что кто-то мог подменить сервер между тобой и настоящей машиной

3️⃣ Почему пароль это вчерашний день

ssh-keygen -t ed25519 -C "твой_email@example.com"
ssh-copy-id user@server_ip

Приватный ключ никогда не покидает твою машину. Сервер присылает случайное число, ты подписываешь его приватным ключом, сервер сверяет подпись публичным. Ключ физически не передаётся по сети, а сервер точно знает, что он у тебя есть

4️⃣ Чтобы не вводить пароль от ключа каждый раз

eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519

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

❓ Что чаще всего спрашивают на собесе

1. Как SSH устанавливает общий секрет по незащищённому каналу
2. Зачем нужен отпечаток ключа хоста
3. Чем аутентификация по ключу отличается от пароля
4. Что защищает от атаки посредника
5. Как работает ssh-agent

😵‍💫Твой телефон прямо сейчас может делить один IP-адрес с тысячами незнакомых людей.

Звучит странно? Если ты сидишь с мобильного интернета, вероятность очень высокая.
Большинство думает, что у каждого устройства есть свой уникальный IP-адрес. На самом деле это давно не так.
Представь обычную квартиру. Дома у тебя есть ноутбук, телефон и телевизор. Например:

💻 Ноутбук - 192.168.0.10

📱 Телефон - 192.168.0.15

📺 Телевизор - 192.168.0.20

Каждое устройство получает свой IP только внутри домашней сети.
Но как только они выходят в интернет, роутер делает NAT (Network Address Translation) - заменяет все внутренние адреса на один общий публичный IP.

Получается, что три разных устройства для всего интернета выглядят как одно.
Но возникает вопрос: как роутер понимает, кому вернуть ответ?
Очень просто. Он создаёт таблицу соответствий.

Например:

192.168.0.10:52341 → 95.25.143.18:41001

192.168.0.15:60124 → 95.25.143.18:41002

192.168.0.20:49812 → 95.25.143.18:41003

Когда сервер отвечает на адрес 95.25.143.18:41002, роутер понимает, что эти данные нужно отправить телефону, а не ноутбуку или телевизору.

🤯 А теперь самое интересное.

Домашний роутер это только начало.
Мобильные операторы используют технологию Carrier-Grade NAT (CGNAT).
Это означает, что тысячи людей могут одновременно выходить в интернет через один и тот же публичный IP-адрес.

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

Поэтому один публичный IP совсем не означает одного пользователя.
Проверить это очень просто.

1️⃣Локальный IP:

ip addr

или

ipconfig

2️⃣Публичный IP:

curl ifconfig.me

или

curl ipinfo.io/ip

Если локальный адрес начинается с 192.168.x.x, 10.x.x.x или 172.16–172.31.x.x, а публичный IP совсем другой между тобой и интернетом работает NAT.
Именно из-за NAT иногда невозможно открыть порт, возникают проблемы с домашними серверами и VPN, а один IP может принадлежать сразу тысячам пользователей.

🔥 А ты знал, что мобильный оператор может выдать один публичный IP сразу тысячам людей?

🔫БАЗА ВСТАЛА ПОД НАГРУЗКОЙ: КАК НАЙТИ, КТО КОГО БЛОКИРУЕТ В POSTGRESQL

CPU свободен. Диск свободен. А база не отвечает

Знакомая ситуация: запросы вроде те же, что вчера, а сегодня всё стоит. База не работает, она ждёт — и если не знать, куда смотреть, диагностика превращается в гадание

Пиши postgres/locks/deadlock в комментариях, если сталкивался 👇

Главное, что нужно запомнить

Блокировка живёт не до конца запроса, а до конца транзакции. Взяла блокировку на строку, потом полминуты делала что-то ещё, ходила во внешний сервис — всё это время держит. Блокировки сами по себе быстрые, держат их долго именно длинные транзакции

1️⃣ Кто кого блокирует

Первое, что нужно узнать: кто на кого ждёт

SELECT pid,
       pg_blocking_pids(pid) AS blocked_by,
       wait_event_type,
       query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Слева процессы, которые ждут, справа те, кто им мешает. Один и тот же PID справа у многих строк — вот он, корень

Дальше смотрим, чем занят этот процесс:

SELECT pid,
       now() - xact_start AS xact_age,
       now() - query_start AS query_age,
       state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE pid = <тот_самый_pid>;

Состояние объясняет, с какой из проблем ты столкнулся

2️⃣ Idle in transaction — самая обидная причина

Транзакция открыта, блокировки взяты, а процесс ничего не делает. Обычно приложение сделало BEGIN, выполнило пару запросов, и ушло куда-то не в базу: вызов внешнего API, обработка в коде, а то и вовсе застряло на ошибке без COMMIT

База при этом полностью здорова, просто ждёт, пока приложение вспомнит закрыть транзакцию. Признак железный: xact_age растёт, query_age нет

Лечится сужением транзакции. И есть страховка на сервере:

idle_in_transaction_session_timeout = '30s'

3️⃣ Долгая транзакция, которая реально работает

Здесь state = 'active', запрос честно выполняется, просто долго. Тяжёлый отчёт, миграция, аналитика на пол-таблицы

Классика, которая валит базы: кто-то запускает ALTER TABLE на большой таблице. DDL не может взять блокировку сразу, потому что таблицу читает долгая транзакция. Он встаёт в очередь. А за ним встают уже все остальные запросы к таблице, потому что новые не могут проскочить вперёд ожидающего DDL

Одна читающая транзакция плюс один ALTER парализуют весь доступ к таблице, хотя по отдельности ни то, ни другое базу бы не остановило

Лечится коротким таймаутом на захват блокировки для DDL:

SET lock_timeout = '2s';
ALTER TABLE orders ADD COLUMN note text;

Не взял блокировку за 2 секунды — упал с ошибкой, а не встал в очередь на полчаса

4️⃣Конкуренция за одни и те же строки

Ни забытых, ни особо длинных транзакций, просто много коротких дерутся за одну строку. Классика — счётчик, который инкрементят из сотни соединений разом:

UPDATE counters SET value = value + 1 WHERE id = 1;

Каждая транзакция быстрая, но выстраиваются в очередь, и под нагрузкой это становится узким местом. Диагностика другая — смотрим агрегированно:

SELECT wait_event_type, wait_event, count(*)
FROM pg_stat_activity
WHERE wait_event_type IS NOT NULL
GROUP BY 1, 2
ORDER BY 3 DESC;

Много Lock наверху — разносим горячие данные на несколько строк, суммируем при чтении

5️⃣ SELECT, который блокирует запись

SELECT * FROM orders WHERE id = 42 FOR UPDATE;

FOR UPDATE берёт блокировку, как будто строку уже обновляют. Ставят часто на всякий случай, а держится она до конца транзакции. Хуже, если попадает в запрос без LIMIT — залочит все возвращённые строки разом

Если строгая блокировка не нужна, есть более мягкий FOR SHARE. А часто оказывается, что блокировка вообще не нужна

KubeDiagrams - прикольная open source штука, которая сама рисует схемы k8s

На вход можно дать YAML, Helm, Helmfile, Kustomize или даже живой кластер. На выходе получаешь диаграмму

CRD понимает, экспортит в PNG/SVG/PDF/draw.io

Для доки, онбординга и быстрого разбора "что у вас тут происходит" выглядит полезно 🧃

https://github.com/philippemerle/KubeDiagrams

Эйчары начали просить время рождения в резюме — чтобы составлять натальные карты кандидатов и оценить человека ещё до собеседования 😭

DEVOPS В РОССИИ 2025: ЦИФРЫ, КОТОРЫЕ СТОИТ ЗНАТЬ 💳

Свежий опрос российских DevOps-инженеров. Разберём подробно, с цифрами, потому что за этими процентами реально видно, куда двигается индустрия.

1️⃣ Топовые команды оторвались от середняков

Доля Elite-команд выросла на 4%, High на 2%. Суммарно топ-профили прибавили 6% за год.

А вот что интересно: разрыв виден не только в релизах, но и в том, как разработчики оценивают свою же работу. Спросили инженеров, согласны ли они с утверждением "обратная связь оперативна, я всё ещё в контексте задачи":

Low — 70,0%
Medium — 80,8%
High — 83,3%
Elite — 85,1%

А с формулировкой "обратная связь информативна и помогает исправить ошибки":

Low — 76,4%
Elite — 89,6%

Разница в 13 процентных пунктов на одном и том же вопросе. Это не про мотивацию людей, это про то, как в команде устроены циклы обратной связи.

2️⃣ Инфобез это теперь часть пайплайна, а не отдельный отдел

75% инженеров используют метрики ИБ в работе, 40% говорят, что инструменты безопасности встроены прямо в CI/CD.

Но внедрение ИБ даётся не бесплатно. Топ проблем, с которыми сталкиваются команды:

45,5% — не хватает технической экспертизы у команды внедрения
42,3% — проблемы совместимости с текущими системами
41,0% — высокая стоимость
36,5% — обучение персонала
33,9% — избыточные алерты и ложные срабатывания
19,6% — vendor lock, зависимость от одного поставщика

Меньше всего боятся правовых и регуляторных требований (18%). Больше всего, буквально каждый второй, боится того, что команда просто не потянет внедрение технически.

3️⃣ ИИ используют 71,3%, но толку от него по-разному

Свой уровень в промпт-инжиниринге инженеры оценивают так:

Новичок — 21,8%
Любитель — 45,7%
Опытный — 27,8%
Гуру — 4,7%

Гуру, разумеется, меньшинство. Но именно они отмечают наибольший прирост личной и командной эффективности от ИИ. То есть навык работы с промптами буквально конвертируется в пользу, а не просто "у меня есть Copilot, стало быстрее".

Ловушка с собеса 🍑

Какие четыре метрики считаются мировым стандартом для оценки производительности DevOps-команды?

Deployment Frequency — частота деплоев
Lead Time for Changes — срок поставки изменений
Mean Time to Recovery — время восстановления после инцидента
Change Failure Rate — доля неудачных изменений

Это DORA-метрики. По ним, собственно, и делят команды на Low, Medium, High и Elite из первого пункта.

Индустрия взрослеет, а разрыв между теми, кто выстроил процессы, и теми, кто нет, увеличивается с каждым годом.

#devops #sre #dora #devopsинженер #ит #собес #ci_cd #backend #ии

ЧТО ДУМАЮТ О DEVOPS HR VS КАК ЭТО НА САМОМ ДЕЛЕ 🤔

Между тем, что пишет HR в вакансии, и тем, что реально происходит внутри компании, обычно пропасть в несколько этажей. Пройдёмся по всей воронке найма - от текста вакансии до оффера.

1️⃣ Текст вакансии

Кажется: ищут супергероя, который знает Kubernetes, Terraform, Ansible, Prometheus, три облака и Python на уровне синьора.

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

2️⃣ Отбор резюме

Кажется: резюме читает живой человек и оценивает опыт целиком.

На самом деле: в крупных компаниях первый фильтр — автоматическая система, которая ищет буквальные совпадения слов из вакансии. Если в вакансии написано «Kubernetes», а у тебя в резюме «k8s», система может тебя просто не увидеть.

Практический вывод: дублируй ключевые термины из вакансии дословно. Это не читерство, это работа с реальностью системы отбора.

3️⃣ Звонок с HR

Кажется: HR должен разбираться в том, что такое readinessProbe или Error Budget.

На самом деле: его задача — не техническая экспертиза, а проверка софт-скилов и базовых рамок: зарплата, формат работы, готовность к переезду. Если ты на этом звонке начинаешь спорить о деталях Kubernetes — просто теряешь время обоих.

4️⃣Техническое интервью

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

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

5️⃣Оффер и зарплата

Кажется: вилка в вакансии — это то, что ты гарантированно получишь.

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

😵‍💫Отдельно про отказы

Отказ - это не приговор твоему уровню. Чаще всего это про несовпадение с конкретной командой прямо сейчас. Видел сильного кандидата, которого не взяли, потому что искали человека именно под легаси-зоопарк технологий, а не потому что он был плох.

Что реально решает на всех этапах 😵‍💫

Понятная история в резюме с ключевыми терминами из вакансии, чёткие ответы без воды на техническом интервью, и адекватность в общении. Все три вещи бесплатны и не требуют пятнадцати сертификатов.

А тебе попадались вакансии или отказы, которые явно писал не технарь?
#devops #hr #собес #devopsинженер #резюме #карьера #ит #трудоустройство

НАВЫКИ, КОТОРЫЕ РЕАЛЬНО ПРОДАЮТСЯ В DEVOPS В 2026 ГОДУ 🖐

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

Что умерло👌

Просто уметь Docker это уже не навык, а гигиенический минимум, как уметь пользоваться почтой.
Jenkins как основной инструмент в резюме сегодня скорее красный флаг, чем плюс - индустрия давно ушла в GitHub Actions и GitLab CI.
Пачка сертификатов без единой реальной истории за спиной впечатляет только того, кто их выдал.
А знание пятнадцати инструментов по верхам работает против тебя — на собесе такого человека раскалывают за три вопроса вглубь.

А что реально продаётся 👏

➕ Kubernetes не на уровне туториала, а с пониманием, как он себя ведёт в проде. Сеть, хранилище, поведение под нагрузкой, апгрейд без даунтайма.

2️⃣ Observability. Не просто поставить Prometheus и Grafana, а собрать метрики так, чтобы по ним реально принимали решения, а не просто смотрели красивые дашборды.

3️⃣ GitOps. Компании физически устали от ручных деплоев через ssh и хотят декларативный подход через ArgoCD или Flux.

4️⃣ Terraform на серьёзном уровне - с модулями и нормальным управлением стейтом, а не один файл на триста строк.

5️⃣ Понимание надёжности: SLO, Error Budget, работа с постмортемами после инцидентов.

Показательный пример ☝️

Два кандидата с одинаковым стажем в три года.
Один пишет в резюме: знаю Docker, Kubernetes, Terraform, Ansible, Jenkins, Prometheus.
Второй пишет: снизил время деплоя с сорока минут до шести за счёт перехода на GitOps, и сократил количество инцидентов на треть после внедрения нормальных SLO.

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

Короче

Рынок устал от людей, которые всё попробовали, но ничего не довели до конца. Сейчас продаётся не ширина, а глубина плюс умение объяснить, что именно ты изменил.

А какой навык, по-твоему, уже потерял вес за последний год? Пиши в комментариях.


#devops #sre #kubernetes #gitops #devopsинженер #ит #собес #резюме #карьера

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

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

Работает в 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 можно буквально ПРОХОДИТЬ как игру, вам интересна - накидайте 🔥