Voltar ao blog Operações de SMS

Escalonamento de incidentes de SMS A2P entre provedores: responsabilidades e evidências

Um guia prático para coordenar investigações de SMS A2P entre vários provedores, documentar o que foi observado e evitar atribuir causas sem evidências suficientes.

Equipe de operações coordenando um incidente de SMS A2P entre vários provedores

Por que um incidente pode atravessar várias fronteiras operacionais

Em uma cadeia de atacado, uma mensagem pode passar por várias empresas ou sistemas antes de chegar ao destino. As evidências disponíveis para este guia não permitem determinar o que cada participante vê, como os registros são correlacionados entre operadores nem qual sistema originou um incidente. Portanto, um relato do cliente, por si só, não basta para atribuir uma causa.

Como precaução operacional, pode ser útil distinguir os dados observados diretamente das informações recebidas de outras partes. Essa organização ajuda a descrever o que se sabe e o que não foi confirmado, mas não constitui um procedimento respaldado aqui por uma norma técnica.

  • Descreva quais informações você observou diretamente e quais recebeu de outra parte.
  • Não pressuponha que todos os participantes usam as mesmas referências, os mesmos status ou as mesmas janelas de horário.
  • Indique quais aspectos ainda não foram confirmados, em vez de apresentar uma explicação provisória como causa.
Por que um incidente pode atravessar várias fronteiras operacionais

Designe um responsável pelo caso e contatos para cada etapa

Como proposta de organização interna, pode-se designar uma pessoa ou equipe para reunir as informações do caso e coordenar as comunicações. Isso não implica que ela controle sistemas de terceiros ou possa determinar, por conta própria, onde um problema se originou.

As evidências disponíveis não estabelecem como as responsabilidades devem ser atribuídas entre provedores nem quais são os canais, prazos ou requisitos de escalonamento. Se esses pontos forem acordados internamente ou entre as partes, convém identificá-los como acordos, sem apresentá-los como uma regra universal.

  • Se for útil para sua organização, atribua uma referência interna ao caso.
  • Identifique os contatos e canais acordados entre as partes.
  • Não apresente prioridades ou prazos de atualização como requisitos universais.
  • Diferencie a coordenação do caso da investigação técnica de cada provedor.
Designe um responsável pelo caso e contatos para cada etapa

Reúna dados úteis antes de escalar

As evidências disponíveis não permitem estabelecer quais dados são mínimos ou suficientes para correlacionar uma mensagem entre provedores. Como sugestão prática, uma consulta pode descrever as informações disponíveis nos próprios sistemas e perguntar à outra parte de quais dados ela precisa para analisar seus registros.

Indique a origem e o contexto de cada dado e esclareça os horários e fusos horários quando forem relevantes. Ao compartilhar informações sobre destinos ou remetentes, use apenas os dados necessários e os canais aprovados pela sua organização.

  • Referência interna do caso e outras referências disponíveis.
  • Destino e remetente pertinentes à consulta, com tratamento adequado dos dados.
  • Data, hora, fuso horário e sistema de origem de cada dado temporal.
  • Status recebido, nome exato do campo ou evento e fonte que o informou.
  • Rota ou configuração, se constarem nos registros consultados.
  • Descrição concreta do impacto observado e do alcance conhecido, sem extrapolações.

Diferencie observações, informações recebidas e hipóteses

Como prática de documentação sugerida, você pode separar os registros do seu próprio sistema das declarações recebidas dos provedores e das explicações ainda não confirmadas. Essa distinção ajuda a esclarecer a origem de cada afirmação; as evidências disponíveis não a estabelecem como requisito técnico ou oficial.

Preserve o contexto dos dados e das comunicações pertinentes à investigação. Se uma interpretação for apresentada, identifique-a como interpretação e indique quais informações faltam para confirmá-la.

  • Observação própria: identifique o sistema e o registro consultado.
  • Informação de um provedor: indique quem a comunicou e quando.
  • Hipótese: descreva-a como provisória e indique o que ainda precisa ser verificado.
  • Não atribua uma causa apenas porque dois eventos coincidiram no tempo.

Acorde prioridades, atualizações e escalonamento

As evidências fornecidas não estabelecem prazos de resposta, prioridades, etapas de escalonamento nem critérios universais para defini-los. Se as partes precisarem dessas diretrizes, podem acordá-las conforme o relacionamento entre elas e documentar que se trata de acordos mútuos.

Descreva o impacto observado e o alcance conhecido. Não prometa uma resolução nem um prazo que não tenham sido confirmados pelas partes responsáveis.

  • Se forem definidas prioridades, documente os critérios acordados.
  • Combine com as partes o formato e a frequência das atualizações.
  • Registre qualquer escalonamento adicional e o motivo informado.
  • Se as partes puderem fazê-lo, use uma referência consistente nas comunicações relacionadas.

Interprete status e DLRs com cautela

As evidências disponíveis não incluem uma especificação técnica pertinente para determinar o que um DLR significa em uma implementação específica nem qual etapa o gera. Com as informações fornecidas, não é possível afirmar que um DLR confirme o recebimento ou a leitura do SMS no aparelho.

Antes de descrever um status, solicite a documentação aplicável à implementação e ao sistema que o comunica. Se essa informação não estiver disponível, limite o resumo a indicar qual status foi recebido, de quem e em que contexto, e deixe explícito o que não pôde ser verificado.

  • Preserve o texto do status e anote quem o comunicou.
  • Não apresente um DLR como prova de recebimento ou leitura no aparelho sem documentação aplicável que o sustente.
  • Não pressuponha que status semelhantes tenham o mesmo significado em sistemas diferentes.
  • Diferencie o status recebido daquilo que foi verificado separadamente.

Documente a cronologia do caso

Como sugestão de gestão, as informações relevantes da investigação podem ser reunidas em um registro do caso, com indicação da fonte e do momento em que foram recebidas. As evidências fornecidas não estabelecem requisitos de auditoria, conservação de registros ou prazos de retenção para incidentes de A2P entre provedores.

Se uma rota ou configuração for alterada durante a investigação, descreva a mudança e a finalidade informada. Não atribua uma mudança posterior no resultado a essa alteração sem evidências que permitam estabelecer essa relação.

  • Anote as comunicações e decisões que considerar relevantes para reconstruir o caso.
  • Indique a fonte e o horário dos dados registrados, quando disponíveis.
  • Descreva as alterações de rota ou configuração e o motivo informado.
  • Siga as políticas internas e os acordos aplicáveis sobre acesso e conservação.

Encerre o caso e registre o que ficou pendente

Ao encerrar um registro, você pode resumir o que foi observado, quais explicações foram confirmadas pelas partes e quais questões continuam sem resposta. As evidências fornecidas não estabelecem categorias oficiais de encerramento nem critérios técnicos para determinar uma causa.

Se forem acordadas medidas de acompanhamento, identifique quem as comunicou e o que ficou pendente. Não transforme uma explicação provisória em regra geral para incidentes futuros.

  • Resuma as observações e as fontes que as fundamentam.
  • Indique quais aspectos não puderam ser confirmados.
  • Registre as ações de acompanhamento acordadas entre as partes.
  • Diferencie as conclusões do caso das hipóteses ainda em aberto.
FAQ

Perguntas frequentes

Um DLR comprova que o SMS chegou ao telefone?

As evidências técnicas fornecidas não permitem determinar o que um DLR confirma em uma implementação específica. Não afirme que ele comprova o recebimento ou a leitura no aparelho sem documentação aplicável que sustente essa conclusão.

Quais dados convém incluir em uma consulta a um provedor?

Você pode descrever as referências, os dados pertinentes de destino e remetente, os horários e fusos horários, o status recebido e sua fonte, além do impacto observado. As evidências disponíveis não estabelecem um conjunto mínimo universal; compartilhe apenas o necessário por canais aprovados.

Quem deve coordenar um incidente que afeta vários provedores?

Sua organização pode designar uma pessoa para coordenar as informações e as comunicações. As evidências fornecidas não estabelecem uma atribuição universal de responsabilidades entre provedores. Coordenar o caso não implica controlar sistemas de terceiros nem determinar, por conta própria, a causa.

O que fazer se os provedores apresentarem versões diferentes?

Como medida de organização, registre separadamente as versões e suas fontes, solicite as informações que cada parte considerar necessárias para analisar o caso e deixe a divergência explícita se ela não puder ser resolvida. As evidências disponíveis não fornecem um procedimento oficial para arbitrá-la.

Fontes consultadas

  1. 3GPP specifications3GPP
  2. ITU-T E.164International Telecommunication Union
  3. GSMA resourcesGSMA