Праздники без админа: как сервер переживёт десять дней один

MAATRIX

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

Почему это не то же самое, что дежурство или отпуск одного админа

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

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

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

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

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

Для контейнеров в docker compose это политика перезапуска плюс honest healthcheck, который проверяет не «жив ли процесс», а «отвечает ли приложение»:

services:
  app:
    image: myapp:latest
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 20s
    deploy:
      restart_policy:
        condition: on-failure
        max_attempts: 5
        window: 120s

restart: unless-stopped перезапускает контейнер при падении и после перезагрузки хоста, но не мешает вручную его остановить, если понадобится. Ключевой нюанс — healthcheck должен реально проверять работоспособность приложения, а не просто «порт слушает»: контейнер может формально висеть в running, пока внутри процесс завис в дедлоке. Как правильно построить HEALTHCHECK и связать его с автоперезапуском зависшего, а не упавшего контейнера, разобрано в статье Docker healthcheck: настройка — это стоит проверить и донастроить именно перед длинными праздниками, а не полагаться на дефолтные докер-компоуз файлы, где healthcheck часто вообще не прописан.

Для сервисов вне контейнеров — то же самое на уровне systemd:

[Service]
Restart=on-failure
RestartSec=5
StartLimitIntervalSec=300
StartLimitBurst=5

StartLimitBurst важен отдельно: без него сервис, который падает в цикле из-за реальной проблемы (например, кончилось место на диске), будет перезапускаться бесконечно, забивая логи и нагружая систему, вместо того чтобы после нескольких попыток остановиться и дождаться человека. Проверьте оба механизма — и docker, и systemd-юниты — тестовым падением сервиса за неделю до праздников: docker kill <container> или systemctl kill <service>, и посмотрите, поднимается ли он сам за разумное время.

Диск и очевидные ресурсные лимиты: то, что автоперезапуск не лечит

Автоперезапуск спасает от зависаний и падений процесса, но не от исчерпания ресурса — если диск заполнен на 100%, перезапущенный контейнер упадёт снова через секунду. Логи, временные файлы, старые бэкапы или Docker-образы копятся месяцами и переполняют диск ровно в тот момент, когда чинить некому.

Минимальная подготовка перед праздниками:

• Проверьте df -h и убедитесь, что свободно хотя бы 20-25% — с запасом на десять дней логов.
• Настройте ротацию логов (logrotate для системных логов, --log-opt max-size=10m --log-opt max-file=3 для докер-контейнеров).
• Почистите неиспользуемые Docker-образы и volume: docker system prune -a --volumes — но сначала на тестовом окружении, чтобы случайно не снести нужный том.
• Если есть локальные бэкапы перед выгрузкой во внешнее хранилище — проверьте, что старые копии удаляются, а не копятся бесконечно.

Это не эффектная работа, но именно она чаще всего оказывается настоящей причиной падения сервиса на пятый день праздников, когда никакой атаки или всплеска трафика не было — просто закончилось место.

Сертификаты и домены: проверено заранее, а не «вроде настроено»

Автопродление Let's Encrypt через certbot или acme.sh работает в подавляющем большинстве случаев, но именно поэтому опасно: когда оно ломается, узнают об этом не заранее, а по факту — браузер начинает ругаться на сертификат, и это происходит без единого предупреждения. Если такой сбой попадёт на середину новогодних каникул, у сайта будет предупреждение безопасности минимум несколько дней, а то и до конца праздников.

Перед уходом на каникулы — не поверить настройке на слово, а прогнать реальную проверку:

# certbot: тестовое продление без реальной перевыпуска
certbot renew --dry-run

# убедиться, что таймер вообще активен и не упал молча
systemctl status certbot.timer
systemctl list-timers | grep certbot

# для acme.sh — принудительный тестовый прогон
acme.sh --renew -d example.com --force --dry-run

Если dry-run падает — почти всегда проблема в DNS-валидации, занятом порту 80 или истёкшем API-токене DNS-провайдера при DNS-01 challenge. Все три причины лечатся за полчаса, если найти их за неделю до праздников — и совершенно не лечатся удалённо посреди каникул без доступа к консоли.

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

Алерты должны будить телефон, а не тонуть в рабочем чате

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

Что стоит перенастроить перед длинным простоем:

• Продублируйте канал доставки на личный телефон, а не только в общий чат. Push-уведомление в приложении мониторинга, SMS через шлюз, или отдельный Telegram-бот, привязанный к личному аккаунту, а не к общему рабочему чату — то, что реально разбудит человека ночью.
• Не завязывайте всё на единственный канал. Если весь мониторинг идёт через Telegram-бота, а у Telegram будет региональный сбой или истечёт токен — вы не узнаете о падении вообще. Второй, независимый канал доставки — не избыточность, а обязательный пункт.
• Проверьте канал заранее реальным тестом: временно занизьте порог алерта на тестовом сервисе и убедитесь, что сообщение дошло, а не потерялось из-за неверного chat_id, спам-фильтра или лимита API. Десять минут теста за неделю до праздников снимают риск обнаружить нерабочую доставку именно тогда, когда она нужна.
• Настройте пороги так, чтобы не было шума. Ложные алерты по мелочи приводят к тому, что через пару дней человек отключает уведомления вручную или начинает их игнорировать — и реальный сигнал тонет среди привычного шума.

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

Дежурный контакт хостинг-провайдера: кому звонить, если совсем плохо

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

Перед праздниками стоит проверить и зафиксировать в доступном месте (закреплённое сообщение, а не файл на рабочем компьютере, к которому никто не подключится):

• Работает ли поддержка хостера в режиме 24/7 круглый год или у неё есть сокращённый график именно на новогодние праздники.
• Номер договора или ID аккаунта, чтобы не тратить время на подтверждение личности в критический момент.
• Канал связи с наивысшим приоритетом — обычно тикет с пометкой critical или отдельный номер телефона для экстренных случаев, если тариф его предусматривает.
• Реалистичное понимание границы ответственности: поддержка чинит инфраструктуру — сеть, железо, гипервизор, — но не ваш код и не логику приложения. Рассчитывать, что тикет в поддержку заменит администратора, если проблема в вашем приложении, не стоит.

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

Заморозка рисков: чего не делать за неделю до праздников

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

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

Имеет смысл сознательно заморозить на период праздников:

• Любые схемы миграции базы данных и необратимые изменения данных.
• Обновления мажорных версий системного ПО, ядра, СУБД.
• Смену DNS-записей без крайней необходимости — DNS кэшируется дольше, чем ожидается, и разбираться с этим без доступа к серверу неудобно.
• Эксперименты с конфигурацией firewall — ошибка здесь способна отрезать доступ к серверу, а исправить её будет некому.

Финальный чек-лист перед уходом на каникулы

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

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