BR112016020189B1 - Método e sistema de resolução que facilita resolução de falhas de rede em centro de dados - Google Patents

Abstract

MÉTODO, SISTEMA DE RESOLUÇÃO QUE FACILITA RESOLUÇÃO DE FALHAS DE REDE EM CENTRO DE DADOS E MEIO DE ARMAZENAMENTO LEGÍVEL POR COMPUTADOR. A presente invenção refere-se a várias tecnologias pertencentes à provisão de assistência a um operador em um centro de dados com relação às falhas no centro de dados. Um alarme é recebido e u dispositivo com falha é identificado com base no conteúdo do alarme. As condições de falha do alarme são mapeadas em um sintoma de falha que pode ser exibido pelo dispositivo com falha e as opções de resolução de problemas previamente empregadas para mitigar o sintoma de falha são recuperadas de dados históricos. Rótulos são respectivamente atribuídos às opções de resolução de problemas, onde um rótulo é indicativo de uma probabilidade que uma opção de resolução de problemas à qual o rótulo foi atribuído mitigará o sintoma de falha.

Description

ANTECEDENTES

[001] Um centro de dados é uma coleção de dispositivos de computação que se comunicam entre si através de uma rede e operam em conjunto para fornecer serviços computacionais e/ou serviços de armazenamento de dados a um ou more usuários finais, onde um usuário final pode ser um indivíduo, uma empresa, ou similar. O centro de dados do mesmo inclui vários dispositivos de computação, vários dispositivos de infraestrutura de rede, como roteadores, re-roteadores, comutadores, gateways, firewalls, redes privadas virtuais (VPNs), pontes, etc., links de comunicações entre dispositivos de computação e dispositivos de infraestrutura de rede e links de comunicações entre dispositivos de infraestrutura de rede. Ao fornecer os serviços previamente mencionados, dados são transmitidos através da rede e entre dispositivos de computação no centro de dados. Os dispositivos de infraestrutura de rede são configurados para direcionar o tráfego através da rede.

[002] Em centros de dados convencionais, os dispositivos de in- fraestrutura de rede incluem dispositivos de ponta, que tendem a ser relativamente caros. Recentemente, entretanto, centros de dados foram configurados para incluir vários dispositivos de infraestrutura de rede de comodidade (por exemplo, pronto para uso) para reduzir os custos capitais associados com o centro de dados. Enquanto esses dispositivos de comodidade o custo menor que os dispositivos "de ponta", dispositivos de comodidade tendem a ser de alguma forma menos confiáveis do que os dispositivos de ponta, resultando em uma carga elevada em operadores de centro de dados para garantir o serviço contínuo. A solução de falhas de rede, entretanto, pode ser com- plexa e, assim, demorada, pois os dispositivos de infraestrutura de rede em um centro de dados podem ser fabricados por vários fabricantes diferentes, como computação e/ou dispositivos de rede no centro de dados podem ter diferentes sistemas operacionais instalados nele, pois um fabricante pode gerar diferentes modelos do mesmo tipo de dispositivo, etc. Assim, há uma quantidade significante de heterogeneidade em centros de dados convencionais.

[003] Em centros de dados relativamente grandes, uma equipe de operações é empregada para garantir que os serviços computacionais e serviços de armazenamento prometidos aos usuários finais (por exemplo, em Acordos de Nível de Serviço) estejam sendo atendidos. Consequentemente, quando um dispositivo de rede (por exemplo, um dispositivo de computação ou um dispositivo de infraestrutura de rede) gera um alarme, o alarme é direcionado a um console do operador monitorado por um operador na equipe de operações. O operador revisa o alarme e, com base no conhecimento e experiência pessoal (e possivelmente algumas diretrizes estáticas), o operador realiza a resolução de problemas e a depuração para rentar mitigar apenas (em vez de diagnostica) ou consertar a falha (diagnosticando a causa raiz do problema) indicada pelo alarme. Enquanto essa abordagem pode ser adequada para centros de dados relativamente pequenos, tal abordagem sem escala. Por exemplo, centros de dados são em escala para incluir centenas de milhares de dispositivos de computação e vários milhares de dispositivos de infraestrutura de rede. Quando eventos particulares ocorrer, um grande número de alarmes pode ser gerado por dispositivos no centro de dados em uma quantidade relativamente curta de tempo. O operador deve analisar através de alarmes para priorizar quais alarmes devem ser inicialmente direcionados e, então, tipicamente utiliza uma abordagem teste-e-erro (potencialmente acionada pelas diretrizes geradas por humano predefinidas) para direcio- nar os alarmes que acredita-se que sejam de alta prioridade Devido à complexidade relativamente alta dos problemas potenciais de rede, o operador pode exigir um intervalo de tempo prolongado de resolução de problemas, que pode resultar em inatividade do serviço.

SUMÁRIO

[004] O seguinte é um breve sumário da matéria que é descrita em mais detalhes aqui. Esse sumário não é destinado a ser limitativo ao escopo das reivindicações.

[005] Descrito aqui são várias tecnologias pertencentes à identifi cação de opções potenciais de resolução de problemas e etapas de resolução que podem ser empregadas para solucionar uma falha de rede em um centro de dados. As opções de resolução de problemas e etapas de resolução são fornecidas a um operador, quem pode utilizar as opções de resolução de problemas e etapas de resolução e solucionam a falha de rede utilizando as opções de resolução de problemas e etapas de resolução fornecidas. Adicionalmente descritas aqui estão as várias tecnologias pertencentes à priorização de falhas de rede com base nos alarmes gerados pelos dispositivos em um centro de dados, em que uma lista priorizada pode ser emersa ao operador para facilitar a triagem de alarmes.

[006] Um centro de dados inclui uma pluralidade de dispositivos de computação em rede, em que dados podem ser transmitidos entre os dispositivos de computação por links de rede em forma de uma pluralidade de dispositivos de infraestrutura de rede, como roteadores, co-roteadores, comutadores, equilibradores de carga, firewalls, redes privadas virtuais (VPNs, virtual private redes), entre outros. Os dispositivos de computação e/ou os dispositivos de infraestrutura de rede (coletivamente referidos como "dispositivos") podem ser configurados para gerar alarmes que são indicativos de falhas de rede. Por exemplo, um comutador pode ser configurado para gerar um alarme quando o comutador detecta que um link entre o comutador e outro dispositivo está inoperante. O alarme é recebido e uma determinação é feita como se o alarme fosse indicativo de um evento de rede acionável (por exemplo, uma falha de rede que deve ser solucionada). Quando for determinado que o alarme é indicativo de uma falha de rede solucio- nável, as condições de falha e os dados de telemetria associados podem ser mapeados em um conjunto de sintomas observados apresentados em: 1) o dispositivo com falha ou link; 2) a plataforma do dispositivo com falha; 3) dispositivos próximos ao dispositivo com falha na topografia de rede; 4) dispositivos que compartilham uma propriedade com o dispositivo com falha; e/ou 5) dispositivos no mesmo centro de dados que o dispositivo com falha, entre outros aspectos. Consequentemente, pelo menos um sintoma (por exemplo, "dispositivo inoperante", "oscilação de link", "alta utilização de CPU", ...) pode ser identificado para o dispositivo com falha ou link.

[007] Responsivo à identificação do sintoma para o dispositivo com falha ou link, uma pluralidade de opções de resolução de problemas recomendadas que pode potencialmente solucionar a falha de rede pode ser identificada. As opções de resolução de problemas podem ser com base nas opções de resolução de problemas prévias observadas no passado para solucionar a falha de rede pertencente ao dispositivo com falha ou link, o tipo de dispositivo com falha, a plataforma do dispositivo com falha, etc. As opções de resolução de problemas podem ter respectivos rótulos atribuídos à elas, em que os rótulos são indicativos das respectivas probabilidades que as opções de resolução de problemas, quando utilizadas pelo operador, solucionarão a falha de rede indicada pelo alarme. Os rótulos podem ser identificados com base nos sucessos ou falhas passados das opções de resolução de problemas quando realizadas com relação ao dispositivo com falha ou link, ao tipo de dispositivo com falha, à plataforma do dispositivo com falha, etc. Consequentemente, o operador pode ser fornecido com uma lista de opções de resolução de problemas para solucionar a falha de rede, bem como rótulos respectivamente atribuídos às opções de resolução de problemas que são indicativas das respectivas probabilidades que as opções de resolução de problemas solucionarão a falha de rede. Ainda, o operador pode empregar o conhecimento de domínio (por exemplo, de experiência ou conhecimento fornecido por um especialista de domínio) em combinação com as probabilidades da opção de resolução de problemas para determinar a sequência de ações para realizar a resolução da falha.

[008] Além disso, para uma opção de resolução de problemas na lista de opções de resolução de problemas, uma pluralidade de etapas de depuração pode ser apresentada ao operador, em que as etapas de depuração podem ser rótulos atribuídos que são respectivamente indicativos de probabilidades que as etapas de depuração corrigirão a falha de rede. Em um exemplo não limitativo, um dispositivo de infra- estrutura de rede pode emitir um alarme que indica que um dispositivo de infraestrutura de rede a jusante não está respondendo às solicitações de pulsação. O alarme pode ser recebido e as condições de falha no alarme podem ser mapeados ao "dispositivo inoperante" do sintoma previamente observado. Para tal sintoma, três opções de resolução de problemas, classificadas por suas respectivas probabilidades para solucionar a falha, podem ser apresentadas ao operador: 1) "verificar cabo", 2) "verificar fonte de alimentação" e 3) "verificar cartão de rede". Rótulos atribuídos às opções de resolução de problemas podem indicar que a primeira opção de resolução de problemas é mais provável para solucionar a falha de rede, a segunda opção de resolução de problemas é a segunda mais provável para solucionar a falha de rede e a terceira opção de resolução de problemas é a terceira mais provável para solucionar a falha de rede. Ainda, para uma opção de resolu- ção de problemas na lista de opções de resolução de problemas, pelo menos uma etapa de depuração pode ser fornecida ao operador. Por exemplo, para a opção de resolução de problemas "verificar cabo", duas etapas potenciais de depuração podem ser apresentadas ao operador. Cada etapa de depuração pode receber um respectivo rótulo que é indicativo de uma probabilidade que a etapa de depuração solucionará a falha de rede. Por exemplo, as etapas de depuração de "reinstalar o cabo" e "limpar o cabo" podem ser apresentadas como etapas de depuração, com a primeira etapa de depuração indicada como sendo mais provável para corrigir a falha de rede do que a segunda etapa de depuração. A indicação de probabilidade pode ser uma função de probabilidades computada com base nas etapas de depuração observadas previamente realizadas por operadores de centro de dados no dispositivo com falha ou link ou dispositivo(s) relacio- nado(s) ao dispositivo com falha ou link.

[009] Uma abordagem acionada por dados pode ser utilizada pa ra identificar as opções de resolução de problemas e etapas de depuração, e para atribuir os respectivos rótulos às opções de resolução de problemas e etapas de depuração. Por exemplo, quando o operador soluciona a falha de rede em forma de uma opção de resolução de problemas e etapa de depuração correspondente, o operador pode fornecer feedback que indica se o sintoma foi corretamente identificado, pode identificar qual opção de resolução de problemas foi selecio-nada e pode identificar quais etapas de depuração foram utilizadas para solucionar a falha de rede. Consequentemente, quando um alarme diferente é subsequentemente recebido (pertencente ao dispositivo com falha ou link, o tipo do dispositivo com falha, a plataforma do dispositivo com falha, etc.), as condições de falha podem ser corretamente mapeadas em um sintoma e rótulos atribuídos às opções de resolução de problemas e etapas de depuração, respectivamente, podem ser atualizadas com base nesse feedback. Assim, ao longo do tempo, a precisão das opções de resolução de problemas e etapas de depuração podem aumentar.

[0010] Adicionalmente, conforme será descrito aqui, alarmes po dem ser agrupados para representar uma falha de rede singular e falhas de rede podem ser priorizadas. Isso é, ao invés de tratar os alarmes de rede de baixo nível em isolamento, os alarmes podem ser correlacionados (agrupados) entre si para representar uma falha de rede singular. De acordo com um exemplo, esse agrupamento pode ser com base em três critérios: 1) tempo; um primeiro alarme gerado por um primeiro dispositivo pode ser agrupado com um segundo alarme gerado recentemente no tempo pelo primeiro dispositivo ou um segundo dispositivo na mesma interface; 2) localização; o primeiro alarme pode ser agrupado com um segundo alarme gerado por um segundo dispositivo que é um vizinho do primeiro dispositivo na rede (por exemplo, 1-2 saltos a montante ou a jusante na topografia de rede hierárquica); e 3) grupo de redundância; o primeiro alarme pode ser agrupado com um segundo alarme gerado por um segundo dispositivo em um mesmo grupo de redundância que o primeiro dispositivo (por exemplo, que pode indicar um problema com um protocolo de failover). O agrupamento de alarmes para representar falhas de rede pode ser empregado para categorizar e classificar as falhas de rede atuais, de modo que as falhas de rede que podem resultar em alto impacto comercial possam ser priorizadas como mais altas do que as falhas de rede que resultam em baixo impacto comercial.

[0011] O sumário acima apresenta um sumário simplificado a fim de fornecer um entendimento básico de alguns aspectos dos sistemas e/ou métodos aqui discutidos. Esse sumário não é uma visão geral extensivo dos sistemas e/ou métodos aqui discutidos. Não é destinado para identificar elementos chave/críticos ou para delinear o escopo desses sistemas e/ou métodos. Sua única finalidade é apresentar alguns conceitos em uma forma simplificada como um prelúdio à descrição mais detalhada que é apresentada posteriormente.

BREVE DESCRIÇÃO DOS DESENHOS

[0012] A figura 1 ilustra uma porção exemplar de um centro de dados.

[0013] A figura 2 ilustra uma arquitetura do centro de dados exemplar.

[0014] A figura 3 é um diagrama em blocos funcional de um siste ma de resolução exemplar que recebe alarmes gerados por dispositivos de rede em um centro de dados e emite opções de resolução de problemas e etapas de depuração responsivas ao recebimento dos alarmes.

[0015] A figura 4 é um diagrama em blocos funcional de um com ponente identificador de resolução exemplar incluído no sistema de resolução.

[0016] A figura 5 é uma tabela de histórico de falhas exemplar.

[0017] A figura 6 é uma interface gráfica do usuário exemplar que descreve as opções potenciais de resolução de problemas e etapas de depuração para solucionar uma falha de rede indicada por um alarme.

[0018] A figura 7 ilustra um componente de priorização de alarme exemplar que é opcionalmente incluído no sistema de resolução.

[0019] A figura 8 é um fluxograma que ilustra uma metodologia exemplar para emitir opções de resolução de problemas para solucionar uma falha de rede indicada por um alarme gerado por um dispositivo de rede.

[0020] A figura 9 é um fluxograma que ilustra uma metodologia exemplar para primeiro agrupar os alarmes relacionados e, então, emitir uma lista classificada de falhas de rede.

[0021] A figura 10 é um fluxograma que ilustra uma metodologia exemplar para atualizar dados históricos pertencentes a um centro de dados com base no feedback do operador.

[0022] A figura 11 é um sistema de computação exemplar.

DESCRIÇÃO DETALHADA

[0023] Várias tecnologias pertencentes à solução de falhas de re de em um centro de dados são agora descritas com referência aos desenhos, em que numerais de referência similares são utilizados para se referirem aos elementos similares por todo o relatório. Na seguinte descrição, para finalidades de explicação, vários detalhes específicos são estabelecidos a fim de fornecer um entendimento profundo de um ou mais aspectos. Pode ser evidente, entretanto, que os aspectos podem ser praticados sem esses detalhes específicos. Em outros casos, estruturas e dispositivos bem conhecidos são mostrados na forma de diagrama em blocos para facilitar a descrever um ou mais aspectos. Ainda, deve ser entendido que a funcionalidade que é descrita como sendo realizada por certos componentes do sistema pode ser realizada por múltiplos componentes. De modo similar, por exemplo, um componente pode ser configurado para realizar a funcionalidade que é descrita como sendo realizada por múltiplos componentes.

[0024] Além disso, o termo "ou" é destinado a significar um "ou" inclusivo em vez de um "ou" exclusivo. Isso é, a menos que especificado de outra forma, ou claro do contexto, a frase "X emprega A ou B" é destinado para significar qualquer uma das permutações inclusivas naturais. Isso é, a frase "X emprega A ou B" é atendida por qualquer um dos seguintes casos: X emprega A; X emprega B; ou X emprega ambos A e B. Além disso, os artigos "um" e "uma" como utilizados nesse pedido e nas reivindicações anexas devem ser geralmente construídos para significar "um ou mais" a menos que especificado de outra forma ou claro a partir do contexto a ser direcionado a uma forma singular.

[0025] Ainda, como aqui utilizado, os termos "componente" e "sis tema" são destinados para abranger armazenamento de dados legível por computador que é configurado com instruções executáveis por computador que fazem com que certa funcionalidade seja realizada quando executada por um processador. As instruções executáveis por computador podem incluir uma rotina, uma função, ou similar. Ainda deve ser entendido que um componente ou sistema pode ser localizado em um único dispositivo ou distribuído por vários dispositivos. Ainda, como aqui utilizado, o termo "exemplar" é destinado para significar servindo como uma ilustração ou exemplo de algo e não é destinado para indicar uma preferência.

[0026] Agora com referência à figura 1, uma porção de um centro de dados exemplar 100 (referido aqui como o centro de dados 100) é ilustrada. O centro de dados 100 pode ser configurado para fornecer serviços a um usuário final 102, em que tais serviços podem ser serviços de computação e/ou serviços de armazenamento, e em que o usuário final 102 pode ser um indivíduo, uma empresa, ou similar. Em um exemplo, o centro de dados 100 pode ser um centro de dados empresarial que é pertencente por uma empresa particular e fornece serviços de computação e armazenamento para a empresa. Em tal situação, o usuário final 102 pode ser um indivíduo que trabalha na empresa, uma divisão da empresa, etc. Em outro exemplo, o centro de dados 100 pode ser operado por uma primeira empresa e o usuário final 102 pode ser uma segunda empresa (por exemplo, a primeira empresa aluga armazenamento de dados e recursos de computação à segunda empresa). Ainda em outro exemplo, o centro de dados 100 pode ser operado por uma empresa e o usuário final 102 pode ser um indivíduo. Serviços de computação e/ou serviços de armazenamento exemplares que podem ser oferecidos pelo centro de dados 100 incluíram serviços de e-mail, serviços de busca, armazenamento, serviços on-line e similares. Em um exemplo, o usuário final 102 pode operar um dispositivo de computação 103 e pode transmitir dados à e receber dados do centro de dados 100 em forma do dispositivo de computação 103, em que o dispositivo de computação 103 pode ser qualquer tipo adequado de dispositivo de computação, incluindo, mas não limitado à, um dispositivo de computação para desktop, um dispositivo de computação móvel (por exemplo, um dispositivo de computação para notebook, um telefone móvel, um dispositivo de computação de ardósia, um dispositivo de computação utilizável, etc.), um servidor, ou similar.

[0027] O centro de dados 100 inclui uma pluralidade de dispositi vos de computação 104-110, em que os dispositivos de computação 104-110 podem incluir servidores, dispositivos de armazenamento dedicados, etc. Os dispositivos de computação 104-110 são configurados para realizar ações (por exemplo, armazenar dados, processar dados, e/ou transmitir dados) com base em uma solicitação do dispositivo de computação 103 do usuário final 102. Por exemplo, o usuário final 102 pode solicitar o desempenho de uma pesquisa sobre o conteúdo no armazenamento do primeiro dispositivo de computação 104 e o primeiro dispositivo de computação 104 pode ser configurado para executar a pesquisa e emitir resultados de pesquisa responsivos ao centro de dados 100 que recebe a solicitação. Em outro exemplo, o segundo dispositivo de computação 106 pode armazenar uma porção de um índice de motor de pesquisa e pode ser configurado para transmitir a porção do índice de motor de pesquisa à outro dispositivo de computação no centro de dados 100 (ou à outro centro de dados) responsivo ao recebimento de uma solicitação para fazer isso do dispositivo de computação 103.

[0028] O centro de dados 100 ainda compreende uma pluralidade de dispositivos de infraestrutura de rede 114-120. Os dispositivos de infraestrutura de rede 114-120 são configurados para facilitar trans- missão de dados entre os dispositivos de computação nos dispositivos de computação 104-110 no centro de dados 100, facilitam a transmissão de dados entre os centros de dados, bem como para facilitar a transmissão de dados entre o dispositivo de computação 103 operado pelo usuário final 102 e os dispositivos de computação 104-110. No centro de dados exemplar 100 descrito na figura 1, os dispositivos de infraestrutura de rede 114-120 incluem dois comutadores 114 e 116, um roteador 118 e um firewall 120. Os dispositivos no centro de dados 100 (onde "dispositivos" se referem coletivamente aos dispositivos de computação e dispositivos de infraestrutura de rede) são de forma comunicável acoplados entre si em forma de links de rede. Assim, por exemplo, o primeiro dispositivo de computação 104 é de forma comunicável acoplado ao comutador 114 em forma de um primeiro link de rede, o segundo dispositivo de computação 106 é de forma comunicável acoplado com o comutador 114 em forma de um segundo link de rede, o comutador 114 é de forma comunicável acoplado ao roteador 118 em forma de um terceiro link de rede e assim por diante. Deve ser entendido que enquanto o centro de dados 100 é mostrado como incluindo um número relativamente pequeno de dispositivos, um centro de dados pode incluir muitos milhares de dispositivos de computação e muitos milhares de dispositivos de infraestrutura de rede. Ainda, os dispositivos de infraestrutura de rede 114-120 podem incluir dispositivos com base em hardware e/ou software. Por exemplo, o roteador 118 pode ser um roteador com base em software que é executado por um dispositivo de computação. De forma similar, o firewall 120 pode ser um firewall de software que executa em um roteador de hardware ou dispositivo de computação.

[0029] Os dispositivos de computação 104-110 e/ou os dispositi vos de infraestrutura de rede 114-120 podem ser configurados para emitir alarmes quando certos eventos respectivos são detectados. Em um exemplo, o roteador 118 pode ser configurado para emitir um alarme quando o roteador 118 emite solicitação de pulsação (por exemplo, uma solicitação para responder à mensagem) direcionada a um dispositivo de computação particular e falha para receber uma ou mais respostas dentro de uma quantidade limiar de tempo da transmissão da pulsação. Em outro exemplo, um conjunto de processos distribuídos que executa dentro do centro de dados 100 (referido como "runners" ou "watchdogs") ou fora do centro de dados 100 pode enviar periodicamente uma solicitação de batimento a um serviço, um servidor, ou um dispositivo de computação além de executar um conjunto de micro transações sintéticas para garantir que o serviço, o servidor ou o dispositivo de computação esteja disponível a partir de uma perspectiva do usuário final (por exemplo, enviar um e-mail de pequeno teste para verificar que o serviço de e-mail está executando correta-mente). Um alarme pode ser gerado quando uma resposta à solicitação de batimento não é recebida. Consequentemente, um alarme pode ser indicativo de uma falha de rede: por exemplo, que o dispositivo de computação é inoperante, ou que um link de rede entre o roteador 118 e o dispositivo de computação particular é inoperante. Em outro exemplo, o comutador 114 pode ser configurado para gerar um alarme quando volume de dados direcionados através do comutador 114 atin-ge um limiar predefinido.

[0030] Um sistema de resolução 122 recebe alarmes gerados pe los dispositivos de computação 104-110 e/ou pelos dispositivos de in- fraestrutura de rede 114-120 e emite dados a uma estação do operador 124 empregada por um operador de rede 126 para ajudar o operador de rede 126 a solucionar falhas de rede indicadas por pelo menos um alarme. Conforme será descrito em mais detalhes aqui, o sistema de resolução 122 pode identificar uma falha de rede com base em pelo menos um alarme recebido e pode identificar uma pluralidade de op- ções potenciais de resolução de problemas para solucionar a falha de rede. Uma opção de resolução de problemas pode ser percebida como uma verificação de alto nível que pode ser realizada pelo operador, como "verificar cartão de rede", "verificar cabo", ou similar. Ainda, o sistema de resolução 122 pode atribuir os respectivos rótulos às opções de resolução de problemas, onde os rótulos são respectivamente indicativos de probabilidades que as opções de resolução de problemas solucionarão a falha de rede quando realizadas pelo operador de rede 126. Conforme será descrito em mais detalhes aqui, o sistema de resolução 122 pode identificar as opções de resolução de problemas e respectivos rótulos com base nas prévias opções de resolução de problemas realizadas pelo operador de rede 126 (ou outros operadores em uma equipe de operações para o centro de dados 100) para solucionar falhas de rede similares (por exemplo, falhas de rede com sintomas similares).

[0031] O operador 126 então recebe uma lista priorizada de opções de resolução de problemas que o operador 126 pode acessar para solucionar a falha de rede. Além disso, uma opção de resolução de problemas pode ter uma ou mais etapas de depuração atribuídas à ela, em que uma etapa de depuração fornece instruções mais granulares (quando comparadas à opção de resolução de problemas) ao operador 126 para solucionar a falha de rede. Em um exemplo, quando o operador 126 escolhe uma opção particular de resolução de problemas, uma lista de etapas de depuração pode ser apresentada ao operador 126. Adicionalmente, cada etapa de depuração pode ter um respectivo rótulo atribuído à ela, onde o rótulo é indicativo de uma probabilidade que a etapa de depuração solucionará a falha de rede identificada (assumindo que a opção de resolução de problemas é a opção correta). A partir da perspectiva do operador 126, o operador 126 recebe uma lista de opções de resolução de problemas da qual o operador 126 pode selecio- nar uma opção particular de resolução de problemas (por exemplo, a opção de resolução de problemas associada com a probabilidade mais alta para solucionar a falha de rede) e pode, então, realizar etapas de depuração em ordem de probabilidade. Além disso, o operador 126 pode ainda receber contagens indicando as inúmeras vezes que uma opção de resolução de problemas e/ou etapa de depuração foi considerada e/ou inúmeras vezes que a opção de resolução de problemas e/ou a etapa de depuração foi bem-sucedida. Por exemplo, duas opções de resolução de problemas podem ser atribuídas com probabilidades equivalentes (por exemplo, 50%). Entretanto, um primeiro rótulo atribuído à primeira opção de resolução de problemas pode indicar que a opção de resolução de problemas foi considerada duas vezes e foi bem-sucedida uma vez, enquanto um segundo rótulo atribuído à segunda opção de resolução de problemas pode indicar que a opção de resolução de problemas foi selecionada milhares de vezes e foi bem-sucedida quinhentas vezes. Quando o operador 126 soluciona a falha de rede, o operador 126 pode fornecer feedback ao sistema de resolução 122 ao qual a opção de resolução de problemas (se houver) e quais etapas de depuração (se houver) solucionaram a falha de rede. Esse feedback pode ser empregado pelo sistema de resolução 122 quando alarmes subse-quentes são recebidos, em que as opções de resolução de problemas, etapas de depuração e rótulos correspondentes podem ser com base no feedback. Assim, o sistema de resolução 122 utiliza uma abordagem com base em dados para fornecer instruções de solução de falha de rede aos operadores.

[0032] O sistema de resolução 122 pode ainda ser configurado para priorizar as falhas de rede para o operador 126, de modo que as falhas de rede sejam acionadas. Como será entendido por um técnico no assunto, algumas falhas de rede têm maior impacto no lucro, rendimento de dados, ou similar, do que outras falhas de rede. O sistema de resolução 122 pode ser configurado para receber um alarme dos dispositivos de computação 104-110 e/ou dos dispositivos de infraes- trutura de rede 114-120, e agrupar o alarme com pelo menos um outro alarme para representar uma falha de rede singular. Assim, ao invés do operador 126 analisar os alarmes independentes de baixo nível, o operador 126 pode receber uma representação de nível mais alto de falhas de rede. Ainda, o sistema de resolução 122 pode priorizar as falhas de rede com relação entre si, de modo que o operador 126 seja direcionado à solução de problemas de falhas de rede tendo impacto mais alta primeiro, seguido por falhas de rede tendo impacto inferior.

[0033] Enquanto o sistema de resolução 122 é mostrado como sen do incluído no centro de dados 100, deve ser entendido que o sistema de resolução 122 pode ser executado em um dispositivo de computação que é externo ao centro de dados 100. Por exemplo, o centro de dados 100 pode incluir um dispositivo de computação que é configurado para transmitir todos os alarmes de rede coletados um dispositivo externo que executa o sistema de resolução 122. Além disso, deve ser entendido que o sistema de resolução 122 pode ser executado em um dispositivo de computação ou distribuído por múltiplos dispositivos de computação. Ainda em outro exemplo, o sistema de resolução 122 pode executar em uma máquina virtual (MV), em que o VM é executado em um dispositivo de computação ou é distribuído por múltiplos dispositivos de computação (interno ou externo ao centro de dados 100).

[0034] Agora com referência à figura 2, uma arquitetura do centro de dados exemplar (parcial) 200 é ilustrada, em que o centro de dados 100 pode ser incluído a arquitetura do centro de dados 200. Deve ser entendido que a arquitetura do centro de dados 200 é exemplar e que outras variantes de topologia, como redes planas/topologias Clos, podem incluir o centro de dados 100 e são destinadas a serem abrangidas pelas reivindicações anexas. A arquitetura do centro de dados 200 compreende uma pluralidade de comutadores Top of Rack (ToR) 202208. Uma respectiva pluralidade de servidores montados em suporte (não mostrada) pode ser conectada (ou com dupla domiciliação) à cada comutador ToR nos comutadores ToR 202-208.

[0035] A arquitetura 200 também inclui um comutador de agrega ção primário 210 e um comutador de agregação de backup 212, em que cada comutador ToR nos comutadores ToR 202-208 é conectado ao comutador de agregação primário 210 e ao comutador de agregação de backup 212 (para redundância). Na prática, um centro de dados inclui vários pares de comutadores de agregação primário e de backup, e cada par redundante de tráfego de agregados de comutadores de agregação de vários (por exemplo, dez) de comutadores ToR. A arquitetura 200 pode incluir um primeiro par redundante de equilibra- dores de carga 214-216 conectado ao comutador de agregação primário 210 e um segundo par redundante de equilibradores de carga 218 e 220 conectado ao comutador de agregação de backup 212. Os equi- libradores de carga 214-220 podem realizar o mapeamento entre endereços IP estáticos (por exemplo, exposto aos clientes através de DNS) e endereços IP dinâmicos de servidores que processam as solicitações do usuário.

[0036] A arquitetura 200 ainda inclui um roteador de acesso primá rio 222 e um roteador de acesso de backup 224. O comutador de agregação primário 210, o comutador de agregação de backup 212, o roteador de acesso primário 222 e o roteador de acesso de backup 224 podem formar um grupo de redundância. Em um centro de dados tendo a arquitetura 200, grupos redundantes de dispositivos e links podem ser utilizados para mascarar as falhas de rede. Os comutadores de agregação 210-212 encaminham o tráfego (agregado dos ToRs 202-208) aos roteadores de acesso 222-224. A arquitetura 200 também inclui um roteador central primário 226 e um roteador central de backup 228, cada um conectado à ambos os roteadores de acesso 222-224. O roteador de acesso primário 222, o roteador de acesso de backup 224, o roteador central primário 226 e o roteador central de backup 228 formam outro grupo de redundância. Os roteadores de acesso 222-224 roteiam, por exemplo, o tráfego agregado de até vários milhares servidores e roteiam o tráfego aos roteadores centrais 226-228. Os roteadores centrais 226-228 conectam-se ao resto da rede do centro de dados e Internet 230.

[0037] Em uma modalidade exemplar, servidores na arquitetura (por exemplo, acoplados aos comutadores ToR 202-208) podem ser divididos em redes de área local virtual (VLANs, virtual local area networks) para limitar a sobrecarga e para isolar os diferentes aplicativos hospedados na rede. Em cada camada da topologia do centro de dados (com a possível exceção de um subconjunto de comutadores ToR, redundância (por exemplo, 1:1 de redundância) pode ser embutido na topologia de rede para mitigar falhas. Ainda, além dos roteadores e comutadores, a arquitetura 200 pode incluir caixas centrais como equilibradores de carga, firewalls e similares. A partir do supracitado, pode ser determinado que os dispositivos de computação 104-110 podem ser dispositivos de computação do servidor na arquitetura, os comutadores 114-116 podem ser comutadores de agregação, o roteador 118 pode ser um roteador de acesso ou um roteador central, etc.

[0038] Agora com referência à figura 3, um diagrama em blocos funcional do sistema de resolução 122 é ilustrado. Conforme indicado acima, o sistema de resolução 122 pode receber alarmes gerados por múltiplos dispositivos no centro de dados 100 em diferentes pontos no tempo. O sistema de resolução 120 inclui um componente receptor de alarme 302 que recebe os alarmes gerados pelos dispositivos no centro de dados 100. Um componente identificador de resolução 304 está em comunicação com o componente receptor de alarme 302 e é confi- gurado para determinar se o alarme recebido pelo componente receptor de alarme 302 for indicativo de uma falha de rede acionável (por exemplo, uma falha de rede que o operador 126 pode solucionar através da resolução de problemas e depuração). De acordo com um exemplo, um alarme gerado pelo roteador 118 pode indicar que o roteador 118 é incapaz de se comunicar com o comutador 116, o que pode, por sua vez, (por exemplo) indicar qualquer dentre 1) o mau fun-cionamento do roteador 2) o comutador sendo inoperante; 3) soltar o cabeamento no link de rede entre o roteador 118 e o comutador 116; etc. Essas falhas de rede acionáveis que podem ser solucionadas pelo operador 126.

[0039] O sistema de resolução 122 pode incluir ou ter acesso a um armazenamento de dados 306 que compreende dados históricos 308. Conforme será descrito em mais detalhes abaixo, os dados históricos 306 podem compreender "tabelas de histórico de falhas" para dispositivos e links no centro de dados 100, em que uma tabela de histórico de falhas para um dispositivo ou link pode incluir informações que são descritivas de falhas passadas do dispositivo ou link, incluindo sintomas de falha, períodos da falha mais recente, número de falhas sobre um período de tempo limite, mudanças de configuração e similares.

[0040] Em operação, o componente receptor de alarme 302 rece be um alarme, que inclui condições de falha. As condições de falha podem incluir período de geração do alarme, identidade do dispositivo ou link que exibe um sintoma de falha, identidade do dispositivo que gerou o alarme, identificação de uma interface que corresponde a um evento detectado, identidade de um centro de dados que inclui o dispositivo ou link que exibe o sintoma de falha, etc. O componente identificador de resolução 304, com base no alarme (e opcionalmente outros alarmes recebidos), pode determinar que o alarme é indicativo de um falha de rede acionável e pode ainda identificar um dispositivo com falha ou link com base nos conteúdos do alarme (por exemplo, em alguns casos o dispositivo que gera o alarme não é o dispositivo com falha). O componente identificador de resolução 304 pode mapear as condições de falha indicadas no alarme e dados de telemetria associados a um conjunto de sintoma previamente observado de falhas incluído nos dados históricos 308. Em um exemplo, o dispositivo com falha ou link pode ter exibido previamente os sintomas de falha, um dispositivo do mesmo tipo que o dispositivo com falha pode ter exibido previamente os sintomas de falha, um dispositivo que compartilha uma plataforma com o dispositivo com falha pode ter exibido previamente os sintomas de falha, um dispositivo próximo na rede (por exemplo, 12 saltos a montante ou a jusante do dispositivo com falha) pode ter exibido previamente os sintomas de falha, etc. É ainda observado que em casos onde as condições de falha do alarme não podem ser mapeadas em um sintoma, então as diretrizes estáticas podem ser colocadas ao operador 126.

[0041] Responsivo ao(s) sintoma(s) observado(s) sendo identifica dos através do mapeamento, o componente identificador de resolução 304 pode realizar uma análise estatística sobre os dados históricos 308 para identificar uma pluralidade de opções de resolução de problemas recomendadas, bem como etapas de depuração que respectivamente correspondem às opções de resolução de problemas, para uso pelo operador 126 para solucionar a falha de rede. Ainda, as opções de resolução de problemas e etapas associadas de depuração podem ser classificadas por segurança, de modo que as opções de resolução de problemas e etapas de depuração com segurança mais alta para solucionar o problema de rede são apresentadas mais proeminentemente ao operador 126.

[0042] Por exemplo, o componente identificador de resolução 304 pode determinar que um alarme de rede gerado pelo comutador 116 indica que o terceiro dispositivo de computação 108 no centro de dados 100 não está respondendo às solicitações de pulsação, que podem ser mapeadas, por exemplo, ao seguinte sintoma previamente observado de falhas para o terceiro dispositivo de computação 108 (ou outros dispositivos no centro de dados 100 ou em outro centro de da-dos): 1) "oscilação de link"; e 2) "dispositivo inoperante". Para cada um desses sintomas identificados pelo componente identificador de resolução 304, o componente identificador de resolução 304 pode identificar opções de resolução de problemas e etapas de depuração correspondentes nos dados históricos 308 indicados como previamente sendo realizados para solucionar falhas de rede que têm tal sintoma. Além disso, o componente identificador de resolução 304 pode atribuir rótulos às opções de resolução de problemas e etapas de depuração que são respectivamente indicativas de probabilidades que as opções de resolução de problemas e etapas de depuração mitigarão a falha de rede. Uma estrutura exemplar de dados nos dados históricos 308 que facilita a identificação dos sintomas, as opções de resolução de problemas, as etapas de depuração e os rótulos é descrita em mais detalhes abaixo.

[0043] Em uma modalidade exemplar, o componente identificador de resolução 304 pode, então, emitir os sintomas, as opções de resolução de problemas, as etapas de depuração e os rótulos correspondentes ao operador 126. Efetivamente, então, o operador 126 recebe uma lista priorizada de opções de resolução de problemas e etapas de resolução para cada sintoma que é mapeado nas condições de falha do alarme recebido (que é indicativo de uma falha de rede acionável). O operador 126 pode, então, passar pelas opções de resolução de pro-blemas e etapas de depuração em uma ordem com base nos rótulos atribuídos às opções de resolução de problemas e etapas de depuração, resultando na resolução relativamente eficiente da falha de rede.

[0044] Em outra modalidade exemplar, o componente identificador de resolução 304 pode identificar pelo menos uma opção de resolução de problemas e pelo menos uma etapa de depuração e pode transmitir um sinal a um dispositivo no centro de dados 100 que faz com que pelo menos uma opção de resolução de problemas seja selecionada e pelo menos uma etapa de depuração seja realizada, sem a intervenção do operador 126. Em um exemplo não limitativo, o componente identificador de resolução 304 pode determinar que há uma probabilidade relativamente alta que reinicia o comutador 116 mitigará um sintoma da falha de rede. O componente identificador de resolução 304 pode transmitir um sinal ao comutador 116 que faz com que o comutador 116 seja reiniciado, sem emergir o alarme ao operador 126 ou, caso contrário, exigindo intervenção do operador.

[0045] Em um exemplo, o componente identificador de resolução 304 pode tentar solucionar automaticamente uma falha de rede antes de emergir às opções de resolução de problemas e etapas de depuração ao operador 126 quando 1) uma probabilidade computada de uma opção de resolução de problemas e etapa de depuração que soluciona a falha de rede está acima de um limiar de probabilidade predefinido (por exemplo, 0,9); 2) a probabilidade computada da opção de resolução de problemas e etapa de depuração que soluciona a falha de rede está ente as k probabilidades mais altas para opções de resolução de problemas e etapas de depuração que solucionam a falha de rede (por exemplo, entre as opções de resolução de problemas e etapas de depuração que são mais prováveis para solucionar a falha de rede); 3) seleção automática da opção de resolução de problemas e desempenho da etapa de depuração não resulta em uma falha de redundância; 4) seleção automática da opção de resolução de problemas e desempenho da etapa de depuração não considera mais do que uma quantidade limiar de tempo (por exemplo, um minuto); e/ou 5) seleção auto- mática da opção de resolução de problemas e etapa de depuração de desempenho não remove um dispositivo que facilita o transporte de um volume relativamente alto de tráfego através do centro de dados 100. Outros fatores para determinar quando selecionar automaticamente uma opção de depuração e realizar uma etapa de depuração são também contemplados.

[0046] O componente identificador de resolução 304 pode ainda ser configurado para emergir dados adicionais pertencentes às falhas de rede ao operador 126. Por exemplo, o componente identificador de resolução 304 pode consultar dados históricos 308 para agregar dados de falha por uma variedade de dimensões. Em um exemplo, com relação a um dispositivo com falha ou link particular (por exemplo, identificado como sendo um dispositivo com falha ou, de outro modo, identificado pelo operador 126), o componente identificador de resolução 304 pode emitir dados que são indicativos de inúmeras vezes que o dispositivo ou link falhou (por exemplo, sobre uma janela de tempo história limiar), frequência do dispositivo ou link que falha com relação à frequência de outros dispositivos ou links no centro de dados 100 que falham, frequência do dispositivo que falha com relação à frequência de outros dispositivos do mesmo tipo no centro de dados 100 que falha, etc.

[0047] Em outro exemplo, o operador 126 pode estabelecer uma solicitação para as informações pertencentes a um tipo de dispositivo, plataforma, ou centro de dados particular e o componente identificador de resolução 304 pode agregar dados de falha por uma variedade de parâmetros para emergir as informações de falha para o operador 126. Em um exemplo não limitativo, responsivo ao recebimento de uma solicitação do operador 126 para informações sobre uma plataforma de dispositivo, o componente identificador de resolução 304 pode emitir dados que identificam o dispositivo com falhas mais frequentemente nessa plataforma, frequência da falha do dispositivo na plataforma com relação às outras plataformas, frequência de falhas de dispositivos de diferentes tipos com relação entre si, etc.

[0048] Ainda em outro exemplo, o operador 126 pode solicitar emergir informações sobre uma dimensão/eixo do centro de dados, em vez de um dispositivo ou tipo de dispositivo especificado. Por exemplo, o operador 126 pode solicitar a identificação do dispositivo com falhas mais frequentemente no centro de dados 100 e o componente identificador de resolução 304 pode retornar uma lista de dispositivos no centro de dados 100 que falham mais frequentemente. De modo similar, o operador 126 pode solicitar a identificação de dispositivos mais estáveis no centro de dados 100 e o componente identificador de resolução 304 pode retornar uma lista de dispositivos no centro de dados 100 que falham menos frequentemente. A estrutura dos dados históricos 308 facilita a agregação de informações sobre várias dimensões/eixos.

[0049] O sistema de resolução 122 pode também incluir um com ponente de feedback 312 que é configurado para receber feedback do operador 126 sobre os sintomas observados para um dispositivo com falha, opções de resolução de problemas e/ou etapas de depuração realizadas para corrigir uma falha de rede causada pelo dispositivo com falha, entre outras informações. Oe componente de feedback 312, responsivo à entrada de recebimento do operador 126, pode, então, ser configurada para atualizar os dados históricos 308 (por exemplo, uma tabela histórica de falhas para o dispositivo com falha). Assim, quando um alarme é subsequentemente recebido pelo sistema de resolução 122, o componente identificador de resolução 304 pode emitir sintomas de falha atualizados, opções de resolução de problemas, etapas de depuração, e/ou rótulos com base nas observações recentes do operador 126.

[0050] O sistema de resolução 122 pode opcionalmente incluir um componente de priorização de evento 314 que prioriza as falhas de rede acionáveis para apresentação ao operador 126. Por exemplo, durante um intervalo de tempo particular (por exemplo, devido a uma distribuição de correção do sistema operacional), vários dispositivos no centro de dados 100 podem gerar alarmes, convencionalmente exigindo que o operador 126 analise através de um grande volume de alarmes para determinar quais alarmes representam as falhas de rede acionáveis e para ainda priorizar as falhas de rede. O componente de priorização de evento 314 reduz a carga no operador 126 correlacionando vários alarmes para representar uma falha de rede singular e priorizar as falhas de rede (por exemplo, como uma função de impacto da falha de rede).

[0051] Em conexão com a priorização das falhas de rede, o arma zenamento de dados 306 pode incluir um gráfico de rede 310, que é representativo de uma topografia de rede hierárquica do centro de dados 100 e o componente de priorização de evento 314 pode priorizar as falhas de rede com base no gráfico de rede 310. Por exemplo, uma falha de rede causada por um dispositivo próximo ao topo da hierarquia de rede (conforme identificado no gráfico de rede 308) impõe um alto risco de interrupção de serviço e pode, dessa forma, ser priorizado mais alto do que as falhas de rede causadas pelos dispositivos inferiores na hierarquia de rede. Em outro exemplo, o componente de priori- zação de evento 312 pode priorizar as falhas de rede como uma função de inúmeras propriedades que podem ser impactadas devido às respectivas falhas de rede (ou ainda uma única propriedade com um risco de alto impacto de inteligência empresarial).

[0052] Agora com referência à figura 4, um diagrama em blocos funcional do componente identificador de resolução 304 é descrito. O componente identificador de resolução 304 recebe um alarme 400 ge- rado por um dispositivo no centro de dados 100. Por exemplo, o dispositivo pode ser um dos dispositivos de computação 104-110 ou um dos dispositivos de infraestrutura de rede 114-120. No exemplo mostrado na figura 4, o alarme 400 inclui uma pluralidade de condições de falha: 1) uma marca temporal que indica quando o alarme foi gerado pelo dispositivo; 2) um ID do alarme que identifica um único alarme gerado de um dispositivo; 3) um ID do dispositivo que identifica o dispositivo que gerou o alarme; 4) um link de interface que identifica uma porta particular ou link de rede que está apresentando uma falha; e 5) e uma descrição de evento, que inclui texto gerado por máquina que fornece mais detalhes sobre a falha e é emitido pelo dispositivo que gerou o alarme 400. Deve ser entendido que o conteúdo do alarme 400 pode diferenciar do que é mostrado na figura 4 e descrito aqui.

[0053] O componente identificador de resolução 304 recebe o alarme 400 e, em uma modalidade exemplar, pode determinar se o alarme é indicativo de uma falha de rede acionável. Com mais especificidade, o componente identificador de resolução 304 inclui um componente identificador de falha 402 que analisa o alarme 400 e pode identificar que o alarme 400 representa uma falha de rede acionável e pode ainda identificar um dispositivo com falha ou link (por exemplo, com base no ID do dispositivo e/ou no gráfico de rede 310). Por exemplo, o dispositivo que gerou o alarme 400 (o dispositivo gerador) pode estar operando corretamente; entretanto, um dispositivo de infraestru- tura de rede (o dispositivo com falha) conectado ao dispositivo que gerou o alarme (por exemplo, em forma de link de interface identificado no alarme 400) pode ser com falha. Em um exemplo, a descrição de evento no alarme 400 pode indicar que o dispositivo identificou pelo ID do dispositivo que não está respondendo às solicitações de pulsação sobre um link de rede particular.

[0054] Ainda, o componente identificador de falha 402 pode atribu- ir metadados ao alarme 400 que é indicativo de gravidade de uma falha de rede indicada pelo alarme. Em um exemplo, responsivo ao componente identificador de falha 402, identificar o dispositivo com falha ou link, o componente identificador de falha 402 pode identificar perda de tráfego que é causada por falhas do dispositivo ou do link. Por exemplo, o componente identificador de falha 402 pode atribuir um de uma pluralidade de valores predefinidos ao alarme 400 com base em um volume de perda de tráfego que pode ser causado por um evento representado pelo alarme 400. Assim, o componente identificador de falha 402 pode atribuir um dentre "alto", "médio" ou "baixo" ao alarme 400 para representar a gravidade do alarme de rede. De acordo com um exemplo, esse valor pode ser colocado em uma tabela do histórico de falhas do dispositivo e/ou uma tabela de histórico de falhas de link.

[0055] Além disso, o componente identificador de falha 402 pode atribuir um valor ao alarme 400 que é indicativo de riscos relacionados à redundância no centro de dados 100. Por exemplo, o valor pode indicar se a falha representada pelo alarme 400 causa perda de tráfego dentro de um grupo de redundância. Para eventos onde a redundância é efetiva e a perda de tráfego é mínima, uma opção de resolução de problemas pode ser automaticamente selecionada e uma etapa de depuração pode ser automaticamente realizada para acionar automaticamente o evento de falha representado pelo alarme 400. Valores exemplares podem incluir "redundância bem-sucedida", "falha de redundância", ou "redundância em risco", em que "redundância em risco" pode indicar que o dispositivo com falha ou link tem uma única perna.

[0056] O componente identificador de resolução 304 ainda inclui um componente mapeador 404. Responsivo ao componente identificador de falha 402 que identifica o dispositivo com falha ou link, o componente mapeador 404 pode acessar os dados históricos 308 e mapear as condições de falha (e dados de telemetria associados) indicadas no alarme 400 (ou um grupo de co-alarmes relacionados que são representativos da falha de rede) em pelo menos um sintoma previamente observado representado nos dados históricos 308.

[0057] Com mais particularidade pertencente a uma estrutura exemplar dos dados históricos 308, os dados históricos 308 podem compreender uma pluralidade de tabelas do histórico de falhas dos dispositivos 406-408 e uma pluralidade de tabelas de histórico de falhas de link 410-412, em que cada tabela de histórico de falhas nas tabelas do histórico de falhas dos dispositivos 406-408 é para um respectivo dispositivo no centro de dados 100 e cada tabela de histórico de falhas nas tabelas de histórico de falhas de link 410-412 é para um respectivo link no centro de dados 100. Opcionalmente, os dados históricos 308 podem incluir tabelas de histórico de falhas para dispositi- vos/link em outros centros de dados. Ainda, enquanto os dados históricos 308 são mostrados como sendo centralizados, deve ser entendido que as tabelas de histórico de falhas 406-412 podem ser distribuídas sobre vários dispositivos de armazenamento.

[0058] As primeiras tabelas do histórico de falhas do dispositivo 406 podem incluir informações históricas de falha para um primeiro dispositivo no centro de dados 100. Essas informações de falha podem incluir, mas não é limitado à incluir: 1) dados que são descritivos do primeiro dispositivo, incluindo identidade do primeiro dispositivo, fabricante do primeiro dispositivo, tipo do primeiro dispositivo, modelo do primeiro dispositivo, plataforma do primeiro dispositivo, etc.; 2) disponibilidade do primeiro dispositivo ao longo do tempo (e quantidade de tempo que passou desde uma falha mais recente); 3) dados de monitoramento de rede, como tráfego passando pelo primeiro dispositivo, CPU atual e utilização de memória do primeiro dispositivo, utiliza- ção de CPU do primeiro dispositivo ao longo do tempo, utilização da memória do primeiro dispositivo ao longo do tempo, inúmeras conexões do primeiro dispositivo, etc.; 4) dados indicativos de mudanças de configuração feitas ao primeiro dispositivo; 5) sintomas de falha observados para o primeiro dispositivo, opções de resolução de problemas previamente empregadas para aliviar os sintomas de falha e etapas de depuração previamente realizadas para solucionar os sintomas de falha; 6) mudanças de hardware e software realizadas no primeiro dispositivo; 7) identidades de engenheiros e operadores que historicamente trabalharam no dispositivo; e 8) número de substituições de componente fora de garantia feitas no primeiro dispositivo. As nésimas tabelas do histórico de falhas do dispositivo 408 podem incluir informações análogas. Retornado brevemente à figura 5, o conteúdo de uma tabela de histórico de falhas 500 exemplar é ilustrada

[0059] A primeira tabela de histórico de falhas de link 410 pode incluir dados históricos de falha para um primeiro link no centro de dados. Essas informações de falha podem incluir, mas não se limita à, incluir, 1) dados que são descritivos do primeiro link, incluindo identidade do primeiro link, dispositivos conectados através do primeiro link, fabrica tais dispositivos/links, plataformas de tais dispositivos, etc.; 2) disponibilidade do primeiro link ao longo do tempo (e quantidade de tempo que passou desde uma falha mais recente); 3) dados de monitoramento de rede, como tráfego atual que passa pelo link, tráfego histórico pelo link, etc.; 4) dados indicativos de mudanças de configuração dos dispositivos acoplados através do link; 5) sintomas de falha observados para o link, opções de resolução de problemas previamente empregadas para aliviar os sintomas de falha e etapas de depuração previamente considerados para solucionar os sintomas de falha; 6) mudanças de hardware e software realizadas nos dispositivos conectados através do link, 7) tipo de link, por exemplo, cobre vs. óptica, 8) capacidade de link etc. A mésima tabela de histórico de falhas de link 412 pode incluir informações análogas.

[0060] Assim, o componente mapeador 408 pode receber o alarme 400 e mapear as condições de falha no alarme 400 em pelo menos um sintoma observado para o dispositivo com falha identificada em pelo menos uma das tabelas do histórico de falhas dos dispositivos 406408 ou das tabelas de histórico de falhas de link 410-412. Por exemplo, o componente mapeador 404 pode inicialmente acessar a tabela de histórico de falhas do dispositivo com falha e determinar se as condições de falha mapeiam o sintoma previamente observado de falhas para o dispositivo com falha. O componente mapeador 404 pode, então, expandir a pesquisa aos dispositivos próximos na rede e/ou dispositivos do mesmo tipo e/ou modelo como o dispositivo com falha para identificar o sintoma previamente observado de falhas que mapeiam às condições de falha indicadas no alarme 400. Em um exemplo não limitativo, o componente mapeador 404 pode mapear as condições de falha do alarme 400 aos sintomas previamente observados: 1) "dispositivo inoperante"; e 2) "oscilação de link" para o dispositivo com falha, conforme indicado na tabela de histórico de falhas para o dispositivo com falha.

[0061] O componente identificador de resolução 304 ainda inclui um componente de atribuição do rótulo 414 que identifica as opções de resolução de problemas identificadas nos dados históricos 308 como sendo previamente realizadas para solucionar o sintoma de falha de rede identificado pelo componente mapeador 404. O componente de atribuição do rótulo 414 ainda atribui rótulos às respectivas opções de resolução de problemas, em que um rótulo é indicativo de uma probabilidade que a opção de resolução de problemas mitigará o sintoma de falha de rede.

[0062] Em uma modalidade exemplar, o componente de atribuição do rótulo 414 pode inicialmente pesquisar as tabelas do histórico de falhas do dispositivo do dispositivo com falha (ou uma tabela de histórico de falhas de link para um link de falha) para determinar se quaisquer opções de resolução de problemas e/ou etapas de depuração foram previamente realizadas para os sintomas observados e dispositivo. Quando o dispositivo com falha e/ou link foi submetido em uma quantidade relativamente grande de resolução de problemas e depuração, o componente de atribuição do rótulo 414 pode não precisar realizar ainda a pesquisa sobre os dados históricos 308. Por exemplo, quando a tabela de histórico de falhas para o dispositivo com falha indica que a opção de resolução de problemas para reiniciar o dispositivo previamente (e com alta segurança) aliviou o sintoma de falha exibido pelo dispositivo com falha, o componente de atribuição do rótulo 414 pode emitir a opção de resolução de problemas sem analisar o conteúdo de outras tabelas de histórico de falhas de outros dispositivos. De modo alternativo, quando a tabela de histórico de falhas para o dispositivo com falha indica que o dispositivo com falha não exibiu previamente o sintoma (ou exibiu raramente o sintoma), então, o com-ponente de atribuição do rótulo 414 pode pesquisar tabelas de histórico de falhas de outros dispositivos, como dispositivos próximos na topologia de rede, dispositivos pelo mesmo fabricante, dispositivos do mesmo tipo, etc. Pela pesquisa das tabelas de histórico de falhas 406412 nos dados históricos 308, o componente de atribuição do rótulo 414 pode identificar opções de resolução de problemas e etapas de depuração previamente bem-sucedidas, bem como respectivos rótulos de segurança, para solucionar o sintoma de falha.

[0063] O componente identificador de resolução 304 pode ainda compreender um componente de saída 416 que emite as opções de resolução de problemas, etapas de depuração e rótulos correspondentes. Em um exemplo, o componente de saída 416 pode emitir tais op- ções de resolução de problemas, etapas de depuração e rótulos a uma tela do dispositivo de computação 124 empregados pelo operador 126. Em outro exemplo, o componente de saída 416 pode transmitir as opções de resolução de problemas, etapas de depuração e rótulos a um diferente dispositivo de computação. Ainda em outro exemplo, o componente de saída 416 pode fazer com que uma opção de resolução de problemas seja automaticamente selecionada e uma etapa de depuração seja automaticamente realizada sem intervenção do operador.

[0064] Além de emitir as opções de resolução de problemas e eta pas de depuração, o componente de saída 416 pode também emitir (para um dispositivo com falha ou link), uma tabela de sumário de histórico de falhas para apresentação ao operador 126. Isso pode fornecer ao operador 126 o contexto histórico pertencente às falhas prévias do dispositivo ou link. Por exemplo, o identificador de resolução pode manter uma tabela de sumário de histórico de falhas para dispositivos e/ou links no centro de dados 100, em que uma tabela de sumário de histórico de falhas exemplar pode incluir, mas não se limita à: 1) um nome do dispositivo ou link; 2) uma indicação como à taxa de falha do dispositivo ou link com relação à outros dispositivos ou links (por exemplo, uma indicação para se o dispositivo ou link é um dispositivo problemático top-k); 3) mudanças recentes feitas ao dispositivo ou link (por exemplo, hardware, software, e/ou mudanças de configuração); 4) uma quantidade de tempo desde a última vez que o dispositivo ou link falhou; e 5) opções recentes de resolução de problemas selecionadas e/ou operadores que realizaram a resolução de problemas.

[0065] Agora com referência à figura 6, uma interface gráfica do usuário 600 exemplar que pode ser apresentada na tela do dispositivo de computação 124 empregada pelo operador 126 é ilustrada. A interface gráfica do usuário 600 pode ser gerada pelo componente identificador de resolução 304. A interface gráfica do usuário inclui um campo 602 que apresenta as seguintes informações ao operador 126 pertencentes ao dispositivo com falha identificado pelo componente identificador de falha 402 ou um dispositivo, caso contrário, de interesse ao operador 126: 1) o nome do dispositivo com falha; 2) o modelo do dispositivo com falha; 3) uma identidade do centro de dados que inclui o dispositivo com falha; 4) uma propriedade do dispositivo com falha; 5) um tipo do dispositivo com falha; 6) mudanças recentes de hardware e mudanças recentes de software; e 7) links aos tickets que descrevem essas mudanças em mais detalhes.

[0066] A interface gráfica do usuário 600 adicionalmente inclui um campo 604 que ilustra sintomas previamente observados que ma- peiam os conteúdos de um alarme recebido (por exemplo, o alarme 400). Conforme mostrado na figura 6, sintomas exemplares podem incluir "link flap" e "dispositivo inoperante." O campo 604 também inclui, para cada sintoma observado, uma pluralidade de opções potenciais de resolução de problemas. Por exemplo, para o sistema do "dispositivo inoperante", as seguintes opções de resolução de problemas são exibidas no campo 604: 1) "verificar cabo"; 2) "verificar fonte de alimentação"; e 3) "verificar cartão de rede". As opções de resolução de problemas têm respectivos rótulos atribuídos a elas que são indicativas das probabilidades que as respectivas opções de resolução de problemas aliviarão o sintoma de falha correspondente. Por exemplo, a opção "verificar cabo" de resolução de problemas recebe um rótulo que indica que há 60% de probabilidade que a resolução de problemas do "dispositivo inoperante" de sintoma de falha através da utilização de pelo menos uma etapa de depuração correspondente à tal opção de resolução de problemas aliviará o problema. De modo similar, a opção "verificar fonte de alimentação" de resolução de problemas pode receber um rótulo que indica que há 25% de probabilidade que realizar a(s) etapa(s) de depuração correspondentes à tal opção de resolução de problemas resultará no alívio do sintoma de falha.

[0067] Conforme determinado, cada opção de resolução de pro blemas tem pelo menos uma etapa de depuração correspondente à ela. Por exemplo, a opção de resolução de problemas "verificar cabo" tem duas etapas de depuração correspondentes a ela (e ilustradas na interface gráfica do usuário 600): 1) "reinstalar cabo"; e 2) "limpar cabo". Essas etapas de depuração são também rótulos atribuídos que são indicativos das respectivas probabilidades que as etapas de resolução solucionarão o sintoma de falha (quando a opção de resolução de problemas principal for selecionada).

[0068] Adicionalmente, algumas etapas de depuração podem ter instruções adicionais atribuídas a elas para ajudar o operador 126 ao realizar as etapas de depuração. Por exemplo, para a etapa de depuração "substituir cartão de rede", instruções adicionais podem ser apresentadas ao operador 126 responsivo ao operador selecionando um ícone gráfico 606 na interface gráfica do usuário 600 que está posicionada adjacente à etapa de resolução previamente mencionada. Isso pode resultar em uma janela pop-up 607 (ou uma janela separa-da) para ser exibida fornecendo o operador 126 com informações adicionais sobre substituir o cartão de rede. As informações adicionais, em uma modalidade exemplar, podem ter hyperlinks atribuídos à elas, em que a seleção de um hyperlink pelo operador 126 pode direcionar o operador às informações adicionais.

[0069] A interface gráfica do usuário 600 pode ainda incluir vários campos 608-612 que podem incluir dados gráficos (por exemplo, gráficos) que são representativos de vários parâmetros operacionais do dispositivo com falha. Por exemplo, o campo 608 pode descrever um gráfico que ilustra o volume do tráfego que passa pelo dispositivo com falha por um intervalo de tempo particular, o campo 610 pode descrever um gráfico que é representante da disponibilidade do dispositivo com falha sobre um intervalo de tempo e o campo 612 pode descrever um gráfico que ilustra pontos no tempo quando o dispositivo com falha foi observado falhar.

[0070] A interface gráfica do usuário 600 pode também incluir re cursos que facilitam o recebimento do feedback do operador 126. Por exemplo, um botão 614 pode ser incluído na interface gráfica do usuário 600 que, quando selecionado, faz com que um intervalo 616 seja apresentado ao operador 126, onde o intervalo 126 inclui vários campos que podem ser utilizados pelo operador 126. Isso permite que o operador 126 identifique os sintomas observados ao solucionar os problemas do dispositivo com falha, uma opção de resolução de pro-blemas empregada pelo operador 126 ao solucionar problemas do dispositivo com falha e etapas de depuração realizadas pelo operador 126 ao solucionar problemas do dispositivo com falha.

[0071] A interface gráfica do usuário 600 pode também incluir um objeto gráfico 618 que é representante de uma vista topológica de uma porção do centro de dados 100, em que o dispositivo identificado no campo 602 pode ser representado como um ícone gráfico central 620 no objeto gráfico 618 e dispositivos um salto do dispositivo identificado no campo 602 pode ser representado por ícones gráficos 622-634 que envolvem o ícone gráfico central 620 (por exemplo, com conexões entre ícones gráficos que representam links entre eles). Além disso, os ícones gráficos 620-634 podem ser codificados por cor para indicar os tipos dos respectivos dispositivos representados pelos ícones gráficos 620-634. Em outro exemplo, os ícones gráficos 620-634 no objeto gráfico 618 podem ter formas respectivas que são indicativas dos tipos dos dispositivos representados pelos ícones gráficos. Por exemplo, um ícone gráfico formado como um quadrado pode representar um roteador central, um objeto gráfico formado como um círculo pode representar uma VPN, etc. Os ícones gráficos 620-634 no objeto gráfico 618 podem ser selecionáveis, em que a seleção de um ícone gráfico faz com que as informações sobre o dispositivo representado pelo ícone gráfico sejam estabelecidas no campo 602 (e outros campos na interface gráfica do usuário 600). Ainda em outro exemplo, o formato de um ícone gráfico pode representar um tipo de dispositivo representado pelo ícone e cor do ícone gráfico pode representar um fabricante do dispositivo. Outras variantes são também contempladas.

[0072] Agora com referência à figura 7, uma descrição exemplar do componente de priorização de evento 312 é ilustrada. O componente de priorização de evento 312 pode receber alarmes gerados pelos dispositivos no centro de dados 100. O componente de priorização de evento 312 inclui um componente de correlação de alarme 700, em que o componente de correlação de alarme 700 correlaciona os alarmes em respectivos grupos, em que os grupos são representantes das respectivas falhas de rede. Em uma modalidade exemplar, o componente de correlação de alarme 700, sob recebimento de um alarme, pode executar uma pesquisa nos dados históricos 308 para identificar alarmes recentes que podem ser relacionados ao alarme recebido. Por exemplo, o componente de correlação de alarme 700 pode pesquisar os dados históricos 308 para alarmes prévios gerados pelo mesmo dispositivo e/ou para a mesma interface (por exemplo, por algum intervalo de tempo histórico limiar, como a maioria dos 30 minutos recentes). Em uma modalidade exemplar, o componente de correlação de alarme 700 pode agrupar o alarme recebido com outros alarmes gerados pelo mesmo dispositivo e/ou pata a mesma interface dentro do intervalo de tempo limiar. Em outro exemplo, o componente gerador de alarme 700 pode agrupar o alarme recebido com pelo menos um alarme gerado por dispositivos próximos na topologia de rede (onde o componente de correlação de alarme 700 identifica os dispositivos próximos através da análise do gráfico de rede 310). Por exemplo, o componente de correlação de alarme 700 pode agrupar o alarme com alarmes gerados nos dispositivos próximos que são de 1 a 2 saltos a montante ou a jusante do dispositivo com falha na topologia de rede hierárquica e que foi gerado dentro de uma quantidade limiar de tempo desde o período que o alarme recebido foi gerado. Além disso, o componente de correlação de alarme 700 pode agrupar o alarme recebido com pelo menos um outro alarme gerado por um ou mais dispositivos em um grupo de redundância de rede (com o dispositivo que gerou o alarme) que pode ser correlacionado (por exemplo, ilustrando um problema com um protocolo de failover). Pode ser determinado que um grupo de alarmes pode ser representante de uma falha de rede singular e diferentes grupos de alarmes podem representar diferentes falhas de rede.

[0073] Com mais detalhes referentes à operação do componente de correlação de alarme 700, para cada alarme recebido, o componente de correlação de alarme 700 pode tentar combinar o alarme com um evento de prioridade ou uma gestão de incidências (se presente). Por exemplo, o componente de correlação de alarme 700 pode realizar a combinação em uma variedade de campos: 1) dispositivo de rede e/ou nome da interface. Um nome do dispositivo é tipicamente codificado como aa-bb-cc-dd, onde aa é o centro de dados, bb é o nome da plataforma, cc é o nome do serviço ou aplicativo hospedado e dd é um número lógico relacionado à implementação do dispositivo que gerou o alarme; 2) o tipo do dispositivo, 3) uma mensagem de erro e 4) período de notificação de evento. Para comparar os campos com base na sequência (nome do dispositivo e mensagem de erro), o componente de correlação de alarme 700 pode utilizar uma variedade de algoritmos de combinação de sequência (por exemplo, editar distância, combinação padrão Aho-Corasick, distância Levenshtein, etc.). Isso permite a combinação de um alarme com possíveis combinações no passado recente (com base no ajuste de um limiar no período de notificação). Segundo, o componente de correlação de alarme 700 pode realizar a combinação com base nas falhas que ocorrem nos dispositivos próximos. Vizinhos são determinados por meio da análise do gráfico de rede 310 com base na conectividade do nível de link. Terceiro, o componente de correlação de alarme 700 pode realizar uma combinação com base no tipo de dispositivo de rede, por exemplo, um bug de con-figuração pelos equilibradores de carga no mesmo centro de dados ou por múltiplos centro de dados resultantes em uma grande falha correlacionada.

[0074] O componente de priorização de evento 312 também inclui um componente classificador 702 que classifica os agrupamentos de alarmes (eventos de falha) para resolução de problemas. O componente classificador 702 pode ser configurado para priorizar eventos para reduzir o impacto negativo no centro de dados 100 e/ou clientes do centro de dados 100. Por exemplo, o componente classificador 702 pode priorizar os eventos com base em um dispositivo com falha estando próximo a um topo de uma hierarquia de rede, pois tais dispositivos impõem um risco relativamente alto de interrupção de serviço. Em outro exemplo, o componente classificador 702 pode priorizar eventos como uma função de inúmeras propriedades que podem ser impactadas devido à falha do dispositivo. Ainda, o impacto de uma única propriedade pode fazer com que o componente classificador 702 atribua uma prioridade relativamente alta a um evento. Em outro exemplo, o componente classificador 702 pode priorizar eventos com base na quantidade de tráfego carregada por um dispositivo com falha. Ainda em outro exemplo, o componente classificador 702 pode priorizar eventos com base em um impacto no tráfego através do centro de dados 100, por exemplo, falha do dispositivo pode causar perda signi- ficante de tráfego. Ainda em outro exemplo, o componente classifica- dor 702 pode priorizar eventos com base em uma falha de redundância potencial. Por exemplo, eventos de falha não mascarados por redundância de intradispositivo ou interdispositivo podem ser classificados relativamente altos. Finalmente, o componente classificador 702 pode priorizar eventos de falha causados por ou que impactam um dispositivo de perna única. Por exemplo, eventos pertencentes a onde failover foi bem-sucedido, mas que podem impor um perigo de causar uma falha de redundância, podem ser classificados relativamente altos. A saída do componente de priorização de evento 312 é, então, uma lista priorizada de eventos, de modo que o operador 126 possa priorizar falhas de rede para reduzir seu impacto em aplicativos e serviços hospedados.

[0075] As figuras de 8 a 10 ilustram metodologias exemplares refe rentes à solução de falhas de rede. Enquanto as metodologias são mostradas e descritas como sendo uma série de ações que são realizadas em uma sequência, deve ser entendido e observado que as metodologias não são limitadas pela ordem da sequência. Por exemplo, algumas ações podem ocorrer em uma ordem diferente do que à descrita aqui. Além disso, uma ação pode ocorrer simultaneamente com outra ação. Ainda, em alguns casos, nem todas as ações podem ser necessárias para implementar uma metodologia descrita aqui.

[0076] Além disso, as ações descritas aqui podem ser instruções executáveis por computador que podem ser implementadas por um ou mais processadores e/ou armazenadas em um meio ou meios legíveis por computador. As instruções executáveis por computador podem incluir uma rotina, uma sub-rotina, programas, uma discussão de execução, e/ou similar. Ainda, resultados de ações das metodologias podem ser armazenados em um meio legível por computador, exibido em um dispositivo de exibição, e/ou similar.

[0077] Agora com referência à figura 8, um fluxograma que ilustra uma metodologia exemplar 800 para emitir uma pluralidade de opções de resolução de problemas para uso quando a resolução de problemas de uma falha de rede é ilustrada. A metodologia 800 começa em 802 e em 804 um alarme que é indicativo de uma falha de rede é recebido. O alarme é gerado por um dispositivo em um centro de dados, que pode ser um dispositivo de computação ou um dispositivo de in- fraestrutura de rede. O alarme pode identificar o dispositivo que acredita estar com falha, o dispositivo que gerou o alarme, uma interface no dispositivo com falha que é afetada, uma marca temporal que indica quando o alarme foi gerado, entre outros dados.

[0078] Em 806, responsivo ao receber o alarme, um dispositivo com falha e/ou link de falha é identificado. O dispositivo com falha pode ser o dispositivo que gerou o alarme ou um dispositivo em comunicação com o dispositivo que gerou o alarme. Deve ser entendido que quando o dispositivo com falha gera o alarme, ele não necessariamente significa que todo o dispositivo ficou inoperante. Em vez disso, o alarme poderia indicar que um dos links do dispositivo ficou inoperante, a utilização da CPU excedeu um limiar predeterminado, a utilização da memória excedeu um limiar predeterminado, etc. Em 808, respon- sivo à identificação do dispositivo com falha, as condições de falha indicadas no alarme são mapeadas para sintomas de falha historicamente observados, em que os sintomas de falha podem ter sido previamente observados como sendo exibidos pelo dispositivo com falha, por dispositivos relacionados ao dispositivo com falha, etc. Conforme indicado acima, as tabelas de histórico de falhas podem ser mantidas para respectivos dispositivos de rede, que facilitam o mapeamento das condições de falha no alarme aos possíveis sintomas de falha.

[0079] Em 810, para um sintoma de falha identificado, uma plurali dade de opções de resolução de problemas é identificada, em que as opções de resolução de problemas são indicativas das resoluções po- tenciais para tratar o sintoma de falha. Ainda, as opções de resolução de problemas podem ter os respectivos rótulos atribuídos a elas que são indicativos de probabilidades das opções de resolução de problemas que tratam o sintoma de falha. Os rótulos podem ser probabilidades ou rótulos mais discretos (por exemplo, alta segurança, média segurança, baixa segurança etc.). Em 812, a pluralidade de opções de resolução de problemas e seus respectivos rótulos são saídas para uso por um operador para solucionar a falha de rede. Conforme observado acima, os rótulos podem ser indicativos de seguranças que as opções de resolução de problemas, quando utilizadas pelo operador, mitigarão respectivamente a falha de rede. A metodologia 800 conclui- se em 814.

[0080] Agora com referência à figura 9, uma metodologia exemplar 900 que facilita o agrupamento de alarmes para identificar uma falha de rede e priorizar as falhas de rede é ilustrada. A metodologia 900 começa em 902 e em 904 um alarme é recebido sendo indicativo de uma falha de rede. Em 906, responsivo ao recebimento do alarme, uma consulta é emitida a um banco de dados. A consulta é com base em um período de geração do alarme, um tipo de dispositivo que emitiu o alarme e uma localização do dispositivo em uma hierarquia da rede. Em 908, responsivo à emissão da consulta, resultados são recebidos com base na consulta, os resultados compreendendo um segundo alarme. Em 910, o alarme é agrupado com o segundo alarme e em 912, uma lista classificada de alarmes é emitida com base no agrupamento do alarme com o segundo alarme. A metodologia 900 conclui-se em 914.

[0081] Agora com referência à figura 10, uma metodologia exem plar 1000 para receber feedback como opções de resolução de problemas e/ou etapas de depuração e atualizar probabilidades correspondentes ás opções de resolução de problemas e/ou etapas de depu- ração com base no feedback é ilustrada. A metodologia 1000 inicia em 1002 e em 1004 o feedback de um operador é recebido. O feedback pode identificar 1) um dispositivo de rede ou link que falhou (por exemplo, incluindo um tipo de dispositivo, uma plataforma do dispositivo, uma localização do dispositivo em uma topografia de rede, etc.); 2) um sintoma da falha; 3) uma identidade de uma opção de resolução de problemas considerada pelo operador para mitigar a falha; 4) uma indicação de se a opção de resolução de problemas mitigou com êxito falha; 5) uma identidade de uma etapa de depuração realizada pelo operador para mitigar a falha; e 6) uma indicação de se a etapa de depuração mitigou com êxito a falha.

[0082] Em 1006, dados históricos que são descritivos de falhas de rede são atualizados com base no feedback. Com mais particularidade, uma tabela do histórico de falhas do dispositivo e/ou uma tabela de histórico de falhas de link podem ser atualizadas com base no feedback recebido. Em 1008, subsequente aos dados históricos sendo atualizados, um alarme é recebido e em 1010 os dados históricos são consultados com base no alarme. Por exemplo, os dados históricos podem ser consultados por várias dimensões (por exemplo, ID do dispositivo, tipo de dispositivo, plataforma de dispositivo, ID do link, etc.). Em 1012, as probabilidades para opções de resolução de problemas e/ou etapas de depuração que podem potencialmente mitigar uma falha de rede indicada pelo alarme são computadas (por exemplo, em tempo real ou off-line). Tais probabilidades podem ser com base no feedback do operador, de modo que as probabilidades sejam refinadas ao longo do tempo conforme o feedback adicional é recebido. Além disso, se o operador deveria ter considerado uma opção de resolução de problemas não previamente empregada em conexão com o disposi-tivo, os dados históricos e/ou as probabilidades podem ser atualizados com essa nova opção de resolução de problemas, que pode ser poste- riormente emersa quando um alarme similar é gerado. A metodologia 1000 conclui-se em 1014.

[0083] Agora com referência à figura 11, uma ilustração de alto nível de um dispositivo de computação 1100 exemplar que pode ser utilizado de acordo com os sistemas e metodologias aqui revelados aqui é ilustrada. Por exemplo, o dispositivo de computação 1100 pode ser utilizado em um sistema que suporta emitir as opções de resolução de problemas e etapas de depuração para tratar os sintomas de falha em um centro de dados. Em forma de outro exemplo, o dispositivo de computação 1100 pode ser utilizado em um sistema que suporta a pri- orização das falhas de rede para um operador. O dispositivo de computação 1100 inclui pelo menos um processador 1102 que executa as instruções que são armazenadas em uma memória 1104. As instruções podem ser, por exemplo, instruções para implementar a funcionalidade descrita como sendo realizada por um ou mais componentes discutidos acima ou instruções para implementar um ou mais dos métodos descritos acima. O processador 1 102 pode acessar uma memó-ria 1104 em forma de um barramento do sistema 1106. Além de armazenar as instruções executáveis, a memória 1104 pode também armazenar tabelas de histórico de falhas, um gráfico de rede, etc.

[0084] O dispositivo de computação 1100 adicionalmente inclui um armazenamento de dados 1108 que é acessível pelo processador 1102 em forma de barramento do sistema 1106. O armazenamento de dados 1108 pode incluir instruções executáveis, tabelas de histórico de falhas, etc. O dispositivo de computação 1100 também inclui uma interface de entrada 1110 que permite que os dispositivos externos se comuniquem com o dispositivo de computação 1100. Por exemplo, a interface de entrada 1110 pode ser utilizada para receber instruções de um dispositivo de computador externo, de um usuário, etc. O dispo-sitivo de computação 1100 também inclui uma interface de saída 1112 que conecta o dispositivo de computação 1100 com um ou mais dispositivo externos. Por exemplo, o dispositivo de computação 1100 pode exibir texto, imagens, etc. em forma de interface de saída 1112.

[0085] Contempla-se que os dispositivos externos que se comuni cam com o dispositivo de computação 1100 através da interface de entrada 1110 e da interface de saída 1112 podem ser incluídos em um ambiente que fornece substancialmente qualquer tipo de interface do usuário com a qual um usuário pode interagir. Exemplos de tipos de interface do usuário incluem interfaces gráfica do usuário, interfaces naturais do usuário e assim por diante. Por exemplo, uma interface gráfica do usuário pode aceitar a entrada de um usuário que emprega dispositivo(s) de entrada como um teclado, mouse, controle remoto, ou similar e fornecem a saída em um dispositivo de saída como uma tela. Ainda, uma interface natural do usuário pode habilitar um usuário para interagir com o dispositivo de computação 1100 em uma forma livre de restrições impostas pelo dispositivo de entrada como teclados, mouses, controles remotos e similares. Ainda, uma interface natural do usuário pode depender do reconhecimento de fala, toque e reconhecimento de estilo, reconhecimento de gesto na tela e adjacente à tela, gestos de ar, cabeça e rastreamento dos olhos, voz e fala, visão, toque, gestos, inteligência de máquina e assim por diante.

[0086] Adicionalmente, enquanto ilustrado como um único sistema, deve ser entendido que o dispositivo de computação 1100 pode ser um sistema distribuído. Assim, por exemplo, vários dispositivos podem estar em comunicação em forma de uma conexão de rede e podem realizar tarefas coletivamente descritas como sendo realizadas pelo dispositivo de computação 900.

[0087] Várias funções descritas aqui podem ser implementadas em hardware, software, ou qualquer combinação dessas. Se implementadas em software, as funções podem ser armazenadas ou transmitidas como uma ou mais instruções ou código em um meio legível por computador. Meios legível por computador incluem meio de armazenamento legível por computador. Um meio de armazenamento legível por computador pode ser qualquer meio de armazenamento disponível que pode ser acessado por um computador. Em forma de exemplo e não limitação, tal meio de armazenamento legível por computador pode compreender RAM, ROM, EEPROM, CD- ROM ou outro armazenamento de disco óptico, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser utilizado para carregar ou armazenar o código de programa desejado na forma de instruções ou estruturas de dados e que podem ser acessados por um computador. Disco e disco, conforme aqui utilizado, incluem disco compacto (CD), disco a laser, disco óptico, disco versátil digital (DVD), disquete e disco Blu-ray (BD), onde os discos geralmente reproduzem os dados magneticamente e os discos geralmente reproduzem os dados opti- camente com lasers. Ainda, um sinal propagado não é incluído dentro do escopo do meio de armazenamento legível por computador. Meios legíveis por computador também incluem meio de comunicação incluindo qualquer meio que facilita a transferência de um programa de computador de um lugar para outro. Uma conexão, por exemplo, pode ser um meio de comunicação. Por exemplo, se o software for transmitido de um website, servidor, ou outra fonte remota utilizando um cabo coaxial, cabo de fibra óptica, par torcido, linha de assinante digital (DSL), ou tecnologias sem fio como infravermelho, rádio e micro-onda, então, o cabo coaxial, o cabo de fibra óptica, o par torcido, o DSL, ou as tecnologias sem fio como infravermelho, rádio e micro-onda estão incluídas na definição do meio de comunicação. As combinações acima também devem ser incluídas dentro do escopo do meio legível por computador.

[0088] De modo alternativo, ou adicional, a funcionalidade aqui descrita pode ser percebida, pelo menos parcialmente, por um ou mais componentes lógicos de hardware. Por exemplo e sem limitação, tipos ilustrativos de componentes lógicos de hardware que podem ser utilizados incluem Matrizes de portas de campos programáveis (FPGAs, Field-programmable Gate Arrays), Circuitos Integrados Específicos de Programa (ASICs, Program-specific Integrated Circuits), Produtos Padrão Específicos de Programa (ASSPs, Program-specific Standard Products), Sistemas de sistema-em-um-chip (SOCs, system-on-a- chip), Dispositivos Lógicos Programáveis Complexos (CPLDs, Complex Programmable Logic Devices), etc.

[0089] O que foi descrito acima inclui exemplos de uma ou mais mo dalidades. Certamente, não é possível descrever cada modificação e alteração concebível dos dispositivos ou metodologias acima para finalidades de descrição dos aspectos previamente mencionados, mas um técnico no assunto pode reconhecer que muitas modificações e permutações adicionais de vários aspectos são possíveis. Consequentemente, os aspectos descritos são destinados à abranger todas essas alterações, modificações e variações que ficam dentro do espírito e escopo das reivindicações anexas. Além disso, à extensão que o termo "inclui" é utilizada em qualquer descrição de detalhes ou reivindicações, tal termo deve ser destinado para ser inclusivo em uma forma similar ao termo "compre-endendo" como "compreendendo" é interpretado quando empregado como uma palavra de transição em uma reivindicação.

Claims (8)

1. Método implementado por computador caracterizado pelo fato de que compreende: receber um alarme, o alarme compreendendo condições de falha que são indicativas de uma falha de rede em um centro de dados, o alarme gerado por um dispositivo de infraestrutura de rede, sendo um dentre um interruptor, um roteador, um re-roteador, um gateway, um hub, ou uma ponte; responsivo à recepção do alarme, acessar dados históricos, os dados históricos compreendendo um sintoma de falha da falha de rede e opções de resolução de problemas anteriormente realizadas para mitigar a falha de rede; mapear as condições de falha do alarme para o sintoma de falha nos dados históricos; responsivo à mapear as condições de falha do alarme para o sintoma de falha, identificar as opções de resolução de problemas; atribuir os respectivos rótulos às opções de resolução de problemas, os rótulos indicativos das respectivas probabilidades de que as opções de solução de problemas mitiguem o sintoma de falha; e emitir a pluralidade de opções de resolução de problemas e seus respectivos rótulos; em que o método ainda compreende, em resposta ao recebimento do alarme, a identificação de um dispositivo com falha que causa a falha da rede, em que o mapeamento das condições de falha do alarme para o sintoma de falha nos dados históricos é baseado na identificação do dispositivo com falha, e em que a identificação das opções de resolução de problemas é baseada na identificação do dispositivo com falha.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: receber feedback de um operador que o sintoma de falha foi mitigado e que uma primeira opção de resolução de problemas nas opções de resolução de problemas foi empregada para mitigar o sintoma de falha; e atualizar os dados históricos com base no feedback.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os dados históricos compreendem uma tabela do histórico de falhas do dispositivo para o dispositivo com falha, a tabela do histórico de falhas do dispositivo compreende o sintoma de falhas previamente exibido pelo dispositivo com falha, o sintoma de falha está incluído no sintoma de falhas previamente exibido pelo dispositivo com falha, e em que a tabela de histórico de falhas ainda compreende as opções de resolução de problemas para o sintoma de falhas previamente exibido pelo dispositivo com falha.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: receber uma seleção de uma opção de resolução de problemas a partir das opções de resolução de problemas; e responsivo a receber a seleção da opção de resolução de problemas, exibir uma etapa de depuração, a etapa de depuração compreendendo uma instrução para solucionar a falha de rede.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: responsivo ao emitir a pluralidade de opções de resolução de problemas e seus respectivos rótulos, transmitir um sinal à um a um dispositivo no centro de dados, o sinal fazendo com que uma opção de resolução de problemas nas opções de resolução de problemas seja realizada sem intervenção do operador.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende calcular as respectivas probabili- dades com base em inúmeras vezes que as opções de resolução de problemas foram indicadas como sendo tiradas nos dados históricos e inúmeras vezes que as operações de resolução de problemas foram indicadas como solucionar com êxito as respectivas falhas de rede.

7. Sistema de resolução (122) que facilita a resolução das falhas de rede no centro de dados, o sistema de resolução caracterizado pelo fato de que compreende: um processador (1102); e uma memória (1104) que compreende uma pluralidade de componentes que é executada pelo processador, a pluralidade de componentes compreendendo: um componente receptor de alarme (302) que recebe um alarme, o alarme compreendendo condições de falha que são indicativas de uma falha de rede no centro de dados, o alarme gerado por um dispositivo de infraestrutura de rede, o dispositivo de infraestrutura de rede sendo um dentre um interruptor, um roteador, um re-roteador, um gateway, um hub, ou uma ponte; e um componente identificador de resolução (304) que, res- ponsivo ao componente receptor de alarme que recebe o alarme, acessa dados históricos, os dados históricos compreendendo um sintoma de falha da falha de rede e opções de resolução de problemas anteriormente realizadas para mitigar a falha de rede, mapeia as condições de falha do alarme para o sintoma de falha nos dados históricos para selecionar uma das opções de resolução de problemas; e emite as opções de resolução de problemas selecionadas para resolver a falha de rede, as opções de resolução de problemas selecionadas tendo rótulos respectivamente atribuídos às mesmas, compreendendo probabilidades de que as opções de solução de problemas selecionadas, quando realizadas por um operador do centro de dados, resolverão a falha de rede; em que o componente identificador de resolução (304), em resposta ao componente receptor de alarme (302) que recebe o alarme, identifica um dispositivo com falha que causa a falha de rede, e em que o mapeamento das condições de falha do alarme para o sintoma de falha no histórico os dados são baseados na identificação do dispositivo com falha, e em que a seleção das opções de resolução de problemas é baseada na identificação do dispositivo com falha.

8. Sistema de resolução, de acordo com a reivindicação 7, caracterizado pelo fato de que o componente identificador de resolução (304) determina os rótulos com base no feedback do operador pertencente às opções de resolução de problemas.

Images