Integração ADMS ↔ Sustentação

Projeto: DSB26201 — Avaliação de arquitetura de integração ADMS (Energisa) Fonte: Reuniao-Sustentacao — "Assessment Integração ADMS com Sustentação (Consultoria Syntropy)" — 24/07/2026 (VTT, ~1h15min) + fluxos_adms_sigod.html (dashboard interno da própria equipe de sustentação) Status: Rascunho para validação Elaborado por: Consultoria Syntropy

Por que este artefato existe

Este artefato cobre a sessão de 24/07/2026 com a equipe de Sustentação (Wagner, Pedro, Lucas), focada no dia-a-dia operacional de diagnóstico e correção de incidentes no ecossistema ADMS/SIGOD/Kafka.

Há uma diferença estrutural em relação aos artefatos anteriores (GIS-ADMS e WFM-ADMS): não existe Ata no Assessment_Consolidado para esta reunião. O consolidado registra Atas 01 a 14 cobrindo o período de 17/06 a 31/07/2026, mas a Ata mais próxima em data — Ata 11, de 27/07 — é uma reunião distinta, com participantes diferentes (Fernando, Gabriel, Éder Xavier, Willians, Nicolas) e foco diferente (inventário de ferramentas de monitoramento, não as dores operacionais da sustentação). Não há qualquer Ata datada de 24/07 ou que cite Wagner, Pedro ou Lucas como participantes.

Isto não é um erro de fidelidade no sentido usual (fato inventado ou mal transcrito dentro de um texto existente) — é uma lacuna de cobertura: o conteúdo desta sessão simplesmente não foi consolidado em nenhuma Ata. Os achados abaixo vêm exclusivamente do cruzamento entre o VTT e o HTML interno da própria equipe, sem um terceiro documento de referência para auditoria cruzada.

Diagrama 1 — Diagnóstico atual: sem event sourcing, sem alerta efetivo

Kafka opera com retenção padrão de 7 dias, mas o consumidor de negócio processa e descarta o evento — nada fica armazenado além do processamento pontual. Não há Dead Letter Queue estruturada hoje: quando o processamento falha, a investigação depende de vasculhar logs verbosos no ELK/Datadog (a própria equipe descreve como "árvore de chamadas aninhadas" difícil de seguir) e, se o problema for do dia corrente, tentar reconstruir a chamada original via log do Sensedia — que retém apenas 1 dia. Passado esse prazo, a chamada original é irrecuperável.

O achado mais relevante da sessão não é apenas a ausência de event sourcing — é a implicação disso sobre a estratégia de correção: quando a equipe corrige um cadastro manualmente direto na base (em vez de reprocessar o evento original), esse "evento fonte" nunca é reconstituído formalmente em lugar nenhum. Se no futuro for implementado um mecanismo de replay, ele reproduziria o mesmo erro original, porque não existe histórico do evento real — só da correção manual aplicada por cima. Isso é uma dívida técnica silenciosa: cada correção manual "resolve" o sintoma sem deixar rastro do evento que a motivou.

Por fim, a equipe relatou não ter alarme efetivo hoje para falhas do lado ADMS — a descoberta de problemas é reativa, via reclamação de usuário ou abertura de sala de guerra, não via monitoramento proativo.

Diagrama 2 — Proposta discutida: event sourcing paralelo (duas pernas)

A proposta discutida ("duas pernas") não altera o fluxo de negócio existente: o consumidor atual continua processando eventos exatamente como hoje. A mudança é aditiva — um segundo consumidor, novo, escuta o mesmo tópico em paralelo e apenas grava o evento bruto, sem transformação, em um object store particionado (por data/hora ou por agregado). Esse Event Store se torna a fonte da verdade para replay: se um bug no consumidor de negócio processar um evento incorretamente, a correção passa a ser reprocessar (replay) o evento armazenado após corrigir o código — não mais uma correção manual direto na base.

Como o Kafka não suporta backup nativo, o Event Store também resolve um segundo problema: replicação incremental (por exemplo, a cada 15 minutos) para um site de contingência, dando à Energisa uma cópia dos eventos fora do cluster Kafka.

Vale registrar uma precondição que a própria equipe levantou: essa proposta fica mais viável se o número de tópicos for reduzido primeiro — hoje são 7 tópicos separados só para eventos de ordem de serviço, o que multiplica o número de consumidores (e portanto o custo) necessários para instrumentar o event store. Isso conecta diretamente com o Diagrama 3.

Diagrama 3 — Racionalização de tópicos Kafka por agregado

Hoje existem 7 tópicos Kafka distintos apenas para eventos de ordem de serviço (criado, despachado, cancelado, encerrado, requisição, agendado, bloqueado). A própria equipe de sustentação identificou dois problemas nisso: custo (Kafka é tratado como recurso "premium", mais caro que outras filas, e cada tópico exige seu próprio consumidor) e falta de garantia de ordem entre os 7 tópicos, já que trafegam em velocidades diferentes — nada impede que um evento de "cancelado" seja processado antes do "criado" correspondente, se vierem de tópicos separados.

A proposta consolida os 7 em um único tópico por agregado, com um envelope de evento padronizado (event_id, event_type, aggregate_type, aggregate_id, correlation_id, schema_version, payload). O ganho estrutural é usar o aggregate_id como chave de partição: todos os eventos da mesma ordem de serviço caem na mesma partição Kafka, garantindo ordem de processamento sem depender de coordenação entre tópicos. Menos tópicos também significa menos consumidores — o que, junto ao Diagrama 2, é apontado como pré-condição de viabilidade econômica para o event sourcing seletivo.

Achados de fidelidade

1. Ausência total de Ata para esta sessão (achado central deste artefato). Não há Ata no Assessment_Consolidado para a reunião de 24/07/2026. A Ata mais próxima cronologicamente (Ata 11, 27/07) cobre uma reunião diferente — outros participantes (Fernando, Gabriel, Éder Xavier, Willians, Nicolas), outro foco (inventário de ferramentas de monitoramento e observabilidade, não as dores operacionais do dia-a-dia de sustentação). Isso significa que os achados listados neste artefato não puderam ser auditados contra um segundo documento independente — dependem exclusivamente da leitura direta do VTT e do cruzamento com o HTML interno. Recomenda-se sinalizar esta lacuna ao time de consolidação de Atas, para que a reunião seja documentada retroativamente ou que se registre explicitamente por que ficou de fora.

2. O arquivo fluxos_adms_sigod.html é o entregável prometido nesta própria reunião, não material de fundo independente. Por volta de 00:17–00:20 do VTT, a equipe menciona compactar um ZIP com "vários HTML" para envio e análise conjunta ("manda um ZIP e a gente abre aqui e dá uma analisada"). O arquivo encontrado na pasta do projeto corresponde a essa promessa: um dashboard interno de ~7.400 linhas, construído pela própria equipe de sustentação da Energisa (não pela consultoria), documentando 50 serviços, ~130 tópicos Kafka únicos, 3 instâncias Sensedia, 9 fluxos (F1–F9) e 4 sistemas integrados — com uma trilha de autoauditoria própria (marcações AUDIT, RESOLVIDO datadas de 30/04, 12/05, 26/05 e 15/07/2026) que referencia arquivos-fonte reais (ex.: OcorrenciaTecnicaTransaction.cs:21-23). Isso eleva a confiabilidade do HTML como fonte — é um documento de engenharia genuíno e já autoauditado, não uma peça de marketing ou rascunho especulativo.

3. Achados técnicos verificados diretamente no VTT (sem Ata para contraste, mas consistentes entre si e com o HTML): ausência de event sourcing (evento descartado após processamento), retenção de log Sensedia de 1 dia vs. retenção Kafka padrão de 7 dias, ausência de DLQ estruturada, carga desigual entre consumidores/partições causando acúmulo de mensagens em algumas réplicas, e a recorrência do problema de carga full (sem endpoint incremental) na integração WFM↔ADMS — já documentado no artefato anterior (Integracao_WFM_ADMS.md) e mencionado novamente nesta sessão como dor persistente da operação.

4. Discussão de governança de ADR (Architecture Decision Record): a equipe discutiu um modelo de dois níveis — ADRs estruturais/vinculantes emitidos por um arquiteto corporativo (analogia usada: "Constituição", que ADRs de solução não podem violar) vs. ADRs específicos de solução emitidos por arquitetos de solução individuais. Este ponto é uma proposta de processo/governança, não uma decisão já tomada — deve ser tratado como tal em qualquer síntese executiva.

Próximo passo

Validar com o time de consolidação de Atas se a reunião de 24/07 foi de fato omitida por lacuna de processo ou se existe um registro em outro formato/local ainda não localizado. Em paralelo, validar com Wagner, Pedro e Lucas se a leitura acima do achado crítico (correção manual sem event sourcing = replay futuro reproduziria o mesmo erro) reflete corretamente a gravidade que a própria equipe atribui ao problema, e se a precondição de reduzir tópicos antes de viabilizar o event sourcing paralelo é consenso ou ainda está em debate.