Se você já trabalhou com TI por mais de dez minutos, sabe que as coisas saem errado. Na verdade, deveria ser óbvio que temos empregos em TI justamente porque as coisas saem errado.

E é disso que o monitoramento e a automação de TI tratam: criar sistemas que se cuidem automaticamente, avisem quando as coisas começam a dar errado e forneçam as informações necessárias sobre o que aconteceu e quando, de modo que você possa evitar o mesmo problema no futuro.

Após mais de uma década implementando sistemas de monitoramento em empresas de grande e pequeno porte, me familiarizei com o que se poderia chamar de “luto do monitoramento”, algo que ocorre com frequência quando você é incumbido de monitorar alguma coisa para outra pessoa – o que é quase inevitável – e essa pessoa lhe pede para fazer coisas que você sabe que causarão problemas. Ele envolve uma série de comportamentos que agrupei em cinco estágios. São como os cinco estágios do luto, só que no monitoramento.

Embora as empresas passem com frequência por esses estágios ao implantarem o monitoramento pela primeira vez, eles também podem ocorrer quando um grupo ou departamento começa a implementar seriamente uma solução existente, quando novos recursos são adicionados a um conjunto de monitoramento atual ou simplesmente em um dia qualquer.

E aqui vou entregar o final da história: se você está familiarizado com o modelo Kubler-Ross padrão, sabe que a aceitação não consta nesta lista.

Primeiro estágio: monitorar tudo

Trata-se da falta de decisão inicial quanto ao monitoramento, uma resposta à pergunta simples e inocente: “O que preciso monitorar?”. A opção favorita de gerentes e equipes que não irão de fato lidar com o tíquete é simplesmente ligar a mangueira de incêndio com força máxima e pedir que você monitore “tudo”. Essa escolha também é feita com frequência por administradores que estão bem no meio de uma catástrofe. Essa decisão parte do pressuposto de que toda a informação é útil e pode ser “ajeitada” posteriormente.

Segundo estágio: momento Prozac

Ainda nos moldes do primeiro estágio, o destinatário de 734 e-mails de alerta de monitoramento recebidos em um intervalo de cinco minutos vem até você e diz: “Tudo isso não pode estar dando errado ao mesmo tempo!” Embora pareça correta a princípio, essa afirmação ignora o fato de que um computador define “dar errado” com o mesmo grau de especificidade dos humanos que solicitaram os monitores. Dessa forma, você reduz as coisas a proporções razoáveis, mas, ainda assim “coisas demais” estão indicadas em vermelho e a reação continua a mesma.

O pior é que, como o “monitoramento era ruim” antes – o que, logicamente, foi decorrência de uma solicitação estúpida – ele deve estar errado novamente. Só que desta vez não está. Ele está captando alterações em todos os níveis há semanas, meses ou anos, e ninguém reparou. Ou as falhas se corrigiram sozinhas muito rapidamente, ou os usuários nunca reclamaram, ou alguém em algum lugar se antecipou e consertou tudo.

Essa é a hora em que você gostaria de poder dar um Prozac para o responsável pelo sistema para ele relaxar e se dar conta de que saber sobre as interrupções é a primeira etapa para evitá-las no futuro.

Terceiro estágio: pintando as rosas de verde

O próximo estágio ocorre quando uma enorme quantidade de coisas permanecem “inativas” e, não importa o quanto você tente, nada as faz mudar para “ativas” porque, afinal de contas, elas estão mesmo inativas.

Em um impulso de orgulho e teimosia, o responsável pelo sistema com frequência ainda admite algo do tipo: “Eles não estão totalmente inativos; estão só ‘meio inativos’.” E mandam você fazer o que for preciso para que os sistemas se mostrem ativos/bons/verdes.

E com isso, quero dizer qualquer coisa mesmo, inclusive alterar os limites dos alertas para níveis impossíveis (“Alertar somente quando estiver inativo por 30 horas. Não, coloque uma semana.”), desativar alertas por completo – em uma ocasião, sob ameaça de perder o emprego – criar uma página completamente falsa com GIFs vermelhos pintados de verde para mostrar para a gerência sênior.

O que torna este estágio ainda mais constrangedor para todos os envolvidos é que o trabalho decorrente costuma ser maior do que a tarefa de realmente corrigir o problema.

Quarto estágio: uma verdade inconveniente

E por aí segue a rede de intrigas, que pode durar semanas ou meses, até o ponto em que ocorre um erro crítico que não pode ser disfarçado (nem no Photoshop). A essa altura, você e o responsável pelo sistema, estão no telefone com a equipe de restauração do serviço, mais uma dúzia de engenheiros e alguns altos executivos de TI, a fim de analisar, verificar e reiniciar tudo em tempo real.

Nesse momento, alguém pede para ver os dados de desempenho do sistema – aquele que está inativo há um mês e meio, mas que apareceu como “ativo” nos relatórios. Para um responsável por sistema que desenvolveu o hábito de comprar tinta verde por atacado, não dá mais para fugir ou se esconder.

Quinto estágio: burlando as regras

Supondo que o responsável pelo sistema permanceceu com seu cargo intacto até o quarto estágio, o quinto envolverá manter você à distância. As pessoas menos sofisticadas encontrarão maneiras de fazer o monitoramento sem de fato ter a inconveniência de realmente ter que monitorar, enquanto as pessoas que já estão na empresa há algum tempo solicitarão informações detalhadas sobre exatamente quais permissões você precisa para monitorar. Essas informações são encaminhadas para uma equipe de auditoria de segurança inevitavelmente nova que nega a solicitação categoricamente porque as permissões envolvem risco demais para serem concedidas.

A esta altura, você tem uma escolha: apresentar toda a documentação e insistir que recebeu as permissões que já tinham sido combinadas ou sair em busca de outro grupo que de fato queira o monitoramento.

E quanto ao responsável pelo sistema que começou dizendo “monitore tudo”? Não se preocupe. Ele estará de volta depois da próxima interrupção do sistema.

Com mais motivos para luto.