Linha 285: Linha 285:
*17/05/2024
*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.
** 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.
*
* 03/06/2024:
** Reunião com Gessyca: Avaliação dos recursos necessários para executar o código criado.


= Pesquisadores  =
= Pesquisadores  =

Edição das 17h55min de 3 de junho de 2024

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:

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.
  • 03/06/2024:
    • Reunião com Gessyca: Avaliação dos recursos necessários para executar o código criado.

Pesquisadores

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