Ритуал перед длинными выходными: что проверить на сервере в пятницу

MAATRIX

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

Чем пятница перед длинными выходными отличается от обычной

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

Это меняет расчёт по каждому пункту инфраструктуры не качественно, а количественно — запас, который был комфортным на двое суток, превращается в тесный на пять. Диск, которого хватало «с запасом до понедельника», может закончиться в субботу вечером, если фоновый рост логов или бэкапов не остановится сам собой. Сертификат, до истечения которого было «ещё полторы недели», может протухнуть ровно в те дни, когда никто не смотрит на алерты и не может руками перевыпустить его через панель. Автообновление, которое обычно чинится одним apt --fix-broken install через полчаса после инцидента, в выходные простоит сломанным весь период.

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

Диск: запас на весь период без вмешательства

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

# текущее состояние по разделам
df -h

# кто съедает место прямо сейчас — топ каталогов
du -sh /var/log/* /var/lib/docker/* /home/*/backups/* 2>/dev/null | sort -rh | head -20

# отдельно докер: образы, тома, кэш сборки
docker system df

# скорость роста за последние сутки, если ведёте историю df в мониторинге —
# иначе грубая оценка по логам за последние 24 часа
find /var/log -mtime -1 -type f -exec du -ch {} + | tail -1

Если под рукой есть Grafana или Zabbix с историей метрики диска — посмотрите наклон графика за неделю и умножьте суточный прирост на число дней выходных плюс день-два про запас. Если истории нет, грубое правило: свободного места должно быть не меньше, чем удвоенный обычный суточный прирост, умноженный на длину периода без присмотра. Подробнее про то, как вообще считать разумный запас, — в статье сколько дискового пространства закладывать с запасом.

Конкретные действия перед выходными, если запас выглядит тесным:

• Прогнать ротацию логов вручную, не дожидаясь планового logrotate, если конфиг настроен на еженедельный, а не ежедневный прогон:

logrotate -f /etc/logrotate.conf

• Почистить неиспользуемые образы и тома Docker, если они копились месяцами:

docker image prune -a -f --filter "until=168h"
docker volume prune -f

• Проверить политику ротации бэкапов — если старые копии не удаляются автоматически, за четыре ночи может набежать заметный объём. Для borgmatic или restic это обычно вопрос одной строки keep-daily в конфиге.
• Отдельно проверить временные каталоги и директории загрузки — они растут непредсказуемо и не всегда попадают под стандартную ротацию логов.

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

Сертификаты: ничего не истекает в ближайшие дни

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

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

# что фактически отдаёт сервер прямо сейчас, а не что лежит в конфиге certbot
for d in example.com www.example.com api.example.com; do
  echo -n "$d: "
  echo | openssl s_client -servername "$d" -connect "$d:443" 2>/dev/null \
    | openssl x509 -noout -enddate
done

# список сертификатов certbot и когда они реально продлятся
certbot certificates

# симуляция продления без реальной замены — покажет, сломано ли что-то
certbot renew --dry-run

Три вещи, на которые стоит обратить внимание в выводе:

• Дата в openssl s_client расходится с датой в certbot certificates. Это значит, что сервис (nginx, Traefik, балансировщик) отдаёт не тот сертификат, что лежит в актуальной копии, — классическая ситуация, когда сертификат обновился на диске, но процесс его не перечитал.
• certbot renew --dry-run падает с ошибкой. Значит, автопродление реально сломано, и до истечения оно ничего не исправит само — если срок истекает в течение выходных, продлевайте вручную сейчас, пока есть время разобраться с причиной.
• До истечения меньше 10-14 дней, даже если dry-run прошёл успешно. Let's Encrypt пытается продлить сертификат за 30 дней до истечения, но если этот запуск по какой-то причине пропущен (сервис лежал, DNS не резолвился, rate limit), следующая попытка будет позже — и может не успеть до конца ваших выходных.

О том, как именно молча ломается автопродление и почему certbot renew иногда «работает», но сертификат на сайте всё равно старый, — в статье сертификат протух в пятницу вечером. Если сертификатов и доменов много, разумно один раз настроить отдельный мониторинг именно этой метрики — с алертом за 2-3 недели, а не за день.

Мониторинг и алерты: кто дежурит и как узнает о проблеме

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

Что проверить именно сейчас, а не понадеяться, что «всё как обычно работает»:

1. Назначен ли конкретный человек дежурным на выходные, а не подразумевается, что «кто-нибудь да увидит». Если команда маленькая и формального дежурства нет — решите заранее, кто первый контакт, и сообщите об этом явно. Разбор того, как выстроить дежурство и эскалацию даже в команде из двух-трёх человек, — в статье дежурство и эскалация в маленькой команде.
2. Реально ли дежурный доступен, а не просто назначен формально. Уточните прямым вопросом: будет ли у него связь хотя бы раз в день в оговорённое время, или он тоже уезжает туда, где интернета нет. Если недоступны все — честно признайте это и снизьте риск другими средствами: усильте автоматические перезапуски, отложите рискованные операции.
3. Дойдёт ли алерт технически. Отправьте тестовое сообщение через тот же канал, что используют боевые алерты, и убедитесь, что оно реально пришло дежурному, а не потерялось из-за неверного chat_id или лимита бота.
4. Не заглушены ли алерты вручную с прошлого раза. Проверьте, не осталось ли активных silence в Alertmanager или отключённых проверок в Uptime Kuma / Zabbix с прошлого инцидента:

# Alertmanager: список активных заглушений
curl -s http://localhost:9093/api/v2/silences | jq '.[] | {comment, endsAt}'

1. Понятны ли пороги алертов дежурному, если это не тот же человек, который их настраивал. Алерт «CPU 85%» без контекста, критично это или нет, вынуждает дежурного либо игнорировать сигнал, либо звонить вам за уточнением — оба варианта плохие.

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

Автоматика и обновления: что поставить на паузу

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

Что стоит найти и явно поставить на паузу на период выходных:

# systemd-таймеры: что и когда сработает в ближайшие дни
systemctl list-timers --all

# crontab на предмет автообновлений, не только root
crontab -l
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done

Конкретные кандидаты на паузу:

• unattended-upgrades на Debian/Ubuntu, если настроен на автоустановку не только security-патчей, но и всех обновлений подряд:

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo systemctl stop unattended-upgrades.timer

• Watchtower или другой автообновлятор Docker-образов, если настроен без пиннинга версий и может подтянуть breaking change из тега latest. Проще всего — временно остановить сам контейнер, не трогая остальные сервисы: docker stop watchtower.
• Плановые миграции, деплои и релизы, запланированные CI/CD на эти даты — если пайплайн настроен на автодеплой при мерже в main, а кто-то по инерции смержит PR в праздник, деплой всё равно случится. Предупредите команду и, если критично, временно защитите ветку от автодеплоя.
• Плановое обновление ядра или мажорной версии базы данных, если оно попадает на эти даты, — перенесите на будни, даже если формально «должно пройти гладко»: если не пройдёт, откатывать будет некому.

Что, наоборот, трогать не нужно: бэкапы (их отсутствие в выходные опаснее, чем наличие), продление сертификатов через certbot (безопасная изолированная операция, которая скорее спасёт вас, чем сломает), ротация логов. Общий принцип, где проводить границу между «оставить в автомате» и «поставить на паузу», разобран в статье правило двух недель для обновлений сервера.

Контакты на экстренный случай

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

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

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

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