Как правильно выключить старый сервер: 30 дней в режиме ожидания

MAATRIX

Миграция прошла, новый сервер держит нагрузку неделю, всё выглядит стабильно — и первый порыв обычно один: снести старый сервер и перестать за него платить. Не делайте этого сразу. Забытая зависимость от старого IP — cron на чужом сервере, вебхук, VPN-профиль, месячный отчёт — всплывает не в день переключения, а через одну-три недели, когда её уже некому чинить по горячим следам. Ниже — рабочая схема: как перевести сервер в режим «выключен, но не удалён», что мониторить 30 дней и когда можно спокойно нажать «удалить».

Почему нельзя удалять сервер сразу после миграции

Логика «сайт открывается, API отвечает, значит переезд закончен» проверяет только то, что бьётся в глаза прямо сейчас. Она не проверяет то, что происходит редко.

Типичные зависимости, которые не всплывают в первые часы:

• Месячные и квартальные джобы. Скрипт биллинга, который раз в месяц забирает выгрузку с old-server:/exports/. Если удалить сервер на третий день после переезда, до следующего запуска джобы никто не узнает, что она сломана.
• Вебхуки и интеграции у третьих лиц. Платёжный шлюз, CRM или партнёрский сервис, у которого в настройках прописан IP или домен старого сервера — не ваш конфиг, вы его не увидите в grep по своим репозиториям.
• Захардкоженные адреса в устройствах и скриптах. IoT-датчики, роутеры с VPN-профилем на старый IP, скрипт на ноутбуке коллеги, который раз в квартал что-то выгружает вручную.
• DNS-кэши и TTL. Даже после смены A-записи часть клиентов и резолверов ещё какое-то время стучится по старому адресу — это отдельная головная боль, которая обычно закрывается за часы-сутки, но не за минуты.
• Резервные и отладочные пути. Мониторинг, который в fallback-режиме дёргает старый сервер, если новый не отвечает. Бэкап-скрипт, который синкает архивы на оба хоста «на всякий случай» и который забыли выключить.

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

Три состояния сервера вместо двух

Обычно про сервер думают в двух состояниях: «работает» и «удалён». Добавьте третье — оно и есть весь смысл этой статьи.

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

Как перевести сервер в режим ожидания технически

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

Шаг 1 — снять с сервера боевую роль, но оставить его слушать. Уберите старый сервер из балансировщика или из DNS (если ещё не убрали на этапе миграции), остановите прикладные сервисы, но не выключайте ОС и сеть:

systemctl stop nginx myapp-worker myapp-api
systemctl disable nginx myapp-worker myapp-api

На месте приложения поставьте лёгкую заглушку, которая просто логирует запрос и отвечает 410 Gone — это честнее, чем 502, и явно говорит любому, кто сюда стучится, что ресурс окончательно не работает:

server {
    listen 80 default_server;
    server_name _;
    access_log /var/log/nginx/decommission-hits.log combined;
    return 410 "This server has been decommissioned. Contact ops.";
}

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

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

# nftables
nft add rule inet filter input ct state new log prefix "DECOM-HIT: " counter
nft add rule inet filter input ct state new drop

# iptables, если nftables не используется
iptables -I INPUT -m state --state NEW -j LOG --log-prefix "DECOM-HIT: "
iptables -I INPUT -m state --state NEW -j DROP

Правило логирует и роняет любое новое входящее соединение — SSH при этом стоит явно разрешить отдельным правилом выше по цепочке, если вам ещё нужен доступ для диагностики. Это ловит попытки подключения по SMTP, VPN-порту, кастомному API-порту — всё, что не HTTP и что вы могли забыть.

Шаг 3 — полная остановка инстанса. После нескольких дней тихого логирования (обычно достаточно 5-7 дней, чтобы поймать первую волну «забытых» обращений) переводите сервер в состояние stopped на уровне провайдера, а не только «выключенный внутри». Диск и данные при этом сохраняются, но сервер перестаёт потреблять CPU/RAM и, как правило, перестаёт тарифицироваться по вычислительным ресурсам (хранилище обычно оплачивается отдельно и дешевле). В панели MAATRIX это делается кнопкой «Остановить» у виртуальной машины — в отличие от «Удалить», она не трогает диск.

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

Что мониторить эти 30 дней

Сама по себе остановка ничего не даёт, если никто не смотрит логи. Наблюдение — это то, ради чего вся схема существует.

Куда смотреть каждые несколько дней:

• Логи заглушки (/var/log/nginx/decommission-hits.log) и firewall (journalctl -k | grep DECOM-HIT или /var/log/kern.log) — кто стучится и как часто.
• Почтовые очереди на новом сервере — если старый был MX или SMTP-релеем, брошенные настройки на стороне отправителей всплывают именно как ошибки доставки на новой стороне, а не на старой.
• Биллинг и логи у партнёров/интеграций, у кого есть доступ спросить напрямую — быстрее, чем ждать, пока их джоба упадёт и они сами напишут вам.
• Мониторинг нагрузки нового сервера на предмет аномалий раз в неделю/месяц — если появляется всплеск в тот же день, что и плановая джоба у кого-то из клиентов, это повод свериться со старым логом.

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

#!/bin/bash
# decom-watch.sh — раз в сутки через cron, шлёт дайджест, только если что-то реальное
LOG=/var/log/nginx/decommission-hits.log
YESTERDAY=$(date -d "yesterday" +%d/%b/%Y)
HITS=$(grep "$YESTERDAY" "$LOG" | grep -vE "bot|crawl|scan" | wc -l)

if [ "$HITS" -gt 0 ]; then
    SUMMARY=$(grep "$YESTERDAY" "$LOG" | grep -vE "bot|crawl|scan" | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -10)
    curl -s -X POST "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" \
      -d chat_id="${TG_CHAT_ID}" \
      -d text="Старый сервер: $HITS обращений за $YESTERDAY:
$SUMMARY"
fi

Фильтр по bot|crawl|scan грубый и не поймает всё — это отправная точка, которую стоит донастроить под свой трафик за первую неделю, когда шум ещё видно глазами. Смысл скрипта не в точности фильтра, а в том, чтобы не читать лог руками каждый день и получать сигнал только тогда, когда есть что смотреть.

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

Как быстро вернуть сервер в строй, если что-то нашлось

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

1. Запустить инстанс. Start в панели провайдера — сервер поднимается с тем же диском, тем же состоянием, в котором был остановлен.
2. Откатить firewall-правила на «пропускать», а не логировать-и-дропать — иначе поднятый сервис всё равно недоступен снаружи:

   nft flush chain inet filter input
   nft add rule inet filter input ct state established,related accept
   nft add rule inet filter input tcp dport 22 accept
   # остальные правила — как было в проде

1. Вернуть сервисы.

   systemctl enable --now nginx myapp-worker myapp-api

1. Если DNS уже переключён на новый сервер и трафик должен идти именно на старый (например, партнёр всё ещё стучится по IP напрямую, а не по домену) — DNS трогать не нужно, старый сервер и так доступен по своему IP сразу после старта.
2. Разобраться в причине, только после того как сервис снова доступен, — чинить зависимость нужно, но не за счёт времени простоя чужой интеграции.

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

Чек-лист перед финальным удалением

Финальное удаление — это шаг без права на «упс». Пройдите чек-лист целиком, а не по памяти.

• [ ] Прошло не меньше согласованного срока (рекомендуем от 30 дней, для сервисов с годовым циклом отчётности — до 60-90).
• [ ] За весь период в логе заглушки и firewall не было обращений, которые вы не можете объяснить сканерами и ботами.
• [ ] Почтовые очереди на новом сервере чистые, ошибок доставки, связанных со старым MX/relay, нет.
• [ ] Партнёры и интеграции, у кого был прямой контакт со старым сервером, письменно подтвердили переход на новый адрес.
• [ ] Снят финальный снапшот диска и проверено, что его можно восстановить в отдельный тестовый инстанс (снапшот, который никогда не разворачивали, — это не гарантия, а надежда).
• [ ] Снапшот сохранён в отдельном хранилище на согласованный срок (обычно ещё 30-90 дней сверху, дешевле, чем держать целый работающий инстанс).
• [ ] Секреты и переменные окружения со старого сервера скопированы в password-менеджер команды, если ещё не были — потом взять их будет неоткуда.
• [ ] Выделенный IP освобождён или переиспользован осознанно, а не автоматически провайдером.
• [ ] Обновлена внутренняя документация/инвентарь — старый сервер убран из CMDB, схем сети, списка бэкапов.

Только после всех пунктов — Destroy / Terminate в панели провайдера. Это тот момент, когда «выключен, но не удалён» переходит в необратимое состояние.

Сколько стоит держать сервер в режиме ожидания и когда сокращать срок

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

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

Срок в 30 дней — разумный дефолт, но не догма:

• Меньше (7-14 дней) можно, если сервис маленький, зависимостей заведомо немного и вы уверены в инвентаризации перед миграцией.
• Больше (60-90 дней) стоит взять, если на сервере были биллинговые, бухгалтерские или комплаенс-процессы с квартальным или годовым циклом — тут месяца может не хватить, чтобы зависимость успела сработать хотя бы раз.
• Регуляторные требования иногда сами диктуют срок хранения данных — это отдельный вопрос к юристам, а не к DevOps-регламенту, и период ожидания перед удалением его не отменяет.

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

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