Переезд на новый SMS-шлюз без остановки уведомлений

Переезд на новый SMS-шлюз — это миграция производственного канала, а не простая замена URL и API-ключа. У провайдеров отличаются статусы, ограничения скорости, правила Sender ID, формат ошибок, callbacks и работа с длинными сообщениями. Без поэтапного плана можно получить дубли, потерянные DLR и незаметное ухудшение скорости.

Безопасная миграция строится вокруг адаптера, параллельного тестирования, небольшого первого трафика и готового отката. Сначала важно понять, как устроен SMS-шлюз, а затем отделить его контракт от бизнес-систем компании.

Инвентаризация перед миграцией

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

• владельца и назначение;
• тип трафика и приоритет;
• объём и пики;
• Sender ID и шаблоны;
• маршрут и операторы;
• срок жизни сообщения;
• формат номера и кодировку;
• текущие DLR и бизнес-реакции;
• требования к скорости и стоимости.

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

Слой адаптера

Бизнес-система не должна знать внутренние названия ошибок каждого провайдера. Введите собственный стабильный контракт: отправить сообщение, получить client message ID, нормализовать ответ и принять единый набор статусов.

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

Единый контракт включает идемпотентный ключ, тип трафика, шаблон, TTL и correlation ID. Не ограничивайтесь полями «номер» и «текст»: иначе важная логика снова окажется спрятана внутри конкретного провайдера.

Сопоставление возможностей

Сделайте таблицу различий:

• авторизация и управление ключами;
• лимиты запросов и сообщения в секунду;
• синхронные коды ошибок;
• поддержка client message ID;
• формат и подпись webhook;
• словарь DLR;
• validity period;
• Sender ID и согласование шаблонов;
• тарификация сегментов;
• инструменты тестирования и поддержки.

Если новая система не поддерживает привычную функцию, решение принимают до переключения. Например, отсутствие поиска по client ID усложняет обработку таймаута, а другой набор DLR требует обновить маппинг.

Тестовый контур

Начните с контролируемых номеров основных операторов. Проверьте кириллицу, латиницу, длинное SMS, переменные шаблона, Sender ID, неверный номер, таймаут, лимит частоты и финальные статусы. Отдельно убедитесь, что webhook для DLR проверяет подпись и переживает повтор события.

Сравнивайте не только «пришло или нет». Измерьте число сегментов, время до принятия API, время до DLR, исходные и нормализованные коды. Сохраните message ID для обращения в поддержку нового провайдера.

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

Shadow и canary без дублей

Shadow-режим не должен отправлять одно SMS через два шлюза. Новый адаптер может параллельно валидировать запрос, рассчитывать маршрут и записывать предполагаемый результат без внешнего вызова. Так проверяются совместимость данных и объёмы.

Затем включают canary: небольшую устойчивую долю реальных сообщений направляют только в новый шлюз. Группу выбирают детерминированно, например по хешу внутреннего ID, чтобы один клиент не прыгал между маршрутами при каждом запросе.

Критичные OTP не обязательно брать первыми. Начните со сценария с понятным TTL, небольшим риском и достаточным объёмом для измерения. После стабильности переходите к следующему классу.

Метрики принятия решения

Старый и новый маршруты сравнивают в одинаковых временных окнах и по одинаковым сценариям:

• доля приёма с первой попытки;
• частота 4xx, 429, 5xx и таймаутов;
• p50/p95 времени до DLR;
• доля финальных доставок и просрочек;
• неизвестные коды статусов;
• обращения пользователей;
• число сегментов и стоимость;
• работа по операторам и Sender ID.

Методика расчёта задержки разобрана в статье про скорость доставки SMS. Не объявляйте победителя после нескольких ручных сообщений: нужна достаточная выборка и несколько периодов нагрузки.

Постепенное переключение

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

На каждом шаге есть автоматические стоп-условия: рост ошибок, нарушение SLO, неизвестные статусы, конфликт Sender ID или увеличение стоимости сверх порога. При срабатывании новая доля не растёт, а маршрут откатывается для ещё не отправленных задач.

Откат

Откат должен быть подготовлен до первого production-сообщения. Старые ключи, callback и мониторинг сохраняются на период миграции. Конфигурационный флаг позволяет вернуть новые задачи, не выпуская код.

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

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

Завершение миграции

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

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

Данные и договорные ограничения

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

Согласуйте формат отчётов, сроки поддержки, порядок эскалации и доступ к деталям доставки. Эти свойства трудно оценить по единичному тестовому SMS, поэтому включите их в критерии приёмки рядом со скоростью и ценой.

Чек-лист готовности к 100%

Перед полным переключением подтвердите: все сценарии найдены; Sender ID активны; статусы сопоставлены; webhook проверяет источник; лимиты и бюджеты настроены; canary прошёл на основных операторах; поддержка получила инструкцию; откат выполняется без релиза; старый маршрут продолжает принимать поздние DLR.

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

Первый расчёт после миграции

Сверьте количество бизнес-операций, вызовов API, message ID, DLR и строк тарификации. Несоответствие может показать дубли, потерянные callbacks или прямой источник, который остался на старом маршруте.

Сравнение проводят несколько раз: сразу после canary, после полного дня и после закрытия окна поздних статусов. Только затем старую интеграцию можно считать действительно неиспользуемой.

Итог

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