Nós que trabalhamos em data centers estamos sentindo a necessidade de expandir o modo como pensamos. Não queremos mais apenas gerenciar os dados que somos responsáveis por manter. Queremos transformar esses dados em informações e, ir além: transformar as informações em ações na forma de automação de data center.

Posso perceber que, mesmo em 2017, nem todo mundo tem a oportunidade de trabalhar em um data center onde monitoramento e automação funcionam juntos como um todo coeso; portanto, talvez essas pessoas não entendam por que estou sendo tão enfático sobre o assunto. Vamos explorar essa questão.

Por que automação?

Você pode se perguntar: se há um bom sistema de monitoramento, por que automação é tão importante? A resposta é: porque você é preguiçoso. Porque a maioria dos profissionais de TI experientes é preguiçosa. Porque passar o dia respondendo a tíquetes, alertas e e-mails é entediante e chato. E, acima de tudo, porque seu tempo vale muito.

Como engenheiro de monitoramento de sistemas, meu segundo passatempo favorito é saber como meus colegas respondem à pergunta: “Como você sabe que há algo errado?”. Essa pergunta os obriga a definir ruim para si mesmos, o que leva a um bom processo de monitoramento e alerta de data center. Mas meu passatempo favorito é perguntar: “E aí? Quando é ruim, como você acabou de descrever, o que você faz a respeito?”.

A resposta a essa pergunta é a base da conversa que leva à automação.

Talvez, depois de receber um alerta, eles limpem uma fila, reiniciem um serviço ou excluam todos os arquivos de um diretório temporário.

Qualquer que seja a medida tomada, é muito provável que ela possa ser executada sem intervenção humana; isso se supormos que a ação já não está incorporada à ferramenta de monitoramento. É por isso que soluções de monitoramento sofisticadas permitem criar um alerta que acione uma medida inicial e, em seguida, aguardam por um tempo especificado. Se a condição persistir, uma segunda (ou terceira, quarta etc.) medida será acionada.

Mas digamos que não exista uma ação definitiva para resolver o problema. Talvez, a resposta seja verificar as últimas 15 linhas de um determinado arquivo de log, analisar outro contador e executar uma consulta de teste do servidor de aplicativos para o banco de dados. Então, com base nos resultados dessas informações, você saberá o que fazer. Nesse caso, a ação automatizada será seguir todas as etapas e inserir os resultados na mensagem de alerta. Isso significa que você receberá um tíquete que já contém um insight preciso das condições no momento da falha, e não 15 minutos mais tarde, depois de você se arrastar da cama até o laptop e começar a analisar a situação.

Pode acreditar: você e seu sistema de monitoramento serão heróis se fizerem isso.

Agora que entendemos melhor por que a automação é uma boa ideia, vamos analisar algumas áreas em que a automação oferece um valor sólido e mensurável à disciplina de monitoramento no setor de TI.

Descoberta: primeira parte

Uma das suas primeiras ações ao ativar um novo sistema de monitoramento é carregar dispositivos. Embora isso possa ser feito manualmente por meio da especificação do nome ou do endereço IP das máquinas e informações de conexão, em qualquer data center que tenha mais de 20 sistemas, essa tarefa será tediosa e frustrante. Realizar a varredura é algo muito mais conveniente e que produz uma visão completa do ambiente. Por cerca de uma semana.

Depois disso, em data centers com mais de 20 sistemas, é bem provável que alguns sistemas tenham sido adicionados, alterados ou removidos. Ativar manualmente varreduras do ambiente se torna impraticável depois da terceira semana. Geralmente, é nesse ponto que nasce o desejo de utilizar a automação.

Conectividade

Descobrir vários dispositivos é bom, mas saber como eles se conectam é melhor. Por quê? Imagine um cenário simples em que um roteador está conectado a dois switches que, por sua vez, estão conectados a 10 servidores. Se o roteador ficasse inoperante, quantos alertas de dispositivo inoperante você deveria receber? Exatamente: um. Apenas um. Sobre o roteador.

Mas quantos alertas você receberá de fato?

Se respondeu 10 (sobre os servidores), 12 (sobre os servidores e os switches) ou qualquer número maior que um, você pode estar certo e, ao mesmo tempo, muito errado.

A solução é configurar uma supressão downstream para que, quando o roteador ficar inoperante, os demais dispositivos downstream sejam colocados em um estado inacessível (ou seja, um estado diferente do inoperante). Embora isso possa ser feito manualmente, é muito melhor quando a automação faz tudo para você.

Descoberta: segunda parte

Tudo bem, digamos que você tenha encontrado todos os dispositivos escondidos no data center. Você realizou uma varredura para saber como eles se conectavam. Você estabeleceu a hierarquia de virtualização, da VM para o host, para o cluster e para o data center. Você até determinou que tipo de hardware cada dispositivo é, quantas interfaces e unidades cada um tem, bem como o status do hardware físico, como ventiladores, sensores de temperatura, controladores de RAID etc. Você está com tudo planejado.

Só falta descobrir qual desses benditos dispositivos é a máquina com o Exchange.

É isso mesmo. Essa descoberta tem tudo a ver com software. Assim como em “Descoberta: primeira parte”, o foco aqui não é tanto o modo, mas com que frequência isso é feito. Porque é claro que você pode realizar uma varredura em um servidor ao adicioná-lo ao sistema e determinar se ele está executando o Exchange, o SharePoint ou o aplicativo personalizado da empresa, mas você nunca saberá (até ser tarde demais) que três semanas depois, o desenvolvedor do aplicativo habilitou o IIS; ou pior, o DHCP.

Talvez você precise ainda mais de automação para procurar aplicativos do que para procurar serviços novos, alterados ou excluídos. Mas é mais complicado que isso.

Atribuições

Uma coisa é saber que o servidor está executando o IIS (ou o DHCP, o SharePoint etc.). Entender como a empresa avalia o servidor é outra coisa bem diferente. É uma máquina importante com SharePoint ou apenas um servidor de controle de qualidade? É uma nova compilação que está sendo testada ou já está funcionando com produtividade total?

Em muitas organizações, os servidores passam por um processo de compilação e teste antes de ir para produção. Na outra extremidade do ciclo, um servidor pode passar um tempo significativo em um estado de desativação, ou seja, ele permanece em execução, mas só é usado em emergências. Da mesma forma, algumas empresas têm sistemas que poderiam migrar de teste para controle de qualidade e produto e/ou de volta para teste.

Em cada um desses casos, a intensidade do monitoramento pode mudar drasticamente.

Portanto, a oportunidade de automação aqui não é tanto a detecção, mas a aplicação dos modelos corretos com base em variáveis personalizadas. Você deseja capacitar as equipes do proprietário para que elas possam definir esses atributos e, em seguida, deixar o sistema de monitoramento detectar as definições e ajustar o monitoramento automaticamente de acordo com elas.

Por fim, há o sistema de alertas

Depois de tudo isso, nós finalmente completamos o ciclo e voltamos aos alertas. A essa altura, presumo que você já tenha entendido o conceito por trás das ações de alerta automatizadas. O que precisamos agora é começar a nos aprofundar. Oferecer o que prometemos.

Qual é a próxima etapa?

A boa automação é possível graças ao bom monitoramento. Quando feita corretamente, a automação é uma solução elegante e simples. E o que é ainda mais importante, não é uma coisa artesanal; é automação do jeito que deve ser. No final das contas, o único limite para monitoramento e automação é sua capacidade de imaginar e implementar, desde que você tenha uma boa ferramenta de monitoramento.