Кратко

  • Домены Fastly без привязки к версии управляются отдельно от конкретной версии сервиса. Подготовку публичного имени можно вести независимо от выпуска приложения.
  • Передача кода не передаёт автоматически возможность направлять пользователей. Для смены оператора важны DNS, подтверждение контроля, сертификаты, права аккаунта и связи с сервисами или правилами маршрутизации.
  • Делегирование между аккаунтами не означает уход с Fastly или юридическую передачу прав. Классические домены и Platform TLS также имеют отдельные процедурные ограничения.

Приложение сдано, адрес ещё предстоит передать

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

Кто сможет распорядиться, чтобы запросы по этому имени попадали в нужный сервис? Управление DNS может оставаться в отдельной учётной записи, сертификатами занимается другой специалист, а права на привязку домена не входят в переданный комплект доступа. Даже при добросовестном сотрудничестве работа с приложением и управление его публичным входом оказываются разными предметами приёмки.

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

Fastly делает границу явной в описании доменов. Домен без привязки к версии управляется отдельно от версии сервиса. Его можно добавить до назначения сервиса, а изменения в управлении доменом не требуют увеличения версии сервиса. Публичное имя получает собственный порядок подготовки, не совпадающий обязательно с графиком релизов.

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

Важна не только новая команда, но и её аккаунт

Старая модель помогает понять изменение. Классические домены Fastly входят в конфигурацию сервиса и его версии. Изменение связи с сервисом требует новой версии. Согласно документации, классическая функциональность доступна только аккаунтам, созданным до 16 сентября 2025 года. Если такой домен используется в другом аккаунте Fastly, делегирование между аккаунтами выполняется через поддержку.

Для доменов без привязки к версии предусмотрено самостоятельное делегирование другому аккаунту или клиенту. Документация описывает подтверждение через управляемый Fastly сертификат, полученный с помощью проверки DNS, и токен в DNS. Другой вариант — действующий сертификат общедоверенного удостоверяющего центра и соответствующий закрытый ключ. Это условия продукта, а не рекомендация свободно пересылать производственные закрытые ключи между подрядчиками.

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

Универсальной эта возможность не является. В руководстве по работе с доменами сказано, что клиенты Platform TLS имеют в Unified Domain Management доступ только для чтения и должны обращаться в поддержку для управления доменами или миграции. План передачи должен учитывать реальный продукт и тип аккаунта, а не обобщённое представление о возможностях Fastly.

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

Что можно подготовить до движения трафика

Возможность сделать часть работы раньше особенно заметна в руководстве по управляемым сертификатам. При стандартной проверке ACME через DNS на Fastly направляется только проверочный поддомен. Производственный трафик не требуется переносить в тот же момент. Подготовка TLS и фактическая смена маршрута пользователей могут идти раздельно.

Проверка через HTTP имеет другое последствие: трафик направляется сразу. Fastly предупреждает, что незавершённая настройка TLS или сервиса может привести к предупреждениям безопасности либо недоступности сайта. Для договора на переход это не просто выбор технической опции. Он определяет, останется ли незаконченная работа внутри подготовки или её последствия уже увидят посетители.

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

Получение первого сертификата также не устраняет будущих зависимостей. Изменения DNS или ограничивающая политика CAA способны помешать продлению. API подписок TLS различает выпуск, продление и повторные попытки выдачи. Продолжающиеся попытки не продлевают срок действия уже истёкшего сертификата. После передачи должен оставаться ответственный за условия следующего обновления.

Документация отдельно отмечает, что отключение всех активаций TLS само по себе не останавливает управляемое продление, тогда как удаление подписки является другой операцией. Здесь не предлагается выполнять ни одну из этих процедур при смене подрядчика. Различие показывает, что использование сертификата и продолжение его обслуживания не сводятся к одному переключателю.

Подтверждённый контроль не равен юридическому праву

API управления доменами хранит разные отношения отдельно. Проверка свидетельствует о подтверждении контроля допустимым сертификатным способом; активация означает наличие хотя бы одной активации TLS. Привязка к сервису и привязка к конфигурации маршрутизации представлены независимо и могут отсутствовать.

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

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

Продление самостоятельно управляемого сертификата остаётся обязанностью клиента. Передача файлов без передачи контроля сроков и необходимых прав лишь откладывает незавершённую работу. Требования TLS добавляют условия аккаунта и разрешений. Полученная инструкция сама по себе не наделяет нового подрядчика правами на её выполнение.

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

Приложение получено, правила входа остались общими

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

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

Документация требует домен в Domain Management, действующий сертификат TLS и активный сервис. Необходимо правило по умолчанию. Конфигурация должна быть развёрнута и связана с доменом; уже развёрнутая конфигурация начинает направлять трафик после установления связи. Право на эту привязку поэтому имеет самостоятельное влияние, не совпадающее с правом выпустить принимающее приложение.

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

Описанные правила распределяют запросы внутри Fastly. Они не доказывают маршрутизацию к стороннему CDN и не означают готовность всего приложения к уходу с платформы. Внутренняя гибкость полезна сама по себе, но не должна выдаваться за уже подтверждённую внешнюю переносимость.

Четыре разных перехода

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

В руководстве по направлению трафика Fastly указывает, что не предоставляет управляемый DNS в описываемой конфигурации. Клиент выбирает DNS-провайдера и устанавливает предложенные записи. Значит, существует область управления именем вне релиза приложения. Однако способность самого заказчика использовать её зависит от его аккаунтов и распределения обязанностей.

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

Масштаб бизнеса объясняет, почему административная деталь заслуживает внимания. В отчёте за второй квартал 2026 года Fastly сообщила о выручке 183,3 млн долларов, в том числе 133,9 млн долларов от Network Services. Это опубликованные компанией показатели её деятельности, а не измерение использования доменов без версии или экономии клиентов. Управление именем находится на входе в значительный бизнес цифровой доставки.

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