Fase I - Estudo

Título da Ideia

Migração da Automação - Monitoramento POP/Localidade

Objetivos

O projeto tem como objetivo auxiliar a área de Alarmística do COR - Centro de Operação de Redes da Algar Telecom no processo de migração da automação do monitoramento de estação (POP) e localidade. Em termos mais detalhados, por conta de uma sobrecarga no Zabbix - ferramenta de software usada para monitorar redes e servidores -, há importância em implementar e refinar a automação em questão no Netcool. Tal importância se dá por conta de muitos alarmes acionarem quando há uma queda ou isolamento, dessa forma, com o monitoramento os alarmes são agrupados e é gerado um alarme sintético que identifica o problema. Com disso, além da diminuição da sobrecarga, o refinamento da automação poderá gerar mais reduções de esforço e de tempo de análise por parte dos analistas durante a investigação das falhas, bem como o tempo de tratamento.

Conceito

Contexto inserido

Este projeto está inserido no contexto de automação do COR - Centro de Operação de Redes da Algar Telecom, mais especificamente na área de alarmes da rede GPON.

Projetos e pesquisas relacionados

Anteriormente a este, houve uma pesquisa da própria área de P&D do Brain:

Alarmística COR

Possibilidades de evolução

Feita a migração dessa automação, deve ser avaliada a sobrecarga inicialmente apontada pelo COR. Em caso da necessidade de uma maior redução, possivelmente a migração e criação de outras automações poderão ser analisadas. Além disso, de maneira prospectiva, pode haver viabilidade de implementações que tragam novos mecanismos que aprimorem o monitoramento de estação e localidade.

Características

Neste projeto, estarão presentes alguns assuntos, ferramentas e mecanismos, principalmente:

Topologias de rede
NodeRed
Netcool

Netcool impact

JavaScript

Requisitos funcionais (RF) e não funcionais (RNF)

RF: Por se tratar de uma automação, os requisitos funcionais envolverão tudo aquilo que é responsabilidade do sistema fazer para que a automação funcione.
- Obter alarmes de POP e Localidade.
- Descobrir POPs e localidades caídas.
- Diagnosticar a queda (caracterizar, enriquecer, se trata uma queda total ou parcial).
- Criar o alarme sintético no banco.
- Disponibilizar os diagnósticos para os analistas.
RNF: Os requisitos não funcionais são um pouco mais abstratos de serem identificados, visto que a aplicação é construída dentro do ambiente na rede Algar. Sendo assim, alguns fatores, como de segurança e disponibilidade já são providos.
- Tempo de resposta e velocidade (?)
- Volume de alarmes (?)
- Usabilidade: a utilização da aplicação em si é automática, o que fator neste tópico é referente à visualização das mensagens que vão para a tela dos analistas.
  - Estrutura intermediária (atualizações nas tabelas para disponibilizar o diagnóstico nos telões)
- Para possibilitar o desenvolvimento, são necessários os acessos Algar, bem como acesso à VPN.
- NodeRed, Netcool Impact, JavaScript, SQL

Atribuições

Neste projeto, cabe ao Brain:

Auxiliar no desenvolvimento e revisão, além de aprimorar:
- Os fluxos no NodeRed
- As políticas e os serviços no Impact

Estudo Dirigido

Inicialmente, além de acompanhar o Caio com proximidade, foi importante assistir alguns vídeos para obter familiaridade com o NodeRed [1]
Analisar os fluxos dessa automação no NodeRed, que já estavam sendo desenvolvidos pelo COR [2]
Documentação do NodeRed [3]
Canal do YouTube do NodeRed [4]

Fase II - Ensino

Conteúdo

Desenvolva um conteúdo que possa transmitir o conhecimento adquirido para outros
Crie um material (Wiki, PDF, PPT, ...) que possa ser armazenado e facilmente atualizável

Apresentação

Apresente ao grupo (reunião, EAD, Blog, ...)
Publique aqui

Metodologia

Descrevas as metodologias usadas. Alguns exemplos:

Estratégia de Job Rotation
Estudos básicos para conhecimento do potencial
Estudos básicos para entendimento sobre o problema
Estudos para dar base aos pesquisadores
Benchmarking com empresas estrangeiras 
Aceleradoras de empresas
Adoção de novas tecnologias
Utilização da proposta de soluções Open-source
Priorização no desenvolvimento interno
Foco na não dependência de fornecedores
Prática de formação dos talentos necessários

Hipóteses

 Que questões envolvem a pesquisa? 
O que se espera provar?
O que se espera como resultado?
Explicações e argumentos que subsidiem a investigação em curso

Fase III - Exemplo de Caso de Negócio

Product Backlog

Descreva os requisitos deste projeto

Benefícios para quem for oferecer esta solução

    Descrever em tópicos os benefícios que uma pessoa ou uma empresa podem obter: ganhos, receitas, novos negócios, novos produtos, novas parcerias

Benefícios para o usuário

    Descrever em tópicos os benefícios para os usuários desta solução.
    Pode se inspirar no Canvas.

Direcionadores chave para esta iniciativa

    Descrever em tópicos o que esta iniciativa pode proporcionar

Possíveis modelos de negócios

    Descrever em tópicos os possíveis modelos de negócios

Business Case

    Descrever um exemplo de negócio que permita avaliar a solução comercialmente

Alinhamento com Lei do Bem

Projeto possui algum elemento tecnologicamente novo ou inovador?

Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada

Projeto possui barreira ou desafio tecnológico superável?

Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese

Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?

Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto

Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?

Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa? 
Anexar cópia do contrato

Fase IV - Protótipo orientado ao Negócio

Escopo

Explique o escopo deste protótipo

Limitações

Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.

PoC

Desenvolva um PoC (Proof of Concept)

Privacidade (LGPD)

Avaliar condições referentes à Lei Geral de Proteção de Dados

Detalhamento Técnico

Descreva especificamente os aspectos técnicos desta pesquisa

Cronograma Macro

Histórico

21/03/2024:
- Kick off: Caio Cesar Oliveira Rabelo:
  - 1. Escopo: alarmes de toda a rede (IP, exemplo, acesso, agregação e backbone). Alarmes de indisponibilidade nos 3 subdomínios. Em alguns casos, o site inteiro está fora do ar (energia, temporal) gera um monte de alarme de indisponibilidade. Foi feito um monitoramento de POPs para agregar todos os alarmes num só. A ideia é agregar todos os alarmes de site de uma localidade. Objetivo: tratar rápido a falha. Foi feito uma 1a implementação no Zabbix com baixa performance. A ideia é migrar para o Netcool criando um alarme sintético. Fazer pra site e localidade.
  - 2. Responsável: Caio Cesar e Elton
  - 3. Frequência dos encontros: Weekly 5a tarde
  - 4. Ferramentas: Netcool, Netcool Impact, NodeRed, Javascript e IPL => Material a ser enviado pelo COR
  - 5. Entrega final: Temos reuniões planejadas para apresentação do status do projeto em VMOs, Conselhos e momentos específicos.

22/03/2024
- Reunião com olhar técnico (bastante introdutório, porém específico sobre o projeto de monitoramento) com Caio e Elton.
  - Ênfase principalmente sobre as plataformas/ferramentas (NodeRed, Netcool/Impact, Inventário Digital) que acessam bancos de dados que já estão estruturados.
  - Impact => Políticas e Serviços -> Serviços acionam políticas.
- Relacionado diretamente ao projeto, inicialmente, para monitoramento de POPs, os alarmes de ICMP são identificados. Em seguida, é feito o enriquecimento, que é acompanhado por status (enrichpop, enriched, status de alarme sintético). Por fim, é possível obter um diagnóstico (ou não) com base nos dados analisados.
25/03/2024
- Acompanhando remotamente o Caio, Elton e equipe a solucionar problemas reais em alarmes de estação.
- Encontrar amanhã no CA.
26/03/2024
- Encontro de manhã e de tarde no CA. Desenvolvemos em cima do código no Impact e NodeRed.
  - A estrutura geral está pronta e o fluxo no NodeRed montado, entretanto há bugs a serem solucionados e melhorias a serem feitas nos códigos das políticas (Impact) e em algumas buscas SQL (NodeRed).
  - Serviços já foram criados tanto para POPs quanto Localidades.
28/03/2024
- Ainda não tendo a VPN na máquina, a continuidade do estudo está sendo dada pela análise do fluxo estruturado no NodeRed.
08/04/2024
- Atualização sobre impedimento: sigo sem a VPN, então sigo estudando alguns tópicos e fluxos, entretanto o desenvolvimento (codificações) segue por parte do COR.
15/04/2024
- Obtenção da VPN. Entretanto, sem os acessos Algar (IP Fixo e Firewall) necessários para acessar o ambiente de desenvolvimento do Nodered do COR.
07/05/2024
- Obtenção dos acessos: IP Fixo e Firewall. Até o momento sem outros impedimentos, o desenvolvimento agora também pode ser feito por parte do Brain.
15/05/2024
- Reunião para dar direcionamento ao início das atividades no NodeRed por parte do Brain.
  - Transferir o fluxo do ambiente produtivo para o amb. de homologação, realizando as devidas trocas de apontamentos.
  - Aprimoramentos no fluxo inicialmente desenvolvido pelo COR.
- Impedimento encontrado: o ambiente de homologação precisará ser criado novamente (COR).
17/05/2024
- Ambiente de homologação criado, o acesso deu certo, mas o NodeRed deu problema com os botões dos injects e dos debugs, o que impede a transferência e teste do fluxo produtivo dentro do amb. de homologação.
28/05/2024
- Reunião de alinhamento com os especialistas do COR, na qual foi concluído que é mais viável a realocação dos pesquisadores a outra contribuição.
29/05/2024
- Primeira reunião sobre a realocação, presencialmente no CA com Luigi, Luiz, Caio, Gessyca e Helen.
  - Direcionamento para contribuição envolvendo IA nos processos de análise de identificação do trecho afetado e agrupamento dos alarmes.
03/06/2024
- Reunião com Gessyca: Avaliação dos recursos necessários para executar o código criado
- LN: Definir se já consegue colaborar no desenvolvimento da solução ou se precisa de alguma formação
06/06/2024
- Luigi conseguiu rodar os códigos em sua máquina do Brain
07/06/2024
- Reunião presencial Gessyca e Luigi para dar continuidade ao trabalho, entretanto foram identificados erros de padronização de entrada
10/06/2024
- Com uma base de dados um pouco maior, a máquina do Brain apresentou problema
- numpy.core._exceptions._ArrayMemoryError: Unable to allocate 191. MiB for an array with shape (24982125,) and data type float64
17/06/2024
- Outras máquinas foram testadas, entretanto o problema realmente se dá na disponibilidade de memória RAM
- Algumas possibilidades estão sendo avaliadas: spark, memory mapping e fracionamento do arquivo
20/06/2024
- Alguns testes com spark foram realizados, mas sem muito sucesso, apenas obtivemos melhor desempenho do código. Rodou em 91s, antes estava entre 106s e 108s
- O tipo de arquivo que armazena o treinamento (joblib) não pode ser dividido. Começamos a ver sobre Pickle, mas ainda estamos inconclusivos
25/06/2024
- Memory mapping resolveu a questão do armazenamento do joblib, por enquanto foi suspendida a necessidade de uma VM com mais RAM
26/06/2024
- Testes com a database menor para conclusão e comparativo das soluções com mmap (mode: read only) e sem (mode: none). Os resultados foram iguais.
- Continuidade na implementação do Spark para paralelismo e melhor desempenho

Pesquisadores

Luigi Negrini (BIRD Brain)
Lucas Resende Gomes (BIRD Brain)
Caio Cesar Oliveira Rabelo (COR)
Elton Soares Silva (COR)
Gessyca Carneiro Bernardes (COR)