Ata 11 · Monitoramento e Observabilidade das Integrações do ADMS: Zabbix, Datadog, ELK, Streaming de Eventos, Segurança de Dados e Ambiente Multicloud (27 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	27 de julho de 2026 (segunda-feira)
Horário	10h02 às 11h08, horário de Brasília
Duração	Aproximadamente 1h06 de sessão
Plataforma	Microsoft Teams (reunião remota, com gravação e transcrição automática)
Natureza	Sessão técnica de levantamento e assessment arquitetural
Tema	Monitoramento e observabilidade das integrações do ADMS: ferramentas, cobertura, correlação de eventos, governança de logs, segurança de dados sensíveis e distribuição multicloud
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.12.1. Identificação e contexto da sessão¶

1.12.1.1. Posicionamento da sessão no assessment¶

A reunião foi aberta com a contextualização do trabalho: a Syntropy Labs conduz uma revisão das integrações relacionadas ao ADMS de ponta a ponta, demanda originada no próprio projeto a partir dos percalços observados na primeira implantação, parte deles já sanados. O método declarado é iniciar por uma visão macro e descer progressivamente ao detalhe de cada componente, equipe e integração.

Foi registrado na abertura que esta sessão ocorre depois de dez áreas já entrevistadas e que o momento é adequado, por funcionar como fechamento parcial da sequência de levantamentos. Diferentemente das sessões anteriores, centradas em fluxos e componentes, esta reuniu as áreas que observam todos esses fluxos: monitoração de infraestrutura, observabilidade de aplicações e telemetria de logs.

1.12.1.2. Escopo técnico abordado¶

Ambientes de tecnologia operacional e de tecnologia da informação, com suas redes segregadas.
Servidores, redes, bancos SQL Server, serviços e processos Windows.
APIs, microserviços em .NET e em Java, OpenShift e Kubernetes.
Confluent Kafka e observabilidade de streaming de eventos.
Ecossistema Elasticsearch, Logstash e Kibana, referido internamente como ELK ou LK.
Datadog como plataforma de APM e observabilidade de aplicações.
Data lake e Databricks no Azure, componentes na AWS, consumo de APIs do Google e identidade Microsoft.

1.12.1.3. Limites da sessão e critério de fidelidade¶

A sessão teve caráter exploratório e de mapeamento. Não foram apresentados inventário formal de ativos monitorados, arquitetura documentada do ambiente de logs, volumetria diária, políticas de retenção por classe de informação, indicadores de tempo médio de detecção e de recuperação nem cronograma das iniciativas em curso.

Além disso, a associação automática entre rótulos de falante e pessoas não se manteve estável ao longo da gravação. Por essa razão, o registro cronológico do Anexo A atribui as falas por papel funcional, e não nominalmente, e os termos capturados de forma foneticamente imprecisa estão relacionados no Anexo B para confirmação antes de comporem desenho de arquitetura ou decisão formal.

1.12.2. Participantes e áreas envolvidas¶


Vladimir Morozowski de Sousa	Syntropy Labs. Condução do assessment e registro da sessão.	Participação confirmada
João Carlos Franco Castellani	Syntropy Labs. Condução da análise sobre correlação, linhagem de eventos, retenção, proteção de dados e centralização.	Participação confirmada
Norberto da Silva Prado	Energisa. Contextualização do assessment, articulação das áreas e complementação sobre ambiente multicloud e histórico das soluções.	Participação confirmada
Fernando	Energisa. Datadog, instrumentação e observabilidade de aplicações.	Participação confirmada
Gabriel	Energisa. Monitoração e operação, referida internamente como N0 ou NOC, e monitoração de infraestrutura.	Participação confirmada
Éder Xavier	Energisa. Especialista responsável pelo ambiente ELK, apresentado como dono da plataforma de logs.	Participação confirmada
Willians e Nicolas	Energisa. Equipe de monitoração e operação.	Participação confirmada

Foram citados, sem participação direta na sessão:

João e Fabiano, responsáveis pela instrumentação do Confluent Kafka no Datadog.
Hugo, da infraestrutura, envolvido na reestruturação do ambiente de logs.
Rômulo, cuja equipe de arquitetura responde pela administração do conector que integra o Kafka ao ambiente de logs.
Valéria, que determinou a suspensão do backup do ambiente de logs por afetar os demais ambientes.
Douglas Maldonado, Thales e Lavínia, da equipe de dados responsável pelo Databricks e pelo Azure.
Douglas Torres, do desenvolvimento do WFM, que havia relatado a dor de visibilidade da integração com o DMS.
Karina, da equipe macro de operação e infraestrutura, e Wellington, envolvido na tratativa sobre o volume de logs enviado pelas torres de desenvolvimento.
Alessandro, coordenação citada nas conversas anteriores sobre centralização da telemetria.
Elastic e seu parceiro oficial, envolvidos na reestruturação do ambiente de logs.

1.12.3. Resumo executivo¶

A sessão consolidou uma visão ampla do ecossistema de monitoramento e observabilidade associado às integrações do ADMS. O cenário atual é funcional, porém distribuído entre diversas ferramentas, domínios tecnológicos e equipes. O modelo pretendido começa a se organizar por responsabilidade, com Zabbix para infraestrutura, Datadog para aplicações e APM e ELK para logs e telemetria, mas essa separação ainda não está integralmente implementada e coexiste com Grafana, Prometheus, PRTG, Oracle OEM, CloudWatch, X-Ray, mecanismos nativos do API Gateway e recursos do Databricks.


Cobertura ponta a ponta	O Datadog não foi viabilizado no ambiente de tecnologia operacional, onde o ADMS foi implantado de forma segregada, e a cobertura se divide entre monitoração de infraestrutura e observabilidade de aplicações.	Alta
Instrumentação parcial	A cobertura do Datadog alcança três das nove unidades, com cerca de 85% das APIs instrumentadas nessas três.	Alta
Plataforma de logs	O ambiente ELK é anterior ao OpenShift, consome recursos em excesso, opera com storage compartilhado e passa por reestruturação ampla.	Alta
Governança de telemetria	Um único tópico de telemetria recebe registros de 151 aplicações, o que impede gestão de volumetria, de propriedade e de impacto.	Alta
Proteção de dados	Não foi confirmada a existência de mascaramento preventivo no fluxo de logs, e a criptografia em trânsito no trecho do Kafka de telemetria foi citada como lacuna em tratamento.	Alta
Observabilidade de eventos	A instrumentação do Confluent Kafka no Datadog está em homologação e é o que permitirá acompanhar produtor, consumidor, latência e profundidade de fila.	Alta
Resposta operacional	O tratamento de incidentes é predominantemente manual, com automação de remediação ainda incipiente.	Média
Ambiente multicloud	Componentes em Azure, AWS e consumo de APIs do Google possuem telemetria própria e não consolidada na visão corporativa.	Média

Síntese do assessment

A maturidade de detecção é superior à maturidade de resposta e, principalmente, à de correlação. Onde o Datadog está instrumentado, a profundidade é boa: há correlação automática de logs, métricas e traces, visão de dependências, latência e alertas técnicos e de negócio. O problema não é a qualidade das ferramentas, e sim a ausência de uma arquitetura de observabilidade que defina fonte oficial por tipo de ativo, limites de sobreposição, cobertura mínima, retenção por classe, modelo de acesso e responsabilidade. Enquanto isso não existir, cada nova solução acrescenta uma fonte de telemetria em vez de reduzir o tempo de diagnóstico.

1.12.4. Visão consolidada da arquitetura de observabilidade¶

A arquitetura atual pode ser entendida como um conjunto de domínios parcialmente sobrepostos, construídos em momentos distintos. Não existe, até o momento, uma visão unificada e formalmente governada de toda a telemetria.


Infraestrutura de OT e de TI	Zabbix	Rede, switches, servidores, recursos, visualizador de eventos, serviços Windows, bancos SQL Server e seus jobs.	Operacional, com instâncias distintas para OT e para TI
Aplicações e APIs críticas	Datadog	APM, traces, métricas, logs correlacionados, dependências, latência e alertas.	Em expansão, com cobertura parcial por unidade
Logs e telemetria	ELK	Centralização de logs, investigação, apoio à homologação e às salas de crise.	Crítico, porém legado e em reestruturação
Streaming de eventos	Confluent Kafka com o módulo de data streaming do Datadog	Produtores, consumidores, tópicos, latência e profundidade de fila.	Instrumentação em homologação
Plataforma de contêineres	Prometheus e Grafana	Métricas internas do OpenShift e do próprio Confluent Kafka.	Disponível e utilizado em casos específicos
Nuvem AWS	CloudWatch e X-Ray	Monitoramento e observabilidade dos componentes executados na AWS.	Descentralizado no domínio da solução
Nuvem Azure e Databricks	Recursos nativos, com integração ao Datadog planejada	Trilhas de auditoria, pipelines, aplicações e métricas.	Monitoramento não previsto originalmente, em construção
Rede corporativa	PRTG	Links e equipamentos de rede, com migração gradual em curso.	Legado ainda ativo
Bancos Oracle	Oracle Enterprise Manager	Monitoramento dos bancos Oracle e alguns indicadores de negócio.	Uso complementar
API Gateway	Mecanismo próprio da plataforma	Registros e monitoramento específicos do gateway.	Silo adicional, com nomenclatura não padronizada

A organização caminha para um modelo de ferramenta por responsabilidade, mas ainda não possui plano de convergência que defina fonte oficial, limites de sobreposição, regras de retenção, modelo de acesso, integração de alertas, propriedade e cobertura mínima por tipo de ativo. Foi contabilizado na própria sessão que existem entre seis e oito ferramentas em uso, sem contar os registros nativos de cada plataforma.

1.12.5. Zabbix e monitoração de infraestrutura¶

O ADMS nasceu em ambiente segregado de tecnologia operacional, com componentes e monitoração próprios. Existem instâncias distintas de Zabbix para o ambiente de OT e para a rede corporativa de TI, o que decorre da própria segregação de redes.

No escopo do ADMS, a cobertura se organiza de forma macro em três áreas: rede, bancos de dados e servidores.
Em rede, são monitorados switches core, switches associados aos servidores e demais recursos de conectividade.
Em servidores, além da camada de recursos, são monitorados o visualizador de eventos, os processos Windows e os serviços principais do DMS, que executam como serviços do sistema operacional.
Em bancos de dados, são monitorados os SQL Server, seus jobs e a camada de banco em geral.
A cobertura do ambiente de OT é mais profunda em infraestrutura, enquanto o Datadog está concentrado no lado de TI e na camada de aplicações.

O Zabbix é, portanto, a referência de infraestrutura para o ADMS, inclusive nos pontos em que o Datadog ainda não foi arquitetado para operar dentro da OT. A extensão do Datadog ao ambiente operacional foi considerada desde os primeiros momentos, com o objetivo declarado de obter visão ponta a ponta, mas ainda não foi viabilizada porque depende de desenho arquitetural e de aprovação.

1.12.6. Operação do NOC e automação de remediação¶

O tratamento de incidentes é majoritariamente manual. Os alertas chegam a um console de operação e estão integrados à ferramenta de gestão de serviços, o que permite atuação rápida. A equipe de monitoração identifica o evento e aciona o time responsável pela resolução.

A iniciativa de auto-remediação mais concreta está relacionada à limpeza de disco: quando determinadas pastas atingem o limite, rotinas removem logs temporários ou arquivos previamente classificados como descartáveis. A própria equipe qualificou esse trabalho como inicial, registrando que pouca coisa se auto-remedia hoje.

Implicação operacional

A maturidade de detecção é superior à maturidade de resposta automatizada. A ausência de roteiros executáveis eleva o tempo médio de recuperação, aumenta a dependência de especialistas e introduz risco de inconsistência em incidentes fora do horário comercial. Esse ponto se conecta diretamente ao registrado em sessões anteriores sobre consumidores que não retomam o processamento automaticamente após reinícios: parte do esforço manual de operação decorre de comportamentos que poderiam ser tratados na própria aplicação.

1.12.7. Datadog, APM e cobertura de instrumentação¶

O Datadog foi introduzido por projeto no ano anterior, quando foram feitas as primeiras instrumentações, e vem sendo expandido à medida que aplicações e APIs são instrumentadas. Foi registrado com franqueza que o objetivo de visão ponta a ponta esperado pelo projeto ainda não foi alcançado, porque depende de ações do time de desenvolvimento durante a implementação e da definição do que deve ser instrumentado.


Capacidades	Correlação de logs, traces e métricas, latência, consumo de recursos, erros, implantações e dependências das requisições.
Foco	Monitoramento concentrado nas APIs e endpoints considerados críticos. As demais APIs e endpoints são acompanhadas por mecanismo distinto.
Cobertura	Três das nove unidades, com aproximadamente 85% das APIs instrumentadas nessas três.
Instrumentação	Inserida no processo de desenvolvimento e de DevOps, por manifesto e pipeline, com esforço descrito como poucas linhas de configuração.
Tecnologias	Predominância de .NET, com componentes em Java, como o motor de cálculo de indicadores citado na sessão.
Alertas	Erros de servidor podem acionar sala de guerra. Existem também alertas de negócio, definidos com as áreas responsáveis, que disparam intervenção da sustentação.
Retenção	Métricas mantidas por 15 meses após a transformação e a ingestão.
Modelo de entrega	Serviço em nuvem, contratado como SaaS.

A instrumentação é responsabilidade compartilhada entre desenvolvimento e sustentação: quando o time coloca a aplicação em operação, o cadastro no DevOps e a inclusão no manifesto ativam a instrumentação já existente na esteira. A consequência arquitetural é direta: a plataforma não oferece observabilidade de componentes que não foram instrumentados, de modo que a cobertura depende de disciplina de engenharia, de padrões de pipeline, de critérios de criticidade e de governança de entrada de novas aplicações.

1.12.8. Correlação de chamadas e linhagem de eventos¶

1.12.8.1. Correlação em chamadas síncronas¶

Para APIs e chamadas síncronas já instrumentadas, o Datadog permite acompanhar a cadeia de requisições, incluindo origem, dependências, saltos, tempos de resposta e destino. Foi citado um recurso de correlação habilitado no momento da instrumentação, que associa automaticamente os registros: a requisição é acompanhada desde a origem, cada ponto em que ela registra log gera um trecho de rastreamento, e o trace pode ser percorrido do disparo até o consumo final.

1.12.8.2. Diferença entre telemetria e APM¶

A sessão delimitou com clareza os papéis das duas plataformas. O ELK fornece telemetria e profundidade de logs, e nele a correlação depende de um campo explícito de identificador de correlação, inserido pela aplicação e preservado ao longo dos registros. O Datadog fornece APM e visão integrada do ciclo de vida da transação, com correlação automática a partir da instrumentação. Foi registrado que o consumo de telemetria hoje está concentrado no ELK, que os logs são registrados nele e que, em homologação e em salas de crise, as equipes olham os dois lados.

1.12.8.3. Lacuna central: linhagem de transformação de eventos¶

O ponto de maior densidade técnica da sessão foi a distinção entre conhecer a relação estática entre produtor, tópico e consumidor e conseguir rastrear a transformação da informação ao longo da cadeia.

Cenário apresentado pela consultoria

Uma API gera um evento e o publica em um tópico. Um microserviço consome esse evento, transforma o conteúdo e publica um segundo evento em outro tópico, que por sua vez é consumido adiante. Se o componente intermediário aplicar uma regra de negócio equivocada, ele produz um evento inconsistente, e o problema se manifesta apenas no consumidor final. Sem linhagem, a investigação parte do sintoma e não do ponto de quebra. A pergunta formulada foi exatamente essa: é possível identificar qual componente transformou o evento e em que ponto a informação se tornou inconsistente?

A resposta registrada é que o módulo de data streaming permitirá acompanhar o caminho da mensagem, identificando a origem do evento, as trilhas que ele percorre, os intermediários que fazem a distribuição e o endpoint de destino da requisição. Esse é, portanto, o recurso que endereça a lacuna, e sua conclusão passa a ser um item relevante do assessment, e não apenas uma entrega de infraestrutura.

1.12.9. Instrumentação do Confluent Kafka e data streaming¶

A instrumentação do Confluent Kafka no Datadog está em fase de homologação, conduzida pelo time responsável pelo Kafka. A iniciativa nasceu de forma secundária ao ADMS, motivada pelo porte do ambiente e pelo volume de informação que trafega no barramento, e o time optou por validar a integração antes de levá-la a produção.


Visibilidade de produtores e consumidores	Identificação dos componentes que publicam e que consomem em cada tópico.
Latência	Medição do tempo associado ao fluxo e ao consumo das mensagens.
Profundidade de fila	Avaliação de acúmulo, atraso e ritmo de consumo, permitindo perceber quando um consumidor parou ou está represado.
Trilha da mensagem	Acompanhamento do caminho e dos saltos entre a origem e o destino.
Correlação com aplicações	Associação do fluxo de eventos aos serviços já instrumentados.
Limite atual	A observabilidade trata de metadados, fluxo e inferência da transação, e não expõe o conteúdo do payload.

Foi esclarecido um ponto relevante de escopo: a instrumentação do Kafka não exige ação das equipes de desenvolvimento. Com a aplicação já monitorada, o Datadog reconhece que uma requisição envolve um tópico e mostra sua latência, mas sem detalhamento. A instrumentação no próprio Kafka é o que traz a granularidade necessária para tornar a correlação de eventos mais específica. No estado atual, a plataforma chega ao nome do produtor por inferência e apresenta a transação de forma mínima.

1.12.10. Ambiente ELK: arquitetura atual¶

O ambiente de logs e telemetria é executado em instalações próprias e é anterior à adoção do OpenShift, razão pela qual não está hospedado no cluster. Ele opera em servidores virtuais Linux, com composição relatada de cinco nós Elasticsearch, um Kafka dedicado ao fluxo de logs, Logstash e servidor Kibana.

1. As aplicações publicam seus registros em tópicos de um Kafka dedicado à telemetria, distinto do barramento corporativo.

2. Um conector construído pela equipe de arquitetura consome esses tópicos. A administração do conector é responsabilidade da equipe de arquitetura de integração.

3. O conteúdo é entregue ao Logstash, onde estão os pipelines de transformação.

4. Os dados são indexados no Elasticsearch.

5. Os usuários consultam os registros pelo Kibana.

Existem consultas específicas de banco de dados que alimentam o Elasticsearch diretamente, sem passar pelo Kafka, em volume descrito como pequeno.
O Kafka utilizado pela telemetria é dedicado e não compartilha o cluster do barramento corporativo, o que foi avaliado positivamente na sessão, dado que o compartilhamento sobrecarregaria ainda mais o ambiente já analisado na Ata 10.
Mesmo com a expansão do Datadog, os participantes não consideram provável a eliminação do ELK, em razão do volume de informação trafegada, da retenção e do licenciamento.

1.12.11. Reestruturação do ambiente ELK¶

A equipe conduz uma reconstrução ampla do ambiente, descrita de forma enfática como jogar no chão e construir do zero. O trabalho envolve a infraestrutura interna, especialistas da Elastic e o parceiro oficial do fabricante, com avaliação de boas práticas e de alternativas em instalações próprias, híbridas ou em nuvem, conforme o custo.

Os motivadores relatados são consumo excessivo de recursos e competição com os demais ambientes. O ambiente de logs foi descrito como algo que envolve praticamente toda a infraestrutura, e a intenção é separá-lo dos demais, com recursos mais robustos e dedicados.

Storage compartilhado como ponto crítico

O compartilhamento de storage foi qualificado na sessão como o calcanhar de Aquiles do ambiente. Em determinado momento houve necessidade de adicionar novos discos e o rebalanceamento gerou problemas que afetaram não apenas a plataforma de logs, mas também os demais serviços que utilizavam o mesmo local de armazenamento. Como consequência, o backup do ambiente de logs foi suspenso por determinação da área responsável, justamente porque estava afetando os outros ambientes. Foi essa sequência de eventos que originou a conversa sobre a reestruturação.


Infraestrutura	Alto consumo de recursos e competição com os demais ambientes.	Separar a plataforma de logs e adotar recursos dedicados e mais robustos.
Storage	Compartilhado, com rebalanceamentos que afetaram outros serviços.	Arquitetura de storage dedicada, com as práticas recomendadas pelo fabricante.
Topologia	Arquitetura legada, anterior ao OpenShift, em servidores virtuais.	Reavaliar instalação própria, modelo híbrido ou nuvem, com base em custo e desempenho.
Operação	Backup suspenso por impacto nos demais ambientes.	Redesenhar proteção, capacidade e observabilidade da própria plataforma.
Dados	Muito ruído e baixa rastreabilidade de origem e de volume.	Governança por aplicação, por tópico e por política de retenção.
Segurança	Lacunas de criptografia em trânsito e de mascaramento.	Criptografia fim a fim, prevenção de perda de dados e controles preventivos.

A reestruturação não deve ser tratada como simples aumento de capacidade. A própria equipe destacou que a frente não é apenas de hardware e que envolve arquitetura, governança de logs, organização de tópicos, retenção, segurança, volumetria e conscientização das torres de desenvolvimento. Foi acordado incluir a consultoria na recorrência de reuniões dessa frente, por convergência direta com o assessment.

1.12.12. Governança de logs, retenção e volumetria¶

A retenção informada para logs de produção é de 15 dias. Os participantes reconheceram uma tensão explícita: esse período pode ser insuficiente para investigação, auditoria e análise histórica, mas o volume de informação desnecessária enviado pelas aplicações é excessivo, de modo que boa parte da capacidade é ocupada por conteúdo sem valor analítico.

Caso concreto de perda de governança

Foi citado um tópico de telemetria denominado API atendimento que recebe registros de 151 aplicações. Nesse modelo, a equipe responsável pela plataforma perde a gestão: se um novo microserviço passa a publicar no mesmo tópico, não há como conhecer a volumetria previamente nem atribuir o impacto a um responsável, e o resultado recorrente é problema de espaço. A direção em discussão é impedir que mais de uma aplicação compartilhe o mesmo tópico de telemetria, permitindo gestão individualizada por aplicação.

Em paralelo, existe um trabalho de conscientização junto às torres de desenvolvimento sobre o que deve ser enviado e o que precisa ser retido. O exemplo utilizado foi direto: enviar mensagens de erro e também mensagens informando que o sistema está normal, repetidas ao longo de meses, torna a retenção inviável. Foi registrado que o responsável atual herdou o ambiente já nessa condição e que a coordenação está sendo alinhada para estabelecer prazo às torres.

A recomendação derivada é instituir um contrato de logging com taxonomia, severidade, esquema, volume máximo, dados pessoais permitidos e proibidos, responsável, índice ou tópico de destino, retenção e custo imputável. Sem esse contrato, a expansão de capacidade tende apenas a postergar o problema, uma vez que a causa é a ausência de critério na origem.

1.12.13. Segurança, criptografia, dados pessoais e LGPD¶

1.12.13.1. Assimetria entre as plataformas¶

A sessão identificou tratamentos distintos entre as duas plataformas. No Datadog, dados como CPF, telefone e cartão de crédito foram descritos como anonimizados, com uma camada de prevenção de perda de dados atuando sobre o conteúdo. O comportamento é transparente tanto para a aplicação quanto para a plataforma, e os campos sensíveis não ficam visíveis na análise. O exemplo apresentado foi o de um módulo de visualização que simula o atendimento ao cliente, no qual CPF e número de celular aparecem anonimizados na própria tela.

No fluxo de telemetria associado ao Kafka e ao ELK, a situação é diferente. Foi reconhecido que, se uma aplicação enviar dados sensíveis no payload e o pipeline estiver configurado para recebê-los, esses dados chegam ao Kafka, ao Logstash e ao Elasticsearch. Não foi confirmada a existência de mascaramento ou de bloqueio preventivo, de modo que a proteção depende fortemente do comportamento da aplicação e da configuração dos pipelines.

1.12.13.2. Criptografia em trânsito¶

Foi registrado que o trecho do Kafka de telemetria não utilizava criptografia em trânsito e que a inclusão de TLS estava sendo tratada, tema levantado também pelo escritório de segurança. Trata-se de lacuna com implicação direta de conformidade, agravada pela possibilidade de trânsito de dados pessoais no mesmo fluxo.

1.12.13.3. Formato dos registros e ausência de padrão aberto¶

Foi descrito que as aplicações enviam uma estrutura definida especificamente para cada uma, em JSON, com um bloco de informações próprias combinado a uma estrutura genérica utilizada internamente, e que todo esse conteúdo trafega no mesmo payload até o Kafka. Foi confirmado que o OpenTelemetry não é utilizado hoje e foi citado como algo novo a ser considerado. A ausência de um padrão aberto de instrumentação dificulta a portabilidade entre plataformas e a normalização da telemetria, tema que se conecta diretamente à discussão de centralização.

1.12.13.4. Recomendação de controles em camadas¶

Prevenção na aplicação e na biblioteca de logging, evitando que o dado sensível seja gerado no registro.
Validação no conector e no broker, bloqueando o que não estiver conforme o contrato de logging.
Transformação e mascaramento nos pipelines do Logstash, antes da indexação.
Políticas de ingestão e de indexação no Elasticsearch, com detecção de segredos.
Criptografia em trânsito fim a fim, com gestão de certificados.
Auditoria de acesso aos índices e trilha de consulta.

A conformidade não deve depender de uma única ferramenta nem de disciplina manual das equipes. A assimetria observada entre as duas plataformas é, em si, o argumento: o mesmo dado sensível é protegido em um caminho e pode ficar exposto no outro.

1.12.14. Centralização e correlação multifonte¶

Não existe projeto formal aprovado para unificar as ferramentas. O que existe são conversas entre as áreas para reduzir a fragmentação e diminuir o número de soluções, hoje entre seis e oito. A visão de curto e médio prazo apresentada é concentrar infraestrutura no Zabbix, aplicações no Datadog e telemetria no ELK, com o reconhecimento explícito de que ainda existe caminho a percorrer para chegar a esse nível.

Foi mencionada a intenção de colocar todos os alertas em um único lugar e de enriquecê-los com informações de diferentes fontes. O mecanismo citado para essa correlação é a configuração de uma camada de consulta sobre múltiplas fontes de monitoramento, referida na sessão como MCP, possivelmente utilizando capacidades já existentes nas duas plataformas principais. Não foram detalhados protocolo, segurança, arquitetura de agentes, catálogo de ferramentas, modelo de dados nem governança dessa camada.

Uma squad dentro da equipe interna de operação e infraestrutura conduz provas de conceito com parceiros, com o objetivo de centralizar os dados de todas as ferramentas, correlacioná-los e geri-los em um único lugar.
A arquitetura pode concentrar os dados no próprio ELK ou utilizar outra plataforma de correlação, decisão ainda não tomada.
O consenso registrado é evitar, neste momento, a compra de uma nova ferramenta, explorando primeiro as capacidades já contratadas e validando casos de uso antes de qualquer aquisição.
Foram citadas empresas parceiras envolvidas nessas provas de conceito, cujos nomes constam do Anexo B para confirmação.

1.12.15. Ambiente híbrido e distribuição multicloud¶

O ambiente foi caracterizado como híbrido e próximo de uma distribuição multicloud, com componentes em instalações próprias, no Azure, na AWS e consumo de APIs do Google. Essa diversidade multiplica as fontes de telemetria e aumenta a necessidade de normalização e de centralização.


Instalações próprias, OT e TI	ADMS, bancos, servidores, OpenShift e a própria plataforma de logs.	Zabbix, Datadog, ELK, Prometheus e Grafana.	Cobertura ponta a ponta ainda incompleta, sobretudo na OT.
Azure	Data lake, Databricks, aplicações e pipelines.	Trilhas de auditoria nativas, com integração ao Datadog planejada.	Monitoramento não previsto no projeto original.
AWS	Plataforma de integração com a solução de mobilidade, sincronização de dados e armazenamento de objetos para arquivos e fotos tiradas em campo.	CloudWatch e X-Ray.	Telemetria descentralizada e não consolidada.
Google Cloud	APIs de mapa, geocodificação e geolocalização utilizadas pela mobilidade e pelo WFM, além de um serviço recente de otimização e roteirização.	Não detalhada na sessão.	Dependência de APIs externas sem visão consolidada.
Identidade Microsoft	Entra ID e diretórios separados entre ambientes.	Registros próprios, não detalhados.	Ausência de relação de confiança entre os diretórios.

A solução na AWS foi contextualizada: ela realiza a integração entre a mobilidade e os dados que permanecem em instalações próprias, substituindo um modelo antigo no qual o dispositivo em campo acionava diretamente o ambiente interno. A modernização adotou um padrão orientado a eventos e utiliza serviços da própria nuvem, incluindo sincronização com a mobilidade e armazenamento de objetos para as fotos de campo. O serviço de otimização e roteirização citado no Google Cloud é recente e está relacionado a uma evolução futura do projeto, a ideia de despacho automático.

Foi registrado ainda que existiu, antes mesmo da entrada do Datadog, uma iniciativa de criar uma API capaz de disparar os logs dos ambientes em nuvem e integrá-los ao ELK interno, de modo a centralizar a visão. A API chegou a ser construída, mas, ao que se sabe, não entrou em produção nem foi utilizada.

1.12.16. Azure, Databricks e lacuna de monitoramento¶

O data lake e o Databricks possuem mecanismos granulares de auditoria. A liberação de acesso e a forma de monitorar são granulares a ponto de permitir identificar quem acessou, quando acessou e até qual coluna foi consultada. Foi delimitado com precisão, porém, que isso constitui trilha de auditoria, e não observabilidade operacional consolidada.

A monitoração do Databricks e das aplicações no Azure não foi prevista pelo time de projeto. Como consequência, as demandas estão sendo devolvidas à arquitetura para incluir o monitoramento das aplicações executadas em modelo sem servidor e a integração com o Datadog. A conexão depende de autorização do time de segurança e da criação de uma aplicação de integração no Azure para permitir a coleta das métricas. A decisão foi tomada na semana anterior à sessão, com a equipe de dados.

Padrão recorrente identificado

A ausência de previsão de monitoramento no escopo original de um projeto não é um caso isolado: ela reaparece na cobertura parcial das unidades, na extensão do Datadog ao ambiente operacional e na instrumentação do Kafka, todas tratadas como iniciativas posteriores à entrega. A recomendação decorrente é incorporar observabilidade como requisito de arquitetura e como critério de aceite de projeto, e não como frente subsequente conduzida pela sustentação.

1.12.17. Identidade e segregação de diretórios¶

O Entra ID é utilizado na identidade Microsoft, com componentes também em instalações próprias. Existem diretórios separados entre os ambientes, incluindo a rede corporativa, e foi confirmado que ainda não há relação de confiança entre eles. A equipe sugeriu envolver os especialistas de identidade em uma conversa específica.

A segregação impacta autenticação de serviços, contas técnicas, integração das próprias ferramentas de observabilidade, experiência de acesso, auditoria e resposta a incidentes. A sessão não detalhou federação, sincronização, controle de acesso baseado em papéis nem mecanismos de acesso privilegiado, itens que permanecem em aberto.

1.12.18. WFM, DMZ e acesso aos logs de integração¶

Ao final da sessão foi retomada uma dor relatada anteriormente pela equipe do WFM. O sistema envia informações ao DMS, mas o trecho de integração não é visível para o time de desenvolvimento e sustentação. Quando ocorre um problema, a equipe precisa solicitar à infraestrutura a recuperação dos logs, porque não possui acesso direto. O fluxo foi descrito literalmente como uma caixa preta, com impacto maior porque muitas dessas situações são emergenciais e a equipe participa da sustentação enquanto o sistema está em operação assistida.

Convergência com a Ata 08

Esta é a mesma dor registrada na sessão com a equipe do WFM, documentada no item 1.9. O que a sessão de observabilidade acrescenta é a causa estrutural e o caminho de solução: não se trata de ausência de logs, e sim de ausência de acesso e de visão self-service sobre logs que existem e ficam retidos em um domínio de infraestrutura ao qual a equipe de desenvolvimento não tem acesso. A convergência entre as duas sessões eleva o item de reclamação pontual para requisito de arquitetura de observabilidade.

Uma iniciativa anterior considerou instalar um agente da plataforma de logs na DMZ, para coletar e disponibilizar os registros dessa integração. Foi avaliado que a implementação não é tecnicamente complexa, mas o tema perdeu acompanhamento durante mudanças de responsáveis e períodos de férias. Os participantes concordaram em retomar uma agenda específica.

Foi registrado também que a equipe de desenvolvimento do WFM gera um identificador de correlação próprio e o utiliza para conseguir reconstituir o rastro das operações, prática que confirma tanto a necessidade quanto a ausência de um mecanismo corporativo padronizado. A solução recomendada precisa equilibrar autonomia operacional e segurança: em lugar de conceder acesso amplo à plataforma de logs, disponibilizar painéis, buscas salvas, visões por aplicação e perfis de acesso com dados minimizados, acompanhados de trilha de auditoria.

1.12.19. Matriz consolidada de ferramentas¶


Zabbix	Infraestrutura de OT e de TI	Profundidade em rede, servidores, banco e serviços, com presença no ambiente operacional.	Instâncias separadas por ambiente e correlação de negócio e de traces limitada.
Datadog	APM e observabilidade de aplicações	Correlação automática, traces, dependências, latência, alertas e anonimização de dados sensíveis.	Cobertura parcial por unidade, ausência na OT e instrumentação do Kafka em evolução.
ELK	Logs e telemetria	Detalhamento de logs, investigação e retenção sob controle interno.	Infraestrutura legada, alto consumo, storage compartilhado, retenção curta, ruído e lacunas de segurança.
Confluent Kafka	Streaming de eventos	Base da integração assíncrona e fonte de telemetria dos fluxos.	Instrumentação detalhada ainda em homologação.
Prometheus e Grafana	Métricas do OpenShift e do Confluent	Visibilidade nativa da plataforma de contêineres.	Mais uma fonte descentralizada de telemetria.
CloudWatch e X-Ray	Componentes na AWS	Integração nativa com os serviços da própria nuvem.	Não consolidado com a visão corporativa.
Recursos do Databricks e do Azure	Auditoria e dados	Granularidade de acesso até o nível de coluna.	Observabilidade operacional não prevista originalmente.
PRTG	Links e equipamentos de rede de TI	Cobertura existente e consolidada.	Legado em migração.
Oracle Enterprise Manager	Bancos Oracle	Especialização no domínio Oracle, com algum monitoramento de negócio.	Escopo restrito e fragmentado.
Mecanismo próprio do API Gateway	Monitoramento do gateway	Dados específicos da plataforma de APIs.	Silo adicional, com nomenclatura não padronizada.

1.12.20. Riscos e lacunas identificadas¶


Ausência de observabilidade ponta a ponta na OT	O Datadog ainda não foi viabilizado no ambiente operacional e a cobertura se divide entre ferramentas.	Demora para localizar falhas entre domínios.	Alta	Definir arquitetura de coleta segura na OT e correlação com APM e telemetria.
Cobertura parcial da instrumentação	Três de nove unidades, com 85% apenas nas unidades já instrumentadas.	Pontos cegos e experiência operacional desigual entre empresas.	Alta	Roadmap de cobertura, critérios de criticidade e aceite de instrumentação.
Plataforma de logs com storage compartilhado	Rebalanceamento de discos e backups afetaram outros serviços.	Risco de indisponibilidade sistêmica além do próprio ambiente de logs.	Alta	Storage e recursos dedicados, planejamento de capacidade e arquitetura resiliente.
Excesso de logs sem governança	Um tópico com 151 aplicações e grande volume de informação desnecessária.	Custo, degradação e ausência de responsável identificável.	Alta	Contrato de logging, tópico por aplicação, quotas e rateio de custo.
Dados pessoais potencialmente indexáveis	Payload sensível pode atravessar Kafka, Logstash e Elasticsearch se o pipeline estiver configurado.	Incidente de conformidade e exposição de dados.	Alta	Mascaramento, detecção de segredos e bloqueio antes da indexação.
Criptografia em trânsito incompleta	Trecho do Kafka de telemetria citado como sem TLS, com tratativa em curso.	Interceptação e não conformidade.	Alta	Criptografia fim a fim, gestão de certificados e validação de configuração.
Monitoramento do Azure e do Databricks não previsto	O projeto não previu ferramenta e as demandas retornaram à arquitetura.	Pontos cegos em dados e em aplicações na nuvem.	Alta	Incluir observabilidade como requisito de arquitetura e aceite de projeto.
Retenção curta de logs	Quinze dias em produção, com reconhecimento de que é pouco para investigação.	Perda de evidência e baixa capacidade investigativa.	Média	Retenção por classe de log, arquivamento frio e redução de ruído.
Remediação predominantemente manual	A operação aciona as equipes e a automação se limita à limpeza de disco.	Tempo de recuperação elevado e risco operacional.	Média	Catálogo de roteiros executáveis e automação segura para cenários repetitivos.
Fragmentação de ferramentas	Entre seis e oito ferramentas, além dos registros nativos de cada plataforma.	Fadiga de alertas e ausência de visão única.	Média	Arquitetura de correlação, taxonomia e console operacional unificado.
Integração como caixa preta para o WFM	A equipe depende da infraestrutura para obter logs da integração com o DMS.	Resposta lenta e baixa autonomia em situações emergenciais.	Média	Observabilidade self-service com controle de acesso e coleta na DMZ.
Diretórios segregados sem relação de confiança	Diretórios separados entre ambientes, sem confiança implementada.	Complexidade de acesso e de integração das ferramentas.	Média	Workshop de identidade, federação e contas técnicas.

1.12.21. Consensos e pontos não decididos¶

1.12.21.1. Consensos observados¶

Zabbix, Datadog e ELK têm papéis distintos e devem coexistir no horizonte próximo.
A observabilidade de eventos no Kafka precisa ser aprofundada por instrumentação específica do Confluent, e não apenas pela instrumentação das aplicações.
O ambiente de logs precisa ser reestruturado, e o problema é arquitetural e de governança, não apenas de capacidade.
O volume e a qualidade dos logs enviados pelas aplicações precisam ser controlados na origem.
A centralização e a correlação devem, inicialmente, explorar as ferramentas já contratadas, antes de qualquer nova aquisição.
O monitoramento do Azure e do Databricks precisa voltar para a arquitetura e ser incorporado ao projeto.
A dor de visibilidade do WFM deve ser retomada em agenda específica.
A consultoria será incluída na recorrência de reuniões da reestruturação do ambiente de logs.

1.12.21.2. Pontos ainda não decididos ou não detalhados¶

Arquitetura-alvo do ambiente de logs: instalação própria, híbrida ou em nuvem.
Cronograma e orçamento da reestruturação.
Plataforma final para correlação e console unificado.
Escopo técnico exato da camada de correlação multifonte mencionada.
Cobertura e cronograma para as seis unidades ainda não instrumentadas.
Modelo de acesso e de autoatendimento para desenvolvimento e sustentação.
Política corporativa de retenção por classe de log.
Implementação efetiva de criptografia, mascaramento e prevenção de perda de dados em todos os fluxos de telemetria.
Integração da telemetria da AWS, do Azure, do Databricks e do Google à visão corporativa.
Viabilidade técnica e restrições de segurança para o Datadog no ambiente operacional.

1.12.22. Plano de ação recomendado¶


1	Formalizar inventário de ferramentas, ativos, fontes, responsáveis, cobertura e retenção	Arquitetura, operação e consultoria	Imediata	Mapa oficial do estado atual
2	Definir a arquitetura-alvo de observabilidade do ADMS ponta a ponta, incluindo OT, TI e nuvem	Arquitetura corporativa	Imediata	Desenho aprovado, com fronteiras claras
3	Concluir a homologação da instrumentação do Confluent Kafka	Time de Kafka e equipe de observabilidade	Alta	Produtor, consumidor, tópico, latência e atraso visíveis
4	Criar roadmap de instrumentação das nove unidades	DevOps, fábricas e sustentação	Alta	Cobertura mensurável e metas por unidade
5	Redesenhar o ambiente de logs com storage dedicado, dimensionamento, alta disponibilidade, backup e capacidade	Infraestrutura, Elastic e parceiro	Crítica	Plataforma estável e isolada dos demais ambientes
6	Implantar governança de logging e de telemetria por aplicação	Arquitetura, DevOps e segurança	Crítica	Redução de ruído, de custo e de risco
7	Implementar criptografia em trânsito e gestão de certificados no fluxo de telemetria	Segurança, Kafka e infraestrutura	Crítica	Criptografia verificável fim a fim
8	Implantar mascaramento e detecção de dados pessoais antes da indexação	Segurança, desenvolvimento e equipe de logs	Crítica	Prevenção de dados sensíveis em logs
9	Definir retenção por tipo de log e camada de arquivamento	Segurança, conformidade e operação	Alta	Equilíbrio entre capacidade de investigação e custo
10	Construir catálogo de roteiros executáveis e de auto-remediação	Monitoração e sustentação	Alta	Redução do tempo de recuperação
11	Retomar a coleta na DMZ e criar visão de autoatendimento para o WFM	Equipe de logs, WFM e segurança	Alta	Remoção da caixa preta operacional
12	Incluir Databricks e aplicações do Azure na arquitetura de monitoramento	Dados, nuvem e observabilidade	Alta	Métricas, logs e alertas integrados
13	Desenhar a camada de correlação multifonte e seus casos de uso	Squad de operação e infraestrutura com arquitetura	Média	Prova de conceito com critérios de sucesso e governança
14	Realizar workshop de identidade entre os diretórios	Identidade, arquitetura e segurança	Média	Modelo de confiança, federação e controle de acesso
15	Estabelecer painel de indicadores operacionais de observabilidade	Operação e gestão do ADMS	Alta	Indicadores de cobertura, detecção, recuperação, ruído e custo

1.12.23. Questões para as próximas sessões¶

1. Qual é a arquitetura lógica e física completa do ambiente de logs, incluindo versões, dimensionamento, storage, alta disponibilidade, backup, recuperação de desastre e volumes diários?

2. Qual é a data-alvo para concluir a instrumentação do Confluent Kafka e quais métricas e traces estarão disponíveis ao final?

3. Como o identificador de correlação é propagado hoje entre APIs, Kafka, microserviços, WFM e DMS, e qual é a relação com o identificador próprio gerado pela equipe do WFM?

4. Quais das nove unidades estão instrumentadas e quais aplicações compõem os 15% ainda não cobertos em cada uma?

5. Quais dados são considerados pessoais ou secretos e proibidos em logs, e onde existem controles automáticos de bloqueio?

6. O trecho de telemetria citado sem criptografia já foi corrigido? Quais conexões utilizam criptografia e como os certificados são geridos?

7. Qual política de retenção é exigida por auditoria, segurança, conformidade e investigação de incidentes?

8. Quem aprova novos tópicos, índices, pipelines e esquemas de telemetria?

9. Como serão integrados CloudWatch, X-Ray, recursos do Azure e do Databricks, Prometheus, Grafana e Zabbix ao console operacional?

10. Qual é o modelo de acesso de autoatendimento para desenvolvedores, sem expor dados sensíveis?

11. Quais incidentes recentes tiveram tempo de recuperação elevado por falta de correlação ou de logs disponíveis?

12. Quais casos de uso da camada de correlação têm prioridade: triagem de alertas, diagnóstico, consulta de procedimentos, correlação ou automação?

13. A adoção do Datadog no ambiente operacional é tecnicamente permitida? Quais restrições de segurança e de conectividade impedem sua implantação?

14. Como a reestruturação do ambiente de logs será testada e migrada sem perda de registros nem indisponibilidade?

15. Existe intenção de adotar um padrão aberto de instrumentação, dado que o OpenTelemetry não é utilizado hoje?

1.12.24. Conclusão do assessment desta sessão¶

A Energisa dispõe de componentes relevantes de observabilidade, mas ainda opera um mosaico de ferramentas e práticas construído em momentos diferentes. O desafio não é selecionar uma ferramenta universal, e sim estabelecer uma arquitetura coerente, com papéis definidos, correlação ponta a ponta, cobertura mensurável, segurança dos dados e governança operacional.

O Datadog oferece uma base madura de APM onde já está instrumentado, o Zabbix é essencial para a infraestrutura e para o ambiente operacional, e a plataforma de logs continua indispensável para a investigação detalhada. A evolução deve preservar essas competências e eliminar as lacunas de integração, propriedade, retenção, segurança e acesso.

Do ponto de vista do assessment das integrações, esta sessão tem um papel específico: ela explica por que várias das dificuldades levantadas nas sessões anteriores foram percebidas tarde ou de forma indireta. Falhas silenciosas de publicação, consumidores que param de consumir, eventos transformados de maneira incorreta e divergência de status entre sistemas são exatamente as classes de problema que dependem de linhagem de eventos e de correlação ponta a ponta para serem detectadas. A conclusão da instrumentação do Kafka e a definição de um mecanismo corporativo de correlação deixam de ser iniciativas de infraestrutura e passam a ser pré-condição para operar as integrações do ADMS com segurança.

Os temas mais urgentes são a reestruturação do ambiente de logs, a proteção de dados sensíveis, a conclusão da instrumentação do Kafka, a incorporação do Azure e do Databricks ao monitoramento, a ampliação da cobertura por unidade e a resolução da falta de visibilidade do WFM. Sem esses elementos, a observabilidade permanecerá reativa e fragmentada. Com eles, torna-se possível avançar para uma operação orientada por objetivos de nível de serviço, com correlação automática e remediação progressivamente automatizada.

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 ao longo do encontro, as falas são atribuídas por papel funcional. Saudações, problemas de áudio, repetições 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:04:03 Coordenação Energisa: Abre a reunião apresentando a consultoria e explicando que está em curso uma revisão das integrações que envolvem o ADMS de ponta a ponta, solicitada pelo próprio projeto em razão dos percalços da primeira implantação, parte deles já sanados, com método que parte de uma visão superior e desce ao detalhe.

00:04:51 Coordenação Energisa: Apresenta o especialista responsável pelo ambiente Elasticsearch, utilizado internamente para geração dos logs de aplicações, serviços e parte dos servidores.

00:05:48 Equipe Datadog: Relata que a frente entrou por projeto no ano anterior, quando foram feitas as primeiras instrumentações, e que o acompanhamento evolui à medida que as aplicações são instrumentadas.

00:06:03 Equipe Datadog: Registra que o objetivo de visão ponta a ponta esperado pelo projeto ainda não foi alcançado, porque depende de ações do time de desenvolvimento durante a implementação e da definição do que deve ser instrumentado. Informa que algumas aplicações e APIs já reportam logs e métricas.

00:06:51 Coordenação Energisa: Apresenta a equipe de monitoração, referida internamente como N0 ou NOC.

00:07:02 Equipe de monitoração: Explica que o ADMS nasceu em ambiente segregado de tecnologia operacional, com tudo criado separadamente, e que banco, servidores e serviços da aplicação estão no Zabbix, além do acompanhamento feito pela equipe de operação.

00:07:57 Consultoria: Registra que a reunião é oportuna como fechamento parcial, uma vez que dez áreas já foram percorridas e já existe uma boa visão do conjunto.

00:08:27 Consultoria: Busca confirmar a delimitação: o Zabbix serve ao monitoramento do ambiente e o Datadog à observabilidade das aplicações.

00:08:43 Equipe Datadog: Confirma a delimitação e detalha que o Datadog olha para as aplicações no lado da TI, enquanto o Zabbix alcança também o ambiente operacional, onde ficam banco e infraestrutura, por serem redes segregadas.

00:09:15 Equipe Datadog: Explica que o foco do Datadog são as integrações, incluindo as APIs e o que transborda do ADMS no ambiente operacional para os serviços corporativos.

00:09:32 Equipe Datadog: Registra que a intenção inicial era colocar o Datadog também no ambiente operacional, para obter visão ponta a ponta, mas que isso ainda não foi viabilizado porque depende de desenho de arquitetura.

00:09:58 Coordenação Energisa: Pergunta se o Zabbix está apenas na rede operacional ou também na corporativa.

00:10:06 Equipe de monitoração: Esclarece que são instâncias diferentes, uma para o ambiente operacional e outra para a TI, e que para o ADMS a cobertura abrange rede, bancos de dados e servidores.

00:10:23 Equipe de monitoração: Detalha a cobertura: switches core e switches associados aos servidores em rede; visualizador de eventos, processos e serviços Windows do DMS nos servidores; e jobs e camada de banco nos SQL Server.

00:11:03 Consultoria: Confirma o entendimento de que a ferramenta gera eventos, apresenta em interface gráfica e produz alertas para a equipe de operação.

00:11:20 Consultoria: Pergunta se existe resolução automática de problemas, citando o exemplo de reiniciar automaticamente uma aplicação que apresentou falha.

00:11:51 Equipe de monitoração: Responde que a maioria é manual e que pouca coisa se auto-remedia. Informa que os alertas estão integrados à ferramenta de gestão de serviços, o que permite atuação rápida.

00:12:01 Equipe de monitoração: Registra que estão começando trabalhos de auto-remediação para limpeza de disco, removendo logs temporários quando determinadas pastas atingem o limite, mas que a iniciativa está no início. Por enquanto o alerta chega ao console, e a operação aciona a equipe responsável.

00:12:44 Consultoria: Passa ao Datadog e busca confirmar a capacidade de identificar quem chamou uma API, o tempo de resposta e a cadeia de chamadas entre APIs.

00:13:05 Equipe Datadog: Confirma que, dentro do que está instrumentado, é possível obter a correlação de logs e traces, com medição de latência e de consumo de recursos, abrangendo o que está em Kubernetes.

00:13:23 Equipe Datadog: Explica que a aplicação instrumentada já entrega métricas que geram alertas, incluindo erros de servidor que acionam sala de guerra e alertas de negócio definidos com as áreas, que disparam intervenção da sustentação.

00:13:48 Consultoria: Pergunta qual é o percentual de cobertura das APIs instrumentadas.

00:14:07 Equipe Datadog: Responde que a cobertura é feita por unidade: de nove unidades, três estão contempladas, e nessas três cerca de 85% das APIs estão instrumentadas.

00:14:29 Consultoria: Pergunta de quem é a responsabilidade pela instrumentação.

00:14:34 Equipe Datadog: Explica que é feita no ato do desenvolvimento: quando o time coloca a aplicação em operação, faz o cadastro no DevOps e inclui no manifesto, e a esteira já possui a instrumentação pronta, bastando poucas linhas de configuração para a plataforma começar a ingerir as métricas.

00:15:03 Consultoria: Pergunta qual é a linguagem predominante das aplicações.

00:15:06 Equipe Datadog: Informa que a maioria é .NET.

00:15:14 Equipe de monitoração: Registra a exceção do motor de cálculo de indicadores, escrito em Java, que é uma integração dentro do ADMS.

00:15:31 Consultoria: Pergunta como a plataforma trata a correlação para eventos.

00:15:38 Equipe Datadog: Informa que a correlação é automática e que a instrumentação traz eventos, erros, implantações e dependências das requisições.

00:15:53 Consultoria: Reformula a pergunta com um cenário concreto: uma API gera um evento, o evento vai para um tópico e outro serviço o consome. Questiona se é possível obter a linhagem do dado e da transformação desse evento.

00:16:32 Equipe Datadog: Responde que ainda não há essa profundidade e que não é possível informar o conteúdo do payload, porque a instrumentação do Confluent está sendo implantada agora pelo time de Kafka, com a funcionalidade de data streaming.

00:17:05 Consultoria: Confirma o entendimento de que, concluída a instrumentação, estarão cobertos eventos, tópico e produtor.

00:17:10 Equipe Datadog: Complementa que o consumidor também será coberto e que será possível avaliar a latência e a profundidade da fila consumida naquele momento.

00:17:29 Equipe de monitoração: Registra que a iniciativa nasceu de forma secundária ao ADMS, motivada pelo porte do Kafka e pela quantidade de informação que trafega no ambiente.

00:17:45 Equipe Datadog: Explica que a equipe optou por validar primeiro a integração e só depois colocá-la em produção, e informa que os responsáveis estão avançando bem na instrumentação.

00:18:06 Consultoria: Pergunta se a instrumentação está restrita ao Kafka ou se envolve ação de desenvolvimento.

00:18:17 Equipe Datadog: Esclarece que não envolve desenvolvimento: com a aplicação já monitorada, a plataforma identifica que a requisição envolve um tópico e mostra a latência, mas sem detalhes. A instrumentação no próprio Kafka é o que traz a granularidade necessária para tornar a correlação de eventos mais específica.

00:20:04 Consultoria: Aprofunda o ponto central: se um segundo componente consome o evento, aplica uma regra de negócio equivocada e produz um evento inconsistente, é preciso haver linhagem para identificar onde ocorreu a quebra e qual componente transformou a informação, porque o próximo consumidor é quem sofrerá o problema.

00:20:44 Equipe Datadog: Responde que o data streaming permitirá acompanhar o caminho da mensagem: identificar a origem do evento, ver as trilhas que ele percorre, os intermediários que fazem a distribuição e o endpoint de destino da requisição.

00:21:19 Equipe Datadog: Explica que a correlação é habilitada por um recurso ativado na instrumentação, que acompanha a requisição desde a origem e registra os saltos, gerando um trecho de rastreamento a cada ponto em que a aplicação registra log, de modo que o trace pode ser percorrido do disparo até o consumo final.

00:22:29 Equipe Datadog: Ressalva que a plataforma não detalha o conteúdo interno, mas traz a transação por inferência, chegando hoje até o nome do produtor.

00:22:39 Coordenação Energisa: Registra que a equipe de desenvolvimento do WFM gera um identificador de correlação próprio e o utiliza para conseguir obter o rastro hoje, e sugere chamar o desenvolvedor sênior para demonstrar o funcionamento.

00:23:14 Coordenação Energisa: Observa que desconhecia esse nível de capacidade da plataforma de APM e o mecanismo de correlação apresentado.

00:23:26 Consultoria: Compara com o ambiente Elasticsearch, no qual a correlação de chamadas também existe, mas, para eventos, normalmente é necessário adicionar explicitamente um campo de identificador de correlação que a plataforma utiliza para associar os registros.

00:24:02 Consultoria: Pergunta se o ambiente Elasticsearch também é utilizado para observabilidade, uma vez que havia entendido tratar-se apenas do adaptador.

00:24:07 Coordenação Energisa: Informa que todas as aplicações e serviços começaram no ambiente Elasticsearch e que o Datadog está chegando agora.

00:24:29 Equipe Datadog: Detalha que o consumo de telemetria está todo no ambiente Elasticsearch, onde os logs são registrados, enquanto o Datadog atua na camada de aplicação.

00:24:52 Equipe Datadog: Explica que, em homologação e em salas de crise, as equipes olham os dois lados, e avalia que a plataforma de logs não sairá do circuito, pela quantidade de informação trafegada, por retenção e por licenciamento.

00:25:21 Consultoria: Consolida a distinção: uma plataforma cumpre a função de telemetria e a outra a função de APM.

00:25:40 Consultoria: Observa que, na telemetria, o correlacionamento explícito é necessário para obter o trace, enquanto no APM a correlação é obtida automaticamente a partir da instrumentação.

00:26:25 Consultoria: Pergunta se a plataforma de logs é instalada e gerida internamente.

00:26:33 Equipe ELK: Confirma que é ambiente próprio e detalha a composição: cinco nós Elasticsearch, um Kafka utilizado pelo fluxo de logs, o Logstash e o servidor Kibana.

00:26:55 Consultoria: Pergunta se esses componentes estão no OpenShift.

00:27:00 Equipe ELK: Responde que estão em servidores, e confirma tratar-se de servidores virtuais fora do cluster.

00:28:01 Coordenação Energisa: Explica que a plataforma de logs nasceu antes do OpenShift e que, por isso, existem soluções fora do cluster, sem que a transferência tenha sido sequer cogitada até o momento.

00:28:21 Equipe ELK: Informa que existe uma frente em curso de reestruturação da plataforma de logs, descrita como jogar no chão e construir do zero, conduzida com o time de infraestrutura, a Elastic e o parceiro oficial do fabricante, para aplicar as melhores práticas e desafogar a infraestrutura.

00:28:52 Equipe ELK: Registra que está sendo avaliada a possibilidade de um modelo híbrido ou em nuvem, conforme o custo, e convida a consultoria a participar dessa discussão.

00:29:37 Consultoria: Pergunta qual é o motivo da reconstrução, se custo ou desempenho.

00:29:49 Equipe ELK: Responde que a infraestrutura sofre com o consumo elevado de recursos da plataforma de logs e que isso decorre da própria concepção do ambiente.

00:30:08 Equipe ELK: Explica que a plataforma envolve praticamente toda a infraestrutura e que a intenção é separá-la dos demais, com máquinas mais robustas.

00:30:33 Equipe ELK: Informa que o backup da plataforma de logs foi suspenso por determinação da área responsável, porque estava afetando os demais ambientes.

00:30:52 Coordenação Energisa: Recorda que a questão central era o storage compartilhado.

00:30:58 Coordenação Energisa: Qualifica o compartilhamento de storage como o calcanhar de Aquiles do ambiente e relata que, em determinado momento, a adição de novos discos gerou problemas no rebalanceamento que afetaram não apenas a plataforma de logs, mas também os demais serviços que utilizavam o mesmo armazenamento.

00:31:24 Equipe ELK: Registra que foi essa sequência de eventos que originou a conversa sobre a reestruturação.

00:32:04 Coordenação Energisa: Propõe incluir a consultoria na recorrência de reuniões dessa frente.

00:32:29 Consultoria: Pergunta qual é o tempo de retenção dos logs em cada plataforma.

00:32:42 Equipe ELK: Informa que a retenção de produção é de 15 dias.

00:32:49 Equipe Datadog: Informa que, no Datadog, após a transformação em métrica, a retenção é de 15 meses, e confirma que a plataforma é um serviço em nuvem.

00:33:10 Equipe ELK: Registra a tensão: 15 dias é pouco para investigação, mas o envio de informação desnecessária é muito grande, de modo que boa parte do que é retido não tem valor.

00:33:40 Equipe ELK: Relata que está alinhando com a coordenação um prazo para as torres de desenvolvimento e contextualiza que herdou a plataforma já nessa condição.

00:34:10 Equipe ELK: Apresenta o caso concreto: um tópico de telemetria denominado API atendimento recebe registros de 151 aplicações, o que faz a equipe perder a gestão. Se um novo microserviço passa a publicar no mesmo tópico, não há como conhecer a volumetria, e o resultado recorrente é problema de espaço.

00:34:45 Equipe ELK: Informa que existe uma frente para impedir o envio de mais de uma aplicação por tópico, permitindo gestão individualizada, e um trabalho de conscientização sobre o que deve ser enviado e retido, ilustrado pelo envio repetido de mensagens informando que o sistema está normal.

00:35:20 Equipe de monitoração: Reforça que a reestruturação da plataforma de logs não é uma frente apenas de hardware.

00:35:35 Consultoria: Confirma o fluxo: as aplicações enviam para tópicos de um Kafka, e um agente consome e grava na plataforma de logs.

00:35:58 Equipe de monitoração: Detalha que existe um conector construído pela equipe de arquitetura, cuja administração pertence à equipe de arquitetura de integração, que consome o tópico do Kafka e entrega ao Logstash, onde estão os pipelines que transformam o conteúdo nos registros consultados no Kibana.

00:36:35 Consultoria: Pergunta se esse Kafka é o mesmo do barramento corporativo, hospedado no OpenShift.

00:36:40 Equipe de monitoração: Responde que o Kafka da telemetria é distinto e dedicado a essa finalidade.

00:36:48 Coordenação Energisa: Explica que a solução foi criada anteriormente e já nasceu com Kafka próprio.

00:37:07 Consultoria: Avalia positivamente a separação, uma vez que o compartilhamento sobrecarregaria ainda mais o barramento corporativo.

00:37:20 Coordenação Energisa: Registra que o escritório de segurança apontou que esse fluxo não utiliza criptografia em trânsito e que a inclusão de TLS está sendo tratada.

00:37:42 Consultoria: Levanta o risco de trânsito de dados pessoais nesse mesmo fluxo, uma vez que as aplicações enviam o que recebem para o tópico.

00:38:16 Coordenação Energisa: Explica que os dados indexados vêm da estrutura enviada pelas aplicações e que é possível inserir conteúdo em estrutura aberta, sem definição prévia, passando pelo Kafka.

00:38:35 Equipe Datadog: Pergunta se a referência é ao padrão aberto de instrumentação.

00:38:43 Coordenação Energisa: Informa que o OpenTelemetry não é utilizado hoje e que as aplicações enviam uma estrutura definida especificamente para cada uma, em JSON, com um bloco de informações próprias combinado a uma estrutura genérica interna, tudo no mesmo payload.

00:39:31 Consultoria: Formula a questão de forma direta: se a aplicação colocar no registro o número do cartão de crédito de um cliente, existe algo que barre esse conteúdo ou ele será gravado no tópico e indexado?

00:40:03 Equipe de monitoração: Responde que, se o pipeline estiver configurado, o dado chegará.

00:40:12 Equipe de monitoração: Complementa que existem também consultas específicas de banco de dados que alimentam a plataforma de logs diretamente, sem passar pelo Kafka, em volume pequeno.

00:40:48 Coordenação Energisa: Conclui que provavelmente não existe mascaramento implementado hoje nesse caminho.

00:40:58 Equipe Datadog: Contrasta com o comportamento do Datadog, no qual dados como CPF, telefone e cartão de crédito são anonimizados e não ficam visíveis, com uma camada de prevenção de perda de dados atuando sobre o conteúdo.

00:41:27 Equipe Datadog: Exemplifica com um módulo de visualização que simula o atendimento ao cliente, no qual CPF e número de celular aparecem anonimizados na tela, de forma transparente para a aplicação e para a plataforma.

00:42:01 Consultoria: Observa que, mantida a plataforma de logs, seria necessário adotar solução equivalente de prevenção de perda de dados para evitar que esse tipo de conteúdo seja indexado.

00:42:41 Consultoria: Consolida o entendimento do cenário: nove empresas, três já contempladas, cerca de 85% dos serviços instrumentados nessas três, com o Datadog cobrindo aplicações e a plataforma de infraestrutura cobrindo servidores, bancos e recursos de rede.

00:43:49 Consultoria: Sintetiza as dores da plataforma de logs: estrutura apartada e anterior às demais soluções, ausência de visibilidade sobre quem consome, retenção de apenas 15 dias, ausência de prevenção de perda de dados e de controle sobre quem envia o quê, entrada de conteúdo sem valor, custo elevado e necessidade de refatoração.

00:44:36 Coordenação Energisa: Confirma que o cenário foi compreendido corretamente.

00:44:42 Consultoria: Pergunta se existem outras ferramentas de monitoramento.

00:45:03 Equipe de monitoração: Relaciona as demais ferramentas: Oracle Enterprise Manager, que acaba fazendo monitoração dos bancos Oracle, e PRTG para links e equipamentos de rede da TI, com migração em curso.

00:45:24 Equipe de monitoração: Registra que o Datadog está concentrado no que é crítico e que existe um grande número de APIs e endpoints não críticos acompanhados por outro mecanismo, que também é utilizado como ferramenta de monitoração e chega a executar regras de negócio.

00:46:01 Coordenação Energisa: Acrescenta que, dentro do OpenShift, existem Grafana e Prometheus, e que as métricas do próprio Confluent Kafka são geradas e consultadas por essa via, além do mecanismo próprio de registros do API Gateway.

00:46:30 Consultoria: Pergunta se existe projeto ou intenção de centralizar esses monitoramentos hoje descentralizados.

00:46:51 Equipe de monitoração: Responde que não existe projeto formal, apenas conversas entre as áreas para diminuir o número de ferramentas, hoje entre seis e oito. A tentativa atual é centralizar a infraestrutura no Zabbix, as aplicações no Datadog e a telemetria na plataforma de logs, com caminho ainda a percorrer.

00:47:31 Equipe Datadog: Complementa que a ideia é colocar os alertas em um único lugar e trazer as informações enriquecidas, com a configuração de uma camada de correlação sobre diversas fontes de monitoramento.

00:47:43 Equipe de monitoração: Informa que uma squad interna está trabalhando nessa direção e que provavelmente centralizará no próprio ambiente de logs ou utilizará outra ferramenta para receber os dados de todas as fontes, correlacioná-los e geri-los em um único lugar.

00:48:23 Consultoria: Pergunta o significado da sigla utilizada para nomear a equipe.

00:48:25 Equipe de monitoração: Esclarece que é a sigla de uma equipe interna que cuida da operação e da infraestrutura, à qual pertencem os participantes da sessão, e que dentro dessa estrutura existe um time dedicado às iniciativas de centralização.

00:49:31 Consultoria: Pergunta se está prevista a aquisição de algum produto de centralização.

00:49:47 Equipe Datadog: Responde que não sabe precisar como será, mas que as duas plataformas existentes permitem construir a camada de correlação, de modo que a aquisição de nova ferramenta neste momento não parece necessária.

00:50:33 Consultoria: Pergunta sobre a existência de soluções em nuvem e sobre transbordo do ambiente próprio.

00:50:47 Equipe Datadog: Responde que o ambiente é híbrido, com parte interna e parte em nuvem, e avalia que está próximo de uma distribuição multicloud.

00:51:07 Consultoria: Confirma que a área de dados está no Azure com Databricks e pergunta o que existe na AWS.

00:52:00 Coordenação Energisa: Informa que na AWS são utilizados CloudWatch e X-Ray para observabilidade dos componentes ali executados.

00:52:23 Coordenação Energisa: Explica que parte da solução de força de trabalho está migrando para essa nuvem, com integração à mobilidade, em fase de implantação e desenvolvimento.

00:52:50 Coordenação Energisa: Detalha que a solução faz a integração entre a mobilidade e os dados que permanecem no ambiente interno, substituindo o modelo antigo em que o dispositivo acionava diretamente o sistema interno, com adoção de um padrão orientado a eventos, sincronização com a mobilidade e armazenamento de objetos para as fotos tiradas em campo.

00:53:39 Consultoria: Pergunta se existe intenção de centralizar também a telemetria dessas soluções em nuvem.

00:53:51 Coordenação Energisa: Responde que seria o mais indicado e relata que houve conversas anteriores sobre o tema com a coordenação responsável.

00:54:20 Coordenação Energisa: Recorda uma iniciativa anterior à entrada do Datadog, na qual foi construída uma API capaz de disparar os logs e integrá-los à plataforma interna de forma centralizada, que aparentemente não chegou a ser utilizada em produção.

00:55:09 Coordenação Energisa: Cita a identidade Microsoft, com uso do Entra ID, e observa que há componentes internos e em nuvem, sugerindo também conversa com a equipe de DevOps.

00:56:08 Coordenação Energisa: Informa que a rede corporativa e o ambiente operacional possuem diretórios separados.

00:56:14 Consultoria: Pergunta se existe relação de confiança entre os diretórios.

00:56:17 Equipe de monitoração: Responde que ainda não existe essa relação de confiança.

00:56:25 Coordenação Energisa: Sugere conversa específica com a equipe de identidade.

00:56:40 Consultoria: Pergunta quais aplicações executam no ambiente de nuvem de dados.

00:56:46 Coordenação Energisa: Informa que existem aplicações associadas ao data lake, incluindo o envio de dados ao órgão regulador, com serviços e APIs próprios.

00:57:26 Coordenação Energisa: Explica que o monitoramento nesse ambiente vem do próprio Azure e do Databricks, com liberação e monitoração granulares, capazes de identificar quem acessou, quando acessou e até qual coluna foi consultada.

00:57:49 Consultoria: Delimita que isso constitui trilha de auditoria e observa que, idealmente, essas informações estariam consolidadas em algum lugar.

00:58:23 Coordenação Energisa: Registra desconhecer como está a telemetria desse ambiente e avalia que provavelmente não está integrada às demais.

00:59:12 Equipe de monitoração: Confirma que se trata de um problema relevante e que nada chegou ainda ao ambiente de monitoração corporativo.

00:59:24 Equipe Datadog: Informa que a frente está em construção e que foi necessário retroceder, porque o monitoramento não havia sido previsto por nenhuma ferramenta pelo time de projeto. As demandas estão retornando à arquitetura para prever o monitoramento do Databricks e das aplicações no Azure, que seriam acompanhadas por metodologia sem servidor, e foi solicitada autorização do time de segurança para criar a aplicação de integração necessária à coleta das métricas.

01:00:11 Equipe Datadog: Informa que a decisão foi tomada na semana anterior, junto com o time de dados, e identifica os responsáveis pela frente.

01:00:47 Coordenação Energisa: Propõe agendar reunião específica com a equipe de dados.

01:01:03 Consultoria: Pergunta se existe uso do Google Cloud.

01:01:14 Coordenação Energisa: Responde que o uso é de APIs do Google, sobretudo de mapas, empregadas pela mobilidade e pelo WFM para conversão de endereço em coordenada e para geolocalização.

01:01:44 Coordenação Energisa: Acrescenta um serviço recente de otimização e roteirização, relacionado a uma evolução futura do projeto, a ideia de despacho automático.

01:03:16 Coordenação Energisa: Retoma a dor de observabilidade da integração do WFM com o DMS, que havia sido relatada pela equipe de desenvolvimento e que ficou no escopo da monitoração de infraestrutura.

01:03:52 Equipe Datadog: Recorda a iniciativa de colocar um agente da plataforma de logs na DMZ, para trazer os registros dessa integração, tema que perdeu acompanhamento durante a mudança de responsáveis.

01:04:30 Equipe Datadog: Avalia que a implementação não é tecnicamente complicada, mas depende do andamento da frente conduzida pela equipe responsável pela plataforma de logs.

01:04:36 Equipe de monitoração: Propõe agenda específica para retomar o tema.

01:04:41 Coordenação Energisa: Contextualiza a origem da demanda: na sessão com a equipe do WFM, foi relatado que o processo envia informação ao DMS sem que a equipe tenha visibilidade, tornando o fluxo uma caixa preta. Quando precisa de informação, a equipe solicita apoio da infraestrutura para buscar os logs, porque não tem acesso, e muitas dessas situações são emergenciais.

01:05:25 Coordenação Energisa: Registra que a equipe participa da sustentação enquanto o sistema está em operação assistida e que essa foi uma de duas dores relatadas.

01:05:40 Coordenação Energisa: Encerra a sessão e confirma o agendamento das conversas complementares.

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

A transcrição automática contém termos foneticamente imprecisos, inclusive para os nomes das próprias plataformas. Nesta ata, as ferramentas foram descritas por sua função e por sua denominação mais provável. Os itens abaixo devem ser confirmados antes de constarem em desenho de arquitetura ou em decisão formal.


ELK, LK e variações	Ecossistema Elasticsearch, Logstash e Kibana utilizado para logs e telemetria.	A transcrição alterna diversas grafias para a mesma plataforma.
N0 e NOC	Equipe de monitoração e operação que recebe alertas e aciona os times de sustentação.	Alguns trechos registram a sigla de forma incorreta.
Recurso de correlação do Datadog	Configuração habilitada na instrumentação que correlaciona automaticamente os registros.	O nome exato do recurso deve ser confirmado na documentação e no console.
Data streaming	Módulo de observabilidade de streaming de eventos, em homologação sobre o Confluent.	Denominação comercial exata a confirmar.
Sigla da equipe interna	Equipe de operação e infraestrutura à qual pertencem os participantes.	A grafia oficial da sigla deve ser confirmada.
Camada de correlação multifonte	Mecanismo de consulta e correlação sobre múltiplas fontes de monitoramento, referido como MCP.	Escopo, protocolo, segurança e governança não foram detalhados.
Mecanismo de acompanhamento das APIs não críticas	Ferramenta utilizada para as APIs e endpoints fora do escopo crítico do Datadog.	Nome capturado de forma imprecisa, a confirmar.
Iniciativas citadas na nuvem	Projetos de instrumentação e de integração no Azure e na AWS.	Nomes de iniciativas e de sistemas com baixa confiança de reconhecimento.
Serviço de otimização e roteirização	Serviço recente do Google Cloud relacionado ao despacho automático.	Produto e fornecedor a confirmar.
Parceiros das provas de conceito	Empresas citadas como envolvidas nas iniciativas de correlação e na reestruturação da plataforma de logs.	Nomes oficiais a confirmar.
Motor de cálculo de indicadores	Componente em Java citado como exceção à predominância de .NET.	Corresponde ao componente tratado na Ata 08.

Além dos termos, os seguintes dados quantitativos e afirmações foram registrados como informados e devem ser confirmados por inventário:

A cobertura de três das nove unidades e o percentual de 85% das APIs instrumentadas nessas três.
A composição de cinco nós Elasticsearch e a topologia completa do ambiente de logs.
O número de 151 aplicações publicando no tópico de telemetria citado.
As retenções de 15 dias para logs de produção e de 15 meses para métricas.
O total de seis a oito ferramentas de monitoramento em uso.
A situação atual da criptografia em trânsito no fluxo de telemetria.
A responsabilidade formal pela administração do conector que integra o Kafka de telemetria ao Logstash.

1.12.25. 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 integralmente o conteúdo das duas fontes, incluindo os pontos em que a transcrição traz detalhe adicional, como o histórico da suspensão do backup da plataforma de logs, a natureza dedicada do Kafka de telemetria, o formato dos registros enviados pelas aplicações e a iniciativa anterior de integrar os logs da nuvem ao ambiente interno.

A atribuição nominal das falas não foi aplicada no registro cronológico porque a associação automática entre rótulos e pessoas não se manteve estável ao longo da gravação. Os participantes estão identificados no item 1.12.2, com base nas apresentações feitas na abertura da sessão. 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 o inventário de ferramentas e ativos e com as sessões complementares acordadas.