Troubleshooting-сценарии: «сайт не открывается», «диск заполнен», «контейнер падает»

↑ Этап 9 · Собес Middle DevOps: вопросы, практика, деплой систем

Обязательно~6 мин чтенияУровень: final

Зачем это на собесе

Сценарные вопросы — самая частая практическая часть: проверяют системность и знание инструментов каждого уровня.

Общий метод

1. Уточнить симптом: что именно не работает, для кого, с какого времени, что менялось (релиз, конфигурация, сертификат, нагрузка).
2. Воспроизвести и определить масштаб (один пользователь/все, одна страница/всё).
3. Гипотезы по слоям (снизу вверх или делением пополам): клиент → DNS → сеть → балансировщик/прокси → приложение → БД/зависимости → ресурсы ОС.
4. Проверка каждой гипотезы командами; смягчение (откат/переключение) важнее причины при продакшн-инциденте.
5. Устранение, проверка, профилактика (алерт, автоматизация, runbook).

Сценарий: «Сайт не открывается»

Шаг	Проверка	Вывод
1	Уточнить: ошибка или таймаут? у всех?	область поиска
2	dig +short site.com	DNS: пусто/неверный IP → запись, резолвер, срок
3	ping/mtr IP	маршрут/сеть
4	nc -vz IP 443	refused → сервис не слушает; timeout → firewall/SG/маршрут
5	openssl s_client -connect site:443 -servername site	сертификат истёк/цепочка/SNI
6	curl -vI https://site	код: 502/503/504 → бэкенд; 403/404 → конфигурация; редиректы
7	на сервере: ss -tulpn, systemctl status nginx, tail error.log	nginx не запущен/ошибка конфигурации
8	бэкенд: curl localhost:8080/health, логи приложения, docker ps	приложение упало/не готово
9	ресурсы: df -h, free -h, top, dmesg | grep -i oom	диск/память/OOM
10	БД/зависимости	недоступна, лимит соединений
11	Изменения	деплой/сертификат/конфиг → откат

Сценарий: «Диск заполнен»

df -h; df -i                                   # место и inode: какой раздел?
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail       # куда ушло
du -sh /var/log/* | sort -h | tail; ls -lhS /var/log | head
docker system df; du -sh /var/lib/docker/*      # образы, тома, логи контейнеров
lsof +L1                                        # удалённые, но открытые файлы (место не освобождено)
find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null
journalctl --disk-usage

Типовые причины и действия:

• логи без ротации → logrotate, journalctl --vacuum-size=500M, лимиты в Docker (max-size), очистить;
• Docker: docker image prune -a, docker builder prune, docker volume ls (осторожно с данными!), логи контейнера (truncate -s 0 <log>);
• удалённый, но открытый файл → перезапуск процесса;
• inode закончились (много мелких файлов: кэши, сессии) → найти каталог (for d in /*; do echo $d $(find $d -xdev | wc -l); done), очистить;
• БД: WAL/временные файлы/слот репликации без потребителя (pg_replication_slots), раздувание;
• бэкапы на том же диске;
• сразу освободить место (безопасно удаляемое), затем найти причину, настроить ротацию, лимиты, мониторинг и алерт (80/90%, прогноз).

Сценарий: «Контейнер падает»

docker ps -a                                              # статус, код выхода
docker logs --tail 200 <c>                                # причина в логах
docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}} {{.State.Error}}' <c>
docker run --rm -it --entrypoint sh <image>               # запустить вручную
docker stats --no-stream; dmesg | grep -i -E 'oom|killed process'

Причины: ошибка конфигурации/нет переменных, недоступна БД/зависимость, неверная команда (exec format error, PID 1 завершился), права (permission denied, non-root), OOMKilled (137), порт занят, restart: always маскирует падение (crash loop), healthcheck неверен. В Kubernetes: kubectl logs --previous, describe pod, get events, probes, requests/limits.

Сценарий: «Высокая нагрузка/сервер тормозит»

uptime (load), top/htop, vmstat 1, iostat -xz 1, free -h, ss -s, pidstat: CPU (user/system/iowait/steal), память/swap, диск (await, %util), сеть, процессы; кто потребляет; когда началось; связь с релизом/трафиком; логи, медленные запросы БД (pg_stat_activity), GC/пулы потоков приложения; решение: откат, масштабирование, ограничение, оптимизация, лимиты.

Сценарий: «Нет подключения к БД»

Порт/сеть (nc -vz db 5432), DNS, firewall/SG, pg_hba.conf, max_connections (исчерпаны — pg_stat_activity), пул соединений приложения, учётные данные/ротация, TLS, БД перегружена/недоступна (диск, OOM, failover), реплика в режиме восстановления (read-only).

Сценарий: «Ошибка 502/504»

502: бэкенд недоступен/упал/закрыл соединение (проверить процесс, порт, сеть, логи nginx connect() failed); 504: таймаут (медленный запрос, БД, ресурсы, proxy_read_timeout); проверить бэкенд напрямую, upstream, IP контейнера (DNS-кэш nginx), перезапуски, ресурсы, недавние изменения.

Сценарий: «Сертификат истёк»

openssl s_client, certbot certificates, таймер/cron продления, certbot renew --dry-run, порт 80/DNS для challenge, reload nginx после продления (deploy-hook); срочно: продлить вручную, reload; профилактика: мониторинг срока (blackbox, алерт за 14/7 дней), автоматизация, проверка в пайплайне.

Сценарий: «Kubernetes: под не запускается»

kubectl describe pod (Events): Pending → ресурсы/taints/PVC; ImagePullBackOff → образ/реестр/секрет; CrashLoopBackOff → логи --previous; CreateContainerConfigError → ConfigMap/Secret; 0/1 Ready → readiness; Evicted/OOMKilled → ресурсы; Service без endpoints → селектор/readiness; Ingress 502/503 → бэкенд/порт; NetworkPolicy/DNS.

Сценарий: «Деплой прошёл, но сервис сломан»

Откатиться (быстро), затем разбор: логи/метрики/трейсы по версии, различия релиза (конфиг, зависимости, миграции), совместимость схемы БД, секреты/переменные, readiness не отражает реальность; профилактика: canary, smoke-тесты, автоматический откат, feature flags.

Сценарий: «Утечка секрета в репозиторий»

Считать скомпрометированным: отозвать/сменить немедленно, проверить логи использования, оценить влияние, затем очистить историю (git filter-repo), внедрить pre-commit (gitleaks), push protection, хранение секретов в хранилище, постмортем.

Сценарий: «Высокая латентность только у части пользователей»

Сегментация (регион, провайдер, устройство, версия), DNS/GeoDNS/CDN, маршрут (mtr), MTU, конкретный узел/под за балансировщиком ($upstream_addr в логах), «шумный сосед», холодный кэш, медленный запрос БД для части данных, IPv6/AAAA, TLS handshake, сторонние зависимости; трассировка для медленных запросов.

Сценарий: «Сервер недоступен по SSH»

Сеть/порт (nc -vz), firewall/SG, sshd работает, ключи/права, AllowUsers, fail2ban заблокировал IP, диск заполнен/inode/память (система не отвечает), консоль провайдера (VNC), перезагрузка; анализ journalctl -u ssh, auth.log.

Как отвечать

• структура: «сначала уточню…, затем по слоям…, проверю…, если X — то Y»;
• называть конкретные команды и что они покажут;
• смягчение → причина → профилактика;
• учитывать безопасность (не удалять данные без проверки, не отключать firewall «на минутку»);
• фиксировать и коммуницировать.

Вопросы с ответами

Сервер отвечает медленно. Ваши первые шаги?

Определить область (все/часть, когда началось, что менялось), посмотреть uptime/top/vmstat/iostat (CPU, память, диск, сеть), найти процесс-потребитель, проверить логи и метрики приложения и БД, при необходимости откатить изменения или масштабировать.

df показывает свободное место, но запись невозможна. Почему?

Закончились inode (df -i), достигнута квота, ФС в режиме read-only после ошибок, либо место занято удалёнными, но открытыми файлами (для обратной ситуации).

Что делать первым при продакшн-инциденте?

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