📚 3 книги по Linux для DevOps-инженера

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

1. Linux Pocket Guide - Daniel Barrett

Не для чтения от корки до корки. Открываешь когда забыл флаг у grep или как работает chmod. Файловая система, SSH, процессы, права доступа, sed/awk всё коротко и по делу. Лежит открытой на второй вкладке.

2. How Linux Works - Brian Ward

Вот эту читаешь именно как книгу. Объясняет что происходит когда ты включаешь сервер: загрузка, ядро, systemd, сеть, память. После неё перестаёшь угадывать начинаешь понимать.

3. The Linux Command Line William Shotts

Если терминал до сих пор вызывает дискомфорт начни отсюда. Bash, пайпы, перенаправление, простые скрипты.

Все три на английском это нормально. Большинство документации тоже на английском, лучше привыкать сразу. При желании можно найти перевод, ссылки давать к сожалению не могу.

#linux
#library

5 огней и дополню файлик ответами

30 огней собрали, ура!
Полный сборник вопросов по Linux с собеседований, забирайте и проходите успешно собесы!

Формат: 🗣 Устный ответ → 💡 Запомни → 💻 Код → ⚠️ Ловушка

так же в md формате чтобы не терять

#linux
#library

Мнения разделились 50 на 50, поэтому делаю пост + видео:



🔴 Почему в IT стало так сложно найти работу?

Кто хочет послушать, а не читать - https://www.youtube.com/watch?v=0qPi7yJfDdQ

Я собрал открытые данные рынка труда, зарплатные исследования и большие выборки вакансий за 2025-2026 год. Не мнение - цифры.

На одну вакансию для новичков сейчас приходит около 7 резюме. В целом по рынку 12 и больше. При этом компании говорят, что не могут найти нужных людей. Обе стороны правы.

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

Новичков много. Тех, кто знает слова Docker, Kubernetes и Terraform, тоже. Но компании ищут не знание слов. Им нужен человек, которому можно доверить боевой сервис: разобраться в инциденте ночью, не уронить кластер при обновлении, выкатить деплой так, чтобы пользователи не заметили.

📉 Для джуниоров рынок стал жёстче. Позиций, где готовы долго обучать с нуля, стало меньше. AI забирает часть рутинных задач, на которых раньше учились новички. Входная планка выросла.

⏳ Воронка найма удлинилась. HR-скрининг, техническое интервью на 60-90 минут, поведенческая секция, system design, финал с менеджером. На серьёзные позиции процесс растягивается на месяц. Топ жалоб кандидатов: нет обратной связи, слишком много этапов, тестовое выполнил — получил отказ без объяснений.

💰 По зарплатам: Middle DevOps по медиане 150-280 тысяч. Senior уходит выше 350-500 тысяч. Финтех и маркетплейсы платят на 40-60% выше среднего, потому что цена ошибки там другая.

🏢 Удалёнки стало меньше. 77% российских компаний вернули команды в офис или гибрид. Полная удалёнка сократилась до 7%. Гибкость остаётся у тех, кто редкий и сильный.

🤖 AI не убил рынок, но поднял планку. Простые задачи автоматизируются. Рутина стоит меньше. Ответственность, production-мышление и умение работать с инцидентами стоят больше.

Рынок IT не умер. Изменились правила. Компании платят не за список технологий в резюме, а за способность брать ответственность и приносить результат.

Следующий выпуск: Roadmap DevOps на 2026 год. Не по курсам, а по тому, что действительно ищут компании.

#resources
#career

Свежие вакансии, заодно можно рыночек оценить, так себе конечно)

1. System Administrator — Центурион-Инновации
middle · 195 000 ₽ · офис Москва
→ [Habr](https://career.habr.com/vacancies/1000167435)

2. Systems Engineer — Alber Blanc
senior · 380 000 ₽ · офис Лимасол
→ [Alberblanc](https://alberblanc.com/careers/senior-network-systems-engineer-521/)

3. DevOps Engineer — Сбер
intern · от 60 000 ₽ · гибрид Питер
→ [Hirehi](https://hirehi.ru/devops/devops-inzhener-57844)

4. Site Reliability Engineer — Яндекс Финтех
middle · 282 000 ₽ · удалёнка
→ [Hirehi](https://hirehi.ru/devops/site-reliability-engineer-58042)

5. Системный инженер — ASTON
middle · 175 000 ₽ · удалёнка
→ [Hirehi](https://hirehi.ru/devops/sistemnyi-inzhener-57152)

6. Системный инженер — Сбер
middle · 165 000 ₽ · офис Чебоксары
→ [Rabota](https://rabota.sber.ru/search/starshiy-spetsialist-po-informatsionnoy-bezopasnosti-ib-4443039/)

7. DevOps Engineer — МТС
middle · 227 000 ₽ · офис Москва
→ [Job](https://job.mts.ru/vacancies/678966233428658215)

8. DevOps Engineer — Greenway Global
lead · от 180 000 ₽ · офис Новосибирск
→ [Hirehi](https://hirehi.ru/devops/devops-inzhener-57589)

❌ «Я же знаю Kubernetes. Почему меня не взяли?»

Недавно вспомнил одну ситуацию с собеседования.

В вакансии было написано:

«Требуется DevOps с опытом Kubernetes.»

На техническом интервью мне задают вопрос:

Что происходит после kubectl apply?

Я начинаю объяснять:

• запрос уходит в API Server;
• объект сохраняется в etcd;
• Controller Manager замечает изменение;
• Scheduler выбирает Node;
• Kubelet получает новую задачу;
• containerd запускает контейнер;
• Pod проходит Readiness Probe и становится Ready.

Интервьюер кивает.

Следующий вопрос:

«Что произойдет, если Scheduler выберет Node, на которой закончилась память?»

Потом:

«Почему Pod может зависнуть в Pending?»

Потом:

«Чем ReplicaSet отличается от Deployment?»

Потом:

«Почему контейнер может уйти в CrashLoopBackOff?»

И только тогда я понял одну важную вещь.

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

kubectl get pods
kubectl logs
kubectl describe
kubectl exec

Но компании проверяют совсем другое.

Они хотят понять не то, знаешь ли ты команду.

Они хотят понять, понимаешь ли ты систему.

Можешь ли ты объяснить:

• почему всё работает именно так;
• какой компонент выполняет каждое действие;
• где искать проблему, если что-то пошло не так;
• как будет вести себя кластер в нестандартной ситуации.

Именно поэтому многие удивляются:

«Я же знаю Kubernetes. Почему меня не взяли?»

Потому что знать команды и понимать архитектуру — это две совершенно разные вещи.

Команды можно выучить за несколько дней.

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

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

💬 А какой самый неожиданный вопрос по DevOps задавали вам на собеседовании? Напишите в комментариях. Интересно собрать реальные истории и потом сделать отдельный пост с разбором.

#kubernetes
#career

🔥 Подборка актуальных вакансий DevOps / SRE / MLOps

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

1️⃣ Золотое Яблоко | DevOps Engineer
💪 Middle • 💰 ~254 000 ₽ • 🏠 Гибрид, Екатеринбург

2️⃣ Островок | MLOps Engineer
💪 Senior • 💰 ~356 000 ₽ • 🏠 Удалённо

3️⃣ Сбер | DevOps Engineer
💪 Senior • 💰 ~308 000 ₽ • 🏠 Гибрид, Москва

4️⃣ ВКонтакте | Site Reliability Engineer
💪 Senior • 💰 ~354 000 ₽ • 🏠 Удалённо по РФ

5️⃣ ВКонтакте | Site Reliability Engineer
💪 Senior • 💰 ~350 000 ₽ • 🏠 Удалённо по РФ

6️⃣ Т1 | Инженер технической поддержки
💪 Middle • 💰 ~145 000 ₽ • 🏠 Офис, Тюмень

7️⃣ Wildberries | Support Engineer
💪 Middle • 💰 ~173 000 ₽ • 🏠 Гибрид, Москва

8️⃣ Авито | Site Reliability Engineer
💪 Middle • 💰 ~250 000 ₽ • 🏠 Удалённо


💬 Нужна ссылка на конкретную вакансию? Напишите её номер в комментариях (например: «2» или «8»)- отправлю в личные сообщения.

🎮 Прокачай Git за один вечер

Читать теорию про git можно бесконечно. А потом всё равно путаешься в rebase и merge conflict на практике.

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

Что цепляет:
– визуализация веток в реальном времени
– от простого checkout до сложного rebase и cherry-pick
– можно сразу увидеть свою ошибку, а не гадать что пошло не так

Рекомендую пройти минимум 5 раз. Первый раз будет больно, дальше пойдёт как по маслу.

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

→ learngitbranching.js.org

#git
#resources

📦 MLOps Roadmap 2026

Полная карта пути от DevOps до Production ML.

12 этапов: цель, что учить, какой стек - на каждом.

Не теория и не курс.
То, через что реально проходят инженеры.

Главная мысль:
MLOps - это не Kubeflow.
Это контроль всего жизненного цикла модели:
от данных до продакшена.
Хочешь двигаться дальше по этой карте?

Пиши «MLOps» в комментариях -
соберу Starter Pack с материалами по каждому этапу.

Наберем 80 комментариев выложу в тг сразу

#library

📦 Linux-собес

Собрал 6 вопросов, которые реально спрашивают на собеседованиях DevOps / SRE / Backend.

1. Что такое процесс?
Выполняющаяся программа в памяти. У неё есть своё адресное пространство, PID, регистры, стек и список открытых файлов. Ядро полностью изолирует процессы друг от друга.

2. Что такое ОС?
Прослойка между железом и приложениями. Управляет процессами, памятью, файловой системой и устройствами. Благодаря ОС один упавший процесс не роняет весь сервер.

3. Что такое файловый дескриптор?
Число, которое ядро выдаёт процессу для работы с файлами, сокетами или pipe. 0, 1 и 2 — это stdin, stdout и stderr.

4. Что такое inode?
Структура на диске, где хранятся метаданные файла: владелец, права, размер, время изменения и указатели на данные. Имя файла хранится отдельно в каталоге.

5. Какие бывают состояния процессов?
- R — выполняется или готов к выполнению
- S — спит (ждёт события), самое частое состояние
- D — ожидание диска (нельзя убить даже kill -9)
- Z — zombie (процесс умер, но родитель не забрал статус)

6. ext4 vs XFS?
- ext4 — универсальный и стабильный выбор по умолчанию.
- XFS — быстрее работает с большими файлами и высокой параллельной записью (хорошо для баз данных и хранилищ).

#linux
#career

Как маршрутизировать на разные Redis и другие сервисы через один LoadBalancer по SNI TCP routing используя Gateway API

https://habr.com/ru/articles/987652/

#resources

📦 Что происходит после нажатия кнопки Power? Как загружается Linux?

Каждый день мы запускаем серверы, контейнеры и виртуальные машины.
Но что на самом деле происходит между нажатием кнопки Power и появлением логина? 🤔
Разберём путь по шагам.

⚡ 1. BIOS / UEFI
Первым запускается BIOS (или UEFI).
Он проверяет оборудование:
• память;
• процессор;
• диски;
• устройства.
После этого ищет загрузчик.

🚀 2. GRUB
Обычно это GRUB.
Его задача проста:
• найти ядро Linux;
• загрузить initramfs;
• передать управление ядру.

🐧 3. Ядро Linux
Ядро распаковывает себя в память и начинает инициализацию системы:
• загружает драйверы;
• монтирует initramfs как временную файловую систему;
• находит настоящий root-раздел;
• выполняет switch_root;
• освобождает временную файловую систему из памяти.

⚙️ 4. PID 1 - systemd
Теперь запускается первый процесс в системе.
У него всегда PID = 1.
Сегодня почти во всех современных дистрибутивах это systemd.

🔥 Чем systemd отличается от старого init?

Он не запускает сервисы по очереди.
Вместо этого строит граф зависимостей и поднимает всё, что возможно, параллельно.
Затем система достигает нужного состояния:
🖥 graphical.target - рабочий стол.
🖧 multi-user.target - серверный режим.

Что такое Unit?

Очень многие думают, что Unit = Service.
На самом деле service - лишь один из типов unit.
Unit - это любой объект, которым умеет управлять systemd.
Самые популярные:

🔹 Service - запускает процессы.
🔹 Socket - открывает порт ещё до запуска сервиса (socket activation).
🔹 Target - объединяет несколько unit в одну цель.
🔹 Timer - выполняет задачи по расписанию (аналог cron).
🔹 Mount - монтирует файловые системы.

Посмотреть состояние unit

systemctl status nginx.service

Увидите:
• состояние сервиса;
• PID процесса;
• последние записи журнала;
• причины возможных ошибок.

📌 Вот и весь путь:

Power → BIOS/UEFI → GRUB → Kernel → initramfs → switch_root → systemd → ваши сервисы.
Именно так Linux проходит путь от кнопки питания до работающего приложения.

#linux
#career

📦 ОТ 1 СЕРВЕРА ДО 1 000 000 ПОЛЬЗОВАТЕЛЕЙ

Как на практике масштабируется система?

Многие думают, что высоконагруженный проект сразу начинается с Kubernetes, микросервисов и десятков серверов.

На деле всё проще.

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

Разберём этот путь по шагам 👇

1️⃣ ОДИН СЕРВЕР

Приложение и база данных работают на одной машине.

Для первых тысяч пользователей этого часто достаточно.

Главное правило: не усложняй архитектуру раньше времени.

2️⃣ БАЗА ДАННЫХ НА ОТДЕЛЬНОМ СЕРВЕРЕ

Когда нагрузка растёт, приложение и база начинают конкурировать за процессор, память и диск.

Первый логичный шаг - вынести базу отдельно.

Теперь приложение и БД можно масштабировать независимо.

3️⃣ LOAD BALANCER И НЕСКОЛЬКО APP-СЕРВЕРОВ

Одного экземпляра приложения становится недостаточно.

Перед несколькими серверами появляется балансировщик:

• Nginx
• HAProxy
• облачный Load Balancer

Он распределяет запросы по алгоритму round robin или least connections.

Но есть важный нюанс: приложение должно быть stateless.

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

Обычно сессии выносят в Redis или используют JWT.

4️⃣ READ-РЕПЛИКИ БАЗЫ ДАННЫХ

В большинстве приложений чтений намного больше, чем записей.

Поэтому основная база принимает запись, а реплики обслуживают чтение.

Это снижает нагрузку на основной сервер.

Но репликация обычно асинхронная, поэтому реплика может немного отставать.

5️⃣ КЭШ ПЕРЕД БАЗОЙ

Следующее узкое место - повторяющиеся запросы.

Решение - Redis и схема cache-aside:

1. Проверяем кэш.
2. Если данных нет, идём в базу.
3. Сохраняем результат в Redis.

При высоком hit rate база почти перестаёт чувствовать нагрузку.

6️⃣ CDN ДЛЯ СТАТИКИ

Картинки, CSS, JavaScript и видео начинают раздаваться через CDN.

Пользователь получает контент с ближайшей точки присутствия.

Это уменьшает задержку и снимает нагрузку с основных серверов.

7️⃣ ГЕОРАСПРЕДЕЛЕНИЕ

Когда пользователи находятся в разных странах и регионах, одного дата-центра становится недостаточно.

Появляются:

• несколько дата-центров
• GeoDNS
• маршрутизация в ближайший регион

Но вместе с этим возникает проблема синхронизации данных между регионами.

8️⃣ MESSAGE QUEUE

Когда сервисы напрямую зависят друг от друга, система становится хрупкой.

Поэтому между ними появляется очередь сообщений:

• Kafka
• RabbitMQ

Очередь помогает переживать всплески нагрузки, выполнять задачи асинхронно и не давать одному медленному сервису тормозить всю систему.

9️⃣ ШАРДИНГ БАЗЫ

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

Например, по user_id.

Но здесь появляется celebrity problem.

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

Поэтому шардинг требует продуманного ключа распределения, consistent hashing и механизма решардинга.

💡 ГЛАВНОЕ

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

Сначала найди реальное узкое место:

• сервер не справляется
• база тормозит на чтении
• сессии рвутся при деплое
• один сервис блокирует остальные

И только потом добавляй следующий уровень сложности.

Преждевременный шардинг, Kafka и геораспределение без реальной нагрузки - это не масштабирование, а лишняя сложность.

💬 Какой этап, по твоему мнению, самый сложный в реальных проектах?

Сохрани пост. Он пригодится перед собеседованием или при проектировании системы.

#library

📦 Root не может удалить свой же файл. И это абсолютно нормально.

Кажется, что root в Linux может всё.

Удалить любой файл.
Изменить любую настройку.
Остановить любой процесс.

Но есть один механизм, который способен сказать root простое:

❌ Operation not permitted.

Разберёмся почему.

🔍 Проверяем на практике

Создадим файл и попробуем удалить его от имени root:

sudo rm file.txt

Получим неожиданную ошибку:

rm: cannot remove 'file.txt': Operation not permitted

Почему?

Ведь это же root.

👀 Смотрим атрибуты файла

Выполняем:

lsattr file.txt

Получаем:

----i--------e-- file.txt

Буква i означает Immutable.

Именно она запрещает любые изменения файла.

Нельзя:

❌ удалить;
❌ переименовать;
❌ изменить содержимое;
❌ создать жёсткую ссылку.

Даже если вы работаете под root.

🤔 Но ведь root может всё?

Не совсем.

Большинство думает, что root обходит любые ограничения.

На самом деле это работает только с правами доступа.

Immutable вообще не относится к rwx.

Он находится уровнем ниже, на уровне файловой системы.

Ядро сначала проверяет атрибуты файла.

И только потом смотрит владельца и права.

💡 Запомнить очень просто

Права доступа (rwx) - это ключ от двери.

Immutable - это дверь, которую наглухо заварили.

Root способен открыть любую дверь.

Но если двери больше нет, открывать уже нечего.

🔓 Как снять Immutable?

Только root (или процесс с capability CAP_LINUX_IMMUTABLE) может убрать этот атрибут.

Достаточно выполнить:

sudo chattr -i file.txt

После этого файл снова можно удалить обычным:

rm file.txt

🔥 Где это используют в реальной жизни?

Immutable часто ставят на критически важные файлы:

• /etc/passwd
• /etc/shadow
• /etc/resolv.conf
• важные конфигурации приложений

Это дополнительная защита даже на случай, если кто-то уже получил root-доступ.

Есть и похожий атрибут append-only (a).

Такой файл можно только дополнять.

Изменить или удалить его нельзя.

Поэтому этот флаг часто используют для логов.

🎯 Это любят спрашивать на собеседованиях

Очень часто кандидат уверенно рассказывает про:

• chmod
• chown
• rwx
• ACL

Но после вопроса:

> Почему root не может удалить файл?

...начинается тишина.

А ответ оказывается в одном маленьком флаге.

💬 Полезно?

Напишите sudo в комментариях.

Разберём полностью chattr и lsattr: все атрибуты, реальные кейсы использования и вопросы, которые любят задавать на Linux / DevOps собеседованиях.

📦 Kubernetes Secret не зашифрован. Вот что нужно знать.

Название Secret создаёт ощущение, что Kubernetes надёжно хранит ваши пароли.

На самом деле по умолчанию это не шифрование.

Это обычный Base64.

Любой, у кого есть доступ к Secret, сможет получить пароль за несколько секунд.

Проверим.

🔍 Создаём Secret

kubectl create secret generic mypass \
  --from-literal=password=SuperSecret123

Теперь попробуем прочитать его.

kubectl get secret mypass \
-o jsonpath='{.data.password}' | base64 -d

Результат:

SuperSecret123

Пароль получен в открытом виде.

🤔 Почему так происходит?

Многие путают Base64 с шифрованием.

Но Base64 - это всего лишь кодировка.

Она не использует:

❌ ключ;

❌ алгоритм шифрования;

❌ секрет для расшифровки.

Она просто меняет представление тех же самых байтов.

Любой человек сможет выполнить:

base64 -d

...и получить исходное значение.

💡 Что хранится в etcd?

По умолчанию Kubernetes сохраняет Secret в etcd именно в таком виде.

Это означает, что любой, кто:

• имеет право выполнить kubectl get secret;

• получил доступ к API Kubernetes;

• имеет доступ к etcd;

сможет прочитать содержимое практически мгновенно.

Поэтому Secret ≠ Encryption.

🔥 Как защищают Secrets в production?

### 1️⃣ Encryption at Rest

Самый правильный способ.

Настраивается через EncryptionConfiguration на API Server.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration

resources:
- resources:
  - secrets

  providers:
  - kms:
      apiVersion: v2
      name: aws-encryption
      endpoint: unix:///run/kmsplugin/socket.sock

  - identity: {}

Используются:

• AWS KMS

• Azure Key Vault

• Google Cloud KMS

• HashiCorp Vault

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

━━━━━━━━━━━━━━━━━━

### 2️⃣ RBAC

Не давайте всем подряд право выполнять:

kubectl get secrets

На практике большинство утечек происходит не через взлом etcd.

А потому, что слишком много пользователей имеют доступ к Secret.

Минимально необходимые права всегда безопаснее.

━━━━━━━━━━━━━━━━━━

### 3️⃣ External Secret Manager

Лучше вообще не хранить секреты в Kubernetes.

Для этого используют:

• External Secrets Operator

• AWS Secrets Manager

• HashiCorp Vault

• Azure Key Vault

В этом случае Kubernetes Secret становится всего лишь кэшем.

Настоящий источник данных остаётся во внешнем Secret Manager.

Там доступны:

✅ ротация секретов;

✅ аудит;

✅ контроль доступа.

━━━━━━━━━━━━━━━━━━

### 4️⃣ GitOps

Если секреты лежат в Git:

используйте

• SOPS

или

• Sealed Secrets.

Секреты шифруются до коммита.

Расшифровывает их уже контроллер внутри Kubernetes.

В репозитории никогда не хранится открытый пароль.

🔎 Как проверить, включено ли шифрование?

ETCDCTL_API=3 etcdctl get \
/registry/secrets/default/mypass | hexdump -C

Если увидите:

k8s:enc:kms

Значит всё хорошо.

Если увидите обычный Base64 - шифрование не включено.

🎯 Главное, что стоит запомнить

Kubernetes Secret - это не сейф.

Это контейнер для хранения чувствительных данных.

По умолчанию он защищён только механизмами доступа Kubernetes.

Если не включить Encryption at Rest и не настроить RBAC, ваши секреты могут оказаться гораздо доступнее, чем кажется.

💬 А вы уже включали EncryptionConfiguration в своих кластерах?

Или до сих пор храните Secrets "как есть"?

Пишите в комментариях 👇

📦 Все сетевые драйверы Docker за 10 минут

На собеседованиях по Docker почти всегда спрашивают:

❓ Чем bridge отличается от host?
❓ Когда нужен overlay?
❓ В чём разница macvlan и ipvlan?
❓ Почему контейнеры не видят друг друга по имени?

Если ответы путаются в голове - сохраняй этот roadmap.

## 1️⃣ Bridge (по умолчанию)

Самый популярный драйвер Docker.

При запуске контейнера Docker:

• создаёт виртуальный мост docker0;
• подключает контейнер через veth;
• выдаёт IP из собственной подсети;
• выпускает трафик наружу через NAT.

Проверить:

docker network ls

docker network inspect bridge

⚠️ Важно

Контейнеры в default bridge не умеют искать друг друга по имени.

Для этого нужен user-defined bridge.

Создать сеть:

docker network create my-net

Запустить контейнеры:

docker run -d --network my-net \
--name app1 nginx

docker run -d --network my-net \
--name app2 nginx

Теперь контейнер app2 сможет обратиться к app1 просто по имени.

Когда использовать:

✅ локальная разработка

✅ микросервисы

✅ большинство приложений


## 2️⃣ Host

Контейнер использует сетевой стек самого Linux-хоста.

Без NAT.

Без docker0.

Без port mapping.

Запуск:

docker run --network host nginx

Плюсы:

✅ максимальная производительность

✅ минимум сетевых накладных расходов

Минусы:

❌ нет сетевой изоляции

❌ контейнер использует порты хоста

❌ работает только на Linux

Когда использовать:

• monitoring agents

• node exporters

• сетевые утилиты


## 3️⃣ Overlay

Соединяет контейнеры между несколькими серверами.

Основа Docker Swarm.

Работает через VXLAN.

Создать сеть:

docker swarm init

docker network create \
-d overlay \
--attachable \
my-overlay

⚠️ Важно

VXLAN добавляет дополнительный заголовок.

Если MTU равен 1500, полезная нагрузка уменьшается примерно до 1450 байт.

Из-за этого иногда появляются "непонятные" таймауты между нодами.

Когда использовать:

✅ Docker Swarm

✅ несколько серверов


## 4️⃣ Macvlan

Контейнер становится полноценным устройством в локальной сети.

У него появляются:

✅ собственный MAC

✅ собственный IP

Для роутера он выглядит как отдельный компьютер.

Создание сети:

docker network create \
-d macvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0 \
macvlan_net

⚠️ Особенность

Linux-хост не может напрямую обращаться к своим macvlan-контейнерам.

⚠️ Большинство облаков блокируют macvlan из-за защиты от MAC Spoofing.

Когда использовать:

• Legacy-системы

• приложения, которым нужен настоящий IP в LAN


## 5️⃣ IPvlan

Очень похож на macvlan.

Но есть отличие.

Все контейнеры используют один MAC-адрес хоста.

При этом каждый получает собственный IP.

Создание сети:

docker network create \
-d ipvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0 \
my-ipvlan

Когда использовать:

✅ если на коммутаторе есть ограничение на количество MAC

✅ большие корпоративные сети


## 6️⃣ None

Максимально простой драйвер.

Контейнер получает только интерфейс:

lo

Проверить:

docker run \
--network none \
alpine ip addr

Никаких:

❌ Ethernet

❌ bridge

❌ NAT

❌ Интернета

Когда использовать:

• batch-задачи

• sandbox

• security-sensitive приложения

## 🚀 Что выбрать?

🟢 bridge

Обычные приложения.

🟢 host

Максимальная производительность.

🟢 overlay

Docker Swarm.

🟢 macvlan

Нужен настоящий IP в LAN.

🟢 ipvlan

Много контейнеров и ограничение по MAC.

🟢 none

Полная изоляция.


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

❓ Почему default bridge не умеет DNS?

❓ Чем host быстрее bridge?

❓ Зачем overlay использует VXLAN?

❓ Почему host не видит macvlan?

❓ Чем macvlan отличается от ipvlan?

❓ Когда лучше использовать none?

Если можешь уверенно ответить на эти вопросы — Docker Networking уже вряд ли сможет тебя удивить на собеседовании.

💾 Сохрани этот roadmap.

Он пригодится и на практике, и перед следующим DevOps-интервью.

🌐 Модель OSI за 10 минут

На любом DevOps, SRE или Backend собеседовании рано или поздно спросят:

❓ Что происходит, когда ты открываешь сайт?

Правильный ответ почти всегда начинается с модели OSI.

Это не просто теория из университета.

Это удобная модель, которая помогает быстро понять, на каком уровне возникла проблема.

Разберём все 7 уровней на реальных примерах. 👇


## 1️⃣ Physical (Физический)

Самый нижний уровень.

Здесь ещё нет IP, TCP или HTTP.

Есть только передача битов по среде.

Работает:

• витая пара;
• оптика;
• Wi-Fi;
• разъёмы;
• сетевые карты.

Что проверять:

ip link

или

ethtool eth0

Типичные проблемы:

❌ оборван кабель;

❌ отключён порт;

❌ нет линка;

❌ плохой сигнал Wi-Fi.


## 2️⃣ Data Link (Канальный)

Здесь появляются MAC-адреса.

Передаются уже не биты, а Ethernet-кадры.

Именно здесь работает коммутатор.

Он смотрит только на MAC-адрес получателя.

IP ему вообще не интересен.

Посмотреть MAC:

ip link show

или

ip addr

Типичные устройства:

✅ Switch

Типичные проблемы:

❌ неправильный VLAN;

❌ MAC Flapping;

❌ STP Loop.


## 3️⃣ Network (Сетевой)

Здесь появляются IP-адреса.

Работают:

• IPv4;

• IPv6;

• маршрутизация;

• ICMP.

Именно здесь работает роутер.

Он выбирает маршрут до сети назначения.

Проверить маршрут:

ip route

Проверить доступность:

ping google.com

или

traceroute google.com

Типичные проблемы:

❌ нет маршрута;

❌ неправильный Gateway;

❌ ACL;

❌ Firewall.


## 4️⃣ Transport (Транспортный)

Здесь появляются:

• TCP;

• UDP;

• порты.

TCP умеет:

✅ подтверждать доставку;

✅ повторно отправлять потерянные пакеты;

✅ соблюдать порядок.

UDP ничего не гарантирует.

Зато работает быстрее.

Проверить соединение:

ss -tulpn

или

netstat -tulpn

Типичные проблемы:

❌ порт закрыт;

❌ Firewall блокирует TCP;

❌ потеря пакетов.


## 5️⃣ Session (Сеансовый)

Отвечает за создание и поддержку соединения между приложениями.

В современной сети редко существует как отдельный протокол.

Чаще его функции выполняют:

• TCP;

• RPC;

• SMB;

• SSH.

Проще говоря:

именно этот уровень отвечает за "разговор" двух приложений.


## 6️⃣ Presentation (Представления)

Этот уровень отвечает за то, как выглядят данные.

Именно здесь появляются:

🔐 TLS

🔐 SSL

🗜️ Сжатие

🔤 Кодировки

Например:

Когда открываешь HTTPS-сайт, именно здесь происходит TLS Handshake.

Проверить сертификат:

openssl s_client \
-connect google.com:443

Типичные проблемы:

❌ просроченный сертификат;

❌ неподдерживаемый TLS;

❌ ошибка шифрования.

## 7️⃣ Application (Прикладной)

Самый верхний уровень.

Именно с ним работают разработчики.

Здесь находятся:

🌍 HTTP

🌍 HTTPS

🌍 DNS

🌍 SSH

🌍 FTP

🌍 SMTP

🌍 MQTT

Например:

curl https://example.com

или

dig google.com

или

ssh user@server

Типичные проблемы:

❌ 404

❌ 500

❌ DNS не отвечает

❌ API недоступно


## 🚀 Что происходит, когда открывается сайт?

1️⃣ Кабель передаёт биты.

2️⃣ Ethernet доставляет кадр.

3️⃣ IP находит маршрут.

4️⃣ TCP устанавливает соединение.

5️⃣ Создаётся сессия.

6️⃣ TLS шифрует данные.

7️⃣ HTTP получает страницу сайта.

И всё это происходит буквально за доли секунды.


## ⚠️ А теперь самое важное

Интернет не работает по OSI.

Реальный стек называется TCP/IP.

В нём всё намного проще:

📍 Link

📍 Internet

📍 Transport

📍 Application

То есть уровни 5, 6 и 7 модели OSI объединены в один.

Поэтому OSI используют не как реальную архитектуру сети, а как удобную модель для диагностики и объяснения того, где именно возникла проблема.


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

❓ На каком уровне работает Switch?

❓ Где работает Router?

❓ Где находится TCP?

❓ Где появляется TLS?

❓ Почему DNS относят к 7 уровню?

❓ Чем OSI отличается от TCP/IP?

Если можешь ответить на эти вопросы без подготовки - сеть уже не станет проблемой на собеседовании.

#linux

Забавный факт.

Меня отправили в вечный мут в достаточно известном канале "DevOps - русскоговорящее сообщество". Никаких объяснений я так и не получил.
Самое интересное, что я ничего не продавал, не спамил и не провоцировал конфликты - наоборот, регулярно бесплатно помогал людям с вопросами и делился своим опытом.

Получилось довольно показательно.

Выводы каждый сделает сам. 🙂

📦 curl висит, а ping работает. Как найти проблему за минуту

Классическая ситуация:

ping example.com

отвечает, хост вроде живой.

А вот:

curl https://example.com

зависает или падает по таймауту.

Причина простая: ping и curl проверяют разные уровни сети.

Чтобы не гадать, проходи цепочку по шагам.

1️⃣ Проверяем сеть и DNS

ping example.com

ping показывает, резолвится ли имя и доступен ли хост по ICMP.

Но важно помнить:

• успешный ping не означает, что нужный порт открыт;
• отсутствие ответа не всегда означает, что сервер недоступен;
• ICMP может быть просто запрещён firewall.

Поэтому ping нужен только как первая быстрая проверка.

2️⃣ Проверяем TCP-порт

nc -zv example.com 443

Флаги:

-z  проверить порт без передачи данных
-v  показать подробный результат

Возможные ответы:

succeeded

TCP-соединение установлено, порт доступен.

Connection refused

Хост доступен, но на порту никто не слушает либо соединение активно отклоняется.

Operation timed out

Пакеты могут блокироваться firewall, Security Group, ACL или теряться по пути.

На сервере проверяем:

ss -tlnp | grep ':443'
systemctl status nginx

3️⃣ Проверяем TLS

openssl s_client \
  -connect example.com:443 \
  -servername example.com

-servername передаёт SNI. Без него сервер с несколькими доменами может вернуть чужой сертификат или вообще разорвать соединение.

Если TCP-порт открыт, но TLS не проходит, возможные причины:

• сертификат истёк;
• сертификат выпущен не на тот домен;
• не совпадают версии TLS или cipher suites;
• reverse proxy настроен неправильно;
• DPI или firewall вмешивается в TLS-трафик;
• сервер ожидает правильный SNI.

Проверить даты сертификата:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

4️⃣ Проверяем HTTP и приложение

curl -v https://example.com

curl -v показывает всю цепочку:

• DNS resolution;
• подключение к IP;
• TCP connection;
• TLS handshake;
• отправленный HTTP-запрос;
• заголовки ответа;
• HTTP status code.

Чтобы диагностика не зависла надолго:

curl -v \
  --connect-timeout 3 \
  --max-time 10 \
  https://example.com

Если TLS прошёл, но приложение не отвечает, проверяем:

502  backend недоступен reverse proxy
503  сервис не готов или перегружен
504  upstream не ответил вовремя
404  запрос дошёл, но маршрут не найден
500  ошибка внутри приложения

🔍 Быстрая последовательность

DNS / ICMP
    ↓
ping

TCP-порт
    ↓
nc -zv

TLS
    ↓
openssl s_client

HTTP / приложение
    ↓
curl -v

💡 Главное правило

Не проверяй всю систему одной командой.

Каждый инструмент отвечает на свой вопрос:

ping              доступна ли сеть по ICMP
nc -zv            устанавливается ли TCP-соединение
openssl s_client  проходит ли TLS-handshake
curl -v           отвечает ли HTTP-приложение

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

Сохрани. На следующем инциденте эта последовательность сэкономит время и нервы.

#devops #linux

📦 Вот что реально могут спросить на собесе

Тема: PgBouncer и Connection Pooling

Пиши pgbouncer / postgres / pooling в комментариях, если работаешь с этим стеком 👇

---

## ⚡ Почему Postgres не любит тысячи соединений

Многие думают, что проблема решается увеличением:

max_connections = 1000

Но это почти никогда не правильное решение.

Каждое новое подключение к PostgreSQL — это отдельный процесс операционной системы, а не поток.

На каждое соединение тратятся:

• создание процесса (`fork()`);
• аутентификация;
• собственная память (обычно 5–10 МБ);
• переключение контекста процессора.

Получается примерно так:

1000 клиентов
        │
        ▼
1000 процессов PostgreSQL
        │
        ▼
CPU ↑
RAM ↑
Context Switch ↑

Сервер начинает тратить ресурсы не на выполнение SQL-запросов, а на обслуживание тысяч процессов.

---

## 🚕 Что делает PgBouncer

Представь службу такси.

Есть:

- 1000 пассажиров (подключений приложения);
- всего 20 машин (реальных соединений с Postgres).

Каждый пассажир думает, что машина принадлежит только ему.

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

Получается:

1000 клиентов
        │
        ▼
 PgBouncer
        │
        ▼
20 соединений
        │
        ▼
 PostgreSQL

Именно поэтому база перестаёт захлёбываться под нагрузкой.

---

## 🔀 Три режима работы PgBouncer

### 1️⃣ Session mode

Client
   │
Connection
   │
Postgres

Соединение закрепляется за клиентом на всю сессию.

✅ максимально совместим

❌ экономия соединений небольшая

---

### 2️⃣ Transaction mode ⭐

Client
   │
Transaction
   │
Pool
   │
Postgres

Соединение выдаётся только на время транзакции.

После COMMIT или ROLLBACK сразу возвращается обратно в пул.

✅ лучший режим для большинства production-систем

✅ максимальная экономия соединений

---

### 3️⃣ Statement mode

Каждый SQL-запрос
        │
получает новое соединение

После каждого запроса соединение сразу возвращается в пул.

Максимальная производительность.

Но есть серьёзное ограничение:

❌ транзакции работать не будут.

Используется крайне редко.

---

## 🪤 Любимая ловушка на собеседовании

Почему в Transaction Mode ломаются некоторые вещи?

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

Из-за этого возникают проблемы.

### Advisory Locks

Плохой вариант:

pg_advisory_lock(...)

Блокировка живёт на соединении.

Соединение ушло обратно в пул → логика ломается.

Используйте:

pg_advisory_xact_lock(...)

Он живёт внутри транзакции.

---

### LISTEN / NOTIFY

Подписка тоже существует только на конкретном соединении.

В Transaction Mode соединение постоянно меняется.

И уведомления перестают приходить.

---

### Prepared Statements

Раньше это тоже была большая проблема.

Начиная с PgBouncer 1.21+ появилась поддержка через:

max_prepared_statements

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

---

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

✅ Зачем нужен PgBouncer, если есть max_connections?

✅ Чем отличаются Session, Transaction и Statement Mode?

✅ Почему Transaction Mode ломает Advisory Locks?

✅ Почему LISTEN / NOTIFY плохо работает через PgBouncer?

✅ Как подобрать размер пула?

✅ Что выбрать:

- PgBouncer
- или встроенный connection pool приложения?

---

💡 Главное, что стоит запомнить

PostgreSQL плохо масштабируется количеством соединений.

Он отлично масштабируется количеством запросов.

Поэтому задача PgBouncer - не ускорить базу, а не дать ей умереть от тысяч подключений.

Сохрани пост - этот вопрос встречается практически на каждом собеседовании уровня Middle/Senior.

#postgres #pgbouncer #database #devops #sre #backend

📦 Вот что реально могут спросить на собесе

Тема: процесс завис в D-state

Пиши dstate / wchan / iostat в комментариях, если сталкивался с таким на проде 👇

---

## 🔴 Задача с собеседования

У тебя завис процесс.

В top или htop он находится в состоянии D (Uninterruptible Sleep).

CPU почти не используется, но iostat показывает высокую нагрузку на диск.

Что делать?

---

## ⚠️ Главное, что нужно знать

Большинство кандидатов первым делом делают:

kill -9 <PID>

И удивляются, что ничего не произошло.

Почему?

Потому что процесс в D-state находится внутри операции ввода-вывода (I/O).

Пока ядро не получит ответ от диска или сетевого хранилища, процесс невозможно завершить даже через SIGKILL.

Именно поэтому kill -9 здесь не работает.

---

## 🔍 Шаг 1. Найти процессы в D-state

ps aux | awk '$8=="D"{print $2,$11}'

# или

top -b -n1 | grep " D "

Если процессов несколько, начинаем с тех, которые находятся в D-state дольше всего.

---

## 🔍 Шаг 2. Посмотреть, чего именно ждёт процесс

Самый полезный файл:

cat /proc/<PID>/wchan

Примеры:

io_schedule

➡️ ожидание дисковой операции

nfs_wait

➡️ ожидание NFS

futex_wait_queue

➡️ ожидание блокировки

Если нужно увидеть полный стек ядра:

cat /proc/<PID>/stack

Там можно встретить:

submit_bio
ext4_file_write_iter
blk_mq_get_tag

Это уже позволяет понять, где именно зависла операция.

---

## 🔍 Шаг 3. Узнать, с чем работает процесс

Какие файлы открыты:

lsof -p <PID>

Только обычные файлы и блочные устройства:

lsof -p <PID> | grep -E "REG|BLK"

Если процесс ещё выполняет системные вызовы:

strace -p <PID> \
-e trace=read,write,pread64,pwrite64 -T

Флаг:

-T

показывает время выполнения каждого вызова.

---

## 🔍 Шаг 4. Проверить диск

Общая нагрузка:

iostat -x 1

I/O конкретного процесса:

iotop -p <PID>

Статистика процесса:

cat /proc/<PID>/io

Смотри:

- количество чтений;
- количество записей;
- объём данных;
- скорость роста счётчиков.

---

## 🔍 Шаг 5. Если проблема в NFS

Проверяем подключённые файловые системы:

mount | grep nfs

Статистика клиента:

nfsstat -c

И снова смотрим:

cat /proc/<PID>/wchan

Если видишь:

nfs4_wait_bit_killable

Практически наверняка процесс ждёт ответа от NFS-сервера.

---

## 🪤 Любимая ловушка на собеседовании

Можно ли убить процесс в D-state?

Ответ:

❌ Нет.

Пока операция ввода-вывода не завершится, ядро не обработает сигнал.

Обычно остаются только три варианта:

- дождаться завершения I/O;
- принудительно размонтировать проблемную файловую систему (если это возможно):

umount -f -l /mnt/storage

- либо перезагрузить сервер.

---

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

✅ Чем D-state отличается от Sleeping и Running?

✅ Почему kill -9 не работает?

✅ Что показывает /proc/<PID>/wchan?

✅ Как определить, диск это или NFS?

✅ Какие команды используешь для диагностики?

---

## 💡 Главное правило

Если процесс находится в D-state, почти всегда проблема не в самом процессе.

Проблема ниже:

- диск;
- RAID;
- SAN;
- NFS;
- iSCSI;
- файловая система;
- драйвер;
- блочное устройство.

Именно их нужно искать в первую очередь.

Сохрани пост — вопрос про D-state регулярно встречается на собеседованиях Middle и Senior DevOps/SRE.

#linux #devops #sre #troubleshooting #kernel #interview