O custo do monitoramento (SEM automatização)

Este artigo é uma continuação do anterior, que pode ser visto neste link.

***

É bem provável que qualquer profissional de TI que usou ferramentas de monitoramento por algum tempo se sinta perfeitamente à vontade configurando ​​novos dispositivos, como servidores, roteadores, switches e afins. Também é provável que acrescentar subelementos, como discos e interfaces, seja algo fácil. Além disso, há uma boa chance de que esses profissionais configuraram um bom número de relatórios e exportações de dados. Isso sem falar nos alertas.

Mas a questão mais importante é o que fazer com esses alertas.

A maioria dos profissionais de TI que usam ferramentas de monitoramento configuram o encaminhamento de alertas por e-mail ou mensagem de texto, que podem receber em seus dispositivos móveis. Aqueles particularmente ambiciosos podem até mesmo configurar a emissão automatizada de tíquetes no sistema de incidentes utilizado pela empresa. Mas, uma vez configurado o sistema, eles costumam dar o trabalho por encerrado.

O que vem depois disso é o de todos os dias: a ferramenta de monitoramento detecta um erro, uma notificação é enviada, um ser humano assume a responsabilidade e inicia uma ação de algum tipo e o problema acaba sendo resolvido (mais cedo ou mais tarde).

Mas por quê? Por que incomodar um ser vivo que está respirando, trabalhando (ou dormindo) se um computador pode fazer algo sobre a situação? O fato é que muitos alertas de monitoramento têm uma resposta simples que muitas vezes pode ser automatizada dentro da própria ferramenta de monitoramento, e com isso economizar muitas horas de mão de obra e de recursos, ajudando – em resumo – nos lucros.

Pense nestes exemplos simples que em geral são esquecidos:

Alerta: o serviço XYZ saiu do ar

Resposta automatizada: tentativa de reinicialização do dispositivo

Alerta: o disco está mais de X por cento cheio

Resposta automatizada: limpar pastas TEMP padrão

Alerta: conflito de endereço IP detectado

Resposta automatizada: desligar porta do dispositivo mais recente

A lista poderia ser enorme.

A qualquer momento, se uma resposta automatizada não for bem-sucedida, as ferramentas de monitoramento adequadas vão desencadear uma ação secundária: os e-mails, mensagens de texto ou tíquetes que mencionamos antes. Na pior das hipóteses, o e-mail, mensagem de texto ou tíquete serão adiados por alguns minutos, mas isso porque o sistema de monitoramento fez imediatamente aquilo que um técnico humano teria feito depois de conectado. Assim, de certo modo, o caminho para a resolução ainda estaria mais que alguns minutos à frente se a resposta automatizada não estivesse funcionando.

E as possibilidades de automatização não param por aí. Ferramentas eficazes de monitoramento também permitem que você inicie automaticamente a coleta de informações adicionais necessárias no momento do alerta e “injete-as” no próprio alerta. Por exemplo:

Alerta: a utilização da CPU está acima de X por cento

Resposta automatizada: identifique os 10 processos principais, classificados por utilização da CPU

Alerta: a utilização da RAM está acima de X por cento

Resposta automatizada: identifique os 10 processos principais, classificados por utilização da RAM

Alerta: a VM está usando mais de X por cento dos recursos do host

Resposta automatizada: identifique a VM pelo nome

Alerta: o disco está mais de X por cento cheio depois da limpeza das pastas TEMP

Resposta automatizada: analise o disco para encontrar os 10 maiores arquivos, classificados por tamanho, que foram acrescentados ou atualizados nas últimas 24 horas

Mas será que este tipo de automatização do monitoramento realmente afeta a lucratividade? A resposta é um sonoro “sim”.

Caso em questão: uma empresa implementou recentemente um sistema não mais sofisticado do que as respostas automatizadas descritas acima para problemas com discos, limpando as pastas TEMP e alertando novamente depois de mais 15 minutos caso os discos ainda estivessem cheios, e adicionando os dez processos principais ao alerta de CPU alta.

O resultado foi uma redução de alertas entre 30% e 70% em relação ao mesmo mês do ano anterior. Em números reais, isso significou 43 a 175 alertas a menos por mês. Além disso, a equipe de suporte viu os resultados e respondeu mais rápido aos alertas restantes, porque sabia que as ações iniciais automatizadas já haviam sido feitas.

Os alertas relacionados à CPU obviamente não se reduziram, mas, novamente, a resposta da equipe de suporte melhorou, pois os tíquetes passaram a incluir informações específicas sobre o que estava acontecendo de errado. Em um dos casos, a empresa conseguiu recorrer a um fornecedor e solicitar um patch porque conseguiu finalmente provar um problema de longa data com o software.

Como a virtualização e a queda dos custos (aliadas, espera-se, à expansão dos orçamentos) forçam o crescimento dos ambientes de TI, a necessidade de potencializar o monitoramento para garantir a estabilidade dos ambientes de computação se torna cada vez mais evidente. Menos óbvia, mas tão crítica e valiosa, é a necessidade de assegurar que o custo humano desse monitoramento continua baixo com a implementação de uma ferramenta de monitoramento que facilite a automação, e com o uso inteligente de tais recursos de automação.