Как перенести письма с Mailgun на YourTrend без простоя

Как перенести транзакционные письма с Mailgun на YourTrend без простоя

Миграции с Mailgun чаще всего ломаются на мелочах: одно поле в webhook, одно правило подавления, один вспомогательный шаблон, о котором никто уже не помнил. Если вы планируете как перенести транзакционные письма с Mailgun на YourTrend без простоя и готовите миграцию с Mailgun на YourTrend, начните с предположения, что сложность не в отправке писем. Сложность в том, чтобы все зависимости приложений продолжали работать, пока два провайдера какое-то время сосуществуют.

Самый безопасный путь — намеренно скучный. Переносите по одному потоку за раз. Отслеживайте каждый endpoint, каждое имя события и каждый шаг поддержки, который зависит от поведения Mailgun.

1. Составьте карту всех компонентов в Mailgun, от которых зависит ваше приложение

Начните с простого списка, а не с редизайна. Перечислите API endpoints Mailgun, к которым обращается ваше приложение, webhook-адреса, на которые оно подписано, логику подавления, блокирующую отдельных получателей, и любой код, который разбирает message ID Mailgun. Если кто-то в команде когда-либо говорил: «Это поле, наверное, не используется», проверьте это до того, как что-либо переносить.

Обычно зависимостей больше, чем показывает первый аудит. Письмо с подтверждением заказа может использовать один endpoint, а письма для сброса пароля — другой. Дашборд поддержки может искать message ID за последние 30 дней, а worker повторной отправки может ожидать тег Mailgun в формате, который YourTrend сам по себе не создаёт.

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

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

2. Выберите самый безопасный вариант сосуществования на время переключения

Не переводите все потоки в первый же день. Выберите один изолированный сценарий, например приветственное письмо или уведомление с низким риском, и сначала пусть YourTrend обслуживает только его. Для остальных потоков Mailgun остаётся активным. Такое разделение уменьшает зону поражения, если в шаблонах или обработке событий что-то будет отличаться.

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

Используйте правило маршрутизации, которое можно объяснить одной фразой. Например: «Сбросы пароля остаются в Mailgun, пока staging-тест не пройдёт, а подтверждения заказов идут через YourTrend только для внутренних сотрудников». Понятное владение лучше хитрого кода. А ещё лучше — письменный план отката.

Если у вас есть внутренний блог или журнал миграции, команде также может пригодиться блог для релиз-нотов и обновлений по запуску. Одно короткое сообщение после каждого шага лучше длинного итога в конце, особенно когда два провайдера работают одновременно.

3. Воссоздайте ожидания по идентификаторам сообщений и отслеживанию доставки

Командам поддержки нужна непрерывность. Если в тикетах, поисковых инструментах или аудиторских логах используются message ID Mailgun, YourTrend должен вписаться в тот же рабочий процесс до того, как на него пойдёт боевой трафик. Это может означать хранение нового ID провайдера рядом со старой внутренней ссылкой, а затем обновление callback-обработчиков, чтобы сопоставлять оба варианта в переходный период.

Особое внимание уделите записям о доставке. Событие bounce, complaint и unsubscribe должно попадать в одну и ту же внутреннюю модель, даже если поля в payload отличаются. Если клиент пишет: «Моё письмо с квитанцией не пришло», поддержка должна уметь найти одну запись и увидеть, отправил ли Mailgun это письмо на прошлой неделе, а YourTrend — письмо того же типа сегодня.

Делайте логирование явным. Логируйте имя провайдера, идентификатор сообщения, получателя, название шаблона и точное событие, которое пришло. Одна строка структурированных данных лучше, чем десять строк общего текста. Короткие логи ускоряют решение об откате.

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

4. Перепишите шаблоны, завязанные на форматирование Mailgun

Именно в шаблонах чаще всего прячутся сюрпризы. Тема письма может отрисоваться нормально, а вот блок в теле — по-другому экранировать переменные. Значения по умолчанию могут сломаться. Форматирование ссылок может измениться. Обработка вложений может вести себя иначе, когда один и тот же шаблон переезжает с Mailgun на YourTrend.

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

Проверьте всё, что связано со ссылками. Подписанные URL, ссылки с токенами и параметры трекинга часто выявляют различия в кодировке. Ссылка, которая в HTML выглядит нормально, может сломаться в мобильном почтовом клиенте, если экранирование изменится всего на один символ. Поэтому одного теста в staging никогда не бывает достаточно.

Обычный текст тоже важен. Сообщение, которое отлично выглядит в HTML, всё равно может отправить плохой plain-text fallback, если провайдер вырезает форматирование в другом порядке. Это не выглядит драматично, но становится проблемой поддержки, как только пользователь пересылает письмо в help desk.

5. Сначала переведите потребителей webhook, а уже потом — трафик на отправку

Сначала должны быть готовы ваши downstream-системы. Если fraud-сервис, CRM, хранилище данных или бот оповещений читает события о доставке, bounce, жалобах или отписках, эти потребители должны принимать payload YourTrend ещё до того, как изменится поток отправки. Иначе письмо может отправляться правильно, а внутренние автоматизации будут тихо ломаться.

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

Полезная привычка — прогонять старые и новые payload событий через один и тот же тестовый стенд. Пропустите через парсер обе структуры. Сравните результат. Если одно событие приводит к отсутствующему полю или null reference, исправьте потребителя до того, как переключать что-либо ещё.

Если ваша команда управляет ещё и многоканальными сообщениями, заметка о лучших практиках web push-уведомлений напомнит, что гигиена downstream-событий — это не только проблема email. Та же дисциплина нужна и там, где система уведомлений зависит от чистого приёма событий.

6. Проверьте один транзакционный поток целиком в staging и в shadow mode на проде

Выберите один тип письма с низким риском и протестируйте только его. Уведомление о доставке или внутреннее оповещение обычно безопаснее, чем сброс пароля. В staging проверьте получателя, тему, тело, вложение, ссылку и последовательность событий от отправки до доставки. Затем повторите тот же тест в production shadow mode, чтобы поведение живого приложения было видно без воздействия на пользователей.

Shadow mode означает, что приложение отправляет реальное production-событие в YourTrend, а пользователь всё ещё получает письмо через Mailgun, либо оно дублируется так, что получатель не видит оба сообщения. Конкретная схема зависит от вашей архитектуры, но цель проста: наблюдать, не мешая.

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

Документируйте любое расхождение, даже небольшое. Отсутствующий тег отписки или другой префикс message ID может и не заблокировать переход, но повлияет на поиск и отчётность. Одна пропущенная деталь позже превращается в три тикета.

7. Переключите только выбранный поток Mailgun и оставьте откат готовым

Теперь переведите только выбранный путь. Не всю почту. Не все шаблоны. Только тот поток, который вы уже протестировали. Переключите маршрутизацию так, чтобы этот сценарий в продакшене обслуживал YourTrend, и оставьте маршрут Mailgun доступным за быстрым переключателем отката.

Откат должен быть реальным действием, а не обещанием. Команда должна знать, кто может его запустить, какое условие его запускает и сколько времени нужно, чтобы вернуть этот поток в Mailgun. Если отрисовка шаблона выглядит некорректно, если обработка webhook теряет поля или поведение доставки меняется так, что это видно вашей службе поддержки, сначала откатите этот путь, а уже потом разбирайтесь.

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

Кратко и конкретно фиксируйте заметки по откату. Кто меняет флаг? Какой поток возвращается обратно? Какая строка лога доказывает, что переключение произошло? Это не теоретические вопросы. От них зависит, можно ли исправить плохой шаблон за 10 минут или за 2 часа.

Если одновременно с переходом вы проверяете идентичность отправителя и аутентификацию, гайд по настройке аутентификации email будет разумным дополнением. Проблемы SPF, DKIM и DMARC легче заметить до отправки первого production-письма, чем после появления первого тикета в поддержку.

Как только выбранный поток несколько раз подряд отработает без сбоев, оставьте Mailgun нетронутым для остальных маршрутов, пока у каждого не будут свой аудит, обновление webhook, проверка шаблона и заметка об откате. Такая более медленная последовательность — это цена за то, чтобы оставаться онлайн во время миграции.