HLD As-Is — Barramento Confluent Kafka

Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa) Fonte: Síntese de quatro artefatos já publicados — topologia-confluent-kafka-multiempresa.md (Ata 04), topologia-rede-kafka-openshift.md (Ata 10), evidencias-producao-confluent-kafka.md (evidência real de produção) e devops-pipeline-confluent-kafka.md (sessão de DevOps, 06/08) — mais a matriz de riscos consolidada e a matriz de achados e lacunas Status: Rascunho para validação — HLD As-Is (arquitetura atual), não To-Be Elaborado por: Consultoria Syntropy

Nota de leitura

HLD As-Is — documenta a arquitetura do Barramento como ela é hoje, não o desenho To-Be. Parte dos achados citados aqui (R31 em diante, incluindo R42, R43 e R44) ainda não passou pela validação de Fase 3 com Norberto e Rômulo — onde um achado é "hipótese a validar" ou está fora da consolidação v1.10, o texto sinaliza isso explicitamente; caso contrário, é tratado como confirmado. Ver também o HLD do ADMS e o diagrama de contexto do ecossistema.

Por que este documento existe

O levantamento (Fase 1 do assessment) está perto do fechamento — falta apenas o retorno com o WFM. Antes de avançar para o To-Be (Fase 4), faz sentido consolidar num único documento de arquitetura tudo que já se sabe sobre o Barramento, hoje espalhado em quatro artefatos e duas matrizes. Esse é o objetivo deste HLD: ser o ponto de entrada único para "como o Barramento funciona hoje", com links para o detalhe em cada artefato de origem — não substituí-los.

Diagrama 1 — Visão consolidada: componentes, donos organizacionais e principais gaps

Este diagrama consolida numa única visão o que os quatro artefatos de origem documentam separadamente: a fronteira de responsabilidade entre Infraestrutura, a equipe de Kafka/Confluent (hoje reforçada pela terceirizada Best2Bee — achado B.1 de evidencias-producao-confluent-kafka.md, ainda pendente de confirmação formal com a Energisa sobre escopo e desde quando atua), DevOps, F5/Gateway e Desenvolvimento. Os números anotados em cada componente vêm da evidência real de produção (evidencias-producao-confluent-kafka.md), não de estimativa verbal — a maior mudança de precisão deste HLD em relação aos artefatos anteriores é substituir a estimativa de "~1000 estruturas ksqlDB" por 587 confirmadas em 02/09/2026 (322 streams + 265 queries; eram 585/263 em 09/07/2026).

Fora do diagrama, deliberadamente: o ELK. O ambiente ELK (telemetria/logs) não aparece como consumidor deste Kafka. A Ata 11 (monitoramento-observabilidade-adms.md, Diagrama 1) registra que o ELK é alimentado por um cluster Apache Kafka dedicado à telemetria — confirmado por Castellani em 08/08/2026 — explicitamente diferente do Confluent Kafka que é o Barramento corporativo documentado neste HLD. Não são "o mesmo Kafka com rótulos diferentes": são dois clusters distintos, plataformas diferentes (Apache Kafka puro vs. Confluent Platform), propósitos, donos e ciclos de vida diferentes. O que este Barramento manda para Grafana/Prometheus/Datadog são as próprias métricas operacionais do cluster (brokers, Connect), não telemetria de aplicação.

Inventário de componentes

Componente	Réplicas/pods	Ambiente confirmado	Observação
Kafka brokers	3	PRD (ocpp1)	~2,5TB cada, ocupação parcial
KRaft controllers	3	PRD	Sem ZooKeeper
Schema Registry	2	PRD	82,9% de cobertura de schema nos tópicos (25/08/2026; era 78,7% em 09/07)
ksqlDB	3	PRD	322 streams, 265 queries, 0 tables — 100% stream, sem estado materializado (02/09/2026)
Kafka Connect	5	PRD	75 conectores (38 JDBC, 34 Debezium/XStream, 3 SQL Server); split em teste (3 operacional + 2 BI) — número de 09/07/2026, não recoberto pela extração de 25/08
Control Center	1	PRD	Console de operação; único ponto de criação manual de objetos ksqlDB

Três clusters OpenShift físicos, não namespaces do mesmo cluster (achado B.4 de evidencias-producao-confluent-kafka.md): ocpd1 (DEV, único com o stack Confluent completo detalhado), ocph1 (HML, só rotas genéricas) e ocpp1 (PRD, confirmado pelos três relatórios de produção analisados). Isso é relevante para o achado de "homologação não representativa" já registrado em D5/D9 — HML é fisicamente outro cluster, não apenas outro namespace do de PRD.

Segregação física por Machine Config Pool: os componentes do Barramento (KRaft, brokers, Connect, ksqlDB) rodam em nodes dedicados, separados do pool geral de ~26 nodes/~3000–3200 pods do restante do ambiente OpenShift — decisão de contenção de blast radius já tomada pela própria equipe de infraestrutura (ver Diagrama 2 de topologia-rede-kafka-openshift.md).

Fluxo de dados: CDC multiempresa e consolidação via ksqlDB

Detalhado com diagramas de sequência em topologia-confluent-kafka-multiempresa.md (Diagramas 2 e 3). Resumo com números reais confirmados:

• Nove bancos Oracle (um por empresa do grupo) mais SQL Server (DMS, em maturação) alimentam o CDC via XStream.
• CDC operacional e CDC de BI/Data Lake compartilham hoje o mesmo pool de Kafka Connect — separação em 3 pods operacional + 2 pods BI está em POC, não em produção.
• O fan-out regional XStream (mesma dúzia de tabelas replicadas por sufixo de empresa) soma 587 dos 835 tópicos totais em produção (~70%, extração de 25/08/2026 — era 621 de 930, ~67%, em 09/07) (achado A.2/A.8 de evidencias-producao-confluent-kafka.md).
• ksqlDB consolida os tópicos por empresa em tópicos unificados via streams/queries UNION — 587 estruturas reais em produção em 02/09/2026 (não ~1000, como estimado de memória na sessão original; eram 585 em 09/07/2026).
• Os 75 conectores de captura rodam, sem exceção, com uma única task (Tasks: 1) — teto arquitetural de paralelismo que explica, com evidência de infraestrutura, os atrasos de captura já registrados em D9 (achado A.3).

Diagrama 2 — Sequência por time: pipeline de CI/CD e a exceção do ksqlDB (R44)

Nenhum artefato deste assessment tinha, até esta revisão, uma visão do pipeline agrupada por responsabilidade organizacional — os Diagramas 1 e 2 de devops-pipeline-confluent-kafka.md (referenciados, não duplicados abaixo) mostram os mesmos passos em colunas por participante, sem agrupar por time. Este diagrama é novo porque combina os dois fluxos daquele artefato (pipeline padrão + exceção do ksqlDB) numa única visão, agrupando os participantes nas mesmas fronteiras organizacionais já desenhadas no Diagrama 1 deste HLD (Infraestrutura, DevOps, Kafka/Confluent + Best2Bee), mais duas raias que aquele diagrama consolidado não precisava mostrar por não serem componentes técnicos do Barramento: Desenvolvimento (quem inicia o fluxo) e Gestão de Mudanças (órgão de governança corporativa, não uma equipe operacional do Barramento). O objetivo é deixar visualmente explícito o achado R44: o caminho do ksqlDB não atravessa nenhuma das raias de aprovação (Infra, Gestão de Mudanças) que o restante do Barramento atravessa.

Pipeline de CI/CD e governança de mudança

Detalhado em devops-pipeline-confluent-kafka.md (Diagramas 1 e 2, sem agrupamento por time — ver Diagrama 2 acima para a visão por raia organizacional). Resumo:

• Publicação via Azure DevOps Server 2020 on-premises (não o SaaS), trunk-based por ambiente, um pipeline por componente do Barramento.
• Governança em duas camadas: aprovação de Pull Request (Infra revisa código) separada da aprovação de execução em produção (Gestão de Mudanças) — builds têm janela de expiração até serem aprovadas.
• Scanning de segurança a cada versão: SAST (SonarQube, on-prem), SCA (JFrog X-Ray, on-prem), DAST (Qualys WAS, SaaS, só para aplicações web/API).
• Gap confirmado (R44): ksqlDB é o único componente cuja infraestrutura é provisionada via pipeline, mas cuja criação de streams/queries é manual, direto no Control Center — sem PR, sem aprovação de Gestão de Mudanças, sem versionamento. Confirmado em 08/08/2026 que o gap persiste na versão da Confluent atualmente em uso pela Energisa.
• Instalação de operators no OpenShift também é manual, por decisão deliberada de segurança — frente de IaC (Terraform) em andamento para cobrir esse e outros passos hoje manuais.
• DevOps do domínio de dados (EDP) é uma esteira totalmente separada (instância própria de Azure DevOps, Databricks/Data Factory, GitFlow) — fora do escopo deste HLD.

Observabilidade e segurança

• Métricas operacionais do próprio cluster (brokers, Connect) via Grafana e Prometheus nativos do OpenShift; Datadog também em uso, com instrumentação do Kafka em homologação segundo a Ata 11.
• ELK não faz parte deste HLD. É alimentado por um cluster Apache Kafka dedicado à telemetria, distinto do Confluent Kafka que é o Barramento aqui documentado (achado da Ata 11, confirmado por Castellani em 08/08/2026 — ver monitoramento-observabilidade-adms.md). Esse Kafka de telemetria, seu storage compartilhado e o risco de propagação de incidentes (D10) pertencem ao domínio de Observabilidade, não ao Barramento — tratado no artefato de origem, não repetido aqui.
• Autenticação via LDAP corporativo — historicamente instável com busca genérica; mitigado declarando três servidores nomeados antes do fallback (achado já registrado na sessão de Ata 04/D5).
• Payloads reais de produção nos tópicos de CRM (crm_chamada_ocorrencia_tecnica e correlatos) não têm event_id, correlation_id nem schema_version — correlação hoje acontece por reaproveitamento de chave de negócio (Protocolo, NumComunicacao), não por identificador dedicado (achado de evidencias-producao-confluent-kafka.md, seção C).
• Mesmo payload real confirma dado pessoal (CPF, celular) em texto puro, sem máscara, em tópico sem Schema Registry — proposto como R42 na matriz de riscos.

Riscos e achados conhecidos (Barramento e OpenShift/plataforma)

#	Sev.	Risco	Domínio	Status de validação
R02	crítico	Ausência de estratégia de backup, replay e DR do barramento de eventos	Barramento (D5)	Base v1.10 — validação pendente na Fase 3
R07	crítico	Tráfego interno ao cluster trafegando por rota externa (F5, firewall, API Gateway)	OpenShift / Rede (D6)	Base v1.10 — confirmado ao vivo na sessão de origem
R13	alto	Governança de eventos ausente: tópicos duplicados e eventos equivalentes	Barramento (D5)	Confirmado ao vivo em 12/08/2026 — ver integracao-wfm-eforce-ordem-servico.md
R14	alto	Consumidores frágeis pós-reinício, intervenção manual	Aplicações (D5)	Confirmado ao vivo em 12/08/2026 — DLQ ausente, classificado pelo dev responsável como "problema crítico de infraestrutura"; ver integracao-wfm-eforce-ordem-servico.md
R15	alto	Capacidade e licenciamento do barramento (~120 cores, não confirmado por inventário)	OpenShift / Custo (D6)	Base v1.10 — hipótese a validar
R27	médio	Ciclo de versões do OpenShift/operador Confluent defasado	Plataforma (D6)	Base v1.10 — atualização em curso pela Energisa
R28	médio	Schema Registry parcial e divergência de esquemas entre empresas	Barramento (D5)	Base v1.10 — quantificado com evidência real (82,9%/0%/0%, 25/08/2026 — CRM caiu de 21% para 0%, causa não confirmada, ver evidencias-producao-confluent-kafka.md A.8)
R42 (proposto)	alto	PII em texto puro em tópico CRM sem Schema Registry	CRM / LGPD (D3)	Fora da consolidação v1.10 — evidência de produção, 05/08
R44 (proposto)	médio	ksqlDB fora do pipeline automatizado de CI/CD	DevOps / Barramento (D5, D6)	Fora da consolidação v1.10 — confirmado por Castellani, 08/08

Ver a lista completa, com todas as severidades e origens, na matriz de riscos consolidada (domínios D5 e D6) e na matriz de achados e lacunas (seções D5 e D6).

Lacunas e pendências de evidência

• Equipe Best2Bee (terceirizada de implantação/gestão/suporte do Confluent/Debezium): identificada só no diagrama de arquitetura fornecido pelo cliente, sem registro em nenhuma Ata, transcrição ou artefato até 05/08/2026. Confirmar escopo e desde quando atua.
• Versão do SQL Server no ambiente ADMS: diagrama do cliente indica 2019; blueprint de componentes registrava "2022 (?)" de memória. Divergência a confirmar, não resolvida silenciosamente.
• Contagem de conectores: resumo executivo do relatório de produção declara 81 conectores; soma do detalhamento fecha em 75. Divergência de 6, sem explicação disponível — não citar "81" em entregável ao cliente antes de esclarecer. A extração de 25/08/2026 (tópicos/schemas) não cobre conectores — pendência segue aberta, precisa de uma extração de conectores nova.
• Queda de 930 para 835 tópicos e perda de schema em CRM (21%→0%): confirmado por comparação entre as extrações de 09/07 e 25/08/2026 (evidencias-producao-confluent-kafka.md, seção A.8), mas sem causa confirmada — pode ser decomissionamento real ou diferença de escopo entre as duas rodadas. Confirmar com a equipe de barramento antes de tratar como fato fechado.
• Versões exatas de componente Confluent por ambiente ainda não confirmadas (só hostnames e topologia física dos 3 clusters).
• Retorno pendente com a equipe do barramento Kafka/Confluent e aplicações consumidoras, decorrente da Ata 10 (item 04 da Fase 1 do plano de trabalho) — inventário de URLs por workload (rota vs. Service), configuração de cliente Kafka, métricas de latência/erro de conexão. Esse é o retorno que mais afeta diretamente este HLD, não o retorno do WFM.

Próximo passo

Este HLD é insumo para a Fase 4 (To-Be) do assessment, não o desenho To-Be em si. Antes de qualquer proposta de arquitetura alvo para o Barramento, o plano de trabalho prevê a validação do diagnóstico com Norberto e Rômulo, seguida da rodada técnica com as áreas — que ainda não ocorreu para a maior parte dos achados citados aqui (R31 em diante). Recomenda-se tratar este documento como a base a apresentar nessa validação, e não pular direto para uma proposta de arquitetura alvo do Barramento antes dela.