Runbook d’incident A2P SMS : détecter, circonscrire et gérer les dégradations de livraison

Ce qui constitue une dégradation de livraison A2P SMS

Un incident A2P SMS ne doit pas nécessairement correspondre à une panne totale. Il peut se manifester par une hausse des messages en attente, une baisse des statuts finaux de livraison, davantage d’erreurs avant l’envoi, une latence accrue avant l’obtention d’un statut final ou un comportement différent pour une combinaison précise de destination, d’expéditeur, d’encodage ou de route.

L’objectif d’un runbook n’est pas de transformer un signal initial en conclusion hâtive. Il vise à créer un processus reproductible pour déterminer quelle partie du service est affectée, quelles preuves sont disponibles et quelles mesures peuvent être appliquées sans aggraver la situation ni enfreindre les exigences locales, les contrôles anti-abus ou les règles de consentement.

La première règle opérationnelle consiste à ne pas employer « livré » comme synonyme de « envoyé ». Un message accepté par un fournisseur ou un opérateur en amont ne constitue pas, à lui seul, une confirmation de livraison à l’utilisateur final.

• Dégradation de la connectivité : l’interface HTTP ou SMPP ne répond pas de manière fiable, présente des erreurs ou voit sa latence augmenter.
• Dégradation de l’acceptation : les requêtes ne sont pas acceptées en amont ou échouent avant de progresser.
• Dégradation des statuts finaux : la proportion de messages en attente, non livrés, inconnus ou bloqués augmente selon la taxonomie disponible.
• Dégradation de la latence : les statuts finaux arrivent toujours, mais plus tard pour une cohorte donnée.
• Dégradation de l’observabilité : l’envoi peut se poursuivre, mais les callbacks ou l’ingestion des événements sont retardés, incomplets ou défaillants.

Définir le service et les limites des preuves disponibles

Avant de déclarer un incident, définissez ce que représente chaque statut dans votre intégration. De nombreuses plateformes distinguent les statuts de mise en file d’attente, d’envoi, d’acceptation par l’opérateur en amont, de livraison signalée et d’échec. Les appellations peuvent varier, mais le runbook doit documenter leur signification exacte pour chaque fournisseur ou interface.

L’acceptation en amont est une preuve utile de progression, mais non une preuve absolue de réception sur le terminal. De même, un statut signalé comme livré dépend des informations reçues par la chaîne de messagerie. La réception réelle sur l’appareil ne peut pas toujours être démontrée indépendamment à partir de la télémétrie du fournisseur.

Il faut également distinguer le statut du message de l’état de santé du canal d’observabilité. Si le point de terminaison de callback échoue, les messages peuvent continuer d’avoir un statut sur la plateforme émettrice, même si votre système n’a pas reçu l’événement.

• Résultat immédiat de l’envoi : réponse HTTP ou PDU SMPP, identifiant attribué et erreur éventuelle.
• Statut asynchrone : transition ultérieure reçue via callback, flux d’événements ou consultation de la ressource du message.
• Livraison signalée : confirmation disponible via l’opérateur ou le canal concerné.
• Réception sur le terminal : niveau de certitude limité par les preuves que l’écosystème de livraison peut signaler.
• Observabilité : disponibilité, retard et exhaustivité des callbacks, des consultations et des processus internes d’ingestion.

Les signaux de détection minimaux

La détection doit combiner des signaux de volume, de statut, de temps et de connectivité. Une seule métrique est généralement ambiguë : une diminution des messages livrés peut indiquer un problème réel, mais aussi une augmentation temporaire de messages encore en attente ou une défaillance dans la réception des événements.

Mesurez les taux par statut sur des cohortes comparables et séparez les statuts finaux des statuts non finaux. Une augmentation des messages en attente impose d’observer leur évolution et leur ancienneté avant de la qualifier d’échec. Définissez des fenêtres temporelles cohérentes avec vos attentes opérationnelles et avec la possibilité de recevoir des événements tardifs.

Pour la latence, enregistrez les horodatages d’acceptation, de transition et de réception des événements. Analysez les percentiles en plus des moyennes : une moyenne stable peut masquer une file d’attente importante sur une partie du trafic.

• Volume accepté, échoué et en attente par intervalle.
• Proportion de statuts finaux par cohorte, distincte des messages non encore finalisés.
• Latence entre l’acceptation et le statut final, observée par percentiles.
• Erreurs HTTP, codes d’erreur du fournisseur, erreurs SMPP et taux de reconnexion.
• Temps de réponse et réussite des contrôles de liaison SMPP via enquire_link et enquire_link_resp.
• Disponibilité du point de terminaison de callback, codes de réponse, tentatives et retard d’ingestion.
• Profondeur, ancienneté et rythme de vidage de vos propres files d’attente.

Segmenter avant de diagnostiquer

N’analysez pas une cohorte mélangée comme s’il s’agissait d’une route homogène. Segmentez avant d’attribuer une cause ou un périmètre. Le même symptôme peut être limité à un pays, un réseau mobile, un expéditeur, un type de trafic, un encodage, des messages multiparties ou une fenêtre temporelle précise.

Conservez les attributs disponibles dans votre télémétrie et utilisez toujours la même définition de cohorte pendant l’incident. Si vous modifiez la segmentation entre deux mises à jour, consignez ce changement et évitez de comparer des pourcentages calculés sur des populations différentes.

L’encodage et le nombre de parties méritent une attention particulière. Les alphabets de données, y compris UCS2, et les messages répartis sur plusieurs parties peuvent ne pas être comparables aux messages en une seule partie utilisant l’alphabet par défaut.

• Destination : pays, réseau mobile lorsqu’il est disponible, et préfixe ou regroupement défini en interne.
• Origine : expéditeur, type d’identifiant et configuration applicable.
• Trafic : OTP, transactionnel, alertes ou autres groupes opérationnels légitimes.
• Contenu technique : encodage, nombre de parties et modèle ou version de contenu lorsqu’ils sont enregistrés.
• Route ou fournisseur : uniquement lorsque cet attribut est disponible et fiable dans votre propre télémétrie.
• Temps : début observé, intervalle affecté et comparaison avec une fenêtre de référence équivalente.

Classification initiale de l’incident

La classification initiale ne doit pas affirmer une cause racine. Elle doit orienter le triage, l’atténuation et l’escalade. Utilisez des catégories pouvant être révisées à mesure que des événements tardifs ou des preuves supplémentaires arrivent.

Un contrôle SMPP satisfaisant avec enquire_link confirme l’état de santé de base de la liaison de protocole lorsque la réponse corrélée est reçue avec succès. Il ne confirme pas que les messages arrivent sur les terminaux. La connectivité et la livraison doivent donc rester des dimensions distinctes dans le registre d’incident.

• Connectivité de l’interface : erreurs de session, timeouts, échecs d’authentification, reconnexions ou absence de réponse de liaison.
• Échec avant l’envoi : requêtes rejetées ou messages ne progressant pas depuis le système émetteur.
• Acceptation sans statut final : messages acceptés qui vieillissent sans confirmation ultérieure.
• Non-livraison finale : augmentation des statuts de non-livraison, d’expiration, d’injoignabilité ou d’autres codes signalés.
• Blocage ou filtrage signalé : statuts ou codes associés au spam, au blocage opérateur ou à une politique, lorsque le canal les expose.
• Échec de callback ou d’observabilité : le statut peut exister à l’origine, mais n’arrive pas ou arrive tardivement dans votre système.
• Anomalie de mesure : changements d’instrumentation, doublons, perte d’événements ou segmentation incorrecte.

Triage étape par étape durant les premières minutes

Le premier objectif est de préserver la capacité d’investigation. Avant de modifier les routes, les limites ou les configurations, capturez un instantané des métriques et un échantillon représentatif de messages. Confirmez ensuite si le problème se situe au niveau de l’émission, de l’acceptation, de la livraison signalée ou de l’observabilité.

Procédez du général au particulier. Vérifiez d’abord l’existence d’un problème de plateforme ou de connectivité partagé, puis délimitez-le par cohorte. Évitez d’affirmer qu’un réseau mobile ou un fournisseur est à l’origine du problème sans comparaison contrôlée ni données corrélables.

• 1. Ouvrir le registre avec l’heure de détection, le détecteur, le symptôme, les services concernés et un périmètre encore inconnu.
• 2. Capturer les taux par statut, la distribution d’ancienneté des messages en attente, les percentiles de latence, les erreurs d’interface, l’état de santé des callbacks et la profondeur des files d’attente.
• 3. Vérifier la connectivité HTTP ou SMPP. En SMPP, contrôler la corrélation correcte entre enquire_link et enquire_link_resp.
• 4. Comparer l’intervalle affecté à une fenêtre de référence équivalente et segmenter par destination, expéditeur, trafic, encodage, nombre de parties et route disponible.
• 5. Examiner un échantillon d’identifiants de messages avec leurs réponses initiales, statuts d’origine, erreurs et horodatages.
• 6. Consulter le statut depuis la plateforme d’origine lorsque les callbacks sont absents ou suspects.
• 7. Classifier provisoirement, attribuer un responsable technique et décider si une atténuation limitée est appropriée.
• 8. Consigner chaque changement, son heure, la cohorte à laquelle il s’applique et le résultat observé.

Messages de test : utiles, mais non conclusifs

Les messages de test servent à vérifier des hypothèses précises, et non à démontrer à eux seuls l’état d’une route entière. Un seul appareil peut présenter des conditions particulières : couverture, disponibilité temporaire, configuration, stockage ou comportement propre au terminal.

Utilisez des destinations autorisées et des numéros correctement normalisés, généralement conformément au plan international E.164 lorsque cela s’applique. Gardez le test minimal, traçable et équivalent à la cohorte que vous souhaitez observer : même destination ou groupe de destinations, expéditeur, catégorie de trafic autorisée, encodage et structure de message.

N’utilisez pas les tests pour contourner les filtres, les contrôles anti-abus, le consentement ou les exigences locales. Si un signal indique un blocage ou un filtrage, la réponse appropriée consiste à examiner la conformité, la configuration et les preuves disponibles, non à modifier le contenu pour tenter de contourner les contrôles.

• Définissez l’hypothèse avant d’envoyer le test.
• Utilisez des numéros de test autorisés et évitez d’inclure des données sensibles.
• Consignez l’identifiant, l’origine, la destination, l’heure, l’encodage, le nombre de parties, le résultat initial et les statuts ultérieurs.
• Comparez plusieurs échantillons homogènes lorsque le volume et les contrôles opérationnels le permettent.
• Confrontez le résultat à la télémétrie agrégée ; n’extrapolez pas à partir d’un seul terminal.
• Si le problème semble limité à quelques appareils, écartez les causes propres à ces appareils avant de l’attribuer à la route.

Atténuation contrôlée et protection du trafic critique

L’atténuation doit réduire les risques tout en préservant la traçabilité. N’appliquez pas de changements globaux sur la base d’un signal limité à une cohorte. Privilégiez les mesures réversibles, limitées dans le temps et documentées.

En cas de congestion, d’augmentation des files d’attente ou d’erreurs de capacité, la limitation de débit, la priorisation et les pauses sélectives peuvent protéger le trafic le plus critique. Dans les scénarios OTP ou transactionnels, séparez les files par priorité si votre architecture le permet et appliquez les limites définies par vos intégrations et vos accords.

Les routes alternatives ne doivent être utilisées que lorsqu’elles sont autorisées, configurées et adaptées à la destination et à la catégorie de trafic. Une alternative ne doit pas servir à contourner les contrôles liés à l’expéditeur, au consentement, au contenu ou à la réglementation locale.

• Prioriser le trafic OTP et transactionnel critique par rapport au trafic moins urgent, conformément à vos règles internes.
• Appliquer des limites de débit ou des pauses contrôlées à la cohorte affectée en présence de signes de saturation ou d’échecs persistants.
• Ajuster la gestion des files d’attente et surveiller l’ancienneté des messages afin d’éviter qu’ils perdent leur utilité opérationnelle.
• Appliquer des routes alternatives préalablement autorisées uniquement aux cohortes admissibles et consigner le changement.
• Ne pas réessayer indistinctement des messages déjà acceptés : cela peut augmenter les doublons, la charge et la complexité de réconciliation.
• Ne pas considérer un blocage ou un filtrage signalé comme un problème de capacité pouvant être résolu en augmentant le volume.