Ata 07 · Integrações do Sistema de Manutenção com ADMS e DMS, Kafka, OpenShift e Contingência (13 de julho de 2026)¶
Ata unificada, consolidada a partir da compilação detalhada da reunião e da transcrição da gravação.
| Data | 13 de julho de 2026 |
| Horário | 15h00 às 15h32, com início da gravação registrado às 15h03 |
| Duração aproximada | Entre 28 e 31 minutos, conforme a fonte |
| Contexto | Assessment da arquitetura de integrações do projeto ADMS da Energisa |
| Tema central | Integrações do sistema de manutenção com o ADMS e DMS, uso do Kafka como barramento, execução no OpenShift, escalabilidade e comportamento em contingência |
| Gravação | Vladimir Morozowski de Sousa |
| Cliente | Energisa (distribuição de energia) |
| Fornecedor | Syntropy Labs |
| Fontes | Compilação detalhada da reunião e transcrição da gravação |
Nota de consolidação das fontes Esta ata unifica dois documentos produzidos sobre a mesma sessão: a compilação detalhada, organizada em 26 blocos temáticos, e a transcrição da gravação. O conteúdo temático segue a estrutura da compilação, enriquecido com os nomes de sistemas, números e referências que constam apenas na transcrição. O registro cronológico revisado consta no Anexo A. Há divergência de registro quanto à duração: a compilação indica 15h00 às 15h32, com aproximadamente 31 minutos, enquanto o cabeçalho da transcrição informa 28 minutos e 8 segundos, com início da gravação às 15h03. A diferença corresponde, provavelmente, ao intervalo entre o início da reunião e o início da gravação. A transcrição foi produzida por reconhecimento automático de voz e apresenta corrupção relevante de nomes de sistemas e de pessoas, além de interjeições em inglês inseridas indevidamente. Os termos normalizados e os que permanecem em dúvida constam no Anexo B. |
Índice desta ata¶
- Objetivo da reunião
- Participantes e pessoas mencionadas
- Reuniões técnicas subsequentes
- Contextualização do sistema de manutenção
- Escopo funcional da integração
- Arquitetura técnica apresentada
- Fluxo de envio das ordens e solicitações de serviço
- Fluxo de retorno do ADMS e DMS
- Origem das manutenções
- Diferença entre manutenção programada e incidente
- Ciclo de vida das ordens de manutenção
- Identificação e rastreabilidade entre sistemas
- Pendências técnicas e cadastrais
- Volumes transacionais e comportamento de carga
- Escalabilidade da aplicação no OpenShift
- Problemas de memória e Garbage Collector
- Observabilidade, monitoramento e suporte operacional
- Integração com o novo ambiente e data center
- Contingência, F5 e redirecionamento entre data centers
- Principais riscos identificados
- Pontos de atenção para a implantação
- Decisões e entendimentos consolidados
- Pendências e questões em aberto
- Ações e próximos passos
- Recomendações técnicas do assessment
- Conclusão executiva
- Anexo A: registro cronológico revisado da sessão
- Anexo B: termos normalizados e trechos que exigem validação
1.8.1. Objetivo da reunião¶
A reunião teve como objetivo compreender em maior profundidade o funcionamento do sistema responsável pelas integrações de manutenção com o ambiente ADMS e DMS, especialmente:
- o escopo funcional do sistema;
- as origens das solicitações e ordens de manutenção;
- o fluxo de envio e retorno das informações;
- os componentes técnicos envolvidos;
- o uso do Kafka como barramento;
- a execução dos serviços no OpenShift;
- os mecanismos de observabilidade e rastreabilidade;
- os riscos relacionados à escalabilidade;
- o comportamento do sistema em situações de contingência;
- os impactos da entrada de novas empresas e novos ambientes;
- as preocupações para a implantação prevista para 1º de setembro.
A conversa também buscou distinguir o processo de manutenção programada do processo de atendimento a incidentes ou ocorrências emergenciais.
1.8.2. Participantes e pessoas mencionadas¶
A transcrição identifica nominalmente os seguintes participantes com fala registrada na sessão.
| Marcus Vinicius Alves de Castro (citado também como Marcos) | Energisa | Responsável pela integração do sistema de manutenção; apresenta o fluxograma, a arquitetura de microserviços, os estados da ordem e as preocupações de escalabilidade e contingência |
| Norberto da Silva Prado | Energisa | Ponto focal técnico do assessment; esclarece a distinção entre manutenção programada e incidente e relata o andamento da discussão de F5 e API Gateway |
| Heitor Cabral Riguete | Energisa | Participação registrada no encerramento da sessão |
| Vladimir Morozowski de Sousa | Digital Solutions e Syntropy Labs | Consultoria; conduz o levantamento, delimita escopo, questiona rastreabilidade, volumetria, observabilidade e contingência |
Foram citados ao longo da reunião, sem participação direta registrada: Vinícius, apontado como possível remetente do fluxograma; Pascoal, associado à discussão anterior sobre identificação da empresa pelo campo de origem da requisição; Gullit, responsável por F5 e API Gateway; Castellani, cuja inclusão nas reuniões seguintes foi solicitada; e Estevam, associado ao apoio na análise dos parâmetros de memória. A compilação relaciona ainda Max, Fábio, Otávio, Wesley e Douglas, além das equipes responsáveis por manutenção, ADMS, infraestrutura, OpenShift, F5, API Gateway e integração. Nem todos os nomes mencionados participaram diretamente da reunião: alguns foram citados como responsáveis por atividades anteriores, decisões técnicas ou esclarecimentos específicos.
1.8.3. Reuniões técnicas subsequentes¶
Antes do início da discussão técnica principal, foram alinhadas outras reuniões previstas para os dias seguintes. Foram mencionadas duas reuniões na quarta-feira, uma das 9h30 às 10h30 e outra das 10h30 às 11h30, com temas envolvendo atendimento, WFM, integrações relacionadas ao sistema de manutenção, os sistemas com maior quantidade de integrações e processos associados ao ADMS.
Também foi mencionada uma reunião adicional, prevista para o dia seguinte, das 11h às 12h, com uma equipe parceira relacionada à IBM e a tecnologias de processamento de eventos, incluindo Flink e outras soluções utilizadas nas integrações. Foi informado que essas discussões poderiam envolver integrações com EDP, integrações correlatas ao WFM, soluções para processamento de dados e eventos e componentes relacionados ao ecossistema Kafka. Vladimir confirmou a intenção de participar e solicitou a inclusão de Castellani na reunião.
1.8.4. Contextualização do sistema de manutenção¶
O primeiro ponto técnico discutido foi a abrangência do sistema de manutenção. Havia dúvida sobre se o sistema atuava apenas como um sistema de ordens de serviço em campo ou se possuía escopo mais amplo, semelhante a soluções de gestão de ativos, de força de trabalho, de operação em campo, de incidentes, de atendimento ou relacionadas aos ambientes de alta e média tensão. A pergunta inicial mencionou expressamente os sistemas de despacho em campo já citados no projeto e questionou se o sistema estaria presente nos dois ambientes, de tecnologia da informação e de tecnologia operacional.
Foi esclarecido que o escopo principal do sistema apresentado está relacionado à manutenção, particularmente ordens de serviço de manutenção, solicitações de serviço, manutenção programada, comunicação das atividades de manutenção com o DMS e ADMS e disponibilização das informações de manutenção para os operadores. Também foi esclarecido que a interlocução do sistema não é com o WFM, e sim com a base do próprio sistema de manutenção.
Delimitação de escopo O sistema não deve ser confundido com o fluxo de atendimento emergencial nem com as ordens técnicas geradas a partir de falta de energia, falta de fase ou outros incidentes. Essa distinção foi o principal ponto de esclarecimento da sessão e resolve a ambiguidade do termo sistema de manutenção que havia sido levantada no planejamento do assessment. |
1.8.5. Escopo funcional da integração¶
A integração apresentada tem como função principal transmitir ao DMS e ADMS informações relacionadas a ordens e solicitações de manutenção. Entre os principais objetivos funcionais estão:
- informar ao operador do DMS que existe uma manutenção programada para determinado ativo;
- disponibilizar informações sobre ordens e solicitações de serviço;
- atualizar no DMS o estado da manutenção;
- sinalizar suspensões, reprogramações, cancelamentos e conclusões;
- informar pendências técnicas ou cadastrais associadas a um ativo;
- permitir que o operador identifique atividades planejadas sobre elementos da rede;
- apoiar a coordenação operacional entre manutenção e operação.
A principal utilização do dado no DMS é proporcionar contexto ao operador. Ao visualizar determinado ativo no mapa, o operador pode saber que existe uma manutenção programada, que existe uma solicitação de serviço associada, que poderá ocorrer desligamento, que existe uma intervenção planejada, que pode haver necessidade de coordenação com outra atividade ou que existe uma pendência técnica ou cadastral relacionada ao ativo. Como registrado na sessão, se houver uma intervenção que exija desligamento, o operador já sabe que existe algo planejado para aquele ativo e decide o que fazer a partir dessa informação.
1.8.6. Arquitetura técnica apresentada¶
A arquitetura descrita é composta pelo sistema de origem da manutenção, seu banco de dados, um serviço responsável por consultar os dados, o Kafka como barramento de mensagens, serviços consumidores e produtores, os mecanismos de integração com o DMS e ADMS, serviços de notificação, o OpenShift como plataforma de execução e as ferramentas de monitoramento e logs. Foram mencionados três microserviços principais, executados no OpenShift, e os tópicos correspondentes no Kafka.
| Serviço de consulta | Consulta periodicamente a base do sistema de manutenção | Lê a base de origem e publica no tópico Kafka |
| Serviço de envio ao DMS | Consome as mensagens e realiza o envio ao DMS e ADMS | Consome o tópico e chama a camada de integração |
| Serviço de notificação | Recebe os retornos do ADMS e os publica no barramento | Permite que o sistema de manutenção atualize seus registros internos |
1.8.6.1. Serviço de consulta¶
Existe um serviço que consulta periodicamente a base do sistema de manutenção. Esse serviço verifica novas ordens de serviço, verifica novas solicitações de serviço, identifica alterações de estado, verifica se o registro já foi integrado e prepara os dados para publicação no Kafka.
1.8.6.2. Serviço de envio ao DMS¶
Após a publicação da mensagem no Kafka, outro serviço consome essa mensagem e realiza o envio ao DMS e ADMS. Esse componente é responsável por consumir as mensagens do tópico, transformar ou preparar os dados no formato necessário, chamar a camada de integração, publicar ou encaminhar os dados para o DMS e tratar o retorno técnico da chamada. Conforme registrado na sessão, essa publicação ocorre por meio da camada de API Gateway.
1.8.6.3. Serviço de notificação¶
Existe também um fluxo de notificação utilizado no retorno das informações do DMS. Esse serviço recebe eventos ou mensagens de retorno e publica essas informações novamente no barramento, permitindo que o sistema de manutenção atualize seus registros internos.
1.8.7. Fluxo de envio das ordens e solicitações de serviço¶
O fluxo principal começa quando uma ordem ou solicitação de serviço é criada no sistema de manutenção.
1.8.7.1. Criação do registro¶
O operador pode criar uma ordem de serviço, uma solicitação de serviço, um documento de manutenção ou uma atividade vinculada a um ativo específico. Durante a criação são informados dados como o ativo relacionado, o tipo de manutenção, a prioridade, as informações da inspeção, a ficha de manutenção, a programação, a eventual necessidade de desligamento e os demais parâmetros necessários à integração. Foi citado como exemplo, na sessão, a associação de uma ordem de serviço a um transformador, com o preenchimento dos dados da ordem e da ficha de inspeção.
Para que a informação seja enviada ao DMS, o registro precisa atender a determinadas regras, como possuir a prioridade correta, estar associado a um ativo válido, possuir cadastro compatível com o cadastro existente no ADMS e atender aos parâmetros definidos para a integração. Foi explicitado que o ativo precisa estar presente no GIS para que exista o cadastro correspondente no ADMS, o que estabelece uma dependência direta entre este fluxo e a integração cadastral tratada na Ata 06.
1.8.7.2. Consulta periódica¶
O serviço de integração realiza consultas periódicas à base de dados. O modelo atual é baseado em polling, com a seguinte sequência:
- consulta a base;
- identifica ordens novas ou alteradas;
- verifica se o registro já foi integrado;
- seleciona os registros elegíveis;
- publica os dados no Kafka.
Ausência de CDC neste fluxo Foi explicitamente informado que esse fluxo não utiliza CDC. A comparação foi feita, na própria sessão, com o sistema de atendimento em campo, que trabalha com captura de alterações no banco. A justificativa apresentada foi que o mecanismo de captura não atenderia ao desenho deste fluxo, o que deve ser tratado como decisão a revalidar, e não como restrição técnica estabelecida. |
1.8.7.3. Publicação no Kafka¶
Depois de identificar um registro elegível, o serviço publica uma mensagem em um tópico Kafka. Essa mensagem contém os dados necessários para o processo de integração. Foi mencionado um tópico específico de origem das ordens de serviço, destinado ao que é enviado ao DMS.
1.8.7.4. Consumo da mensagem¶
Um serviço consumidor acompanha o tópico Kafka. Ao receber uma nova mensagem, ele lê os dados, valida o conteúdo, executa o envio, chama a interface do DMS e ADMS e registra o resultado da operação.
1.8.7.5. Disponibilização no DMS¶
Após o envio, a ordem ou solicitação passa a ficar disponível no DMS como uma requisição de trabalho, permitindo que o operador visualize a informação no contexto operacional. Foi registrado que essa requisição é apresentada em janela própria do DMS, distinta da tela de tratamento de incidentes.
1.8.8. Fluxo de retorno do ADMS e DMS¶
O retorno do DMS ocorre principalmente para informar alterações ou decisões tomadas pelo operador. Um exemplo apresentado foi a suspensão de uma manutenção. O operador pode identificar que já existe outra atividade programada, que há conflito de programação, que existe necessidade de desligamento, que o horário não é adequado ou que existe alguma restrição operacional. Nesses casos, o operador pode suspender a atividade e informar o motivo.
A informação retorna ao sistema de manutenção, permitindo registrar a suspensão, reprogramar a atividade, alterar o planejamento, reagendar a execução e manter o histórico da decisão. Foi descrito que, ao retornar ao sistema de manutenção, o responsável verifica que houve suspensão e programa a execução para outro momento.
O retorno não representa, necessariamente, a criação de uma nova ordem pelo ADMS. Em muitos casos, representa uma atualização do estado de uma ordem originada no sistema de manutenção. Foi esclarecido na sessão que, nesse fluxo, o sistema de manutenção é a origem do dado e não consome ordens criadas no DMS.
1.8.9. Origem das manutenções¶
As manutenções podem ser originadas de diferentes formas.
1.8.9.1. Criação manual¶
O operador pode criar manualmente a ordem ou solicitação de manutenção no sistema, informando o ativo, o tipo de serviço, a programação, os dados técnicos, as informações de inspeção e a prioridade.
1.8.9.2. Geração por sistemas especializados¶
Outro sistema, mencionado como responsável pelo cálculo de manutenções, pode gerar automaticamente as atividades. Esse sistema utiliza informações como data da última manutenção, periodicidade definida, plano de manutenção, histórico do ativo, regras de inspeção e características do equipamento. A partir dessas informações, calcula a próxima manutenção e cria automaticamente o registro correspondente, já com a data de serviço programada. Foi registrado que esse sistema pode gerar várias solicitações de inspeção preventiva de uma só vez, e que a maior parte delas se enquadra nos critérios de envio ao DMS.
Preventiva e preditiva A discussão distinguiu a manutenção preventiva, calculada por periodicidade e histórico, da preditiva, baseada no comportamento do equipamento, que sinalizaria a necessidade de intervenção mesmo quando a regra de periodicidade não a indica. A preditiva foi caracterizada como algo que, de modo geral, ainda não existe nesse fluxo. |
1.8.9.3. Origem em pendências¶
Também podem ser criados registros relacionados a pendências técnicas, pendências cadastrais, problemas identificados durante atendimento, inconsistências vinculadas ao ativo e necessidades de atuação de equipes de cadastro.
1.8.10. Diferença entre manutenção programada e incidente¶
Um dos pontos de maior dúvida durante a reunião foi a diferença entre manutenção programada, incidente, atendimento emergencial e ordem técnica. Foi esclarecido que a integração discutida está focada principalmente em atividades programadas de manutenção, e que o fluxo de ordem técnica, associado ao atendimento, seria tratado em reunião posterior.
| Manutenção programada | Manutenção preventiva, inspeções, intervenções planejadas, correções previamente identificadas, serviços com programação definida e atividades que podem exigir desligamento programado | Integração tratada nesta sessão, com destino ao DMS como requisição de trabalho |
| Incidente ou atividade não programada | Falta de energia, falta de fase, falha emergencial, ocorrência operacional, problema identificado em tempo real e necessidade de atendimento imediato | Segue outro fluxo, relacionado aos sistemas de atendimento e operação emergencial |
O sistema apresentado pode receber informações derivadas de outros processos, mas seu objetivo principal é integrar atividades de manutenção programada. Ao ser questionado sobre a origem da manutenção, o interlocutor confirmou que, do ponto de vista da integração, a origem não é determinante: a manutenção chega ao sistema e é processada a partir dali.
1.8.11. Ciclo de vida das ordens de manutenção¶
A integração acompanha as alterações do ciclo de vida da ordem ou solicitação. Foram mencionados estados e eventos como criada, programada, enviada ao DMS, recebida pelo DMS, disponível para o operador, em execução, suspensa, reprogramada, cancelada, executada, concluída, finalizada e retirada do DMS.
| Criação | Quando a ordem é criada no sistema de manutenção, ela é transmitida ao DMS, desde que atenda aos critérios definidos. |
| Programação | Quando a ordem é programada, essa informação é atualizada no DMS. |
| Execução | Durante a execução, o estado da ordem pode ser atualizado e disponibilizado aos sistemas envolvidos. |
| Suspensão | Pode ocorrer quando existe restrição operacional ou necessidade de reagendamento, com estado específico de suspensão da operação. |
| Reprogramação | Quando a atividade não pode ser executada na data planejada, é reprogramada para uma nova data. |
| Cancelamento | A ordem pode ser cancelada quando não existe mais necessidade de execução; nesse caso, o registro correspondente também é removido ou invalidado no DMS. |
| Finalização | Quando a manutenção é concluída, a informação é atualizada e a requisição é retirada da lista de requisições de trabalho do DMS, por deixar de ser relevante para a operação corrente. |
1.8.12. Identificação e rastreabilidade entre sistemas¶
Foi questionado se existe um identificador único que transita entre os diferentes sistemas. A resposta foi que existem identificadores correlacionados. O sistema de manutenção possui seu próprio código interno. Quando o registro é criado no DMS, também é gerado um código específico no ambiente de destino, na forma de um identificador de requisição de trabalho.
Para manter a correlação, o código interno do sistema de manutenção é armazenado no registro criado no DMS, o identificador do DMS pode ser mantido no sistema de origem, os dois códigos permitem identificar a correspondência e a equipe consegue pesquisar uma ordem específica nos logs e nos sistemas.
Embora não tenha sido caracterizado como um identificador corporativo único universal, existe uma estratégia de correlação entre os códigos de cada aplicação. Não foram relatados casos conhecidos de perda definitiva dessa correlação.
1.8.13. Pendências técnicas e cadastrais¶
Foi descrito um fluxo específico para pendências técnicas ou cadastrais. Essas pendências podem surgir a partir de atendimentos, de códigos específicos do processo operacional, de registros do DMS, de inconsistências relacionadas ao ativo e da necessidade de atualização cadastral. Foi registrado que a origem principal está no atendimento em campo, cujo serviço de pendência técnica e cadastral transita pelo ADMS.
O DMS publica as informações em uma fila e o sistema de manutenção executa a seguinte sequência:
- consome a fila;
- filtra os registros relevantes;
- identifica os tipos de serviço relacionados a pendências;
- cria um documento interno;
- associa a pendência ao ativo;
- disponibiliza a informação ao operador;
- permite o encaminhamento para uma equipe técnica ou cadastral.
Esse processo funciona como um mecanismo de controle interno para garantir que problemas identificados durante a operação não sejam perdidos. O trânsito das informações ocorre integralmente pelas filas do Kafka. Foi descrito que o documento criado informa que determinado ativo precisa ser cadastrado ou apresenta pendência, e que o próprio operador do sistema de manutenção decide o encaminhamento, contatando a equipe responsável.
1.8.14. Volumes transacionais e comportamento de carga¶
O volume diário foi caracterizado como relativamente baixo em operação normal. Foi mencionada uma estimativa de aproximadamente 100 registros em determinados contextos, mas o valor pode variar de acordo com a empresa, a quantidade de ativos, o volume de manutenções, o dia de operação, as regras de seleção e a geração automática por outros sistemas. Nem todos os registros criados necessariamente atendem aos critérios para envio ao DMS. Foi citado que uma das empresas do grupo possui quase dois milhões de ativos cadastrados, o que pode gerar volumes bem superiores à estimativa.
1.8.14.1. Operação normal¶
Durante a operação regular, o comportamento é distribuído: uma ordem é criada, a mensagem é publicada, a mensagem é processada e o fluxo retorna ao nível normal. Não foi observado o mesmo comportamento de sistemas que enviam grandes quantidades de requisições simultâneas de maneira contínua. A comparação foi feita, na própria sessão, com o sistema de atendimento em campo, descrito como gerador de requisições instantâneas em volume muito superior, comportamento que este fluxo não apresenta, sem formação relevante de fila no Kafka.
Correlação com outros registros deste documento A caracterização do sistema de atendimento em campo como gerador de rajadas de requisições instantâneas converge com o gargalo de fila única relatado na Ata 05 para a abertura de reclamação no OMS e com a preocupação de volumetria em contingência registrada na Ata 01. O fluxo de manutenção, por contraste, apresenta perfil de baixa volumetria transacional, e seu risco concentra-se na carga inicial e no consumo de memória. |
1.8.14.2. Implantação de uma nova empresa¶
O principal pico acontece durante a implantação de uma nova empresa. Nessa situação, o serviço pode recuperar dados históricos, identificar registros anteriores, processar um conjunto acumulado, enviar grande quantidade de mensagens em sequência, aumentar o consumo de memória, pressionar os recursos do OpenShift e aumentar temporariamente a fila Kafka. Foi descrito que, nesse momento, o serviço recupera os dados anteriores e os envia de uma só vez, retornando ao comportamento normal ao término da implantação. Esse cenário de carga inicial precisa ser considerado separadamente do comportamento transacional regular.
1.8.15. Escalabilidade da aplicação no OpenShift¶
A principal preocupação técnica apresentada está relacionada à escalabilidade horizontal da aplicação. O serviço atual possui uma única aplicação, mas internamente cria uma execução ou processo específico para cada empresa. Em termos simplificados:
- existe um único serviço implantado;
- cada empresa possui sua própria base;
- o serviço cria internamente uma unidade de processamento por empresa;
- cada unidade consulta a base correspondente;
- cada unidade publica as mensagens relacionadas àquela empresa.
À medida que novas empresas são adicionadas, aumenta a quantidade de processos internos, o consumo de memória, o número de conexões, o volume de consultas e a complexidade operacional, tornando o serviço mais pesado. A arquitetura interna dificulta que o OpenShift distribua automaticamente a carga entre múltiplos pods. Foi relatado que a busca por uma forma válida de aplicar o escalonamento horizontal ainda não obteve resultado, e que o próprio responsável estava avaliando internamente alternativas de otimização.
1.8.15.1. Limitação atual¶
O serviço não foi desenhado como uma aplicação stateless facilmente replicável. Por manter múltiplos processamentos internos associados a diferentes empresas, existe dificuldade para criar réplicas, dividir a carga, evitar processamento duplicado, determinar qual pod processa qual empresa, realizar balanceamento horizontal e utilizar Horizontal Pod Autoscaler de forma segura.
1.8.15.2. Risco futuro¶
Com apenas algumas empresas, o problema ainda pode ser administrável, e foi registrado na sessão que a configuração atual do OpenShift está atendendo à demanda. Entretanto, conforme novas empresas forem incorporadas, poderá ocorrer aumento progressivo de memória, degradação de desempenho, necessidade de pods maiores, reinicializações mais frequentes, dificuldade de manutenção, maior risco operacional e impossibilidade de escalar de forma automática.
1.8.16. Problemas de memória e Garbage Collector¶
Foi relatado um problema anterior relacionado ao consumo de memória no OpenShift, já tratado pela equipe. O comportamento observado era o seguinte:
- a aplicação continuava consumindo memória;
- o Garbage Collector não liberava a memória no momento esperado;
- o consumo crescia continuamente;
- a aplicação ultrapassava o limite de memória definido para o pod;
- o OpenShift encerrava a aplicação por falta de memória;
- o pod era reiniciado;
- o processamento continuava a partir do ponto anterior.
Não houve relato de perda definitiva de mensagens ou ordens. O principal impacto era a interrupção temporária, o atraso no processamento, a reinicialização da aplicação e o aumento de latência.
1.8.16.1. Causa identificada¶
A aplicação Java não estava reconhecendo corretamente os limites do container. Mesmo com um limite de memória configurado para o pod, citado na sessão como da ordem de um gigabyte, a JVM enxergava a quantidade de memória disponível no ambiente como um todo. Como consequência, o Garbage Collector não atuava de acordo com o limite real do pod, e a aplicação seguia alocando além do que o pod admitia.
1.8.16.2. Ajustes realizados¶
Foram realizados ajustes de parâmetros na aplicação e na pipeline de implantação para tornar a JVM consciente do ambiente de container, limitar adequadamente o uso de memória, melhorar o acionamento do Garbage Collector, alinhar o comportamento da aplicação ao limite do pod e reduzir a ocorrência de encerramentos por falta de memória. O ajuste foi conduzido com apoio da equipe responsável pela pipeline.
1.8.17. Observabilidade, monitoramento e suporte operacional¶
Existem mecanismos de monitoramento em diferentes camadas.
1.8.17.1. Dashboard do OpenShift¶
O dashboard permite acompanhar o estado dos pods, a execução dos serviços, as reinicializações, o consumo de recursos, os eventos de infraestrutura, os erros da aplicação e os logs do container.
1.8.17.2. Plataforma de logs¶
Também é utilizada uma solução centralizada de logs, citada na sessão como a plataforma ELK, empregada para monitoramento e pesquisa operacional. A aplicação registra eventos ao longo do fluxo, como início do processamento, leitura do registro, publicação da mensagem, consumo do tópico, envio ao DMS, retorno da chamada, ocorrência de erro e tentativa de reprocessamento.
A equipe de sustentação consegue pesquisar uma ordem específica pelo seu identificador. Por exemplo, quando alguém informa que determinada ordem não chegou ao ADMS, a equipe pode verificar se a ordem foi localizada pelo serviço, se a mensagem foi publicada, se o consumidor recebeu a mensagem, se houve tentativa de envio, se o DMS respondeu, se ocorreu erro, se houve reprocessamento e em qual etapa o fluxo parou. Foi descrito que o filtro por identificador da ordem permite distinguir se houve tentativa de reprocessamento, se a tentativa resultou em erro ou se não houve tentativa alguma.
1.8.17.3. Limitações atuais¶
Apesar da existência de logs, não foi apresentado um painel fim a fim de negócio com todos os estados da integração. O monitoramento atual parece concentrar-se em infraestrutura, logs técnicos, análise reativa e pesquisa por ordem individual. Existe oportunidade de evolução para uma observabilidade integrada e orientada ao processo de negócio.
1.8.18. Integração com o novo ambiente e data center¶
Foi discutida a entrada de uma nova empresa ou novo grupo no ambiente ADMS, com implantação prevista para 1º de setembro. Houve dúvida sobre qual grupo seria utilizado. Foi esclarecido que a nova entrada ocorrerá no Grupo 1, embora o primeiro grupo anteriormente implantado tenha sido denominado Grupo 3, em uma sequência que gerou alguma confusão.
A principal preocupação não estava relacionada ao volume transacional regular, mas à correta definição da origem da mensagem, da empresa responsável, do endpoint de destino, do grupo correspondente, do data center ativo e do mecanismo de roteamento.
Inversão da numeração dos grupos A numeração dos agrupamentos é fonte recorrente de confusão nos registros deste documento: o primeiro grupo implantado foi o Grupo 3 e a sequência prossegue pelo Grupo 1. A observação foi feita explicitamente nesta sessão e converge com os registros das Atas 03 e 06, reforçando a ação de confirmação da topologia oficial dos grupos junto ao PMO do programa. |
1.8.19. Contingência, F5 e redirecionamento entre data centers¶
Um dos principais pontos de atenção foi o comportamento da integração em situações de contingência. Foi mencionado que existem dois data centers, um principal e um secundário. O F5 mantém o direcionamento para o data center ativo, e o secundário permanece inativo até que se identifique o chaveamento. Quando ocorre o chaveamento, o data center secundário assume, o tráfego precisa ser redirecionado, o endpoint correto precisa ser utilizado e as integrações devem continuar funcionando.
1.8.19.1. Situação atual¶
Segundo os relatos, parte do processo de redirecionamento ainda ocorre manualmente. Em uma situação anterior, a equipe de monitoração entrou em contato, o responsável realizou o transbordo manualmente e o redirecionamento foi executado pelo próprio F5, de modo que a continuidade dependeu de intervenção humana.
Convergência com a Ata 05 Este relato corrobora diretamente o que foi levantado na sessão de 10 de julho com a equipe de Sensedia e F5: o site switch é coordenado e manual, e a equipe de F5 desabilita o membro anterior e habilita o secundário após confirmação. Norberto referenciou expressamente essa conversa durante a sessão. O ponto passa a ter registro independente por duas frentes distintas, a de infraestrutura e a de aplicação consumidora. |
1.8.19.2. Preocupação do sistema de manutenção¶
A equipe do sistema de manutenção deseja garantir que, no momento da entrada em produção, não seja necessário alterar a aplicação, não seja necessário modificar endpoints manualmente, o redirecionamento seja transparente, o F5 ou o API Gateway identifique o ambiente ativo, o roteamento seja realizado automaticamente, a empresa e o grupo sejam corretamente identificados e o sistema continue enviando mensagens sem intervenção do time de desenvolvimento. Foi manifestado, ainda, o interesse em ser envolvido nas discussões sobre esse tema, uma vez que o andamento da conversa não estava sendo acompanhado pela equipe de manutenção.
1.8.19.3. Identificação por origem¶
Foi relembrada uma discussão anterior, ocorrida durante a especificação do DMS, sobre a necessidade de identificar, pelo campo de origem da requisição, qual empresa está enviando a mensagem, de modo a redirecionar automaticamente o endpoint. Essa identificação seria usada para determinar o endpoint correto, direcionar a chamada, selecionar o ambiente correspondente, evitar configurações manuais e suportar múltiplas empresas. A confirmação de que esse mecanismo permanece previsto foi apontada como a principal pendência da equipe para a entrada em produção.
A solução pode envolver F5, API Gateway, regras de roteamento, identificação pelo campo de origem, endpoints virtuais, health checks e mecanismos automáticos de failover.
1.8.20. Principais riscos identificados¶
| Escalabilidade limitada | A arquitetura com um único serviço e múltiplos processamentos internos por empresa dificulta o escalonamento horizontal. |
| Crescimento do consumo de memória | A entrada de novas empresas pode aumentar significativamente o consumo de memória da aplicação. |
| Dependência de polling | O uso de consultas periódicas à base gera carga adicional, latência, necessidade de controle de registros processados, dificuldade de escalabilidade e risco de consultas concorrentes. |
| Pico durante cargas iniciais | A implantação de uma nova empresa pode provocar carga muito superior à operação normal. |
| Falta de automação completa no failover | O processo de contingência ainda apresenta componentes manuais. |
| Roteamento por empresa e grupo | Existe risco de envio ao endpoint ou grupo incorreto caso a identificação da origem não esteja adequadamente implementada. |
| Observabilidade fragmentada | O acompanhamento está distribuído entre OpenShift, logs e sistemas de negócio, sem uma visão consolidada de ponta a ponta. |
| Dependência de conhecimento tácito | Algumas decisões e procedimentos parecem depender de pessoas específicas, o que aumenta o risco operacional. |
| Ausência de métricas claras de capacidade | Não foram apresentados indicadores formais de capacidade máxima, quantidade de empresas suportadas, consumo por empresa, throughput, tempo médio de processamento, limite de backlog e comportamento em contingência. |
1.8.21. Pontos de atenção para a implantação¶
Para a implantação prevista para 1º de setembro, deverão ser verificados: cadastro correto da nova empresa; definição do grupo de destino; endpoints de integração; identificação da origem; regras de roteamento; configuração do F5; configuração do API Gateway; comportamento em failover; consumo de memória; limites dos pods; parâmetros da JVM; tratamento da carga histórica; capacidade dos tópicos Kafka; retenção das mensagens; reprocessamento; monitoramento; alertas; procedimentos de suporte; e responsabilidades durante a entrada em produção.
Também será importante executar testes específicos de carga inicial, operação normal, queda do data center principal, mudança para o data center secundário, retorno ao data center principal, reinicialização do serviço, indisponibilidade do DMS, indisponibilidade do Kafka, duplicidade de mensagem, reprocessamento e consistência da correlação entre os identificadores.
1.8.22. Decisões e entendimentos consolidados¶
Ao final da reunião, ficaram consolidados os seguintes entendimentos.
- A integração discutida está associada principalmente à manutenção programada.
- O processo de incidente emergencial segue outro fluxo e será aprofundado em reuniões posteriores.
- O sistema de manutenção é a principal origem das ordens e solicitações enviadas ao DMS.
- O Kafka é utilizado como barramento entre os serviços.
- A aplicação consulta periodicamente a base e não utiliza CDC nesse fluxo.
- O DMS disponibiliza a manutenção ao operador como uma requisição de trabalho.
- O retorno do DMS é utilizado para atualização de estados, suspensões e outras decisões operacionais.
- Existe correlação entre o identificador do sistema de manutenção e o identificador criado no DMS.
- Não foram relatadas perdas definitivas de ordens durante falhas de memória.
- O principal problema já observado foi o aumento do consumo de memória e a reinicialização do pod.
- A maior preocupação estrutural é a dificuldade de escalabilidade horizontal.
- O principal pico de carga ocorre durante a implantação de uma nova empresa.
- O failover entre data centers ainda precisa ser confirmado e automatizado.
- O sistema de manutenção não deve necessitar de alteração manual durante a contingência.
- O fluxo técnico apresentado deverá ser compartilhado com a equipe de assessment.
1.8.23. Pendências e questões em aberto¶
Permaneceram as seguintes questões, organizadas por tema.
| Escalabilidade | Como será realizado o escalonamento horizontal do serviço. Como evitar processamento duplicado caso sejam criadas múltiplas réplicas. É possível separar o processamento por empresa. A aplicação poderá ser transformada em serviços independentes por empresa. Existe possibilidade de substituir o polling por CDC ou eventos. |
| Capacidade | Qual é o consumo médio de memória por empresa. Qual é a capacidade máxima de uma instância. Qual é o comportamento durante a carga histórica. Quais são os tempos médios de processamento. Qual é o SLA para uma ordem aparecer no DMS. |
| Resiliência | Como funciona o reprocessamento automático. Existe Dead Letter Queue. Como são tratadas mensagens inválidas. Como são tratadas duplicidades. |
| Contingência | O failover do F5 será totalmente automático. Quem é responsável pelo chaveamento. O API Gateway participa do roteamento. Como o campo de origem será utilizado para determinar a empresa. Como será realizado o retorno do data center secundário para o principal. Existe procedimento documentado para contingência. |
| Implantação e monitoramento | Como será testado o novo grupo. Existe painel de monitoramento fim a fim. Quais alertas são enviados à equipe de sustentação. |
1.8.24. Ações e próximos passos¶
| 1 | Compartilhamento do fluxo técnico | Marcus e Vinícius deverão encaminhar o fluxograma apresentado durante a reunião, contendo preferencialmente componentes, serviços, tópicos Kafka, sistemas de origem e de destino, fluxos de ida e de retorno, estados, integrações e pontos de monitoramento. Foi informado que o material passaria por uma revisão final antes do envio. |
| 2 | Participação nas reuniões seguintes | Vladimir e Castellani deverão participar das reuniões subsequentes relacionadas a atendimento, WFM, integrações, IBM, Flink, sistemas correlatos e fluxos de incidentes. |
| 3 | Confirmação da arquitetura de contingência | A equipe deverá confirmar com os responsáveis por F5 e API Gateway como ocorre o failover, se o processo será automático, quais health checks serão utilizados, como os endpoints são atualizados, se haverá necessidade de intervenção manual, como o sistema identifica o data center ativo e como ocorre o retorno ao ambiente principal. |
| 4 | Avaliação da escalabilidade | Deverá ser realizada análise específica sobre a arquitetura interna do serviço, o consumo por empresa, a divisão de responsabilidades, a possibilidade de particionamento, a capacidade de criação de múltiplos pods, o uso de escalabilidade horizontal, o isolamento de falhas e o controle de concorrência. |
| 5 | Testes de implantação | Antes da entrada em produção, deverão ser conduzidos testes de carga, pico, contingência, recuperação, reprocessamento, reinicialização, indisponibilidade, roteamento, correlação de identificadores e observabilidade. |
1.8.25. Recomendações técnicas do assessment¶
1.8.25.1. Separar o processamento por empresa¶
Recomenda-se avaliar a separação lógica ou física dos processadores por empresa. Possíveis alternativas: um deployment por empresa; um consumer group por empresa; particionamento Kafka pela identificação da empresa; workers independentes; filas específicas; configuração externa de tenants; e processamento distribuído. Essa separação pode melhorar escalabilidade, isolamento, monitoramento, manutenção, dimensionamento e recuperação de falhas.
1.8.25.2. Tornar os serviços stateless¶
Sempre que possível, os serviços devem ser stateless. Estados de processamento deverão ser mantidos em banco de controle, no Kafka, em cache distribuído, em tabela de checkpoints ou em armazenamento compartilhado. Isso permitirá múltiplos pods, recuperação automática, distribuição de carga e uso seguro do Horizontal Pod Autoscaler.
1.8.25.3. Implementar idempotência¶
Cada mensagem deve possuir chave idempotente, com composição sugerida a partir da empresa, do identificador da ordem, da versão ou estado, da data do evento e do tipo do evento. Isso evita duplicidade em situações de retry, reinicialização, reprocessamento, failover e indisponibilidade temporária.
1.8.25.4. Adotar Dead Letter Queue¶
Mensagens que não puderem ser processadas após determinado número de tentativas devem ser encaminhadas para uma fila de exceção. A Dead Letter Queue permitirá isolar erros, impedir bloqueio do fluxo, facilitar correção, manter rastreabilidade e reprocessar mensagens posteriormente.
1.8.25.5. Automatizar o failover¶
O failover deve ser automatizado e testado. A solução deverá combinar endpoint virtual, F5, health checks, API Gateway, timeout, retry controlado, circuit breaker, observabilidade e retorno automatizado ou controlado.
1.8.25.6. Criar observabilidade fim a fim¶
Recomenda-se criar um painel consolidado contendo ordens identificadas, ordens publicadas, mensagens consumidas, chamadas realizadas, respostas recebidas, erros, retries, backlog, latência, disponibilidade, consumo por empresa e status do data center.
1.8.25.7. Definir indicadores operacionais¶
Indicadores recomendados: tempo entre criação e publicação; tempo entre publicação e consumo; tempo entre consumo e disponibilização no DMS; quantidade de mensagens pendentes; quantidade de erros; quantidade de retries; quantidade de mensagens na Dead Letter Queue; reinicializações de pods; consumo de CPU; consumo de memória; throughput por empresa; e disponibilidade por integração.
1.8.25.8. Executar teste de carga inicial¶
O teste não deve considerar apenas o volume diário médio. Deve simular carga histórica, implantação de uma nova empresa, envio em massa, indisponibilidade temporária do destino, formação de backlog, retomada após indisponibilidade e reinicialização da aplicação durante o pico.
1.8.25.9. Documentar o procedimento de contingência¶
O procedimento deverá informar responsáveis, contatos, critérios de acionamento, passos de validação, mecanismos automáticos, ações manuais, evidências esperadas, retorno ao ambiente principal e plano de comunicação.
1.8.26. Conclusão executiva¶
A reunião permitiu compreender o papel do sistema de manutenção dentro do ecossistema ADMS. O fluxo atual atende ao objetivo de disponibilizar ao operador informações sobre manutenções programadas, utilizando serviços intermediários, Kafka e interfaces com o DMS. A solução possui mecanismos de rastreabilidade e não foram relatadas perdas definitivas de ordens. Entretanto, existem pontos relevantes de evolução arquitetural.
O principal risco está na forma como um único serviço mantém processamentos internos para múltiplas empresas. Esse desenho dificulta a escalabilidade horizontal e pode gerar aumento progressivo de consumo de memória à medida que novas empresas forem adicionadas.
Outro ponto crítico é a contingência entre data centers. Embora existam F5 e mecanismos de redirecionamento, foi relatada a ocorrência de intervenções manuais em situações anteriores. Para a nova implantação, é essencial garantir que o chaveamento seja transparente para as aplicações e não dependa de alterações manuais nos sistemas de origem.
A observabilidade técnica existente permite investigar falhas por meio de logs e dashboards de infraestrutura. Contudo, recomenda-se evoluir para uma visão fim a fim do processo de negócio, com métricas de latência, throughput, backlog, erros, retries e situação de cada ordem.
Para a implantação prevista para 1º de setembro, os principais focos deverão ser escalabilidade, consumo de memória, carga histórica, roteamento por empresa, definição dos grupos, automação do failover, rastreabilidade, monitoramento, testes de contingência e documentação operacional. A arquitetura funciona no cenário atual, mas precisará ser preparada para o crescimento do número de empresas e para a operação resiliente em múltiplos data centers.
Anexo A · Registro cronológico revisado da sessão¶
Registro cronológico revisado do conteúdo inteligível da reunião, com a marcação de tempo da gravação. A sequência temporal, as perguntas, respostas, hipóteses e conclusões foram preservadas. Saudações, repetições, problemas de conexão e compartilhamento de tela, interjeições e trechos em inglês inseridos indevidamente pelo reconhecimento automático de voz foram condensados. Nomes de sistemas e de pessoas corrompidos na transcrição foram normalizados conforme o Anexo B.
00:04 Norberto: Pergunta se há material disponível para a apresentação.
00:06 Marcus: Informa que dispõe do material que havia enviado anteriormente.
00:09 Norberto: Informa que não recebeu o material e solicita o compartilhamento de tela.
00:15 Vladimir: Coloca a questão inicial de escopo: qual é a abrangência do sistema, se se trata de ordem de serviço em campo, como nos sistemas de despacho já citados no projeto, ou se envolve gestão de ativos, e se o sistema está presente nos dois ambientes, de tecnologia da informação e de tecnologia operacional.
00:40 Marcus: Responde que o escopo envolve principalmente a parte de ordem de serviço.
00:47 Marcus: Detalha que, no DMS, o que se vê é a ordem de serviço e a solicitação de serviço.
00:52 Vladimir: Pergunta se a interlocução do sistema é com o WFM.
00:56 Marcus: Esclarece que não é com o WFM, e sim com os sistemas de manutenção.
01:02 Vladimir: Pergunta se a função é alocar pessoas.
01:06 Marcus: Responde que o objeto do fluxo é a requisição de trabalho.
01:11 Vladimir: Solicita que Marcus prossiga com a apresentação do material.
02:38 Marcus: Informa que, por ter sido convocado em cima da hora, dispõe de um fluxograma preparado originalmente para a equipe de sustentação, com o objetivo de dar contexto sobre os projetos e os caminhos percorridos pela integração com o DMS.
03:08 Marcus: Apresenta a arquitetura: existem três microserviços. O primeiro realiza a consulta à base do sistema de manutenção e é executado no ambiente OpenShift.
03:08 Marcus: Descreve os outros dois serviços, que operam contra o barramento Kafka: um produz as mensagens e outro é responsável por consumir a mensagem e enviar ao DMS. Cita ainda o serviço de notificação, pelo qual o ADMS retorna as informações, que são gravadas no barramento, consumidas pelo microserviço e eventualmente registradas na base de origem.
03:08 Marcus: Resume que a arquitetura se compõe basicamente de três serviços no OpenShift e dos tópicos no Kafka.
04:09 Vladimir: Avalia positivamente o fluxo e solicita o envio posterior do material.
04:17 Vladimir: Pergunta qual é o evento que dá início ao processo no sistema de manutenção.
04:25 Vladimir: Complementa a pergunta: quem aciona primeiro o sistema, ou se é um operador que registra a informação.
04:30 Marcus: Responde que o operador cria, no sistema de manutenção, uma ordem de serviço ou uma solicitação, associando o ativo correspondente, por exemplo um transformador, e informando os dados da ordem e da ficha de inspeção.
04:30 Marcus: Detalha que o registro precisa atender aos parâmetros definidos para integrar com o DMS, entre eles a prioridade correta e a presença do ativo no GIS, condição para que exista o cadastro correspondente no ADMS.
04:30 Marcus: Explica que o microserviço executa periodicamente uma consulta à base de solicitações, identifica os registros novos que ainda não foram integrados ao DMS e recupera todos os dados do serviço.
05:25 Marcus: Descreve que os dados são publicados no barramento, no tópico de origem das ordens de serviço, que corresponde ao que é enviado ao DMS. A partir da publicação, o componente intermediário consome a fila, recupera os dados e realiza a publicação por meio da camada de API Gateway.
05:25 Marcus: Conclui que, com esse consumo, a informação passa a ficar disponível no DMS como requisição de trabalho.
06:05 Vladimir: Pergunta se o sistema consome, em uma fila, os serviços que o ADMS disponibiliza.
06:14 Marcus: Esclarece que a disponibilização é do próprio sistema de manutenção: a origem é o sistema de manutenção, que cria a ordem; o microserviço recupera os dados e publica no barramento; e o componente intermediário consome as mensagens novas e envia os dados ao DMS.
06:14 Marcus: Acrescenta que, nesse fluxo, não há consumo de dados originados no DMS. O que retorna é a decisão do operador, por exemplo a suspensão de uma ordem de serviço, quando há outra manutenção programada, necessidade de desligamento ou inspeção já prevista para o mesmo ativo. O operador pode suspender e registrar o motivo, e o responsável no sistema de manutenção verifica a suspensão e reprograma a execução.
06:14 Marcus: Descreve o segundo fluxo de retorno, referente a pendências cadastrais, solicitado pela área. Ele se origina no atendimento em campo, cujo serviço de pendência técnica e cadastral transita pelo ADMS. O sistema de manutenção consome uma fila enviada pelo ADMS com os dados do serviço, filtra os registros com esse tipo de serviço e os traz de volta, tudo por meio das filas do Kafka.
07:59 Vladimir: Levanta a dúvida de escopo: se a ordem de serviço pode vir do ADMS, do OMS ou do CRM, e se essa solicitação corresponde a um incidente.
08:15 Norberto: Esclarece que o caso em discussão é manutenção, diferente da ordem técnica, e informa que a ordem técnica seria tratada na reunião de quarta-feira, envolvendo o atendimento.
08:25 Vladimir: Explicita a origem da confusão: a relação entre um atendimento e uma manutenção quando um equipamento falha.
08:45 Norberto: Reformula a pergunta para Marcus: se o atendimento de falta de energia ou falta de fase se relaciona a uma manutenção.
08:57 Marcus: Responde que esse caso pertence ao lado do incidente.
09:01 Vladimir: Esclarece sua intenção: entender se a manutenção tem origem preventiva ou decorre de um problema ocorrido.
09:16 Vladimir: Consolida o entendimento de que, para o sistema de manutenção, a origem não é determinante: a manutenção chega e é processada.
09:23 Marcus: Confirma.
09:28 Marcus: Detalha a principal finalidade da integração: mostrar ao operador que existem ordens de serviço e solicitações programadas para determinado ativo quando ele o visualiza no mapa. Se houver algo que exija desligamento, o operador já sabe que existe uma atividade planejada e decide o que fazer.
09:57 Vladimir: Pergunta se existe um número único que transita entre os sistemas, ou apenas o identificador interno do sistema de manutenção.
10:08 Marcus: Responde que existe o código da manutenção e que, ao ser criada a requisição de trabalho no DMS, é gerado um código próprio no destino. O código interno é armazenado no nome dessa requisição, para permitir a correspondência.
10:28 Marcus: Reforça que o objetivo é saber a que registro interno a requisição corresponde.
10:31 Vladimir: Confirma o entendimento de que existe um código que transita entre os diversos sistemas.
10:38 Vladimir: Solicita que Marcus prossiga com o que considerar relevante.
10:47 Marcus: Resume o escopo geral: o envio das solicitações e a atualização no DMS de tudo que ocorre de alteração no sistema de manutenção. Se a ordem é criada, é criada no destino; se é programada, a programação é informada; se é executada, o estado é enviado; e se é finalizada, a requisição é retirada da lista do DMS, por deixar de ser relevante.
10:47 Marcus: Acrescenta a alteração de status por retorno de suspensão e as solicitações de pendência, que podem vir do sistema de atendimento em campo ou do DMS. O sistema recupera os incidentes com esse serviço vinculado e cria um documento interno informando que o ativo precisa ser cadastrado ou apresenta pendência. O operador do sistema de manutenção decide o encaminhamento e contata a equipe responsável, em procedimento interno de controle.
12:01 Vladimir: Retoma os estágios mencionados: início, em manutenção, finalização e encerramento.
12:11 Vladimir: Pergunta quais são os estados de exceção, considerando que a manutenção pode não ter sido concluída com êxito.
12:17 Marcus: Pede esclarecimento: se a referência é a cancelamento ou reprogramação.
12:22 Vladimir: Detalha o cenário: necessidade de trocar equipamento ou impossibilidade de execução, e pergunta quais estados diferenciados existem no workflow.
12:29 Marcus: Responde que existe o estado cancelado, quando se verifica que a execução não será mais necessária, o que também retira a ordem do DMS, por deixar de existir. Para os casos de suspensão, quando houve intervenção durante a execução, existe o estado de suspensão da operação. Existe ainda o estado de reprogramação, quando a data planejada não pode ser cumprida e a atividade é remarcada.
13:17 Vladimir: Pergunta quais são as principais dores e o que, na visão de Marcus, deveria ser examinado com mais atenção diante da implantação prevista para 1º de setembro.
13:33 Marcus: Responde que, no momento, a configuração atual do OpenShift está atendendo, mas registra uma preocupação que vinha avaliando internamente em busca de otimização.
13:53 Marcus: Compara com o sistema de atendimento em campo, que trabalha com captura de alterações no banco, e identifica o mecanismo como CDC.
14:13 Marcus: Explica que o sistema de manutenção não utiliza CDC, porque o mecanismo não funcionaria nesse desenho. Detalha que o serviço cria, para cada empresa, um processo interno próprio, cada um responsável por uma base distinta do sistema de manutenção, realizando a consulta e o envio. Assim, quanto mais empresas entram no DMS, mais processos internos são criados.
14:13 Marcus: Registra que, por criar um processo por empresa, ainda não encontrou uma maneira válida de aplicar o escalonamento horizontal do OpenShift para dividir recursos.
15:11 Norberto: Pergunta se hoje é utilizado o mesmo serviço para todas as empresas ou um serviço para cada empresa.
15:18 Marcus: Confirma que existe um único serviço e que, internamente, para cada empresa já implantada no DMS, é criado um processo próprio responsável pelo monitoramento daquela origem.
15:20 Norberto: Confirma o entendimento de que, nessa configuração, não é possível escalar.
15:38 Vladimir: Registra que a escalabilidade é uma preocupação.
15:39 Marcus: Confirma e caracteriza o risco futuro: não conseguir aplicar o escalonamento horizontal e permitir que o OpenShift crie pods adicionais conforme a necessidade.
15:43 Norberto: Pergunta se o serviço é utilizado apenas para o ADMS.
16:01 Norberto: Observa que hoje existem apenas três empresas.
16:09 Norberto: Pergunta se o volume de solicitações de manutenção é baixo atualmente.
16:17 Marcus: Confirma que o volume é baixo e que o único momento de pico significativo é a implantação de uma nova empresa, quando o serviço recupera os dados anteriores e os envia de uma só vez. Após a implantação, o comportamento retorna ao normal, com processamento pontual à medida que as ordens surgem.
16:17 Marcus: Diferencia esse comportamento do sistema de atendimento em campo, caracterizado por grande volume de requisições instantâneas, e observa que este fluxo não forma fila relevante no Kafka. Aponta que a questão principal é o uso de memória alocada para manter o serviço em execução.
16:43 Norberto: Reforça a distinção para Vladimir: o que é programado passa por este fluxo de manutenção, enquanto o que não é programado corresponde à ordem de serviço de incidente, acionada em situações emergenciais.
17:24 Norberto: Confirma que este fluxo trata do que é programado.
17:28 Marcus: Acrescenta que, por ser diferente do incidente, no DMS a informação aparece como requisição de trabalho, em janela própria.
17:34 Vladimir: Consolida o entendimento de que o volume é menor porque se trata basicamente de manutenções preventivas e preditivas.
17:43 Vladimir: Pergunta o que se considera volume baixo, propondo uma ordem de grandeza para referência.
17:50 Marcus: Responde que o maior volume de que se recorda, a partir de comentários sobre a utilização do sistema, chega a cerca de 100 ordens no sistema de manutenção, sem que necessariamente todas atendam aos requisitos de envio e sem que o número corresponda a uma única empresa.
18:09 Marcus: Observa que o número pode ser maior, dependendo do dia e da empresa, e cita que uma das empresas possui quase dois milhões de ativos cadastrados.
18:25 Marcus: Acrescenta que o sistema de cálculo de manutenções pode criar várias solicitações de inspeção preventiva de uma só vez, e que a maior parte delas se enquadra nos critérios de envio, mas que isso não configura o padrão de rajada contínua observado no sistema de atendimento em campo.
18:50 Vladimir: Pergunta se o próprio sistema calcula quando as manutenções preditivas e preventivas são necessárias, ou se essa informação vem do SCADA e do ADMS.
19:05 Marcus: Responde que a ordem pode ser criada manualmente pelo operador no sistema de manutenção ou automaticamente pelo sistema especializado em cálculo de manutenção, que conhece a data da última manutenção e da última inspeção do ativo e calcula quando será necessária a próxima.
19:40 Marcus: Complementa que esse sistema define a data de serviço e programa a atividade automaticamente.
19:41 Vladimir: Confirma que é esse sistema que trata a manutenção preventiva.
19:45 Marcus: Confirma.
19:49 Vladimir: Observa que a manutenção preditiva, de modo geral, não existe, e que, se fosse implementada, envolveria o SCADA e técnicas de aprendizado de máquina.
19:59 Marcus: Responde que o próprio sistema de cálculo também utiliza dados de outra origem para essa finalidade.
20:14 Vladimir: Explica o conceito de manutenção preditiva: baseia-se no comportamento do equipamento, de modo que um comportamento errático justifica a intervenção mesmo quando a regra de periodicidade não a indica. Consolida o entendimento de que há mais de um sistema envolvido nessa integração.
20:32 Marcus: Registra que não detalhou integralmente o que está por trás do lado do sistema de manutenção, tendo tratado esse sistema como uma das pontas, e menciona o componente móvel utilizado em campo.
20:47 Marcus: Observa que esse componente é onde se registram as intervenções, mas que não é central para o caso em discussão.
20:52 Vladimir: Explica a motivação da pergunta sobre número único: observabilidade e rastreabilidade. Pergunta se já ocorreu algum caso de perda de informação entre os sistemas.
21:08 Vladimir: Detalha a pergunta: se houve situação em que a informação não retornou ou em que o número se perdeu.
21:16 Marcus: Responde que não houve perda de número. Relata que o problema já observado, e por ele corrigido, era específico do OpenShift: o Garbage Collector não atuava corretamente no momento em que era necessário liberar memória.
21:35 Marcus: Detalha que o consumo de memória crescia até extrapolar o limite definido, o que provocava o encerramento da aplicação por falta de memória. Ao reiniciar, a aplicação retomava do ponto anterior, sem perda de dados.
21:52 Vladimir: Pergunta se o Garbage Collector removia mais do que devia naquele momento.
21:56 Marcus: Esclarece que não: a memória não era liberada, e sim acumulada. Relata que testou parâmetros, com apoio da equipe responsável, para incluir na pipeline de implantação.
21:56 Marcus: Explica a causa: o pod não conseguia fazer a aplicação reconhecer o limite correto. Mesmo com o limite definido em cerca de um gigabyte, a aplicação enxergava o ambiente como um todo e continuava alocando além do que o pod admitia. O parâmetro adicionado teve exatamente a função de forçar a aplicação a considerar o limite do pod.
22:54 Marcus: Conclui que o ajuste faz a aplicação usar o limite do pod em vez do ambiente inteiro.
22:59 Vladimir: Pergunta se existe algum painel ou dashboard que acompanhe todo esse processo e fluxo.
23:09 Marcus: Responde que existe o dashboard do OpenShift, para acompanhar a execução do pod e os logs internos, e a plataforma ELK, utilizada para o acompanhamento dos logs.
23:27 Marcus: Detalha que a própria aplicação registra os eventos de monitoramento: ao chegar a determinada etapa, gera log de informação; em caso de erro, gera log de erro. Isso permite que a sustentação acompanhe o que está acontecendo. Exemplifica com o caso de alguém informar que uma ordem não chegou ao DMS.
23:27 Marcus: Explica que, nesse caso, é possível filtrar as mensagens especificamente pela ordem, para verificar se houve tentativa de reprocessamento, se a tentativa resultou em erro ou se não houve tentativa alguma.
24:03 Marcus: Acrescenta que, além disso, existe o próprio sistema de manutenção, onde se acompanha a criação da solicitação, e o ADMS, ponta final onde o operador visualiza o que está chegando.
24:20 Vladimir: Pergunta, além dos pontos já levantados, se a entrada do data center da Paraíba na equação em 1º de setembro traz alguma preocupação maior, em especial quanto a possíveis latências.
24:43 Marcus: Responde que, por enquanto, não. Registra como única preocupação um tema discutido durante a especificação do DMS, antes da homologação dos testes, que ainda gostaria de confirmar com os responsáveis, e pergunta se a nova entrada ocorreria como Grupo 2.
25:09 Norberto: Corrige: será o Grupo 1.
25:13 Norberto: Explica a inversão: o primeiro grupo implantado foi o Grupo 3, e a sequência passou agora para o Grupo 1.
25:16 Marcus: Registra que, de qualquer forma, trata-se de outro grupo.
25:25 Marcus: Relembra a conversa mantida com Pascoal na época, sobre a requisição feita aos adaptadores, na qual ele definiria uma maneira de identificar, pelo campo de origem, qual empresa está enviando a mensagem.
25:41 Marcus: Complementa que a identificação permitiria redirecionar automaticamente o endpoint, e que sua única preocupação é confirmar se esse mecanismo permanece previsto.
25:46 Norberto: Informa que essa conversa foi mantida com Gullit, atual responsável tanto pelo F5 quanto pelo API Gateway, que explicou o funcionamento: por meio do F5, mantém-se o direcionamento apontado.
26:02 Norberto: Detalha que o direcionamento aponta para um data center, enquanto o segundo, secundário, permanece inativo até que se identifique o chaveamento, momento em que o tráfego é redirecionado. Registra que há uma etapa desse processo executada manualmente.
26:17 Norberto: Informa que a equipe questionou a possibilidade de automatizar essa etapa, em conversa recente.
26:23 Marcus: Solicita ser envolvido nesse tema, informando que estava sem acompanhamento do andamento da conversa e que é cobrado internamente a respeito. Reforça que a preocupação da equipe é não haver necessidade de qualquer ação do lado do sistema de manutenção quando a solução entrar em produção.
26:49 Norberto: Relata que o tema foi tratado na última reunião com Vladimir presente, e que, no último caso de transbordo, a equipe de monitoração entrou em contato e o responsável executou a operação manualmente pelo próprio F5.
27:12 Vladimir: Avalia positivamente a visão integrada obtida na conversa e verifica se há pontos adicionais.
27:21 Norberto: Não apresenta pontos adicionais.
27:23 Marcus: Considera que abordou todos os pontos referentes à sua frente.
27:28 Vladimir: Solicita a Marcus e a Vinícius o envio do fluxo apresentado.
27:37 Marcus: Informa que fará uma revisão final do material, verificando eventuais ajustes de texto, e o encaminhará por e-mail.
27:42 Vladimir: Reforça que o conteúdo é o mais relevante e reitera o pedido de envio.
27:55 Participantes: Encerram a reunião com agradecimentos mútuos, incluindo o reconhecimento do conteúdo apresentado.
Anexo B · Termos normalizados e trechos que exigem validação¶
A transcrição foi produzida por reconhecimento automático de voz e apresenta corrupção relevante de nomes de sistemas, de pessoas e de empresas, além de interjeições em inglês inseridas indevidamente. Os itens abaixo devem ser confrontados com a documentação oficial do programa.
- Nome oficial e sigla do sistema de manutenção, referido na transcrição de forma variável e inconsistente.
- Nomes dos três microserviços que compõem a integração, cujas denominações aparecem corrompidas na transcrição e devem constar do fluxograma a ser encaminhado.
- Nome oficial do sistema responsável pelo cálculo automático das manutenções preventivas.
- Nome oficial do sistema de atendimento em campo citado como origem das pendências técnicas e cadastrais e como referência de comparação de volumetria.
- Denominação do componente móvel utilizado em campo para registro das intervenções.
- Identificação da empresa citada como possuidora de quase dois milhões de ativos, cujo nome aparece corrompido na transcrição.
- Grafia dos nomes próprios citados, entre eles Marcus Vinicius Alves de Castro, também tratado como Marcos, além de Pascoal, Gullit, Estevam e Vinícius.
- Formato exato do identificador da requisição de trabalho gerado no DMS.
- Confirmação do limite de memória configurado para o pod e dos parâmetros de JVM efetivamente aplicados na pipeline.
- Confirmação de que o mecanismo de identificação da empresa pelo campo de origem da requisição permanece previsto para a entrada em produção.
1.8.27. Observações finais¶
Esta ata foi consolidada a partir de dois documentos produzidos sobre a mesma sessão: a compilação detalhada da reunião e a transcrição da gravação. O registro cronológico do Anexo A preserva a sequência e o conteúdo técnico da conversa, com condensação de trechos sem conteúdo relevante e normalização dos termos corrompidos pelo reconhecimento automático. As classificações de risco e as recomendações têm caráter indicativo e serão refinadas nas etapas seguintes da consultoria.