Diagnóstico Preliminar As-Is — Mapa de Lacunas e Evidências Pendentes

Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa) Versão: v0.2 · rascunho de trabalho (migrado do HTML original para markdown em 03/08/2026; revisado em 04/08/2026 e 05/08/2026 — ver notas de revisão ao final) Data-base: 28/07/2026

O que ainda falta para transformar hipóteses em achados confirmados: sessões não realizadas, evidências solicitadas e não entregues, e valores citados de memória que precisam de confirmação documental. Ver também Matriz de achados e lacunas e Matriz de riscos consolidada.

Critério de severidade desta tabela: crítico = bloqueia diretamente a validação do go-live G1 (01/09) ou é pré-requisito de outra sessão pendente; alto = achado confirmado com impacto operacional relevante, sem bloqueio direto de data; médio = relevante para maturidade do ambiente, sem urgência ligada ao G1. Vocabulário próprio deste mapa — não confundir com a classificação de maturidade de evidência (achado confirmado / hipótese a validar / risco potencial / recomendação preliminar) usada na matriz de achados e lacunas.

Sessões e retornos pendentes (em 28/07/2026)

Nota de leitura: "Situação" registra se a sessão ocorreu, não se o objetivo da linha foi integralmente evidenciado — as duas coisas divergem nas três primeiras linhas (ver detalhamento em cada célula e a nota de revisão ao final).

Sessão	Objetivo	Situação
Infraestrutura e contingência	RTO, RPO, runbooks, replicação, testes de DR e continuidade do barramento (objetivos de recuperação dos eventos).	crítico — sessão realizada em 03/08, ver 010-evidencias/150-dr-sistemas-corporativos.md. Evidência parcial: fonte é rascunho sem Ata cruzada (só VTT); RTO obtido é agregado — 24h para "aplicações críticas" dos sistemas corporativos, não por sistema, como o objetivo pede; RPO não foi levantado; continuidade do barramento (escopo de E1) não foi tema desta sessão. Permanece pendente.
Rede / Telecom	Links, redundância, latência, F5, firewall, VLANs e restrições entre redes OT, DMZ e corporativa. Contribui para validar conectividade da cadeia de captura (encaminhamento da Ata 12).	crítico — sessão realizada em 29/07 (Ata 13). Capacidade, latência e topologia interdatacenter confirmadas. RTO/RPO e modo de replicação do banco corporativo (Data Guard, síncrono/assíncrono) seguem em aberto — a própria Ata 13 (seção 1.14.12, item 6) registra que isso precisa de sessão específica com as equipes responsáveis, ainda a agendar.
Big Data / Databricks	Confirmar formato da camada de entrada, camadas, consumo e prazos; classificar requisitos de ingestão e retirar do barramento cargas inadequadas.	alto — sessão realizada em 31/07 (Ata 14). Objetivo original confirmado, mas a sessão abriu lacunas novas e de severidade maior que o objetivo original (resiliência da integração ambiente-próprio↔nuvem, retenção, idempotência, qualidade de dados) — ver E7.
Fornecedor Schneider	Reunião única e objetiva acumulando as dúvidas sobre upgrades, views, bibliotecas e site switch (decisão da Ata 12).	alto — pendente
Especialista WFM	Volumetria e janelas do motor IQOS e das integrações de equipes; sessão após retorno de férias.	médio — pendente
Retornos de validação	Érica (fluxo de incidentes ponta a ponta), GIS/ADMS (janela de 12 horas e números divergentes), F5/Sensedia (monitores e contratos) e equipe do barramento com desenvolvedores das aplicações consumidoras.	alto — pendente

Evidências a obter, por domínio

E1 · OpenShift e barramento (pontos de validação da Ata 10)

• ~~Versões exatas do OpenShift por ambiente e do operador e componentes Confluent, antes e depois da atualização;~~ confirmado em 29/08/2026, com uma divergência a esclarecer (texto vs. tabela para PRD — ver seção F.1 do artefato de evidências);
• ~~Nodes, cores, memória e pods por componente, e total efetivo de cores licenciados do barramento;~~ confirmado em 29/08/2026 (limits por pod); total efetivo de cores dedicados/licenciados ainda depende de confirmação formal da cifra "~120 cores" da Ata 10 (ver R15);
• Número de clusters Kafka, capacidade provisionada e ocupação real; tópicos, esquemas, produtores e consumidores por domínio;
• Políticas de retenção por tópico e volume diário e mensal de eventos;
• Parâmetros de StorageClass, métricas de entrada e saída e confirmação da hipótese de esquema de paridade;
• Lista das aplicações em rota externa e existência de endpoints fixos em código;
• Ferramentas de backup efetivamente testadas, com registro formal; capacidade real do object storage como Event Store;
• Existência de mecanismo de replicação entre clusters já contemplado no licenciamento Confluent.

Atualização (05/08/2026): análise de relatórios reais de produção e de um diagrama de arquitetura do cliente fechou parcialmente esta evidência — número real de tópicos (930), cobertura de schema por domínio, contagem real de conectores e tasks, e hostnames reais dos 3 clusters (dev/hml/prd) confirmados. Versões exatas de componente Confluent, capacidade provisionada vs. ocupação, e políticas de retenção por tópico continuam pendentes. Ver 030-artefatos/evidencias-producao-confluent-kafka.md.

Atualização (28/08/2026): número de tópicos e cobertura de schema atualizados com extração de 25/08/2026 — 835 tópicos, 82,9% com schema (692/835). Contagem de conectores/tasks não foi recoberta por esta extração (só tópicos/schemas) e continua com o número de 09/07/2026. Queda de 930→835 tópicos e perda de schema em CRM (21%→0%) ainda sem causa confirmada — ver seção A.8 do artefato de evidências.

Atualização (29/08/2026): versões exatas de OpenShift/Confluent por ambiente e recursos dedicados (nodes/pods/CPU/memória/armazenamento) confirmados por resposta formal ao Bloco 2 — ver 030-artefatos/evidencias-producao-confluent-kafka.md, seção F. Duas pendências remanescentes: confirmação formal de que PRD permanece em 7.9.8 (o texto da resposta contradiz a própria tabela) e a leitura correta da duplicação Control Center/Control Center NG. Total efetivo de cores licenciados/dedicados (cifra de "~120 cores" da Ata 10) tem agora indício, não confirmação, de estar superestimada — ver R15/D6.

Atualização (16/08/2026): nova evidência pendente, aberta para validar a proposta de brainstorming 030-artefatos/propostas-barramento-ksqldb/proposta-1-debezium-topic-routing.md (PR #49) — que assume schema homogêneo entre as 9 empresas para o ByLogicalTableRouter funcionar e presume que as queries de consolidação são UNION puro, sem lógica adicional: - Schema Avro mais recente, por empresa, dos tópicos de origem das tabelas candidatas ao piloto (via Schema Registry, GET /subjects/{subject}/versions/latest — não o export completo dos 835 tópicos [25/08/2026, era 930 em 09/07], só o subconjunto multiempresa relevante ao piloto); - ~~Texto completo (não truncado) das 263 queries persistentes do ksqlDB, via SHOW QUERIES EXTENDED;~~ — resolvido em 02/09/2026. A Energisa entregou o texto completo das agora 265 queries (ksqldb_report_20260902_081400.json); confirmou-se WHERE em 32 delas (30 com filtro NOM_TABELA sobre stream compartilhada, 2 com lógica de negócio real) e PARTITION BY em 261 — corrigindo a leitura anterior baseada no relatório truncado, que não via nenhuma das duas. Ver evidencias-producao-confluent-kafka.md, Seção A.11. ~~O schema Avro por empresa das tabelas candidatas ao piloto (outra metade do mesmo pedido, item 18 do Bloco 2)~~ — resolvido em 03/09/2026: o export completo do Schema Registry (1.768 subjects) mostrou schema_id distinto por empresa em DESPACHO_OS/OS_DIGITACAO, o que pareceu indício de divergência — corrigido no mesmo dia ao cruzar com o ddl_completo dos streams do ksqlDB (já recebido em 02/09/2026): as 9 empresas têm exatamente a mesma estrutura de colunas nas duas tabelas. schema_id diferente aqui não significa schema diferente. Ver evidencias-producao-confluent-kafka.md, Seção A.12.

E2 · Cadeia de captura de dados (encaminhamentos da Ata 12)

• Nomes e esquemas das duas tabelas de maior volume e suas configurações no barramento;
• Desenho da arquitetura do XStream elaborado na prova de conceito (a publicar no repositório compartilhado);
• Levantamento dos comandos DDL e versões que interromperam a captura;
• Medição de vazão por etapa da cadeia (captura, transporte, materialização, consumo);
• Inventário de consumidores das bases do ADMS, com finalidade, criticidade e prazo tolerável.

Atualização (05/08/2026): a mesma análise identificou causa raiz arquitetural para o atraso de captura — task única por conector, sem exceção entre os 75 conectores de produção — resposta parcial, não substitui a medição de vazão por etapa ainda pendente. Ver 030-artefatos/evidencias-producao-confluent-kafka.md.

E3 · Observabilidade (confirmações da Ata 11)

• Matriz consolidada de ferramentas com fonte oficial por tipo de ativo, validada pelas equipes;
• Volumetria real do tópico único de telemetria e mapeamento das 151 aplicações emissoras;
• Confirmação da configuração de TLS no trecho do Kafka de telemetria e do estado do mascaramento de dados pessoais;
• ~~Cobertura de instrumentação por unidade e plano de expansão além das três atuais~~ — confirmado em 28/08/2026: licenciamento Datadog já adquirido, expansão segue as ondas de implantação ADMS/OMS por unidade (próxima: Sergipe, fim de agosto/2026). Ver 030-artefatos/monitoramento-observabilidade-adms.md.

E4 · GIS, ADMS e incidentes

• Resolução dos números de performance que divergem entre fontes documentais;
• Confirmação da janela real de sincronização GIS-ADMS e do comportamento com equipamentos recém-instalados;
• Fluxo documentado ponta a ponta de incidentes: geração, agrupamento, retorno ao CRM, fechamento, reabertura e conciliação de eventos tardios;
• Capacidade, backlog e limites de processamento do adaptador ADMS, com posição formal da Schneider sobre o defeito em aberto.

E5 · Infraestrutura e continuidade

• RTO e RPO definidos por sistema e resultados dos testes de DR já realizados;
• Runbooks de chaveamento de site, com papéis, dependências e tempos medidos;
• Topologia de links entre Paraíba e Minas, SLAs contratados e histórico de indisponibilidade;
• Comportamento planejado das integrações do G1 em cenário de degradação da WAN.

E6 · Pendências operacionais da consultoria

• Acesso funcional ao Citrix e ao DevOps testado com Vlad e Castellani;
• Artefatos das reuniões (apresentações, diagramas, gravações) completos no SharePoint;
• Transcrições centralizadas na pasta oficial, organizadas por reunião (Norberto).

E7 · Engenharia de dados e Data Lake (achados da Ata 14, ainda não refletidos nas seções E1–E6)

Domínio novo, aberto na revisão de 04/08/2026. A sessão de Big Data/Databricks (Ata 14, 31/07) foi tratada na tabela de sessões como "realizada", mas revelou lacunas de severidade alta — algumas com prioridade P0 no próprio plano de ação da Ata 14 — que não tinham correspondência em nenhum dos domínios E1–E6 abaixo.

• Topologia exata, failover e SLA do componente de integração entre o ambiente próprio e a nuvem — hoje ponto único de falha da cadeia regulatória e operacional, segundo a própria equipe de dados;
• Política de retenção da área de aterrissagem por criticidade, substituindo a regra uniforme de sete dias — há caso concreto já ocorrido de dado perdido por reprocessamento solicitado fora da janela;
• Mecanismo de reprocessamento, captura incremental de estado e idempotência dos consumidores — ausentes hoje; a mesma lacuna de idempotência já havia sido identificada de forma independente na Ata 09 (consumidores dos eventos de ocorrência técnica);
• Regras mínimas de qualidade de dados (completude, validade, consistência) com quarentena — inexistentes hoje; risco de publicação de dado regulatório semanticamente incorreto sem qualquer bloqueio técnico, em ambiente com penalidade por atraso ou erro;
• Viabilidade técnica e contratual (uso em nuvem) da extração incremental por marcador temporal como alternativa ao upgrade de licenciamento Oracle para replicação de grande volume, estimado em cerca de R$ 6 milhões e considerado inviável para um único projeto;
• Propriedade formal, documentação e sustentação do serviço de gravação em Go, desenvolvido internamente sob pressão de prazo regulatório — mesmo padrão de risco já registrado para a materialização de views do ADMS na Ata 12 (ver E1).

Regra de ouro do diagnóstico

Nenhuma lacuna é resolvida silenciosamente. Valores citados de memória nas sessões permanecem como hipóteses até confirmação por inventário, manifesto ou documento, e divergências entre fontes são levadas às áreas como questões de validação, nunca arbitradas pela consultoria.

Nota da migração (03/08/2026): as linhas de "Situação" acima foram atualizadas para refletir que as sessões de Infraestrutura/DR, Rede/Telecom e Big Data já ocorreram entre a data-base deste documento (28/07) e hoje. Os itens de evidência (E1–E6) não foram revisados a partir dessas novas sessões — isso é trabalho pendente, não uma lacuna do assessment original.

Nota de revisão (04/08/2026): duas correções sobre a nota acima. Primeiro, as três linhas de "Situação" tratadas como resolvidas passaram a distinguir explicitamente "sessão ocorrida" de "objetivo integralmente evidenciado" — nenhuma das três fecha o objetivo original por completo, e a própria Ata 13 registra RTO/RPO e replicação do banco corporativo como pendentes de sessão específica ainda a agendar. Segundo, foi aberta a seção E7 para capturar lacunas novas e críticas reveladas pela Ata 14 que não tinham lugar em nenhum domínio E1–E6 — algumas delas com prioridade P0 no plano de ação da própria Ata. Os itens de E1 a E6 em si ainda não foram revisados achado a achado a partir do conteúdo das três sessões recentes — isso continua como trabalho pendente, agora explicitado por domínio em vez de ficar implícito nesta nota.

Nota de revisão (05/08/2026): E1 e E2 marcadas como parcialmente fechadas a partir da análise de relatórios reais de produção do Confluent e de um diagrama de arquitetura fornecido pelo cliente — ver 030-artefatos/evidencias-producao-confluent-kafka.md. Nenhuma das duas foi fechada integralmente; os itens específicos ainda pendentes estão listados na nota de cada seção. E3–E7 não foram afetadas por esta rodada.

Nota de revisão (28/08/2026): um item de E3 (cobertura de instrumentação por unidade e plano de expansão do Datadog) foi marcado como confirmado, a partir de resposta formal da Energisa ao Bloco 11 do questionário de mitigação de lacunas. Os demais três itens de E3 seguem pendentes. Ver 030-artefatos/monitoramento-observabilidade-adms.md e 080-diagnostico/matriz-riscos-consolidada.md (R20, também atualizado por esta resposta).