O drift de configuração aparece quando DEV, QA e PROD deixam de ser equivalentes no que deveria ser controlado: parâmetros externalizados, credenciais, endpoints, certificados, papéis, variáveis de deploy, schedulers, feature toggles ou regras de retentativa. O risco é prático. O mesmo pacote pode passar em QA e falhar em produção porque uma dependência foi alinhada apenas manualmente.
Reduzir drift não significa burocratizar cada ajuste. Significa saber qual configuração pode variar por ambiente, quem pode alterá-la, como isso fica evidenciado e qual comparação mínima acontece antes de promover uma versão.
1) Separar desenho de configuração operacional
Um bom ponto de partida é distinguir o que pertence ao desenho do iFlow e o que pertence à operação do ambiente. O desenho deve viajar sob controle; a configuração deve estar externalizada, documentada e restrita.
- Desenho: passos do fluxo, mapeamentos, validações, rotas, transformações e tratamento de erros.
- Configuração: URLs, aliases, credenciais, filas, timers, limites, flags e parâmetros por ambiente.
- Decisão operacional: quem aprova uma exceção temporária e quando ela deve ser removida.
Quando essa fronteira não existe, a correção urgente mistura código, configuração e critério operacional no mesmo movimento.
2) Definir uma matriz de configuração esperada
A matriz não precisa ser pesada, mas deve permitir comparar ambientes sem depender de memória. Uma versão útil inclui:
| Elemento | Pergunta de controle | Evidência |
|---|---|---|
| Endpoint | O host corresponde ao ambiente correto? | URL esperada, owner e data de revisão |
| Credential alias | O alias existe e seu uso está aprovado? | Nome do alias, responsável e janela de rotação |
| Parâmetros | O valor varia por ambiente ou deveria ser idêntico? | Valor esperado ou regra de variação |
| Scheduler | A frequência de QA representa o comportamento produtivo? | Frequência, fuso horário e restrições |
3) Controlar mudanças manuais sem negar a operação real
Em landscapes reais sempre haverá ajustes manuais: uma credencial que roda, um endpoint que muda, um teste de conectividade ou uma pausa temporária do scheduler. O problema não é que existam. O problema é não deixarem rastro.
4) Comparar antes de promover, não depois do incidente
Antes de mover uma versão para QA ou PROD, convém revisar uma lista curta:
- Parâmetros externalizados: valores esperados e diferenças justificadas.
- Credenciais e certificados: aliases existentes, validade e owner.
- Endpoints: host, path, autenticação, allowlist e dependência funcional.
- Scheduler e retentativas: frequência, janelas de carga e risco de duplicados.
- Observabilidade: logs, Correlation ID, alertas e critério de escalamento.
Essa revisão não substitui SAP Transport Management, SAP Cloud ALM nem monitoramento runtime. Ela funciona como uma camada de disciplina operacional para que esses controles não convivam com configuração invisível.
5) Tratar exceções como inventário vivo
Uma exceção aceita pode ser razoável: um endpoint temporário durante cutover, um scheduler reduzido para testes ou um certificado com rotação pendente. O importante é que tenha vencimento e responsável. Se uma exceção não tem data de revisão, ela vira configuração permanente por acidente.
6) Sinais de drift que merecem investigação
- O mesmo iFlow exige passos manuais diferentes para deploy em cada ambiente.
- QA usa endpoints, payloads ou credenciais que não representam produção.
- Aliases existem com nomes parecidos, mas sem convenção nem owner claro.
- Falhas são resolvidas alterando parâmetros diretamente no tenant sem evidência posterior.
- A comparação de ambientes depende de uma pessoa específica.
Em uma avaliação de governança de SAP CPI, o drift costuma aparecer como dívida silenciosa: nem sempre quebra hoje, mas reduz a confiabilidade de cada promoção futura. Por isso o Picasso CPI Governance Assessment revisa configuração, ownership, evidências e operabilidade sem sugerir que documentação substitui controles nativos da SAP.