Приёмка выделенного сервера: чек-лист диагностики после аренды Ubuntu

За 17 лет работы с highload-сервисами я брал в аренду десятки dedicated-серверов. И каждый раз первый час после получения root-доступа — это не настройка проекта, а тотальная проверка железа. Потому что даже у топовых хостеров бывают «уставшие» диски и скрытые проблемы.

Облачный VPS можно пересоздать за минуту. Выделенный сервер — физическое железо с историей износа. Простой сервиса бьёт и по деньгам, и по SEO: падает аптайм, растут таймауты, страдает репутация IP. На highload-проектах «потом разберёмся» почти всегда дороже, чем 30 минут диагностики при приёмке.

Эта статья — готовый чек-лист для разработчиков и админов, которые только что получили доступ к новому dedicated на Ubuntu: 4 этапа, команды для копирования и короткий сценарий автоматизации.

• Железо: SMART, температуры, RAID, ошибки ядра
• Соответствие тарифу
• Безопасность и чистота ОС
• Сеть: пинг, потери, скорость
• Автоматизация и сохранение отчёта

1. Железо: проверяем то, что нельзя переустановить

Акцент: софт можно накатить заново. Битый диск или перегретый CPU — это простой и тикет в поддержку. На highload-сервисе битый диск = простой бизнеса и потеря клиентов.

SMART дисков

sudo apt update
sudo apt install -y smartmontools
sudo smartctl -a /dev/sda
# NVMe:
sudo smartctl -a /dev/nvme0n1

Смотрите не «PASS/FAIL» в одной строке, а конкретные атрибуты. Хостеры не всегда признают проблему гарантийной — чем раньше зафиксируете отчёт, тем проще спорить фактами.

Температуры

sudo apt install -y lm-sensors
sudo sensors-detect --auto
sensors
# Для NVMe:
sudo smartctl -A /dev/nvme0n1 | grep -i temperature

Ошибки ядра и MCE

sudo dmesg -T | grep -iE 'error|fail|mce|hardware|I/O error|ata.*exception'
journalctl -k -p err..alert --no-pager | tail -n 100

MCE (Machine Check Exception) — аппаратная ошибка CPU/памяти/шины. На свежей машине это красный флаг: не «шум в логах», а повод открыть тикет до деплоя продакшена.

RAID

# Software RAID
cat /proc/mdstat
sudo mdadm --detail /dev/md0

# Аппаратный контроллер (часто LSI/Adaptec)
sudo apt install -y megacli storcli 2>/dev/null || true
sudo storcli /c0 /vall show
# или
sudo megacli -LDInfo -Lall -aAll

Статус должен быть Optimal / [UU] для зеркала. Degraded, rebuild, missing disk — сразу в поддержку, не «подождём пока достроится» на боевом проекте.

Стресс-тест (опционально, но полезно при приёмке)

sudo apt install -y stress-ng memtester fio
# CPU + RAM ~30 минут
sudo stress-ng --cpu 0 --vm 2 --vm-bytes 75% --timeout 30m --metrics-brief
# Память (пример на 4 ГБ)
sudo memtester 4G 1
# Диск: последовательная запись/чтение
sudo fio --name=seq --filename=/tmp/fio.test --size=4G --bs=1M --rw=readwrite --iodepth=16 --runtime=60 --time_based

Зачем 30 минут при приёмке: многие дефекты памяти и питания проявляются не в idle, а под нагрузкой. Если во время теста растут температуры, сыпятся MCE или появляются I/O errors — сервер не принимаете в работу.

Срочно в поддержку:

• bad sectors / pending sectors / media errors;
• MCE или hardware errors в dmesg;
• температура CPU > 85 °C в простое;
• RAID не Optimal / degraded;
• объём RAM/дисков/сеть заметно ниже тарифа.

2. Соответствие тарифу: вам дали то, за что вы заплатили?

Быстрая сверка «ожидание vs реальность» занимает пять минут и часто ловит подмену модели CPU, не тот объём RAM или 1G вместо обещанных 10G.

lscpu
free -h
lsblk -o NAME,SIZE,TYPE,MODEL,ROTA,TRAN
sudo dmidecode -t memory
ip -br link
# замените eth0/ens3 на ваш интерфейс
sudo ethtool eth0

Совет: сохраните вывод команд в файл с датой. При споре с хостером «у вас в панели написано X» слабее, чем ваш же отчёт с timestamp с свежей машины.

3. Безопасность и чистота ОС: не доверяйте «чистой установке»

«Чистая Ubuntu от хостера» не равна hardening. Иногда на образе уже открыты лишние порты, крутятся чужие сервисы или IP успел попасть в чёрные списки после предыдущего арендатора.

Минимальный hardening

• Обновления: sudo apt update && sudo apt upgrade -y
• SSH-ключи вместо паролей, отключить root-login по паролю
• UFW: только нужные порты
• fail2ban для SSH

Подробный разбор базовой настройки — в Linux Survival Guide: SSH, UFW, Fail2ban, права и логи.

Проверка на компрометацию

ss -tulnp
ps auxf
crontab -l
sudo ls -la /etc/cron.* /var/spool/cron/crontabs 2>/dev/null
last -a | head
sudo lastb | head
# подозрительные бинарники с сетевой активностью
sudo lsof -i -P -n | head -n 50

Ищите чужие cron-задачи, неизвестные процессы с высокой CPU, слушающие порты не из вашего стека, недавние failed logins с кучей IP — типичные следы майнеров и «подарочных» бэкдоров на переиспользованном железе.

Rootkit / аудит конфигурации

sudo apt install -y lynis
sudo lynis audit system

Lynis не «лечит» сам — он даёт список предупреждений. На приёмке важны критичные findings: открытый root по паролю, слабые SSH-настройки, отсутствие автообновлений безопасности, лишние SUID-бинарники. Warnings по hardening закрывайте до деплоя приложения.

Репутация IP и PTR

curl -4 ifconfig.me
dig -x ВАШ_IP +short
# быстрая проверка DNS-резолвинга
dig google.com +short

Почему это критично для SEO-сервисов и почты: «грязный» IP или отсутствующий/кривой PTR ломает доставку писем, мешает парсингу и внешним API, а в худшем случае тянет репутационный хвост на домен. Чистая микроразметка помогает SEO — аналогично, чистое железо и чистый IP помогают аптайму и доверию. Практический разбор разметки: руководство по Schema.org.

4. Сеть: пинг, потери, реальная скорость

Интерфейс «Link detected: yes» ещё не значит, что канал пригоден для продакшена.

mtr до шлюза и внешних точек

sudo apt install -y mtr-tiny
ip route | awk '/default/ {print $3}'
# 100 проб до шлюза (подставьте IP gateway)
sudo mtr -rwzc 100 ШЛЮЗ
# контрольная точка наружу
sudo mtr -rwzc 100 1.1.1.1

Как читать вывод: смотрите Loss% и рост Latency по хопам. Допустимые потери на шлюзе — ориентир < 0.5%. Потери на дальних хопах бывают нормальны (ICMP rate-limit); потери на 1–2 хопе внутри ДЦ — уже проблема провайдера.

iperf3: реальная пропускная способность

sudo apt install -y iperf3
# публичные тестовые серверы меняются — выберите ближайший к ДЦ
iperf3 -c скорость.сервер.пример -P 4
iperf3 -c скорость.сервер.пример -R -P 4

Сверяйте результат с тарифом (1G ≈ до ~900–940 Mbit/s полезной нагрузки, 10G — соответственно выше). Если ethtool показывает 10G, а iperf едва тянет 200 Mbit/s без объяснимой причины — фиксируйте и пишите в поддержку.

DNS

resolvectl status
dig google.com
dig @1.1.1.1 abramov.top

Если резолвинг нестабилен — смените резолверы (Cloudflare/Google/провайдерские) до того, как на сервер поедет CI, почта и мониторинг.

5. Автоматизация: one-liner для быстрого старта

Не обязательно собирать зоопарк утилит. Выберите инструмент под задачу.

sudo apt install -y smartmontools lm-sensors lshw net-tools curl wget inxi mtr-tiny
# Паспорт железа
sudo inxi -Fxz > /root/server_audit_$(date +%F).txt
# SMART всех дисков
for d in /dev/sd? /dev/nvme?n1; do
  [ -b "$d" ] || continue
  echo "===== $d =====" >> /root/server_audit_$(date +%F).txt
  sudo smartctl -a "$d" >> /root/server_audit_$(date +%F).txt 2>&1
done
# Быстрый бенч (YABS)
curl -sL yabs.sh | bash | tee -a /root/server_audit_$(date +%F).txt

Зачем сохранять отчёт: при будущих проблемах это ваше доказательство, что сервер был исправен (или уже неисправен) при приёмке. Хостеры меняют диски и коммутацию — ваш файл с датой остаётся фактом.

Заключение

30 минут диагностики экономят дни простоя и нервы. Порядок простой: железо → тариф → безопасность → сеть → отчёт в файл. Только после этого ставьте Nginx, PHP, Docker/Podman и деплойте проект.

Дальше по экосистеме:

• Linux Survival Guide — базовая настройка и hardening Ubuntu;
• Schema.org для SEO — как структурированные данные усиливают выдачу (так же, как чистое железо усиливает аптайм).

Нужна помощь с аудитом сервера или настройкой highload-сервиса — напишите мне в Telegram или через страницу контактов.

Поделитесь в комментариях, какие сюрпризы находили при приёмке dedicated-серверов. Логичное продолжение — мониторинг и алертинг: чтобы проблемы ловить до звонка от клиента.