Перейти к содержанию

10. Troubleshooting: подход production-инженера

Типовые кейсы (сервер тормозит, закончился диск, сервис не стартует, нет сети, упал после рестарта) и системный алгоритм диагностики: CPU/память/диск, логи, сеть, права, последние изменения.

Типовые кейсы

Сервер «тормозит»

  • Load average и CPU: top, htop — высокий load при высоком %CPU означает перегрузку процессора; при высоком load и низком CPU — часто I/O wait (диск или сеть). Смотреть столбец wa в top, iostat -x 1, vmstat 1.
  • Память и swap: free -h — занята ли RAM, активен ли swap. Активный swap даёт задержки. Топ процессов по памяти: ps -eo pid,rss,cmd --sort=-rss | head.
  • Диск: iostat, iotop — кто читает/пишет; не заполнен ли раздел и inode (df -h, df -i).
  • Сеть: при подозрении на сетевую перегрузку — ss, nethogs, трафик по интерфейсам.

См. разделы 4. Процессы, CPU, память и 2. Файловая система и диски.

Закончился диск

  • Место: df -h — какой раздел заполнен (часто /, /var, /var/log).
  • Inode: df -i — при свободных гигабайтах «No space left» часто из-за исчерпания inode (много мелких файлов).
  • Кто съел: du -sh /var/*, du -sh /var/log/*; часто логи, кэш, временные файлы.
  • Удалённые файлы, ещё открытые: lsof +L1 — не освобождают место до закрытия; перезапуск сервиса освобождает.
  • Действия: очистка логов (logrotate, ручное удаление), расширение тома (LVM) или перенос данных.

См. раздел 2. Файловая система и диски.

Сервис не стартует

  • Логи unit’а: journalctl -u <unit> -n 100 --no-pager — там обычно причина: ошибка конфига, порт занят, permission denied, отсутствующий файл или зависимость.
  • Зависимости: unit может ждать другой unit (After=, Requires=); проверить systemctl list-dependencies, состояние зависимостей.
  • Права и владелец: конфиг или рабочий каталог с неверными правами; проверить путь из unit и ls -la.
  • Порт занят: ss -tlnp — не слушает ли другой процесс нужный порт.

См. разделы 1. Архитектура и основы ОС, 6. Логи и observability, 3. Пользователи и безопасность.

Нет сети

  • Линк и адрес: ip link, ip addr — интерфейс up, есть ли IP.
  • Маршрут: ip route, ip route get <цель> — куда уходят пакеты, есть ли default route.
  • DNS: cat /etc/resolv.conf, dig hostname, dig @8.8.8.8 hostname — резолвится ли имя, доступен ли резолвер.
  • Firewall: iptables -L -n -v, nft list ruleset — нет ли DROP для нужного трафика в INPUT/FORWARD.
  • Слушающий адрес: сервис может слушать только 127.0.0.1 — тогда снаружи недоступен; ss -tlnp.

См. разделы 5. Сеть в Linux и 6. Linux Networking в разделе Networking.

Упал после рестарта

  • Что изменилось при перезагрузке: конфиги в /etc, fstab, сеть (DHCP дал другой IP?), зависимости пакетов после обновления.
  • Логи загрузки и сервисов: journalctl -b — что происходило при старте; journalctl -u <unit> -b — почему unit не поднялся.
  • Логи ядра: journalctl -k -b, dmesg — OOM, ошибки диска, драйверов.
  • Файловая система и монтирование: не смонтировался ли раздел (ошибка в fstab, отсутствует устройство), не изменился ли UUID диска.

Систематически: сравнить текущее состояние с тем, что было до рестарта (конфиги, список пакетов, вывод mount, ip, systemctl).

Алгоритм диагностики

Один и тот же порядок помогает не пропустить очевидное и быстрее выйти на причину.

1. CPU / Memory / Disk

Сначала базовые ресурсы: не перегружен ли CPU, не закончилась ли память (и не ушло ли всё в swap), не заполнен ли диск и inode. Команды: top, free -h, df -h, df -i. Если здесь проблема — дальше искать, кто потребляет (процессы, каталоги, логи).

2. Logs

Логи сервиса и ядра часто сразу дают причину: ошибка конфига, порт занят, OOM, сбой диска. journalctl -u <unit>, journalctl -k, dmesg. При любом инциденте смотреть логи в первую очередь после проверки ресурсов.

3. Network

Если симптом «не доступен» или «не резолвится»: линк, адрес, маршрут, DNS, firewall, на каком адресе слушает сервис. Не предполагать «сеть работает» — проверить по шагам с проблемного хоста.

4. Permissions

«Permission denied», сервис не может прочитать конфиг или записать в каталог — проверить владельца, права, ACL, при необходимости SELinux/AppArmor. Не решать проблему chmod 777 без понимания причины.

5. Recent changes

Что менялось перед инцидентом: обновления пакетов, смена конфига, рестарт, добавление диска, смена сети. Часто причина в последнем изменении; откат или точечное исправление конфига восстанавливает работу.

!!! tip "Практика"

Чек-лист при любом инциденте: (1) Ресурсы — CPU, память, диск/inode; (2) Логи — unit и ядро; (3) Сеть — если касается доступности; (4) Права — если отказ в доступе к файлам; (5) Что меняли недавно. Так вы не тратите время на второстепенное и быстрее находите root cause.

Паттерны и антипаттерны

Паттерн Описание
Идти по алгоритму Ресурсы → логи → сеть → права → изменения. Не прыгать наугад.
Фиксировать состояние до правок Снимки конфигов, вывод команд — чтобы откатиться или сравнить.
Один шаг за раз Менять одну вещь, проверять; иначе непонятно, что помогло.
Антипаттерн Почему плохо Что делать
Менять всё подряд Теряется причинно-следственная связь, сложно откатить. Менять по одному, проверять, документировать.
Игнорировать логи В логах часто уже написана причина. Всегда смотреть journalctl и dmesg при сбоях.
Полагаться на «у меня работает» Окружение (сеть, версии, конфиг) может отличаться. Проверять на проблемном хосте и в том же окружении.

Дополнительные материалы