Disaster Recovery: Continuidade do ADMS e dos Sistemas Corporativos¶
Projeto: DSB26201 — Avaliação de arquitetura de integração ADMS (Energisa) Fonte: Reuniao-DR — "Assessment Integração ADMS - DR Sistemas Corporativos (Consultoria Syntropy)" (VTT, 03/08/2026, ~22min) Status: Rascunho para validação — sem Ata consolidada correspondente (sessão mais recente do assessment; ainda não incorporada ao Assessment_Consolidado, que hoje termina na Ata 14) Elaborado por: Consultoria Syntropy
Aviso metodológico¶
Diferente de todos os artefatos anteriores deste ciclo, este documento foi construído exclusivamente a partir da transcrição (VTT), sem uma Ata consolidada para cruzamento de fidelidade — a sessão é a mais recente do assessment e a Ata correspondente ainda não foi redigida. Por isso, a seção de achados abaixo chama-se "Achados de transcrição" em vez de "Achados de fidelidade": não há uma segunda fonte independente para corroborar ou contestar nomes, números e afirmações. Trechos com identificação automática de falantes ambígua ou com termos foneticamente incertos estão marcados como tal. Recomenda-se tratar este artefato como insumo para a futura Ata, não como substituto dela.
Por que este artefato existe¶
A sessão discutiu a governança de testes de disaster recovery (DR) do ADMS e, principalmente, a contingência dos sistemas corporativos que se integram a ele — tema que a própria Ata 13 (Rede e Telecomunicações) já havia identificado como lacuna: os sistemas corporativos rodam apenas em Minas Gerais e nunca tiveram um chaveamento integral testado, ao contrário do ADMS, que é ativo-ativo entre Cataguases (MG) e João Pessoa (PB).
Participou "Mike", apresentado como ponto focal da Prática — a Central de Chamados de TI da Energisa, capturada de forma imprecisa no VTT como "Gotik" (corrigido em 05/08/2026, confirmado por Castellani) — que junto com "Marcos" garante a execução dos testes de desastre. Norberto e Castellani conduziram a análise arquitetural; Vladimir acompanhou o registro. Foram citados, sem participação direta: Renan (equipe que executa os testes na ponta), Marcos Paulo (planejamento), Fabiano, Carlos André e Valéria (equipe de DevOps/OpenShift) e Erica (interlocutora com a Schneider, fornecedora do ADMS).
O valor da sessão está em expor, com detalhe operacional, como funciona hoje o teste de continuidade dos sistemas corporativos — e em confirmar, na fala dos próprios participantes, o achado que a Ata 13 já havia sinalizado: a dependência entre ADMS e sistemas corporativos não é testada de ponta a ponta, porque cada um tem seu próprio ciclo de teste.
Diagrama 1 — Continuidade: ADMS ativo-ativo vs sistemas corporativos em bolha de DR¶
O ADMS já opera em modelo ativo-ativo entre os dois data centers, testado com regularidade (achado já registrado na Ata 13). Os sistemas corporativos seguem um modelo diferente: rodam em produção em Cataguases e são replicados de forma contínua — banco de dados e aplicação — para João Pessoa por um link agregado (3 links em agregação, segundo a fala do participante). Essa réplica fica desligada, pronta, mas inativa: é o que a própria equipe chama de "bolha".
Dois tipos de teste foram descritos. O "site suíte local" corta toda a conectividade com Minas Gerais e sobe a Paraíba isoladamente — é o cenário que mais se aproxima de um desastre real ("imagina que perdemos Cataguases, caiu um meteoro lá"), mas não foi executado em 2026 para os grupos 1 e 3, por orientação da própria Schneider, fornecedora do ADMS, que sinalizou risco de perda de dados nesse cenário. O "site suíte global" mantém a conectividade e apenas promove a Paraíba a ambiente principal — foi o teste efetivamente realizado este ano.
Diagrama 2 — Dois tipos de teste de DR: local (isolado) vs global (promoção)¶
Um ponto relevante para o assessment: a decisão de não fazer o teste local em 2026 não foi tomada pela equipe interna, mas por orientação explícita da Schneider — que apontou risco de perda de dados no cenário isolado. Na própria sessão, um participante reconhece que a equipe ainda está "alinhando com a Schneider" o motivo técnico dessa orientação, com e-mails trocados mas sem explicação conclusiva. Isso é relevante como possível ponto de dependência de fornecedor a se aprofundar em uma sessão futura, e não deveria ser lido como uma limitação técnica da Energisa.
Diagrama 3 — Ativação da bolha de DR corporativa e aspiração de redução do RTO¶
O procedimento de ativação envolve cortar a replicação, desabilitar as comunicações de rede de produção, ligar as VMs e bancos replicados e ajustar configurações locais (nomes TNS, Citrix, permissionamento) até reconstruir uma rede que simule Cataguases dentro de João Pessoa. Segundo a equipe, esse procedimento "tem dado certo".
O RTO declarado hoje é de 24 horas para subir as aplicações críticas, conforme o "plano tecnológico" vigente — sem que a sessão detalhasse esse plano em profundidade. Foi mencionada, como ideia ainda não formalizada, a possibilidade de replicar o serviço propriamente dito (como já ocorre para Redis e Mongo) em vez de replicar a VM inteira, o que reduziria esse tempo — mas trata-se de algo "anotado" para acompanhamento futuro, não de um projeto em andamento. Um modelo ativo-ativo para os sistemas corporativos já foi estudado, mas não avançou por causa do custo de licenciamento dos diversos componentes envolvidos.
Vale destacar um dado de maturidade histórica citado na sessão: o escopo de aplicações testadas cresceu de cerca de 45 (há 3-4 anos) para mais de 70 hoje — um indicador de evolução contínua do programa de testes, ainda que sem estar diretamente ligado ao achado central desta sessão.
Achados de transcrição¶
1. Resolvido (05/08/2026): "Gotik" era "Prática". Mike se apresenta como ponto focal "pela pela gotik, juntamente com o Marcos" — erro de reconhecimento de fala confirmado por Castellani: o termo é Prática, a Central de Chamados de TI da Energisa, não uma sigla organizacional nem nome de fornecedor. Corrigido nesta rodada; não deve mais ser tratado como termo em aberto em Atas futuras.
2. Possível erro de ASR: "com essa Elaine". No encerramento, um participante pergunta "Tem mais alguma coisa com essa Elaine?" — não há nenhuma "Elaine" citada em qualquer outro ponto da sessão, nem uma introdução prévia com esse nome. É plausível que seja um erro de transcrição de uma expressão como "com isso" ou similar, mas diferente dos casos "Alberto"/Norberto já resolvidos em sessões anteriores, aqui não há elemento de contexto (fala anterior de alguém com nome parecido) que sustente uma hipótese de resolução. Fica como questão em aberto, não como fabricação.
3. Nova ocorrência de "Alberto" — mas provavelmente não é o mesmo fenômeno das sessões anteriores. Aos ~18:41 aparece: "a gente conseguir fazer algo é no Alberto mais mais ativo, cara" — no contexto de uma discussão sobre tornar o ambiente "mais ativo" (ativo-ativo). Diferente das ocorrências anteriores de "Alberto" (que eram substituições de "Norberto" em falas atribuíveis a uma pessoa), esta parece ser o reconhecimento de fala confundindo "ADMS" (ou "ativo") com "Alberto" dentro de uma frase sobre arquitetura — não uma referência a pessoa. Vale registrar como uma segunda manifestação distinta do mesmo padrão de erro de ASR sobre essa palavra, não como a mesma ocorrência.
4. Expressão de sentido obscuro: "entende o Nordeste?" (~11:54). Não há contexto geográfico ou organizacional na sessão que explique essa referência a "Nordeste" — é provável que seja um erro de transcrição de uma expressão coloquial (como "entende o que eu digo?"), mas isso é uma hipótese, não uma confirmação.
5. Convergência direta com a Ata 13 (Rede e Telecomunicações). A descrição desta sessão sobre sistemas corporativos rodarem exclusivamente em Minas Gerais, sem ativo-ativo, e sobre a "bolha" isolada nunca ter sido um chaveamento integral real, é idêntica em substância ao que a Ata 13 já havia registrado de forma independente (sessão de 29/07, dez dias antes). Essa é uma corroboração forte entre duas sessões distintas, com interlocutores parcialmente diferentes — aumenta a confiança de que a caracterização do problema está correta, ainda que, por não haver Ata desta sessão, não seja tecnicamente uma corroboração "Ata-a-Ata" no mesmo sentido das anteriores.
6. Sem inconsistências numéricas identificadas. Os números citados (link agregado, RTO de 24h, evolução de 45 para 70+ aplicações testadas, cronograma de testes de agosto/setembro de 2026) não apresentam contradição interna dentro da própria sessão. Não há, porém, uma segunda fonte para confirmá-los.
Próximo passo¶
Como não existe ainda uma Ata consolidada para esta sessão, o primeiro próximo passo é metodológico: incorporar este levantamento à consolidação formal (Ata 15, presumivelmente), com validação dos termos incertos apontados acima diretamente com os participantes — o item 1 ("Gotik"/Prática) já está resolvido e pode ser incorporado diretamente. Em paralelo, do ponto de vista de conteúdo, a própria sessão sugere dois encaminhamentos concretos: (1) uma conversa com a equipe de DevOps (Carlos André, Valéria) sobre a replicação via OpenShift, já sinalizada como prioridade pelos participantes; e (2) o esclarecimento pendente com a Schneider sobre a recomendação de evitar o teste "site suíte local" — pendência que, combinada com o achado central desta sessão (testes de DR do ADMS e dos sistemas corporativos desacoplados), reforça a necessidade já apontada pela Ata 13 de uma sessão específica dedicada à continuidade de negócio de ponta a ponta.