DNS и SSL забывают до конца: как не уронить сайт при миграции

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

Хвосты миграции редко выглядят как полный offline. Чаще это «серая зона»: одни клиенты видят новый контур, другие — старый кэш; браузер ругается на имя в сертификате; MX указывает на сервер, который уже выключили. Для бизнеса это выглядит как хаос без понятной причины.

Что обычно забывают в момент переключения

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

SSL/TLS и цепочки доверия. Сертификат выпустили на старый балансировщик, на новом — self-signed «на время», промежуточный CA забыли, wildcard не покрыл поддомен кабинета или API. Сайт «открывается», но конверсия падает на предупреждении браузера.

Почта: SPF, DKIM, DMARC, MX. Веб переехал, почтовый контур — нет. Или наоборот: MX уже новый, а SPF всё ещё разрешает только старые IP. Итог предсказуем — письма в спаме, уведомления о заказах не доходят, поддержка тонет в «мы ничего не получали».

Редиректы и канонические URL. HTTP→HTTPS, www→apex, старые пути после смены структуры. Без карты редиректов SEO и закладки клиентов превращаются в 404.

Мониторинг после переключения. Смотрят, что хост пингуется, и уходят. Не смотрят: срок сертификата, ошибки TLS, долю 5xx, очередь почты, latency с разных сетей, корректность HSTS.

Как это проявляется у пользователей и внутри компании

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

Отдельно больно смешанный режим: часть трафика на новом контуре, часть — на старом. Данные и сессии разъезжаются, баги становятся невоспроизводимыми. Пока TTL не выгорел и сертификаты не выровняли, инцидент растягивается на дни.

Ещё один тихий сбой — служебные имена. API, вебхуки платёжки, callback SMS-провайдера, статический CDN домен. Витрина уже на новом IP, а уведомления об оплате всё ещё стучатся на старый хост. Снаружи «сайт открылся», внутри бизнес-процесс разорван.

Подходы, которые реально закрывают хвосты

Снижение TTL заранее. За несколько суток до окна ставят короткий TTL на критичные записи (A/AAAA, CNAME, MX при смене почты). После стабилизации TTL возвращают к нормальным значениям — иначе каждый следующий инцидент снова будет долгим.

Сертификаты готовят до переключения трафика. Выпуск и проверка цепочки на новом балансировщике, покрытие всех нужных имён, тест с внешних сетей, проверка OCSP/CRL по возможности. «Поставим SSL после DNS» — способ получить день жалоб.

Почтовый контур ведут отдельным чек-листом: MX, SPF (include и ip4/ip6), DKIM-ключи, DMARC-политику, PTR при необходимости, тестовые письма на крупные провайдеры. Веб и почта — разные риски; их нельзя «доделать завтра» одной фразой.

Карта редиректов и быстрая проверка после переключения. Список URL из аналитики и sitemap, проверка кодов ответа, CORS и cookie-доменов для кабинетов. Плюс усиленное наблюдение первые 24–72 часа: TLS, DNS, почта, ошибки приложения.

Ошибки, которые растягивают «серую зону»

Считать миграцию законченной в момент «сайт открылся по IP». Для бизнеса конец — когда имя, сертификат и почта стабильны для реальных клиентов.

Менять всё в одном окне без репетиции: DNS, SSL, MX, CDN, WAF. Каждый слой добавляет свою задержку распространения; без прогона на тестовом контуре сюрпризы гарантированы.

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

Не назначить владельца переключение чеклиста. Когда DNS «у админа», сертификат «у devops», SPF «у кого то из маркетинга», хвосты никто не закрывает до жалоб.

Игнорировать CDN и кэш DNS у провайдеров. Даже при коротком TTL картинка у разных операторов отличается часами — это надо закладывать в коммуникацию и мониторинг.

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

Чек-лист переключение: DNS, SSL, почта, редиректы

• Инвентаризация имён: apex, www, api, cabinet, static, mail, служебные поддомены.
• TTL снижен заранее; зафиксированы текущие и целевые записи A/AAAA/CNAME/MX/TXT.
• Сертификаты выпущены и проверены на новом контуре до переключения пользователей.
• SPF/DKIM/DMARC согласованы с фактическими отправителями после миграции.
• Карта редиректов и проверка топ-URL из аналитики.
• План отката DNS и критерии решение «продолжаем или стоп» (не только «пингуется»).
• Мониторинг TLS, DNS, почты и ошибок приложения на 72 часа после окна.
• Коммуникация бизнесу: что могут увидеть клиенты в период распространения DNS.

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

Почему сайт по IP работает, а по домену — нет? Обычно запись ещё указывает на старый адрес, кэш DNS не истёк, либо сертификат выписан не на то имя, которое видит браузер.

Можно ли переключить DNS, а SSL «доделать утром»? Технически да, коммерчески почти всегда нет: предупреждение браузера бьёт сильнее короткого планового окна с готовым сертификатом.

Почта обязательна в том же окне, что и сайт? Не всегда. Но MX/SPF нельзя оставлять «висящими»: либо почта остаётся на старом контуре осознанно, либо переезжает по своему чек-листу с тестами доставки.

Сколько держать короткий TTL? Обычно дни до переключение и первые сутки двое после стабилизации, затем вернуть к значениям, удобным для эксплуатации.

Что считать завершением миграции? Не акт «ВМ в облаке», а стабильные имя→адрес, валидный TLS для всех публичных имён, рабочая доставка писем и отсутствие смешанного трафика на отключённый контур.

Следующий шаг

Хвосты DNS, SSL и почты — не мелочи после «настоящей» миграции, а часть переключение. Если переезд уже случился и симптомы серой зоны налицо, сначала выровняйте записи, сертификаты и отправителей, затем закрепите чек-лист на следующие изменения. Системно такие переезды ведут в рамках Миграции в облако — с упором на контролируемое переключение, а не только на копирование серверов.