Инструментарий сисадмина: аудит 300 серверов для MSP-компании

В марте 2026 года к нам обратилась MSP-компания ТехноПоддержка, обслуживающая IT-инфраструктуру 45 клиентов. Под управлением было 300 серверов: 210 Linux (Ubuntu, Debian, CentOS), 70 Windows Server, 20 сетевых устройств. Каждый инженер использовал свой набор утилит, документация отсутствовала, а среднее время реакции на инцидент составляло 47 минут.

Задача: стандартизировать набор инструментов, развернуть их на всех серверах через Ansible, обучить команду из 12 инженеров и сократить MTTR (Mean Time To Resolve) вдвое.

Мы разделили инструментарий на 6 категорий и для каждой подобрали проверенные утилиты с конкретными сценариями использования.

Первая группа утилит решает задачу «что происходит с процессом прямо сейчас». Это основа любого расследования инцидентов.

# strace — трассировка системных вызовов процесса
# Почему nginx возвращает 502? Смотрим, к чему обращается:
strace -f -e trace=network -p $(pgrep -o nginx)

# Типичная находка: connect() к backend возвращает ECONNREFUSED
# connect(5, {sa_family=AF_INET, sin_port=htons(8080),
#   sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED

# strace с подсчётом вызовов — ищем что тормозит
strace -c -p $(pgrep -o php-fpm) -e trace=file
# % time    seconds  usecs/call  calls  syscall
# 82.31   4.128831        45    91752  lstat
# → PHP-FPM делает 91K lstat вызовов, проблема в autoload

# perf — профилирование производительности ядра
# CPU flame graph для Java-приложения:
perf record -g -p $(pgrep -o java) -- sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg

# perf top — аналог top для функций ядра
perf top -g
# Если видите __copy_user_enhanced_fast_string → проблема с I/O

# dmesg — сообщения ядра Linux
# Последние 50 сообщений с временными метками:
dmesg -T --level=err,warn | tail -50

# Типичные находки на проблемных серверах:
# [Thu Mar 14 03:22:15 2026] Out of memory: Killed process 4523 (mysqld)
# [Thu Mar 14 03:22:15 2026] ata1.00: exception Emask 0x0 SAct 0x0
# → OOM killer убил MySQL, диск начал сыпаться

Мы установили strace, perf и sysstat на все 210 Linux-серверов через единый Ansible-плейбук. На 23 серверах CentOS 7 пришлось дополнительно собирать perf из исходников — стандартная версия была слишком старой.

Сетевые проблемы — 40% всех обращений в ТехноПоддержку. Стандартизация инструментов диагностики сети дала наибольший эффект.

# ss — замена netstat, работает мгновенно на серверах с 100K+ соединений
# Все TCP-соединения к MySQL с состоянием и таймерами:
ss -tnp state established '( dport = :3306 )'
# ESTAB  0  0  10.0.1.5:42380  10.0.2.10:3306  users:(("php-fpm",pid=4521,fd=12))

# Подсчёт соединений по состояниям — быстрая диагностика утечки:
ss -s
# TCP: 24532 (estab 18204, closed 4120, orphaned 89, timewait 2119)
# → 4120 CLOSED + 89 orphaned = утечка соединений в приложении

# nmap — аудит открытых портов (запускаем с jump-сервера)
# Быстрый скан всех серверов клиента:
nmap -sS -T4 --top-ports 1000 -oG scan_results.txt 10.0.0.0/24

# Обнаружение несанкционированных сервисов:
nmap -sV -p- --open 10.0.1.15
# 8888/tcp open http  Jupyter Notebook 6.4.0
# → Jupyter без пароля на проде! Инцидент безопасности.

# tcpdump — перехват пакетов для глубокого анализа
# Записываем трафик между app-сервером и Redis:
tcpdump -i eth0 -w /tmp/redis_traffic.pcap host 10.0.3.1 and port 6379 -c 10000

# Быстрый анализ: DNS-запросы с сервера (ищем DNS amplification)
tcpdump -i eth0 port 53 -nn -c 100

# mtr — комбинация traceroute + ping с live-статистикой
# Диагностика потери пакетов до клиентского сервера:
mtr --report --report-cycles 100 -n 185.120.45.10
# HOST                    Loss%  Snt  Last  Avg  Best  Wrst  StDev
# 1. 10.0.0.1              0.0%  100   0.5  0.4  0.3   1.2   0.1
# 2. 172.16.0.1             0.0%  100   1.2  1.1  0.9   3.4   0.3
# 3. 195.208.112.1         15.0%  100   8.4  12.3  6.1  45.2   8.7
# → 15% потерь на третьем хопе — проблема у провайдера

После внедрения стандартного набора сетевых утилит среднее время диагностики сетевых инцидентов сократилось с 35 минут до 12 минут.

Диски — самый частый аппаратный источник проблем. 18 из 300 серверов ТехноПоддержки работали с деградированными RAID-массивами, о чём никто не знал.

# iotop — аналог top для дискового I/O
# Кто нагружает диск прямо сейчас:
sudo iotop -oPa
# TID    PRIO  USER  DISK READ  DISK WRITE  COMMAND
# 4523   be/4  mysql  485.31 M   1.24 G     mysqld
# 12045  be/4  root    12.45 M   890.12 M   rsync --bwlimit=0
# → rsync без ограничения скорости убивает I/O для MySQL

# smartctl — мониторинг здоровья дисков
# Проверка SMART-статуса всех дисков на сервере:
for disk in /dev/sd?; do
    echo "=== $disk ==="
    smartctl -H $disk | grep 'SMART overall'
    smartctl -A $disk | grep -E 'Reallocated|Current_Pending|Offline_Uncorrectable'
done

# Результат с проблемного сервера:
# === /dev/sdb ===
# SMART overall-health self-assessment: PASSED
#   5 Reallocated_Sector_Ct   0x0033   098   098   036    Pre-fail  345
# → 345 переназначенных секторов! Диск на грани смерти

# blktrace + blkparse — детальный анализ I/O паттернов
# Запись трейса дисковых операций на 10 секунд:
blktrace -d /dev/sda -o trace -w 10
blkparse -i trace -d trace.bin
btt -i trace.bin

# D2C (device-to-complete) latency:
# MIN: 0.000041  AVG: 0.004521  MAX: 0.892341
# → Пиковая задержка 892 мс — диск деградирует

По результатам аудита мы заменили 6 дисков до их полного отказа, предотвратив потенциальные простои. На оставшихся серверах настроили мониторинг SMART через Telegraf с алертами в Telegram.

ТехноПоддержка использовала только Zabbix, который собирал метрики раз в минуту. Для оперативной диагностики этого недостаточно. Мы добавили два инструмента:

# Установка Netdata — мониторинг в реальном времени (1-секундная гранулярность)
bash <(curl -Ss https://my-netdata.io/kickstart.sh) --stable-channel

# /etc/netdata/netdata.conf — ключевые параметры
[global]
    memory mode = dbengine
    page cache size = 256
    dbengine multihost disk space = 2048  # 2 GB истории
    update every = 1

[web]
    bind to = 127.0.0.1  # только через SSH-туннель
    allow connections from = localhost

[plugins]
    apps = yes           # мониторинг по процессам
    proc = yes           # /proc метрики
    diskspace = yes      # дисковое пространство

# Telegraf — сбор метрик для централизованного мониторинга
# /etc/telegraf/telegraf.conf
[agent]
  interval = "10s"
  flush_interval = "10s"

[[outputs.influxdb_v2]]
  urls = ["http://monitoring.internal:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "techsupport"
  bucket = "servers"

[[inputs.cpu]]
  percpu = true
  totalcpu = true

[[inputs.disk]]
  ignore_fs = ["tmpfs", "devtmpfs", "overlay"]

[[inputs.smart]]
  path_smartctl = "/usr/sbin/smartctl"
  path_nvme = "/usr/sbin/nvme"
  use_sudo = true

[[inputs.net]]
[[inputs.netstat]]
[[inputs.processes]]
[[inputs.systemd_units]]
  unittype = "service"

Netdata стал основным инструментом для live-диагностики (каждый инженер открывал его первым при инциденте), а Telegraf собирал метрики в InfluxDB для исторического анализа и трендов в Grafana.

12 инженеров ТехноПоддержки тратили 3-4 часа в день на рутинные операции: проверки, обновления, перезапуски. Мы автоматизировали ключевые сценарии:

# tmux — мультиплексор терминала для параллельной работы
# Стандартный layout для дежурного инженера:
# ~/.tmux.conf
set -g mouse on
set -g history-limit 50000
set -g default-terminal "screen-256color"
bind | split-window -h
bind - split-window -v

# Скрипт запуска рабочего окружения дежурного:
#!/bin/bash
tmux new-session -d -s oncall
tmux send-keys -t oncall 'htop' C-m
tmux split-window -h -t oncall
tmux send-keys -t oncall 'tail -f /var/log/syslog' C-m
tmux split-window -v -t oncall
tmux send-keys -t oncall 'watch -n5 ss -s' C-m
tmux attach -t oncall

# GNU parallel — массовое выполнение команд на серверах
# Проверка uptime на всех серверах клиента:
cat servers_client42.txt | parallel -j 20 \
  'ssh -o ConnectTimeout=5 {} uptime 2>/dev/null || echo "{}: UNREACHABLE"'

# Массовый сбор версий OpenSSL (аудит CVE):
cat all_servers.txt | parallel -j 50 --tag \
  'ssh {} "openssl version" 2>/dev/null'

# Результат:
# srv-web-01    OpenSSL 3.0.13 30 Jan 2024
# srv-db-03     OpenSSL 1.1.1f  31 Mar 2020  ← УСТАРЕВШАЯ!

# expect — автоматизация интерактивных команд
# Автоматическая смена пароля на серверах без Ansible:
#!/usr/bin/expect -f
set timeout 10
set server [lindex $argv 0]
set oldpass [lindex $argv 1]
set newpass [lindex $argv 2]

spawn ssh admin@$server
expect "password:"
send "$oldpass\r"
expect "\$"
send "passwd\r"
expect "Current password:"
send "$oldpass\r"
expect "New password:"
send "$newpass\r"
expect "Retype new password:"
send "$newpass\r"
expect "\$"
send "exit\r"

После внедрения автоматизации рутинные задачи сократились с 3-4 часов до 40 минут в день на инженера.

Аудит безопасности выявил критические проблемы на 34 из 300 серверов. Стандартизированный набор инструментов безопасности теперь запускается автоматически при подключении нового сервера.

# lynis — комплексный аудит безопасности Linux
sudo lynis audit system --quick

# Ключевые находки на серверах ТехноПоддержки:
# [WARNING] No password set for single user mode (grub)
# [WARNING] Found 12 kernels. Consider cleanup
# [WARNING] PermitRootLogin is set to 'yes' in sshd_config
# [WARNING] No file integrity tool installed (AIDE, Tripwire)
# Hardening index: 54/100 — критически низкий

# aide — контроль целостности файлов
# /etc/aide/aide.conf
/bin        p+i+n+u+g+s+b+m+c+sha256
/sbin       p+i+n+u+g+s+b+m+c+sha256
/usr/bin    p+i+n+u+g+s+b+m+c+sha256
/usr/sbin   p+i+n+u+g+s+b+m+c+sha256
/etc        p+i+n+u+g+sha256
!/etc/mtab
!/etc/adjtime

# Инициализация базы
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Ежедневная проверка через cron:
0 3 * * * /usr/bin/aide --check | mail -s "AIDE report $(hostname)" security@techsupport.ru

# clamav — антивирусный сканер для Linux
# Еженедельное сканирование shared-директорий:
#!/bin/bash
LOGFILE="/var/log/clamav/weekly_scan_$(date +\%Y\%m\%d).log"
freshclam --quiet
clamscan -r --infected --log=$LOGFILE \
  /var/www/ /home/ /tmp/ /var/tmp/

INFECTED=$(grep 'Infected files:' $LOGFILE | awk '{print $3}')
if [ "$INFECTED" -gt 0 ]; then
    cat $LOGFILE | mail -s "ALERT: $INFECTED infected files on $(hostname)" \
        security@techsupport.ru
fi

После полного аудита и применения рекомендаций Lynis средний hardening index серверов вырос с 54 до 82 из 100. Все серверы с root-доступом по SSH были закрыты, настроен AIDE, Fail2Ban и автоматические обновления безопасности.

За 6 недель работы мы полностью стандартизировали инструментарий команды ТехноПоддержки:

Ansible-плейбуки для установки всего инструментария стали частью стандартной процедуры подключения нового сервера: один вызов ansible-playbook site.yml -l new_server — и через 15 минут сервер полностью оснащён для диагностики, мониторинга и аудита безопасности.