Приёмка нового сервера: 12 проверок до первого боевого запроса

MAATRIX

Новый сервер приехал, доступ по SSH есть, хочется сразу залить туда прод и выдохнуть. И вот здесь чаще всего теряют часы или дни: диск оказывается медленнее заявленного, firewall не настроен, автообновления никто не включил, а через полгода никто не помнит, зачем на сервере открыт порт 8080. Ниже — рабочий чек-лист из 12 проверок, которые стоит пройти до того, как на сервер пошёл первый боевой трафик, а не после инцидента.

Зачем нужна приёмка, а не просто "сервер поднялся"

Провайдер прислал IP и пароль root — это не значит, что сервер готов к продакшену, это значит, что он готов к проверке. Разница в подходе простая: приёмка — это разовая процедура на 30-60 минут, которая находит проблемы, пока на сервере ещё ничего не крутится и её можно решить пересозданием инстанса, сменой тарифа или обращением в поддержку без риска простоя.

Часть проверок ловит явный брак: диск с провалами по IOPS, канал с реальной скоростью в разы ниже заявленной. Часть — закрывает организационные дыры: сервер без firewall, без ключей SSH и без мониторинга живёт "как получится" до первого сканирования ботами, которое обычно случается в первые сутки после того, как IP засветился в интернете. Дальше — все 12 проверок по порядку, с командами и тем, на что смотреть.

Проверки 1-2: реальная производительность CPU и диска

Заявленные в тарифе vCPU и NVMe — это верхняя граница, а не гарантия. На переподписанных нодах реальная производительность может заметно отличаться, и узнать это лучше в первые минуты, а не когда база начнёт тормозить под нагрузкой.

1. CPU. Быстрый прогон через sysbench:

apt install -y sysbench   # или dnf install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Смотрите на строку events per second и сравнивайте с другими серверами того же провайдера или с прошлым опытом на похожем тарифе — универсального "эталонного" числа нет, оно зависит от поколения CPU. Если результат заметно ниже, чем на аналогичном тарифе неделю назад, — повод написать в поддержку с логом теста, а не гадать самостоятельно.

2. Диск. Синтетика через fio даёт куда больше информации, чем dd:

apt install -y fio
fio --name=randrw --rw=randrw --bs=4k --size=1G --numjobs=4 \
    --runtime=60 --group_reporting --filename=/root/fio_test.img
rm -f /root/fio_test.img

Смотрите на IOPS и lat (задержку) для чтения и записи отдельно. Если провайдер в спецификации тарифа заявляет конкретные цифры IOPS — сверяйтесь с ними напрямую. Если нет — ориентируйтесь на порядок величины: NVMe должен давать задержки в единицы миллисекунд на случайной нагрузке, а не десятки. Точные цифры сильно зависят от конфигурации хоста и типа диска, поэтому не берите чужие числа как эталон — важна сама методика сравнения "заявлено vs получено".

Проверки 3-4: сетевая связность и скорость канала

Сервер может быть быстрым сам по себе и при этом плохо доступным из нужных регионов — это отдельная категория проблем, которая не видна изнутри самого сервера.

3. Связность. Проверьте доступность с нескольких точек — со своей машины, с другого сервера в другом регионе, через mtr или traceroute, чтобы увидеть, нет ли аномальных прыжков или потерь пакетов на конкретном хопе:

mtr -rw -c 50 your-server-ip

Также стоит явно проверить, что MTU на канале не режется где-то посередине — это частая причина "всё пингуется, но большие пакеты теряются":

ping -M do -s 1472 your-server-ip

Если пакет с флагом "не фрагментировать" и размером 1472 байта (1500 - 28 байт заголовков) проходит — с MTU всё в порядке.

4. Скорость. Реальную пропускную способность канала лучше не оценивать на глаз, а замерить iperf3 между сервером и точкой, откуда реально будет идти трафик (не только localhost-тестом самого провайдера):

# на сервере
iperf3 -s
# с клиента
iperf3 -c your-server-ip -t 20

Отдельно есть смысл прогнать замеры именно из региона, где физически находится сервер — про методику и подводные камни таких тестов есть отдельный разбор в статье про скорость и uptime серверов в США. Если цифры заметно ниже заявленного тарифного канала — фиксируйте результат скриншотом/логом и идите в поддержку сразу, пока сервер ещё не под нагрузкой.

Проверки 5-6: firewall и лишние сервисы с первого дня

Это тот случай, где "настрою потом" почти всегда означает "не настрою до инцидента". Открытый по умолчанию сервер сканируют ботнеты в первые часы после публикации IP.

5. Firewall. Политика по умолчанию — deny, разрешаете только то, что реально нужно. На Ubuntu/Debian через ufw:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Открывать всё "на всякий случай" — типичная ошибка, разбор того, к чему это приводит на практике, есть в статье про антипаттерн "firewall разрешить всё". Если провайдер даёт ещё и firewall на уровне хостинга (security groups, облачный firewall) — настройте его тоже: это второй рубеж на случай, если локальный firewall на сервере кто-то случайно отключит при отладке.

6. Лишние сервисы. Свежий образ ОС часто тащит сервисы, которые вам не нужны — от avahi-daemon до заранее поднятого веб-сервера с дефолтной страницей. Смотрим, что реально слушает порты:

ss -tulpn
systemctl list-unit-files --state=enabled

Всё лишнее — выключаем и отключаем автозапуск:

systemctl disable --now avahi-daemon cups

Принцип простой: каждый работающий сервис — это потенциальная точка входа и лишняя строчка в логах, за которой тоже надо следить. Меньше сервисов — меньше площадь атаки и меньше шума при разборе инцидентов.

Проверки 7-8: мониторинг и автообновления — до запуска, а не после

Ошибка, которая стоит дороже всего остального в этом списке: настраивать мониторинг и автообновления, когда сервер уже несёт прод. К этому моменту либо уже что-то упало и мониторинг ставят "по факту", либо накопился долг из непропатченных CVE.

7. Мониторинг. Минимальный набор до запуска — метрики хоста (CPU, RAM, диск, сеть) и алерт на недоступность. Быстрый вариант — node_exporter + внешний Prometheus/Grafana или Zabbix-агент, если инфраструктура уже на Zabbix:

useradd --no-create-home --shell /usr/sbin/nologin node_exporter
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-linux-amd64.tar.gz
tar xzf node_exporter-linux-amd64.tar.gz
cp node_exporter-linux-amd64/node_exporter /usr/local/bin/

и юнит systemd, запускающий его от отдельного пользователя. Отдельно стоит завести внешний uptime-чек (например, Uptime Kuma или healthchecks.io) — он покажет недоступность сервера снаружи, даже если внутренний мониторинг молчит из-за той же аварии, которая положила сервер. Важный нюанс: мониторинг, который стоит на этом же сервере и ни на что не смотрит со стороны, падает вместе с сервером и не присылает алерт — это довольно частые грабли, схожая история разобрана в материале про чек-лист безопасности нового сервера.

8. Автообновления безопасности. На Debian/Ubuntu — unattended-upgrades с ограничением только security-обновлениями (мажорные апдейты пакетов лучше катить руками и с тестом):

apt install -y unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

В /etc/apt/apt.conf.d/50unattended-upgrades оставьте включённой только ветку ${distro_id}:${distro_codename}-security, остальные — закомментируйте, чтобы не словить неожиданный мажорный апгрейд ядра в 4 утра. На RHEL-семье — аналог через dnf-automatic с apply_updates = yes только для security-репозитория.

Проверки 9-10: время и доступ по SSH

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

9. Часовой пояс и синхронизация времени. Сервер должен быть либо явно в UTC, либо в известном вам поясе — но не "как получилось у провайдера". Проверка и установка:

timedatectl
timedatectl set-timezone UTC

Синхронизация времени обязательна — рассинхрон в несколько секунд ломает TLS-хендшейки, а в минуты — вообще всё, что завязано на токены и подписи. Проверьте, что chrony или systemd-timesyncd активен и синхронизирован:

chronyc tracking
timedatectl show -p NTPSynchronized

10. SSH-ключи вместо пароля. Если провайдер выдал root-доступ по паролю — это временное состояние, а не конфигурация для продакшена. Заливаете свой публичный ключ, затем в /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin prohibit-password

и systemctl restart sshd. Перед рестартом обязательно проверьте новое подключение по ключу в отдельной сессии, не закрывая текущую — иначе при ошибке в конфиге можно остаться без доступа к серверу. Подробный разбор с частыми ошибками при переходе на ключи есть в статье про настройку SSH-ключей вместо пароля — там же про то, что делать, если ключ всё-таки потерян.

Проверки 11-12: снимок конфигурации и паспорт сервера

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

11. Первичный снимок конфигурации. Сразу после базовой настройки — до того, как на сервер начнут накатывать прикладные изменения — зафиксируйте состояние системных конфигов. Минимальный вариант — etckeeper, который кладёт /etc под git:

apt install -y etckeeper
etckeeper init
etckeeper commit "initial state after acceptance checklist"

Это не замена полноценному бэкапу, а страховка именно для системного слоя: если через месяц что-то в конфиге firewall или sshd сломается непонятно кем и когда, будет с чем сравнить. Полноценный бэкап прикладных данных — отдельная задача, которую стоит настраивать этим же вечером, а не откладывать; borgbackup для этого разобран в материале про установку и настройку borgbackup на VPS.

12. Паспорт сервера. Последний пункт — не команда, а документ. Одна страница, куда попадает всё, что иначе живёт только в памяти того, кто настраивал сервер: IP-адреса, ОС и версия ядра на момент приёмки, кто выдал доступ и когда, какие порты открыты и зачем, где лежат ключи, что настроено из этого чек-листа и с какой датой. Минимальный шаблон:

# Паспорт сервера: prod-web-01

- Провайдер / тариф: ...
- IP: ...
- ОС: Ubuntu 24.04, ядро на момент приёмки: ...
- Дата приёмки: 2026-08-XX
- Firewall: ufw, открыты 22/80/443
- Мониторинг: node_exporter -> Grafana, Uptime Kuma на внешнем чек-инге
- Автообновления: unattended-upgrades, только security
- SSH: доступ по ключу, PasswordAuthentication no
- Бэкап: borgbackup, репозиторий ..., расписание ...
- Ответственный: ...

Без этого документа приёмка проводится один раз и её результат теряется — через полгода никто не вспомнит, включён ли firewall осознанно или "как-то так получилось". С ним — приёмка становится воспроизводимой процедурой, а не разовым геройством.

Частые вопросы