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

Тема: 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

📦 401, 403, 404, 500, 502, 503, 504...

Если ты DevOps, Backend или SRE, то эти коды ошибок видишь почти каждый день.

Но большинство знает только их названия. А вот что именно они означают и где искать проблему — уже вопрос.

Разбираемся.

---

## 🟢 2xx — Всё хорошо

200 OK — запрос успешно выполнен.

201 Created — ресурс создан.

204 No Content — операция успешна, но сервер ничего не возвращает.

---

## 🟠 4xx — Ошибка клиента

### 400 Bad Request

Неверный запрос.

Например:

- битый JSON;
- отсутствует обязательное поле;
- неверный формат данных.

---

### 401 Unauthorized

Сервер не знает, кто ты.

Причины:

- нет JWT;
- токен просрочен;
- отсутствует авторизация.

Запомнить просто:

> Сначала представься.

---

### 403 Forbidden

Сервер знает пользователя, но не разрешает доступ.

Например:

user → /admin

↓

403 Forbidden

💡 Мнемоника:

401 — не знает.

403 — знает, но не пускает.

---

### 404 Not Found

Ресурс не найден.

---

### 405 Method Not Allowed

URL существует, но этот HTTP-метод запрещён.

---

### 409 Conflict

Конфликт данных.

Например, пользователь с таким email уже существует.

---

### 429 Too Many Requests

Сработал Rate Limit.

Часто встречается в:

- Nginx
- Cloudflare
- API Gateway
- Kubernetes Ingress

---

## 🔴 5xx — Ошибка сервера

### 500 Internal Server Error

Ошибка внутри приложения.

Ищем логи Backend.

---

### 502 Bad Gateway

Очень любят спрашивать на собеседованиях.

Схема:

Client
   │
Nginx
   │
Backend

Nginx смог подключиться к Backend.

Но получил некорректный ответ.

Поэтому вернул:

502 Bad Gateway

---

### 503 Service Unavailable

Сервис временно недоступен.

Причины:

- приложение выключено;
- deployment обновляется;
- maintenance;
- backend исключён из балансировки.

---

### 504 Gateway Timeout

Самая частая путаница с 502.

При 504 Backend вообще не успел ответить.

Причины:

- долгий SQL;
- блокировки;
- зависший API;
- перегруженный сервер.

---

## 💡 Как отличить 502 и 504

Очень простой способ.

Открой логи Backend.

👉 Есть запись о запросе?

Скорее всего 502.

👉 Запроса нет вообще?

Почти наверняка 504.

Тогда ищем:

- timeout;
- сеть;
- firewall;
- балансировщик;
- перегруженный upstream.

---

## 🧠 Шпаргалка

200 ✔ Всё хорошо

400 ❌ Неверный запрос

401 🔑 Не знает кто ты

403 🚫 Знает, но не пускает

404 🔍 Не найдено

405 ✋ Метод запрещён

409 ⚠ Конфликт

429 🚦 Слишком много запросов

500 💥 Ошибка приложения

502 🔄 Backend ответил неправильно

503 🛠 Сервис недоступен

504 ⏳ Backend не успел ответить

💬 Какой HTTP-код чаще всего встречается у тебя в работе?

#devops #backend #sre #nginx #http

🚨 GitLab CI может обманывать. И большинство узнаёт об этом только после падения продакшена.

Есть опасное заблуждение:

> Pipeline зелёный = релиз успешный.

К сожалению, это не так.

GitLab CI не знает, работает ли ваше приложение. Он знает только одно: все команды в Job завершились без ошибок.

И это две большие разницы.

---

## Самая распространённая ошибка

Вот обычный Job:

deploy:
  stage: deploy
  script:
    - kubectl apply -f deployment.yaml

Pipeline станет зелёным, если команда выполнится успешно.

Но что будет дальше?

Возможны десятки сценариев:

❌ Pod ушёл в CrashLoopBackOff

❌ Образ не скачался (`ImagePullBackOff`)

❌ Приложение не прошло Readiness Probe

❌ Контейнер стартует 5 минут

❌ Deployment завис во время rollout

GitLab этого не проверяет.

Он уже считает, что деплой успешен.

---

## Как делают новички

deploy:
  script:
    - kubectl apply -f app.yaml

Получают:

✔ Pipeline Passed

И спокойно идут пить кофе.

Через пять минут приходит сообщение:

> Прод не работает.

---

## Как делают в production

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

deploy:
  stage: deploy
  script:
    - kubectl apply -f deployment.yaml
    - kubectl rollout status deployment/my-app --timeout=300s

Теперь GitLab дождётся, пока Kubernetes действительно обновит приложение.

Если хотя бы один Pod не сможет подняться, Job завершится ошибкой.

Именно этого обычно и ждут на production.

---

## Ещё несколько причин, почему Pipeline зелёный, а приложение не работает

### 1. allow_failure

tests:
  allow_failure: true

Тесты могут полностью упасть.

Pipeline всё равно останется зелёным.

Используйте только там, где падение действительно допустимо.

---

### 2. Ошибка скрыта

./deploy.sh || true

Или

set +e

Такие конструкции скрывают реальные ошибки.

GitLab считает, что всё прошло успешно.

---

### 3. Нет проверки готовности

Deployment создан.

Но приложение ещё не готово принимать трафик.

Если сразу завершить Job, пользователи могут получить ошибки, хотя Pipeline уже зелёный.

---

### 4. Используется старый образ

Очень частая проблема:

image: latest

или

kubectl set image ...

с тем же тегом.

Kubernetes может вообще не скачать новую версию.

Pipeline успешный.

Код старый.

---

### 5. Нет smoke-тестов

Deployment закончился.

Но никто не проверил:

curl https://service/health

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

---

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

✅ Что означает зелёный Pipeline?

✅ Почему kubectl apply не гарантирует успешный релиз?

✅ Для чего нужен kubectl rollout status?

✅ Чем отличается успешный Job от успешного Deployment?

✅ Какие проверки должны выполняться после деплоя?

---

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

GitLab CI проверяет команды.

Production проверяет результат.

Поэтому хороший pipeline заканчивается не на:

kubectl apply

А на проверке того, что приложение действительно работает:

kubectl rollout status deployment/my-app

или

kubectl wait \
--for=condition=Ready \
pod \
-l app=my-app

или хотя бы

curl https://service/health

Именно эти несколько строк отличают учебный pipeline от production-ready CI/CD.

💬 А какие проверки после деплоя используете вы? Только rollout status или ещё добавляете smoke-тесты и проверки health endpoint?

#gitlab #gitlabci #devops #kubernetes #cicd #sre #linux

🐳 Docker - 15 вопросов, которые реально спрашивают на собеседованиях

Если готовишься на DevOps, SRE или Backend - эти вопросы стоит знать без запинки.

В видео разобрал:

✅ Что такое образ и контейнер
✅ Dockerfile и слои образов
✅ CMD vs ENTRYPOINT
✅ COPY vs ADD
✅ bind mount, volume и tmpfs
✅ bridge, host и overlay сети
✅ Почему контейнер завершается сразу после запуска
✅ Разница между docker stop и docker kill
✅ Как уменьшить размер образа
✅ Multi-stage build
✅ Практические вопросы, которые действительно встречаются на собеседованиях

Без воды - только теория, практика и реальные вопросы.

🎬 Смотреть:
⁠https://www.youtube.com/watch?v=pOGJ0Tlt3P4

💬 А какой вопрос по Docker на собеседовании был самым неожиданным для вас?

#docker #devops #kubernetes #linux #backend #sre #собеседование #it #programming #dockerfile

🔥 Сохраняй, пригодится каждому, кто работает с Linux

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

Внутри:
• навигация по файловой системе;
• поиск файлов;
• права доступа;
• процессы;
• сеть;
• архивы;
• логи;
• диски;
• системная информация;
• полезные сочетания и лайфхаки.

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

💾 Сохрани, чтобы не искать команды каждый раз.

#linux #devops #sysadmin #backend #docker #kubernetes #terminal #cheatsheet #собеседование