Сайт на новом хостинге: когда закрывать переключение?

Зафиксируйте границу конкретного переключения

Здесь рассматривается одно существующее публичное имя с неизменными URL. Уполномоченный администратор по отдельному согласованию меняет назначение одной A-записи в режиме DNS-only. Перенос регистратора, серверов имён, цепочки CNAME и маршрутизация через прокси в этот учебный план не входят. Для другого устройства системы понадобится другой разбор.

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

Читайте срок уже полученного ответа

TTL задаёт срок кеширования DNS-записи. Для обычной модели ниже окончание срока = время получения + полученный TTL. Определение TTL.

В 09:00 TTL меняется с 3600 на 300 секунд; назначение меняется в 09:10. Единственный исправный авторитетный источник в модели обновляется мгновенно и согласованно. A, B и C обозначают кеши, не людей.

При запросе в 09:11 A отвечает старым назначением с остатком 2880 секунд, B обновляется и получает новое с TTL 300, C возвращает старое с остатком 180. Модель исключает предварительное обновление, вытеснение, дополнительные слои кеша и выдачу просроченных ответов.

Снижение TTL у источника не переписывает срок ранее полученного ответа. У AWS этот принцип объяснён для миграции серверов имён; оттуда нельзя переносить сроки и операции NS в наш пример A-записи. Ожидание прежнего срока.

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

Разделите подготовку и наблюдение после смены

Во втором варианте назначение меняется в 10:00. Длинный ответ, полученный в 08:59:59, истёк к 09:59:59. Однако короткий старый ответ, полученный в 09:59:59, действует до 10:04:59. Подготовка устраняет прежний длинный срок, но не отменяет это пересечение.

Обратное изменение тоже не отзывает уже полученные ответы: новое назначение, сохранённое в 10:01 на 300 секунд, остаётся в кеше до 10:06 при возврате источника в 10:02. Это продолжение модели, а не инструкция отката.

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

Запросите журнал наблюдений, а не общий процент

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

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

Три зелёных проверки из четырёх не означают, что переключились 75% покупателей. Сначала пришлось бы определить аудиторию, выборку и связь проверок с её реальными путями. В этом руководстве такого измерения нет. Отчёт владельцу перечисляет наблюдённые точки и исключения, не придумывая процент готовности всей сети.

Разделяйте повтор одного наблюдения и независимую проверку другой точки. Сохраните обе строки, если результат изменился. Для каждого исключения укажите ожидаемую следующую проверку, а не заменяйте неудачную строку удачной. Так видно, что команда действительно объяснила переход, а не выбрала удобный снимок.

Не превращайте расчёт в мировой срок завершения

RFC 8767 допускает использование просроченного ответа, когда не удалось обновить данные у авторитетного источника. Поэтому истечение рассчитанного TTL не гарантирует завершение переключения для всего интернета. Это граница модели, не предложение включать такой режим. RFC 8767, разделы 4 и 7.

Реальный план также должен назвать дополнительные зависимости: локальные кеши, прокси, уже открытые соединения и состояние приложения. Администратор определяет, какие из них относятся к выбранной схеме. Числа 09:59 и 10:04:59 объясняют учебные ответы; они не являются разрешением выключить прежнее назначение или универсальным нормативом ожидания.

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