Sensedia, F5 e Site Switch do ADMS¶
Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 10/07/2026 (1h48min, pasta Reuniao-Sensedia) e Ata 05 já consolidada no Assessment (item 1.6) Status: Rascunho para consolidação — a Ata 05 é bem fundamentada (três fontes declaradas); este artefato visualiza os três achados centrais e registra uma contradição editorial na própria ata Elaborado por: Syntropy Labs
Por que este artefato existe¶
A sessão de 10/07 apresentou a arquitetura de API Gateway (Sensedia) e balanceamento (F5) que sustenta as integrações síncronas com o ADMS, conduzida por Gullit e Thiago (equipe Sensedia/F5) com participação de Norberto, Vladimir e Castellani. A Ata 05 cobre essa sessão com base em três fontes declaradas (ata formal, compilação técnica e transcrição cronológica) — inclusive atribuindo explicitamente a afiliação "Digital Solutions e Syntropy Labs" à ata formal, o que confirma (em vez de contradizer) o mesmo dado encontrado na Ata 07. Este artefato traduz os três achados centrais — a topologia Sensedia/F5/CDC, o processo de site switch manual, e o incidente real de congelamento do CDC — em diagramas para o Capítulo 4 (Infraestrutura) e o Capítulo 5 (Riscos).
Diagrama 1 — Topologia Sensedia/F5/CDC¶
O ponto estrutural aqui é que existem dois caminhos de rede completamente distintos para o ADMS: o caminho síncrono (middleware → Sensedia → F5 → ADMS), usado por serviços que precisam de uma API externa ao cluster, e o caminho de CDC (Kafka Connect/Debezium → F5 → SQL Server do ADMS), que não passa pelo Sensedia e cujo VIP exato nem a própria equipe de F5 conseguiu confirmar durante a sessão.
Diagrama 2 — Site switch: processo manual atual vs. proposta¶
Este é o tema central da sessão, segundo a própria Ata 05. O ponto mais importante é técnico e sutil: o F5 monitora apenas se a porta 443 responde, não se a aplicação está no papel lógico ativo — então nada impede, hoje, que os dois lados pareçam "saudáveis" simultaneamente após um chaveamento incompleto.
Diagrama 3 — Incidente real: CDC congelado após failover¶
Este não é um cenário hipotético — é um incidente já ocorrido, relatado por Norberto na própria sessão. É o melhor argumento concreto para a recomendação nº 5 da Ata 05 (identificar o VIP e mecanismo de conexão do Kafka Connect ao SQL Server), porque mostra o que acontece quando essa lacuna de rastreabilidade se manifesta na prática.
Achado editorial: "ambiente estável" contradiz a própria tabela de riscos¶
Auditando a Ata 05 contra a transcrição, o conteúdo técnico bate bem — inclusive o nome do serviço "ONT" é corretamente marcado no Anexo C como pendente de confirmação (a transcrição literalmente registra "ENT", não "ONT"). O achado que vale registrar aqui não é de fidelidade à transcrição, é de consistência interna do próprio documento:
A conclusão executiva (item 1.6.20.1) afirma que "o ambiente Sensedia e F5 encontra-se operacionalmente estável" e que "não foram identificados problemas críticos ou riscos imediatos de arquitetura". Mas a tabela de achados da mesma ata (item 1.6.15) classifica quatro riscos como severidade Alta: site switch manual, health check apenas por porta, CDC sem reapontamento comprovado, e payloads síncronos massivos. Um incidente real de congelamento do CDC (Diagrama 3 acima) já aconteceu. Isso não é necessariamente incorreto — "estável" pode estar descrevendo a operação do dia a dia, e "Alta" pode estar descrevendo o risco de cauda em cenário de contingência — mas a redação atual não faz essa distinção, e as duas frases lidas em sequência soam contraditórias. Vale ajustar a redação da conclusão executiva antes de consolidar no Capítulo 5, para não subestimar os quatro riscos altos que a própria ata levantou.
Próximo passo¶
Consolidar os três diagramas na Ata 05 (itens 1.6.9/1.6.10 e 1.6.11) e usá-los no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos e Matriz RAID). Ao consolidar, ajustar a conclusão executiva da Ata 05 para reconciliar "ambiente estável" com os quatro riscos de severidade Alta já identificados na própria tabela — e priorizar a identificação do VIP do conector CDC (recomendação nº 5 da ata), já que o artefato aqui mostra um incidente real, não apenas um risco teórico.