Миграция

Чек-лист для параллельной работы двух провайдеров

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

Прежде чем отправлять реальный трафик второму провайдеру:

  • Убедитесь, что форматы ответов обоих провайдеров сопоставлены с общей внутренней структурой данных, чтобы код приложения читал один нормализованный формат независимо от того, какой провайдер фактически ответил на конкретный запрос
  • Заранее определите логику разделения: доля трафика, конкретные эндпоинты, конкретные сегменты клиентов или теневой режим, в котором второй провайдер вызывается, но его результат только записывается в лог и не используется
  • Настройте отдельное логирование или пометки, чтобы потом можно было определить, какой провайдер обработал любой запрос; это чрезвычайно важно, когда что-то идёт не так и нужно понять, куда смотреть в первую очередь

Пока работают оба провайдера:

  • Регулярно сравнивайте частоту ошибок и время ответа у обоих, а не только один раз в начале, поскольку поведение может меняться в течение дней или недель так, что одна начальная проверка этого не заметит
  • Следите за расхождениями в фактических результатах двух провайдеров на одних и тех же входных данных и заведите чёткий порядок принятия решений на случай, когда они не совпадают, вместо того чтобы считать, что один из них просто прав
  • Ведите заметки о любых шаблонах запросов, которые заметно по-разному ведут себя у двух провайдеров, поскольку именно эти случаи стоит протестировать тщательнее, прежде чем отключать старого провайдера

Прежде чем отключить исходного провайдера:

  • Убедитесь, что каждый путь в коде, который может вызвать старого провайдера, действительно проверен на новом, а не только типичные случаи
  • Проверьте, нет ли жёстко заданной резервной логики, которая предполагает, что старый провайдер всегда доступен, поскольку после периода работы с двумя провайдерами иногда остаётся резервный код, который никто не вспоминает удалить
  • Назначьте конкретную дату отключения старого провайдера, а не позволяйте периоду работы с двумя провайдерами тянуться бесконечно, поскольку переход без чёткого срока, как правило, так и не завершается

Совместимые хосты My Geocode созданы специально для того, чтобы первая половина этого процесса, нормализация формата ответов, была в основном не нужна, если для провайдера, с которого вы переходите, уже есть соответствующий хост: формат остаётся идентичным оригиналу, и ваш существующий код нормализации (если он у вас был) продолжает работать без изменений. Полный список из 17 совместимых хостов находится на странице /compatibility/. Каждый запрос также содержит заголовки квоты, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining и другие, описанные на странице /docs/rate-limits/; они полезны для описанного выше шага сравнительного логирования независимо от того, какой провайдер оценивается в качестве второго.

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