Ежемесячное ТО сервера: что сделать в первый рабочий день месяца

MAATRIX

Еженедельный регламент ловит быстро всплывающие проблемы — забитый диск, упавший бэкап, просроченный SSL. Но есть класс граблей, которые копятся месяцами и вскрываются только тогда, когда уже поздно: бэкап, который два года никто не пробовал развернуть; диск, который забьётся не завтра, а через шесть недель, если тренд не переломить; пакет с дырой в CVE, который стоит с прошлой весны, потому что «работает — не трогай». Для этого нужна отдельная, более глубокая ревизия — и удобнее всего привязать её не к дате вроде «1-го числа» (которое падает то на субботу, то на праздник), а к первому рабочему дню месяца. Это статья про то, что конкретно в этот день проверить и как не превратить чек-лист в формальность для галочки.

Почему именно первый рабочий день месяца

Дата вроде «каждое 1 число» ломается о календарь: 1 января — праздник, 1 мая — тоже, случайное воскресенье — тем более. Если регламент привязан к жёсткой дате, он либо переносится каждый раз вручную (и тогда быстро забывается), либо выполняется по инерции в выходной, когда вы явно не в рабочем настроении разбирать логи ротации сертификатов.

Первый рабочий день месяца — самоочевидный якорь: он есть всегда, не требует сверки с производственным календарём и совпадает с моментом, когда вы и так открываете почту, таск-трекер и, скорее всего, бухгалтерию за прошлый месяц. Практический приём — завести повторяющуюся задачу в календаре или таск-менеджере с правилом «первый будний день» (в Google Calendar и большинстве трекеров это стандартный тип повторения), а не хардкодить число. Второй приём — привязать чек-лист к событию, которое и так уже привычно: закрытию месяца в биллинге, если вы ведёте учёт расходов на инфраструктуру.

Cron для автоматической части (см. ниже) можно оставить на фиксированное число — расхождение в 1-3 дня с «первым рабочим» для автоматики не критично, речь про удобство именно ручной, вдумчивой части ревизии.

# автоматический прогон отчёта на 1 число, 07:00 —
# ручной разбор всё равно делаете в свой первый рабочий день
0 7 1 * * /usr/local/bin/monthly-server-report.sh | mail -s "Monthly report $(hostname)" you@example.com

Тестовое восстановление из бэкапа

Это пункт, который еженедельный регламент обычно не потянет по времени, а раз в месяц — самое то. Смысл прост: бэкап, который никогда не разворачивали, с точки зрения надёжности неотличим от его отсутствия. Как проверить, что бэкап рабочий — отдельная большая тема, здесь — минимальный ежемесячный ритуал.

Выберите один компонент (в ротации — по очереди все важные: база данных, конфиги, docker volume с пользовательскими данными) и разверните его бэкап в изолированной среде — на тестовой VM или хотя бы в отдельном docker-контейнере, не трогая прод.

Пример для дампа PostgreSQL:

# поднимаем чистый контейнер
docker run -d --name pg-restore-test -e POSTGRES_PASSWORD=test postgres:16

# ждём старта и заливаем последний дамп
sleep 5
gunzip -c /backups/pg/latest.sql.gz | docker exec -i pg-restore-test psql -U postgres

# проверяем, что данные реально там и в разумном объёме
docker exec pg-restore-test psql -U postgres -c "SELECT count(*) FROM public.orders;"

# сверяем с ожидаемым порядком величины (не точным числом — оно у вас своё)
docker rm -f pg-restore-test

Для docker volume — аналогично: восстановить в отдельный volume и открыть/примонтировать, проверив, что файлы читаются, а не просто «архив распаковался без ошибок». Ошибка при распаковке — это одно, а битые внутри архива данные при чистой распаковке — совсем другое, и именно второе чаще всего вскрывается только на реальном восстановлении.

Фиксируйте результат в лог (файл, таск-трекер, что угодно) с датой и компонентом — иначе через три месяца вы не вспомните, когда в последний раз реально пробовали поднять базу из бэкапа, а не просто смотрели, что job завершился с кодом 0.

Ревизия дискового пространства с прогнозом

Еженедельная проверка обычно ограничивается вопросом «сколько свободно сейчас». Ежемесячная должна отвечать на вопрос «когда закончится, если ничего не менять» — а это требует истории, а не снимка.

Если у вас есть Prometheus/Zabbix/Netdata — прогноз почти бесплатный:

# для Prometheus + node_exporter: линейная экстраполяция по последним 6 часам
# результат — секунды до заполнения диска
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 86400 * 30)

Если мониторинга с историей нет, самый дешёвый способ — вести собственный лог df раз в сутки через cron и считать линейный тренд руками:

# добавить в cron: раз в сутки
echo "$(date +%F) $(df --output=avail -B1 / | tail -1)" >> /var/log/disk-history.log

# раз в месяц — грубая оценка тренда за последние 30 дней
awk 'NR==1{first=$2; d1=$1} END{
  days=(NR-1);
  if (days>0) {
    rate=(first-$2)/days;
    print "Свободно сейчас:", $2/1073741824, "GB";
    print "Расход в сутки:", rate/1073741824, "GB/day";
    if (rate>0) print "Хватит примерно на", int($2/rate), "дней";
  }
}' /var/log/disk-history.log

Это грубая линейная оценка — реальный расход почти никогда не линеен (логи растут скачками при инцидентах, бэкапы — при добавлении новых баз), но даже такая прикидка лучше, чем разовый снимок «занято 61%», который ничего не говорит о скорости приближения к 100%. Если по прогнозу до заполнения меньше 60 дней — это повод спланировать расширение диска или чистку заранее, а не в ночь аврала. Разбор по каталогам, кто конкретно ест место — du -h --max-depth=2 / 2>/dev/null | sort -rh | head -20 — тоже стоит делать не только по факту проблемы, а на регулярной основе, чтобы видеть, что растёт быстрее ожидаемого.

Проверка сертификатов на горизонте месяца

Еженедельная проверка обычно смотрит на срок в 7-14 дней — этого достаточно, чтобы не пропустить критичный момент, но не хватает на спокойное планирование. Ежемесячная ревизия должна смотреть на горизонт 30-45 дней и охватывать не только веб-сертификаты, но и внутренние: для VPN, для внутренних API, для клиентских сертификатов IKEv2/OpenVPN, если они у вас есть.

# проверка всех сертификатов Let's Encrypt на сервере разом
for cert in /etc/letsencrypt/live/*/cert.pem; do
  domain=$(basename $(dirname "$cert"))
  end=$(openssl x509 -enddate -noout -in "$cert" | cut -d= -f2)
  end_epoch=$(date -d "$end" +%s)
  now_epoch=$(date +%s)
  days_left=$(( (end_epoch - now_epoch) / 86400 ))
  echo "$domain: $days_left дней"
done

Для сертификатов не на этом сервере (например, у поставщика или в другом ЦОД) — та же логика, но через openssl s_client:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

Отдельно стоит сверить: не остался ли где-то самоподписанный сертификат вместо нормального (частая история во внутренних сервисах, поднятых «на скорую руку») и не истекает ли промежуточный сертификат в цепочке — сама точка входа может обновляться исправно, а забытый intermediate обрушить проверку у части клиентов. Подробнее про эти грабли и автопродление — в статье про мониторинг сертификатов и доменов. Если у вас настроен certbot с systemd-таймером, стоит раз в месяц явно прогнать certbot renew --dry-run, чтобы убедиться, что автопродление действительно сработает, а не просто «таймер существует».

Ревизия установленных пакетов

Еженедельно вы, скорее всего, просто накатываете security-патчи. Раз в месяц стоит взглянуть шире — что вообще стоит на сервере и зачем.

Список пакетов с датой последнего обновления (Debian/Ubuntu):

# что не обновлялось дольше 90 дней
grep -oP '(?<=^Start-Date: ).*' /var/log/apt/history.log | sort -u | tail -5
apt list --upgradable 2>/dev/null

Более полезный практический шаг — найти пакеты, которые стоят, но не используются. Универсального инструмента нет, но есть приближения:

# пакеты, установленные вручную (не как зависимости) — кандидаты на ревизию
apt-mark showmanual

# systemd-сервисы, которые в принципе есть на диске, но не enabled и не running —
# кандидаты на удаление, если это не намеренный резерв
systemctl list-unit-files --state=disabled

# то же самое приближение для RHEL/AlmaLinux
dnf history list | tail -20
dnf list installed | grep -v @System

Отдельно проверьте версии критичных сервисов (nginx, СУБД, среды выполнения) на соответствие текущим LTS/stable-веткам вендора — сильно устаревшая минорная версия иногда означает, что вы уже пропустили несколько security-релизов, даже если apt upgrade формально «ничего не находит» (пакет мог зависнуть на старой ветке репозитория). Если сервер разворачивался «с нуля» по общей методичке, сверьтесь с исходным чек-листом установки — например, обновление и обслуживание Ubuntu 24.04 — не отклонилась ли текущая конфигурация от задуманной за месяцы точечных правок.

Полностью убирать пакет с продакшена в тот же день не стоит — сначала отключите сервис и понаблюдайте неделю-две, чтобы не оказалось, что «неиспользуемый» демон на самом деле кому-то нужен раз в квартал.

Сверка пользователей и доступов

Самая скучная часть ревизии — и самая важная с точки зрения безопасности, потому что доступы имеют свойство накапливаться и никогда не сокращаться сами. Подрядчик, который закончил проект в марте, сотрудник, который сменил роль, тестовый аккаунт, который «временно» завели полгода назад — всё это должно попадать в ежемесячный разбор, а не ждать, пока кто-то случайно наткнётся.

# все пользователи с интерактивным шеллом (не системные)
awk -F: '$7 !~ /nologin|false/ {print $1, $7}' /etc/passwd

# кто состоит в sudo/wheel
getent group sudo   # Debian/Ubuntu
getent group wheel  # RHEL/AlmaLinux

# авторизованные SSH-ключи по каждому пользователю — источник тихо забытых доступов
for u in $(awk -F: '$7 !~ /nologin|false/ {print $1}' /etc/passwd); do
  f="/home/$u/.ssh/authorized_keys"
  [ -f "$f" ] && echo "=== $u ===" && cat "$f"
done

# последний вход каждого пользователя — молчащий аккаунт полгода это красный флаг
lastlog

Пройдитесь по списку и на каждую строку задайте прямой вопрос: «этот человек всё ещё должен иметь доступ именно к этому серверу?» Сверьте с HR/списком активных подрядчиков, если он у вас формально ведётся. Отдельно проверьте доступы в панели управления хостинга и в облачных консолях — там форма другая, но принцип тот же: сверить список активных пользователей с тем, кто реально должен там быть сейчас. Тема ухода сотрудника и что с этим делать разобрана отдельно — сотрудник уволился, а доступ остался — если такая ситуация у вас уже случалась, стоит превратить разовый разбор в постоянный пункт этого чек-листа.

Заодно проверьте sudoers на предмет строк вроде NOPASSWD: ALL, оставленных «для удобства» во время какого-то деплоя и так и не убранных:

grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

Сводный чек-лист и как его вести

Чтобы ежемесячная ревизия не превратилась в открытие терминала «на удачу», удобно держать её как чек-лист с чекбоксами — в issue-трекере, в заметках, где угодно, лишь бы с историей выполнения.

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

Если у вас несколько серверов, чек-лист стоит вести по каждому отдельно — прогноз диска и список пользователей у них разный, а объединять «на глаз» — верный способ что-то пропустить.

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