Troubleshooting-сценарии

Что отвечать

`uptime` - load average и время аптайма (только что ребутался?). `top -bn1 | head -20` - кто жрёт CPU прямо сейчас. `vmstat 1 5` - CPU/IO/swap по тикам. `dmesg --since "1 hour ago"` - OOM, kernel-ошибки, выкинутый диск. `df -h && df -i` - место и inode'ы. Это даёт картину «процесс/память/диск» за 30 секунд, дальше уже целевая диагностика.

Что хотят услышать

Senior должен: - назвать порядок «снизу вверх»: сначала ресурсы (CPU/RAM/IO/disk), потом сетевые connections, потом application - упомянуть USE method (Brendan Gregg): для каждого ресурса - Utilization, Saturation, Errors - сказать что `top` показывает мгновенный снимок, для тренда нужны Prometheus/Grafana, для прошлого - `sar` (sysstat) - назвать `ss -s` для summary connections, `iostat -x 1 5` для дисков - не лезть сразу в strace/perf - это инструменты второго эшелона, когда первые пять команд уже сузили область

Подводные камни

• ✗ Сразу запускать tcpdump или strace - слишком узко без контекста
• ✗ Не проверить `dmesg` - там часто прямой ответ (OOM, hardware error)
• ✗ Забыть `df -i` - inode-exhaustion даёт «no space» при свободном месте

Follow-up

• ? Что покажет `vmstat 1 10` и какие колонки самые важные?
• ? Чем USE-method отличается от RED-method?
• ? Где смотреть тренд за последние сутки если Prometheus не было?

Что отвечать

Процессы в LA считаются как Runnable (R, ждут CPU) и Uninterruptible Sleep (D, ждут I/O). Если CPU свободен - значит куча процессов в D-state, обычно из-за медленного диска или NFS, который завис. Смотри `ps -eo state,pid,cmd | awk '$1 ~ /^D/'` - увидишь кто. Дальше `iostat -x 1` и `iotop` - кто и куда генерит I/O.

Что хотят услышать

Кандидат должен: - объяснить состав LA: R + D, не только R - назвать D-state как главного подозреваемого при «LA высокий, CPU низкий» - обычно диск/NFS/iSCSI - сказать что процесс в D-state не убить даже kill -9, потому что он в syscall'е внутри ядра - назвать `iostat`, `iotop`, `/proc/<pid>/io`, `/proc/<pid>/stack` как инструменты копать дальше - упомянуть что NFS-mount без `soft,intr` может намертво залипнуть, утянув за собой кучу процессов

Подводные камни

• ✗ Сказать «LA это CPU» - нет, это R+D процессы
• ✗ Не вспомнить про D-state как причину
• ✗ Считать что perf/profiler помогут - нет, профайлер видит CPU, а здесь проблема в I/O wait

Follow-up

• ? Что такое `iowait` в выводе `top` и как он связан с D-state?
• ? Чем отличается `mount -t nfs soft` от `hard`?
• ? Как убить процесс, застрявший в D-state на отвалившемся NFS?

Что отвечать

Открытые удалённые файлы. Кто-то держит fd на гигабайтный лог, который был `rm`'нут - ядро не освобождает блоки пока fd открыт, но `du` его уже не видит. Решение: `lsof | grep deleted` найдёт виновника, дальше reload процесса (SIGHUP для большинства демонов) или рестарт. Альтернатива: `truncate -s 0 /proc/<pid>/fd/N` - освободит блоки без рестарта процесса.

Что хотят услышать

Senior должен: - назвать `lsof | grep deleted` первой командой - это закрывает большинство кейсов - объяснить почему «truncate через /proc/PID/fd/N» работает: это тот же файл, который держит процесс, просто без directory entry - назвать второй частый кейс: процесс пишет в файл, который лежит ПОД точкой монтирования. Если FS примонтировали поверх непустого каталога, файлы под mount-point продолжают занимать место, но не видны через `du /` пока не сделать `umount` - упомянуть reserved blocks (`tune2fs -m 0` чтобы освободить 5%) как aggressive last resort

Подводные камни

• ✗ Сразу искать большие файлы через `du` - `du` их не покажет
• ✗ Делать `rm` ещё раз - файла уже нет, fd всё равно держит блоки
• ✗ Рестартить весь сервис, когда хватило бы SIGHUP

Follow-up

• ? Как `logrotate` это решает штатно? Что делает `copytruncate`?
• ? Что произойдёт если сделать `> /proc/PID/fd/N`?
• ? Почему рестарт демона освобождает место мгновенно?

Что отвечать

`dmesg | grep -i oom` или `journalctl -k --grep=oom` покажет жертву и кто её убил (kernel или systemd-oomd). Дальше: смотри `oom_score` процесса и его cgroup-лимит. Если лимит в cgroup ниже реальной потребности - нужно или поднять лимит (`memory.max` в cgroups v2), или починить утечку. Если лимита не было и убил kernel OOM - смотри график потребления памяти и кто соседи по нагрузке.

Что хотят услышать

Senior должен: - различить kernel OOM (нет памяти на хосте) и cgroup OOM (превышен лимит контейнера/сервиса) - это разные сценарии - назвать `memory.high` как graceful backpressure-механизм в v2 вместо жёсткого `memory.max` - сказать что `oom_score_adj=-1000` делает процесс неуязвимым - используется для критичных компонентов (sshd, например) - упомянуть что swap НЕ спасает от OOM в долгосрочной перспективе, только оттягивает; thrashing обычно хуже честного OOM - назвать что в Kubernetes OOM в контейнере = pod restart с reason `OOMKilled`, видно через `kubectl describe pod`

Подводные камни

• ✗ Думать что OOM это всегда нехватка хост-памяти - может быть cgroup-лимит при свободной хост-памяти
• ✗ Поставить `oom_score_adj=-1000` везде - система останется без механизма самовосстановления
• ✗ Включить swap как «фикс» - обычно даёт деградацию вместо OOM

Follow-up

• ? Чем `systemd-oomd` отличается от kernel OOM?
• ? Что покажет `memory.events` в cgroup v2?
• ? Как `earlyoom` срабатывает раньше kernel OOM и зачем он нужен?

Что отвечать

Ping работает по IP - значит сетевая связность есть. curl падает - значит резолв имени сломан. Проверь: `dig example.com` напрямую (минует glibc-cache) → `cat /etc/resolv.conf` → `getent hosts example.com` (через NSS, как делает curl). Расхождение `dig` и `getent` укажет где сломано: NSS, `/etc/hosts` override, либо systemd-resolved.

Что хотят услышать

Senior должен: - различить путь curl (NSS → resolved → upstream DNS) и путь dig (напрямую в указанный nameserver) - назвать что ping тоже идёт через NSS, но если у юзера сразу IP в команде - резолв не нужен; «ping по IP работает» в задаче означает что network OK - проверить `/etc/nsswitch.conf` строку `hosts:` - порядок имеет значение, иногда `files` подмонтирован через override - упомянуть что в Docker-контейнере свой `/etc/resolv.conf` (от Docker DNS), а в k8s - от CoreDNS, путь резолва другой

Подводные камни

• ✗ Сразу делать `dig @8.8.8.8 example.com` - обходит твой resolver, не покажет проблему
• ✗ Думать что `nslookup` адекватный инструмент - устарел, скрывает половину информации, используй `dig`
• ✗ Не проверить `/etc/hosts` - банальный override часто причина

Follow-up

• ? Чем `getent hosts X` отличается от `dig X`? Когда дадут разный ответ?
• ? Как посмотреть кэш systemd-resolved и очистить его?
• ? Что происходит при `search example.com.` в `/etc/resolv.conf`?

Что отвечать

Три варианта где обрыв. `ss -tn state established | grep <port>` - если соединение есть в Established, проблема в приложении (не отвечает). Если нет - `tcpdump -i any port N` покажет: SYN ушёл и нет SYN-ACK (drop в файрволе или сервер не слушает), или SYN-ACK пришёл и нет финального ACK (router drop, MTU blackhole). Параллельно `dmesg` и `conntrack -L` - может conntrack-таблица переполнена.

Что хотят услышать

Senior должен: - назвать ss как первый инструмент, tcpdump - второй - различить три класса причин: network (SYN не доходит), firewall (DROP или conntrack overflow), application (соединение есть, но handler залип) - упомянуть `nf_conntrack_max` и `nf_conntrack_count` как проверку на overflow - типичный SRE-инцидент под нагрузкой - назвать MTU blackhole как редкую но злую причину: handshake проходит, потом первый большой пакет тонет и нет ICMP обратно (firewall режет ICMP)

Подводные камни

• ✗ Сразу tcpdump на полную ленту - забьёт диск, нужны фильтры
• ✗ Не проверить conntrack - типично игнорируется
• ✗ Сказать «увеличить timeout» - лечит симптом, не причину

Follow-up

• ? Как отличить «firewall дропнул SYN» от «сервер не слушает» в tcpdump?
• ? Что показывает `ss -i -t` (с info по TCP-стейту)?
• ? Как настроить detection MTU blackhole с tracepath?

Что отвечать

137 = 128 + 9, значит процесс убит SIGKILL. Обычно это OOM или kubelet/Docker превысил `memory.max`. Проверь: `docker inspect <id>` - `OOMKilled: true` и `ExitCode: 137` подтвердят OOM. `dmesg` покажет kernel-сторону, `kubectl describe pod` (если k8s) - что лимит сработал. Лечение: поднять memory limit, либо починить утечку в приложении.

Что хотят услышать

Кандидат должен: - расшифровать exit codes: 128+N значит killed by signal N (130 = SIGINT/Ctrl+C, 137 = SIGKILL, 139 = SIGSEGV, 143 = SIGTERM) - назвать `docker inspect` и `kubectl describe pod` как источники истины для exit reason - объяснить разницу между OOM-kill хоста и cgroup-OOM - в Docker/k8s обычно второе - упомянуть liveness/readiness probes как другую причину перезапусков (probe failure → restart)

Подводные камни

• ✗ Перепутать exit code 137 (SIGKILL) с 139 (SEGV) - разные причины
• ✗ Думать что 137 это всегда OOM - может быть просто `docker kill`
• ✗ Не проверить probes - типичная причина «pod рестартится каждые 30 секунд»

Follow-up

• ? Что значит exit code 143 и в каком случае его увидишь?
• ? Чем `restartPolicy: OnFailure` отличается от `Always` в k8s?
• ? Как настроить разумный memory limit, если приложение бьётся?

Что отвечать

Cron бежит с минимальным окружением: PATH обычно `/usr/bin:/bin`, нет твоего `.bashrc`, HOME может быть `/`. Скрипт работает в shell, но падает в cron - почти всегда из-за этого. Проверка: `cat /var/log/syslog | grep CRON` (или `journalctl -u cron`) покажет был ли запуск. Если запускался и упал - добавь `>>/tmp/cron.log 2>&1` в crontab-строку чтобы увидеть stderr.

Что хотят услышать

Senior должен: - назвать минимальный PATH и отсутствие dotfiles как главную причину «работает в shell, не работает в cron» - сказать что cron не открывает терминал, поэтому `tput`, `read`, `sudo -A` сломаются - упомянуть `MAILTO` в crontab - куда летит stderr по умолчанию (если есть локальный MTA) - назвать systemd timers как современную альтернативу с гораздо большим контролем (env, restart, dependencies) - предложить `env -i bash -c '<команда>'` как способ воспроизвести cron-окружение в shell

Подводные камни

• ✗ Думать что cron унаследует `.bashrc` юзера - нет, это не login shell
• ✗ Использовать `~` в путях - HOME может быть не таким как ожидаешь
• ✗ Не редиректить stderr - сообщения об ошибках теряются

Follow-up

• ? Зачем нужен `MAILTO=""` в начале crontab?
• ? Чем systemd timer лучше cron для production?
• ? Как сделать чтобы cron-задание не запускалось параллельно с предыдущим экземпляром?