<p>Monitoração de aplicações com alta disponibilidade: Uma prática bem comum é implementar a monitoração sempre de forma individual das aplicações, isso gera um número desnecessário de incidentes e falta de priorização. Um exemplo clássico é se temos um banco de dados em cluster, no qual um nó é ativo e o outro passivo, normalmente quando o nó primário cai, geramos um incidente com a maior criticidade possível. É importante sabermos quando esse nó primário cai? Sim, porém é mais importante saber quando os dois nós caem. O cenário ideal seria implementar uma monitoração no nó principal com uma severidade media e uma outra observando o estado dos dois nós em conjunto com uma criticidade alta.</p>
<p>Monitoração de dispositivos de rede: De acordo com o estudo Network Barometer Report 2015 da Dimension Data, que traz uma análise nas redes do mundo inteiro, uma monitoração pode reduzir mais de 30% do tempo para resolver problemas e 75% do tempo para fazer “troubleshoot”. Isso mesmo, 75%! É um valor bem alto! E quanto mais efetiva e assertiva nossa monitoração for esse número pode aumentar mais a eficiência e pró-atividade na operação.</p>
<p>Alguns pontos são levados em consideração para poupar esforços quando o assunto é analisar incidentes desnecessários: a maneira como é feita a validação, se um dispositivo está fora, ou o que chamamos comumente de “polling”, o ideal é que esse tenha algumas regras, tais como: checar o estado do dispositivo a cada um minuto por três vezes, ou por três minutos contínuos, claro esse número pode variar, mas a ideia aqui é não gerar o alerta na primeira falta de resposta do equipamento porque para a ferramenta de monitoração chegar até ele existem muitas vezes um longo caminho que pode influenciar e muito na resposta, fazendo com que tenhamos os chamados falsos alertas.</p>
<p>Outro ponto que deve ser levado em consideração é o “timeout” que já existe na rede para definição dos “thresholds”, pois é comum clientes que tem servidores e equipamentos em diversas localidades e nem sempre o link de acesso tem uma boa velocidade. Portando, nestes casos, devemos aplicar regras mais customizadas de acordo com o comportamento da resposta.</p>
<p>E é claro que temos situações que não podemos esperar por três minutos para gerar um alerta de equipamento. Neste tipo de cenário, o ideal é que um sensor da ferramenta fique no servidor mais próximo dessa infraestrutura para que essa percepção seja afetada da menor forma possível.</p>
<p>E também a distribuição desses sensores, exemplo: clientes que têm várias localidades, quando possível colocar um sensor por região com o objetivo de ter uma percepção mais apurada.</p>
<p>Outra funcionalidade que devemos explorar nas ferramentas de monitoração é a capacidade de “root cause”, ou seja, quando um equipamento principal cair terá apenas um alerta de alta prioridade e não diversos alertas para cada dispositivo na rede afetada. Isso requer trabalho e conhecimento no ambiente para configurar, porém o resultado é muito eficaz e assertivo porque você terá o alerta somente do dispositivo com problema.</p>
<p>Além da correlação dos equipamentos de rede, outra que pode ser aproveitada para servidores é quando houver um alerta de servidor indisponível. Qualquer outro alerta será eliminado ou não disparado, já que o servidor está inacessível e não há possiblidade de tratar nenhum outro problema. Sendo assim, esses outros alertas não fazem nenhum sentido.</p>
<p>Essas ideias citadas acima, se aplicadas, ajudarão a ter uma operação mais eficiente, mais produtiva e assertiva, pois o centro terá uma console mais limpa, apenas com eventos que realmente devem ser tratados. Terão uma priorização mais adequada, fazendo com que todo o processo de comunicação seja mais condizente Em linha gerais, ninguém será acordado de madrugada porque um banco principal caiu, já que a contingência trabalha no que foi proposto.</p>
<p>Todas essas ideias podem ser implementadas através das principais ferramentas de monitoração do mercado. Basta o profissional ter conhecimento e paciência para saber a função de cada uma dessas ferramentas na operação.<br /><br /><br /><em>(*) Analista de Suporte e Monitoração da Sonda IT</em></p>
