Runbook de incidentes A2P SMS: detectar, acotar y gestionar degradaciones de entrega

Qué constituye una degradación de entrega A2P SMS

Un incidente A2P SMS no tiene que ser una caída total. Puede aparecer como un aumento de mensajes pendientes, una caída de los estados finales de entrega, más errores antes del envío, mayor latencia hasta el estado final o un comportamiento distinto en una combinación concreta de destino, remitente, codificación o ruta.

El objetivo de un runbook no es convertir una señal inicial en una conclusión apresurada. Es crear un proceso repetible para determinar qué parte del servicio está afectada, qué evidencia existe y qué medidas pueden aplicarse sin empeorar la situación ni incumplir requisitos locales, controles antiabuso o reglas de consentimiento.

La primera disciplina operativa consiste en no usar “entregado” como sinónimo de “enviado”. Un mensaje aceptado por un proveedor o carrier aguas arriba no equivale, por sí solo, a una confirmación de entrega al usuario final.

• Degradación de conectividad: la interfaz HTTP o SMPP no responde de forma fiable, presenta errores o aumenta su latencia.
• Degradación de aceptación: las solicitudes no llegan a ser aceptadas aguas arriba o fallan antes de progresar.
• Degradación de estados finales: crece la proporción de mensajes pendientes, no entregados, desconocidos o bloqueados según la taxonomía disponible.
• Degradación de latencia: los estados finales siguen llegando, pero lo hacen más tarde para una cohorte concreta.
• Degradación de observabilidad: el envío puede continuar, pero los callbacks o la ingesta de eventos están retrasados, incompletos o fallando.

Definir el servicio y sus límites de evidencia

Antes de activar una incidencia, defina qué representa cada estado en su integración. Muchas plataformas distinguen entre estados de cola, envío, aceptación por el carrier aguas arriba, entrega reportada y fallo. Los nombres pueden variar, pero el runbook debe documentar su significado concreto para cada proveedor o interfaz.

La aceptación aguas arriba es una evidencia útil de progreso, no una prueba absoluta de recepción en el terminal. Del mismo modo, un estado reportado como entregado depende de la información recibida a través de la cadena de mensajería. La recepción real en el dispositivo no siempre puede demostrarse de manera independiente desde la telemetría del proveedor.

También hay que separar el estado del mensaje de la salud del canal de observabilidad. Si el endpoint de callback falla, los mensajes pueden seguir teniendo estado en la plataforma emisora, aunque su sistema no haya recibido el evento.

• Resultado inmediato de envío: respuesta HTTP o PDU SMPP, identificador asignado y error, si existe.
• Estado asíncrono: transición posterior recibida mediante callback, stream de eventos o consulta del recurso de mensaje.
• Entrega reportada: confirmación disponible a través del carrier o canal correspondiente.
• Recepción en terminal: nivel de certeza limitado por la evidencia que el ecosistema de entrega pueda reportar.
• Observabilidad: disponibilidad, retraso y completitud de callbacks, consultas y procesos internos de ingesta.

Las señales mínimas de detección

La detección debe combinar señales de volumen, estado, tiempo y conectividad. Una sola métrica suele ser ambigua: una reducción de entregados puede indicar un problema real, pero también un aumento temporal de mensajes aún pendientes o un fallo en la recepción de eventos.

Mida tasas por estado sobre cohortes comparables y separe estados finales de los no finales. Un incremento de pendientes requiere observar su evolución y antigüedad antes de clasificarlo como fallo. Establezca ventanas temporales coherentes con sus expectativas operativas y con la posibilidad de recibir eventos tardíos.

Para latencia, registre las marcas temporales de aceptación, transición y llegada de eventos. Analice percentiles además de promedios: una media estable puede ocultar una cola significativa en una parte del tráfico.

• Volumen aceptado, fallido y pendiente por intervalo.
• Proporción de estados finales por cohorte, separada de mensajes aún no finalizados.
• Latencia entre aceptación y estado final, observada por percentiles.
• Errores HTTP, códigos de error del proveedor, errores SMPP y tasas de reconexión.
• Tiempo de respuesta y éxito de comprobaciones de enlace SMPP mediante enquire_link y enquire_link_resp.
• Disponibilidad del endpoint de callback, códigos de respuesta, reintentos y retraso de ingesta.
• Profundidad, antigüedad y ritmo de vaciado de las colas propias.

Segmentar antes de diagnosticar

No diagnostique una cohorte mezclada como si fuera una ruta homogénea. Segmente antes de atribuir causa o alcance. El mismo síntoma puede estar limitado a un país, una red móvil, un remitente, un tipo de tráfico, una codificación, mensajes multipartes o una ventana temporal específica.

Conserve los atributos disponibles en su telemetría y use siempre la misma definición de cohorte durante el incidente. Si cambia la segmentación entre actualizaciones, registre el cambio y evite comparar porcentajes calculados sobre poblaciones diferentes.

La codificación y el número de partes merecen atención específica. Los alfabetos de datos, incluido UCS2, y los mensajes divididos en varias partes pueden no ser comparables con mensajes de una sola parte bajo el alfabeto por defecto.

• Destino: país, red móvil cuando esté disponible y prefijo o agrupación definida internamente.
• Origen: remitente, tipo de identificador y configuración aplicable.
• Tráfico: OTP, transaccional, alertas u otros grupos operativos legítimos.
• Contenido técnico: codificación, número de partes y plantilla o versión de contenido cuando se registre.
• Ruta o proveedor: solo cuando ese atributo esté disponible y sea fiable en su propia telemetría.
• Tiempo: inicio observado, intervalo afectado y comparación con una ventana de referencia equivalente.

Clasificación inicial del incidente

La clasificación inicial no debe afirmar una causa raíz. Debe orientar el triage, la mitigación y la escalación. Use categorías que puedan revisarse a medida que lleguen eventos tardíos o evidencias adicionales.

Una comprobación SMPP satisfactoria con enquire_link confirma la salud básica del enlace de protocolo cuando se recibe la respuesta correlacionada con éxito. No confirma que los mensajes estén llegando a los terminales. Por ello, conectividad y entrega deben mantenerse como dimensiones separadas en el registro de incidente.

• Conectividad de interfaz: errores de sesión, timeouts, fallos de autenticación, reconexiones o ausencia de respuesta de enlace.
• Fallo antes del envío: solicitudes rechazadas o mensajes que no progresan desde el sistema emisor.
• Aceptación sin estado final: mensajes aceptados que acumulan antigüedad sin confirmación posterior.
• No entrega final: incremento de estados de no entrega, expiración, inalcanzable u otros códigos reportados.
• Bloqueo o filtrado reportado: estados o códigos asociados a spam, bloqueo de carrier o política, cuando el canal los exponga.
• Fallo de callback u observabilidad: el estado puede existir en origen, pero no llega o llega tarde a su sistema.
• Anomalía de medición: cambios de instrumentación, duplicados, pérdida de eventos o segmentación incorrecta.

Triage paso a paso en los primeros minutos

El primer objetivo es preservar la capacidad de investigar. Antes de cambiar rutas, límites o configuraciones, capture una instantánea de métricas y una muestra de mensajes representativa. Después, confirme si el problema está en la emisión, en la aceptación, en la entrega reportada o en la observabilidad.

Trabaje de lo general a lo específico. Compruebe primero si existe un problema de plataforma o conectividad compartido; después delimite por cohorte. Evite declarar que una red móvil o un proveedor es la causa sin una comparación controlada y datos correlacionables.

• 1. Abrir el registro con hora de detección, detector, síntoma, servicios implicados y alcance todavía desconocido.
• 2. Capturar tasas por estado, distribución de edad de pendientes, percentiles de latencia, errores de interfaz, salud de callbacks y profundidad de cola.
• 3. Verificar la conectividad HTTP o SMPP. En SMPP, comprobar la correlación correcta entre enquire_link y enquire_link_resp.
• 4. Comparar el intervalo afectado con una ventana de referencia equivalente y segmentar por destino, remitente, tráfico, codificación, partes y ruta disponible.
• 5. Revisar una muestra de identificadores de mensajes con sus respuestas iniciales, estados originales, errores y marcas temporales.
• 6. Consultar el estado desde la plataforma de origen cuando los callbacks estén ausentes o sean sospechosos.
• 7. Clasificar de forma provisional, asignar responsable técnico y decidir si procede una mitigación limitada.
• 8. Registrar cada cambio, su momento, la cohorte a la que se aplica y el resultado observado.

Mensajes de prueba: útiles, pero no concluyentes

Los mensajes de prueba sirven para comprobar hipótesis concretas, no para demostrar por sí solos el estado de toda una ruta. Un único dispositivo puede tener condiciones particulares: cobertura, disponibilidad temporal, configuración, almacenamiento o comportamiento propio del terminal.

Use destinos autorizados y números correctamente normalizados, habitualmente conforme al plan internacional E.164 cuando aplique. Mantenga la prueba mínima, trazable y equivalente a la cohorte que desea observar: mismo destino o grupo de destino, remitente, clase de tráfico permitida, codificación y estructura de mensaje.

No use pruebas para eludir filtros, controles antiabuso, consentimiento o requisitos locales. Si una señal apunta a bloqueo o filtrado, la respuesta correcta es revisar cumplimiento, configuración y evidencia disponible, no cambiar el contenido para intentar sortear controles.

• Defina la hipótesis antes de enviar la prueba.
• Use números de prueba autorizados y evite incluir datos sensibles.
• Registre identificador, origen, destino, hora, codificación, número de partes, resultado inicial y estados posteriores.
• Compare varias muestras homogéneas cuando el volumen y los controles operativos lo permitan.
• Contraste el resultado con la telemetría agregada; no extrapole desde un único terminal.
• Si el problema parece limitado a pocos dispositivos, descarte causas propias de esos dispositivos antes de atribuirlo a la ruta.

Mitigación controlada y protección del tráfico crítico

La mitigación debe reducir riesgo mientras se mantiene la trazabilidad. No aplique cambios globales por una señal limitada a una cohorte. Priorice medidas reversibles, acotadas en el tiempo y documentadas.

Cuando haya congestión, aumento de cola o errores de capacidad, el control de ritmo, la priorización y las pausas selectivas pueden proteger el tráfico más crítico. En escenarios OTP o transaccionales, separe las colas por prioridad si su arquitectura lo permite y aplique los límites definidos por sus integraciones y acuerdos.

Las rutas alternativas solo deben utilizarse cuando estén autorizadas, configuradas y sean apropiadas para el destino y la clase de tráfico. Una alternativa no debe utilizarse para evitar controles de remitente, consentimiento, contenido o regulación local.

• Priorizar tráfico OTP y transaccional crítico frente a tráfico menos urgente, conforme a sus reglas internas.
• Aplicar límites de ritmo o pausas controladas a la cohorte afectada si existen señales de saturación o fallos sostenidos.
• Ajustar la gestión de cola y vigilar la antigüedad de mensajes para evitar que pierdan utilidad operativa.
• Aplicar rutas alternativas previamente autorizadas solo a las cohortes permitidas y registrar el cambio.
• No reintentar de forma indiscriminada mensajes ya aceptados: puede aumentar duplicados, carga y complejidad de reconciliación.
• No tratar un bloqueo o filtrado reportado como un problema de capacidad que pueda resolverse incrementando el volumen.