Gerência de Redes: Uso da técnica de Máquina de Regras para Análise Causa-Raiz na Manutenção

Transcrição

1 Gerência de Redes: Uso da técnica de Máquina de Regras para Análise Causa-Raiz na Manutenção Este tutorial apresenta um exemplo de uso de uma Máquina de Regras (MR) em Engineering Intelligence (EI) para a análise de causa-raiz em uma rede de telecomunicações. Máquina de Regras é uma das técnicas usada em BI (Business Intelligence). Trata-se de uma forma programável de expressar regras de conhecimento que sejam intuitivam e de fácil interpretação e programação. A MR pode ser implementada por meio de árvore de decisão, relações lógicas, tabelas de decisão, hierarquia de eventos, etc. A EI, tal como BI, é também um processo de coleta, análise e gerência da informação e conhecimento. Nesse caso é orientada para dar apoio aos problemas de engenharia de planejamento e/ou operação da empresa. Jorge Moreira de Souza Doutor em Informática (81) pelo Instituto Nacional Politécnico de Toulouse, França, Mestre (75) e Bacharel (71) em Engenharia Elétrica na PUC-RIO. As principais áreas de interesse são Engenharia de Tráfego e Análise de Confiabilidade de Sistemas. Trabalha atualmente na FITec onde desenvolve trabalhos de análise/avaliação e revisões de projeto. Participou com membro da Comissão do I Concurso Teleco de Trabalhos de Conclusão de Curso (TCC), realizado em 2005, e do II Concurso Teleco de Trabalhos de Conclusão de Curso (TCC), realizado em jmdsouza@fitec.org.br Categoria: Operação e Gestão Nível: Introdutório Enfoque: Técnico Duração: 15 minutos Publicado em: 22/12/2008 1

2 Gerência de Redes: Introdução As redes de comunicação estão cada vez mais complexas abrangendo um grande número de diferentes equipamentos que funcionam juntos para oferecimento do serviço fim-a-fim aos usuários. A esse aumento de complexidade corresponde um aumento no número de falhas permanentes / transientes e um aumento substancial no número de alarmes no centro de gerência da rede devido à interdependência entre os elementos de rede (ER), a ocorrência primária gerando múltiplas ocorrências secundárias. Isso implica que um alarme gerado por um ER se propague rapidamente causando um efeito avalanche de alarmes que chegam até o sistema de gerência. No contexto de Gerência de Redes, a gerência de alarmes é uma facilidade importante no sentido de permitir ao operador uma análise e ação rápidas sobre as causas da ocorrência evitando um possível colapso da rede. De maneira geral, os alarmes gerados on-line pelo sistema vão para a tela de operação permanecendo na tela enquanto ativados ou até o reconhecimento pelo operador. Na desativação saem da tela e são gravados em uma base de histórico. Em situações normais a quantidade de alarmes na tela do operador é pequena e é relativamente fácil a interpretação das ocorrências. Nos casos mais graves, quando ocorre perda de enlace, por exemplo, há geralmente uma avalanche de alarmes. Nesse último caso, ocorre um aumento substancial no número de alarmes devido à interdependência entre os ERs, uma ocorrência primária (alarmes primários) gerando múltiplas ocorrências secundárias (alarmes secundários). As soluções propostas no contexto da análise eficiente dos alarmes são [1]: Filtragem e redução do fluxo de alarmes (alarmes secundários) identificando os alarmes primários; Análise causa-raiz (root cause) dos alarmes primários; Análise estatística das variações no comportamento dos alarmes. No tutorial [1] foi abordado o item 3, mostrando algumas técnicas estatísticas utilizáveis na análise de alarmes. No presente tutorial será apresentada uma solução para o item 2 usando: O conceito de classe de alarmes proposto na recomendação X.733 do International Telecommunication Union T [2] e seguido por muitos fabricantes de equipamentos de telecomunicações; Uma forma programável de expressar o conhecimento por meio de regras, que chamaremos de Máquina de Regras (MR). A Máquina de Regras é uma das técnicas de Engineering Intelligence (EI). EI é um processo sistemático de coleta, análise e gerência da informação e conhecimento para dar apoio aos problemas de engenharia de planejamento e/ou operação da empresa. Os conceitos serão exemplificados usando os alarmes de uma rede em anel SDH (Synchronous Digital Hierarchy). 2

3 Gerência de Redes: Análise Causa-Raiz Nos casos de avalanche de alarmes, torna-se necessário ter regras de identificação e priorização dos alarmes primários que servirão para a identificação da causa-raiz. Regras para identificação dos alarmes primários Para esse levantamento e o estabelecimento de regras é necessário minerar a base de dados de ocorrência à procura de cenários significativos e nesses cenários levantar a cronologia de ocorrências dos alarmes. Nos casos reais que tratados, o sistema gera de a ocorrências por mês. Para efetuar a procura de cenários recorre-se a uma ferramenta, o OLAP (On Line Analytical Processing). O tutorial [3] mostra a utilização do OLAP. Um exemplo da etapa de procura e criação de cenários desse projeto pode ser encontrado em [4]. Um sistema inteligente procura, numa determinada janela de tempo, conjuntos de eventos (alarmes) correlacionados e as regras que regem essa correlação. Os registros são organizados em função da topologia da rede e da data de ocorrência. Os conjuntos considerados significativos são analisados visando identificar os alarmes primários e secundários. Na identificação são usados os diversos atributos de um alarme para efetuar a filtragem. Num sistema flexível, os atributos de filtragem devem ser configurados pelo usuário. Com a finalidade de identificar os alarmes secundários, desnecessários na análise causa-raiz, o sistema deve dispor de filtros de alarmes. Por exemplo: Filtro usando o atributo que permite a identificação de alarmes gerados por tributários da rede; Filtro usando o atributo que identifica a causa, filtrando aqueles alarmes considerados de pouca importância; Etc. Como sugestão de implementação, o aplicativo pode ter uma janela onde o usuário identifica os atributos usados para filtro e os valores dos atributos que serão usados. Figura 1: Exemplo de janela para filtro de atributos. 3

4 A tela da figura 1 exemplifica a implementação de uma janela de filtro de alarmes de tributários usando, no caso, o atributo tipo de objeto disponível no equipamento. O aplicativo permite a pesquisa de todos os valores do atributo tipo de objeto (botão Pesquisar tipo de objeto). O usuário então escolhe os que deverão ser filtrados. Vale lembrar que os Elementos de Rede (ER s) podem ficar fora devido à manutenção. Deve haver um cadastro que permita indicar os elementos em manutenção para os quais os alarmes gerados serão filtrados durante o período de manutenção e teste. Regras para priorização dos alarmes primários A definição da priorização dos alarmes é importante para indicar a causa-raiz principal quando vários alarmes relacionados a um enlace ocorrem simultaneamente. Para a proteção da rede de telecomunicações no caso de falhas, são desenvolvidos sistemas automatizados que atuam a partir de alarmes que sinalizam situações de degradação importante. No caso de uma rede SDH, pode-se definir uma hierarquia de prioridades necessária para guiar as atuações quando vários eventos são alarmados simultaneamente. Exemplos de alarmes na ordem de prioridade para uma rede SDH: Falha no enlace (por exemplo: loss of signal LOS, loss of framing LOF); Falha na sinalização (excessive bit error rate BER); Sinalização degradada (high bit error rate HBER); Etc. Na seção a seguir será possível verificar o que são alarmes da classe comunicação e qualidade (observar a tabela 1, que prioriza os alarmes por classe). 4

5 Gerência de Redes: Máquina de Regras Uma Máquina de Regras (MR) é uma forma programável de expressar o conhecimento. A Máquina de Regras considera determinados atributos do alarme e programa a forma de tratamento dos atributos para chegar à causa raíz. A MR exemplificada neste tutorial usa o conceito de classe de eventos (no caso apresentado, associado aos alarmes) proposto na recomendação X.733 do International Telecommunication Union T [2], e que geralmente é seguida pelos fabricantes. Das cinco classes recomendadas na X.733, serão usadas três classes: Equipamento (equipment): está associado a um defeito no equipamento; Comunicação (communication): está associado à falta parcial ou total de comunicação entre ER s; Qualidade (quality): está associado à degradação da comunicação entre ERs ou da qualidade do serviço. São definidas pela X.733, adicionalmente às classes citadas, as classes: ambiental (environment) e processamento (processing). A MR implementa uma árvore de decisão cuja complexidade depende de cada problema. Figura 2: Árvore de decisão. No exemplo deste tutorial, a MR é mostrada na figura 2 e usa a classificação de tipos dos alarmes citada acima e a vizinhança entre os ER s. Os dois primeiros níveis da árvore de decisão verificam a classe do alarme, o último a vizinhança entre os ER s. Dois Elementos de Rede são vizinhos quando partilham o mesmo enlace. Na figura 3, os ER s 1 e 2 são vizinhos. 5

6 Figura 3: Falha de comunicação. Considera-se que há uma Rede de Supervisão por onde os alarmes são enviados. A Rede de Supervisão é monitorada separadamente. Como exemplo, para a rede em estudo será definida a seguinte tabela de hierarquia (tabela 1, o primeiro da lista por classe sendo o mais prioritário) de alarmes por classe. Essa tabela varia dependendo do fabricante. Caso para um dado ER ocorram diferentes alarmes da mesma classe, apenas o mais prioritário é selecionado para a análise causa-raiz. Tabela 1: Hierarquia de alarmes por classe. Classe Equipment Communication Quality Causa 1. Power Supply Failure 2. Ethernet Failure 3. Card Fail 1. Loss ofsignal (LOS) 2. Loss of Frame (LOF) 1. BER 2. HBER 3. Low Fast BER Voltando ao exemplo da figura 3, só há o alarme LOS enviado por ER2. A MR indicará falha de comunicação em relação ao vizinho ER1. A figura 4 mostra o caso de rompimento do enlace entre ER1 eer2. Nesse caso a MR indicará falha de comunicação de ER1 em relação à ER2 e de ER2 em relação à ER1. 6

7 Figura 4: Rompimento do enlace. Uma MR poderia ser programada em dois passos. No primeiro passo identificaria os alarmes importantes, no segundo passo a causa provável. No exemplo da figura 4, como cada ER gera o alarme LOS e os dois ER s são vizinhos, pode-se concluir que houve rompimento do enlace. A figura 5 ilustra o caso de alarmes de comunicação e de equipamento entre ER s vizinhos. Figura 5: Alarme de comunicação e de equipamento entre vizinhos. Nesse caso a MR indicaria a falha de equipamento (Card Fail) como provável causador da falha de comunicação. Geralmente o alarme informa a posição da placa causadora do alarme, o que permitiria a localização do problema. Resumindo, a árvore de decisão para definição da causa raiz usada como exemplo, segue a seguinte lógica: Uma funcionalidade que pode ser incorporada ao aplicativo é um histórico baseado nos cenários reais de causa-raiz. O cenário é o conjunto de ocorrências de alarmes desde o primeiro registro até o total desaparecimento de uma ou mais causas-raiz. O histórico guarda todos os cenários causa-raiz ocorridos. O histórico torna-se importante em sistemas que não são supervisionados 7 x 24 horas para verificar as ocorrências importantes fora do período de supervisão. Serve também para treinamento de operadores, pois a seqüência cronológica de alarmes pode simular os eventos de um dado cenário. 7

8 Gerência de Redes: Considerações Finais A programação do conhecimento por meio de Máquina de Regras foi usada em um projeto realizado pela FITec. Ela mostrou-se de fácil entendimento por parte dos usuários. Sua implementação também foi fácil, admitindo a complexidade necessária à solução do problema. Essa facilidade de entendimento permite o teste das MR s implementadas também por parte dos usuários. Esse entendimento das regras programadas gera confiança dos usuários no sistema implementado. Diferentemente de máquinas que são treinadas a partir de registros de ocorrências (Rede Neural é um exemplo), a MR programada permite refletir a experiência do operador. Claro, toda solução nessa área tem vantagens e desvantagens cuja discussão não é objeto desse tutorial. Referências [1] Tutorial Teleco: Aumentando a Disponibilidade da Rede por meio da Análise Estatística de Alarmes, [2] ITU X.733, INFORMATION TECHNOLOGY OPEN SYSTEMS INTERCONNECTION SYSTEMS MANAGEMENT: ALARMREPORTING FUNCTION, [3] Tutorial Teleco: Gerência de Redes: Consulta e Análise de Registros de Alarme Usando OLAP, [4] L. Scheunemann et all, Utilização de sistemas inteligentes para o processamento de alarmes e identificação de causa raiz, Publicado nos Anais do Citenel 2007, Araxá, MG. 8

9 gerência de Redes: Teste seu Entendimento 1. Como se definiria Engineering Inteligence? É uma técnica de Inteligência Artificial. É um processo de coleta, análise e gerência da informação e conhecimento. É uma técnica de otimização de sistemas. É uma especialização da engenharia. 2. Máquina de Regras programada é: Uma linguagem de programação de alto nível. Um novo sistema operacional. Uma forma programável de expressar o conhecimento. Uma forma automática de programação. 3. As classes de eventos recomendadas na X.733 são: Primário e secundário. Comunicação, equipamento, qualidade. Critical, major, minor. Comunicação, equipamento, qualidade, ambiental, processamento. 4. Quando se trata de alarmes associados à falhas, a classe de comunicação indica: Falta parcial ou total de comunicação. A placa defeituosa. O protocolo utilizado. O equipamento defeituoso. 9