Falha de conectividade ou degradação de rota A2P SMS: como isolar a causa com evidências

Conectividade, aceitação e entrega são sinais distintos

Um incidente de A2P SMS pode surgir em diferentes pontos do percurso. A conexão pode falhar antes do envio da mensagem; a plataforma ou o SMSC pode rejeitá-la; o envio pode ser aceito sem que haja ainda um resultado final; ou uma falha pode ocorrer após a aceitação. Cada situação exige evidências diferentes.

No SMPP, uma resposta bem-sucedida a submit_sm indica que o SMSC aceitou a mensagem para envio posterior. Isso, por si só, não confirma que ela chegou ao telefone. Da mesma forma, ENQUIRE_LINK e ENQUIRE_LINK_RESP verificam a conexão de aplicação entre ESME e SMSC, não a entrega pela rede móvel.

• Conexão ou sessão: verifique se o cliente consegue estabelecer e manter a comunicação com a interface.
• Resposta ao envio: determine se a solicitação foi aceita ou rejeitada e registre o motivo disponível.
• Resultado posterior: correlacione os relatórios de status com a mensagem original e verifique qual entidade os emitiu.
• Recepção por uma pessoa: não deduza que alguém leu o SMS com base em uma resposta de protocolo ou em um DLR.

Delimite o percurso e preserve os identificadores

Antes de alterar rotas ou configurações, desenhe o percurso realmente utilizado pelo tráfego: aplicação cliente, integração HTTP ou sessão SMPP, plataforma, fornecedor e destino móvel. Anote em que ponto cada registro é gerado e quem produz cada resposta. O funcionamento interno de um Service Centre pode estar fora do que uma interface ou especificação permite observar; reconheça esse limite na análise.

Preserve horários e referências suficientes para conectar as etapas. No SMPP, registre o número de sequência da solicitação e da resposta, o identificador de mensagem retornado e, se chegar um recibo, a referência à mensagem original. Para HTTP, preserve o identificador de solicitação disponível, o horário, o endpoint e a resposta. Não presuma que identificadores de sistemas diferentes sejam intercambiáveis.

• Registre o horário do envio e o fuso horário, o destino em formato normalizado, o remetente, o tipo de tráfego e a rota selecionada.
• Guarde o código HTTP ou o status SMPP, o corpo ou os campos de erro pertinentes e o identificador de correlação disponível.
• Acrescente o horário e a origem de cada callback ou DLR, além da referência à mensagem.
• Proteja os dados pessoais e limite o acesso aos registros conforme as políticas aplicáveis.

Verifique primeiro a integração

Comece pelo lado que você controla. Em HTTP, separe erros de transporte das respostas HTTP e examine o código, o corpo e qualquer indicação de nova tentativa. Um 503 significa que o servidor não pode atender à solicitação temporariamente; pode estar associado, por exemplo, a sobrecarga ou manutenção, e o Retry-After pode orientar o tempo de espera. Um 429 significa que o servidor considera que foram enviadas solicitações em excesso durante um período; a resposta também pode incluir Retry-After. Um 502 identifica um problema de gateway ou proxy com uma resposta inválida do servidor upstream, mas não indica, por si só, qual componente originou o problema.

No SMPP, verifique o status do bind, desconexões, tempos limite, respostas às solicitações e a saúde da sessão. ESME_RTHROTTLED (0x58) indica que o ESME excedeu os limites permitidos nessa interface. Isso é evidência de limitação de taxa ali, não prova de degradação em uma rota de destino.

Verifique também a fila local, a confirmação de recebimento dos callbacks e a lógica de novas tentativas. O SMPP não garante idempotência por si só. Se ocorrer um tempo limite, pode ser impossível saber apenas com esse sinal se o SMSC processou a solicitação. Antes de tentar novamente, use os mecanismos documentados de correlação e consulta de status disponíveis, se houver; não presuma que seja sempre possível determinar se a operação já foi aceita.

• Se a conexão ou o bind falhar, investigue primeiro as credenciais, a configuração da sessão, a conectividade e os limites da interface.
• Se receber rejeições, agrupe-as por código e preserve as respostas originais antes de alterar parâmetros.
• Se houver 429 ou ESME_RTHROTTLED, compare o volume e a taxa de solicitações com os limites acordados; não os classifique automaticamente como falha de cobertura.
• Se houver 503 ou 502, consulte o responsável pelo componente que respondeu e forneça o horário, o identificador e a resposta observada.

Procure padrões por destino e atributos do tráfego

Investigue uma degradação de rota procurando diferenças repetíveis entre segmentos, em vez de isolar uma mensagem sem contexto. Compare destinos, operadoras quando a informação for confiável, remetentes, tipo de tráfego, rota e período. Sempre que possível, mantenha constantes os demais atributos relevantes: uma comparação entre envios diferentes pode confundir o efeito da rota com mudanças de destinatário, remetente, conteúdo ou configuração.

Registre qual segmento falha e qual serve de comparação. Se um incidente coincidir com uma operadora de destino, isso é uma pista para delimitar a investigação; não basta para provar que a rede dessa operadora seja a causa. Valide se a amostra e os parâmetros são comparáveis e solicite evidências adicionais às partes que controlam as etapas não visíveis.

• Agrupe os casos por país ou destino, operadora conhecida, remetente, tipo de tráfego OTP/transacional/marketing, rota e período.
• Compare separadamente as taxas de aceitação, rejeição e status finais; não misture métricas com definições diferentes.
• Verifique se as mensagens comparadas têm configurações equivalentes e se os períodos são coerentes.
• Anote alterações de configuração, volume ou comportamento do cliente que coincidam com o início do problema.

Compare amostras controladas sem confundir correlação com causa

Selecione amostras equivalentes e defina antecipadamente qual sinal será comparado: resposta de envio, tempo até uma resposta, recebimento de um callback ou status reportado. Evite combinar em um único número eventos que ocorrem em etapas distintas. Uma diferença observada entre dois segmentos ajuda a formular hipóteses, mas não estabelece causalidade por si só.

Quando for seguro e autorizado, faça comparações limitadas com tráfego legítimo e consentido. Não altere várias variáveis ao mesmo tempo: se mudar rota, remetente e configuração simultaneamente, será mais difícil saber o que alterou o resultado. Coordene os testes com os responsáveis pertinentes e evite gerar tráfego adicional desnecessário.

• Defina o grupo afetado, um grupo de comparação e o período antes de analisar os resultados.
• Controle o destino, o remetente, o tipo de mensagem, a configuração e as condições de envio relevantes.
• Separe as medidas de aceitação das medidas de entrega e indique os dados ausentes.
• Repita a comparação em outro período se o volume ou a composição da amostra puder explicar a diferença.

Interprete os DLR conforme a origem e o alcance

Um DLR é um sinal cujo significado depende de quem o emite e de como está definido na integração. Na especificação 3GPP, um relatório do Service Centre confirma o recebimento pelo centro, não necessariamente pelo terminal; um relatório emitido pela estação móvel confirma o recebimento pelo terminal, não que o usuário tenha lido a mensagem. Verifique a origem do relatório e o status que ele representa antes de usá-lo como evidência.

Um SMS-STATUS-REPORT informa o status do envio, mas não equivale automaticamente a uma confirmação de recebimento por uma pessoa. Também pode haver diferenças entre o que uma interface chama de “entregue” e o evento técnico que sustenta esse status. Se o emissor do DLR ou sua semântica não estiverem claros, documente essa incerteza e peça esclarecimentos ao fornecedor.

• Correlacione o relatório com o identificador da mensagem original e preserve o horário.
• Pergunte qual entidade gera o status, qual evento ele confirma e quais status de falha pode representar.
• Diferencie a ausência de DLR, o atraso do relatório e o status de falha; não os trate como equivalentes.
• Não use um DLR isolado para atribuir o problema à rede móvel, ao fornecedor ou ao terminal.

Árvore de decisão para isolar e escalar

Faça o diagnóstico em ordem, da primeira etapa observável ao resultado posterior. Interrompa a investigação na primeira etapa cujas evidências não estejam disponíveis e solicite os registros necessários; não passe de um sintoma de integração diretamente a uma conclusão sobre a rede de destino.

Se o serviço estiver degradado, priorize medidas seguras e reversíveis: reduza ou pause o tráfego afetado quando houver risco de duplicação, abuso ou impacto operacional e siga o procedimento acordado para mudar de rota. Não presuma que exista uma rota alternativa, que ela ofereça o mesmo comportamento ou que esteja autorizada para esse tráfego.

• Sem conexão HTTP ou bind SMPP: reúna horários, erros de transporte, status da sessão e alterações recentes; encaminhe à equipe responsável pela conectividade ou integração.
• Há sessão, mas o envio é rejeitado: agrupe os códigos e as respostas. Verifique o formato e os limites da interface; encaminhe exemplos que possam ser correlacionados.
• O envio foi aceito, mas falta o resultado: verifique callbacks, tempos limite e o significado do DLR. Solicite ao fornecedor o status da etapa posterior; a aceitação não comprova a entrega.
• Os relatórios mostram falhas concentradas por segmento: valide amostras equivalentes e compartilhe o padrão com o fornecedor e as partes de destino, sem declarar a causa até haver evidências dessa etapa.
• Há resultados contraditórios ou identificadores que não se correlacionam: suspenda as conclusões, verifique relógios, referências e duplicatas e reconstrua o percurso com os registros originais.

Documente evidências, incertezas e ações

Um bom relatório permite que outra equipe reproduza o raciocínio sem presumir a causa. Separe fatos observados, hipóteses e conclusões; indique quais sistemas forneceram cada registro e que parte do percurso continua fora do campo de observação. Anexe uma amostra pequena e representativa, com os dados protegidos, e não apenas capturas agregadas sem identificadores.

Os padrões definem limites e sinais diferentes para cada etapa: conexão, aceitação e relatórios de status. O diagnóstico deve refletir esses limites e distinguir observações verificáveis de hipóteses que ainda precisam de evidências.

• Resuma o impacto, o início e o fim conhecidos, os segmentos afetados e não afetados e as alterações recentes.
• Inclua horários, identificadores, respostas originais e a definição de cada status analisado.
• Identifique cada item como fato, hipótese, dado pendente ou ação tomada.
• Registre quem deve fornecer as próximas evidências e quando o diagnóstico será revisado.