Ata 05 · Sensedia, F5, Kafka e CDC e Integrações ADMS (10 de julho de 2026)

Ata unificada, consolidada a partir da ata formal da reunião, da compilação técnica por temas e da transcrição cronológica revisada do encontro.

Data	10 de julho de 2026
Horário de início	10h32 (America/Sao_Paulo)
Duração do conteúdo falado	Aproximadamente 61 minutos
Natureza	Sessão técnica de levantamento e assessment
Escopo	API Management, F5, site switch, CDC, Kafka Connect, integrações síncronas e governança
Gravação	Vladimir Morozowski de Sousa
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Status	Diagnóstico preliminar sujeito a validação técnica
Fontes	Ata formal da reunião, compilação técnica por temas e transcrição cronológica revisada

Nota de consolidação das fontes Esta ata unifica três documentos produzidos sobre a mesma sessão: a ata formal, a compilação técnica por temas e a transcrição cronológica revisada. O conteúdo temático segue a estrutura da compilação, os nomes completos dos participantes vêm da ata formal e o registro cronológico integral consta no Anexo B. Há divergência de registro quanto à duração: o metadado da gravação informa término às 11h54min49s, enquanto o último trecho falado disponível aparece em 01:00:56 e já contém o encerramento formal. A diferença pode representar período sem fala, gravação mantida aberta ou inconsistência do metadado.

Índice desta ata

1. Sumário executivo
2. Participantes, objetivo e método de levantamento
3. Arquitetura de integração observada
4. Uso do Sensedia como API Gateway e API Management
5. Ciclo de vida, catálogo e governança de APIs
6. Transformações XML e JSON e responsabilidade de integração
7. Esteira CI e CD, deploy manual e oportunidade de IaC
8. Monitoramento e observabilidade no Sensedia
9. Arquitetura F5: VIPs, pools, membros e health monitors
10. Site switch do ADMS entre Minas e Paraíba
11. CDC com Kafka Connect, Debezium e SQL Server
12. Padrões síncronos SOAP e XML e impactos de volumetria
13. Filas, DLQ, serviço ONT e resiliência
14. Nomenclatura e documentação operacional
15. Achados, riscos e impactos
16. Recomendações arquiteturais
17. Plano de ação priorizado
18. Matriz de decisões e pendências
19. Perguntas para as próximas reuniões
20. Conclusões da fase inicial do assessment

• Anexo A: glossário técnico
• Anexo B: registro cronológico da sessão
• Anexo C: trechos e termos que exigem validação

1.6.1. Sumário executivo

Diagnóstico central O ambiente está funcional, porém a continuidade operacional depende de procedimentos manuais e de sinais de saúde insuficientes para distinguir servidor disponível de aplicação efetivamente ativa. A maior prioridade é transformar o site switch do ADMS e o reapontamento do CDC em processos determinísticos, monitoráveis, testáveis e, quando tecnicamente possível, automatizados.

A reunião integrou o assessment mais amplo das integrações do ADMS e concentrou-se nos papéis do Sensedia, do F5, do Kafka Connect com CDC, do OpenShift e das aplicações intermediárias.

• O Sensedia é utilizado principalmente como gateway e proxy, mas também fornece catálogo, planos de acesso, rate limiting, interceptors, roteamento e transformações de formato em alguns fluxos.
• O ciclo de publicação no gateway é separado do CI e CD das aplicações. A equipe de desenvolvimento envia especificações e abre chamados; a equipe da plataforma configura e publica manualmente.
• O F5 monitora principalmente disponibilidade de porta. Esse sinal não é suficiente para determinar qual instância do ADMS está logicamente ativa após um site switch.
• O site switch entre Minas e Paraíba exige coordenação manual entre aplicação, F5, Citrix e VMs e operação. O risco aumenta em ocorrências noturnas e fora do horário normal.
• O conector CDC acessa o SQL Server do ADMS por F5 e VIP e não passa pelo Sensedia. Em um failover real, o ADMS seguiu operando, mas os dados derivados do CDC ficaram congelados, indicando falha de reapontamento ou reconexão.
• As integrações síncronas em SOAP e XML podem sofrer com payloads muito grandes, especialmente quando incidentes envolvem centenas de milhares de unidades consumidoras.
• A convenção de nomes dos VIPs facilita troubleshooting, mas permanece tácita e deve ser formalizada.

1.6.2. Participantes, objetivo e método de levantamento

Participaram da reunião os profissionais relacionados a seguir. Os papéis foram inferidos a partir da atuação registrada na transcrição.

Norberto da Silva Prado	Energisa	Ponto focal técnico do assessment; explica contexto, integrações, dores e a agenda das entrevistas
Vinicius Batista Peçanha	Energisa	Participação técnica no levantamento
Ghullite Tacone Bento (citado como Gullit)	Energisa	Equipe responsável por Sensedia e F5; demonstra API Gateway, monitoramento, VIPs, pools, health monitors e a operação de site switch
Thiago da Silva Andrade	Energisa	Equipe Sensedia e API Gateway; apoia a administração da plataforma e participa do levantamento
Vladimir Morozowski de Sousa	Digital Solutions e Syntropy Labs	Consultoria; abre a reunião e contextualiza o trabalho
João Carlos Franco Castellani	Digital Solutions e Syntropy Labs	Arquiteto consultivo; conduz as perguntas de arquitetura, governança de APIs, CI e CD, health checks e resiliência

1.6.2.1. Objetivo

Levantamento inicial e entendimento do ambiente Sensedia API Gateway e F5 Load Balancer utilizados no ecossistema ADMS, como parte do assessment conduzido pela Syntropy Labs para identificação de oportunidades de melhoria, riscos operacionais, evolução arquitetural e pontos de atenção. De forma específica, compreender a arquitetura atual, as dores e as oportunidades envolvendo Sensedia, F5, failover e site switch, CDC e integrações do ADMS.

1.6.2.2. Contexto e método de levantamento

A avaliação foi motivada pela necessidade de revisar, de forma ponta a ponta, a arquitetura de integração utilizada pelo ADMS após sua implantação e evolução operacional. O objetivo da consultoria é entrevistar todas as equipes envolvidas, abrangendo Infraestrutura, Middleware, Desenvolvimento e Operação, para obter uma visão completa do ambiente, identificando gargalos, riscos, oportunidades de automação e melhorias arquiteturais.

• A necessidade surgiu após a primeira implantação do ADMS, quando foram observadas dores e questões de integração.
• A abordagem definida é construir primeiro uma visão ponta a ponta e, depois, aprofundar as dores em cada componente e mesa de desenvolvimento.
• Foram planejadas sessões específicas com Kafka e Confluent, Sensedia e F5, GIS com SFTP e as equipes responsáveis pelos middlewares e integrações.
• O assessment deve distinguir os papéis de mensageria, gateway, balanceamento, transformação, aplicação e banco, evitando sobreposição de responsabilidades.

1.6.3. Arquitetura de integração observada

Fluxo de API síncrona Serviço ou middleware, VIP do F5 associado ao Sensedia, Sensedia e API Gateway, VIP do F5 do ambiente de backend, servidor ou adaptador do ADMS.

Fluxo CDC Kafka Connect com Debezium, VIP e F5, SQL Server do ADMS, captura CDC, tópico Kafka, consumidores internos no OpenShift.

• O ambiente ADMS opera integralmente on-premises e as APIs internas não são expostas diretamente à internet.
• Consumidores dentro do OpenShift tendem a se comunicar internamente; as chamadas ao ADMS utilizam gateway e F5.
• O CDC não utiliza o Sensedia, pois o conector acessa diretamente o banco por meio de VIP e F5.
• As integrações apresentam perfis distintos: alto número de eventos pequenos, menor frequência com payloads grandes e mensagens divididas em chunks.
• Foi citada como exemplo uma integração ligada ao OMS que recupera incidentes já arquivados e também as unidades consumidoras afetadas, elevando o volume, o que motivou a divisão da mensagem em chunks.
• O F5 atua como camada de distribuição de tráfego entre os componentes do ADMS, com componentes ativos em Minas Gerais e na Paraíba e chaveamento entre ambientes realizado de forma controlada e manual.

1.6.4. Uso do Sensedia como API Gateway e API Management

• Uso predominante como gateway e proxy para receber, autenticar, controlar e encaminhar requisições.
• Consumo realizado exclusivamente de forma interna, sem exposição direta à internet.
• Autenticação baseada em Client ID e Client Secret.
• Uso de interceptors para roteamento condicionado por empresa ou contexto. Foi citado um caso específico, associado ao QS, em que a plataforma é usada também para gerenciamento e roteamento condicionado, com um interceptor direcionando a solicitação para servidores diferentes conforme a empresa ou o contexto recebido.
• Aplicação de exceções, políticas e proteções solicitadas pelo escritório de segurança.
• Catálogo de APIs, API Design, planos de acesso, ambientes permitidos e rate limit. Foi demonstrada a configuração de plano de acesso com ambiente de homologação ou produção e limite exemplificado em até mil requisições por minuto.
• Monitoramento de operações, volume, erros e duração média.
• Transformação entre XML e JSON em alguns fluxos, mas não de forma uniforme nos dois sentidos.
• O backend é cadastrado por ambiente, incluindo homologação e produção, com o fluxo de encaminhamento montado na própria plataforma.

1.6.5. Ciclo de vida, catálogo e governança de APIs

• Os desenvolvedores consultam a documentação do catálogo, porém não cadastram diretamente novos endpoints.
• Para publicar ou alterar uma API, a equipe de desenvolvimento abre chamado e informa endpoint, URL e backend.
• A equipe da plataforma configura o fluxo e cria revisões no Sensedia. Quando é necessário adicionar um endpoint, não se altera diretamente a versão publicada: gera-se uma nova revisão e realiza-se o deploy mediante processo de mudança.
• Existe versionamento manual: a equipe cria uma nova revisão e direciona os consumidores para a nova versão.
• Quando necessário, é possível retornar a uma revisão anterior por Revision Management, selecionando a versão anterior e executando novo deploy.
• Esse tipo de retorno já ocorreu em canais digitais, que possuem maior utilização, sem casos relevantes recordados no ADMS.
• Quebras de contrato não foram apontadas como dor recorrente no ADMS, mas existem riscos porque as validações não estão acopladas ao pipeline. A equipe de mudança e os desenvolvedores podem conhecer casos não visíveis para o time do gateway.
• O mock é mais usado no início do desenvolvimento, quando a API ainda não está pronta; a prática fica com a equipe de desenvolvimento e nem sempre permanece na fase de homologação.

Oportunidade de governança Adotar lint e políticas de compatibilidade de contratos OpenAPI, com regras semelhantes às oferecidas pelo Spectral: versionamento obrigatório, proibição de remoção incompatível de campos e parâmetros, validação de nomenclatura e bloqueio do pipeline antes do deploy. Ao detectar remoção de parâmetro ou quebra de contrato, o pipeline deveria emitir alerta, recusar a execução e exigir correção na pull request antes do deploy.

1.6.6. Transformações XML e JSON e responsabilidade de integração

• O ADMS disponibiliza adaptadores e Web Services baseados em SOAP e XML.
• O ecossistema interno da Energisa utiliza JSON em diversas integrações.
• Interceptores do gateway executam conversão em alguns sentidos, com exemplo demonstrado na sessão.
• A transformação ocorre somente em uma direção em determinados fluxos; no caminho inverso, a aplicação realiza a conversão.
• A ideia original, discutida com a Sensedia, era fazer toda a conversão na plataforma, mas a implementação encontrou limitações ou incompatibilidades práticas ao tentar usar o interceptor em ambos os sentidos, exigindo que parte da transformação permanecesse na aplicação.
• A arquitetura deve formalizar onde cada transformação ocorre, evitando duplicidade, assimetria e dependência oculta.

Questão de arquitetura levantada na sessão Foi discutido se o gateway atua apenas como proxy ou também como camada anticorrupção entre domínios com linguagens diferentes, por exemplo quando um domínio chama a entidade de cliente e outro a representa como pessoa física ou jurídica. A resposta indicou que, na maior parte dos fluxos, o gateway recebe e repassa o payload ao backend, existindo porém APIs com alguma tradução.

1.6.7. Esteira CI e CD, deploy manual e oportunidade de IaC

O fluxo atual segue três etapas: o desenvolvimento cria ou altera a API, envia a documentação ao time Sensedia e a equipe Sensedia realiza o cadastro e a publicação.

• O CI e CD da aplicação e o deploy do gateway são processos separados. O CI e CD do desenvolvimento publica a aplicação, depois é aberto um chamado e a equipe de Sensedia cria ou altera manualmente a API.
• Portanto, o deploy do gateway está fora da esteira de CI e CD da aplicação, com os desenvolvedores atuando como clientes da equipe da plataforma.
• Isso aumenta lead time, dependência de equipe especializada e possibilidade de divergência entre aplicação e contrato publicado.
• Em uma esteira integrada, o mesmo pipeline poderia publicar a API e aplicar as validações automaticamente.
• Existe iniciativa paralela corporativa de Infrastructure as Code que deve ser avaliada para incorporar APIs, políticas, planos, interceptors e configurações de F5. Norberto comprometeu-se a verificar com a equipe do projeto se o Sensedia e o API Gateway estão incluídos no escopo.

1.6.8. Monitoramento e observabilidade no Sensedia

O Sensedia é utilizado para monitoramento operacional das APIs do ADMS, com recursos para acompanhar documentação, operações e endpoints consumidos, quantidade de requisições, erros e duração média das operações. A equipe informou possuir boa visibilidade operacional através dos recursos analíticos da ferramenta.

• A plataforma exibe volume de chamadas, endpoints consumidos, erros e duração média, além de latência e tempo médio de resposta.
• A ausência de tráfego pode indicar indisponibilidade do backend, mas é um sinal indireto e tardio. Se o backend parar, as chamadas no Sensedia deixam de ser entregues e a volumetria monitorada apresenta uma lacuna visível.
• Para troubleshooting ponta a ponta, recomenda-se correlacionar request ID, evento Kafka, chamada síncrona, resposta do ADMS, DLQ e atualização dos consumidores.
• Muitos erros tendem a ocorrer no nível da aplicação, e não do gateway; o monitoramento da plataforma permite analisar as falhas.

1.6.9. Arquitetura F5: VIPs, pools, membros e health monitors

• VIPs recebem conexões e encaminham para pools de servidores. O caminho básico demonstrado: o API Gateway recebe a solicitação de um cliente, encaminha ao F5, e o F5 direciona para o servidor de destino, sem passar pelo firewall de borda nesse fluxo interno.
• Existe um VIP dedicado para a integração no ambiente G3.
• O VIP demonstrado é simples, sem policy específica, e trabalha em modo standard como balanceador e proxy.
• O F5 trata a conexão, aplica os parâmetros necessários e encaminha para um pool. O pool possui monitor configurado, que verifica uma porta do servidor e determina se o membro está ativo. Sem o monitor, o VIP não opera corretamente.
• O pool possui membros principal e secundário; o secundário permanece desabilitado fora de manutenções ou contingências. O membro secundário citado está na Paraíba e o principal no datacenter associado ao ambiente de Minas Gerais.
• Na prática, o pool não funciona como Round Robin, porque somente o membro principal fica habilitado. O tráfego observado é muito maior no servidor principal.
• Existem membros antigos remanescentes da implantação, criados quando ainda não estava definido qual seria o principal, que devem ser revisados e removidos mediante processo de mudança. Eles não alteram o funcionamento atual.
• O health monitor atual observa principalmente a disponibilidade da porta 443, verificando o backend que receberá a chamada.
• Porta ativa não garante que a aplicação esteja saudável nem que o servidor esteja no papel primário. Se o servidor desligar ou falhar de forma evidente, o monitor detectará; porém, uma falha lógica da aplicação pode não ser identificada.
• Procedimento de manutenção descrito: para atualizar um servidor, as conexões são direcionadas ao secundário, atualiza-se o principal e depois as conexões retornam.

1.6.10. Site switch do ADMS entre Minas e Paraíba

Este foi o principal tema discutido durante a reunião.

Situação atual A equipe do ADMS altera manualmente o ambiente ativo. Em seguida, comunica a equipe de F5, que desabilita o membro anterior e habilita o secundário. Outras equipes, como as responsáveis por Citrix e VMs, também participam da operação, em atuação coordenada em salas técnicas.

1.6.10.1. Cenário e sequência atual

1. A equipe da aplicação realiza o chaveamento do ADMS.
2. A equipe responsável pelo F5 realiza manualmente a alteração dos pools e destinos de tráfego, desabilitando o membro atual e habilitando o secundário.
3. O processo depende de interação humana entre múltiplas equipes e da confirmação prévia da equipe de aplicação.

1.6.10.2. Limitação técnica central

• A aplicação não sinaliza automaticamente ao F5 que o ambiente ativo mudou.
• O servidor que deixou de ser primário pode continuar respondendo na porta 443, ou seja, a aplicação pode ter mudado seu papel lógico sem desligar a porta.
• Para o F5, ambos os servidores continuariam saudáveis. Se os dois membros estivessem habilitados, o balanceador poderia considerar ambos aptos e distribuir chamadas incorretamente.
• Por isso, a equipe do F5 precisa desabilitar explicitamente o membro anterior para que o novo servidor passe a receber conexões.
• A automação exige um sinal técnico confiável de papel ativo ou readiness da aplicação.

1.6.10.3. Riscos identificados

• Dependência de atuação manual e de equipe preparada e coordenada, envolvendo F5, Citrix e VMs e equipe da aplicação.
• Necessidade de acionamento de equipes de plantão, com risco elevado em um site switch noturno.
• Maior tempo de recuperação em situações emergenciais.
• Potencial atraso em processos de contingência fora do horário comercial.

1.6.10.4. Solução candidata discutida

Endpoint de health e papel Disponibilizar endpoint de health e readiness que retorne HTTP 200 somente no nó apto a receber tráfego. O F5 deve validar status e, idealmente, conteúdo esperado, retirando automaticamente do pool o nó que não responder. O site switch deve alterar esse sinal de forma transacional, permitindo retirar o antigo primário e habilitar o novo sem balanceamento indevido. O endpoint poderia ser controlado por script ou arquivo.

• Foi levantada a alternativa de, no nível da aplicação, fazer a porta 443 deixar de responder durante a mudança, o que precisa ser discutido porque a manutenção pode ocorrer no servidor sem desligar a aplicação da forma esperada.
• Foi recordada uma ideia semelhante já discutida internamente, descrita como double check: validar um ponto e, se ele não responder, encaminhar ao outro membro.
• A consultoria concordou que a oportunidade central é automatizar monitoramento e failover, mantendo o procedimento manual apenas como contingência.
• Foi sugerido envolver a Schneider na análise do site switch, para compreender melhor os sinais disponíveis na aplicação.

1.6.11. CDC com Kafka Connect, Debezium e SQL Server

Existe um Kafka Connect dentro do ambiente Kafka. Esse conector usa o F5 para se conectar à base SQL Server do ADMS, captura as mudanças via CDC com Debezium, publica em tópico Kafka e outro componente consome o tópico. Nesse fluxo não existe Sensedia na frente do conector: o Sensedia é utilizado quando um serviço interno precisa chamar uma API externa ao seu ambiente, como nas chamadas ao ADMS.

• O acesso ao banco passa por VIP e F5, mas o objeto exato não foi identificado durante a reunião. A análise da nomenclatura sugeriu um VIP que parece direcionar diretamente para OpenShift, possivelmente relacionado ao próprio Confluent, o que explicaria a ausência de ação manual semelhante à do VIP do ADMS.
• Não foi recordada nenhuma ação de F5 para o fluxo Kafka durante a troca para a Paraíba.
• Em condições normais, a replicação do banco permite que o conector continue recebendo dados. Ocorreu, porém, um failover real em que a aplicação de Minas foi parada para manutenção.
• Nesse incidente não houve perda de dados, mas o fluxo ficou parado por um período. Os dashboards alimentados pelo CDC ficaram congelados, embora o ADMS continuasse operando no ambiente da Paraíba.
• A hipótese principal é que o conector manteve o apontamento para o banco anterior ou não reconheceu automaticamente o novo primário.
• É necessário validar connection string, listener, DNS e VIP, comportamento do driver JDBC, reconexão do Debezium, offsets e saúde do connector task.
• Ficou registrada a necessidade de levantar a documentação e identificar exatamente qual VIP, nome e fluxo atendem ao conector CDC, uma vez que o componente pode estar registrado com outra nomenclatura.
• O caso deve ser analisado ponto a ponto com a equipe do Kafka e Confluent.

1.6.12. Padrões síncronos SOAP e XML e impactos de volumetria

As chamadas ao ADMS são síncronas. Na concepção da solução, a Schneider disponibilizou adaptadores standard via SOAP e XML, sem alternativa assíncrona por outro protocolo. Existem middlewares no OpenShift que se comunicam com o ADMS, e essas integrações passam pela cadeia de gateway e F5.

• Em contingências, a quantidade de eventos e clientes pode crescer abruptamente.
• No retorno de incidentes, as mensagens podem carregar a lista de unidades consumidoras atingidas.
• Uma ocorrência de subestação pode envolver centenas de milhares de clientes, elevando payload, tempo de processamento e pressão sobre filas.
• Features recentes do ADMS melhoraram tempos de processamento que antes se aproximavam de uma hora, passando a concluir em poucos minutos em cenários de contingência, mas o comportamento em novos eventos extremos precisa ser testado.
• Foram recordados casos de contingência do COE, como eventos de chuva, em que os atendimentos demoravam. O nível atual de resiliência para um novo incidente extremo não é conhecido.

1.6.13. Filas, DLQ, serviço ONT e resiliência

• Foi citado um serviço identificado na transcrição como ONT, ainda sujeito a confirmação do nome, com reunião prevista com os responsáveis.
• A integração de abertura de reclamação para o OMS possuía fila única de processamento, diferentemente do Kafka, que permite particionamento e paralelismo. A fila única gerava gargalo.
• Melhorias foram implantadas, mas não se sabe se resolveram totalmente o problema; é necessário revalidar com a equipe.
• A dor do retorno pelo serviço ONT ainda existe: o processamento continua demorando em determinadas condições.
• Existe mecanismo de DLQ, porém o desenho, os critérios de retry, a retenção, o reprocessamento e o ownership devem ser detalhados com o desenvolvimento. A equipe de desenvolvimento deverá apresentar como o mecanismo funciona atualmente.
• O detalhamento da DLQ e da resiliência pertence à próxima fase do assessment, junto às equipes de desenvolvimento.

1.6.14. Nomenclatura e documentação operacional

• A nomenclatura dos VIPs contém informações úteis sobre ambiente, OpenShift, DMZ e tipo de backend. Prefixos e faixas permitem identificar recursos em OpenShift, DMZ, ambiente interno ou externo e tipo de servidor.
• Alguns nomes são legados e fogem ao padrão atual, refletindo decisões tomadas durante a implantação.
• A regra foi adotada operacionalmente pela equipe ao assumir a operação, para facilitar troubleshooting entre milhares de VIPs, mas não está formalizada em documento.
• Deve ser criado padrão oficial com glossário, exemplos, ownership e processo de exceção.

1.6.15. Achados, riscos e impactos

Site switch manual	Atraso ou erro humano na troca	Indisponibilidade e acionamento de plantão	Alta
Health check apenas por porta	Falso positivo de saúde	Tráfego enviado ao nó errado	Alta
CDC sem reapontamento comprovado	Connector parado após failover	Dashboards e consumidores congelados	Alta
Deploy do gateway fora do CI e CD	Divergência de contrato e configuração	Quebra de consumidores e retrabalho	Média
Payloads massivos síncronos	Timeout e fila saturada	Atraso em contingências	Alta
Fila única e serviço ONT	Baixo paralelismo	Gargalo de processamento	Média / alta
Nomenclatura tácita	Dependência de conhecimento pessoal	Troubleshooting lento	Média

1.6.16. Recomendações arquiteturais

1. Definir contrato de health e readiness do ADMS que represente papel ativo, saúde funcional e capacidade de receber tráfego.
2. Configurar monitor HTTP e HTTPS no F5 com validação de status e conteúdo, evitando depender apenas da porta 443.
3. Orquestrar o site switch e a alteração do health endpoint de forma transacional e auditável.
4. Executar prova de conceito de failover planejado e de failover abrupto, incluindo cenários noturnos e perda parcial de componentes.
5. Identificar o VIP e o mecanismo de conexão do Kafka Connect ao SQL Server; validar listener, DNS, connection string, driver, reconexão e offsets.
6. Criar monitoramento específico para connector e task do Debezium, lag, taxa de eventos e congelamento de tópicos e dashboards.
7. Integrar a publicação de APIs e políticas ao CI e CD e ao IaC, com lint de OpenAPI e regras de retrocompatibilidade.
8. Formalizar a responsabilidade das transformações entre XML e JSON e reduzir conversões dispersas entre gateway e aplicações.
9. Realizar teste de carga com incidentes de alta cardinalidade e payloads contendo grandes listas de clientes.
10. Documentar a convenção de nomes de VIPs, pools, membros, ambientes e recursos legados.

1.6.17. Plano de ação priorizado

0 a 15 dias	Mapear o fluxo real de site switch e de CDC; identificar VIPs, pools, connection strings e sinais disponíveis.	ADMS e Schneider, F5, Kafka e Confluent, DBA	Diagrama do estado atual validado
0 a 30 dias	Criar endpoint de health e papel e prova de conceito de monitor F5 com validação HTTP.	ADMS e Schneider, F5	Teste controlado com troca automática
0 a 30 dias	Reproduzir failover do SQL Server e observar Kafka Connect e Debezium.	Kafka e Confluent, DBA, F5	Relatório de teste e causa raiz
30 a 60 dias	Definir SLOs, alertas e runbook de site switch e CDC.	Operação, observabilidade e arquitetura	Dashboard, alertas e runbook aprovado
30 a 90 dias	Incluir o API Gateway na iniciativa de IaC e CI e CD e aplicar lint de contratos.	DevOps, Sensedia, desenvolvimento	Pipeline automatizado em homologação
30 a 90 dias	Executar testes de carga e resiliência para payloads massivos e fila do serviço ONT.	Desenvolvimento, ADMS, performance	Relatório de capacidade e plano de correção
0 a 60 dias	Formalizar a nomenclatura e o inventário dos VIPs.	Rede e F5, arquitetura	Padrão publicado e inventário revisado

1.6.18. Matriz de decisões e pendências

• Decidir qual componente é a fonte de verdade do papel ativo do ADMS.
• Decidir se o F5 executará failover automático ou somente automatizará a detecção e recomendará ação.
• Confirmar se o SQL Server possui listener ou endpoint único apropriado ao failover.
• Confirmar o VIP e a rota efetivamente utilizados pelo Kafka Connect.
• Definir o owner do conector CDC durante contingência.
• Definir política de retry, DLQ e reprocessamento das integrações síncronas.
• Confirmar o escopo da iniciativa de IaC para Sensedia e F5.
• Formalizar o padrão de nomenclatura e o plano de saneamento de objetos legados.

1.6.19. Perguntas para as próximas reuniões

• Qual endpoint ou estado interno do ADMS indica inequivocamente qual nó está ativo.
• O site switch pode alterar automaticamente um endpoint, arquivo ou flag consumível pelo F5.
• O F5 pode validar o corpo da resposta, e não apenas status ou porta.
• Qual é a topologia do SQL Server: Availability Group, replicação, listener, DNS ou VIP próprio.
• Qual connection string o Debezium usa e quais parâmetros de reconexão e failover estão configurados.
• O connector task reinicia sozinho, em quanto tempo, e há alerta de estado FAILED ou de ausência de eventos.
• Como offsets e schema history são preservados durante reinício e failover.
• Como a DLQ é implementada e quem autoriza o reprocessamento.
• Qual o maior payload já observado e quais timeouts existem em cada camada.
• Quais APIs do ADMS têm contrato versionado e quais ainda dependem de processo manual.

1.6.20. Conclusões da fase inicial do assessment

1.6.20.1. Ambiente considerado estável

• O ambiente Sensedia e F5 encontra-se operacionalmente estável.
• Não foram identificados problemas críticos ou riscos imediatos de arquitetura.
• Os mecanismos atuais de monitoramento oferecem boa visibilidade operacional.

1.6.20.2. Principais oportunidades observadas

1. Automação do processo de site switch e failover.
2. Evolução dos health checks para validações funcionais.
3. Integração do Sensedia ao pipeline de CI e CD.
4. Ampliação da governança de APIs.
5. Revisão dos fluxos de contingência e recuperação.
6. Validação da performance das integrações após as melhorias implementadas pela Schneider.

Anexo A · Glossário técnico

ADMS	Advanced Distribution Management System; plataforma integrada de operação da distribuição.
API Gateway	Camada de entrada que controla, protege e encaminha chamadas de APIs.
API Management	Gestão do ciclo de vida de APIs, incluindo catálogo, design, políticas, publicação e análise.
CDC	Change Data Capture; captura de alterações realizadas no banco.
Debezium	Conjunto de conectores para captura de mudanças em bancos e publicação em Kafka.
DLQ	Dead Letter Queue; fila para mensagens que não puderam ser processadas.
F5 e BIG-IP	Plataforma de entrega de aplicações, VIPs, pools, balanceamento e health checks.
Health check	Verificação usada para determinar se um membro pode receber tráfego.
IaC	Infrastructure as Code; configuração de infraestrutura por código versionado.
Kafka Connect	Framework Kafka para execução de conectores de origem e destino.
OpenShift	Plataforma Kubernetes empresarial usada para executar serviços e componentes.
Site switch	Troca operacional do ambiente ativo entre datacenters e sites.
VIP	Virtual IP; endereço lógico de entrada associado a um pool de backends.

Anexo B · Registro cronológico da sessão

Registro cronológico revisado do conteúdo inteligível da reunião. A sequência temporal, as perguntas, respostas, hipóteses e conclusões foram preservadas. Saudações, repetições, interjeições e trechos sem conteúdo técnico foram condensados. Termos reconhecidos de forma claramente incorreta foram normalizados. Os horários seguem a marcação da transcrição original, inclusive quando há pequena inversão de ordem na fonte.

00:00:01 Vladimir: Abre a reunião explicando que a consultoria está apoiando Norberto e a equipe na revisão da estratégia e dos componentes de integração. Informa que a empresa atua no Rio de Janeiro e possui experiência com grandes organizações.

00:00:18 Vladimir: Apresenta a experiência de João Castellani, destacando sua atuação anterior como gerente de arquitetura da TV Globo e o contato com ambientes que combinam tecnologia da informação e tecnologia operacional. Faz o paralelo com a Energisa, onde a engenharia e a operação possuem características distintas da TI corporativa tradicional.

00:00:53 Norberto: Explica que a necessidade do assessment surgiu a partir do próprio ADMS. Após a primeira implantação, apareceram questões e dores que motivaram uma reanálise ponta a ponta.

00:01:02 Norberto: Relata que apresentou a necessidade de uma consultoria em conversa com Valfre, com participação de Érica, e que foi assim que conheceu Vladimir e Castellani. Observa que Castellani já conhecia Érica de experiências anteriores.

00:01:31 Norberto: Esclarece que a revisão será geral. Desde o marco inicial, várias ações já evoluíram internamente, mas a consultoria deve primeiro construir uma visão ampla do ambiente, compreender as dores em cada ponta e depois aprofundar os pontos críticos.

00:02:15 Norberto: Justifica a reunião específica com as equipes de F5 e Sensedia. Informa que, no dia anterior, houve reunião com a equipe do Confluent Kafka e seus componentes e que outras reuniões serão realizadas com cada mesa de desenvolvimento e com os responsáveis pelas integrações.

00:02:36 Norberto: Cita uma reunião marcada para as 15h com a pessoa responsável pela integração do GIS, baseada em SFTP, e reforça que a solicitação é analisar ponta a ponta todas as integrações.

00:02:58 Vladimir: Ressalta que Kafka, Sensedia e F5 são elementos críticos e fundamentais na arquitetura de integração. Defende separar claramente o papel de cada componente, especialmente porque o domínio operacional pode produzir grande volumetria e eventos muito granulares.

00:03:27 Norberto: Explica que as integrações possuem perfis distintos. Algumas transportam payloads maiores, porém com menos requisições; outras possuem fluxo intenso de eventos, payloads pequenos e conectores que leem diretamente o banco.

00:03:48 Norberto: Cita como exemplo integrações de eventos e uma integração ligada ao OMS que recupera incidentes já arquivados. Nessa integração também são recuperadas as unidades consumidoras afetadas, elevando o volume. Para suportar o processamento, a mensagem é dividida em chunks.

00:04:27 Vladimir: Registra a entrada de Castellani. Recapitula rapidamente a apresentação sobre a experiência da consultoria e o conhecimento de ambientes de TI e OT.

00:05:06 Norberto: Solicita que Gullit e Thiago se apresentem, pois Thiago ainda não era conhecido por todos.

00:05:25 Gullit (Sensedia e F5): Apresenta-se e informa que atua junto com Thiago na sustentação da plataforma. Explica que existem formas de acesso interno e externo, sendo o ambiente em discussão predominantemente interno e controlado.

00:05:59 Gullit (Sensedia e F5): Compartilha a tela e mostra as APIs do ADMS. Afirma que o consumo ocorre internamente, sem exposição direta à internet. Há um VIP dedicado para a integração no ambiente G3.

00:06:27 Gullit (Sensedia e F5): Descreve o caminho básico: o API Gateway recebe a solicitação de um cliente, encaminha ao F5, e o F5 direciona para o servidor de destino. Nesse fluxo interno, a chamada não passa pelo firewall de borda.

00:07:26 Thiago (Sensedia e F5): Apresenta-se como integrante vindo do time de desenvolvimento da Energisa para atuar em conjunto com Gullit na administração do Sensedia e do API Gateway. Coloca-se à disposição para os esclarecimentos.

00:07:46 Norberto: Pergunta se é conveniente começar pelo inventário de integrações do ADMS que utilizam o API Gateway e, posteriormente, complementar com as equipes de desenvolvimento.

00:08:05 Castellani: Antes de entrar no inventário, pergunta sobre a forma de uso do Sensedia: apenas como API Gateway ou também como plataforma de API Management, incluindo gestão do ciclo de vida e eventual orquestração.

00:08:40 Gullit (Sensedia e F5): Explica que há um caso específico, associado ao QS, em que a plataforma é usada também para gerenciamento e roteamento condicionado. Conforme a empresa ou contexto recebido, um interceptor direciona a solicitação para servidores diferentes.

00:09:21 Gullit (Sensedia e F5): Afirma que, na maior parte dos casos, o Sensedia opera principalmente como gateway e proxy. Em algumas situações, também são aplicadas regras por interceptors para atender requisitos de segurança, exceções e proteções solicitadas pelo escritório de segurança.

00:10:06 Castellani: Pergunta se o catálogo de APIs é usado para registrar todas as APIs e se os desenvolvedores conseguem consultá-lo para localizar interfaces e endpoints disponíveis.

00:10:14 Gullit (Sensedia e F5): Confirma o catálogo, mas informa que o desenvolvedor não tem autonomia completa para cadastrar endpoints. Quando precisa de um novo endpoint, abre chamado para a equipe da plataforma, informa URL e backend, e a equipe realiza a configuração.

00:10:55 Gullit (Sensedia e F5): Mostra na tela onde o backend é cadastrado por ambiente, incluindo homologação e produção, e como é montado o fluxo de encaminhamento.

00:11:37 Castellani: Confirma se, nesse ponto, o gateway atua apenas como proxy, sem transformar o modelo de informação ou funcionar como uma camada anticorrupção entre domínios com linguagens diferentes.

00:12:03 Castellani: Dá um exemplo conceitual: um domínio pode chamar a entidade de cliente, enquanto outro domínio a representa como pessoa física ou jurídica. Pergunta se o gateway traduz semanticamente esses conceitos ou apenas repassa o payload.

00:12:20 Gullit (Sensedia e F5): Responde que, na maior parte dos fluxos, recebe e repassa o payload ao backend. Reconhece, porém, que existem APIs com alguma tradução.

00:12:42 Norberto: Esclarece que algumas integrações com o ADMS usam Web Services e XML do lado do ADMS e JSON do lado da Energisa. Nessas integrações, há conversão de XML para JSON ou de JSON para XML em uma das direções.

00:13:08 Gullit (Sensedia e F5): Confirma que a conversão é realizada por interceptor e mostra um exemplo na tela.

00:13:38 Castellani: Resume que, na integração com o ADMS, o Sensedia executa conversões entre JSON e XML.

00:13:50 Norberto: Ajusta a explicação: a transformação ocorre somente em uma direção em determinados fluxos; no caminho inverso, a aplicação realiza a conversão. Relata que, durante o desenvolvimento, foram identificados problemas ao tentar usar o interceptor em ambos os sentidos.

00:14:06 Norberto: Lembra que a ideia original, discutida com a Sensedia, era fazer toda a conversão na plataforma, mas a implementação encontrou limitações ou incompatibilidades práticas, exigindo parte da transformação na aplicação.

00:14:33 Castellani: Pergunta sobre API Design: se a organização desenha a interface antes da implementação, produz mock, valida contrato e testes e, somente depois de aprovada, conecta a API ao backend.

00:15:21 Gullit (Sensedia e F5): Explica que a equipe recebe do desenvolvimento a especificação e cadastra a API no módulo de design. Depois configura planos de acesso, ambientes permitidos, limites de uso e demais parâmetros.

00:15:42 Gullit (Sensedia e F5): Mostra a configuração de plano de acesso, incluindo ambiente de homologação ou produção e rate limit, exemplificando uma faixa de até mil requisições por minuto.

00:16:35 Norberto: Comenta que o mock é mais usado no início do desenvolvimento, quando a API ainda não está pronta. A prática fica com a equipe de desenvolvimento e nem sempre permanece na fase de homologação.

00:16:59 Castellani: Apresenta o Spectral como exemplo de ferramenta open source para lint de contratos OpenAPI. Explica que regras podem ser acopladas ao pipeline para checar padrões, versionamento e compatibilidade antes do deploy.

00:17:27 Castellani: Cita validações como nomenclatura, versionamento, conformidade com padrões internos e prevenção de quebra de interface. Observa que o próprio Sensedia possui mecanismos de governança semelhantes, possivelmente no módulo de API Design.

00:17:43 Castellani: Pergunta se o processo atual verifica formalmente se uma nova versão de API preserva compatibilidade e evita quebrar consumidores existentes.

00:18:09 Norberto: Informa que existe versionamento manual: a equipe cria uma nova revisão e direciona os consumidores para a nova versão.

00:18:26 Gullit (Sensedia e F5): Mostra o recurso de revisão e governança da plataforma. Explica que, quando é necessário adicionar um endpoint, não altera diretamente a versão publicada; gera uma nova revisão e realiza o deploy mediante processo de mudança.

00:19:27 Castellani: Reformula a pergunta para focar em incidentes reais: questiona se já ocorreu de uma API mudar a interface, quebrar um consumidor em produção e exigir fallback para a versão anterior.

00:20:13 Gullit (Sensedia e F5): Responde que mudanças de documentação normalmente são informadas para que a equipe adapte a configuração. Reconhece que pode ter ocorrido quebra de aplicação, mas não se recorda de vários casos.

00:20:50 Castellani: Pergunta especificamente sobre fallback após uma mudança aprovada e implantada.

00:21:05 Gullit (Sensedia e F5): Explica que, se o problema estiver no endpoint publicado, pode acessar o Revision Management, selecionar a versão anterior e executar novo deploy, restaurando o estado anterior.

00:21:45 Gullit (Sensedia e F5): Diz que esse tipo de retorno já ocorreu em canais digitais, que possuem maior utilização, mas não se recorda de casos relevantes no ADMS. Norberto também informa que não acompanhou ocorrências desse tipo.

00:22:14 Castellani: Conclui provisoriamente que quebra de contrato não parece ser a dor principal do ADMS, embora a equipe de mudança e os desenvolvedores possam conhecer casos não visíveis para o time do gateway.

00:22:43 Castellani: Explica que uma ferramenta como Spectral, integrada ao pipeline, impediria a promoção de uma especificação incompatível. Usa como exemplo a regra de retrocompatibilidade: parâmetros podem ser adicionados, mas não removidos sem versionamento adequado.

00:23:13 Castellani: Detalha que, ao detectar remoção de parâmetro ou quebra de contrato, o pipeline deveria emitir alerta, recusar a execução e exigir correção na pull request antes do deploy.

00:23:49 Castellani: Observa que o cenário atual é diferente: o CI e CD do desenvolvimento publica a aplicação, depois é aberto um chamado e a equipe de Sensedia cria ou altera manualmente a API. Portanto, o deploy do gateway está fora da esteira de CI e CD da aplicação.

00:24:28 Gullit (Sensedia e F5): Confirma a separação: os desenvolvedores são clientes da equipe da plataforma; enviam a documentação e os dados, e a equipe executa a configuração no gateway.

00:25:05 Castellani: Comenta que, em uma esteira integrada, o mesmo pipeline poderia publicar a API e aplicar as validações automaticamente.

00:25:17 Norberto: Informa que existe uma iniciativa paralela de Infrastructure as Code avaliando soluções para automação, e sugere que o tema possa ser incorporado a esse projeto.

00:25:38 Castellani: Encerra o bloco de entendimento do Sensedia e solicita continuidade para a visão das APIs e do monitoramento.

00:26:20 Gullit (Sensedia e F5): Apresenta a visão geral de monitoramento das APIs do ADMS. Mostra recursos para acompanhar documentação, operações e endpoints consumidos, quantidade de requisições, erros e duração média das operações.

00:27:37 Gullit (Sensedia e F5): Explica que as requisições seguem da camada de gateway para o F5 e, então, ao servidor ou backend de destino.

00:28:44 Gullit (Sensedia e F5): Passa a demonstrar o F5. Mostra um VIP de produção que recebe conexões. O VIP é simples, sem policy específica, e atua como balanceador e proxy em modo standard.

00:29:20 Gullit (Sensedia e F5): Explica que o F5 trata a conexão, aplica os parâmetros necessários e encaminha para um pool. O pool possui monitor configurado; o monitor verifica uma porta do servidor e determina se o membro está ativo.

00:29:52 Gullit (Sensedia e F5): Diz que, sem o monitor, o VIP não opera corretamente. Mostra membros do pool: um principal ativo e outro usado em contingência e manutenção. Alguns membros antigos permaneceram da época do projeto e deveriam ser removidos, embora não alterem o funcionamento atual.

00:30:32 Gullit (Sensedia e F5): Descreve o procedimento de manutenção: para atualizar um servidor, as conexões são direcionadas ao secundário; atualiza-se o principal; depois as conexões retornam. O tráfego observado é muito maior no servidor principal.

00:31:10 Equipe: Confirma a localização dos ambientes: o secundário citado está na Paraíba; o principal está no outro datacenter, associado ao ambiente de Minas Gerais.

00:31:29 Norberto: Pergunta se o pool usa Round Robin, tentando alternar entre os membros.

00:31:34 Gullit (Sensedia e F5): Esclarece que, na prática, não funciona como Round Robin porque somente o membro principal fica habilitado. Os membros antigos foram criados durante o projeto, quando ainda não estava definido qual seria o principal.

00:31:48 Gullit (Sensedia e F5): Informa que é necessário abrir uma mudança para remover os membros antigos. Reforça que, quando não há site switch, o membro de contingência precisa permanecer desativado.

00:32:26 Norberto: Pergunta como o F5 identifica que um membro deve ser desativado e se existe alguma API do ADMS usada para verificar a condição.

00:32:33 Gullit (Sensedia e F5): Responde que há um health monitor olhando a porta 443 e verificando se ela está ativa.

00:32:47 Castellani: Pergunta o nível do monitoramento: se é apenas TCP e porta, HTTP com status 200, ou chamada a um serviço específico. Observa que o servidor pode estar ativo e a aplicação Sensedia ou ADMS estar inoperante.

00:33:05 Gullit (Sensedia e F5): Esclarece que o monitor está olhando para o backend que receberá a chamada. O VIP recebe a conexão, passa pelo pool e entrega ao servidor final.

00:33:52 Castellani: Confirma que o backend do VIP mostrado é o servidor do ADMS, e não o Sensedia. Reconstitui o fluxo: a chamada chega ao gateway, usa o VIP do F5 e alcança o servidor.

00:34:40 Castellani: Pergunta se o monitor verifica a saúde do ADMS como aplicação ou apenas se o servidor e a porta estão respondendo.

00:34:28 Gullit (Sensedia e F5): Responde que, do lado do F5, a verificação atual é basicamente se a porta está ativa. Se o servidor desligar ou falhar de forma evidente, o monitor detectará; porém, uma falha lógica da aplicação pode não ser identificada.

00:34:46 Gullit (Sensedia e F5): Explica que, se o backend parar, as chamadas no Sensedia também deixam de ser entregues, e a volumetria monitorada apresenta uma lacuna visível.

00:35:06 Norberto: Pergunta sobre o site switch do ADMS. Hoje a equipe da aplicação executa manualmente a troca para o ambiente da Paraíba; quer entender como o F5 identifica essa mudança.

00:35:23 Gullit (Sensedia e F5): Esclarece que a aplicação não sinaliza automaticamente ao F5. Durante o procedimento, a equipe do ADMS comunica que vai virar o ambiente, e a equipe de F5 realiza a mudança manual.

00:35:44 Gullit (Sensedia e F5): Descreve a operação coordenada em salas técnicas: quando a equipe de aplicação confirma que o ambiente foi alterado, o operador do F5 desabilita o membro atual e habilita o membro secundário.

00:36:05 Norberto: Confirma que o processo é manual.

00:36:07 Gullit (Sensedia e F5): Explica que depende da confirmação da equipe da aplicação; somente depois desabilita um membro e habilita o outro.

00:36:27 Norberto: Pergunta se seria possível o F5 monitorar um endpoint de saúde e realizar a troca automaticamente.

00:36:37 Gullit (Sensedia e F5): Diz que é possível ter os dois membros e retirar automaticamente um membro que caia, mas alerta para um detalhe: quando o ADMS faz o site switch dentro da aplicação, o servidor anterior pode continuar com a porta ativa.

00:37:01 Gullit (Sensedia e F5): Explica que a aplicação pode ter mudado seu papel lógico sem desligar a porta 443. Para o F5, ambos os servidores continuariam saudáveis; por isso, se ambos estivessem habilitados, o balanceador poderia enviar tráfego para os dois.

00:37:24 Gullit (Sensedia e F5): Reforça que a equipe do F5 precisa desabilitar explicitamente o membro anterior para que o novo servidor passe a receber conexões. A automatização dependeria de um sinal técnico confiável da aplicação.

00:37:46 Norberto: Registra que é necessário avaliar com a área de aplicação se existe algo que permita automatizar a decisão.

00:37:52 Gullit (Sensedia e F5): Sugere que, se o processo de site switch também desabilitasse a porta ou algum indicador, o monitor do F5 poderia detectar. Sem isso, o F5 entende que os dois lados estão ativos e um algoritmo de balanceamento poderia distribuir requisições incorretamente.

00:38:39 Norberto: Pergunta se há uma dor operacional relacionada ao processo atual.

00:38:46 Gullit (Sensedia e F5): Responde que a principal limitação é a necessidade de uma equipe preparada e coordenada para executar o site switch manual. A operação envolve F5, Citrix e VMs e equipe da aplicação.

00:39:09 Gullit (Sensedia e F5): Questiona se seria viável, no nível da aplicação, fazer a porta 443 deixar de responder durante a mudança. Observa que isso precisa ser discutido porque a manutenção pode ocorrer no servidor sem desligar a aplicação da forma esperada.

00:39:36 Gullit (Sensedia e F5): Explica que, caso a aplicação forneça um endpoint que deixe de retornar 200 no servidor inativo e passe a retornar 200 no ativo, o F5 poderia automatizar a seleção. Sem esse sinal, o processo permanece complexo e dependente de ação manual.

00:40:18 Castellani: Propõe estudar uma solução com monitor HTTP a um endpoint específico de saúde ou de papel. O endpoint poderia ser controlado por script ou arquivo e retornar 200 somente no nó que deve receber tráfego. O F5 retiraria automaticamente do pool o nó que não respondesse.

00:40:59 Gullit (Sensedia e F5): Lembra que já houve ideia semelhante, mencionando um double check: validar um ponto e, se ele não responder, encaminhar ao outro membro.

00:41:16 Norberto: Confirma que esse é o tipo de mecanismo esperado.

00:41:19 Norberto: Muda para o tema do conector Kafka e CDC. Explica que existe um conector que observa o banco e um VIP associado. Pergunta se o F5 executa alguma ação para migrar o apontamento entre Minas e Paraíba.

00:41:47 Gullit (Sensedia e F5): Informa que não se recorda de nenhuma ação de F5 para Kafka durante a troca para a Paraíba.

00:41:53 Norberto: Explica que esse é um possível gap. Em condições normais, a replicação do banco permite que o conector continue recebendo dados, mas ocorreu um failover real em que a aplicação de Minas foi parada para manutenção.

00:42:34 Norberto: Relata que, nesse incidente, não houve perda de dados, mas o fluxo ficou parado por um período. Dashboards alimentados pelo CDC ficaram congelados, embora o ADMS continuasse operando no ambiente da Paraíba.

00:42:44 Norberto: Conclui que o apontamento do conector e do banco provavelmente não foi redirecionado para o ambiente da Paraíba. Identifica esse comportamento como outro ponto crítico a investigar.

00:43:05 Gullit (Sensedia e F5): Concorda que o caso deve ser analisado com a equipe do Kafka e Confluent, ponto a ponto. Afirma que, no seu histórico, não houve ação manual de F5 para esse fluxo.

00:43:20 Norberto: Observa que o conector também possui um VIP e tenta localizar o objeto correspondente.

00:43:37 Gullit (Sensedia e F5): Analisa a nomenclatura e identifica um VIP que parece direcionar diretamente para OpenShift, possivelmente relacionado ao próprio Confluent. Por isso, não haveria ação manual semelhante ao VIP do ADMS.

00:44:05 Equipe: Conclui que é necessário levantar a documentação e identificar exatamente qual VIP, nome e fluxo atendem ao conector CDC. O componente pode estar registrado com outra nomenclatura.

00:44:29 Castellani: Registra esse item como gap a investigar e pergunta sobre a padronização de nomes dos VIPs.

00:44:51 Gullit (Sensedia e F5): Explica que a nomenclatura indica características do ambiente. Prefixos e faixas permitem identificar recursos em OpenShift, DMZ, ambiente interno ou externo e tipo de servidor.

00:45:29 Gullit (Sensedia e F5): Reconhece que alguns nomes são antigos e fogem ao padrão atual. Afirma que adotou um padrão próprio ao assumir a operação para facilitar troubleshooting entre milhares de VIPs.

00:46:23 Castellani: Pergunta se a regra de nomenclatura está documentada.

00:46:29 Gullit (Sensedia e F5): Responde que a regra não está formalmente documentada; foi um padrão operacional adotado pela equipe.

00:46:47 Equipe: Confirma que determinados VIPs representam produção e homologação e que alguns nomes refletem decisões tomadas durante a implantação.

00:47:29 Norberto: Pergunta se Gullit percebe outras dores no Sensedia ou no F5 relacionadas às integrações do ADMS.

00:47:41 Gullit (Sensedia e F5): Responde que a principal questão é o site switch. Fora disso, a integração é transparente, e muitos erros tendem a ocorrer no nível da aplicação, não do gateway. O monitoramento da plataforma permite analisar as falhas.

00:48:34 Norberto: Sugere envolver a Schneider na análise do site switch para compreender melhor os sinais disponíveis na aplicação.

00:48:40 Castellani: Reconstitui o fluxo de eventos: um produtor publica no Kafka, um consumidor recebe o evento e pode chamar um serviço. Pergunta se a chamada ao serviço passa por Sensedia e F5.

00:49:13 Gullit (Sensedia e F5): Explica que uma chamada externa ao cluster pode chegar primeiro a um VIP do F5 associado ao Sensedia, entrar no gateway, depois usar outro VIP do ambiente G3 e seguir ao serviço.

00:49:57 Castellani: Pergunta se o fluxo descrito é o mesmo do CDC.

00:50:05 Norberto: Esclarece que não. O CDC não passa pelo Sensedia; utiliza um F5 e VIP apenas para o apontamento de rede ao banco.

00:50:33 Norberto: Explica que existe um Kafka Connect dentro do ambiente Kafka. Esse conector usa o F5 para se conectar à base SQL Server do ADMS.

00:50:57 Castellani: Resume o fluxo CDC: Kafka Connect acessa a base SQL Server, captura mudanças via CDC e Debezium, publica em tópico Kafka e outro componente consome o tópico.

00:51:22 Castellani e equipe: Confirma que, nesse fluxo, não existe Sensedia na frente do conector. A maioria dos consumidores e serviços está dentro do OpenShift e se comunica internamente, sem sair pelo F5.

00:51:55 Castellani: Conclui que, se um serviço interno precisar chamar uma API externa ao seu ambiente, ele usa o Sensedia. Norberto confirma que esse é o caso das chamadas ao ADMS.

00:52:12 Norberto: Explica que existem middlewares no OpenShift que se comunicam com o ADMS. Essas integrações passam pela cadeia de gateway e F5.

00:52:21 Castellani: Pergunta se a chamada ao ADMS é síncrona.

00:52:28 Norberto: Confirma. Explica que, na concepção, a Schneider disponibilizou adaptadores standard via SOAP e XML e não havia alternativa assíncrona por outro protocolo.

00:52:51 Castellani: Pergunta sobre a capacidade do ADMS diante de picos de eventos e alto volume de requisições síncronas.

00:53:20 Norberto: Relata que o ADMS recebeu novas features que melhoraram o processamento em cenários de contingência. Processos que antes demoravam muitos minutos ou quase uma hora passaram a concluir em poucos minutos.

00:54:01 Norberto: Explica um caso crítico: no retorno de um incidente, se houver muitos clientes atingidos, o ADMS envia também a lista de unidades consumidoras. Uma falha de subestação pode envolver centenas de milhares de clientes e gerar uma mensagem muito grande.

00:54:35 Norberto: Cita o serviço ONT e informa que ainda será realizada reunião com os responsáveis. A integração de abertura de reclamação para o OMS possuía uma fila única de processamento.

00:55:05 Norberto: Compara a fila única com o Kafka, que permite subdivisão por partições. A fila única gerava gargalo. Foram feitas melhorias, mas não se sabe se resolveram totalmente o problema; é necessário revalidar com a equipe.

00:55:40 Norberto: Recorda casos de contingência do COE, como eventos de chuva, em que os atendimentos demoravam. Sabe que a Schneider implementou features que melhoraram o comportamento, mas não conhece o nível atual de resiliência para um novo incidente extremo.

00:56:29 Norberto: Afirma que a dor do retorno pelo serviço ONT ainda existe: o processamento continua demorando em determinadas condições.

00:56:37 Castellani: Reconstitui novamente o fluxo para confirmar entendimento: um evento é consumido por um serviço no OpenShift; esse serviço envia uma requisição síncrona ao ADMS para processamento.

00:57:02 Castellani: Pergunta o que acontece quando o OMS e o ADMS estão fora do ar.

00:57:14 Norberto: Informa que existe um processo de DLQ, embora não detalhe a implementação. Explica que a equipe de desenvolvimento deverá apresentar como o mecanismo funciona atualmente.

00:57:33 Castellani: Reconhece que o detalhamento da DLQ e da resiliência já pertence à próxima fase, junto às equipes de desenvolvimento.

00:57:46 Norberto: Pergunta se Gullit e Thiago têm alguma outra dor ou se Castellani possui mais perguntas.

00:57:59 Gullit (Sensedia e F5): Reitera que a principal oportunidade é otimizar o site switch. O processo funciona, mas poderia ser melhor e menos dependente de operação manual.

00:58:22 Norberto: Levanta o risco de um site switch ocorrer à noite: é preciso acionar plantão e garantir monitoramento e pessoas disponíveis para realizar a troca manual.

00:58:46 Castellani: Concorda que a oportunidade central é automatizar monitoramento e failover, mantendo procedimento manual apenas como contingência. Resume que esse é o principal problema identificado no bloco de F5.

00:59:09 Castellani: Registra outro ponto de atenção: o deploy no API Gateway está fora do CI e CD, e a governança poderia ser mais automatizada para reduzir o risco de quebra de contrato.

00:59:25 Castellani: Observa que a iniciativa de IaC pode endereçar parte dessa automação. Norberto se compromete a conversar com a equipe do projeto para verificar se o Sensedia e o API Gateway estão incluídos no escopo.

00:59:45 Castellani: Registra ainda um ponto não crítico: a regra de nomenclatura dos VIPs é tácita. Recomenda formalizar a convenção, que já é útil e estruturada, para torná-la reutilizável e governável.

01:00:26 Norberto: Agradece a Gullit e Thiago. Confirma a próxima reunião, à tarde, com a equipe da integração de GIS e ADMS.

01:00:44 Participantes: Confirmam a agenda e encerram a reunião com agradecimentos.

Anexo C · Trechos e termos que exigem validação

Itens em que a fonte permaneceu ambígua ou dependente de confirmação técnica.

• Nome exato de algumas integrações citadas no início da reunião, devido à baixa inteligibilidade da transcrição automática.
• Identificação do VIP específico utilizado pelo Kafka Connect e Debezium para acessar o SQL Server do ADMS.
• Nome e desenho atual do serviço citado como ONT, bem como seu mecanismo de fila e de DLQ.
• Capacidade real do health monitor do F5: TCP, HTTPS simples ou requisição HTTP com validação de status e corpo.
• Comportamento do ADMS e da Schneider durante o site switch: mudança de papel, disponibilidade das portas, endpoint de prontidão e possibilidade de automação.
• Escopo da iniciativa de IaC e possibilidade de incluir a configuração e o deploy do Sensedia e do F5.

1.6.21. Observações finais

Esta ata foi consolidada a partir de três documentos produzidos sobre a mesma sessão: a ata formal da reunião, a compilação técnica por temas e a transcrição cronológica revisada. Eventuais nomes de pessoas e termos técnicos transcritos automaticamente foram normalizados para refletir o contexto do projeto. As classificações de prioridade e os prazos do plano de ação têm caráter indicativo e serão refinados nas etapas seguintes da consultoria.