BPF - Troubleshooting

Prévia do material em texto

Política de privacidade Sobre Wiki BPF Termo de responsabilidade
Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP
Esta página foi modificada pela última vez em 8 de janeiro de 2020, às 22h10min
Índice [ocultar] 
1 Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP
2 Introdução
3 Afinal de contas, o que é o troubleshooting?
4 Roteiro recomendado para um troubleshooting mais efetivo
4.1 Etapas da fase "Problema"
4.1.1 Defina o problema
4.2 Etapas da fase "Diagnóstico"
4.2.1 Colete informações
4.2.2 Analise as informações coletadas
4.2.3 Elimine hipóteses
4.3 Etapas da fase "Solução"
4.3.1 Proponha hipóteses
4.3.2 Testar hipóteses
4.3.3 Problema Resolvido
5 Como prestar um suporte técnico de alto nível para a sua empresa
5.1 Conheça bem o seu próprio ambiente
5.2 Conheça as tecnologias utilizadas na sua infraestrutura
5.3 Conheça os padrões de configuração utilizados pelas áreas de engenharia e operação
5.4 Conheça os estados operacionais desejados para as áreas funcionais da sua infraestrutura
5.5 Domine as boas práticas de suporte a problemas na rede
5.6 Antecipe problemas com processos consistentes de prevenção de falhas e recuperação de desastres
6 Método seguro: como refinar as suas habilidades de suporte à problemas em redes
6.1 De Cima a Baixo (Top-down)
6.2 De Baixo para Cima (Bottom-Up)
6.3 Dividir para Conquistar (Divide and Conquer)
6.4 Siga o Caminho (Follow-the-Path)
6.5 Encontrar Diferenças (Spot the Diferences)
6.6 Mover o Problema de Lugar (Move The Problem)
7 É melhor termos um método seguro para trabalhar do que inventar moda na hora de resolver um problema na rede!
8 Fique atento quanto a situações mais complicadas
9 Quando a "casa cai'
10 Conclusão do artigo
Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP
Autor: Leonardo Furtado
Introdução
Este artigo toca num tema que frequentemente visita os bate-papos com amigos, nos eventos, e em grupos de discussão. Muitas das vezes o profissional está precisando
resolver algum tipo de problema e não faz a menor idéia por onde começar.
Não mais! Este artigo de nossa Wiki foi elaborado especialmente para você, profissional que sente dificuldades ao tentar resolver problemas na sua rede! Espero que curta a
abordagem e didática aqui empregados!
Afinal de contas, o que é o troubleshooting?
Troubleshooting é o conjunto de ações orientadas à resolução de problemas na infraestrutura de redes, computadores, sistemas ou serviços correlatos. O seu único propósito é
o de sanar o problema, restaurando assim o bom funcionamento do equipamento, rede, sistema ou serviço afetado, preferencialmente em tempo hábil e sem causar distúrbios
adicionais para os usuários no decorrer do processo.
O troubleshooting consiste de ações de definição, análise, diagnóstico e reparo, e fazendo isto devidamente com auxílio de processos, ferramentas e boas práticas, sendo
estas o foco deste artigo.
Troubleshooting de redes: a "arte suave"!
Roteiro recomendado para um troubleshooting mais efetivo
Todo o processo é dividido em três fases primárias, denominadas Problema, Diagnóstico e Solução. Cada uma destas fases possui etapas, e cada uma destas etapas contém
um conjunto de ações específicas para o tratamento e condução do suporte ao problema. O que será mostrado a seguir é uma expansão dos conceitos de cada fase.
Problema
Nesta fase, o principal objetivo é a definição do problema. As redes IP podem ser um tanto complexas em alguns ambientes, pois frequentemente empregam tecnologias em
configurações mais sofisticadas e que agregam complexidade e dificuldades de entendimento para o cenário de suporte a problemas. Como a dinâmica para surgimento de
problemas envolve diversas possibilidades para cada caso, fica impraticável por muitas vezes corrigir um problema sem causar outros problemas, ou resolver o problema em
tempo hábil. Uma coisa é certa: uma hora ou outra o problema será resolvido!
As questões aqui na verdade são: a) você conseguirá resolver o problema em tempo hábil, buscando minimizar os impactos para o negócio? b) você conseguirá resolver
o problema sem causar distúrbios adicionais (graves ou não) para o ambiente?
Isto tudo pode ser evitado em grande parte através da correta definição do problema.
Diagnóstico
Tão importante quanto definir o problema é saber diagnosticá-lo o mais precisamente possível. A proposta desta fase é conduzir diagnósticos efetivos alimentados pelas
conclusões obtidas na fase "Problema" supracitada. Uma vez que você for capaz de compreender o problema com clareza (ou seja, defini-lo), você estará apto para iniciar o
trabalho de coleta de informações e análises correspondentes com o intuito de identificar a causa-raiz e de completar o seu diagnóstico com maior clareza.
A qualidade da definição do problema impactará positiva ou negativamente o seu diagnóstico. Por onde começar o seu diagnóstico? Qual equipamento você acessará primeiro
para coletar informações? Quais áreas funcionais da configuração e operação daquele equipamento deverão ser verificadas em primeira e segunda instâncias? Quais deverão
ser as suas expectativas de comparação, contraste e constatação?
Solução
Bastante óbvio... certo? Esta fase promoverá a correção do problema que: a) foi definido/compreendido corretamente, b) foi analisado e diagnosticado corretamente.
Na verdade, é mais que isso. Bem mais que isso. É resolver o problema com qualidade de ações, atitude e responsabilidade.
Esta fase constitui na correção do problema de forma mais cirúrgica, e não "matar uma barata com bala de canhão" como ocorre em muitos casos. Será nesta fase que você
determinará o roteiro de correção do problema, as implicações e riscos associados com as manobras corretivas, ou seja, se a manobra de correção apresenta riscos de
indisponibilidades parciais ou totais em caráter temporário, isto é, se haverá mais impacto ou não no ambiente para resolver aquele problema. E será nesta fase que você
validará a necessidade de abertura de GMUD em caráter emergencial, se deverá haver um plano de comunicação com gestores e clientes, definir o plano de validação e
rollback, dentre outras iniciativas.
Fases do processo de troubleshooting: Definição, Diagnóstico, Solução
Etapas da fase "Problema"
Verifiquemos o roteiro esmiuçado e recomendado da fase "Problema".
Defina o problema
O mal que assola a humanidade, e em praticamente todas as áreas de interação: fornecer soluções para problemas que não compreendemos adequadamente. Isto pode dar
certo, ou pode dar (muito) errado.
Isto é muito válido no universo da tecnologia da informação e comunicação (TIC), em especial quando algum problema ocorre na infraestrutura e o analista sai disparando
comandos, configurações, etc., no intuito de corrigir um problema que ele mesmo não sabe exatamente o que é ou como surgiu! Isto consome tempo e recursos, além de
contribuir para o estresse e esgotamento emocional das equipes de suporte, principalmente em ambientes onde há aquela "panela de pressão". Quem nunca sentiu-se
pressionado, estressado, frustrado, desmotivado, quando atuando sob pressão de clientes e de gestores?
Mas há outros problemas associados aos modelos de suporte rápidos e pouco estruturados, ou seja a abordagem de suporte "à bangu":
1. As correções em muitos casos provocam desvios dos padrões estabelecidos pela Engenharia da empresa.
1. Com o tempo, os padrões das configurações dos elementos de rede tendem a divergir razoavelmente daqueles que correspondem às práticas aprovadas. E você
começa a bagunçar com a configuração dos dispositivos da rede. E isto é péssimo!
2. Isto acarreta no aumento da complexidade operacional e dificulta as ações de manutenção das documentações e demais procedimentos operacionais. Como
manter a documentação da rede sincronizada e consistente nestas circunstâncias?
2. Aumenta substancialmente o risco decorrentes de falha humana durante estas ações de suporte "impensadas". Ou seja, durante uma atividade desuporte, você poderá,
acidentalmente, agravar a situação!
A parte mais crítica do processo de resolução de problemas ("troubleshooting") é a condução de uma análise adequada com o objetivo de definição do problema. Algumas
sugestões de ações cabíveis neste estágio tão importante:
Descrição do Problema ("título")
Além de data e hora do surgimento do problema - quando o problema foi notado ou comunicado por usuários/clientes e/ou pela equipe de operação?
Escopo do Problema
Quais serviços da rede estão sendo afetados? Por exemplo:
Wireless corporativo ou de convidados, acesso à Internet de usuários banda larga, acesso à Internet de usuários corporativos, acesso a websites ou serviços
específicos, etc.
Fator de indisponibilidade associado ao problema:
100% indisponível?
Parcialmente indisponível?
Problema de natureza intermitente?
Lentidão apenas?
Locais afetados pelo problema:
Prédios/sites, andares, departamentos/setores, sites, pops, e os usuários ou clientes espalhados nestes
Segmentos lógicos afetados, do conceito lógico do projeto
VLANs específicas? Subredes específicas? Servidores específicos? Aplicações específicas?
Perímetros específicos, tais como usuários autenticados em um BNG/BRAS específico, usuários de um anel Metro, usuários atendidos por um roteador PE
específico, etc.
Análise temporal do problema - quanto à detecção e recebimento da notificação ou relato do problema
Quando o problema surgiu pela primeira vez, isto é, quando a equipe de TI foi acionada?
Algum analista estava realizando alguma configuração ou modificação em algum equipamento da rede?
Há registros de mudanças recentes que coincidam com o surgimento do problema? (ex: revisão dos logs de TACACS+ ou registros internos de GMUD)
Caso afirmativo, qual é a probabilidade de relevância das alterações que foram realizadas com o problema reportado?
É factível considerar rollback, caso esta análise indique alta probabilidade.
É um problema recorrente, ou seja, ocorre com alguma frequência em sua rede?
Dentre outras iniciativas e questionamentos desta natureza.
Este pequeno roteiro embarca fatores tais como escopo temporal + perímetro + qualitativo + quantitativo, fomentando toda a lógica de análise preliminar e a devida compreensão
do problema, ou seja, trazendo à tona todas as informações que você precisa saber para definir o problema! A qualidade das confirmações das situações e contextos acima
ditará o seu grau de sucesso no troubleshooting nas etapas posteriores.
Isto é o que chamamos de Abordagem de Troubleshooting Estruturado, ao oposto dos métodos pouco ortodoxos (“from the hip” ou "à bangu") usados por muitos ou pela
maioria dos analistas.
Etapas da fase "Diagnóstico"
Verifiquemos o roteiro esmiuçado e recomendado da fase Diagnóstico.
Colete informações
Com a definição do problema realizada com êxito, aqui você buscará coletar as informações necessárias para promover um diagnóstico efetivo do problema. Os equipamentos
que você deverá acessar e as respectivas áreas funcionais a serem inspecionadas, enfim, tudo isto dependerá das informações obtidas durante a definição do problema. Já
neste estágio, você deverá saber quais tecnologias (protocolos, serviços) deverão ser verificadas e em quais equipamentos você deverá conduzir estas verificações inicialmente.
Aqui você analisará logs, processos, CPU, memória, filas, buffers, interfaces, VLANs, tabelas MAC, ARP cache, vizinhanças/adjacências de protocolos de roteamento, estruturas
de dados dos protocolos de roteamento, tabela de roteamento, ACLs, policies de BGP ou IGP, NAT, e tantos outros, mas tudo aquilo e somente os componentes que tiverem
relação ou conexão parcial ou total com a definição do problema.
Analise as informações coletadas
Na medida em que a coleta de informações vai desenrolando-se, você deverá traçar uma estratégia de análise para cada componente inspecionado. Em outras palavras, saber
exatamente o que olhar e o que verificar em cada situação coletada. Isto inclui estado das interfaces, erros nas interfaces, configuração das interfaces (endereços IP, MTU, etc.),
configurações e estados VLAN/802.1Q/STP/etc., configurações e estados de protocolos de roteamento (métricas, áreas, autenticações, políticas, filtros, adjacências, etc.), rotas
na tabela de roteamento, serviços diversos e que por ventura se façam presentes (ex: port security, DHCP Snooping, DAI, IPSG, IP SLA, PBR, PPPoE, NAT, QoS/policy, o que for..
etc.), e assim por diante.
Obviamente isto exigirá bons conhecimentos sobre cada uma das tecnologias mantidas nas coletas que você realizou, como elas funcionam, como interagem, e quais são os
requisitos de integração de cada uma destas tecnologias.
Elimine hipóteses
Das informações que você coletou, e após efetuar as análises preliminares, você deverá saber identificar o que certamente não contribui para o problema, ou o que não
promoveu participação para o surgimento do problema.
O foco é o seguinte: tudo o que não for relacionado ao problema deverá ser desconsiderado.
A idéia aqui é fazer você ir ao campo de batalha com as armas necessárias apenas e com, no máximo, 3 possibilidades de ações visando a correção do problema. Como
costumamos afirmar, “não adianta dar tiro pra tudo quanto é lado”, pois, além de levar muito mais tempo, é pouco efetivo, confunde, e pode causar outros e indesejáveis
problemas, além do estresse emocional já comentado. Procure ser cirúrgico na hora de eliminar possibilidades, pois não adianta você encaminhar "10 possibilidades" para a fase
de solução!
Etapas da fase "Solução"
Verifiquemos o roteiro esmiuçado e recomendado da fase Solução.
Proponha hipóteses
Em muitos casos você pode ter sido muito eficiente ou ter tido sorte, pois o problema foi fácil de diagnosticar! Isto é, você definiu bem o problema, fez as análises devidas, e, num
piscar de olhos, conseguiu identificar a causa-raiz do problema!
No entanto, em muitos casos, poderão restar dúvidas, pois o diagnóstico do problema em questão talvez possa ser mais complexo e exigir mais conhecimentos por parte do
analista, mas que, mesmo assim, você acredita que o problema esteja relacionado a duas ou três possibilidades, cujas interpretações são decorrentes da análise de informações
e eliminação de hipóteses. Neste caso, a sugestão aqui é a de propor as hipóteses restantes devidamente classificadas por fidelidade (com o problema) versus o risco e esforço
de implementação da correção.
Por exemplo, você tem duas hipóteses para resolver um determinado problema: uma delas, aparentemente a mais óbvia de ser o problema, mas que você não tem muita certeza
ainda, exige uma manobra que provocará algum distúrbio na rede, tipo uma indisponibilidade. Já a segunda hipótese, menos provável de ser o problema, exige uma manobra
corretiva mais rápida e que ainda apresenta zero risco para o negócio. Em razão disto, você poderá optar por aplicar a hipótese #2 e, caso não dê certo, fazer o rollback, e
agendar a manobra necessária para a execução da hipótese #1, seja em caráter emergencial ou em horário apropriado, dependendo da urgência para o saneamento do
problema no seu caso.
Testar hipóteses
É exatamente aqui que você conduzirá as ações especificamente corretivas. Não saia mexendo em vários componentes de uma vez só! Seja organizado e tenha o controle
absoluto da situação. Isto significa que você deverá implementar uma única ação corretiva (hipótese) por vez, sabendo que, em muitos casos, uma única hipótese poderá exigir a
intervenção de uma ou mais tecnologias e em um ou mais equipamentos. Execute o procedimento com cautela, e faça as validações devidas para confirmar a correção do
problema. Certifique-se que a manobra não tenha causado outros problemas (as vezes resolve “aquele” problema, mas pode afetar outras coisas na rede).
Não funcionou? Desfaça a alteração e implemente a próxima hipótese, ou, caso o problema não tenha sido corrigido, mas a correção (que não deu certo) é necessária mesmo
assim, talvez esteja faltando conhecimentos para resolvero problema ou que talvez algum componente adicional tenha ficado de fora. Ou você (talvez) não tenha sido eficiente
durante a coleta e análise de informações.
É a parte mais difícil de todo o processo de suporte, por isto que insisto que você seja bem efetivo nos estágios anteriores, justamente para atenuar a complexidade de
compreensão, diagnóstico e correção do problema aqui, neste estágio.
Problema Resolvido
Aqui você celebrará a resolução do problema! Aliás, não somente isto, aproveite a oportunidade para documentar o problema e a solução empregada, e fazendo isto em uma
base de conhecimentos que poderá servir para capacitar os times de suporte para que o problema em questão possa ser evitado futuramente, ou, caso haja nova ocorrência, ter
a solução ou correção implementada em menor prazo e esforço.
Todas estas etapas podem ser representadas visualmente conforme mostrado a seguir:
Abordagens para o troubleshooting estruturado
Como prestar um suporte técnico de alto nível para a sua empresa
Convenhamos, algumas redes são relativamente grandes e contam com uma diversidade bem razoável de equipamentos e tecnologias. Em adição, alguns projetos técnicos são
razoavelmente ousados e complexos, especialmente em ambientes com boa redundância e proteção do plano de controle, dentre outras sofisticações. Saber exatamente quais
equipamentos acessar, quais tecnologias verificar, e em qual ordem isto deverá ser feito, isto tudo exige algumas coisas por parte do analista.
Certifique-se de cumprir com as seis dicas a seguir para elevar o seu padrão de suporte a problemas na rede para o nível Black Belt (faixa-preta)!
1. Conheça bem o seu próprio ambiente
2. Conheça as tecnologias utilizadas na sua infraestrutura
3. Conheça os padrões de configuração utilizados pelas áreas de engenharia e operação
4. Conheça os estados operacionais desejados para as áreas funcionais da sua infraestrutura
5. Domine as boas práticas de suporte a problemas na rede (foco deste artigo aqui)
6. Antecipe problemas com processos consistentes de prevenção de falhas e recuperação de desastres
Tratemos cada um destes pontos isoladamente.
Conheça bem o seu próprio ambiente
Aqui é onde eu vejo com muita frequência alguns "absurdos" e em várias empresas Brasil afora. Profissionais com mais de um ano "de casa" e que não conhecem detalhes
fundamentais sobre os seus próprios ambientes! Surreal!
Amigo, sendo franco aqui, se eu contrato um profissional para operar a minha rede, é obrigação daquele profissional de dedicar o tempo necessário para estudar e compreender
o meu/seu ambiente, documentar e revalidar todo e qualquer "parafuso" presente, e saber dissertar sobre cada componente necessário para a viabilidade dos serviços ofertados
para clientes internos e externos. E isto dentro do escopo de atribuições daquele profissional, nada mais e nada menos. E não é o que eu vejo por aí na maioria dos casos,
infelizmente.
Quer aprender bem sobre redes? Ótimo! Comece aprendendo sobre a sua rede, o seu ambiente.
Eu vejo com alguma frequência pessoas desprendendo um tempo bem razoável em aprender uma tecnologia ou uma solução que sequer faz parte da infraestrutura ou da
realidade do projeto técnico da empresa, enquanto este mesmo profissional sequer conhece profundamente o seu próprio "quintal"! Aprender coisas novas é luxo para aqueles
que já dominam os seus próprios ambientes; conhecem bem sobre tudo aquilo que estiver embarcado nele.
Antes de você sair aventurando-se no universo de tecnologias de rede sem um propósito, foque em dominar o seu próprio ambiente, seja ele bom (sólido) ou ruim. É para isto
que você é pago, e há uma expectativa de resultados associados ao seu desempenho em implementar recursos, operar o seu próprio ambiente e resolver problemas. Isto deverá
ser a sua prioridade. Com o tempo você poderá aventurar-se em outras áreas e tecnologias que ainda não façam parte da realidade da empresa. Publicarei um artigo em breve
na Wiki do BPF para estudarmos este tema com maior profundidade.
Como sugestão para esta questão de "conhecimentos sobre o seu próprio ambiente", também comprometo-me em publicar outros artigos para falarmos somente disto. Por hora,
recomendo que você dedique o seu tempo em documentar e estudar o seu próprio ambiente. Neste quesito, recomendo a leitura do seguinte artigo, da Wiki do BPF: Boas
Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor.
Conheça as tecnologias utilizadas na sua infraestrutura
Como resolver um problema de OSPF, se você só sabe configurar o básico de OSPF e, mesmo assim, porque alguém na empresa, ou em algum lugar, compartilhou seus padrões
de configuração da sua rede?
Se você não sabe apropriadamente como este protocolo funciona, quais são os seus pacotes ou mensagens, como estas mensagens são transportadas através da rede, as
estruturas de dados mantidas pelo protocolo, os requerimentos para formação de adjacências, etc. Então, como você poderá ser garantidamente efetivo na resolução de
problemas do OSPF? Só se for na base do "chutômetro" ou de alguma coisa muito óbvia!
Como resolver um problema relacionado ao BGP, se você desconhece a sua operação e mecanismos mais básicos? (dica: dê uma conferida no artigo O Mínimo que Você precisa
saber sobre o BGP para você confirmar o quanto você não sabe sobre o BGP, este mesmo aí que roda na sua rede...).
Para você ser realmente eficiente na resolução de problemas na sua rede, você precisará, nesta ordem:
1. Documentar ou revalidar a documentação da sua rede, incluindo o projeto lógico, padrões, diagramas, etc. Ou seja, passar efetivamente a conhecer/dominar a sua
própria rede.
2. Revalidar os seus conhecimentos sobre cada tecnologia utilizada pela sua infraestrutura. Você identificará tecnologias aqui que não domina ainda, então você poderá
preparar-se em termos de estudos e revisões.
A minha recomendação neste caso é que você una as duas coisas: conheça a sua própria rede e estude as tecnologias presentes no seu ambiente.
Isto fará toda a diferença na qualidade e agilidade do seu suporte a problemas no seu ambiente.
Conheça os padrões de configuração utilizados pelas áreas de engenharia e operação
Uma coisa é conhecer bem ou muito bem uma tecnologia, tipo um protocolo ou serviço de rede. Outra é compreender os critérios e padrões quanto à utilização daquela
tecnologia no seu ambiente. São duas coisas distintas. Para exemplificar isto bem, as práticas de configuração e manutenção do BGP da sua empresa anterior podem ser
bastante distintas das práticas e padrões usados no BGP da sua empresa atual. Obviamente que experiência conta, claro! Mas, antes de você sair fazendo "do seu jeito",
certifique-se dos padrões vigentes adotados pela empresa.
Alguns ambientes possuem padrões específicos que foram selecionados e afirmados por alguém, ou por um setor inteiro da empresa (ex: Engenharia). Caberá à você confirmar
os padrões de configuração destas tecnologias em sua infraestrutura. Procure entender o "por que" de cada bloco da configuração dos elementos. Isto assegurará consistência
no seu trabalho de provisionamento e suporte de serviços, e até mesmo melhorará os seus conhecimentos acerca destas mesmas tecnologias em muitos casos. Você evolui ao
mesmo tempo em que passa a ser muito útil para a empresa, especialmente no momento em que problemas acontecerem.
E, obviamente, haverá uma oportunidade aqui para você encaminhar sugestões para aprimoramentos ou refinamentos destas configurações com base nos seus conhecimentos
e experiência prévia, caso você domine o assunto em padrões ou moldes superiores aos encontrados no seu ambiente atual.
Conheça os estados operacionais desejados para as áreas funcionais da sua infraestrutura
De certa forma, um tanto redundante com relação à documentação da rede já discutida previamente. Só que aqui as necessidades ou objetivos são mais específicos: você quer
(deve) tirar um "snapshot" do estado operacional das tecnologias (protocolos e serviços) em uso na sua rede!
Aproveitea oportunidade que a sua rede não está apresentando quaisquer problemas no momento para documentar este estado operacional "saudável", arquivar isto, e,
posteriormente, poder identificar e confrontar problemas que surgirem no ambiente com este estado operacional de rede "saudável" que foi coletado/documentado. Esta atitude
poderá ser extremamente útil quando problemas de alto impacto acontecerem na sua rede e você precisar de uma referência de estado operacional para nortear o seu
diagnóstico de problemas!
Domine as boas práticas de suporte a problemas na rede
É o que justamente este artigo tenta promover. Métodos, conhecimentos, boas práticas. Prossiga com a leitura!
Antecipe problemas com processos consistentes de prevenção de falhas e recuperação de desastres
Aqui é onde eu vejo muito "vacilo" por parte dos analistas de redes! Muitos profissionais não dedicam o tempo necessário para estudar o "merdômetro" (não encontrei
expressão mais irônica que esta para usar aqui...), que é a probabilidade de algum problema ocorrer no seu ambiente e o que você deverá fazer para:
1. Antecipar ou evitar o problema
2. Reagir cirurgicamente para sanar o problema, atenuando seus impactos, aborrecimentos e perdas para o negócio
Ou seja, o profissional fica "moscando" por meses e sem planejar uma resposta sequer a eventuais tipos de incidentes e, quando um problema grave ocorre, fica mais perdido
que cego em tiroteio. É uma das situações que vejo muito frequentemente em empresas do setor de ISP de pequeno e médio portes.
Além de perder tempo apenas para entender ou compreender (definir) o problema, o analista desprenderá um tempo razoável nas ações de diagnóstico e reparo do problema,
algo que poderia ter fluído muito mais rápida e efetivamente caso ele tivesse um plano de resposta pronto, em mãos. Sem contar que muitos dos problemas que geram
aborrecimentos para clientes internos e externos podem (e devem!) ser evitados por completo, caso haja a correta identificação do risco durante os exercícios de planejamento
de contingência da organização.
Você ou a sua empresa exercita cenários de falhas e determina impactos para o negócio? Não? Está na hora de você ou a sua empresa passar a fazer isto com seriedade,
profissionalismo e compromisso.
Dica: conduza uma extensa e apropriada análise qualitativa de riscos para identificar quais problemas podem ser evitados ou antecipados, seus respectivos impactos
quantificados (inclusive financeiros!), e faça um plano de contingência para descrever as ações necessárias para a resolução destes incidentes.
Método seguro: como refinar as suas habilidades de suporte à problemas em redes
Você poderá conduzir o processo de suporte com métodos próprios, mas isto dependerá do seu conhecimento acerca das tecnologias empregadas e do quanto você
compreende sobre a sua própria rede, conforme comentado ou sugerido anteriormente.
O que disseminarei a seguir é extremamente útil para dois perfis de profissionais de redes que identifico frequentemente em diversas empresas: profissionais iniciantes e
profissionais enferrujados.
O profissional "iniciante" seria um perfil tipo Nível 1 e que esteja começando na área, com pouco tempo de experiência. Já o "enferrujado", é aquele "macaco-velho" (Nível 2 ou 3,
ou até mesmo um N1!) e que já está há alguns anos na empresa, mas que nunca parou para pensar como as coisas deveriam ser feitas e da melhor forma possível. Ou seja,
aquele profissional que possui algum, bom ou ótimo conhecimento sobre algumas das tecnologias e configurações de seu próprio ambiente de redes, mas que nunca organizou o
seu próprio trabalho a ponto de evitar e sanear problemas. E, em ambos os perfis, os profissionais frequentemente saem atirando para todos os lados quando um problema
ocorre na rede.
Você identifica-se com um destes dois perfis? Então este artigo foi feito para você.
Na hora em que estiver coletando informações para uma análise de causa-raiz, você poderá partir para a linha de execução com os seguintes métodos didáticos. Em todos os
casos, consideraremos o modelo de referência OSI para a condução destes métodos.
Métodos de condução do suporte ao problema na rede
De Cima a Baixo (Top-down)
Lembra-se das camadas do modelo de referência OSI? O seu trabalho será balizado por estas camadas! Por exemplo:
Um problema para o qual que você está efetuando suporte diz que o usuário não consegue acessar um servidor Web interno.
Você, então, a partir da VLAN/subrede do usuário, poderia realizar um telnet para a porta TCP 80 ou 443 do referido servidor.
Abriu (conectou)? Então você sabe que a VLAN/subrede do usuário está OK, portanto confirme que outros usuários na mesma VLAN consigam acessar o servidor pelo
procedimento padrão (http ou https).
Se nenhum deles conseguir, o problema pode ser DNS, ou configurações do servidor Web, pois da camada de Transporte para baixo está definitivamente OK (em
algumas raras exceções, pode ser a rede também).
Se não funcionar (a conexão com o servidor via telnet ip porta):
Se não há a conexão com a porta TCP correspondente à aplicação, o problema pode ser a aplicação no servidor, ou algum firewall no meio do caminho, ou falha na
conectividade IP (camada de Rede), ou em camadas inferiores.
O próximo passo seria confirmar se há a conectividade IP da origem (VLAN/subrede dos usuários) até o destino, e vice-versa.
Neste caso você procederia com a validação das funções de roteamento da rede IP, usando procedimentos tais como ping, traceroute, e validação das rotas
correspondentes nas tabelas de roteamento.
Caso o ping não funcione, possa ser que algum firewall no meio do caminho esteja bloqueando as mensagens ICMP. Resta então fazer uma validação das rotas
necessárias para o cenário funcionar.
Caso estejam faltando rotas, o problema pode estar nos protocolos de roteamento, o que exigiria validações das vizinhanças/adjacências e configurações...
... ou o problema pode estar em alguma camada inferior (L2 ou L1).
Caso não haja a vizinhança devida dos protocolos de roteamento, é possível que haja um problema com a camada de Enlace de Dados (L2) e, portanto, você teria que
inspecionar as VLANs, tabelas MAC, entroncamentos 802.1Q, protocolos de resiliência L2, etc.
Caso não sejam identificados problemas nos componentes L2 diretamente, o problema pode estar na camada Física (L1).
As interfaces ou enlaces estão "Up"? Há contadores de erros nestas interfaces (ex: erros ou drops excessivos?).
Enfim, acho que você compreendeu a lógica de todo este processo Top-Down. Nesta abordagem, testamos as camadas de cima para baixo. A abordagem em si é muito segura, o
único "problema" é que você terá que testar a pilha toda, de cima para baixo, o que pode levar mais tempo. Mas é um mal necessário, enfim.
De Baixo para Cima (Bottom-Up)
É justamente o inverso do Top-down. Aqui você testará tudo de baixo para cima: a interface ou link está Up? A porta tem erros? A máquina está na VLAN certa? A tabela MAC
daquela VLAN mostra os endereços MAC do usuário e do default gateway? O endereço IP/máscara/default gateway está correto? Você consegue pingar o default gateway? Você
consegue pingar o servidor? Onde morre o traceroute? Há rota para ir e rota para retornar? Você consegue fazer um Telnet na porta do servidor? E assim por diante...
Dividir para Conquistar (Divide and Conquer)
É o método mais rápido para se chegar lá, pois a proposta aqui é economizar tempo mesmo. Para iniciar, você poderá realizar um traceroute a partir da subrede de origem até o
endereço IP de destino e identificar onde o teste "morre".
Se todos os saltos forem reportados no traceroute, então você aparentemente não tem problemas na rede, pelo menos não no que diz respeito ao L3, L2 e L1. O problema
pode estar relacionado a firewalls, outros dispositivos de segurança (ex: IPS), balanceador de carga, ou com o serviço do próprio servidor, etc.
Se o traceroute "morrer" em algum salto, você então sabe que da subrede de origem até aquele salto onde o traceroute "morreu" não há problemasL1, L2 ou L3.
Daquele pondo em diante você fará então o Top-down ou Bottom-up.
Por exemplo, o usuário não acessa o servidor. Então, da VLAN deste usuário, ou diretamente da máquina dele, você faz um traceroute até o servidor, e verifica até onde o teste
reporta como bem sucedido. Se pingar ou der OK no traceroute, tente o telnet na porta da aplicação. Se não funcionar, procure por firewalls ou outros tipos de dispositivos de
segurança presentes no meio do caminho.
Agora, se o traceroute não for bem sucedido, vá até o último gateway que reportou OK no teste e verifique as configurações e modos operacionais daquele router (com Top-
Down ou Bottom-Up), e use o Follow-the-Path abaixo para ir seguindo o caminho até encontrar o equipamento que possui problemas nos componentes físicos ou lógicos
envolvidos nesta comunicação pretendida.
Siga o Caminho (Follow-the-Path)
Geralmente é usado juntamente com o Divide and Conquer. Quando o traceroute “morrer”, você tem que ir seguindo o caminho a partir do último gateway que reportou o OK no
teste de rastreamento de rotas, e fazer as verificações necessárias com Top-Down ou Bottom-Up.
Aqui uma boa e atualizada documentação (tipo um diagrama) fará toda a diferença nos quesitos tempo e esforço. Você poderá comparar os resultados dos comandos de
verificação com a topologia mostrada no diagrama e encurtar substancialmente o seu tempo e esforço. Do contrário, você terá que praticamente desenhar a sua rede no papel
na medida em que faz as verificações e validações. Possa ser que você encontre o problema rapidamente, ou que você tenha que ir, um por um, até o último equipamento para
matar a charada, enquanto valida as tabelas MAC, rotas, adjacências, conexões físicas, etc.
Encontrar Diferenças (Spot the Diferences)
Ao realizar o Divide and Conquer, e em combinação com o Follow-the-Path e Top-Down ou Bottom-Up, e se você tiver muitas dificuldades na identificação de onde o problema
possa estar, você poderá comparar um serviço na rede que seja similar àquele que você está realizando o troubleshooting, preferencialmente algo idêntico ou similar e que
esteja funcionando. Ou comparar com um snapshot obtido previamente. Isto é muito útil, por exemplo, quando testando ou fazendo troubleshooting de emparelhamentos BGP ou
MPLS L3VPNs, ou outros cenários com configurações mais elaboradas, para citar alguns casos, onde você poderia comparar estas configurações mais complexas (ex: VRFs,
policies, contextos, redistribuições de protocolos de roteamento, configurações de NAT e afins) com a configuração do serviço que está apresentando o problema.
Mover o Problema de Lugar (Move The Problem)
Próximo da hora do desespero: após você ter validado tudo e não ter conseguido localizar o problema, tendo praticamente esgotado as possibilidades, uma medida radical seria
experimentar tentar isolar o problema através de uma ação de mudança (de lugar), seja esta física ou lógica. Por exemplo, mudar o ponto de rede do usuário, trocar cabos, trocar
a conexão na porta do switch onde o usuário estiver localizado, migrar a conexão para outro equipamento, e ações deste tipo. Procure adotar as medidas mais rápidas e/ou de
menor esforço e risco, visando economizar tempo. Para exemplificar, o que é mais rápido, trocar o cabo do usuário na baia dele ou na porta do switch? Seria mais rápido você
trocar uma fibra ou remanejar o usuário de switch? Seria mais rápido migrar a conexão para outro módulo físico no mesmo equipamento, ou migrar para outro o equipamento? É
viável você transferir as configurações L3 do roteador PE atual para outro equipamento a ser posicionado? Substituir o equipamento inteiro é a ação mais rápida ou viável?
É melhor termos um método seguro para trabalhar do que inventar moda na hora de resolver um problema na rede!
Não que eu curta ser burocrático, até mesmo porque as sugestões e conceitos deste artigo não são qualquer coisa deste tipo. Para ser efetivo, você precisa de processos, de
um "norte"; de uma bússola. Com as empresas e indivíduos cada vez mais dependentes da disponibilidade de recursos computacionais, haverá sempre uma pressão, frustração
e perdas associadas com a queda de produtividade e lucratividade de empreendimentos inteiros e que dependem das soluções e ferramentas da tecnologia da informação e
comunicação para fazer negócios, agilizar processos, e servir interesses com maior comodidade e agilidade. Sem contar que muitas tecnologias estão orientadas aos conceitos
de redução de custos também e, portanto, cada falha e cada indisponibilidade é péssima para todos: empresa, usuários e clientes.
Conforme citado anteriormente, você tem total liberdade para gerir o suporte técnico de seu ambiente como melhor lhe convier. Eu apenas entendo que você será mais efetivo
com os seus próprios métodos somente a partir do momento em que você passar a conhecer bem (ou muito bem) os componentes e situações particulares do seu ambiente.
Para todos os demais casos, sugiro seguir as recomendações deste artigo!
Falando de seguir as dicas deste artigo: no início, você poderá ter um pouco de dificuldade em seguir os roteiros propostos. Caso isto aconteça, a resposta é simples: você
não está acostumado ainda a trabalhar de forma pautada e organizada. É que nem frequentar uma academia após anos de sedentarismo, e amanhecer no dia seguinte repleto
de dores! "Uma vida de contemplações glutônicas e sedentárias o deixou lento demais para agir...". :-D
Encare este desafio como "aprender a andar de bicicleta". Para não tomar aquele tombo, coloque os processos em ordem, pratique, ganhe confiança, antecipe-se, e, em pouco
tempo, você estará fera no assunto! Pode apostar nisto!
Roteiro estruturado de troubleshooting é que nem aprender a andar de bicicleta: leva
algum tempo pra dominar, mas funciona e dá resultados permanentes!
Fique atento quanto a situações mais complicadas
Há algumas situações onde realmente o problema fica difícil de ser resolvido. Dedicarei esta seção para dissertar um pouco a respeito.
Em suma, como você provavelmente já deva saber, os equipamentos presentes nas infraestruturas L2 e L3 possuem áreas sistêmicas denominadas plano de controle (control
plane), plano de dados (data plane), plano de serviços (service plane) e plano de gerenciamento (management plane). Resumindo aqui o que são, o que fazem, e
exemplificando também alguns dos principais componentes de cada um destes planos:
Control Plane
É a área sistêmica onde ficam hospedados os protocolos de roteamento, tais como RIP, OSPF, EIGRP, ISIS, BGP, assim como as rotas estáticas e a tabela de roteamento (routing
information base ou RIB). Em adição, diversos protocolos são mantidos também no control plane, tais como os protocolos associados ao MPLS (LDP, RSVP-TE, BGP-LS (uma
address-family do BGP)), além de protocolos de resiliência L2 (Spanning Tree, EAPS, REP, G.8032, e outros), e suas respectivas estruturas de dados. E, para finalizar, protocolos
tais como o ARP e o IPv6 ND (ICMPv6). Outras tecnologias e recursos normalmente presentes nas redes implementam partes de suas funções também neste plano, mas buscarei
simplificar este entendimento e, portanto, pararei por aqui.
A principal função do control plane é fornecer as funções de programabilidade das estruturas de comutação e encaminhamento de pacotes, ou seja, a alimentação de suas
tabelas de roteamento de forma dinâmica ou estática e no intuito de termos uma convergência da rede (entendimento coletivo acerca dos caminhos da rede, mas cada roteador
tendo o seu próprio entendimento quanto a isto), e sinalizar ao plano de dados, via mecanismos de troca de mensagens entre processos (ou IPCs), sobre a disponibilidade
destes caminhos.
Alguns dos diversos problemas que você terá que resolver ("efetuar o troubleshooting") tem relação direta com estes protocolos. E, em grande parte, estes problemas podem ser
evitados com boas práticas na configuração do roteamento (L3) e também valendo o mesmo para as tecnologias L2. Portanto, procure projetar e configurarestas tecnologias
obedecendo às boas práticas, pois, assim, raramente você terá que se preocupar em resolver problemas na rede com estes protocolos e serviços. Fica a dica!
Todavia, caso isto venha a acontecer (os problemas), esteja preparado! A análise de informações coletadas precisa ser feita corretamente. O que olhar no output de um comando
para verificação de adjacências do OSPF? O que olhar na tabela BGP de rotas recebidas de um peer EBGP? Isto significa que você precisa conhecer previamente as tecnologias
que você mesmo deverá suportar em sua rede para quando os problemas ocorrerem.
O meu julgamento aqui:
Identificar e localizar problemas nos protocolos é "mamão-com-açúcar" para profissionais organizados, metódicos, e conhecedores destas tecnologias e protocolos.
Os comandos "show" e "display" disponíveis na CLI dos equipamentos revelam praticamente tudo aquilo que você precisa olhar para localizar um problema ou alguma
inconsistência.
Há opções bem versáteis de diagnósticos de problemas com protocolos no plano de controle, tais como consultas de logs e debugs específicos.
É o troubleshooting mais fácil de todos. Acredite!
Data Plane
O plano de dados por sua vez representa as estruturas específicas para as ações de processamento e encaminhamento de pacotes, podendo ser baseada em software
(softrouting) ou em silício especializado, tais como ASICs e FPGAs. É no plano de dados onde ocorre de fato a determinação de caminhos e o efetivo encaminhamento do pacote,
em adição a toda e qualquer manobra ou ação a ser executada sobre os cabeçalhos dos pacotes (ex: manipulação do tag de VLAN, imposição/swap/pop de label, marcação de
QoS, tradução de endereços IP) ou sobre a transmissão do pacote em si (ex: policiamento, moldagem, ajuste de TCP MSS, ou fragmentação).
O plano de dados vive em plena harmonia com o plano de controle - ou pelo menos deveria! Em roteadores mais sofisticados, em termos de processos em execução, um plano
não depende do outro para funcionar, mas, na prática, sem o plano de controle, como o roteador preencherá a sua FIB lá no plano de dados?
Isto significa que um problema num protocolo de roteamento provocará a fuga de rotas na tabela de roteamento (RIB), a qual é mantida no plano de controle.
Consequentemente, o plano de dados fica sem as instruções correspondentes (ex: entradas na FIB e respectivas adjacências para reescrita de cabeçalhos) para encaminhar
pacotes para aqueles destinos. Tudo muito óbvio.
Ou seja, muitos dos problemas que experimentamos na rede à título de "encaminhamento de pacotes" na verdade não estão no plano de dados, e sim no plano de controle. Mas
esta parte é fácil de identificar (vide comentário da seção acima).
O que realmente dificulta muitos casos de suporte é quando não há problemas aparentes no plano de controle! Aí, meu amigo, como diria o Galvão Bueno, "haaaaaja coração!".
A maioria dos problemas específicos do plano de dados são relativamente fáceis de identificar e resolver, mas não sem um esforço antes, até mesmo custos em alguns casos!
Citarei apenas alguns exemplos aqui, pois as possibilidades são muito vastas mesmo:
Problemas associados à perda de conectividade:
Possíveis causas: queda ou rompimento de enlace. Fácil de identificar e resolver.
Problemas associados à lentidão de comunicações com perda de pacotes:
Possível causa: tráfego excedente em uma policy (que pode ser resolvido por meios de configurações). Fácil de resolver.
Possível causa: congestionamentos (os "gargalos", os quais podem ser atenuados com ajustes no cenário de QoS, ou aumentando a capacidade do circuito).
Relativamente fácil de resolver, mas pode levar tempo (ex: aumento de capacidade).
Possível causa: problemas com o processamento de um ou mais dispositivos presentes na rede. O diagnóstico aqui é razoavelmente mais difícil, pois normalmente exige
que você compreenda bem as capacidades dos dispositivos, além de algum (bom) conhecimento da arquitetura dos equipamentos envolvidos. Além de saber onde obter
as informações necessárias na configuração e estado operacional dos componentes do equipamento, e fazendo isso para cada equipamento.
Problemas associados à lentidão de comunicações com aumento de latência e/ou jitter:
Estando a latência geral um pouco elevada, mas estável ou consistente, talvez um refinamento das políticas de QoS atenuem o delay fim a fim e o jitter. Exige maior
capacitação por parte do analista para efetuar este tipo de correção.
Agora, há situações bem complicadas onde você começa a investigar e descobre que:
Você não encontra problemas nas configurações dos protocolos e serviços no plano de controle.
Você descobre que a carga (processamento) dos processos correspondentes está aparentemente normal.
Você não encontra indicadores de erros nas interfaces físicas e/ou lógicas dos respectivos enlaces da comunicação fim a fim.
Você não encontra indícios de congestionamentos nas filas de saída destas interfaces.
O seu time de transmissão realizou um teste de RFC no circuito usando uma ferramenta específica (ex: JDSU) e reportou não haver problemas com o circuito suspeito.
Mas, mesmo assim, o seu cliente reporta a lentidão, e este problema pode ser confirmado por você!
O que você faz? Onde você olha? Qual tecnologia você inspeciona? Qual comando você digita? E em qual equipamento?
É o tipo de situação mais difícil de se resolver; o que consome maior esforço e tempo.
O meu julgamento aqui:
Muitos do problemas específicos do plano de dados podem ser evitados com abordagens mais atraentes e profissionais. Ou seja, um bom projeto técnico e com boa
engenharia de rede, tráfego e planejamento de capacidades.
A maioria dos problemas no plano de dados deixa um rastro observável e reportado por comandos específicos na CLI ou na plataforma de gerenciamento da rede.
Há, no entanto, algumas situações onde realmente você possa vir a ter extrema dificuldade em termos de diagnósticos!
É nessas horas que você precisará conhecer melhor a arquitetura dos equipamentos e envolver o suporte do fabricante. E contar com profissionais mais experientes ou
com uma consultoria de excelência.
Aiás, você possui os contratos de assistência técnica e suporte estendidos vigentes, em dia? É nessas horas que isto faz uma tremenda falta!
No geral, o troubleshooting de problemas do plano de dados é mais complexo do que o troubleshooting de problemas do plano de controle, e normalmente exige mais
experiência por parte do analista.
Service Plane
Não esmiuçarei este com detalhes. Mas nesta área é onde ficam hospedados protocolos e serviços tais como PPPoE, IPoE, GRE, IPsec, L2VPN e outros. Normalmente ou quase
sempre estes protocolos e serviços compartilham os mesmos componentes onde estão hospedados os demais protocolos e serviços do plano de controle (ex: CPU e memória).
Os problemas mais frequentes aqui são: padrões de configuração empregados (fora das boas práticas), desalinhamento de utilização com relação à capacidade do recurso
naquele equipamento (ex: violação quanto a quantidade de sessões, quantidade de túneis, etc.). A resolução destes problemas, quando o componente estiver operando dentro
de suas capacidades, requer conhecimento da tecnologia em questão.
Management Plane
E, para finalizar, a área sistêmica onde estão hospedados os protocolos e serviços específicos de gerenciamento, tais como Telnet, SSH, Netconf, SNMP, OAM, CFM, NetFlow,
IPFIX e afins. Em muitos casos, compartilhando os mesmos ou a maioria dos componentes onde estão hospedados, também, os protocolos e serviços dos planos de controle e de
serviços (ex: CPU e memória).
Os problemas aqui tendem a ser bem pontuais e de fácil diagnóstico, na maioria dos casos. Não entrarei em detalhes para não estender-me desnecessariamente com o artigo.
Quando a "casa cai'
Falando aqui especificamente de defeitos de software, os famosos "bugs". Há situações onde as configurações dos protocolos e serviços estão corretas no ponto de vista do que
deveriam ser mesmos, e em alinhamento com as boas práticas,mas, mesmo assim, você está com um baita problema em algum serviço da rede.
Malditos... bugs!
Não estenderei-me demasiadamente nesta seção, pois já estou projetando um artigo para falar somente disto ("gerenciamento de crises provocadas por bugs de software",
ou algum nome intuitivo assim). Siga acompanhando a Wiki do BPF!
Para sintetizar, o que posso falar, e com absoluta propriedade, são os seguintes:
Não há software isento de defeitos (bugs).
Felizmente, em muitos casos, um eventual defeito (bug) existente no código do software do equipamento, referente a um protocolo ou serviço, poderá não te causar qualquer
problema ou distúrbio, pois, da maneira como você configurou o recurso, o referido bug não é acionado ("trigger").
Nenhum equipamento, modelo, marca ou fabricante está imune quanto a bugs no software.
Existem bugs "bons", "mais ou menos bons", e "nojento e maus"!
É óbvio que todo bug é muito ruim! Mas, como não temos como rodar software 100% imune com relação a bugs, em algum momento na sua carreira você se deparará com um
bug! Fato! Quando isto acontecer, você rezará para que seja um bug "bom", e não um bug "nojento e mau"! Não entendeu ainda? Relaxe! Acompanhe a minha linha de raciocínio
a seguir:
Bug "bom" é aquele que "mostra a cara", ou seja, quando há uma notificação no log do equipamento indicando um problema, e geralmente acompanhando alguma
mensagem ou indicador que pode ser pesquisado por você ou pelo suporte do fabricante do seu equipamento.
Se você tiver que experimentar - indesejavelmente - um bug no software do seu equipamento, e este bug vier a te causar algum problema, você realmente desejará que
este bug "mostre a sua cara". Por que?
Porque ficará muito mais fácil para você pesquisar por um software isento daquele bug (fixed) e/ou acionar o fabricante para comunicar o problema e, assim, obter o
devido suporte.
Bug "mais ou menos bom" é aquele onde você precisará conduzir diversos diagnósticos e coletas, geralmente seguindo procedimentos com a orientação do suporte técnico
do fabricante e, ao encaminhar toda a coleta para o fabricante, os times de suporte fazem as depurações diversas e "acertam" (hit) o bug, ou seja, localizam um bug que já é
conhecido pelos times de engenharia e desenvolvimento daquele software. Ufa!
Este "hit" do bug na base interna dos times de desenvolvimento do fabricante permite localizar o problema por um "bug ID" já conhecido. Alguns fabricantes chamam isto
de Distributed Defect Tracking System (DDTS).
Geralmente aqui já tem uma ação paliativa conhecida e documentada para aquele bug ID ou DDTS, ou;
Uma release de software já disponível, isenta deste bug ID ou DDTS.
Bug "nojento e mau" é aquele que o suporte do fabricante, após ter recebido os dados das suas coletas, debugs, etc., não consegue localizar um problema conhecido na
base interna de bugs! Amigo, você acabou de "abrir" um bug! Ou seja, sequer ainda existe correção disponível para o seu problema. Que azar, hein?!
Com pouco ou muito esforço, o fabricante poderá recomendar um "workaround", que seria uma solução paliativa para você fugir do problema provocado pelo bug,
enquanto você ainda usa o software que contém o defeito, normalmente por falta de opções no momento com relação a software.
E enquanto os times de desenvolvimento do fabricante correm atrás do que fazer para corrigir o código contendo o problema, o que poderá levar meses em alguns
casos.
Por exemplo, isto pode exigir algum comando adicional, ou ajustes de parâmetros de algum recurso, remoção da configuração correspondente ao problema (o que é
inviável em muitos casos ou projetos), ou reboot pontual ou periódico do equipamento.
Ou trocar o software do equipamento por outro que seja compatível com os recursos e funcionalidades exigidas pelo seu projeto técnico.
Em alguns casos mais graves, a solução seria aguardar uma correção do problema em nova release de software! Isto é cruel.
No entanto, há formas de evitarmos surpresas desagradáveis com relação a problemas de software. Quer ver? Confira este artigo Boas Práticas para Políticas de Manutenção de
Software de Ativos de Rede, disponível em nossa Wiki!
Conclusão do artigo
Para concluir, entenda que o troubleshooting de redes pode ser uma "ciência" um tanto ampla e complexa, pois são variáveis praticamente infinitas em termos de dinâmicas de
surgimento de problemas. As situações são muitas, mesmo!
Felizmente, muitos dos problemas podem ser evitados através da adoção de excelentes abordagens de projeto técnico e com o auxílio das boas práticas. E, claro, da sua
capacidade e compromisso em antecipar-se aos diversos tipos de problemas que podem surgir em sua rede. Antecipe-se! Tome as iniciativas necessárias através de uma boa
documentação, e monte um bom roteiro de suporte, bem elaborado e estruturado. Isto fará toda a diferença!
Espero que você tenha curtido este artigo! Compartilhe-o e ajude a divulgar o trabalho do Brasil Peering Forum (BPF)!
Obrigado!
Autor: Leonardo Furtado
Categoria: Capacitação
Página Discussão Ler Ver código-fonte Ver histórico Pesquisar em Wiki BPF
Página principal
Mudanças recentes
Página aleatória
Ajuda
Menu
Quem Somos
Participação
Conteúdos Úteis
Categorias
Documentos Públicos
Agenda
Ferramentas
Páginas afluentes
Mudanças
relacionadas
Páginas especiais
Versão para impressão
Ligação permanente
Informações da página
Crie uma conta Entrar