Disponibilidade não é entregabilidade: como medir três camadas de saúde numa rota A2P SMS

Uma rota disponível nem sempre está operacionalmente saudável

Nas operações de A2P SMS, chamar uma rota de “disponível” pode ocultar três perguntas diferentes. A ligação técnica está operacional? O sistema aceita as mensagens enviadas? As mensagens geram um resultado de entrega que possa ser interpretado e reconciliado? Uma resposta positiva à primeira pergunta não responde automaticamente às restantes.

Uma sessão SMPP pode ser estabelecida, responder às suas verificações de ligação e manter-se aberta enquanto uma rota apresenta rejeições de envio, acumulação de pedidos pendentes, degradação de latência ou uma redução dos DLR. Da mesma forma, um submit aceite pode significar que o SMSC aceitou a mensagem através da ligação SMPP, e não que o destinatário a recebeu.

A disponibilidade e a entregabilidade de rotas A2P SMS devem, por isso, ser avaliadas como um conjunto de sinais relacionados, mas não equivalentes. Separá-los evita que uma métrica favorável ou desfavorável domine uma decisão que exige contexto.

• Não utilize uma sessão ativa como substituto da entrega.
• Não contabilize pedidos aceites, colocados em fila ou enviados como mensagens entregues.
• Não interprete a ausência de um DLR como prova automática de não entrega sem rever o comportamento acordado da rota e o processo de reconciliação.
• Compare resultados entre populações homogéneas; não misture testes sintéticos com tráfego de produção numa única percentagem.

As três camadas de medição

O modelo operacional mais útil separa a saúde da rota em três camadas. A primeira é a disponibilidade técnica entre os sistemas que trocam tráfego. A segunda é a aceitação de cada pedido de envio. A terceira é o resultado posterior de entrega comunicado pelos mecanismos disponíveis.

Cada camada necessita dos seus próprios identificadores, janelas temporais, métricas e limiares internos. Requer também uma conclusão expressa com precisão: “conectividade confirmada”, “submit aceite” ou “DLR final recebido” descrevem factos distintos e não devem substituir-se entre si.

• Camada 1: disponibilidade técnica. Mede sessão, conectividade, respostas e tempos de resposta.
• Camada 2: aceitação de tráfego. Mede respostas aos envios, rejeições síncronas, pedidos pendentes, filas e timeouts.
• Camada 3: resultado de entrega. Mede DLR, estados finais, estados intermédios quando existirem e latência até ao resultado.

Camada 1: disponibilidade técnica não é prova de entrega

Em SMPP, enquire_link e enquire_link_resp servem para verificar a fiabilidade da via de comunicação e o funcionamento da ligação aplicacional entre o ESME e o SMSC. São sinais adequados para confirmar se a sessão responde, detetar perdas de conectividade e medir o tempo de resposta dessa troca.

Estes sinais não provam que uma mensagem tenha sido encaminhada para uma rede móvel, que o destino esteja acessível nem que o assinante tenha recebido um SMS. O próprio modelo SMPP reserva mecanismos distintos para solicitar e transportar recibos de entrega.

A medição da conectividade deve registar o ciclo de vida da sessão e os eventos de manutenção, sem extrapolar esses resultados para a camada de entrega.

• Hora de estabelecimento e encerramento da sessão.
• Resultado do bind e erros de sessão.
• Envios de enquire_link, respostas recebidas, perdas e tempo de resposta.
• Reconexões, duração das interrupções e frequência de timeouts.
• Eventos separados por conta, ligação, rota declarada quando aplicável e janela temporal.

Camada 2: o que demonstra a aceitação de tráfego

A aceitação responde a uma pergunta mais restrita do que a entrega: o extremo recetor aceitou este pedido neste momento? No fluxo SMPP, uma resposta bem-sucedida a um pedido de envio pode comprovar a aceitação da mensagem pelo SMSC através da ligação. O resultado posterior exige acompanhamento, normalmente através de um Delivery Receipt solicitado para a mensagem.

Em plataformas de mensagens baseadas em API, existe uma distinção equivalente: um pedido pode ser aceite ou colocado em fila antes de a mensagem ser enviada para uma operadora a montante e antes de existir uma confirmação ou um recibo de não entrega. Trate cada transição como uma etapa, não como uma garantia retrospetiva.

A capacidade também não deve ser inferida apenas a partir de um bind aberto. O SMPP não define um máximo universal de operações pendentes; este depende da implementação do SMSC. Por isso, uma rota aparentemente disponível pode degradar-se à medida que aumentam os pedidos concorrentes.

• Registe códigos de resposta de submit e rejeições síncronas.
• Meça timeouts de resposta e pedidos pendentes ou não confirmados.
• Observe a evolução das filas e falhas de envio quando a interface expuser esses estados.
• Associe cada envio ao seu identificador de mensagem, destino normalizado, remetente, conteúdo ou classe de conteúdo, rota e marca temporal.
• Avalie a aceitação sob uma carga autorizada e controlada; um teste isolado não caracteriza a capacidade sustentada.

Camada 3: DLR e os limites da evidência de entrega

Um SMSC Delivery Receipt é um sinal que o SMSC gera ao detetar o estado final de uma mensagem registada. Em SMPP, pode ser recebido através de deliver_sm ou data_sm e inclui campos úteis para correlação e interpretação, como o identificador da mensagem recebida, message_state e, quando presente, network_error_code.

Um DLR final é uma evidência mais próxima do resultado de entrega do que uma resposta de submit, mas continua a ser um sinal do ecossistema de mensagens, e não uma prova universal e independente de leitura, interação ou receção verificada no terminal. A semântica concreta e o alcance das confirmações dependem da rede, do fornecedor e da implementação.

Os estados intermédios merecem um tratamento separado. Podem indicar, por exemplo, uma tentativa inicial falhada enquanto a mensagem permanece retida para novas tentativas. O seu suporte é específico da implementação do SMSC e do fornecedor; não presuma que todas as rotas os emitirão, nem compare a sua ausência como se fosse necessariamente uma falha.

• Conserve o identificador de envio e o identificador referenciado no DLR para reconciliar eventos.
• Separe DLR finais de notificações intermédias.
• Meça o tempo desde a aceitação até ao DLR, além da proporção de DLR recebidos dentro de uma janela definida internamente.
• Classifique os estados de acordo com a documentação contratual e técnica de cada integração; não force equivalências entre vocabulários diferentes.
• Descreva “DLR de entrega recebido” sem o transformar em “leitura confirmada” ou “receção independente no terminal”.

Conceber testes sintéticos legítimos e controlados

Os testes sintéticos ajudam a detetar alterações de comportamento antes de afetarem amplamente o tráfego, mas devem ser realizados apenas para destinos autorizados e com controlos de conformidade. O seu valor resulta de manter variáveis conhecidas, e não de tentar reproduzir toda a diversidade do tráfego comercial.

Utilize destinos de teste sob controlo ou com autorização expressa. Normalize os números de acordo com a norma E.164 para reduzir ambiguidades de formato e manter uma segmentação consistente por país ou destino internacional. Mantenha um inventário dos destinos, da autorização aplicável, da rota prevista, do remetente e do perfil de conteúdo utilizado.

Conceba casos que permitam comparar o mesmo sinal ao longo do tempo. Se alterar simultaneamente o destino, o remetente, o texto e a rota, será difícil atribuir a causa de uma variação.

• Defina um conjunto autorizado de destinos de teste e reveja-o periodicamente.
• Teste separadamente a conectividade, o submit, a correlação de DLR e o tempo até ao resultado.
• Mantenha textos legítimos, não enganosos e adequados às políticas aplicáveis.
• Varie uma dimensão de cada vez: destino, operadora, remetente, tipo de conteúdo ou rota declarada, quando aplicável.
• Registe a versão do caso de teste, hora, identificadores, respostas síncronas, eventos assíncronos e observações.
• Não transforme um resultado de teste numa garantia para todos os destinos, remetentes ou tipos de tráfego.

Complementar com produção sem misturar populações

O tráfego de produção oferece cobertura real de destinos, remetentes e situações operacionais que um teste sintético não reproduz. No entanto, incorpora variabilidade: campanhas, picos de OTP, alterações de conteúdo, diferenças de consentimento, comportamento dos terminais e políticas aplicáveis. Por isso, serve para observar padrões, mas exige segmentação antes de atribuir uma causa à rota.

Mantenha os resultados sintéticos e os de produção como populações distintas. Uma queda simultânea em ambos os grupos pode justificar uma investigação prioritária. Um desvio apenas em produção pode exigir primeiro a revisão de alterações na composição, no remetente, no conteúdo ou no destino antes de concluir que existe uma degradação de conectividade ou de entrega.

A monitorização deve conservar identificadores persistentes e reconciliar eventos assíncronos. Se faltar um callback, a ausência do evento não deve transformar-se imediatamente numa conclusão; quando a interface disponível permitir consultar o estado, utilize-a como parte do processo de reconciliação.

• Identifique cada registo como sintético ou produção.
• Segmente a produção por destino, operadora quando conhecida, tipo de tráfego, remetente, conteúdo ou modelo e rota declarada, quando aplicável.
• Não compare diretamente um teste para um único destino com uma campanha multissegmento.
• Reveja o estado das mensagens que permaneçam sem resultado terminal dentro da janela operacional definida.
• Conserve evidências de alterações de configuração, incidentes e ajustes de tráfego juntamente com as métricas.

Métricas e padrões que exigem atenção

O painel de controlo deve apresentar séries separadas por camada. Um único valor de disponibilidade pode ocultar que a ligação está saudável enquanto os submits são rejeitados, ou que os submits são aceites enquanto diminui a proporção observada de DLR finais.

Procure alterações face a uma linha de base comparável, não apenas valores absolutos isolados. A comparação faz sentido quando preserva o mesmo grupo de destino, operadora se disponível, remetente, perfil de conteúdo, rota declarada e faixa horária. Alterações na composição podem produzir um sinal aparente de degradação sem que a causa seja a conectividade.

Entre os padrões de interesse encontram-se conectividade estável com queda de DLR, aumento de rejeições síncronas com sessões saudáveis, crescimento de pedidos pendentes, aumento da latência de submit ou de DLR e concentração de resultados adversos numa única combinação de destino, remetente ou conteúdo.

• Conectividade: percentagem de sessões operacionais, perdas de keepalive, reconexões e latência de resposta.
• Aceitação: proporção de respostas bem-sucedidas, rejeições por código, timeouts, pendentes e tempo de resposta ao envio.
• Entrega: proporção de DLR final recebido, distribuição de estados, tempo até ao DLR e mensagens sem resultado reconciliado.
• Segmentação: destino em E.164, operadora quando disponível, remetente, tipo de tráfego, conteúdo ou modelo, rota declarada e população de teste ou produção.
• Evidência: identificadores correlacionáveis, marcas temporais, códigos de erro disponíveis e alterações operacionais associadas.