Runbook per incidenti A2P SMS: rilevare, circoscrivere e gestire i degradi di consegna

Cosa costituisce un degrado della consegna A2P SMS

Un incidente A2P SMS non deve necessariamente essere un'interruzione totale. Può manifestarsi come un aumento dei messaggi in attesa, una riduzione degli stati finali di consegna, più errori prima dell'invio, maggiore latenza fino allo stato finale o un comportamento diverso per una specifica combinazione di destinazione, mittente, codifica o instradamento.

L'obiettivo di un runbook non è trasformare un segnale iniziale in una conclusione affrettata. È creare un processo ripetibile per determinare quale parte del servizio sia interessata, quali evidenze siano disponibili e quali misure possano essere applicate senza peggiorare la situazione né violare requisiti locali, controlli antiabuso o regole sul consenso.

La prima disciplina operativa consiste nel non usare “consegnato” come sinonimo di “inviato”. Un messaggio accettato da un fornitore o carrier a monte non equivale, da solo, a una conferma di consegna all'utente finale.

• Degrado della connettività: l'interfaccia HTTP o SMPP non risponde in modo affidabile, presenta errori o aumenta la propria latenza.
• Degrado dell'accettazione: le richieste non vengono accettate a monte oppure falliscono prima di progredire.
• Degrado degli stati finali: aumenta la quota di messaggi in attesa, non consegnati, sconosciuti o bloccati, secondo la tassonomia disponibile.
• Degrado della latenza: gli stati finali continuano ad arrivare, ma più tardi per una coorte specifica.
• Degrado dell'osservabilità: l'invio può proseguire, ma i callback o l'acquisizione degli eventi sono in ritardo, incompleti o non funzionanti.

Definire il servizio e i suoi limiti di evidenza

Prima di attivare un incidente, definite cosa rappresenti ciascuno stato nella vostra integrazione. Molte piattaforme distinguono tra stati di coda, invio, accettazione da parte del carrier a monte, consegna segnalata e fallimento. I nomi possono variare, ma il runbook deve documentarne il significato specifico per ciascun fornitore o interfaccia.

L'accettazione a monte è un'evidenza utile di avanzamento, non una prova assoluta di ricezione sul terminale. Analogamente, uno stato segnalato come consegnato dipende dalle informazioni ricevute attraverso la catena di messaggistica. La ricezione effettiva sul dispositivo non può sempre essere dimostrata in modo indipendente dalla telemetria del fornitore.

Occorre inoltre separare lo stato del messaggio dalla salute del canale di osservabilità. Se l'endpoint di callback non funziona, i messaggi possono continuare ad avere uno stato nella piattaforma mittente, anche se il vostro sistema non ha ricevuto l'evento.

• Risultato immediato dell'invio: risposta HTTP o PDU SMPP, identificatore assegnato ed eventuale errore.
• Stato asincrono: transizione successiva ricevuta tramite callback, flusso di eventi o interrogazione della risorsa messaggio.
• Consegna segnalata: conferma disponibile tramite il carrier o il canale corrispondente.
• Ricezione sul terminale: livello di certezza limitato dalle evidenze che l'ecosistema di consegna può segnalare.
• Osservabilità: disponibilità, ritardo e completezza di callback, interrogazioni e processi interni di acquisizione.

I segnali minimi di rilevamento

Il rilevamento deve combinare segnali di volume, stato, tempo e connettività. Una sola metrica è spesso ambigua: una riduzione dei messaggi consegnati può indicare un problema reale, ma anche un aumento temporaneo dei messaggi ancora in attesa o un errore nella ricezione degli eventi.

Misurate i tassi per stato su coorti comparabili e separate gli stati finali da quelli non finali. Un incremento dei messaggi in attesa richiede l'osservazione della loro evoluzione e anzianità prima di classificarlo come fallimento. Definite finestre temporali coerenti con le vostre aspettative operative e con la possibilità di ricevere eventi tardivi.

Per la latenza, registrate le marche temporali di accettazione, transizione e arrivo degli eventi. Analizzate i percentili oltre alle medie: una media stabile può nascondere una coda significativa in una parte del traffico.

• Volume accettato, fallito e in attesa per intervallo.
• Proporzione degli stati finali per coorte, separata dai messaggi non ancora finalizzati.
• Latenza tra accettazione e stato finale, osservata per percentili.
• Errori HTTP, codici di errore del fornitore, errori SMPP e tassi di riconnessione.
• Tempo di risposta e successo dei controlli di collegamento SMPP tramite enquire_link ed enquire_link_resp.
• Disponibilità dell'endpoint di callback, codici di risposta, ritenti e ritardo di acquisizione.
• Profondità, anzianità e velocità di smaltimento delle code interne.

Segmentare prima di diagnosticare

Non diagnosticate una coorte mista come se fosse un instradamento omogeneo. Segmentate prima di attribuire causa o impatto. Lo stesso sintomo può essere limitato a un Paese, una rete mobile, un mittente, un tipo di traffico, una codifica, messaggi multipart o una specifica finestra temporale.

Conservate gli attributi disponibili nella telemetria e usate sempre la stessa definizione di coorte durante l'incidente. Se modificate la segmentazione tra gli aggiornamenti, registrate la modifica ed evitate di confrontare percentuali calcolate su popolazioni diverse.

La codifica e il numero di parti meritano un'attenzione specifica. Gli alfabeti dati, incluso UCS2, e i messaggi suddivisi in più parti potrebbero non essere comparabili con i messaggi a parte singola nell'alfabeto predefinito.

• Destinazione: Paese, rete mobile quando disponibile e prefisso o raggruppamento definito internamente.
• Origine: mittente, tipo di identificatore e configurazione applicabile.
• Traffico: OTP, transazionale, avvisi o altri gruppi operativi legittimi.
• Contenuto tecnico: codifica, numero di parti e modello o versione del contenuto, quando registrati.
• Instradamento o fornitore: solo quando tale attributo è disponibile e affidabile nella vostra telemetria.
• Tempo: inizio osservato, intervallo interessato e confronto con una finestra di riferimento equivalente.

Classificazione iniziale dell'incidente

La classificazione iniziale non deve affermare una causa radice. Deve guidare il triage, la mitigazione e l'escalation. Utilizzate categorie che possano essere riesaminate man mano che arrivano eventi tardivi o evidenze aggiuntive.

Un controllo SMPP riuscito con enquire_link conferma la salute di base del collegamento di protocollo quando la risposta correlata viene ricevuta correttamente. Non conferma che i messaggi stiano raggiungendo i terminali. Per questo, connettività e consegna devono essere mantenute come dimensioni separate nel registro dell'incidente.

• Connettività dell'interfaccia: errori di sessione, timeout, errori di autenticazione, riconnessioni o assenza di risposta del collegamento.
• Fallimento prima dell'invio: richieste rifiutate o messaggi che non avanzano dal sistema mittente.
• Accettazione senza stato finale: messaggi accettati che accumulano anzianità senza conferma successiva.
• Mancata consegna finale: aumento di stati di mancata consegna, scadenza, irraggiungibile o altri codici segnalati.
• Blocco o filtraggio segnalato: stati o codici associati a spam, blocco del carrier o policy, quando il canale li espone.
• Guasto del callback o dell'osservabilità: lo stato può esistere all'origine, ma non arriva oppure arriva tardi al vostro sistema.
• Anomalia di misurazione: modifiche alla strumentazione, duplicati, perdita di eventi o segmentazione errata.

Triage passo dopo passo nei primi minuti

Il primo obiettivo è preservare la capacità di investigare. Prima di modificare instradamenti, limiti o configurazioni, acquisite un'istantanea delle metriche e un campione rappresentativo di messaggi. Quindi, confermate se il problema riguarda l'emissione, l'accettazione, la consegna segnalata o l'osservabilità.

Procedete dal generale allo specifico. Verificate innanzitutto se esiste un problema condiviso di piattaforma o connettività; poi delimitatelo per coorte. Evitate di dichiarare che una rete mobile o un fornitore sia la causa senza un confronto controllato e dati correlabili.

• 1. Aprire il registro con ora di rilevamento, rilevatore, sintomo, servizi coinvolti e impatto ancora sconosciuto.
• 2. Acquisire tassi per stato, distribuzione dell'anzianità dei messaggi in attesa, percentili di latenza, errori di interfaccia, salute dei callback e profondità delle code.
• 3. Verificare la connettività HTTP o SMPP. In SMPP, controllare la corretta correlazione tra enquire_link ed enquire_link_resp.
• 4. Confrontare l'intervallo interessato con una finestra di riferimento equivalente e segmentare per destinazione, mittente, traffico, codifica, parti e instradamento disponibile.
• 5. Esaminare un campione di identificatori messaggio con le rispettive risposte iniziali, stati originali, errori e marche temporali.
• 6. Interrogare lo stato dalla piattaforma di origine quando i callback sono assenti o sospetti.
• 7. Classificare in modo provvisorio, assegnare un responsabile tecnico e decidere se sia opportuna una mitigazione limitata.
• 8. Registrare ogni modifica, il relativo momento, la coorte a cui viene applicata e il risultato osservato.

Messaggi di test: utili, ma non conclusivi

I messaggi di test servono a verificare ipotesi specifiche, non a dimostrare da soli lo stato di un intero instradamento. Un singolo dispositivo può avere condizioni particolari: copertura, disponibilità temporanea, configurazione, archiviazione o comportamento del terminale.

Utilizzate destinazioni autorizzate e numeri correttamente normalizzati, in genere conformi al piano internazionale E.164 quando applicabile. Mantenete il test minimo, tracciabile ed equivalente alla coorte che desiderate osservare: stessa destinazione o gruppo di destinazione, mittente, classe di traffico consentita, codifica e struttura del messaggio.

Non usate i test per eludere filtri, controlli antiabuso, consenso o requisiti locali. Se un segnale indica blocco o filtraggio, la risposta corretta è riesaminare conformità, configurazione ed evidenze disponibili, non modificare il contenuto per tentare di aggirare i controlli.

• Definite l'ipotesi prima di inviare il test.
• Usate numeri di test autorizzati ed evitate di includere dati sensibili.
• Registrate identificatore, origine, destinazione, ora, codifica, numero di parti, risultato iniziale e stati successivi.
• Confrontate più campioni omogenei quando il volume e i controlli operativi lo consentono.
• Confrontate il risultato con la telemetria aggregata; non estrapolate da un singolo terminale.
• Se il problema sembra limitato a pochi dispositivi, escludete cause specifiche di tali dispositivi prima di attribuirlo all'instradamento.

Mitigazione controllata e protezione del traffico critico

La mitigazione deve ridurre il rischio mantenendo la tracciabilità. Non applicate modifiche globali in risposta a un segnale limitato a una coorte. Privilegiate misure reversibili, limitate nel tempo e documentate.

In presenza di congestione, crescita della coda o errori di capacità, il controllo del ritmo, la prioritizzazione e le pause selettive possono proteggere il traffico più critico. Negli scenari OTP o transazionali, separate le code per priorità se la vostra architettura lo consente e applicate i limiti definiti dalle integrazioni e dagli accordi.

Gli instradamenti alternativi devono essere usati solo quando autorizzati, configurati e appropriati per la destinazione e la classe di traffico. Un'alternativa non deve essere usata per evitare controlli su mittente, consenso, contenuto o normativa locale.

• Dare priorità al traffico OTP e transazionale critico rispetto al traffico meno urgente, secondo le vostre regole interne.
• Applicare limiti di ritmo o pause controllate alla coorte interessata se vi sono segnali di saturazione o guasti persistenti.
• Adeguare la gestione delle code e monitorare l'anzianità dei messaggi per evitare che perdano utilità operativa.
• Applicare instradamenti alternativi precedentemente autorizzati solo alle coorti consentite e registrare la modifica.
• Non ritentare indiscriminatamente messaggi già accettati: ciò può aumentare duplicati, carico e complessità di riconciliazione.
• Non trattare un blocco o filtraggio segnalato come un problema di capacità risolvibile aumentando il volume.