Справочник команд терминала для системного администрирования и расследований

от
3

Терминал остаётся самым быстрым способом понять, что происходит с сервером: какие процессы потребляют ресурсы, где заканчивается место, какие службы слушают сеть и что менялось в логах. Графические панели удобны для обзора, но при расследовании инцидента или аварии часто нужно получить факты за минуты.https://seberd.ru/25697

Ниже — короткий справочник команд, которые полезны системному администратору, DevOps-инженеру и специалисту по информационной безопасности. Это не список «магических» one-liner-ов, а базовая карта: что смотреть, зачем смотреть и как не навредить системе во время диагностики.

1. Быстро понять состояние системы

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

uptime
free -h
df -h
top
ps aux --sort=-%mem | head
  • uptime показывает load average и помогает понять, перегружена ли система.
  • free -h показывает память и swap в читаемом формате.
  • df -h отвечает на частый вопрос: не закончился ли диск.
  • top даёт живую картину процессов.
  • ps aux --sort=-%mem | head быстро выводит процессы, которые потребляют больше всего памяти.

2. Сеть и открытые порты

Когда сервис недоступен, важно проверить не только приложение, но и сетевой уровень: слушает ли процесс порт, есть ли маршрут, отвечает ли DNS.

ss -tulpn
ip addr
ip route
resolvectl status
curl -I https://example.com
  • ss -tulpn показывает TCP/UDP-порты и процессы, которые их слушают.
  • ip addr и ip route помогают проверить адреса и маршруты.
  • resolvectl status полезен при проблемах DNS на systemd-системах.
  • curl -I быстро показывает HTTP-заголовки и статус ответа.

3. Логи: от симптома к причине

Логи лучше читать от конкретного симптома: время ошибки, имя сервиса, IP-адрес, user-agent, код ответа. Не стоит сразу выгружать гигабайты журналов — сначала сузьте окно времени.

journalctl -xe
journalctl -u nginx --since "30 minutes ago"
tail -n 100 /var/log/syslog
grep -i "error" /var/log/nginx/error.log

Для расследований полезно сохранять исходные факты: время, команду, результат, гипотезу. Это снижает риск «починить случайно» и потерять причину сбоя.

4. Аккуратность перед изменениями

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

cp nginx.conf nginx.conf.bak
nginx -t
systemctl reload nginx
systemctl status nginx --no-pager

Хороший порядок такой: сначала прочитать состояние, затем проверить гипотезу, потом внести минимальное изменение и сразу проверить результат. Это одинаково важно и для эксплуатации, и для ИБ-разбора.

Оставьте комментарий