Pular para conteúdo

Diagnóstico Preliminar As-Is — Síntese Executiva

Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa) Versão: v0.1 · rascunho de trabalho (migrado de portal-adms-v4.html para markdown em 06/08/2026) Data-base: 03/08/2026

O ambiente é funcional e sustenta a operação diária do grupo. Ele cresceu resolvendo problemas reais sob prazos de implantação exigentes, e um crescimento assim deixa, naturalmente, uma agenda de consolidação: os componentes funcionam bem individualmente, e as conexões entre eles, muitas construídas sob medida, ganham agora a oportunidade de receber donos formais, acordos de nível de serviço, observabilidade de ponta a ponta e automação do que hoje depende de operação manual. As ferramentas escolhidas são adequadas; o que o diagnóstico prioriza é maturidade de arquitetura e governança: o desenho de rede, a continuidade do barramento e da captura de dados, os contratos entre produtores e consumidores e a tradução do termo "tempo real" em requisitos mensuráveis.

De onde vem cada afirmação

Afirmação Evidências
Ambiente funcional que sustenta a operação Operação diária das nove distribuidoras sobre o barramento; G3 em produção; site switch do ADMS testado com regularidade e avaliado como prática tranquila (Ata 13, artefato de DR).
Crescimento por decisões locais sob prazo de implantação O próprio diagnóstico registra que várias soluções customizadas resolveram problemas reais sob prazo de implantação (síntese, Postura e atribuições). Exemplos: materialização de views para viabilizar o CDC (Ata 12), carga full do WFM (Ata 08), rotas externas para tráfego interno (Ata 10).
Soluções customizadas sem propriedade formal R21, procedimentos da cadeia de captura sem responsável formal (Ata 12); R18, telemetria de 151 aplicações num único tópico sem dono (Ata 11); R13, tópicos duplicados sem governança (Ata 10); VIPs sem padrão de nomenclatura (D7, Ata 05). Consolidado na CV5.
Acordos de nível de serviço por definir R23, consumidores de dados sem acordo de nível de serviço (Ata 12); R21; D9, intervalos de 5 e 10 minutos definidos pela duração dos jobs, não por requisito de negócio (Ata 12).
Observabilidade ainda não ponta a ponta R16, tecnologia operacional sem observabilidade e APM em três das nove unidades (Ata 11); mosaico de ferramentas sem correlação entre domínios (D10); lacuna de linhagem de transformação de eventos (artefato de monitoramento); Sustentação sem alarme efetivo, descoberta reativa de falhas (artefato de sustentação).
Operação manual em pontos críticos CV3 consolidando: chaveamento do F5 por change multiequipe (R11, Ata 05); reinício manual de pods consumidores (R14, Atas 04 e 10); recuperação manual da captura (Ata 12); resposta a incidentes predominantemente manual (R29, Ata 11).
Desenho de rede R07, tráfego interno ao cluster saindo por F5, firewall e API Gateway antes de voltar (Ata 10, apontado como maior retorno imediato); assimetria do G1, cada evento atravessa 3000 km como operação normal (Atas 01, 03, 05 e 13).
Continuidade do barramento e da captura R02, ausência de backup, replay e recuperação de desastre dos eventos (Ata 10); R03 e CV1, failover incompleto da cadeia de dados (Atas 05 e 12); chaveamento integral do ambiente corporativo nunca exercitado de ponta a ponta (artefato de DR).
Contratos entre produtores e consumidores R12, APIs sem testes de contrato (Ata 05); R28, Schema Registry parcial e esquemas divergentes entre empresas (Atas 04 e 09); R08, dual write sem Outbox e sem correlation ID (Ata 09); R04 e R22, mudanças de esquema do fornecedor sem comunicação (Ata 12).
Requisitos de tempo ainda não formalizados CV4 (conversa de 11/07, Atas 11 e 12); R30, custo de Databricks e streaming direcionado sem acordo de nível de serviço de negócio comprovado; D9, achado confirmado de intervalos sem requisito formalizado.

Leitura original do diagnóstico (íntegra, sem edição)

Leitura de conjunto. O ambiente é funcional e sustenta a operação, mas cresceu por acúmulo de decisões locais tomadas sob pressão de implantação. O padrão se repete em camadas diferentes: componentes que funcionam individualmente, conectados por soluções customizadas sem propriedade formal, sem SLA definido, sem observabilidade ponta a ponta e com dependência relevante de intervenção manual. Os problemas mais graves não são de ferramenta, e sim de arquitetura e governança: desenho de rede, continuidade do barramento e da captura de dados, contratos entre produtores e consumidores, e ausência de requisitos formalizados por trás dos termos "tempo real".

Em números

  • 16 — Sessões de levantamento realizadas e documentadas.
  • 18 — Artefatos técnicos de arquitetura, com 43 diagramas.
  • 11 — Domínios cobertos na matriz de achados e lacunas.
  • 7 — Riscos críticos, de 30 consolidados: o topo da agenda de priorização antes do go-live do G1.
  • 42 — Achados classificados, cada um com recomendação preliminar de melhoria correspondente.
  • 5 — Convergências transversais: programas que destravam melhorias em várias áreas de uma vez.

O que o programa já construiu

Antes dos riscos e das lacunas, o registro do que o levantamento encontrou funcionando. Cada item cita a sessão que o sustenta.

Operação sustentada em nove distribuidoras O ambiente de integração em produção sustenta a operação diária do grupo: barramento corporativo multiempresa, fluxos de atendimento, manutenção, campo e dados regulatórios funcionando de ponta a ponta. É a primeira frase da própria síntese executiva: o ambiente é funcional e sustenta a operação. Origem: Síntese executiva · Atas 01 a 12

G3 em produção e fornecedores consolidados O agrupamento G3 opera integralmente em Minas Gerais e o SCADA do G1 já está implantado, com o OMS agendado para 01/09 e 01/10. A plataforma integrada substitui seis fornecedores de SCADA e OMS por um único. Origem: Atas 03 e 13

Continuidade do ADMS exercitada na prática O ADMS opera ativo-ativo entre Minas Gerais e Paraíba, com manobras periódicas de site switch que desativam a instância de uma distribuidora e a operam do outro site. A própria equipe avalia a prática como tranquila. Origem: Ata 13 · artefato de DR

Revisão de arquitetura reduziu o custo do programa A revisão do modelo de arquitetura levou o custo do projeto ADMS de R$ 190 milhões para R$ 122 milhões, e o investimento de hardware de R$ 50 milhões para R$ 31 milhões. Origem: Ata 03

Rede interdatacenter dimensionada e em evolução A sessão de rede descartou a hipótese de gargalo nas integrações: capacidade dos enlaces suficiente, terceiro enlace em implantação e projeto de interconexão dedicada entre os datacenters contratado, com migrações previstas até março de 2027. Origem: Ata 13

Governança de TI e estratégia alinhadas O framework de doze domínios funcionais e a organização por VPT formam uma estrutura de governança madura, e a modernização via ADMS materializa a estratégia 4Ds declarada ao mercado. O programa não é uma iniciativa isolada de TI. Origem: Ata 02 · Business Model Canvas

Melhoria contínua que já está em curso A reestruturação do ELK, a atualização do operador Confluent, a homologação da instrumentação do Kafka no Datadog e os seis relatórios essenciais do COp são iniciativas da própria equipe da Energisa, anteriores a este diagnóstico. Os pontos de maior retorno identificados na Ata 10 também já têm dono e prioridade em plano de ação P0 e P1. As recomendações deste assessment somam-se a esse movimento, não o inauguram. Origem: Síntese executiva · Atas 10 e 11

Os dois eixos críticos frente ao go-live G1 (01/09)

Continuidade: nem o barramento de eventos nem a cadeia de captura de dados possuem hoje estratégia de recuperação que acompanhe uma troca de site — a replicação para os consumidores corporativos considera apenas o ambiente primário, e não existe backup ou replay consolidado dos eventos. Topologia: o G1 opera com ADMS ativo na Paraíba e sistemas corporativos em Minas, uma dependência WAN de produção sem precedente nas implantações anteriores, cuja resiliência ainda não foi evidenciada por testes.

Decisões e o contexto em que foram tomadas

Parte relevante do que o diagnóstico aponta nasceu de decisões que fizeram sentido sob as restrições da época: prazo de implantação, custo e a oportunidade que se apresentava. Reconhecer esse contexto muda a natureza da recomendação: institucionalizar e evoluir o que provou valor, em vez de refazer.

Materialização de views para viabilizar a captura de dados (Ata 12) As views do fornecedor invocam bibliotecas do produto e buscam informação em memória. A camada de materialização construída pela equipe foi o que tornou a captura de dados possível, no prazo, sem depender de evolução do produto. A oportunidade agora é dar à solução que provou valor a sustentação institucional que faltou: propriedade formal, ciclo de vida e um contrato de dados com o fornecedor.

Conector de captura no OpenShift corporativo (Ata 13) Hospedar o conector junto ao Kafka corporativo foi decisão consciente: a observabilidade e a operação estão centralizadas ali, e o ambiente operacional não possui orquestrador de contêineres. A coordenação já avaliou a alternativa de aproximá-lo do banco e definiu o encaminhamento certo: decidir com as evidências de homologação do primeiro OMS, dados reais em vez de hipótese.

Carga full de equipes no WFM (Ata 08) O modelo de carga completa é simples de operar e atendeu o volume da época da implantação. Foi o crescimento que passou a expor timeouts e janelas críticas. A evolução para integração incremental por API, em estratégia híbrida, já foi discutida com critérios na própria sessão.

Topologia do G1 com ADMS ativo na Paraíba (Atas 01, 03, 05 e 13) Usar o datacenter da Paraíba como sítio ativo do G1 deu ao programa redundância geográfica real e viabilizou o cronograma de go-lives. A contrapartida, a dependência de rede de longa distância em produção, é conhecida e mensurada em 60 a 70 milissegundos. O que falta não é refazer a decisão, é evidenciar por testes o comportamento sob degradação antes de 01/09.

Soluções customizadas sob prazo de implantação (Síntese executiva · Ata 12) O próprio diagnóstico registra que várias soluções customizadas resolveram problemas reais sob prazo de implantação. O padrão a corrigir não é a existência delas, é a ausência de dono formal, acordo de nível de serviço e ciclo de vida. Institucionalizar o que provou valor é caminho mais curto do que substituir.

Plataforma de logs anterior ao OpenShift (Ata 11) O ELK serviu o grupo antes da era do cluster e cresceu junto com a demanda; o consumo e o storage compartilhado são consequência desse crescimento, não de um erro de desenho. A reestruturação em curso pela própria equipe é a correção natural, e a recomendação do assessment é dimensioná-la com storage dedicado e planejamento de capacidade.

Convergências transversais

Cinco padrões atravessam sessões diferentes e devem ser tratados como problemas únicos, não como itens isolados por área:

Postura e atribuições O diagnóstico registra decisões históricas com respeito ao contexto em que foram tomadas: várias soluções customizadas resolveram problemas reais sob prazo de implantação. As dores relatadas pelas equipes internas constam como achados por decisão conjunta registrada na Ata 12. Iniciativas em curso da própria Energisa (reestruturação do ELK, atualização do operador Confluent, homologação da instrumentação do Kafka no Datadog, seis relatórios essenciais do COp) são da equipe do Norberto e estão indicadas como tal.

CV1 · Failover incompleto da cadeia de dados O failover via F5 resolve o redirecionamento de endpoint, mas não a continuidade do job de captura, a integridade de LSN e offsets, nem o reapontamento da replicação para o site secundário. Atas 05 e 12.

CV2 · Cargas massivas sem classe de serviço Carga full de equipes no WFM, tabelas de alta volumetria retendo a fila do CDC e cargas de BI encaminhadas ao barramento: o mesmo padrão de volume sem segregação por criticidade. Atas 08, 10 e 12.

CV3 · Dependência de intervenção manual Chaveamento do F5 por change multiequipe, reinício manual de pods consumidores e recuperação manual da captura: a contingência depende de pessoas, não de automação. Atas 05, 10 e 12.

CV4 · "Tempo real" sem requisito formalizado Intervalos de 5 e 10 minutos definidos pela duração dos jobs e não por necessidade de negócio; dashboards chamados de real-time sem SLA de processo. Conversa 11/07, Atas 11 e 12.

CV5 · Governança e propriedade formal ausentes VIPs sem padrão, tópicos duplicados, telemetria de 151 aplicações em um único tópico e procedimentos customizados sem responsável: ativos críticos sem dono identificável. Atas 05, 10, 11 e 12.

Ver também