Перенос автоматизации Zapier или Make на новый хост геокодирования
No-code автоматизации с шагом геокодирования требуют иного подхода к миграции, чем собственный код. Вот как провести такой переход.
Первая неделя после миграции: за чем следить
Первая неделя после запуска миграции в продакшен обычно и показывает разрыв между тем, что покрыло тестирование, и тем, как на самом деле выглядит реальный рабочий трафик. Тестирование, каким бы тщательным оно ни было, охватывает конечный набор сценариев; целая неделя живого трафика выявляет длинный хвост реального использования, который план тестирования почти никогда не предугадывает полностью.
Несколько конкретных вещей, за которыми стоит внимательно следить в эту первую неделю, помимо общих панелей частоты ошибок, которые большинство команд уже проверяет:
Шаблоны запросов, которые вы не догадались протестировать. Реальные пользователи вводят адреса с опечатками, необычным форматированием и региональными особенностями, которые ваши тестовые данные могли не охватить. Если следить именно за ростом числа ответов «результаты не найдены» по сравнению с базовым уровнем до миграции, можно выявить различия в форматировании или сопоставлении адресов между провайдерами, которые чистые тестовые данные пропустили.
Расход квоты в сравнении с вашей реальной оценкой. Если вы оценивали потребность в квоте до миграции, первая неделя это время, когда оценка встречается с реальностью. Сверка заголовков X-Quota-Used и X-Quota-Free-Remaining, описанных на странице /docs/rate-limits/, с прогнозируемым дневным объёмом быстро покажет, была ли ваша оценка близкой или её нужно скорректировать, прежде чем выбирать конкретный тариф на более долгий срок.
Распределение времени ответа, а не только средние значения. Среднее время ответа, которое выглядит нормально, может скрывать меньший, но значимый хвост медленных запросов, проявляющийся только под реальной параллельной нагрузкой, а ограниченная тестовая среда редко точно это воспроизводит.
Любой участок кода, который всё ещё незаметно обращается к старому провайдеру. При миграции иногда пропускают место вызова, особенно в редко используемой функции или редко запускаемом фоновом задании, и первая неделя часто оказывается временем, когда этот пробел проявляется сам собой, обычно через обращение в поддержку или неожиданную запись в логе, а не в результате активного поиска.
Расхождение кэшированных данных между результатами старого и нового провайдера. Если ваш план миграции включал какой-либо из подходов к работе с кэшем, описанных в других статьях (пометка записей по провайдеру-источнику или естественное истечение старых записей), в первую неделю стоит действительно проверить, что всё работает как задумано, а не предполагать это.
Короткая ежедневная проверка в эту первую неделю, даже всего пятнадцать минут на просмотр нужных панелей и заголовков, выявляет большую часть того, что могла упустить миграция, гораздо раньше, чем если ждать, пока проблема всплывёт в виде обращения в поддержку. После первой недели без существенных проблем большинство команд вполне может вернуться к обычному ритму мониторинга, использовав это окно именно для того, чтобы поймать различия, которые может выявить только реальный трафик, а не тестирование.
Если всё же обнаружится что-то, что тестирование пропустило, именно заранее, ещё до миграции, подготовленный план отката, а не импровизация под давлением, не даёт трудной первой неделе стать по-настоящему плохой.