Ata 13 · Rede e Telecomunicações: Topologia Interdatacenter, Segmentação, Capacidade, Latência, Posicionamento do Conector de Captura e Recuperação de Desastre (29 de julho de 2026)

Ata consolidada a partir do relatório técnico produzido sobre a sessão e da transcrição integral da gravação, com unificação dos temas e preservação dos pontos que dependem de validação no áudio original.

Data	29 de julho de 2026 (quarta-feira)
Horário	10h01 às 10h29, horário de Brasília
Duração	Aproximadamente 28 minutos
Plataforma	Microsoft Teams (reunião remota, com gravação e transcrição automática)
Natureza	Sessão técnica de levantamento com as equipes de rede e infraestrutura
Tema	Topologia de conectividade entre os data centers de Minas Gerais e da Paraíba, segmentação entre TI e OT, capacidade e latência dos enlaces, conectividade com nuvem, posicionamento do conector de captura e maturidade da recuperação de desastre
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Elaborado por	Syntropy Labs
Fontes	Relatório técnico consolidado da sessão e transcrição integral da gravação do Microsoft Teams

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

1.14.1.1. Posicionamento no assessment

A sessão foi aberta com a contextualização habitual: desde a implantação do ADMS houve um período de contingência, com atrasos de processamento e lacunas específicas a tratar, e em conversa com a gestão e a equipe do projeto foi solicitada a revisão de pontos da arquitetura, com ênfase na integração ponta a ponta. Foi registrado que já haviam sido realizadas cerca de treze reuniões com equipes distintas, incluindo desenvolvimento, dados, OpenShift, infraestrutura e banco de dados, em uma releitura conduzida área por área.

O objetivo específico desta sessão foi validar a topologia de rede que sustenta a comunicação entre os data centers, levantar as dores operacionais da área, avaliar os riscos das implantações próximas e aprofundar os temas de contingência e recuperação de desastre. Como nas demais sessões, as equipes foram convidadas a trazer as dores e as preocupações relacionadas às integrações, especialmente as próximas ao momento de entrada em produção.

1.14.1.2. Limites da sessão

A sessão foi curta e teve caráter confirmatório. A identificação automática de falantes não permite associar com segurança todas as vozes aos nomes citados, de modo que o registro cronológico do Anexo A atribui as falas por papel funcional. Diversos termos técnicos e nomes próprios foram capturados de forma foneticamente imprecisa e estão relacionados no Anexo B. Os números de ocupação foram apresentados de memória e com divergência entre média e pico, e não foram apresentadas séries históricas de utilização, medições de latência por direção nem documentação de recuperação de desastre.

1.14.2. Participantes e áreas envolvidas

A gravação não associa de forma inequívoca todos os nomes às vozes registradas. A relação abaixo reúne os nomes e papéis indicados durante a conversa, sem atribuição definitiva de fala.

Norberto da Silva Prado	Energisa, arquitetura e integração	Contextualização do assessment, apresentação da topologia, cronograma de implantação e condução dos encaminhamentos.
Nelson	Energisa, redes e sustentação	Descreveu os enlaces, o compartilhamento da infraestrutura, a ocupação, a latência e a prática de testes de recuperação de desastre.
Armando	Energisa, infraestrutura	Informou o estágio da contratação e a previsão de implantação do Data Center Interconnect.
Gustavo, Marcelo e Daniel	Energisa, participantes técnicos	Mencionados durante a conversa e no encerramento. Marcelo participou a partir de João Pessoa e um dos participantes a partir de Campo Grande.
João Carlos Franco Castellani	Syntropy Labs	Condução da análise sobre latência nas integrações, posicionamento do conector de captura, replicação de banco e maturidade da recuperação de desastre.
Vladimir Morozowski de Sousa	Syntropy Labs	Condução, gestão e acompanhamento do assessment e registro da sessão.

Foram citados, sem participação direta:

• Thiago Xavier, autor do desenho de topologia utilizado na sessão, e Tales, com quem o material foi compartilhado.
• Érica de Andrade e Santos, no contexto da solicitação do assessment.
• Marcos Anunciação e um profissional da equipe de segurança, indicados como responsáveis pela frente de recuperação de desastre corporativa.
• Equipe de dados, que avalia a adoção de VPN ou enlace dedicado com a nuvem.

1.14.3. Resumo executivo

A sessão concluiu que a conectividade entre os data centers aparenta possuir capacidade suficiente para as próximas implantações, sem indicação imediata de saturação. A área de rede não apresentou dor operacional relevante. Entretanto, ao aprofundar a conversa, o foco deslocou-se da capacidade para quatro pontos que exigem validação formal e que passam a integrar o diagnóstico do assessment.

Capacidade dos enlaces	Dois enlaces de 10 Gbit/s entre os data centers, compartilhados por todo o ambiente, com ocupação informada entre menos de 50% e 70%, conforme o critério de medição.	Aparente folga para a implantação prevista, mas sem linha de base formal.	Extrair séries históricas com média, pico e percentis por direção antes da entrada em produção.
Latência interdatacenter	Entre 60 e 70 milissegundos, compatível com a distância superior a três mil quilômetros.	Relevante para as integrações síncronas entre o OMS na Paraíba e os sistemas corporativos em Minas Gerais.	Medir o comportamento real em homologação e definir limites de tempo de espera e novas tentativas.
Posicionamento do conector de captura	O conector e o Debezium executam no OpenShift corporativo, distantes do banco de origem no ambiente operacional.	Sensibilidade a variações de rede, atraso na captura e dificuldade de recuperação.	Avaliar a aproximação do conector ao banco, ponderando a centralização da observabilidade e da operação.
Assimetria dos modelos de continuidade	O ADMS opera em modelo ativo-ativo entre os sites, enquanto os sistemas corporativos executam apenas em Minas Gerais e são levantados na Paraíba somente em caso de desastre.	Em um chaveamento do ADMS, a integração passa a atravessar a distância entre os sites.	Tratar a assimetria como premissa de projeto das integrações, e não como situação excepcional.
Replicação do banco corporativo	Informado o uso de Data Guard entre os sites, sem confirmação de modo de proteção nem de transporte síncrono ou assíncrono.	Objetivos de ponto e de tempo de recuperação desconhecidos e possível defasagem em falha abrupta.	Confirmar a configuração com a administração de banco e a área de continuidade.
Maturidade da recuperação de desastre	Nunca houve declaração real de desastre nem chaveamento integral do ambiente corporativo. Os testes ocorrem em ambiente isolado.	Dependências reais de produção podem não estar sendo exercitadas.	Mapear os testes já realizados, o cronograma e a cobertura das dependências.
Conectividade com a nuvem	O tráfego para a nuvem de dados ocorre pela internet pública. Existe VPN para um projeto específico na outra nuvem, e o projeto de força de trabalho também trafega pela internet.	Exposição a variação de rota e ausência de acordo de nível de serviço para cargas críticas.	Avaliar conectividade dedicada ou VPN conforme a criticidade de cada integração.
Segmentação e projeto de interconexão	A separação entre as redes de TI e de OT é feita por identificador de VLAN. Existe contratação de solução de interconexão de data centers em fase de assinatura.	Limitações de isolamento e de governança até a conclusão do projeto.	Acompanhar o cronograma, com infraestrutura em 2026 e migrações até março de 2027.

Síntese do assessment O resultado mais relevante desta sessão não é a confirmação de que existe capacidade disponível, e sim o deslocamento do risco. A rede, isoladamente, não é o gargalo. O que importa é a combinação entre a distância física, que impõe um piso de latência que nenhuma contratação elimina, e uma assimetria de arquitetura: o ADMS pode operar de qualquer um dos dois sites, enquanto os sistemas corporativos com os quais ele se integra permanecem concentrados em um deles. Sempre que o ADMS estiver operando na Paraíba, toda a integração com o corporativo atravessará os três mil quilômetros. Essa não é uma situação de exceção: sob o G1, ela é a configuração normal de operação.

1.14.4. Topologia interdatacenter

1.14.4.1. Descrição do enlace

A topologia conecta o data center principal do Grupo Energisa, em Cataguases, Minas Gerais, ao ambiente da Paraíba, em João Pessoa. A conectividade foi descrita como um enlace de camada 3 entre redes locais, apoiado por dois enlaces de 10 Gbit/s que saem diretamente dos switches do ambiente e alcançam os firewalls que atendem ao ADMS em cada ponta.

• Foi esclarecido que o firewall citado não é dedicado ao ADMS, embora atenda a esse ambiente.
• Os enlaces não são exclusivos do ADMS: toda a replicação entre os dois data centers atravessa essa mesma infraestrutura, assim como as demais cargas do ambiente.
• O data center de Minas Gerais é o principal do grupo, e o da Paraíba é o ambiente de recuperação de desastre.
• O desenho utilizado na sessão foi confeccionado por Thiago Xavier e compartilhado com Tales. As equipes de rede confirmaram, durante a própria conversa, que o material reflete o ambiente atual.

1.14.4.2. Distribuição dos agrupamentos

A distribuição dos agrupamentos entre os data centers, já registrada em atas anteriores, foi confirmada nesta sessão sob a perspectiva de rede.

G3	Data centers de Minas Gerais, exclusivamente.	Já implantado. Foi o primeiro agrupamento a entrar em operação.
G1	Data center da Paraíba.	Em implantação. O SCADA havia acabado de ser implantado e o OMS estava previsto para entrar em seguida.
G2	A definir conforme o cronograma.	Expansão futura, que elevará progressivamente o tráfego entre os sites.

Foi registrado que existem, além do tráfego do ADMS, as replicações associadas à recuperação de desastre e ao chaveamento entre sites, bem como as replicações dos dados corporativos, para que também possam ser levantados na Paraíba em caso de desastre. Todas atravessam o mesmo enlace, incluindo as replicações dos bancos discutidos na sessão do dia anterior com as equipes de administração de banco de dados.

1.14.4.3. Segmentação entre TI e OT

A separação entre as redes de tecnologia da informação e de tecnologia operacional é realizada atualmente por identificador de VLAN sobre o mesmo enlace entre redes locais. Está em andamento um processo de contratação de solução de interconexão de data centers, destinado a modernizar e estruturar essa interligação.

Situação atual	Interligação entre os sites com segmentação lógica entre TI e OT por identificador de VLAN.
Projeto futuro	Implementação de solução de interconexão de data centers, ainda não iniciada na data da sessão.
Contratação	Processo concluído com vencedor definido e contrato em fase de assinatura, sem divulgação formal até aquele momento.
Cronograma	Instalação da infraestrutura prevista ainda para 2026, com as migrações previstas para conclusão até março de 2027.
Ampliação de enlaces	Não confirmada como parte desse projeto. Foi mencionada uma iniciativa paralela, conduzida separadamente, destinada à ampliação, cujo detalhamento não estava disponível na sessão.

A implicação prática é que, até a conclusão dessa frente, a segmentação entre os dois domínios permanece lógica e apoiada em configuração de VLAN, com as limitações de isolamento e de governança correspondentes. O cronograma também é relevante para o assessment: a conclusão prevista para março de 2027 é posterior às implantações do G1 e do G2, de modo que essas entradas em produção ocorrerão sobre a topologia atual.

1.14.5. Capacidade, ocupação e latência

1.14.5.1. Ocupação informada

A avaliação predominante das equipes de rede e de infraestrutura foi de que a capacidade disponível é suficiente para a implantação prevista. Os números apresentados, porém, foram informados de memória e com divergência de critério, o que exige formalização.

Capacidade física	Dois enlaces de 10 Gbit/s.	Compartilhados por todo o ambiente de data center, não exclusivos do ADMS.
Ocupação	Menos de 50% em uma fala, pico em torno de 50% em outra e menção posterior a 60% e 70%.	É necessário separar média, percentil de referência, pico e direção do tráfego antes de concluir sobre a folga real.
Latência atual	Entre 60 e 70 milissegundos.	Compatível com a distância superior a três mil quilômetros, mas relevante para integrações síncronas e para replicação.
Proposta de fornecedor	Compromisso técnico de menos de 50 milissegundos.	Valor citado em avaliação de proposta técnica, ainda dependente de comprovação em operação.
Terceiro enlace	Em implantação, conforme informado na sessão.	Aumenta resiliência e capacidade, mas não reduz o tempo de propagação.

Divergência a resolver antes do go-live Os números de ocupação apresentados na sessão variam entre menos de 50% e 70%, conforme quem informa e qual critério é adotado. Essa divergência não indica erro: uma fala tratava de ocupação média e outra de pico. Ela indica, porém, que não existe uma linha de base compartilhada e formalizada, o que torna frágil qualquer conclusão sobre a margem disponível para as próximas ondas de implantação. A recomendação é extrair séries históricas de 30 a 90 dias, com média, pico, percentis, perda, variação de atraso e latência por direção, antes da entrada em produção do OMS.

1.14.5.2. Latência e limite físico

A latência observada foi atribuída principalmente à distância entre os sites, superior a três mil quilômetros, e a própria equipe de rede registrou que não há como reduzi-la de forma significativa por essa via. Foi mencionada uma proposta técnica de fornecedor com compromisso de latência inferior a 50 milissegundos, ainda sujeita a comprovação em operação.

Um ponto importante foi explicitado na sessão: o terceiro enlace em implantação melhora a resiliência e a capacidade, mas não reduz a latência, porque o principal fator é a distância física. A consequência arquitetural é direta: a latência deve ser tratada como uma premissa de projeto das integrações, e não como um problema a ser resolvido por contratação de rede.

1.14.5.3. Percepção de dor pela área

Quando questionada diretamente sobre dores no ambiente, a área de rede respondeu que não existe dor específica, à exceção do risco sistêmico inerente às replicações que atravessam a infraestrutura compartilhada. Do ponto de vista da sustentação e da operação de redes, a avaliação foi de que o ambiente comporta a demanda atual e a prevista, com folga.

Essa ausência de dor na camada de rede é, em si, um dado relevante do assessment: ela reposiciona o risco das próximas implantações para as camadas de integração e de continuidade, tratadas nos itens seguintes, em lugar da capacidade de transporte.

1.14.6. Cronograma de implantação e crescimento do tráfego

• O SCADA havia acabado de ser implantado no momento da sessão.
• O OMS foi indicado para entrada em 1º de setembro de 2026, com uma etapa adicional em 1º de outubro de 2026.
• O G3, já implantado, opera exclusivamente nos data centers de Minas Gerais, de modo que suas integrações não atravessam o enlace entre sites.
• A integração do G1 envolve o OMS no data center da Paraíba comunicando-se com os sistemas corporativos em Minas Gerais, cenário no qual a latência ganha importância.
• A expansão futura contempla a adição do G2, elevando progressivamente o tráfego entre os sites.

A avaliação da área foi de que a capacidade suportará bem o acréscimo, considerando a estimativa do tráfego atual e do que será adicionado, inclusive com a entrada do G2. Foi registrado, contudo, que essa avaliação é qualitativa e não decorre de projeção formal de volume por onda de implantação, o que integra as evidências solicitadas.

A referência de calendário citada na gravação foi interpretada como 1º de setembro e 1º de outubro de 2026, conforme o contexto da sessão e as demais atas. Convém confirmar formalmente o calendário e as distribuidoras associadas a cada onda.

1.14.7. Conectividade com ambientes de nuvem

Nuvem de dados	O tráfego ocorre atualmente pela internet pública. Não foi identificado enlace dedicado equivalente aos serviços de interconexão privada oferecidos pelo provedor.
Intenção de evolução	Foi mencionada a intenção de avaliar VPN ou enlace dedicado, tema que está com o arquiteto e o engenheiro da área de dados, sem implementação confirmada.
Segunda nuvem	Existe VPN estabelecida para um projeto específico. O projeto de força de trabalho que utiliza esse ambiente, porém, trafega pela internet pública.

Ponto de governança A conectividade por internet pública não implica, por si só, inadequação. Ela exige, entretanto, confirmação de criptografia, redundância, disponibilidade, acordo de nível de serviço, observabilidade, rotas de contingência e aderência aos requisitos de segurança correspondentes à criticidade de cada integração. Esse ponto se conecta ao registrado na Ata 11 sobre a ausência de monitoramento previsto para os componentes em nuvem: uma integração que trafega por internet pública e não é observada acumula duas lacunas na mesma cadeia.

1.14.8. Integrações entre sites e posicionamento do conector de captura

1.14.8.1. Natureza da comunicação

As integrações entre o ADMS e os sistemas corporativos utilizam chamadas de API e troca de eventos. Foi confirmado na sessão que também há o conector de captura de dados alterados, associado ao Confluent Kafka, já detalhado na Ata 12.

A distinção decisiva foi estabelecida durante a conversa. Enquanto o G3 opera integralmente nos data centers de Minas Gerais, e portanto suas integrações permanecem locais, o G1 coloca o OMS no data center da Paraíba comunicando-se com os sistemas corporativos que permanecem em Minas Gerais. É nessa configuração que a latência entre os sites passa a incidir sobre cada chamada e sobre a captura de eventos.

Preocupação declarada pela própria coordenação Foi registrado de forma explícita que a preocupação com a latência decorre justamente dessa configuração: quando a integração se dá entre o ambiente da Paraíba e os sistemas corporativos de Minas Gerais, o volume de eventos a serem produzidos e consumidos atravessa o enlace. Essa é a mesma dependência WAN sob o G1 registrada nas atas anteriores, agora confirmada pela perspectiva de rede, com o valor concreto de 60 a 70 milissegundos como referência.

1.14.8.2. Posicionamento atual dos componentes

• O Confluent Kafka e o conector de captura executam no OpenShift, no ambiente corporativo.
• A rede operacional, onde reside o ADMS, não possui, segundo o entendimento dos participantes, infraestrutura equivalente de orquestração de contêineres.
• Foi esclarecido que o conector de captura e o plugin que realiza a leitura das mudanças precisam operar juntos, de modo que aproximar a captura do banco implicaria implantar o próprio conector dentro do ambiente do ADMS.

1.14.8.3. Hipótese de aproximação ao banco de origem

A consultoria levantou que, em desenho ideal, o componente que lê as mudanças deveria estar próximo do banco de origem, e não do lado oposto do enlace. A avaliação foi acolhida pela coordenação, que registrou já ter considerado essa alternativa e tê-la levado à equipe de OpenShift na ocasião.

Reduz a exposição da captura à variação da rede entre os sites e diminui o atraso introduzido pela distância.	Exigiria implantar o conector dentro do ambiente operacional, que não dispõe de infraestrutura de orquestração de contêineres.
Aproxima a leitura do redo log e da fila de captura do ponto em que os eventos são gerados.	A observabilidade, a operação e a governança são centralizadas no ambiente corporativo, e a distribuição desses componentes contraria esse arranjo.
Reduz o risco de reconexão e de recuperação da captura após interrupções de enlace.	Aumentaria a superfície a operar dentro da rede operacional, com as restrições de segurança associadas.

O encaminhamento acordado foi aguardar as evidências de homologação. O primeiro OMS estava em teste no momento da sessão, e o comportamento observado na entrada em produção deve fornecer a medição concreta que hoje falta para decidir. Foi registrado consenso de que o tema constitui ponto de atenção, independentemente da decisão final.

Convergência com a Ata 12: o gargalo de vazão relatado pela administração de banco, com atraso de 10 a 20 minutos no consumo, foi atribuído à leitura sequencial e ao compartilhamento de infraestrutura entre cargas de criticidade distinta. A distância entre o conector e o banco de origem, discutida aqui, é um fator adicional a considerar no mesmo diagnóstico, e não uma explicação concorrente.

1.14.9. Continuidade do ADMS e recuperação de desastre corporativa

1.14.9.1. Dois modelos distintos de continuidade

A sessão explicitou uma assimetria que estrutura boa parte do risco arquitetural do ambiente.

ADMS	Ativo-ativo entre Minas Gerais e a Paraíba.	Manobras periódicas de chaveamento, com desativação da instância de uma distribuidora em Minas Gerais e operação por um período a partir da Paraíba. Alguns testes já foram realizados e a avaliação registrada é de que a prática está tranquila.	Confirmar escopo, frequência, resultados, objetivos de recuperação e cobertura das integrações durante o chaveamento.
Sistemas corporativos	Execução normal em Minas Gerais, com levantamento na Paraíba apenas em caso de desastre. Não é ativo-ativo.	Testes em ambiente isolado, no qual um sistema é selecionado e usuários e analistas acessam uma bolha segregada na Paraíba, com os bancos, o diretório e as demais dependências levantados para a verificação.	Nunca houve declaração real de desastre nem chaveamento integral de produção.

Foi descrito o funcionamento dos testes corporativos com detalhe: escolhe-se um sistema, citado como exemplo o faturamento de uma das distribuidoras, define-se um fim de semana, e os analistas de sustentação acessam uma bolha na Paraíba para verificar se os sistemas funcionam. Nessa bolha são levantados os bancos necessários, o diretório de identidade e os demais componentes. A afirmação registrada foi categórica: nunca foi decretado desastre e nunca houve chaveamento efetivo do ambiente corporativo, porque se trata de uma operação de grande porte.

Limite do teste em ambiente isolado Um teste conduzido em bolha segregada valida que os componentes sobem e que o sistema funciona isoladamente. Ele não exercita, necessariamente, as dependências reais de produção: resolução de nomes, rotas, autenticação, certificados, filas, APIs e integrações externas. Como o ADMS opera em modelo ativo-ativo e os sistemas corporativos não, um evento real de desastre colocaria em prova exatamente a camada que os testes atuais não cobrem, que é a integração entre os dois domínios. Este é o ponto que precisa ser levado à sessão específica de continuidade.

1.14.9.2. Proximidade entre bancos e aplicações

Um esclarecimento relevante foi obtido durante a conversa: no chaveamento do ADMS, os bancos acompanham os servidores de aplicação e permanecem próximos dos clientes, de modo que a operação a partir do site alternativo não introduz latência interna significativa para a própria aplicação. O impacto de latência não está, portanto, na operação do ADMS em si, e sim na sua comunicação com os sistemas corporativos que permanecem no outro site. Essa distinção delimita corretamente o escopo do risco.

1.14.9.3. Iniciativa de replicação dos sistemas corporativos

Foi mencionada a existência, no passado, de uma iniciativa de estudo para replicar os sistemas corporativos para João Pessoa, o que endereçaria diretamente a assimetria descrita. O estado atual dessa iniciativa não estava disponível na sessão e foi indicada a frente de segurança e continuidade como responsável pelo tema.

1.14.10. Replicação do banco corporativo

Foi informado, com ressalva expressa de que a confirmação depende da equipe responsável, que a replicação do banco Oracle entre os data centers utiliza Data Guard, informação que convergia com o que havia sido relatado na sessão do dia anterior.

A consultoria levantou a distinção que importa para o diagnóstico: um standby convencional mantém uma réplica que não pode ser consultada, enquanto a modalidade que permite leitura no ambiente secundário habilita usos adicionais. Não foi possível confirmar qual das duas está em uso, tampouco o modo de proteção adotado.

• Se a replicação for assíncrona, hipótese considerada provável em razão da distância, a latência amplia a janela de defasagem entre o primário e o secundário.
• Nessa configuração, uma falha abrupta pode implicar perda das transações ainda não transportadas, com impacto de consistência além da simples indisponibilidade.
• É necessário conhecer o modo de proteção, o transporte de redo, o atraso de transporte e de aplicação, o objetivo de ponto de recuperação e os procedimentos de chaveamento planejado e de failover.
• A verificação da consistência entre os bancos e as integrações dependentes deve integrar os testes de recuperação, e não apenas a disponibilidade isolada de cada componente.

O encaminhamento foi levar o questionamento novamente à equipe de banco de dados e à frente de continuidade, para confirmar a modalidade e os parâmetros efetivamente configurados.

1.14.11. Riscos, lacunas e pontos de atenção

Latência entre o OMS na Paraíba e os sistemas corporativos em Minas Gerais	Aumento do tempo de resposta das APIs, acúmulo de eventos, expiração de chamadas e degradação das jornadas integradas.	Alta
Conector de captura distante do banco de origem	Maior sensibilidade a variações de rede, atraso na captura, instabilidade e dificuldade de recuperação após interrupções.	Alta
Replicação do banco corporativo sem modo e parâmetros confirmados	Objetivos de recuperação desconhecidos e possível perda ou defasagem de dados no failover.	Alta
Testes de recuperação restritos a ambientes isolados	Dependências reais de produção, resolução de nomes, rotas, autenticação e integrações podem não ser exercitadas.	Alta
Entrada em produção do OMS sem critérios explícitos de aceite de integração	Problemas de desempenho ou de continuidade podem se manifestar apenas após a entrada em produção.	Alta
Ocupação dos enlaces sem linha de base unificada	Decisões apoiadas em números divergentes entre média e pico, com risco de saturação não percebida.	Média
Dependência de internet pública para parte das integrações em nuvem	Exposição a variação de rota, disponibilidade e ausência de acordo de nível de serviço adequado para cargas críticas.	Média
Segmentação entre TI e OT apoiada em VLAN até a conclusão do projeto de interconexão	Limitações de isolamento, de governança e de evolução da interligação entre os sites.	Média

1.14.12. Conclusões e encaminhamentos

1. Não foi identificada preocupação imediata de capacidade de rede que impedisse a entrada em produção do OMS no início de setembro.

2. A distância física explica a maior parte da latência observada. O terceiro enlace melhora resiliência e capacidade, mas não reduz o tempo de propagação.

3. O ambiente do ADMS foi considerado operacionalmente estável nos testes realizados, segundo as áreas de rede e de infraestrutura.

4. A principal preocupação técnica deslocou-se da capacidade de transporte para as integrações entre o OMS da Paraíba e os sistemas corporativos concentrados em Minas Gerais.

5. O posicionamento do conector de captura e a arquitetura de replicação devem ser reavaliados com as evidências de homologação.

6. A maturidade da recuperação de desastre corporativa e a configuração da replicação do banco precisam ser tratadas em sessão específica com as equipes responsáveis, ainda a agendar.

7. O desenho de topologia utilizado na sessão será disponibilizado na pasta de trabalho compartilhada do assessment.

1.14.13. Plano de ação recomendado

Disponibilizar o desenho atualizado de topologia, com versão e data	Infraestrutura e equipe do ADMS	Imediato	Arquivo versionado na pasta de trabalho do assessment
Extrair métricas de 30 a 90 dias dos enlaces, com média, pico, percentis, perda, variação de atraso e latência por direção	Redes e sustentação	Antes da entrada em produção do OMS	Painel ou relatório com linha de base e margem de capacidade
Executar teste ponta a ponta do OMS na Paraíba contra os sistemas corporativos em Minas Gerais	ADMS, integrações e redes	Durante a homologação	Tempos de resposta das APIs, vazão de eventos, acúmulo, erros e critérios de aceite
Validar a arquitetura do conector de captura e a proximidade ao banco de origem	Integrações, OpenShift e administração de banco	Antes da entrada do G1	Diagrama lógico e físico e decisão arquitetural registrada
Confirmar a configuração da replicação do banco corporativo	Administração de banco Oracle	Próxima sessão de continuidade	Modo de proteção, transporte, atraso, objetivos de recuperação e procedimento documentado
Mapear os testes de recuperação já executados e o cronograma futuro	Segurança e continuidade	Próxima sessão de contingência	Plano de testes, resultados, pendências e cobertura das dependências
Avaliar conectividade dedicada ou VPN para as cargas críticas em nuvem	Nuvem, redes e segurança	Plano de evolução	Análise de risco, custo, acordo de nível de serviço e decisão
Confirmar escopo, cronograma e impacto do projeto de interconexão e do terceiro enlace	Infraestrutura	Após a assinatura contratual	Roteiro de implantação e migração até março de 2027

1.14.14. Questões para as próximas sessões

1. Qual é a versão oficial e atualizada da topologia, incluindo enlaces, firewalls, VLANs, rotas, sites e componentes do ADMS e do OMS?

2. Os dois enlaces de 10 Gbit/s operam em modo ativo-ativo, com balanceamento, ou em modo primário e secundário? Qual é a capacidade efetivamente utilizável?

3. Quais são a média, o pico e os percentis de referência de ocupação, latência, variação de atraso e perda de pacotes, por direção?

4. Qual é o acordo de nível de serviço contratado e medido para os enlaces atuais e para a proposta que promete latência inferior a 50 milissegundos?

5. Qual é o escopo do terceiro enlace e como ele será integrado à política de roteamento e de failover?

6. Quais APIs do OMS são síncronas e quais limites de tempo de espera, novas tentativas e disjuntor foram definidos?

7. Qual volume de eventos por segundo e qual tamanho médio de mensagem são esperados por onda de implantação?

8. Onde estão fisicamente o conector de captura e o componente de leitura das mudanças em relação ao banco de origem e ao cluster do barramento?

9. Como o conector de captura reage a falha do banco principal, a mudança de endereço ou de resolução de nomes e ao chaveamento para o site secundário?

10. Qual é a configuração exata da replicação do banco corporativo: modo de proteção, transporte, modalidade com leitura no secundário e limites de atraso?

11. Quais objetivos de tempo e de ponto de recuperação foram aprovados para o ADMS, o OMS, o ambiente corporativo e as integrações?

12. Os testes em ambiente isolado exercitam resolução de nomes, autenticação, certificados, filas, APIs, rotas e dependências externas?

13. Existe plano para um teste integrado de chaveamento, com participação das áreas de negócio e de operação?

14. Quais critérios objetivos autorizarão a entrada em produção do OMS em setembro e a etapa de outubro?

1.14.15. Conclusão do assessment desta sessão

Esta foi a sessão mais curta do ciclo de levantamento e, ainda assim, uma das mais úteis para delimitar o risco. Ela permitiu descartar uma hipótese que atravessava as atas anteriores, a de que a capacidade de rede entre os data centers pudesse ser o gargalo das integrações sob o G1, e confirmar, com número concreto, o fator que efetivamente incide sobre elas.

A latência de 60 a 70 milissegundos não é um defeito a corrigir: é uma consequência da distância entre os sites, e nem a contratação de um terceiro enlace nem o projeto de interconexão a eliminarão. O que a torna relevante é a assimetria de arquitetura. Enquanto o ADMS opera em modelo ativo-ativo e pode responder a partir de qualquer um dos dois data centers, os sistemas corporativos com os quais ele se integra permanecem concentrados em Minas Gerais. Sob o G1, com o OMS na Paraíba, atravessar o enlace deixa de ser exceção e passa a ser a configuração normal de operação.

Duas consequências decorrem disso e devem ser incorporadas ao diagnóstico consolidado. A primeira é que o posicionamento do conector de captura, hoje no ambiente corporativo e distante do banco de origem, precisa ser reavaliado com as medições de homologação, somando-se às causas já identificadas na Ata 12 para o atraso observado no consumo. A segunda é que a maturidade da recuperação de desastre corporativa, exercitada apenas em ambientes isolados e nunca em chaveamento integral, deixa sem verificação exatamente a camada de integração entre os dois domínios, que é onde a assimetria se manifesta.

A área de rede não apresentou dor, e essa constatação tem valor próprio: ela indica que o esforço de mitigação deve concentrar-se no desenho das integrações e na estratégia de continuidade, e não na expansão da infraestrutura de transporte.

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. Como a associação automática entre rótulos de falante e pessoas não se manteve estável, as falas são atribuídas por papel funcional. A conversa inicial de abertura, saudações, sobreposições, problemas de compartilhamento de tela e trechos corrompidos pelo reconhecimento automático de voz foram condensados ou omitidos, e os termos técnicos capturados de forma imprecisa foram normalizados quando o contexto permitiu identificação segura.

00:00:29 Participantes: Na abertura informal, os participantes informam suas localidades: parte da equipe em Minas Gerais, um participante em Campo Grande, outro em João Pessoa e a consultoria no Rio de Janeiro.

00:01:41 Coordenação Energisa: Contextualiza o assessment: desde a implantação do ADMS houve um período de contingência, com atrasos de processamento, e algumas lacunas específicas precisavam ser tratadas.

00:02:06 Coordenação Energisa: Registra que, em conversa com a gestão e a equipe do projeto, foi solicitada a revisão de pontos da arquitetura, principalmente da integração ponta a ponta.

00:02:16 Coordenação Energisa: Informa que já foram realizadas cerca de treze reuniões com equipes distintas, passando por desenvolvimento, dados e OpenShift, uma a uma, em busca de pontos de melhoria. Apresenta a consultoria, com a gestão do assessment e o arquiteto.

00:02:49 Coordenação Energisa: Reforça o convite para que a área traga suas dores ou qualquer questão relacionada às integrações que envolvem o ADMS.

00:03:03 Consultoria: Registra que as dores são importantes e que, havendo implantação próxima, as preocupações relativas ao momento de entrada em produção também interessam, porque introduzem elementos novos.

00:03:27 Consultoria: Solicita a apresentação da topologia para iniciar a conversa.

00:03:42 Redes: Observa que a topologia e a arquitetura mais atualizadas devem estar com a coordenação, em razão do barramento de integração.

00:04:59 Coordenação Energisa: Compartilha o desenho encontrado e solicita a confirmação das equipes sobre ser o mais recente.

00:05:08 Redes: Confirma que o ambiente está exatamente conforme o desenho apresentado.

00:05:13 Coordenação Energisa: Identifica a autoria do desenho e informa que foi compartilhado internamente antes de chegar à sessão.

00:05:30 Redes: Descreve a topologia: existe um caminho do ADMS, referido como firewall de borda, que atende ao ambiente do ADMS.

00:05:47 Redes: Detalha os enlaces: basicamente dois enlaces de 10 Gbit/s entre Minas Gerais e a Paraíba, em ligação entre redes locais.

00:05:55 Redes: Explica que os enlaces saem diretamente dos switches do ambiente e que existe uma conexão de camada 3 entre o firewall do ADMS de Minas Gerais e o firewall do ADMS da Paraíba.

00:06:16 Redes: Esclarece que o firewall não é dedicado ao ADMS.

00:06:23 Redes: Registra que toda a replicação entre os dois sites passa por essa mesma infraestrutura.

00:06:35 Consultoria: Pergunta se esse compartilhamento tem algum impacto sobre o ADMS e sobre o barramento.

00:06:51 Coordenação Energisa: Contextualiza o cronograma: a implantação que envolve o SCADA está em curso para o G1, o G3 já foi implantado e opera exclusivamente nos data centers de Minas Gerais.

00:07:08 Coordenação Energisa: Detalha o que trafega pelo enlace: as replicações referentes à recuperação de desastre e ao chaveamento do ADMS, e também as replicações dos dados corporativos, para que possam ser levantados na Paraíba em caso de desastre.

00:07:23 Coordenação Energisa: Registra que o ADMS é ativo-ativo e que, portanto, as aplicações passam por esse enlace, inclusive as replicações dos bancos discutidos na sessão do dia anterior com as equipes de administração de banco de dados.

00:07:49 Redes: Complementa que o enlace é compartilhado por todo o ambiente de data center, com o principal do grupo em Cataguases e o ambiente de recuperação de desastre em João Pessoa.

00:08:03 Redes: Ressalta que, nesse enlace entre redes locais, a separação entre a rede de TI e a rede de tecnologia operacional é feita por identificador de VLAN, e informa que existe um processo de contratação em andamento para implementar a interconexão de data centers, ainda não iniciada.

00:08:32 Redes: Consulta a área de infraestrutura sobre o estágio dessa contratação.

00:08:37 Infraestrutura: Informa que o processo está em fase de assinatura de contrato, com vencedor já definido e ainda não divulgado.

00:08:48 Redes: Pergunta se a previsão de implementação é para o ano corrente.

00:08:51 Infraestrutura: Responde que o prazo é até março do ano seguinte.

00:09:02 Infraestrutura: Detalha que a infraestrutura deve ser instalada ainda no ano corrente, mas que as migrações estão previstas para finalizar até março do ano seguinte.

00:09:17 Consultoria: Pergunta se a área possui alguma dor ou problema nesse ambiente.

00:09:23 Redes: Responde que não, à exceção do risco inerente à replicação como um todo.

00:09:27 Consultoria: Observa que o ambiente parece bastante confiável.

00:09:36 Coordenação Energisa: Informa que o SCADA acabou de ser implantado e que o próximo é o OMS, previsto para o dia primeiro de setembro, com uma etapa seguinte em primeiro de outubro.

00:09:45 Coordenação Energisa: Avalia que o enlace suportará bem o acréscimo, considerando a quantidade estimada de tráfego.

00:10:00 Coordenação Energisa: Compara a estimativa do que já trafega com o que será adicionado, inclusive com a entrada futura do G2, e avalia que a capacidade deve estar com bastante folga.

00:10:22 Coordenação Energisa: Pergunta à infraestrutura se o projeto de interconexão prevê aumento desses enlaces.

00:10:33 Infraestrutura: Responde que não faz parte daquele projeto, mas que existe uma iniciativa paralela de ampliação, conduzida separadamente, cujo detalhamento não está disponível no momento.

00:10:49 Consultoria: Pergunta como é a conectividade quando o tráfego se destina ao ambiente de nuvem.

00:10:52 Coordenação Energisa: Informa que a comunicação é direta, saindo pela própria internet.

00:10:56 Consultoria: Pergunta se existe algum enlace dedicado com o provedor de nuvem.

00:10:58 Redes: Responde que não existe serviço de interconexão privada com aquele provedor e que, para esse destino, o tráfego é pela própria internet.

00:11:08 Coordenação Energisa: Registra que o tema deve ser tratado com a equipe de dados, que possui arquiteto e engenheiro dedicados, e que existe previsão de avaliar uma VPN ou um enlace dedicado, ainda não implementado.

00:11:23 Consultoria: Pergunta sobre a conectividade com o segundo provedor de nuvem.

00:11:26 Coordenação Energisa: Informa que existe VPN para um projeto específico, mas que o projeto de força de trabalho, que também utiliza esse ambiente, trafega pela internet.

00:12:01 Consultoria: Retoma a análise a partir do desenho apresentado.

00:12:15 Consultoria: Passa ao tema da contingência, buscando confirmar o modelo ativo-ativo do ADMS e como é feita a movimentação de dados entre os sites.

00:12:40 Coordenação Energisa: Informa que a movimentação é realizada pela solução própria do ADMS, e não por mecanismo do banco de dados, e recorda a documentação já compartilhada sobre esse ponto.

00:13:05 Consultoria: Avalia que a latência não deve representar problema para a operação da própria plataforma e questiona os valores praticados.

00:13:14 Coordenação Energisa: Registra que, em razão da distância, a latência observada está entre 60 e 70 milissegundos.

00:13:21 Redes: Contextualiza que a distância entre os sites supera três mil quilômetros e que não há como reduzir significativamente essa latência.

00:13:34 Consultoria: Menciona uma avaliação técnica recente de proposta de fornecedor.

00:13:38 Coordenação Energisa: Informa que a proposta técnica desse fornecedor garante latência inferior a 50 milissegundos.

00:13:44 Redes: Registra ceticismo quanto ao compromisso apresentado.

00:13:51 Consultoria: Observa que a área de rede é a mais indicada para reportar eventual desvio em relação ao contratado.

00:13:57 Redes: Confirma que o valor praticado hoje está entre 60 e 70 milissegundos.

00:14:03 Coordenação Energisa: Recorda a previsão de um terceiro enlace.

00:14:06 Redes: Confirma que está em implantação, mas ressalva que não reduzirá significativamente a latência, porque um dos principais fatores é a distância.

00:14:19 Consultoria: Pergunta se a área tem alguma preocupação relevante quanto à implantação prevista para o início de setembro e se tudo está endereçado.

00:14:46 Redes: Responde que, do ponto de vista da sustentação e da operação de redes, a ocupação do enlace está abaixo de 50%, ressalvando que fala especificamente da sua área e não da sustentação da aplicação.

00:15:11 Infraestrutura: Informa que o pico do enlace fica em torno de 50% de ocupação.

00:15:17 Redes: Esclarece que o valor que havia citado era de ocupação média e menciona faixas de 60% e 70%.

00:15:23 Consultoria: Passa ao tema da recuperação de desastre, registrando que também é uma preocupação.

00:15:37 Redes: Informa que a equipe do ADMS realiza manobras com certa frequência, referidas como testes de chaveamento entre sites.

00:15:46 Coordenação Energisa: Detalha o procedimento: marca-se um horário, desativa-se a instância da distribuidora em Minas Gerais e opera-se por um período a partir da Paraíba.

00:15:55 Consultoria: Registra que alguns testes já foram feitos e que, até onde tem conhecimento, essa parte está tranquila.

00:16:24 Consultoria: Avalia que a solução é adequada, uma vez que os bancos ficam próximos dos servidores de aplicação e dos clientes, de modo que a operação não é muito impactada pela distância.

00:16:43 Consultoria: Detalha o entendimento: sendo ativo-ativo, quando se chaveia para o outro site, opera-se lá, e os bancos acompanham os servidores, de modo que não há impacto de latência para a própria aplicação.

00:17:01 Coordenação Energisa: Introduz a ressalva decisiva: quando se trata dos sistemas corporativos, esses sistemas rodam exclusivamente em Minas Gerais.

00:17:26 Coordenação Energisa: Explicita a consequência: ao integrar com o ADMS da Paraíba, a questão da latência incide sobre essa comunicação.

00:17:31 Consultoria: Confirma o entendimento e associa o efeito ao volume de eventos que precisam ser enviados e consumidos através do enlace.

00:17:38 Coordenação Energisa: Confirma que essa era exatamente a preocupação.

00:17:40 Consultoria: Pergunta se os sistemas corporativos sempre executam em Minas Gerais.

00:17:43 Coordenação Energisa: Confirma, ressalvando que, em caso de desastre nos sistemas corporativos, eles são levantados na Paraíba. Registra que ali não é ativo-ativo: o levantamento ocorre no momento em que se declara a recuperação de desastre, com um período necessário para subir tudo, e informa que ainda há reunião a agendar com a equipe que trata desse tema.

00:18:11 Coordenação Energisa: Delimita o escopo da conversa ao que está em operação, citando o G3 como primeiro agrupamento implantado.

00:18:25 Coordenação Energisa: Reforça a distinção: quando se fala da integração com o G1, trata-se da integração entre o que está no data center da Paraíba e os sistemas corporativos que estão em Minas Gerais, e aí sim incide a latência da comunicação.

00:18:41 Consultoria: Pergunta se essa comunicação ocorre apenas por eventos ou também por chamada de API.

00:18:47 Coordenação Energisa: Responde que ocorre por chamada de API e também pelo conector de captura de dados alterados utilizado no ambiente.

00:19:02 Consultoria: Pergunta onde esse conector está posicionado: junto ao ADMS ou na rede corporativa.

00:19:11 Coordenação Energisa: Informa que está junto com o Confluent Kafka, tudo dentro do OpenShift, que fica na rede corporativa. O ambiente do ADMS não possui essa infraestrutura.

00:19:21 Coordenação Energisa: Complementa que não existe orquestrador de contêineres na rede de tecnologia operacional, até onde tem conhecimento.

00:19:43 Consultoria: Observa que, em teoria, o ideal seria que o componente de leitura das mudanças estivesse próximo do banco de origem.

00:19:54 Consultoria: Detalha que o restante da cadeia pode ficar mais apartado, mas que o componente de captura deveria estar próximo da origem.

00:19:59 Coordenação Energisa: Explica a restrição técnica observada na implantação: o conector do barramento e o plugin de leitura precisam operar juntos, de modo que aproximar a captura implicaria implantar o próprio conector dentro do ambiente do ADMS.

00:20:19 Coordenação Energisa: Registra que levou essa alternativa à equipe de OpenShift na época, e que a objeção envolvia observabilidade e uma série de outras questões que são tratadas de forma centralizada no ambiente corporativo.

00:20:45 Coordenação Energisa: Informa que a decisão dependerá do comportamento observado quanto à latência, uma vez que os testes estão em curso e o primeiro OMS está em homologação, e manifesta concordância com a avaliação da consultoria.

00:21:07 Consultoria: Registra que o tema constitui ponto de atenção.

00:21:11 Consultoria: Passa à contingência do ambiente corporativo, observando que a maior parte de suas aplicações está concentrada em um dos sites.

00:21:21 Consultoria: Pergunta qual mecanismo é utilizado para a replicação do banco.

00:21:29 Coordenação Energisa: Informa que, para a replicação do banco Oracle entre Minas Gerais e a Paraíba, acredita tratar-se de Data Guard, conforme comentado pela equipe de banco na sessão anterior.

00:21:43 Consultoria: Questiona qual modalidade está em uso, distinguindo a configuração que permite consulta no ambiente secundário daquela em que o banco de réplica permanece indisponível para uso.

00:21:57 Coordenação Energisa: Registra que a informação recebida foi apenas o nome do mecanismo e que a modalidade exata pode ser questionada novamente à equipe responsável.

00:22:11 Consultoria: Observa que a latência também pode influenciar, uma vez que provavelmente a replicação opera em modo assíncrono.

00:22:25 Consultoria: Explicita a consequência: em uma falha, pode haver perda ou defasagem de dados, além de questão de consistência.

00:22:46 Consultoria: Pergunta se já ocorreu algum desastre real em que o ambiente corporativo tenha sido levantado.

00:22:59 Coordenação Energisa: Responde que, em produção, não ocorreu, e que sabe que estão sendo feitos testes, sem dispor dos detalhes.

00:23:15 Consultoria: Registra que o tema será tratado em reunião específica com a frente de contingência e que este é o ponto de atenção da sessão.

00:23:32 Consultoria: Sintetiza a recomendação para mitigação: o componente de leitura das mudanças e o conector deveriam estar próximos da origem dos dados.

00:23:52 Coordenação Energisa: Recorda que houve, há algum tempo, uma iniciativa de estudo para replicar todos os sistemas corporativos para João Pessoa.

00:24:09 Coordenação Energisa: Indica a frente responsável pelo tema, associada à equipe de segurança, como a que normalmente lidera essa iniciativa.

00:24:28 Redes: Afirma de forma categórica que nunca houve recuperação de desastre efetiva com chaveamento para o outro site, e que o que se faz são testes em bolha.

00:24:45 Redes: Descreve o procedimento: escolhe-se um sistema, citando como exemplo o faturamento de uma das distribuidoras, e define-se um fim de semana para o teste.

00:24:54 Redes: Detalha que os usuários e os analistas de sustentação do sistema acessam uma bolha segregada na Paraíba, para verificar se os sistemas estão funcionando.

00:25:14 Redes: Complementa que, nesse ambiente, são levantados todos os bancos necessários ao sistema, o diretório de identidade e os demais componentes, e então o teste é realizado.

00:25:27 Redes: Reforça que nunca foi decretada recuperação de desastre, por se tratar de uma operação de grande porte, e que o que existe é a realização periódica desses testes.

00:25:38 Coordenação Energisa: Confirma que esse ambiente de teste é apartado e segmentado.

00:25:40 Redes: Confirma que se trata de ambiente em bolha.

00:25:43 Consultoria: Confirma o entendimento de que não se realiza um chaveamento efetivo do ambiente.

00:25:49 Redes: Reafirma que isso nunca ocorreu no ambiente corporativo.

00:25:57 Coordenação Energisa: Avalia ser importante entender com a frente responsável qual é a situação atual e o cronograma.

00:26:10 Redes: Ressalva que a confirmação definitiva cabe à equipe de segurança, responsável pelo tema.

00:26:25 Consultoria: Sintetiza o impacto: a preocupação recai sobre os eventos gerados pela captura, que deveriam estar próximos da origem.

00:27:02 Consultoria: Registra que o quadro ficou claro e avalia positivamente a sessão.

00:27:07 Consultoria: Solicita que o desenho de topologia seja disponibilizado na pasta de trabalho compartilhada do assessment.

00:27:21 Coordenação Energisa: Confirma o compartilhamento, identificando a autoria do material.

00:27:24 Redes: Pondera sobre eventual restrição de segurança para o compartilhamento, avaliando que o material descreve o ambiente de forma adequada para o entendimento pretendido.

00:27:41 Coordenação Energisa: Agradece a participação e encerra a sessão.

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

A transcrição automática apresenta qualidade reduzida em termos técnicos e nomes próprios. Nesta ata, os elementos foram descritos preferencialmente por sua função e os termos abaixo são registrados para confirmação antes de constarem em desenho de arquitetura ou em decisão formal.

Ligação entre redes locais	Enlace de camada 3 entre os data centers, apoiado em dois circuitos de 10 Gbit/s.	A expressão aparece corrompida em diversos trechos da transcrição.
Firewall de borda	Equipamento de borda que atende ao ambiente do ADMS em cada site.	Foi esclarecido que não é dedicado ao ADMS. A nomenclatura oficial deve ser confirmada.
Interconexão de data centers	Projeto de modernização da interligação entre os sites, com contratação em fase de assinatura.	Cronograma e escopo a confirmar após a formalização contratual.
Componente de leitura das mudanças	Plugin de captura de dados alterados que opera junto ao conector do barramento.	A transcrição registra o termo de formas variadas e foneticamente distantes. Corresponde ao componente tratado na Ata 12.
Serviço de interconexão privada com a nuvem	Enlace dedicado com o provedor de nuvem, inexistente no ambiente.	O termo aparece corrompido na transcrição.
Chaveamento entre sites	Manobra de transferência da operação do ADMS entre os data centers.	Referida na sessão por expressões variadas. Corresponde ao mecanismo do fornecedor tratado na Ata 12.
Data Guard	Mecanismo de replicação do banco Oracle entre os sites.	Informado com ressalva. A modalidade, o modo de proteção e o tipo de transporte precisam ser confirmados.
Teste em bolha	Verificação conduzida em ambiente isolado no site secundário, com levantamento dos componentes necessários.	Prática descrita com clareza na sessão. O escopo e o cronograma devem ser obtidos com a frente responsável.
Proposta de fornecedor de telecomunicações	Proposta técnica com compromisso de latência inferior a 50 milissegundos.	Fornecedor e escopo da proposta a confirmar.

Além dos termos, os seguintes dados quantitativos foram registrados como informados e devem ser confirmados por medição:

• A capacidade de dois enlaces de 10 Gbit/s e o estágio de implantação do terceiro enlace.
• A ocupação informada, que variou entre menos de 50% e 70% conforme o critério adotado.
• A latência de 60 a 70 milissegundos e a distância superior a três mil quilômetros entre os sites.
• O compromisso de latência inferior a 50 milissegundos apresentado em proposta técnica.
• As datas de 1º de setembro e de 1º de outubro de 2026 para as etapas de entrada em produção do OMS.
• O prazo de março de 2027 para a conclusão das migrações do projeto de interconexão.

1.14.16. Observações finais

Esta ata foi consolidada a partir de dois documentos referentes à mesma sessão: o relatório técnico produzido sobre a reunião e a transcrição integral da gravação. Os temas foram unificados por assunto, preservando o conteúdo das duas fontes, incluindo os pontos em que a transcrição traz detalhe adicional, entre eles a razão técnica pela qual o conector e o componente de captura precisam operar juntos, a objeção da equipe de plataforma quanto à descentralização da observabilidade, a menção à iniciativa anterior de replicar os sistemas corporativos para o site secundário e a descrição detalhada do funcionamento dos testes em ambiente isolado.

A atribuição nominal das falas não foi aplicada no registro cronológico porque a gravação não oferece base segura para associar todas as vozes aos nomes citados. Os participantes estão identificados no item 1.14.2, com a ressalva correspondente. As classificações de severidade, as prioridades do plano de ação e as estimativas têm caráter indicativo e serão refinadas com as medições solicitadas e com as sessões de continuidade e de dados já acordadas.