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 IQS 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;
Nodes, cores, memória e pods por componente, e total efetivo de cores licenciados do barramento;
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.

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.

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.