My Geocode

Миграция

Планирование отката до начала миграции

· 3 мин чтения · My Geocode · #план-отката#планирование-миграции#геокодирование#управление-рисками#развёртывание

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

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

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

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

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

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

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

Ещё в разделе «Миграция»