Alterações de configuração HTTP e SMPP em SMS A2P: implementação e reversão

O que conta como alteração de configuração

Uma alteração de configuração modifica a forma como uma aplicação ou plataforma estabelece ou utiliza uma conexão, mesmo que o código da aplicação não mude. Pode afetar parâmetros da interface HTTP ou de uma conexão SMPP; o âmbito concreto depende da implementação e do contrato técnico com cada contraparte.

O SMPP é um protocolo de nível aplicacional que funciona sobre TCP/IP e é utilizado para trocar mensagens SMS. Esta descrição não determina, por si só, que parâmetros cada sistema pode alterar nem como os implementar. Para HTTP e SMPP, confirme o significado e as restrições de cada parâmetro na documentação técnica aplicável.

Este guia aborda o controlo da alteração: o que analisar antes, como limitar a exposição e o que registar. Não substitui os testes de regressão de uma integração completa nem descreve a manutenção de sessões ou a rotação de credenciais.

• Identifique o componente que será alterado e a conexão afetada.
• Distinga as alterações locais das que podem exigir coordenação com um fornecedor ou contraparte.
• Não deduza a compatibilidade apenas porque o parâmetro existe numa configuração.

Inventário prévio: âmbito e dependências

Antes de editar a configuração, crie um registo da alteração que permita responder ao que será modificado, onde será aplicado e quem deverá validar o resultado. O inventário deve descrever a situação existente e o âmbito previsto, sem presumir que todas as conexões partilham os mesmos parâmetros.

Associe cada conexão aos sistemas que a utilizam, às equipas responsáveis e às contrapartes que devem ser informadas da alteração. Se não conseguir identificar o âmbito com segurança, interrompa a preparação e complete o inventário antes de agendar a aplicação em produção.

• Registe o parâmetro e o componente afetados, o valor atual e a alteração proposta num sistema com acesso controlado.
• Anote as aplicações, os ambientes e as conexões potencialmente dependentes.
• Designe responsáveis pela aplicação, observação, decisão de interromper e reversão.
• Indique se há uma contraparte externa envolvida e se a documentação disponível exige coordenação.
• Defina explicitamente o âmbito inicial; evite incluir no mesmo processo conexões que não sejam necessárias.

Análise de impacto e compatibilidade

Classifique a alteração de acordo com o local onde é configurada e com quem controla o extremo correspondente. Uma alteração limitada a um sistema próprio ainda pode afetar os sistemas dependentes; se modificar uma expectativa partilhada com um fornecedor, não a trate como uma alteração puramente local.

Compare a nova configuração com a documentação técnica e os acordos aplicáveis à conexão. As fontes disponíveis não estabelecem uma lista universal de parâmetros compatíveis para todas as implementações HTTP ou SMPP: a compatibilidade deve ser confirmada na documentação das partes envolvidas.

Se não for possível verificar a compatibilidade, reduza o âmbito ou adie a alteração. Não use uma resposta HTTP ou um estado SMPP isolado como prova de que o fluxo completo está a funcionar corretamente.

• O parâmetro é local ou afeta uma expectativa partilhada?
• Existe documentação atualizada para ambos os extremos da conexão?
• Que sistemas ou processos poderão ser afetados se a conexão deixar de se comportar como esperado?
• Quem deve confirmar a compatibilidade antes da janela de alteração?
• Que observações permitirão distinguir um problema causado pela alteração de uma variação não relacionada?

Planeie a implementação antes de a aplicar

Documente as aprovações necessárias segundo os controlos da sua organização e prepare a validação num ambiente adequado, se disponível. Defina antecipadamente a janela, o âmbito inicial, a pessoa que executa e a pessoa que decide se o processo continua ou é interrompido.

Uma implementação gradual limita a exposição ao aplicar primeiro a alteração ao âmbito mais restrito que seja representativo e autorizado. Não presuma que todas as plataformas permitem dividir o tráfego ou as conexões dessa forma; confirme as opções de implementação disponíveis na sua arquitetura.

Especifique as condições de interrupção antes de começar. Se não houver uma forma verificável de observar o resultado ou de voltar a uma configuração anterior, considere que a alteração não está pronta para produção.

• Registe as aprovações, a janela e os responsáveis.
• Valide a configuração proposta fora do âmbito de produção, quando possível.
• Escolha um âmbito inicial que possa ser observado e controlado.
• Acorde que resultados permitem continuar e quais obrigam a interromper.
• Confirme que a configuração anterior está disponível para uma reversão autorizada.

Verificações posteriores: HTTP e SMPP

Após aplicar a alteração, verifique o comportamento a partir do sistema e da conexão afetados, utilizando as verificações documentadas para essa implementação. Compare os resultados com a linha de base anterior e registe o momento de cada observação. Não existe um conjunto universal de testes que possa ser considerado válido para todas as API HTTP ou todas as implementações SMPP.

Em HTTP, verifique se os pedidos pertinentes recebem as respostas esperadas segundo a documentação da interface e se os erros não apresentam alterações inesperadas. Uma resposta satisfatória pode indicar aceitação numa etapa do sistema; por si só, não demonstra que o SMS chegou ao dispositivo.

Em SMPP, observe o estado básico das conexões e a troca esperada segundo a documentação da contraparte. Não interprete a existência de uma sessão ou uma resposta protocolar como prova de entrega no telemóvel.

• Analise os registos e as métricas disponíveis para o componente alterado antes e depois da mudança.
• Verifique os erros de conexão e as respostas da interface de acordo com o significado definido na documentação correspondente.
• Se o sistema apresentar DLR, registe o estado comunicado e a sua origem; um DLR não equivale a receção verificada no terminal.
• Anote o intervalo observado e quaisquer diferenças em relação à linha de base, sem lhes atribuir automaticamente uma causa.

Critérios de reversão e controlo da exposição

A reversão não deve ser improvisada durante um incidente. Defina antes da alteração que condições obrigam a interromper a expansão, quem toma a decisão e quem repõe a configuração anterior. Os critérios devem basear-se nos sinais que é realmente possível observar e nos limites operacionais acordados pela equipa; não existe aqui um limite numérico universal.

Se surgir uma degradação que coincida com a alteração, limite a exposição e compare os registos antes de concluir que a alteração é a causa. Quando um critério acordado for atingido, interrompa a implementação e siga o procedimento aprovado para restaurar a configuração anterior. Em seguida, verifique o estado da conexão com as verificações disponíveis.

Guarde as evidências da alteração e da reversão. Não apague registos nem faça ajustes adicionais durante a recuperação sem os documentar: isso dificulta reconstituir a sequência e avaliar o resultado.

• Defina critérios observáveis e responsáveis por interromper e reverter.
• Estabeleça limites de exposição que a sua plataforma consiga efetivamente aplicar.
• Mantenha acessível a configuração anterior e confirme que corresponde ao componente afetado.
• Após reverter, confirme o comportamento com as mesmas verificações utilizadas para avaliar a alteração.
• Registe os incidentes e as ações adicionais, mesmo que a causa não seja confirmada.

Registo final e encerramento da alteração

Ao encerrar, deixe uma cronologia que permita reconstituir o que foi alterado, quando, por quem e o que foi observado. Distinga factos observados de interpretações: por exemplo, uma resposta aceite, um estado de entrega comunicado e uma receção no terminal são afirmações diferentes.

Se a alteração for revertida, registe também o momento, o motivo e as verificações posteriores. Se for mantida, documente as ações pendentes e quaisquer limitações que impeçam considerar o resultado conclusivo.

• Guarde a configuração anterior e a nova no sistema de registo autorizado, evitando expor segredos.
• Anote o âmbito, as conexões afetadas, as aprovações, os responsáveis e a hora da aplicação.
• Registe as verificações, os incidentes, a decisão final e as alterações de acompanhamento.
• Indique claramente o que se sabe, o que foi comunicado e o que não pôde ser verificado.