Скорость доставки SMS: как измерять задержку и контролировать SLA

Скорость доставки SMS — это не одно число из отчёта провайдера. Пользователь ощущает полное время от бизнес-события до появления сообщения на телефоне. В этот интервал входят задержка приложения, очередь, вызов SMS API, маршрутизация и сеть оператора. Чтобы управлять скоростью, эти этапы нужно измерять отдельно.

Среднее значение почти всегда недостаточно. Большинство SMS может приходить быстро, а небольшая доля — опаздывать на минуты. Для OTP и срочных уведомлений именно этот «хвост» определяет качество.

Точки времени

Сохраните несколько меток:

• occurred_at — бизнес-событие произошло;
• queued_at — задача устойчиво записана;
• attempt_started_at — начался вызов API;
• accepted_at — провайдер вернул message ID;
• provider_event_at — время статуса у провайдера;
• webhook_received_at — ваш endpoint получил DLR;
• processed_at — бизнес-система обработала статус.

Из них складываются разные интервалы. occurred_at → accepted_at показывает вашу подготовку и API. accepted_at → provider_event_at приблизительно отражает дальнейший маршрут. provider_event_at → webhook_received_at показывает задержку callback. Полный интервал до DLR объединяет всё.

DLR не подтверждает, что человек прочитал SMS, и время статуса может иметь ограничения конкретного оператора. Но для системного сравнения маршрутов это наиболее доступная техническая точка.

Почему не среднее

Если 99 сообщений доставлены за 5 секунд, а одно — за 10 минут, среднее составит около 11 секунд и скроет опыт одного клиента. Поэтому используйте распределение и перцентили: p50 описывает типичный случай, p95 — границу для 95% наблюдений, p99 — редкий хвост.

Не смешивайте сценарии. OTP, массовая кампания и ночное плановое уведомление имеют разные ожидания. Отдельно сегментируйте маршрут, оператора, регион, Sender ID и размер сообщения, если объёма данных хватает для устойчивого вывода.

Google SRE рекомендует измерять долю запросов, уложившихся в порог, и следить за хвостовой задержкой, потому что среднее скрывает выбросы (материал о SLO). Для SMS тот же принцип применяется к доле сообщений, получивших целевой DLR за заданное время.

SLI, SLO и SLA

Эти термины удобно разделять:

• SLI — фактический показатель, например доля OTP с DLR delivered не позднее 30 секунд;
• SLO — внутренняя цель для показателя;
• SLA — договорное обязательство и последствия его нарушения, если они предусмотрены.

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

Цель по нескольким порогам

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

Удобная формулировка: «не менее X% сообщений данного сценария получают целевой финальный статус за Y секунд в скользящем окне Z». Рядом фиксируются доля ошибок и просрочек. Цель не должна стимулировать скрывать неудачные сообщения из знаменателя.

Где искать задержку

Если растёт occurred_at → queued_at, проблема в приложении или создании задач. Если стареет очередь, не хватает пропускной способности либо массовый поток вытеснил срочный. Если API отвечает медленно, проверьте соединение и провайдера. Если accepted_at → DLR вырос только у одного оператора, вероятна проблема маршрута или сети.

Для диагностики нужны связанные логи SMS-отправок и надёжный webhook статусов. Без одинаковых идентификаторов этапы невозможно соединить в одну временную шкалу.

Неполные и поздние данные

Часть DLR приходит позже окна отчёта или не приходит вовсе. Если считать метрику только по уже полученным финальным статусам, результат будет завышен: медленные сообщения временно исчезнут из знаменателя.

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

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

Алерты

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

Разделяйте предупреждение и аварию. Небольшой рост p95 массового потока может требовать наблюдения, а та же задержка OTP — немедленной реакции и остановки кампаний. Для этого заранее настроены приоритеты SMS-трафика.

Проверка провайдера и собственного контура

Периодически отправляйте контролируемые сообщения на тестовые номера разных операторов и сравнивайте API, DLR и фактическое получение. Такой синтетический тест не заменяет продовые метрики, но помогает отделить отсутствие пользовательского трафика от поломки мониторинга.

Сравнивая провайдеров, используйте одинаковые сценарии, интервалы и выборки. Несколько ручных SMS в удачный момент не доказывают стабильный SLA. Важнее распределение на достаточном объёме и поведение во время пиков.

Базовая линия и сезонность

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

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

Изменение маршрута, Sender ID или шаблона отмечайте на графике. Без аннотаций команда увидит скачок, но не сможет связать его с production-изменением.

Ошибки измерения

Распространённая ошибка — начинать таймер после выхода задачи из очереди. Тогда самый важный backlog исчезает из метрики. Вторая ошибка — учитывать только delivered и исключать ошибки: медленный провал становится невидимым. Третья — смешивать время события провайдера в одной зоне с локальным временем сервера в другой.

Проверьте полноту соединения по message ID: долю отправок без DLR, callbacks без исходной записи и события с отрицательной длительностью. Если качество данных снизилось, SLO помечают неполным, а не публикуют точную на вид цифру.

Отчёт для бизнеса и техники

Бизнес-отчёт показывает долю своевременных сообщений по сценарию и влияние на клиента. Технический раскрывает этапы, маршруты и хвостовые задержки. Оба строятся из одной модели данных, чтобы команды не спорили из-за разных определений «доставлено вовремя».

Рядом с процентом указывайте абсолютный объём и окно. 99% из ста сообщений и 99% из миллиона требуют разной уверенности и масштаба реакции.

Итог

Контроль скорости начинается с временной шкалы от события до DLR. Перцентили, доля сообщений внутри порога и раздельные SLO по сценариям показывают реальный опыт лучше среднего. Когда задержка разложена на приложение, очередь, API, маршрут и webhook, команда понимает не только что стало медленнее, но и где искать причину.