Сменить API-хост в продакшене без сбоя вполне реально, но для этого смену нужно рассматривать как развёртывание со своим профилем рисков, а не как правку одной строки конфигурации, отправленную прямо в продакшен. Разница между плавным переключением и инцидентом почти всегда заключается в подготовке, а не в самом моменте переключения.
Перед переключением:
Заранее получите учётные данные для нового хоста и убедитесь, что они работают в тестовой или промежуточной среде на реальных шаблонах запросов, а не только на одном ручном тестовом вызове
Настройте в приложении запись в лог того, какой хост обработал каждый запрос, пусть даже временно, чтобы проверять ход развёртывания и потом диагностировать любую проблему по хостам
Убедитесь, что ваша система конфигурации позволяет менять значение хоста без полного повторного развёртывания приложения, будь то переменная окружения, флаг функции или удалённый сервис конфигурации, поскольку процесс с повторным развёртыванием на каждое изменение медленнее реагирует, если что-то пойдёт не так посреди переключения
Во время переключения:
Если инфраструктура позволяет, внедряйте изменение постепенно, а не сразу целиком: долю трафика, один сервер или регион за раз или один некритичный эндпоинт раньше остальных
Следите за частотой ошибок и временем ответа в реальном времени во время развёртывания, сравнивая их непосредственно с вашими базовыми показателями до переключения, а не с предполагаемым допустимым диапазоном
Держите учётные данные прежнего хоста активными и готовыми в течение этого периода, чтобы откат был изменением конфигурации, а не новым развёртыванием
После переключения:
Дайте новому хосту поработать с полным трафиком в течение заданного периода наблюдения, прежде чем считать миграцию завершённой, поскольку некоторые проблемы проявляются только при длительной нагрузке или в определённое время суток
Сравните фактические данные ответов старого и нового хоста на выборке одинаковых запросов, если вы записывали оба, чтобы выявить тонкие различия в данных, которые одна лишь частота ошибок не покажет
Отключайте учётные данные старого хоста только после того, как период наблюдения прошёл без проблем, в конкретную заранее выбранную дату, а не «когда-нибудь»
Поскольку совместимые хосты My Geocode воспроизводят точный формат запросов и ответов провайдера, фактическое изменение кода при миграции на основе совместимости часто сводится к имени хоста и учётным данным для аутентификации, что уменьшает объём нового кода в самый рискованный момент переключения. Сама аутентификация поддерживает четыре способа: заголовок X-API-Key, Authorization: Bearer, HTTP Basic auth или параметр запроса, поэтому эта часть изменения часто может быть чистым обновлением конфигурации, а не изменением кода, в зависимости от того, как устроена ваша существующая клиентская библиотека.
Миграция без простоя зависит не столько от хитроумной инфраструктуры, сколько от дисциплины: тщательно подготовьтесь, внедряйте постепенно, внимательно наблюдайте и сохраняйте путь назад, пока не будете достаточно уверены, что он не понадобится.
Отключить API-ключ старого провайдера слишком рано или слишком поздно одинаково рискованно. Вот как правильно вывести учётные данные из эксплуатации после завершения миграции.