Ata 10 · Assessment de Arquitetura de OpenShift, Confluent Kafka e Integrações do ADMS: Rede, Storage, Capacidade, Continuidade e Resiliência (20 de julho de 2026)

Ata consolidada a partir do relatório técnico detalhado produzido sobre a sessão e da transcrição integral da gravação, com unificação dos temas e atribuição nominal das falas confirmada.

Data	20 de julho de 2026 (segunda-feira)
Horário	16h01 às 17h00, horário de Brasília
Duração	Aproximadamente 58 minutos de sessão, dos quais 54 minutos gravados
Plataforma	Microsoft Teams (reunião remota, com gravação e transcrição automática)
Natureza	Sessão técnica de levantamento e assessment arquitetural
Tema	OpenShift, Confluent Kafka, integrações do ADMS, rede, storage, capacidade, licenciamento, backup e recuperação de desastre
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Elaborado por	Syntropy Labs
Fontes	Relatório técnico detalhado da sessão e transcrição integral da gravação do Microsoft Teams

1.11.1. Identificação e contexto da sessão

1.11.1.1. Contexto de participação

A reunião foi realizada no contexto do assessment das integrações do ADMS com os sistemas corporativos e as plataformas de dados. Norberto da Silva Prado, responsável por articular o encontro, não participou em razão de atraso de voo e orientou que a sessão fosse conduzida pelos demais participantes.

A equipe convidada dispunha apenas de uma visão superficial do propósito do encontro. O convite havia sido apresentado como um assessment de OpenShift a pedido do projeto ADMS, sem detalhamento adicional, e a própria equipe solicitou a contextualização na abertura. A consultoria esclareceu que o olhar é de arquitetura de integrações do ADMS com os diversos sistemas, citando como referência a integração com o GIS, que era problemática no início do trabalho e já havia sido tratada pela Energisa, e o marco de entrada em produção do próximo agrupamento, previsto para o dia primeiro de setembro.

A partir dessa contextualização, o foco foi ampliado do levantamento de infraestrutura para a relação entre infraestrutura, rede, barramento, aplicações consumidoras, armazenamento, capacidade e continuidade. A equipe de infraestrutura registrou, ainda na abertura, que já estava conduzindo internamente uma discussão sobre o ambiente do barramento, porque ele cresceu de forma acentuada e passou a concorrer com outros ambientes dentro do OpenShift.

1.11.1.2. Objetivos técnicos estabelecidos na conversa

• Obter uma visão geral da versão e da configuração do OpenShift produtivo e não produtivo, incluindo a existência de mecanismos de escalonamento automático.
• Compreender a topologia dos componentes Kafka e Confluent e sua distribuição em nodes e pools de máquinas.
• Mapear a comunicação de rede entre aplicações, serviços do cluster, rotas externas, F5, firewall e API Gateway, verificando se produtores e consumidores permanecem na rede interna.
• Entender o modelo de armazenamento persistente e a dependência do ambiente de virtualização.
• Avaliar crescimento, consumo de recursos, licenciamento e alternativas de segregação do barramento.
• Discutir padrões de integração, uso de captura de dados alterados, demandas de BI e plataforma de dados e a necessidade real de processamento em tempo real.
• Avaliar as limitações atuais de backup e de recuperação de desastre do Kafka.
• Investigar os problemas de reconexão e de retomada das aplicações consumidoras após indisponibilidades ou atualizações.

1.11.1.3. Limites da sessão

A reunião teve caráter exploratório. Não foram apresentados inventários completos de tópicos, consumidores, volumes por fluxo, políticas de retenção, acordos de nível de serviço, métricas de latência ou procedimentos formais de recuperação de desastre. Vários pontos foram baseados na experiência operacional dos participantes e precisam ser confirmados com evidências extraídas do próprio cluster e com a equipe responsável pelo barramento, que não estava presente.

1.11.2. Participantes e áreas envolvidas

Carlos Andre Souza	Energisa, infraestrutura e plataforma OpenShift. Responsável técnico pelo ambiente. Apresentou a arquitetura, demonstrou configurações no cluster durante a sessão e relatou as limitações de backup, de recuperação de desastre e de capacidade.
Hugo Alves de Oliveira	Energisa, gestão de infraestrutura. Contextualizou o convite, trouxe a discussão anterior com a Confluent sobre ksqlDB e Flink e esclareceu a natureza da plataforma de dados e do Databricks.
João Carlos Franco Castellani	Syntropy Labs. Condução da análise arquitetural sobre rede, padrões de integração, modelagem de eventos, Event Store e resiliência dos consumidores.
Vladimir Morozowski de Sousa	Syntropy Labs. Condução, contextualização do assessment e registro da sessão.

Foram citadas, sem participação direta, as seguintes pessoas e organizações:

• Norberto da Silva Prado, articulador da reunião, ausente por atraso de voo.
• Equipe responsável pelo barramento Kafka e Confluent, que é também a equipe do API Gateway, indicada como interlocutora necessária para o detalhamento da configuração interna dos componentes.
• Equipes de aplicação responsáveis pelos consumidores do ADMS e do Sigode, apontadas como necessárias em uma rodada seguinte.
• Confluent, que havia proposto anteriormente a migração de processamentos de ksqlDB para Flink.
• Arquiteto da Red Hat, consultado sobre as tentativas de backup do Kafka.
• Equipes de projetos de BI e da plataforma de dados, origem das solicitações de disponibilização de tabelas no barramento.

1.11.3. Resumo executivo

O ambiente apresenta sinais de crescimento rápido e de acúmulo de decisões locais que, isoladamente, podem ter sido funcionais, mas que em conjunto aumentam a complexidade operacional, o consumo de recursos e o risco de indisponibilidade. O Kafka tornou-se um componente de grande porte dentro do OpenShift e passou a competir com outros workloads, ao mesmo tempo em que aplicações internas utilizam caminhos de rede externos ao cluster sem necessidade.

Rede interna	Consumidores internos acessam o Kafka por rota externa, atravessando F5, firewall e API Gateway antes de retornar ao cluster.	Crítica
Backup e recuperação de desastre	Não existe estratégia operacional consolidada para recuperação dos eventos nem para continuidade do barramento.	Crítica
Governança de eventos	Há indícios de multiplicação desnecessária de tópicos e de eventos equivalentes, elevando tráfego e processamento.	Alta
Capacidade e licenciamento	Kafka e Kafka Connect ocupam vários nodes dedicados e ampliam o custo de licenciamento do OpenShift e a pressão sobre virtualização e storage.	Alta
Resiliência das aplicações	Consumidores demoram a restabelecer o consumo após reinícios e, em alguns casos, exigem reinício manual de pods.	Alta
Uso do barramento	Cargas de captura de dados alterados, de BI e de grandes tabelas podem estar sendo encaminhadas ao Kafka sem avaliação suficiente de alternativas batch ou nativas.	Alta
Storage	O Kafka intensificou as gravações em disco no mesmo ambiente de virtualização utilizado por outros workloads.	Alta
Ciclo de versões	O operador e os componentes permaneceram desatualizados por período relevante. A atualização está em curso, porém o processo precisa ser institucionalizado.	Média

Conclusão executiva preliminar O problema não se resume ao porte do Kafka. O quadro resulta da combinação entre desenho de rede inadequado, ausência de governança de eventos, uso indiscriminado do barramento, crescimento das cargas de dados, baixa maturidade de continuidade e fragilidades nas aplicações consumidoras. Cada um desses fatores tem tratamento próprio, e a correção de rede é a de maior retorno imediato e menor ambiguidade técnica.

1.11.4. Ambiente OpenShift, versões e ciclo de atualização

1.11.4.1. Versões informadas

• O ambiente produtivo foi informado como OpenShift 4.20.24.
• Os ambientes não produtivos já estariam em uma versão 4.21, sem confirmação do patch exato durante a sessão.
• A atualização do produtivo foi tratada com cautela deliberada, porque o barramento e as aplicações conectadas mostraram-se sensíveis a reinicializações gerais do ambiente.

1.11.4.2. Impacto das atualizações

Foi relatado que as atualizações do OpenShift exigem reinicialização de componentes e podem provocar perda temporária de conectividade entre as aplicações e o Kafka. O problema não termina com o retorno da plataforma: algumas aplicações consumidoras permanecem com consumo lento, represado ou interrompido, exigindo intervenção manual. Foi registrado que o efeito ocorreu em mais de uma atualização e também em outras intervenções de infraestrutura que impactaram o ambiente do barramento.

1.11.4.3. Interpretação arquitetural

A sensibilidade do ecossistema a atualizações indica dependência excessiva entre o ciclo de vida da plataforma, os componentes do barramento e as aplicações. Em um desenho mais resiliente, a indisponibilidade temporária de brokers ou serviços deveria ser absorvida por políticas de reconexão, espera progressiva, idempotência, sondas de disponibilidade adequadas e retomada automática do consumo. A consequência prática do quadro atual é que a operação passou a postergar atualizações, o que amplia a defasagem de versões e a exposição a vulnerabilidades.

1.11.4.4. Dimensão do ambiente e licenciamento

O OpenShift produtivo foi descrito como um ambiente de grande porte, com um número expressivo de APIs e da ordem de três mil a três mil e duzentos pods. O Kafka não consome todo o cluster, mas representa uma parcela relevante de nodes, cores, memória e storage.

• Existem nodes dedicados a Kafka, KRaft, Kafka Connect e ksqlDB, além de cerca de 26 nodes destinados aos demais workloads.
• O cálculo apresentado verbalmente para os nodes do ecossistema do barramento somou da ordem de 120 cores dedicados, com impacto direto no licenciamento do OpenShift.
• Além do licenciamento do OpenShift, existem custos de licenciamento da Confluent e de componentes específicos, o que torna a decisão de capacidade uma questão de custo total, e não apenas de recursos técnicos.

O crescimento de consumidores, conectores, tópicos e cargas de dados exige um modelo formal de planejamento de capacidade. A expansão baseada apenas na adição de nodes tende a aumentar custos sem remover as ineficiências de desenho. A ordem correta é reduzir tráfego e armazenamento desnecessários e, em seguida, dimensionar a infraestrutura residual.

1.11.5. Topologia do Kafka e da Confluent e segregação de workloads

1.11.5.1. Componentes em produção

A topologia produtiva inclui Kafka, KRaft, Kafka Connect e ksqlDB, além de outros componentes Confluent que não foram detalhados na sessão. Os quatro componentes de maior consumo foram distribuídos em nodes apartados do pool geral de workers. Os demais componentes, de menor criticidade, permanecem em workers compartilhados com o restante do ambiente. Nos ambientes não produtivos a distribuição é diferente, com componentes ativados apenas quando necessário.

1.11.5.2. Nodes dedicados e Machine Config Pools

• A segregação foi implementada por Machine Config Pools, o que permite aplicar configurações e políticas específicas sem impactar todo o conjunto de workers.
• A motivação declarada foi dupla: atender componentes que exigem maior poder de processamento e memória e facilitar as atualizações.
• Foi mencionado o ajuste de um limite de processos ou identificadores de processo nos nodes dedicados, para suportar maior paralelismo. O parâmetro exato deve ser confirmado.
• O Kafka Connect foi citado com cinco nodes em produção.

Racional da segregação A justificativa apresentada para os pools dedicados é precisa e merece registro: sem eles, qualquer ajuste necessário a um componente do barramento teria de ser aplicado a todo o pool de workers, o que impactaria o ambiente inteiro. A segregação por Machine Config Pool é, portanto, uma decisão correta de contenção de blast radius, e não apenas de capacidade.

1.11.5.3. Separação dos Kafka Connects por workload

A equipe está experimentando separar os Kafka Connects por grupos de workloads ou projetos. Em lugar de todos os fluxos utilizarem os mesmos conectores, determinados conjuntos de aplicações passariam a utilizar grupos dedicados, com nomes e recursos próprios. Em produção existem hoje entre quatro e cinco pods de conector, e todos os fluxos se conectam a eles.

• Em homologação já foi criado um conjunto apartado, com StatefulSet próprio e nomenclatura distinta, para validar a abordagem.
• A motivação é reduzir a interferência entre projetos grandes e limitar o impacto de cargas intensivas, uma vez que o ADMS não é o único sistema conectado ao barramento.
• O detalhamento da configuração interna desses conjuntos depende da equipe do barramento, que não participou da sessão.
• A abordagem é um passo intermediário útil, mas não substitui uma arquitetura-alvo com critérios formais de multilocação, capacidade e isolamento.

1.11.5.4. Debate sobre ksqlDB e Flink

Foi relatada uma discussão anterior com a Confluent sobre a possível migração de determinados processamentos de ksqlDB para Flink, motivada por limitações de performance do ksqlDB e por maior capacidade de tratamento, limpeza e deduplicação. A conversa não teve continuidade e não era de conhecimento da área de infraestrutura, o que indica uma lacuna de circulação de informação técnica entre as áreas envolvidas no barramento. O tema deve ser tratado como hipótese de evolução, e não como decisão.

1.11.5.5. Ausência de replicação de dados do Kafka

Foi afirmado que hoje não existe replicação de dados do Kafka, por não haver ferramenta implantada com essa função. Foi mencionado que a licença poderia contemplar um recurso adequado, ponto que precisa ser verificado no contrato e no inventário de componentes Confluent. Essa ausência é a raiz técnica do problema de continuidade tratado no item 1.11.13 e condiciona qualquer discussão de recuperação de desastre.

1.11.6. Arquitetura de rede, F5, rotas e comunicação interna

1.11.6.1. Topologia de entrada do cluster

O F5 atua como ponto de entrada das rotas publicadas pelo OpenShift. Um endereço da infraestrutura interna, que não pertence à VLAN do OpenShift, foi configurado como VIP no F5. Abaixo desse VIP existe um pool composto pelos três infra nodes que executam os routers do cluster, responsáveis por encaminhar as requisições aos destinos internos. O DNS das aplicações aponta para esse VIP, o que foi demonstrado na própria sessão: a resolução de qualquer endereço de API do cluster, do barramento ou do Kafka retorna o endereço de entrada do F5.

1.11.6.2. Segmentação e liberações

• O cluster produtivo utiliza uma VLAN exclusiva para o OpenShift.
• A rede interna do cluster foi descrita como única, sem segregação por Network Policies. Segundo o relato, não há políticas de rede aplicadas para controlar a comunicação lateral entre namespaces ou workloads.
• A liberação de acesso é feita por faixas de IP do OpenShift e regras de firewall, conforme a origem ou o destino. Quando o cluster é a origem, a faixa é liberada para os destinos externos necessários, como bancos de dados.
• Quando um consumidor externo precisa alcançar uma rota, um front-end ou uma API publicada, o acesso ocorre pelo endereço do VIP no F5.

1.11.6.3. Achado central: comunicação interna por rota externa

O achado mais objetivo da sessão é que aplicações hospedadas dentro do próprio OpenShift acessam o Kafka, e possivelmente outras APIs internas, por meio de rotas externas, em lugar de utilizar Services e o DNS interno do cluster. Foram citados nominalmente o Sigode e os pods do ADMS entre os serviços que se conectam ao Kafka por essa via.

Pod consumidor, Service interno, endpoint do Kafka dentro do cluster, sem sair do ambiente.	Pod consumidor, rota e DNS externo, F5, firewall, API Gateway, retorno ao OpenShift e somente então o Kafka.

O efeito é uma volta desnecessária para fora do cluster e de retorno ao mesmo ambiente. A avaliação registrada pela própria equipe de infraestrutura foi de que há perda expressiva de latência e de performance nesse caminho, além de dependência do F5, do firewall e do gateway, aumento do número de pontos de falha e maior complexidade de diagnóstico.

Uma distinção importante foi estabelecida durante a conversa: a comunicação entre os próprios componentes do barramento ocorre por Service, dentro do cluster, e os produtores foram descritos como utilizando a rede interna. O problema concentra-se nas aplicações consumidoras, que buscam a informação no Kafka a partir da rota publicada. Essa distinção delimita o escopo da correção e precisa ser confirmada com o inventário de endpoints.

1.11.6.4. Evidências levantadas na sessão

• Durante a demonstração no cluster foram identificadas variáveis de ambiente de uma API de atendimento apontando para outra API por URL externa, o que indica que o padrão não está restrito ao Kafka.
• Foi identificado também acesso ao Schema Registry por rota, e não por Service interno.
• Os endpoints encontrados estavam definidos em variáveis de ambiente. Não foi possível confirmar, na sessão, se existem valores fixos no código-fonte, hipótese considerada plausível pela própria equipe.
• A necessidade de migrar para Services internos já havia sido comunicada às equipes de aplicação, que estavam tentando implementar a mudança, sem confirmação de conclusão.

1.11.6.5. Posicionamento do API Gateway

O API Gateway foi descrito como externo ao OpenShift no ambiente produtivo. Nos ambientes de desenvolvimento, a equipe estava configurando o gateway dentro do cluster, como pods, arranjo que ainda não havia sido levado à produção. A posição exata do gateway no caminho de rede produtivo precisa ser confirmada, porque ela define quantos saltos a comunicação interna atravessa hoje e qual o ganho efetivo da correção.

1.11.6.6. Implicações de segurança e governança

Paradoxo de rede identificado A combinação entre ausência de Network Policies e uso de rotas externas para comunicação interna produz um paradoxo: o tráfego que deveria permanecer dentro do cluster faz um caminho mais longo, mais caro e mais frágil, enquanto a comunicação lateral que efetivamente ocorre dentro do cluster permanece sem segmentação. A correção precisa ser dupla, simplificando os caminhos internos e, ao mesmo tempo, introduzindo controles explícitos entre namespaces e workloads. Corrigir apenas o primeiro lado aumenta a superfície de comunicação lateral não controlada.

1.11.7. Storage, virtualização e impacto de entrada e saída

1.11.7.1. Modelo de persistência

Os Persistent Volume Claims utilizados pelos componentes do barramento são provisionados por uma StorageClass baseada em driver CSI do VMware. Na prática, os volumes persistentes são materializados como discos virtuais no datastore do ambiente de virtualização, que foi descrito como hiperconvergente Dell VxRail sobre VMware, em versão informada verbalmente como 8.0.3.330, com atualizações já em tratativa com o fornecedor.

• Todos os componentes do barramento utilizam a mesma StorageClass e criam PVCs convencionais.
• Não foi relatado uso produtivo de object storage para retenção histórica de eventos.
• A instalação do OpenShift está integrada ao ambiente de virtualização, o que reforça a dependência entre plataforma de contêineres e plataforma de máquinas virtuais.

1.11.7.2. Volumetria informada

Foi mencionada a existência de três clusters Kafka, cada um com capacidade da ordem de dois terabytes e meio e ocupação parcial. Os números foram citados de memória durante a demonstração e precisam ser extraídos do inventário, porque são a base de qualquer discussão sobre retenção, Event Store e dimensionamento.

1.11.7.3. Pressão de gravação

A entrada do Kafka no OpenShift aumentou significativamente o volume de gravações em disco. Como o mesmo ambiente de virtualização hospeda outros workloads, inclusive outras cargas relevantes, o comportamento intensivo de entrada e saída do Kafka passou a onerar a plataforma de virtualização e pode gerar contenção com sistemas que operam em paralelo. Esse ponto foi apresentado pela equipe como uma das preocupações centrais de arquitetura, ao lado do licenciamento.

1.11.7.4. Hipótese sobre a política de storage

Foi levantada, durante a inspeção da StorageClass, a suspeita de que a política de storage aplicada aos volumes do barramento não seja a mais adequada para carga de escrita intensiva, com hipótese de perda de performance associada a um esquema de redundância com paridade, do tipo RAID 6. A leitura do termo na transcrição não permite afirmação definitiva, e a própria equipe registrou que a configuração provavelmente foi o padrão adotado na época da implantação.

Foi observado ainda que a alteração dessa política no ambiente existente não é trivial, por envolver risco de perda de dados, e exigiria um plano específico de migração de volumes. Recomenda-se revisar os parâmetros da StorageClass e da política de storage, além de latência, operações por segundo, throughput, replicação, tamanho de blocos e afinidade entre volumes e nodes, antes de qualquer decisão.

1.11.8. Esteira de DevOps, operador CFK e gestão de versões

1.11.8.1. Mecanismo de atualização

As alterações de configuração e de versão dos componentes Kafka e Confluent são realizadas por esteira de DevOps, com aprovação e publicação no OpenShift por pipeline, com participação dos times de desenvolvimento e de plataforma. A esteira concentra praticamente todas as modificações nos componentes do barramento.

1.11.8.2. Atualização do operador Confluent for Kubernetes

• O operador estava significativamente desatualizado e foi atualizado nos ambientes de desenvolvimento e de homologação.
• A equipe optou deliberadamente pela penúltima versão disponível, em lugar da mais recente, para evitar exposição a defeitos de uma release muito nova. A decisão foi discutida e acordada entre plataforma e barramento.
• Os componentes Kafka, Connect e demais serviços foram alinhados a versões compatíveis com o operador e com a versão do OpenShift em uso, com o objetivo declarado de permanecer em suporte e reduzir exposição a vulnerabilidades.
• A atualização de produção ainda estava pendente no momento da sessão.
• Foi mencionada a evolução aproximada do operador de uma versão 2.9.3 para 3.2.3. A numeração deve ser confirmada nos manifestos e no inventário de versões.

1.11.8.3. Diagnóstico sobre gestão de ciclo de vida

A atualização em curso é positiva, mas o histórico indica ausência de um processo contínuo de gestão de ciclo de vida. Foi relatado que os componentes foram implantados e permaneceram sem atualização por período prolongado. É necessário instituir calendário, matriz de compatibilidade entre OpenShift, operador, componentes Confluent e bibliotecas de cliente, ambientes de teste equivalentes, critérios de rollback e janela operacional definida.

1.11.9. Ambientes não produtivos e fidelidade dos testes

Desenvolvimento e homologação não reproduzem integralmente a capacidade de produção. Componentes e recursos são ativados temporariamente para testes e removidos em seguida, prática adotada por causa do custo de licenciamento do OpenShift e da Confluent e do consumo de infraestrutura. A prática foi descrita de forma direta: sobe-se o componente, executa-se o teste e ele é desativado.

A consultoria levantou a possibilidade de utilizar uma edição open source do Kafka nos ambientes de desenvolvimento, reduzindo custo de licenciamento nos testes. A área de infraestrutura registrou uma ressalva pertinente: existe o risco de validar uma configuração ou funcionalidade em uma edição e encontrar comportamento diferente na versão licenciada utilizada em produção, gerando impacto posterior. A avaliação precisa ser feita componente a componente, com apoio do fornecedor.

Em qualquer cenário, a diferença atual entre ambientes reduz a fidelidade dos testes de carga, de atualização e de comportamento em falha, que são exatamente os testes necessários para tratar os riscos identificados nesta sessão.

1.11.10. Padrões de integração e uso do barramento

1.11.10.1. Barramento utilizado como passagem universal

A discussão indicou que o Kafka está sendo utilizado em fluxos cuja natureza é de integração ponto a ponto, de movimentação massiva de dados ou de carga e transformação. Nesses casos, o barramento recebe grandes volumes apenas para intermediar uma transferência entre origem e destino. O exemplo citado foi o de rotinas que leem da ordem de cem mil registros e transformam cada registro em um evento, publicando o conjunto no barramento apenas para que outro componente o consuma e grave no destino.

1. Um produtor lê ou captura os dados na origem e publica os eventos no Kafka.

2. Outro componente consome os eventos e os grava em uma plataforma de destino.

3. Quando o requisito não é streaming nem desacoplamento temporal, o desenho adiciona custo, persistência intermediária e complexidade, sem benefício correspondente.

1.11.10.2. Critério arquitetural proposto

Cada fluxo deve ser classificado antes da definição da tecnologia. O uso do barramento é justificável quando existem múltiplos consumidores, necessidade de desacoplamento, replay, ordenação, baixa latência ou processamento contínuo. Transferências de periodicidade diária, cargas históricas e tabelas completas podem ser mais adequadas a outras abordagens.

Evento operacional em tempo real, com múltiplos consumidores e necessidade de replay	Kafka e processamento de eventos
Carga diária, histórica ou de tabela completa	Processos de carga e transformação, completos ou incrementais
Replicação entre banco relacional e plataforma de dados em nuvem	Conector nativo do banco ou da plataforma, serviço de integração gerenciado ou recurso equivalente
Integração síncrona entre APIs internas	API interna acessada por Service, com gateway apenas quando houver exposição externa
Transferência massiva de arquivos ou de dados	Object storage, transferência gerenciada de arquivos ou ingestão nativa da plataforma de dados

1.11.11. Captura de dados alterados, BI e plataforma de dados

1.11.11.1. Demanda crescente da plataforma de dados

Foram relatadas solicitações de projetos de BI e da plataforma de dados corporativa para disponibilização de tabelas muito grandes no Kafka. A área de sustentação percebe crescimento acelerado e manifestou preocupação com a expansão contínua dos volumes, descrevendo as solicitações como pedidos de tabela sobre tabela, sem limite estabelecido, e associando esse movimento diretamente ao crescimento observado no ambiente.

• Foram citados a plataforma de dados da Energisa e o Databricks, hospedado em nuvem, como destinos dos dados.
• As solicitações incluem tabelas extensas e potencialmente históricas, e não apenas eventos operacionais compactos.
• O requisito de tempo real não estava claro para todos os fluxos, nem para as áreas presentes.

1.11.11.2. Desenho atual e alternativas

O desenho discutido utiliza captura de dados alterados, com Debezium sobre Kafka Connect, para capturar as alterações no SQL Server e publicar eventos no Kafka, que depois alimentam outra estrutura. O mecanismo é tecnicamente válido, mas produz grande volume e persistência intermediária quando aplicado a tabelas extensas sem exigência de baixa latência.

A consultoria sugeriu avaliar conectores nativos entre o banco relacional, a nuvem e o Databricks, ou mecanismos de integração da própria plataforma de dados. Para processos de periodicidade diária ou sem exigência de baixa latência, um processo de carga e transformação removeria o barramento do caminho, com redução direta de tráfego, storage e processamento.

Achado de governança revelado na sessão Ao discutir o fluxo, a área de gestão de infraestrutura registrou que acreditava que a integração entre o banco relacional e a plataforma de dados ocorresse por um serviço de integração gerenciado, e não pelo Kafka. A constatação de que o fluxo atravessa o barramento foi feita durante a própria reunião. O achado é relevante além do caso específico: indica que decisões de rota de dados estão sendo tomadas sem visibilidade das áreas que sustentam a plataforma e absorvem o custo de capacidade.

1.11.11.3. Pergunta a formalizar

Requisito a ser formalizado fluxo a fluxo Tudo precisa realmente ser processado em tempo real? A resposta deve ser dada fluxo a fluxo, com registro explícito de acordo de nível de serviço de atualização, volume, janela, tolerância a atraso e criticidade operacional. Sem essa formalização, o barramento continuará sendo o caminho padrão para qualquer necessidade de movimentação de dados, por ausência de critério, e não por decisão de arquitetura.

1.11.12. Modelagem de eventos, tópicos e duplicação de mensagens

1.11.12.1. Fragmentação por status

Foi apresentado o padrão observado em outra frente do assessment: uma mesma entidade de negócio com aproximadamente sete tópicos distintos, cada um representando um tipo ou status do evento. Uma aplicação recebe o evento original, quebra-o em vários eventos derivados e os publica em novos tópicos, para atender consumidores específicos.

Convergência com a Ata 09 O padrão descrito nesta sessão pela consultoria é exatamente o que foi levantado com as áreas de canais digitais e de atendimento convencional em 15 e 16 de julho, registrado no item 1.10.5: sete tópicos representando estados da mesma ocorrência, alimentados por um componente que consolida e republica o conteúdo. A convergência é significativa porque as duas sessões chegam ao mesmo achado por caminhos independentes, uma pela modelagem funcional e outra pelo consumo de infraestrutura. Isso eleva o tema de discussão de desenho para item de capacidade e de custo, com efeito mensurável em nodes, cores, storage e licenciamento.

1.11.12.2. Efeito multiplicador

O padrão aumenta de forma multiplicativa o número de mensagens, tópicos, produtores, consumidores e pontos de falha. A informação essencial permanece a mesma, mas é replicada em múltiplas representações.

• Maior tráfego no cluster e na rede.
• Mais armazenamento e maior necessidade de retenção.
• Mais processamento no produtor intermediário e em cada consumidor.
• Maior dificuldade de versionamento de esquemas e de rastreabilidade.
• Maior risco de divergência entre os eventos derivados.

1.11.12.3. Alternativa recomendada

A alternativa é definir a entidade e um esquema canônico, publicar os diferentes tipos de mudança em um tópico coerente e permitir que os consumidores filtrem por tipo, status ou atributo. A decisão final deve considerar volume, ordenação por chave, retenção e isolamento de domínios, mas a criação de um tópico por status não deve ser o padrão automático.

1.11.12.4. Governança necessária

• Catálogo de eventos e tópicos, com dono, domínio, esquema, chave de partição, retenção e consumidores.
• Processo de aprovação para novos tópicos e para eventos derivados.
• Schema Registry com políticas de compatibilidade e de versionamento.
• Métricas de duplicação, fan-out, volume por domínio e crescimento de storage.
• Critérios explícitos de compactação, retenção e exclusão.

1.11.13. Backup, retenção, Event Store e recuperação de desastre

1.11.13.1. Situação atual de backup

A equipe relatou tentativas sem sucesso de realizar backup convencional dos volumes do Kafka. Foram testadas três ferramentas distintas, entre elas a solução de proteção de dados do próprio ecossistema OpenShift e uma prova de conceito com uma ferramenta de terceiros, sem resultado satisfatório em nenhuma delas. Como o Kafka grava continuamente, um snapshot consistente dos volumes exigiria parada ou coordenação que não é viável em operação contínua.

A conclusão foi validada externamente: após as tentativas, a equipe discutiu o caso com um arquiteto da Red Hat e confirmou que a arquitetura do Kafka, por gravar de forma contínua, não é compatível com a estratégia de backup de volume. A decisão registrada foi abandonar essa linha, o que é tecnicamente correto e desloca a questão para a estratégia de persistência de eventos.

1.11.13.2. Situação atual de recuperação de desastre

Existe um segundo cluster OpenShift destinado à recuperação de desastre, que não opera em modo ativo-ativo. A intenção atual é instalar o operador e subir os componentes do barramento no ambiente secundário com volumes vazios. Ainda não há mecanismo definido para replicar ou recuperar os eventos necessários, uma vez que não existe ferramenta de replicação implantada.

Declaração explícita registrada na sessão Foi afirmado de forma direta que hoje não existe backup nem recuperação de desastre efetiva do barramento e que, em caso de indisponibilidade catastrófica do site principal, o ambiente secundário não está pronto para assumir a operação com continuidade de dados. A equipe está buscando alternativas para obter, ao menos, um nível mínimo de recuperação. Este é o risco de maior severidade identificado na sessão e o único cuja materialização não admite mitigação posterior.

1.11.13.3. Event Store como alternativa

A alternativa discutida é criar uma saída paralela que persista os eventos em object storage. Os eventos podem ser comprimidos e gravados em formato analítico, particionados por data e hora. O Event Store passa a ser o repositório durável e recuperável, enquanto o Kafka mantém apenas a retenção operacional necessária. A proposta foi acolhida pela equipe de infraestrutura como caminho a incorporar, com o reconhecimento de que hoje esse mecanismo não existe e que, na situação atual, a perda do ambiente implica perda dos eventos.

Função principal	Transporte e processamento de eventos ativos	Persistência histórica durável
Retenção	Curta ou média, conforme a necessidade operacional	Longa, definida por política de ciclo de vida
Custo de armazenamento	Mais elevado para grande histórico	Mais eficiente, com compressão e formatos colunares
Recuperação	Replay dentro da janela de retenção	Reidratação e republicação de eventos históricos
Backup	Não deve depender de snapshot do log ativo	Pode usar políticas normais de backup e replicação do object storage

1.11.13.4. Particionamento e janela de recuperação

Foi detalhado o mecanismo de particionamento que viabiliza o backup: os eventos são gravados em partições por data, hora e, se o volume justificar, por intervalos menores, da ordem de quinze minutos. As partições já fechadas, que não estão mais recebendo escrita, podem ser copiadas por rotinas convencionais de backup. O resultado prático é uma janela de perda potencial limitada ao intervalo da partição corrente, em lugar da situação atual, na qual não existe ponto de recuperação.

1.11.13.5. Retenção e replay

Sem Event Store, a tendência organizacional é aumentar a retenção no Kafka para proteger-se contra perda de eventos, o que amplia o consumo do storage mais caro do conjunto. Com um repositório histórico confiável, a retenção do barramento pode ser reduzida a dias ou semanas, conforme o acordo de nível de serviço de cada fluxo, e os eventos são recuperados do object storage e republicados de forma controlada quando necessário. A política de retenção atualmente praticada por tópico não era conhecida pelos participantes e integra a lista de validação.

1.11.13.6. Infraestrutura disponível para provas de conceito

• Foi mencionada a capacidade de object storage do OpenShift Data Foundation, originalmente criada para apoiar as tentativas de backup.
• Existe também um MinIO instalado em servidor Linux no data center da Paraíba, utilizado para provas de conceito, inclusive as de backup em andamento.
• A opção por um servidor externo ao cluster foi deliberada, para não concentrar no mesmo ambiente o dado e a sua cópia.
• O MinIO atual é experimental e não deve ser tratado como solução produtiva sem alta disponibilidade, replicação, segurança, monitoramento e governança.

1.11.14. Resiliência das aplicações consumidoras

1.11.14.1. Comportamento observado

Após reinícios do OpenShift, atualizações ou intervenções de infraestrutura, aplicações consumidoras do ADMS e do Sigode podem deixar de consumir ou consumir com baixa velocidade. As filas acumulam eventos e, em diversos casos, os pods precisam ser reiniciados manualmente para que o fluxo volte a operar em velocidade adequada. O problema já ocorreu mais de uma vez.

• O efeito atinge informações operacionais que exigem atualização praticamente em tempo real.
• Os usuários dos centros de operação percebem o atraso de imediato, porque a nova geração da solução entrega os dados com latência muito menor que o sistema anterior, o que elevou o patamar de expectativa.
• O acúmulo gera backlog no barramento e piora, em seguida, o tempo de resposta da própria aplicação, produzindo um efeito de duas camadas.

1.11.14.2. Hipóteses técnicas

• Políticas inadequadas de reconexão e de espera progressiva nos clientes Kafka.
• Ausência ou configuração incorreta de disjuntor para dependências temporariamente indisponíveis.
• Tempos limite, sessões, sinais de atividade, rebalanceamento e grupos de consumo mal ajustados.
• Sondas de disponibilidade que não refletem a capacidade real de consumir mensagens, apenas a existência do processo.
• Uso de rota externa, com F5, firewall e gateway no caminho, introduzindo falhas adicionais na reconexão.
• Gerenciamento inadequado de offsets ou de confirmações em cenários de queda e retomada.
• Concorrência insuficiente para drenar o backlog acumulado após a recuperação.

A própria equipe de infraestrutura levantou espontaneamente a hipótese de que o problema esteja relacionado ao uso da rota em lugar do Service, avaliação com a qual a consultoria concordou como possibilidade concreta. As duas causas não são exclusivas: a correção de rede reduz a probabilidade de falha na reconexão, e o tratamento no cliente garante a retomada quando a falha ocorrer. A investigação deve considerar as duas frentes simultaneamente.

1.11.14.3. Disjuntor e retomada automática

Foi detalhado o comportamento esperado: a aplicação identifica a indisponibilidade, abre o circuito para evitar chamadas contínuas a uma dependência ausente, realiza tentativas periódicas com intervalos progressivos e, ao perceber o restabelecimento, fecha o circuito e retoma o processamento normal, sem intervenção humana. No caso do Kafka, o padrão precisa ser adaptado às bibliotecas de cliente, às políticas de nova tentativa e à semântica de consumo adotada. Foi registrado o entendimento, compartilhado pelas duas partes, de que uma aplicação hospedada em uma plataforma de contêineres deve absorver o reinício de suas dependências como comportamento esperado, e não como exceção.

1.11.15. Riscos técnicos e impactos operacionais

Falha do site principal sem recuperação possível dos eventos do barramento	Alta	Muito alto	Crítico	Perda de continuidade, impossibilidade de replay e recuperação prolongada
Comunicação interna trafegando por rota externa	Alta	Alto	Crítico	Latência, dependências adicionais e falhas de reconexão
Crescimento de eventos e tópicos duplicados	Alta	Alto	Alto	Expansão de storage, processamento, rede e complexidade
Uso do barramento para cargas massivas sem exigência de tempo real	Alta	Alto	Alto	Custos elevados e risco de saturação do barramento
Aplicações que não retomam o consumo automaticamente	Média	Alto	Alto	Backlog e atraso em informações operacionais críticas
Defasagem de versões de operador, componentes e clientes	Média	Alto	Alto	Vulnerabilidades, perda de suporte e risco elevado em atualizações
Ausência de Network Policies no cluster	Alta	Médio	Alto	Movimentação lateral sem controle e baixa segmentação
Storage compartilhado sob carga intensiva de escrita	Média	Alto	Alto	Contenção e degradação de outros workloads da virtualização
Ambientes de teste não equivalentes à produção	Alta	Médio	Médio	Falhas não detectadas antes da entrada em produção

O risco técnico se traduz diretamente em atraso de informações operacionais, indisponibilidade percebida pelos centros de controle, aumento de custo de infraestrutura, maior tempo de diagnóstico e redução da capacidade de evolução do ADMS e da plataforma de dados.

1.11.16. Recomendações arquiteturais

1.11.16.1. Prioridade imediata: corrigir o tráfego interno

1. Inventariar todas as URLs de Kafka e de APIs utilizadas por workloads internos, identificando quais utilizam rota e quais utilizam Service.

2. Substituir rotas externas por Services internos e pelo DNS do cluster sempre que origem e destino estiverem no OpenShift.

3. Eliminar valores fixos no código e centralizar os endpoints em ConfigMaps, Secrets ou mecanismo de configuração governado.

4. Medir latência e taxa de erro de conexão antes e depois da correção, para dimensionar o ganho e sustentar as decisões seguintes.

5. Introduzir Network Policies por namespace e por domínio, mantendo apenas as comunicações necessárias.

1.11.16.2. Segregar o barramento de forma orientada a requisitos

A separação do Kafka do OpenShift compartilhado deve ser avaliada por estudo de capacidade e de operação, e não apenas pelo consumo atual. As opções incluem cluster OpenShift dedicado ao barramento, ambiente separado no mesmo parque, infraestrutura virtualizada específica ou serviço gerenciado, conforme requisitos de soberania do dado, suporte, latência e custo.

• Considerar crescimento projetado, blast radius, ciclo de atualização e independência operacional, além do consumo corrente.
• Comparar o custo total de cores do OpenShift, licenciamento Confluent, virtualização, storage e operação com as alternativas dedicadas.
• Avaliar se brokers, conectores e processamento de streaming exigem níveis distintos de isolamento, o que permitiria uma separação parcial.

1.11.16.3. Instituir governança de eventos

• Criar catálogo corporativo de eventos e tópicos.
• Definir esquema canônico por domínio e regras de versionamento.
• Revisar os tópicos fragmentados por status e as aplicações que duplicam eventos.
• Estabelecer revisão de arquitetura obrigatória para novos fluxos de streaming.
• Definir quotas, retenção, compactação e políticas de nomenclatura.

1.11.16.4. Classificar as cargas por acordo de nível de serviço

Criar uma matriz de decisão que defina quando utilizar streaming, captura de dados alterados, API, carga e transformação ou transferência de arquivos. Cada solicitação de BI ou da plataforma de dados deve informar origem, volume, frequência, latência necessária, profundidade histórica, consumidores, criticidade e janela de processamento, como condição para aprovação.

1.11.16.5. Construir o Event Store e a estratégia de replay

1. Selecionar object storage produtivo, com alta disponibilidade e replicação entre sites.

2. Persistir os eventos relevantes em formato comprimido e particionado por data e hora.

3. Definir política de ciclo de vida por domínio e por exigência regulatória.

4. Criar procedimento e ferramenta de reidratação e republicação controlada dos eventos.

5. Reduzir a retenção do Kafka somente após comprovar integridade e recuperabilidade do Event Store.

1.11.16.6. Redesenhar a recuperação de desastre do barramento

A recuperação de desastre deve ser definida por objetivos de ponto e de tempo de recuperação, e não pela capacidade de instalar componentes vazios no ambiente secundário. É necessário escolher entre replicação de clusters, replicação de tópicos, recuperação a partir do Event Store, reconstrução de estado a partir dos sistemas de origem, ou combinação dessas estratégias.

• Testar failover e failback de forma periódica, e não apenas documentar o procedimento.
• Documentar as dependências de DNS, F5, firewall, certificados, esquemas, configurações e segredos.
• Garantir que as aplicações saibam alternar endpoints e retomar o consumo de forma automática, requisito que se conecta diretamente ao item 1.11.14.
• Verificar se a licença Confluent já contempla mecanismo de replicação entre clusters, o que alteraria o custo da solução.

1.11.16.7. Aumentar a resiliência dos consumidores

• Revisar as configurações de cliente Kafka, grupos de consumo, sinais de atividade, tentativas e espera progressiva.
• Implementar verificações de saúde funcionais, que reflitam a capacidade de consumir, e não apenas a existência do processo.
• Garantir idempotência e tratamento de mensagens duplicadas no consumo.
• Automatizar o escalonamento para drenagem de backlog após incidentes.
• Criar testes controlados de falha, com reinício de brokers, perda de rede e rebalanceamento.

1.11.16.8. Fortalecer ciclo de vida e observabilidade

• Manter matriz de compatibilidade entre OpenShift, operador, componentes Confluent e bibliotecas de cliente.
• Definir calendário periódico de atualização e critérios para correção emergencial.
• Monitorar atraso por grupo de consumo, throughput, taxa de erro, rebalanceamento, uso de disco, operações por segundo, latência de storage e tráfego por rota.
• Criar objetivos de nível de serviço para disponibilidade do barramento e latência dos eventos críticos.

1.11.17. Plano de ação priorizado

1.11.17.1. Ações de 0 a 30 dias

Inventário de rotas, Services, endpoints e consumidores do Kafka	Plataforma OpenShift, aplicações e barramento	Mapa de comunicação e lista de correções priorizadas
Medição de latência e de tráfego no caminho atual	Infraestrutura e observabilidade	Linha de base técnica antes da correção
Inventário de tópicos, volumes, retenção e atraso de consumo	Equipe do barramento	Relatório de capacidade e de governança
Mapeamento de versões e de compatibilidade	Plataforma e barramento	Matriz de versões e plano de atualização de produção
Definição preliminar de objetivos de recuperação por fluxo crítico	Negócio, operação e arquitetura	Requisitos de continuidade formalizados
Análise dos consumidores que não retomam automaticamente	Times de aplicação	Lista de causas e de correções
Extração das evidências de configuração do cluster	Plataforma OpenShift com a consultoria	Conjunto de evidências para substituir os números citados de memória

1.11.17.2. Ações de 30 a 60 dias

• Migrar as aplicações prioritárias para Services internos e ativar Network Policies controladas.
• Revisar e consolidar tópicos duplicados em um domínio piloto.
• Classificar os fluxos de BI e da plataforma de dados entre tempo real, quase tempo real e batch.
• Executar prova de conceito de Event Store com object storage produtivo ou arquitetura equivalente.
• Executar teste controlado de reinício e medir a recuperação automática dos consumidores.
• Concluir a atualização do operador e dos componentes em produção, com rollback testado.
• Revisar a política de storage aplicada aos volumes do barramento e avaliar o plano de migração, se confirmada a inadequação.

1.11.17.3. Ações de 60 a 120 dias

• Definir a arquitetura-alvo do barramento: compartilhado reforçado, cluster dedicado, plataforma separada ou serviço gerenciado.
• Implementar a estratégia de recuperação de desastre e realizar o primeiro exercício completo.
• Instituir a governança corporativa de eventos e o fórum de revisão de arquitetura para streaming.
• Automatizar políticas de retenção, quotas, capacidade e ciclo de vida.
• Revisar contratos e licenças e comparar o custo total das alternativas de implantação.

1.11.18. Encaminhamentos e evidências acordadas

A sessão produziu encaminhamentos concretos, alguns deles convergentes com iniciativas já em curso na Energisa.

1. A equipe de infraestrutura informou que já possui uma entrega em andamento: um estudo sobre a separação do barramento e as melhorias associadas. Foi registrado que essa entrega converge com o objeto do assessment, o que recomenda alinhamento de escopo e de cronograma entre as duas frentes para evitar trabalho duplicado.

2. Foi oferecido acesso ao ambiente para coleta de evidências técnicas pela consultoria, com apoio da equipe de plataforma.

3. Foi autorizado contato direto com a área de infraestrutura, por mensagem ou agenda, sem necessidade de intermediação, para esclarecimentos e novas rodadas.

4. Foi recomendada, pela própria equipe, uma nova rodada com as áreas responsáveis pelas aplicações consumidoras, ausentes nesta sessão.

5. A gravação da reunião seria encaminhada à coordenação do assessment e disponibilizada à consultoria.

As sessões técnicas ainda necessárias, decorrentes desta reunião, são:

• Equipe responsável pelo barramento Kafka e Confluent, para validar topologia, componentes, versões, licenças, retenções e a configuração dos conjuntos de conectores.
• Desenvolvedores do ADMS e das aplicações consumidoras, para revisar endpoints, reconexão e idempotência.
• Time da plataforma de dados e do Databricks, para classificar os requisitos de ingestão e eliminar do barramento as cargas inadequadas.
• Infraestrutura, storage e redes, para avaliar entrada e saída, F5, firewall, VLANs e Network Policies.
• Sessão de continuidade para estabelecer objetivos de recuperação e escolher a estratégia de recuperação de desastre.

1.11.19. Pontos que exigem validação

Os itens abaixo foram mencionados ou inferidos na sessão, muitos deles citados de memória durante a demonstração, e precisam ser confirmados por inventário, manifestos ou documentação técnica antes de compor conclusões definitivas do assessment.

• Versão exata do OpenShift nos ambientes de desenvolvimento, homologação e produção.
• Versões exatas do operador e de cada componente Confluent antes e depois da atualização.
• Quantidade de nodes, cores, memória e pods dedicados por componente, e o total efetivo de cores licenciados atribuídos ao barramento.
• Número de clusters Kafka, capacidade provisionada e ocupação real de cada um.
• Políticas atuais de retenção por tópico e volume diário e mensal de eventos.
• Quantidade de tópicos, esquemas, produtores e consumidores por domínio.
• Parâmetros da StorageClass, política de storage aplicada e métricas de entrada e saída, incluindo a confirmação da hipótese de esquema de paridade.
• Parâmetro exato ajustado nos nodes dedicados para ampliação de paralelismo.
• Posição e função exata do API Gateway no caminho de rede produtivo.
• Lista das aplicações que utilizam rota externa e existência de endpoints fixos em código.
• Ferramentas de backup efetivamente testadas e o registro formal dos resultados.
• Capacidade real do object storage disponível e sua adequação como Event Store produtivo.
• Existência de mecanismo de replicação entre clusters já contemplado no licenciamento.
• Objetivos de ponto e de tempo de recuperação exigidos para ADMS, barramento, esquemas, conectores e consumidores.
• Natureza de tempo real, quase tempo real ou batch de cada integração de BI e da plataforma de dados.
• Causas técnicas dos consumidores que não retomam o consumo após interrupções.

1.11.20. Conclusão do assessment desta sessão

A sessão confirmou que o ambiente OpenShift é robusto e operacionalmente relevante, mas passou a sustentar um ecossistema Kafka e Confluent que cresceu de forma acelerada e se tornou um dos principais vetores de consumo, de complexidade e de risco. A equipe já adotou medidas corretas, como nodes dedicados, Machine Config Pools, segregação inicial de conectores e atualização do operador, além de ter interrompido por conta própria uma linha de investigação inadequada, a do backup de volume. Essas ações, porém, tratam principalmente sintomas de capacidade e de manutenção.

Os problemas mais estruturais estão no desenho de integração. Aplicações internas se comunicam por rotas externas, eventos equivalentes são multiplicados, grandes tabelas são encaminhadas ao barramento sem confirmação da necessidade de streaming e a recuperação após falhas depende de intervenção manual. Ao mesmo tempo, não existe estratégia madura de persistência histórica e de continuidade para os eventos.

Diagnóstico preliminar A arquitetura encontra-se em um estágio de expansão funcional com governança e resiliência abaixo do nível exigido pela criticidade operacional do ADMS. O ambiente ainda funciona, mas apresenta sinais de dívida arquitetural acumulada e risco crescente de saturação, de indisponibilidade prolongada e de aumento desproporcional de custos.

O diagnóstico se resume em cinco conclusões:

1. O caminho de rede interno está incorreto em parte relevante dos fluxos. O uso de rotas externas para comunicação dentro do cluster adiciona latência e dependências evitáveis. É a correção de maior retorno e de menor ambiguidade técnica.

2. O barramento está absorvendo cargas além do seu papel ideal. Demandas de captura de dados alterados, de BI e de movimentação de tabelas precisam ser classificadas, e parte delas pode utilizar alternativas nativas ou batch.

3. A governança de eventos é insuficiente. A fragmentação de tópicos e a geração de eventos derivados elevam artificialmente o volume e o custo do ecossistema, achado que converge com o levantado com as áreas de atendimento.

4. Continuidade e recuperabilidade são as questões mais críticas. Sem Event Store, replicação adequada ou recuperação de desastre testada, uma falha grave pode produzir perda de dados e recuperação incerta.

5. As aplicações consumidoras não são suficientemente resilientes. A retomada lenta ou manual após falhas ameaça a operação em tempo real e precisa ser corrigida tanto no software quanto na conectividade.

P0	Eliminar a comunicação interna por rota externa e corrigir a reconexão dos consumidores críticos	Redução de latência e de falhas operacionais
P0	Definir objetivos de recuperação e a arquitetura mínima de recuperação de desastre	Plano real de continuidade do barramento
P1	Inventariar e racionalizar tópicos e eventos	Redução de tráfego, de storage e de complexidade
P1	Classificar as cargas de BI e de captura de dados por necessidade de tempo real	Remoção do barramento das cargas inadequadas
P1	Implementar o Event Store	Persistência histórica, replay e redução de retenção
P2	Decidir a segregação ou o cluster dedicado ao barramento	Independência operacional e previsibilidade de capacidade
P2	Institucionalizar ciclo de vida, observabilidade e testes de falha	Operação sustentável e menor risco em atualizações

A prioridade é corrigir o caminho de rede, eliminar tráfego e eventos redundantes, classificar os requisitos de tempo real e estabelecer continuidade. Com essas medições em mãos, a organização poderá decidir de forma fundamentada se o Kafka deve permanecer no OpenShift compartilhado, migrar para um cluster dedicado ou adotar outra plataforma, formalizando a arquitetura-alvo e o roadmap de execução. Registra-se que essa decisão já é objeto de um estudo interno em andamento, o que cria a oportunidade de conduzir as duas frentes de forma integrada.

Anexo A · Registro cronológico revisado da sessão

Registro cronológico revisado do conteúdo inteligível da sessão, com a marcação de tempo da gravação. A sequência temporal, as perguntas, respostas, hipóteses e conclusões foram preservadas. Saudações, repetições, sobreposições de fala, comentários laterais e trechos corrompidos pelo reconhecimento automático de voz foram condensados ou omitidos. Termos técnicos capturados de forma imprecisa foram normalizados quando o contexto permitiu identificação segura.

00:00:04 Vladimir: Verifica se a equipe recebeu contexto prévio sobre o objetivo da reunião.

00:00:11 Hugo: Informa que o convite havia sido apresentado apenas como um assessment de OpenShift a pedido do projeto ADMS, sem detalhamento, e solicita a contextualização.

00:00:35 Vladimir: Contextualiza o assessment: análise das integrações do ADMS com os diversos sistemas, com olhar de arquitetura. Cita a integração com o GIS, que era problemática e já foi tratada, e o próximo agrupamento a entrar em produção no dia primeiro de setembro.

00:01:28 Hugo: Pergunta se as integrações em análise são do lado da aplicação.

00:01:47 Castellani: Confirma que as integrações são do lado da aplicação e explica que é necessário entender o fluxo, o uso do barramento, das filas e dos tópicos, a existência de fila de mensagens não processadas e o tratamento de idempotência.

00:02:20 Castellani: Explicita a segunda frente: entender como a infraestrutura está construída, se o OpenShift atua como plataforma de contêineres e de máquinas virtuais e se existe object storage disponível no ambiente.

00:02:46 Carlos Andre: Informa que a própria equipe já está discutindo internamente o ambiente do barramento, porque ele cresceu de forma acentuada e passou a concorrer com outros ambientes dentro do OpenShift.

00:03:06 Carlos Andre: Registra que a intenção interna é estudar a viabilidade de separar o barramento, seja para outro cluster OpenShift, seja para fora da plataforma de contêineres, e que o assessment pode apoiar essa decisão.

00:04:14 Castellani: Detalha o que precisa ser levantado: visão geral da versão e da configuração do OpenShift, existência de escalonamento automático e forma de integração com a estrutura de rede, verificando se microserviços produtores e consumidores permanecem na rede interna do cluster.

00:04:59 Castellani: Pergunta se o ambiente tem saída para a internet, se é fechado e se o API Gateway está dentro do OpenShift.

00:05:00 Carlos Andre: Informa que a rede não é separada e inicia a apresentação por partes.

00:05:12 Carlos Andre: Informa que o OpenShift produtivo está na versão 4.20.24 e que os ambientes não produtivos já estão em uma versão 4.21, cuja identificação exata não recorda.

00:05:33 Carlos Andre: Relata que, desde a entrada do barramento no ambiente, a atualização ficou difícil, porque o conjunto é sensível: as aplicações que se conectam ao Kafka se perdem quando o ambiente é reiniciado, o que é inerente ao processo de atualização.

00:06:16 Carlos Andre: Descreve a segregação adotada: nodes apartados para Kafka, KRaft, Connect e ksqlDB em produção, com o Connect já em cinco nodes, enquanto os demais componentes permanecem em workers compartilhados.

00:06:50 Carlos Andre: Explica que a segregação foi feita por Machine Config Pool, para aplicar configurações específicas sem impactar todo o pool de workers, e menciona o ajuste de um limite de processos nos nodes dedicados para suportar mais paralelismo.

00:07:47 Hugo: Relata que a Confluent realizou uma reunião anterior sugerindo migrar processamentos de ksqlDB para Flink.

00:08:01 Carlos Andre: Registra desconhecimento dessa conversa e avalia que é o momento de rever a arquitetura.

00:08:13 Hugo: Detalha a motivação apresentada pela Confluent: limitações do ksqlDB e ganho de performance no tratamento, na limpeza e na deduplicação.

00:08:25 Carlos Andre: Aponta que a questão de replicação de dados precisa ser tratada: hoje não existe replicação do Kafka por ausência de ferramenta, embora a licença possa contemplar um recurso adequado.

00:08:40 Carlos Andre: Informa que a rede do OpenShift produtivo é única, sem segregação e sem Network Policies aplicadas.

00:08:59 Hugo: Complementa que existe uma VLAN exclusiva para o OpenShift de produção.

00:09:01 Carlos Andre: Apresenta o problema central: a maioria dos serviços que estão dentro do OpenShift, incluindo o Sigode e os pods do ADMS, conecta-se ao Kafka utilizando a rota, e não o Service.

00:09:29 Carlos Andre: Explica o percurso resultante: ao usar a rota, a requisição sai do cluster, alcança o DNS que aponta para o F5, atravessa o API Gateway, que é externo ao OpenShift, e retorna ao cluster, passando também pelo firewall.

00:10:10 Carlos Andre: Informa que o API Gateway estava sendo configurado como pods dentro do OpenShift nos ambientes de desenvolvimento, arranjo que ainda não havia sido levado à produção, e que a equipe do gateway é a mesma do barramento.

00:10:18 Carlos Andre: Avalia que o caminho atual produz perda expressiva de latência e de performance, informa que a mudança para Service já foi solicitada às equipes de aplicação e classifica o ponto como crítico e necessário.

00:10:50 Castellani: Solicita confirmação sobre quais componentes utilizam a rede interna e quais saem do cluster.

00:11:29 Castellani: Pergunta se produtores e consumidores apresentam o mesmo comportamento.

00:11:33 Carlos Andre: Esclarece que a comunicação entre os componentes internos ocorre por Service e que o desvio se concentra nas aplicações consumidoras que buscam informação no Kafka.

00:12:20 Castellani: Pergunta se os endpoints utilizados estão em propriedades de configuração ou fixos no código-fonte.

00:12:38 Carlos Andre: Responde que provavelmente estão em variáveis de ambiente, quando não estiverem no código, e passa a inspecionar o cluster para verificar.

00:12:50 Carlos Andre: Identifica ao vivo uma API de atendimento configurada para acessar outra API por rota, demonstrando que o padrão não está restrito ao Kafka.

00:13:27 Carlos Andre: Identifica também o Schema Registry sendo acessado por rota.

00:13:32 Carlos Andre: Confirma que encontrou casos em variáveis de ambiente, não descarta valores fixos em código e classifica o ponto como melhoria crítica a ser corrigida.

00:13:41 Castellani: Registra que essa foi a primeira pergunta feita no início do assessment e que a informação anterior era de que todo o tráfego permanecia interno ao cluster, o que a demonstração não confirma.

00:14:18 Carlos Andre: Passa ao armazenamento: a StorageClass do barramento utiliza driver CSI do ambiente de virtualização.

00:14:37 Carlos Andre: Levanta a suspeita de que a política de storage aplicada, associada a um esquema de paridade, esteja prejudicando a performance, observa que a mudança sem perda de dados seria complexa e avalia que a configuração foi o padrão adotado na época.

00:15:11 Carlos Andre: Descreve que os dados são gravados como discos virtuais no datastore do ambiente hiperconvergente, que todos os componentes utilizam a mesma StorageClass e que não há uso de object storage para retenção histórica.

00:15:53 Carlos Andre: Informa que a virtualização é hiperconvergente Dell VxRail, em versão 8.0.3.330, com atualizações já em tratativa com o fornecedor, e descreve o modelo de pool de discos e datastore.

00:17:06 Carlos Andre: Relata que a equipe do barramento está tentando separar os conectores: hoje existem quatro a cinco pods de conector em produção e todos os fluxos se conectam a eles.

00:17:50 Carlos Andre: Detalha a proposta de conjuntos dedicados de conectores por grupo de workloads, com nomenclatura própria, motivada pelo porte crescente dos projetos e pelo fato de o ADMS não ser o único sistema conectado ao barramento.

00:18:40 Carlos Andre: Mostra que em homologação já existe um conjunto apartado, com StatefulSet próprio, e informa que o detalhamento interno depende da equipe do barramento.

00:19:46 Carlos Andre: Registra que os ambientes não produtivos não reproduzem a separação nem a quantidade de nodes de produção.

00:20:10 Carlos Andre: Explica que componentes são ativados apenas para teste e depois desativados, em razão do licenciamento do OpenShift e da Confluent.

00:20:32 Castellani: Sugere avaliar o uso de edição open source do Kafka nos ambientes de desenvolvimento para reduzir custo de licenciamento nos testes.

00:21:04 Carlos Andre: Registra a ressalva de que uma configuração ou funcionalidade validada em edição diferente da utilizada em produção pode gerar impacto posterior.

00:21:47 Carlos Andre: Descreve a topologia de entrada: três infra nodes por cluster, onde rodam os routers.

00:22:05 Carlos Andre: Explica que um endereço da infraestrutura interna, externo à VLAN do OpenShift, foi configurado como VIP no F5, com um pool formado pelos três infra nodes.

00:22:50 Carlos Andre: Demonstra que a resolução de qualquer endereço de API do cluster, do barramento ou do Kafka retorna o endereço de entrada do F5, que redireciona para os infra nodes.

00:23:31 Carlos Andre: Descreve o modelo de liberação no firewall: a faixa de IP do OpenShift é liberada quando o cluster é origem e precisa alcançar bancos ou outros destinos externos.

00:24:06 Carlos Andre: Reforça que o acesso externo a rotas, front-ends e APIs ocorre pelo endereço do VIP e conclui que diversas aplicações utilizam a rota sem necessidade, porque poderiam alcançar o destino internamente.

00:24:48 Carlos Andre: Apresenta a esteira de DevOps, que concentra as atualizações e modificações dos componentes do barramento, com aprovação e publicação por pipeline.

00:25:10 Carlos Andre: Informa que a atualização do operador foi conduzida diretamente, já aplicada em desenvolvimento e homologação, na penúltima versão disponível.

00:25:28 Carlos Andre: Explica a decisão pela penúltima versão como forma de evitar defeitos de uma release muito recente, e informa que os componentes foram alinhados a versões compatíveis com o operador e com o OpenShift, para permanecer em suporte e reduzir vulnerabilidades. A atualização de produção segue pendente.

00:26:46 Castellani: Pergunta se, mesmo sem estar no último nível de atualização, o ambiente está em um patamar adequado.

00:27:06 Carlos Andre: Responde que o operador estava bastante desatualizado e que os componentes foram implantados e não recebiam atualização havia muito tempo.

00:27:58 Carlos Andre: Consulta o inventário e indica a evolução do operador de uma versão anterior para a atual, com numeração a ser confirmada nos manifestos.

00:32:26 Castellani: Pergunta se o Kafka é o único componente responsável pelo consumo elevado no ambiente ou se existem outros.

00:32:43 Carlos Andre: Responde que o ambiente é muito grande, com muitas APIs e da ordem de três mil a três mil e duzentos pods, e que o barramento tornou-se um componente de grande porte.

00:33:30 Carlos Andre: Apresenta o cálculo verbal dos cores dos nodes dedicados ao Kafka e ao Connect, concluindo que o licenciamento do OpenShift correspondente é elevado, além dos cerca de 26 nodes destinados aos demais workloads.

00:34:50 Carlos Andre: Relata que a entrada do Kafka aumentou de forma expressiva a gravação em disco e passou a onerar o ambiente de virtualização, que hospeda outros workloads em paralelo, e resume o conjunto como a preocupação central de arquitetura.

00:35:37 Castellani: Retoma o ponto discutido em sessão anterior: rotinas que leem cerca de cem mil registros, transformam cada um em evento e publicam no barramento configuram, na prática, uma integração ponto a ponto de natureza de carga e transformação, que não precisaria atravessar o Kafka.

00:36:06 Carlos Andre: Complementa com informação adicional: projetos de BI estão solicitando a publicação de tabelas de porte muito grande no barramento, o que preocupa as equipes que sustentam o ambiente.

00:36:53 Hugo: Esclarece que os destinos são a plataforma de dados da Energisa e o Databricks, hospedados em nuvem.

00:37:15 Carlos Andre: Reforça que os pedidos são de volumes elevados, tabela sobre tabela, sem limite, e avalia que é o momento de rever a arquitetura, em razão do crescimento acelerado.

00:37:41 Castellani: Pergunta se o projeto da plataforma de dados tem natureza de tempo real.

00:37:52 Carlos Andre: Registra que esse ponto precisa ser melhor compreendido.

00:37:57 Hugo: Pergunta se o fluxo realmente passa pelo Kafka e observa que o dado precisa estar na nuvem, não necessariamente no barramento.

00:38:10 Castellani: Explica que o desenho utiliza Debezium para capturar as alterações e publicar no Kafka, de onde o conteúdo segue para a outra estrutura, e que isso gera volume elevado trafegando pelo barramento.

00:38:40 Castellani: Apresenta a alternativa: utilizar conector nativo do próprio banco relacional com a nuvem, que já realiza a captura, sem intermediação do barramento.

00:39:05 Hugo: Registra que acreditava que a integração ocorresse por um serviço de integração gerenciado e que não sabia que o fluxo passava pelo Kafka.

00:39:16 Castellani: Reforça a pergunta a ser formalizada: se todo o fluxo precisa ser em tempo real, uma vez que processos de periodicidade diária poderiam ser atendidos por carga e transformação, sem consumo elevado de recursos.

00:39:48 Carlos Andre: Concorda e reforça que, no ritmo das solicitações atuais, não há limite previsível de crescimento.

00:39:58 Carlos Andre: Informa a volumetria de storage do barramento, na ordem de três clusters com capacidade de dois terabytes e meio cada, com ocupação parcial.

00:40:18 Carlos Andre: Relata que não consegue realizar backup do ambiente: nenhuma ferramenta obtém o backup sem parada, porque não há janela para interromper o Kafka e o snapshot não se completa. Informa que uma prova de conceito estava em andamento e que o teste com a solução do próprio ecossistema OpenShift também não funcionou.

00:40:42 Castellani: Explica que, para eventos, a estratégia adequada não é backup convencional, e introduz o conceito de persistência de eventos: além da saída para o consumidor, uma segunda saída grava o evento em object storage.

00:41:16 Carlos Andre: Registra que esse mecanismo não existe hoje e que, na situação atual, a perda do ambiente implica perda dos eventos.

00:41:22 Castellani: Detalha o ganho do Event Store: comprimir o evento, gravá-lo em formato analítico no object storage, manter ciclo de vida longo e reduzir o tempo de retenção no Kafka.

00:42:01 Carlos Andre: Informa não saber qual é a política de retenção praticada nos tópicos.

00:42:13 Castellani: Explica que, sem Event Store, a tendência é manter retenção longa e storage maior no barramento, e que com o repositório histórico a retenção pode cair para dias, com reidratação e republicação quando for necessário replay.

00:42:47 Carlos Andre: Avalia a estratégia como adequada e registra que pode entrar no escopo das melhorias, uma vez que hoje não existe.

00:43:00 Carlos Andre: Descreve a situação da recuperação de desastre: existe um segundo cluster OpenShift, que não é ativo-ativo, e a intenção é instalar o operador e subir os componentes com volumes vazios, sem que haja mecanismo definido para os dados.

00:43:23 Carlos Andre: Registra a ausência de ferramenta de replicação e a busca por alternativas para obter ao menos um nível mínimo de recuperação.

00:43:40 Carlos Andre: Afirma que hoje não há backup nem recuperação de desastre e que, em caso de perda do site principal, o ambiente secundário não está pronto para assumir.

00:43:49 Castellani: Registra a situação como risco.

00:44:05 Carlos Andre: Informa que desistiu da linha de backup convencional após testar três ferramentas distintas e que, em conversa posterior com um arquiteto da Red Hat, confirmou que a arquitetura de gravação contínua do Kafka é incompatível com essa abordagem.

00:44:30 Castellani: Detalha o particionamento do Event Store por data e hora, com intervalos que podem chegar a quinze minutos conforme o volume, permitindo backup das partições que não estão mais em uso.

00:45:16 Castellani: Registra que essa é a razão da pergunta inicial sobre a existência de object storage no ambiente.

00:45:30 Carlos Andre: Informa que existe object storage criado no ambiente, originalmente para apoiar as tentativas de backup, e que optou por instalar um MinIO em servidor Linux próprio, no data center da Paraíba, para não manter o dado e a cópia no mesmo ambiente. O servidor é utilizado nas provas de conceito em andamento.

00:46:16 Carlos Andre: Avalia que a alternativa de Event Store deveria ter sido levantada antes e considera a discussão uma oportunidade relevante.

00:46:42 Carlos Andre: Sugere envolver as áreas responsáveis pelas aplicações em uma nova rodada e informa que a própria equipe tem uma entrega em andamento, um estudo sobre a separação do barramento e as melhorias associadas, que converge com o assessment.

00:47:23 Hugo: Coloca a equipe à disposição para dúvidas por mensagem ou contato direto.

00:47:28 Carlos Andre: Autoriza contato direto e oferece acesso ao ambiente para coleta de evidências.

00:47:43 Castellani: Explica a fase atual do trabalho: levantamentos, compilação e encaminhamento à coordenação, com foco no barramento.

00:48:14 Castellani: Apresenta o objetivo técnico de reduzir a quantidade de tópicos, de eventos enviados ao barramento e, em consequência, de recursos consumidos.

00:48:31 Castellani: Descreve o caso observado em outra frente: sete tópicos para a mesma entidade, um por status, quando um único tópico com tipo de evento atenderia, e uma aplicação que recebe o evento original, quebra-o em sete e republica, multiplicando os eventos sem necessidade.

00:49:55 Carlos Andre: Relata a percepção da equipe sobre o reinício do ambiente: em mais de uma atualização, e também em outras intervenções, o barramento foi impactado.

00:50:24 Carlos Andre: Descreve o efeito nas aplicações consumidoras do ADMS e do Sigode, que retêm a fila e demoram a perceber o retorno da dependência, e levanta a dúvida sobre a causa estar na aplicação ou na arquitetura.

00:50:56 Carlos Andre: Avalia que uma aplicação hospedada na plataforma de contêineres deveria ser mais resiliente e reconectar-se automaticamente após um reinício.

00:51:00 Castellani: Confirma o entendimento do cenário: a dependência é derrubada e recomposta, e as aplicações demoram a retomar o consumo.

00:51:24 Carlos Andre: Confirma que, em diversos casos, é necessário reiniciar os pods manualmente para que voltem a consumir em velocidade adequada.

00:51:41 Carlos Andre: Explica o impacto operacional: os centros de operação dependem da informação em tempo real e, em janelas de muitas ocorrências, percebem e reportam o atraso de imediato, porque a nova geração da solução entrega os dados praticamente em tempo contínuo, diferentemente do sistema anterior.

00:52:14 Castellani: Caracteriza o tratamento adequado como disjuntor: a aplicação abre o circuito ao perceber a indisponibilidade, tenta em intervalos progressivos e retoma automaticamente quando a dependência é restabelecida.

00:52:52 Carlos Andre: Levanta a hipótese de que o problema também esteja relacionado ao uso da rota em lugar do Service.

00:53:01 Castellani: Concorda que a hipótese é plausível e observa que, além da sobrecarga no barramento, existe impacto no tempo de resposta da aplicação.

00:53:19 Carlos Andre: Confirma o efeito de acúmulo progressivo e que essa é exatamente a reclamação recebida da operação.

00:53:55 Carlos Andre: Encerra a gravação e informa que a encaminhará à coordenação do assessment.

Anexo B · Termos normalizados e valores que exigem confirmação

A sessão foi registrada por transcrição automática, que capturou de forma imprecisa parte dos nomes de produtos, componentes e parâmetros. Nesta ata, os componentes foram descritos preferencialmente por sua função, e os termos abaixo são registrados para confirmação na documentação técnica e no inventário do ambiente.

OpenShift 4.20.24 e 4.21	Versões de produção e de ambientes não produtivos.	O patch dos ambientes não produtivos não foi identificado na sessão.
CFK	Operador Confluent for Kubernetes, responsável pelo ciclo de vida dos componentes.	A evolução citada, de uma versão 2.9.3 para 3.2.3, precisa ser confirmada nos manifestos.
KRaft	Mecanismo de consenso e metadados do Kafka, em node dedicado.	Substitui o coordenador externo em versões recentes. Topologia a confirmar.
ksqlDB e Flink	Processamento de streaming atual e alternativa proposta pela Confluent.	Migração é hipótese de evolução, sem decisão registrada.
Machine Config Pool	Mecanismo utilizado para segregar nodes e aplicar configurações específicas.	Parâmetro de limite de processos ajustado nos nodes dedicados a confirmar.
VxRail e VMware 8.0.3.330	Ambiente hiperconvergente que sustenta o cluster.	Versão informada verbalmente, a confirmar no inventário.
Política de storage com paridade	Suspeita de configuração inadequada da StorageClass para carga de escrita intensiva.	O termo capturado sugere um esquema do tipo RAID 6. Hipótese a validar.
Object storage disponível	Capacidade do OpenShift Data Foundation e MinIO em servidor Linux na Paraíba.	O MinIO é experimental, utilizado em provas de conceito.
Ferramentas de backup testadas	Três ferramentas distintas, entre elas a solução de proteção de dados do ecossistema OpenShift e uma ferramenta de terceiros.	A identificação da terceira ferramenta e os resultados formais devem ser registrados.
Plataforma de dados e Databricks	Destinos das cargas solicitadas ao barramento.	Nomenclatura oficial dos projetos a confirmar.
Nova geração da solução de operação	Referida na sessão como a versão que entrega dados com latência muito menor.	A transcrição alterna entre ADMS e Sigode nessa referência. A denominação correta deve ser confirmada.
Volumetria do barramento	Três clusters Kafka com capacidade da ordem de dois terabytes e meio cada.	Números citados de memória durante a demonstração, a extrair do inventário.

1.11.21. Observações finais

Esta ata foi consolidada a partir de dois documentos referentes à mesma sessão: o relatório técnico detalhado produzido sobre a reunião e a transcrição integral da gravação. A unificação permitiu confirmar a atribuição nominal das falas, que no documento de trabalho original havia sido substituída por papéis funcionais em razão da ambiguidade do reconhecimento automático de voz, e recuperar elementos que não constavam do relatório, entre eles as três ferramentas de backup testadas e a validação com o fornecedor da plataforma, a hipótese específica sobre a política de storage, a localização e a motivação do object storage utilizado nas provas de conceito, o cálculo verbal dos cores dedicados e o estudo interno sobre separação do barramento já em andamento.

As classificações de criticidade, os níveis de risco e os prazos do plano de ação têm caráter indicativo. Vários números apresentados foram citados de memória durante a demonstração no cluster e estão relacionados no item 1.11.19 para confirmação por inventário. A equipe de plataforma ofereceu acesso ao ambiente para essa coleta, o que deve ser priorizado antes da consolidação das recomendações no capítulo de arquitetura-alvo.