Evidências de Produção — Barramento Confluent Kafka e Ambiente Best2Bee¶
Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa
Fonte: Três relatórios técnicos exportados do Confluent Control Center / Kafka Connect em produção, gerados em 09/07/2026 — topicos_detalhado_latest.md, conectores_detalhado_latest.md, ksqldb_prd_latest.md — e um diagrama de arquitetura, ambientes-barramento-integracao-confluent.png, anexos fornecidos diretamente pelo cliente
Status: Rascunho para consolidação — primeira leitura auditável de dados reais de produção do barramento, cruzada com achados já registrados nas Atas 04, 09, 10 e 12
Elaborado por: Syntropy Labs
Por que este artefato existe¶
Até aqui, boa parte dos números sobre o barramento (cores, tópicos, conectores, cobertura de schema) vinha citada de memória em sessão, com hedge explícito de "a confirmar por inventário" (Ata 10, Anexo B). Os quatro anexos analisados aqui são a primeira evidência documental real — extração direta do Confluent Control Center e do Kafka Connect em produção, não relato verbal. Isso permite fechar parte das evidências pendentes [E1] e [E2], quantificar achados que hoje só existiam como observação qualitativa (D5, D9), e levanta achados novos que nenhuma sessão havia registrado.
Regra de leitura: os relatórios e o diagrama já estão versionados neste repositório (ver links acima, commitados em PR separado para não sobrecarregar a revisão deste artefato com ~290KB de dados brutos). Os números abaixo continuam citados a partir da leitura desses arquivos.
A. Achados do inventário real de produção (Kafka Connect + Confluent Control Center)¶
A.1 · Cobertura de Schema Registry por domínio — quantifica R28/D5¶
Visão geral: 732 de 930 tópicos (78,7%) têm schema associado. Mas a distribuição por domínio é desigual, e a lacuna não está espalhada — está concentrada:
| Domínio | Tópicos | Com schema | Sem schema |
|---|---|---|---|
WFM (wfm_*) |
40 | 0 (0%) | 40 (100%) |
CRM (crm_*) |
14 | 3 (21%)* | 11 (79%) |
| CDC Stream / Oracle Stream / JDBC Stream | 22+31+25 | maioria | minoria |
*Os 3 tópicos CRM com schema são derivados internos do ksqlDB (*_pab_key_v1), não os tópicos de origem publicados pela aplicação.
Isso dá número concreto ao achado qualitativo de R28 ("Schema Registry com adoção parcial e divergência de esquemas entre empresas do grupo") e mostra que a exceção não é pontual: é o domínio inteiro de WFM e a quase totalidade de CRM — exatamente os dois domínios que originam o fluxo de atendimento/incidente discutido na Ata 09 (D3).
A.2 · Explosão multiempresa quantificada — reforça achado da Ata 04/topologia-confluent-kafka-multiempresa¶
A categoria "Outros" do relatório de tópicos soma 791 tópicos (85% do total de 930) — quase todos a mesma dúzia de tabelas (ORDEM_SERVICO, EQUIPE, DESPACHO_OS, CLIENTE etc.) replicadas por sufixo de empresa via XStream (com_spr, com_toc, com_ron, com_ser, sgm_mts, sgm_mtn, sgm_ron, sgm_pab, sgm_mgr, sgm_spr, sgm_ser, sgm_toc, sgm_acr, igs_*, sgd_*, itg_crp). Isso torna visível, em escala real, o padrão já discutido na Ata 04 sobre consolidação multiempresa via ksqlDB — e dá um número concreto para a comparação KSQLDB vs. Flink vs. microsserviço vs. pré-consolidação no banco que a própria Ata 04 pede como ação de 30–90 dias.
A.3 · Concentração de captura em task única — achado novo, relevante para R05/D9¶
Os 75 conectores detalhados no relatório (38 JDBC + 34 Debezium/XStream + 3 SQL Server) rodam, sem exceção, com Tasks: 1. O caso mais extremo observado é oracle-source-xst-com-mgr, que captura 47 tabelas por uma única task; há pelo menos 3 outros conectores com 45–47 tabelas na mesma condição.
Isso é evidência de infraestrutura para dois achados já registrados na Ata 12/D9, até agora sem explicação de causa raiz: - "Leitura sequencial por número de mudança faz tabelas analíticas reterem o avanço de tabelas críticas" — se a tabela lenta e a tabela crítica dividem a mesma task de um conector, uma bloqueia a outra por construção, não por acidente. - O atraso de 10–30 minutos em tabelas de alto volume (R05) — task única por conector é um teto arquitetural de paralelismo que limita vazão, independente de tuning.
Recomenda-se levar isso para [E2] como resposta parcial de causa raiz (a medição de vazão por etapa que a evidência pede continua pendente, mas a arquitetura que explica o gargalo já está confirmada).
A.4 · Tópicos com réplica única — achado novo, severidade mista¶
O relatório aponta 16 tópicos com apenas 1 réplica em produção (contra o mínimo de 3 recomendado pela própria nota de boas práticas do relatório). A maioria é de baixa criticidade — derivados ksqlDB (*_pab_key_v1, TB_*_PAB_V1) e tópicos WFM de baixo volume (coordenadas, escalas). Um deles, porém, é _confluent-ksql-barramento-confluent.ksqldb__command_topic — o tópico interno de comando do próprio cluster ksqlDB, que guarda o estado das 263 queries persistentes em produção. Réplica única nesse tópico específico é ponto único de falha para a recuperação de todo o processamento ksqlDB — risco distinto de R02 (que cobre o barramento de eventos de negócio, não a própria plataforma de streaming).
A.5 · Inconsistência no próprio relatório — nota metodológica¶
O resumo executivo do relatório de conectores declara 81 conectores, mas a soma das três categorias detalhadas (JDBC 38 + Debezium 34 + SQL Server 3) fecha em 75, e a soma de tabelas por conector individual bate exatamente com o "543" do resumo. Ou seja, o total de tabelas reconcilia, mas o total de conectores no cabeçalho, não — uma divergência de 6 conectores não explicada pelo detalhamento disponível. Registrar como pendência de esclarecimento antes de citar "81 conectores" em qualquer entregável ao cliente.
A.6 · Saúde operacional — dado novo, sem achado de risco associado¶
74 conectores RUNNING, 1 PAUSED (oracle-source-jdbc-itg-mts.igdems), 0 FAILED. Não constitui achado, mas é linha de base que não existia antes e serve de referência para contrastar com qualquer instabilidade relatada em sessão futura.
A.7 · Arquitetura ksqlDB é 100% stream, sem tables materializadas¶
O relatório ksqlDB mostra 322 streams, 0 tables ("Nenhuma table encontrada"), 263 queries persistentes, todas RUNNING, 98% delas em formato AVRO. É um dado relevante para a decisão pendente ksqlDB→Flink da Ata 04: migrar um pipeline 100% stream (sem estado materializado acumulado) tende a ser tecnicamente mais simples que migrar com state stores — reduz um dos riscos da comparação que a própria Ata pede.
B. Achados do diagrama de arquitetura¶
B.1 · Novo ator não documentado: equipe "Best2Bee"¶
O diagrama identifica explicitamente uma equipe terceirizada — "Equipe Best2Bee que irá atuar na implantação, gestão e suporte na plataforma de Confluent Kafka e Debezium" — com acesso via Citrix (browser, para ELK/Grafana) e via Citrix VDA (máquina de trabalho com VSCode, Git, Postman, CLI OpenShift/Kafka, Azure DevOps). Esse ator não aparece em nenhuma Ata, transcrição ou artefato lido até agora. Recomenda-se confirmar com a Energisa quem é a Best2Bee e desde quando atua — isso é relevante para os achados de propriedade formal já registrados (R21, R41: componentes customizados sem dono formal).
B.2 · Correção candidata: SQL Server aparece rotulado como 2019, não 2022¶
O container na zona "ADMS [DMZ ADMS]" está identificado como [Container: SQL Server 2019]. Isso diverge da hipótese anterior registrada no blueprint de componentes ("2022 (?)", citada de memória pelo consultor, não localizada em nenhuma transcrição revisada). É fonte documental — mais forte que recordação verbal — mas ainda uma fonte única (diagrama sem data de geração nem autoria visível), então trata-se de achado forte a confirmar, não fato fechado. Ação sugerida: atualizar o blueprint de componentes (blueprint-componentes-adms.md, seção C.0) para registrar a divergência entre as duas fontes, em vez de substituir silenciosamente uma hipótese por outra.
B.3 · Azure DevOps é instância própria on-premises, não o serviço SaaS — com versão e topologia exatas¶
"Azure DevOps Server 2020 Update 1.1 (Version: 18.181.31527.1)", rodando em 3 VMs de aplicação (MGDVPSEAPLP1 Tier1/Windows Server 2016, MGDVPSEAPLP2 e MGDVPA2APLP1 Tier2-3/Windows Server 2019) mais uma VM de Search (MGDVPSESCHP1), URLs devops.energisa.com.br e hmgdevops.energisa.corp. Isso substitui a entrada genérica de "Azure DevOps" hoje registrada no blueprint (seção E) — a distinção on-prem vs. SaaS muda a leitura de responsabilidade sobre patch, disponibilidade e atualização de versão.
B.4 · Três clusters OpenShift confirmados por hostname — não dois¶
A lista de URLs do diagrama confirma três ambientes distintos, cada um como cluster OpenShift próprio (não namespace compartilhado):
| Sufixo | Ambiente provável | Evidência |
|---|---|---|
ocpd1 |
DEV | Único com o stack Confluent detalhado no diagrama (Kafka, KSQLdb, Connect, Schema Registry, Control Center, todos em *.apps.ocpd1.energisa.corp) |
ocph1 |
HML | Só rotas genéricas de console/oauth/grafana no diagrama |
ocpp1 |
PRD | Idem; reconciliado com o cabeçalho dos 3 relatórios de produção analisados na Seção A, que declaram URL: https://ksqldb.apps.ocpp1.energisa.corp e Ambiente: PRODUCAO |
Isso é relevante para o achado da Ata 04 sobre "homologação não representativa" (baixa volumetria e dados desatualizados): agora se sabe que HML é fisicamente outro cluster, não apenas outro namespace do mesmo cluster de PRD — o que muda a leitura de por que a paridade de ambiente é difícil de manter.
C. Cruzamento com os payloads de evento fornecidos pelo Castellani¶
Cinco payloads reais de produção foram fornecidos para os tópicos crm_chamada_ocorrencia_tecnica, crm_registra_ocorrencia_sistema_tecnico, crm_retorno_ocorrencia_sistema_tecnico, crm_comunicacao e crm_clientes_afetados_desligamento_emergencial. Todos os cinco batem com o status "Sem Schema" confirmado no inventário da Seção A.1.
Confirma, com payload real, a incerteza registrada na Ata 09. Nenhum dos cinco payloads tem event_id, event_type, correlation_id, causation_id ou schema_version. A correlação entre eventos hoje acontece por reaproveitamento de chave de negócio — Protocolo propagado de crm_chamada_ocorrencia_tecnica para crm_registra_ocorrencia_sistema_tecnico, depois NumComunicacao/NumeroComunicacao propagado até crm_retorno_ocorrencia_sistema_tecnico — e não por um identificador de correlação dedicado. É a confirmação literal, em produção, do que a Ata 09 registrou como incerteza ("não foi possível confirmar se existe identificador único de evento no envelope") e exatamente a lacuna que a recomendação de envelope canônico (Castellani, Ata 09, item 1.10.5.7/1.10.18; ver também 030-artefatos/integracao-sustentacao-adms.md, Diagrama 3) propõe corrigir.
Achado novo, candidato a risco: dado pessoal em texto puro em tópico sem schema. crm_chamada_ocorrencia_tecnica carrega CPF (CpfCnpjAlfanumerico) e celular (CelularSolicitante) sem máscara, num tópico sem contrato formal nem Schema Registry. Os riscos de dados pessoais hoje documentados (R19) cobrem só o pipeline de telemetria/ELK (D10) — este é um vetor diferente (barramento operacional de CRM, D3), sem risco correspondente na matriz atual. Proposta de novo risco:
| # (proposto) | Risco | Domínio | Impacto principal | Origem |
|---|---|---|---|---|
| R42 (proposto) | Dados pessoais (CPF, telefone) trafegando em texto puro em tópicos operacionais de CRM sem Schema Registry nem contrato formal, sem mascaramento nem controle de acesso por schema. | CRM / LGPD (D3) | Exposição de dado pessoal sem trilha de governança; qualquer consumidor do tópico recebe o dado sem filtro. | Achado desta análise, a partir de payload real de crm_chamada_ocorrencia_tecnica |
D. Nota de nomenclatura — Sigode/SIGOD¶
Este artefato não resolve a ambiguidade já registrada em 030-artefatos/fluxos-atendimento-adms.md (seção "Achado de nomenclatura: 'Sigode' vs. MsAttFiltroIncidentes") — os tópicos WFM analisados na Seção A.1 (wfm_ordem_servico_*) são consistentes com a atribuição da wiki técnica (produto SIGOD/WFM como origem), mas isso não fecha a dúvida sobre quem de fato filtra e republica os 7 tópicos por status. Mantido como pendência de confirmação com Izabooh ou Lucas, como já registrado no artefato de origem.
E. Evidências pendentes atualizadas¶
| Item | Situação antes | Situação após esta análise |
|---|---|---|
| [E1] Número de tópicos, esquemas, produtores/consumidores por domínio | Pendente, números citados de memória | Parcialmente fechado — 930 tópicos, 4.401 partições, cobertura de schema por domínio quantificada (Seção A.1) |
| [E1] Versões exatas do OpenShift/Confluent por ambiente | Pendente | Parcialmente fechado — hostnames reais confirmados para os 3 clusters (Seção B.4); versões de componente Confluent ainda não confirmadas |
| [E2] Medição de vazão por etapa da cadeia de captura | Pendente | Não fechado, mas causa raiz arquitetural identificada (Seção A.3 — task única por conector) |
| [E2] Inventário de consumidores das bases do ADMS | Pendente | Não avançado por este anexo |
Próximo passo¶
- Confirmar com a Energisa a identidade e o escopo de atuação da equipe Best2Bee (B.1) e a divergência de versão do SQL Server 2019 vs. 2022 (B.2), antes de atualizar o blueprint de componentes.
- Levar a proposta de risco R42 (dados pessoais em
crm_chamada_ocorrencia_tecnica) à próxima rodada de validação da matriz de riscos consolidada, junto com as propostas de elevação de R20/R22 já pendentes. - ~~Versionar os 3 relatórios brutos e o diagrama~~ — feito, ver links na seção "Fonte" acima (
010-evidencias/relatorios-producao-confluent/e050-drawio/ambientes-barramento-integracao-confluent.png). - Esclarecer a divergência de contagem de conectores no relatório (81 vs. 75, Seção A.5) com quem gerou o relatório antes de citar o número "81" em qualquer entregável ao cliente.
- Consolidar os achados A.1–A.7 e B.1–B.4 na próxima Ata de Kafka/OpenShift ou como addendum à Ata 10, seguindo o mesmo padrão já usado para a sessão de 24/07 (ver
030-artefatos/fluxos-atendimento-adms.md).