Topologia de Rede e Continuidade — Kafka/Confluent no OpenShift

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 20/07/2026 (54min, pasta Reuniao-Openshift) e Ata 10 já consolidada no Assessment (item 1.11, incorporada em 24/07/2026) Status: Rascunho para consolidação — a Ata 10 já existe e é tecnicamente sólida; este artefato traduz os achados dela em diagramas C4/sequência e registra uma ressalva de fidelidade encontrada na auditoria Elaborado por: Syntropy Labs

Por que este artefato existe

A sessão de 20/07 já foi transformada em Ata 10, e essa ata é, até aqui, a mais cuidadosa do projeto: normaliza corretamente ambiguidades do reconhecimento automático de voz (ex.: "rede 6" → hipótese RAID 6, "mini IO" → MinIO), e tem uma seção inteira (Anexo B) dedicada a marcar números e nomes citados de memória como pendentes de confirmação — um padrão que as Atas 02 e 03 não tinham. Este artefato não recria a ata; visualiza os três achados centrais dela em C4/sequência para uso direto no Capítulo 4 (Infraestrutura) e no Capítulo 6 (Recomendações), e registra a única inconsistência de fidelidade que a auditoria encontrou.

Diagrama 1 — Comunicação interna por rota externa (achado central da sessão)

Este é o achado de maior retorno da sessão, segundo a própria Ata 10 ("é a correção de maior retorno imediato e menor ambiguidade técnica"). O ponto notável, e que a ata capta bem, é que o problema não está nos produtores — só nos consumidores, que buscam o Kafka pela rota publicada em vez do Service interno. Isso foi demonstrado ao vivo na própria sessão, não é hipótese: Carlos André encontrou, inspecionando o cluster, uma API de atendimento configurada por variável de ambiente apontando para outra API via rota, e o Schema Registry no mesmo padrão.

Diagrama 2 — Topologia Kafka/Confluent e segregação por Machine Config Pool

A segregação por Machine Config Pool (nodes dedicados para Kafka, KRaft, Connect e ksqlDB, separados do pool geral de ~26 nodes) é uma decisão correta de contenção de blast radius — a própria Ata 10 registra isso como um dos poucos pontos em que a equipe de infraestrutura já tomou a decisão certa por conta própria, mesmo sem estar sob o mesmo governo de decisão do assessment.

Diagrama 3 — De "sem estratégia de continuidade" para Event Store

Este é, segundo a própria Ata 10, "o risco de maior severidade identificado na sessão e o único cuja materialização não admite mitigação posterior": não existe hoje backup nem recuperação de desastre efetiva do barramento. A equipe já esgotou a linha de investigação errada (backup convencional de volume, testado com 3 ferramentas e descartado com validação de um arquiteto Red Hat) e reagiu bem à proposta de Event Store como saída paralela — o ponto em aberto é que isso ainda não está implementado.

Achado de fidelidade: afirmação sem lastro na transcrição

Auditando a Ata 10 contra a transcrição integral, encontrei uma única inconsistência real, mas que vale registrar porque contrasta com o cuidado do resto do documento. A ata afirma como fato assentado: "Norberto da Silva Prado, responsável por articular o encontro, não participou em razão de atraso de voo." Essa informação não aparece em nenhum lugar da transcrição — o único indício correlato é Vladimir dizendo, na abertura, "acho que o Norberto ele deu uma palhinha", que se refere a um contexto prévio repassado por Norberto à equipe convidada, não à razão de sua ausência.

A própria Ata 10 declara ter sido consolidada a partir de duas fontes — "o relatório técnico detalhado produzido sobre a reunião e a transcrição integral da gravação" — então o dado do atraso de voo pode legitimamente vir do relatório técnico, ao qual não tenho acesso direto. O ponto de auditoria não é que a informação seja necessariamente falsa, é que ela é a única afirmação factual do documento sem nenhum hedge ("a confirmar", "citado de memória", etc.), apesar de não ter lastro na fonte primária disponível — um padrão que o resto do documento evita sistematicamente (veja o cuidado equivalente em relação à versão do CFK, à ferramenta de backup não identificada, ou ao nome "Sigode 2.0"). Recomendo confirmar a origem dessa frase com quem produziu o relatório técnico antes de tratá-la como fato consolidado em versões futuras do Assessment.

Achado de convergência: reforça o padrão dos "7 tópicos por status"

A Ata 10 registra, no item 1.11.12.1 ("Convergência com a Ata 09"), que o padrão de fragmentação de eventos discutido nesta sessão — uma entidade com sete tópicos, um por status, quando um tópico único com tipo de evento bastaria — é o mesmo achado already levantado nas sessões de 15 e 16/07 com atendimento (Ata 09, item 1.10.5). Isso é relevante para este projeto porque o artefato Fluxos de Integração ADMS-Atendimento já havia documentado esse exato padrão a partir da wiki técnica (MsAttFiltroIncidentes consumindo 7 tópicos wfm_ordem_servico_*). Agora são três fontes independentes — Ata 09, wiki técnica, e esta sessão de infraestrutura — convergindo no mesmo achado por caminhos completamente diferentes (modelagem funcional, documentação técnica, e consumo de infraestrutura). Isso eleva a fragmentação de tópicos de "observação pontual" a achado estrutural do assessment, com efeito mensurável em nodes, cores, storage e licenciamento, exatamente como a Ata 10 argumenta.

Riscos que já têm dono no plano de ação da Ata 10 (P0/P1)

Prioridade	Achado	Situação
P0	Comunicação interna por rota externa	Confirmado ao vivo, correção de maior retorno e menor ambiguidade
P0	Ausência de backup e DR efetivos do barramento	Risco crítico, único sem mitigação posterior possível
P1	Tópicos e eventos duplicados	Convergente com Ata 09 e com o artefato de Atendimento
P1	Cargas de BI/CDC sem avaliação de necessidade real-time	Debezium via Kafka Connect movendo tabelas grandes sem SLA definido
P1	Event Store como estratégia de persistência e replay	Proposta acolhida pela equipe, não implementada
P2	Segregação/cluster dedicado para o barramento	Já é objeto de estudo interno da Energisa — oportunidade de alinhar escopo
P2	Ciclo de vida, observabilidade e testes de falha	Operador estava desatualizado por período prolongado, atualização em curso

Próximo passo

Consolidar os três diagramas na Ata 10 (itens 1.11.6, 1.11.5 e 1.11.13) e usá-los como base visual do Capítulo 4 (Infraestrutura, Clusters e Datacenters) e do Capítulo 6 (Recomendações e Roadmap), quando esses capítulos forem trabalhados. Antes disso, recomenda-se confirmar com quem redigiu o relatório técnico da sessão a origem da afirmação sobre a ausência de Norberto por atraso de voo — item pequeno, mas que não deveria ficar sem lastro documentado em um assessment que se pretende auditável.