Concrete Logo
Hamburger button

(2+2) Utilizando Alarmes, 5 dicas para uma gestão eficaz

  • Blog
  • 23 de Dezembro de 2014
Share

Para quem está acostumado a monitorar sistemas em produção sabe que a gestão de alarmes pode ser a diferença entre o sucesso e o fracasso de uma implantação.
Sem a configuração adequada de alarmes, sistemas podem ficar fora do ar por um tempo significativo e provocar perdas bem maiores do que teríamos apenas lidando com a causa original do problema. Um alarme mal configurado pode gerar milhares de avisos indesejados e simplesmente enlouquecer sua equipe.
Então vamos lá, estes são os meus top 5 para a gestão de alarmes…

A. Alarmes são feitos para seres humanos

Não adianta imaginar alarmes, políticas e processos sem levar em conta o fator humano. É preciso considerar se as ferramentas que temos disponíveis são adequadas para as pessoas e para a situação de stress gerada quando um alarme está tocando e te avisando de um problema em PROD.
Tenha certeza de que as ferramentas necessárias para resolver os problemas estão disponíveis e são fáceis de usar. Tenha certeza de que o alarme dá informações precisas e de forma simples.
Precisamos olhar para o alarme, entender o que está acontecendo e conseguir reagir rapidamente para lidar com a situação.

B. Quando houver um problema, o alarme tem que tocar

Parece óbvio, mas é um dos problemas mais comuns na gestão de sistema de software. Muitas vezes passamos tempo demais pensando em como fazer o software e encantar nossos clientes e tempo de menos pensando que temos que manter o software rodando.
Tente mapear, durante a criação do software, quais são as condições críticas de erro, e como lidar com cada uma delas. É importante que possamos verificar as situações de erro de forma programática no ambiente de produção.
A última coisa que podemos querer é chegar na 2a feira de manhã para trabalhar e descobrir que o sistema estava fora do ar e nossos clientes estão, digamos, chateados.
Se o sistema parar, ou estiver funcionando de forma errada, precisamos saber imediatamente.

Tente identificar de forma automatizada situações que facilitem a atuação da monitoria, ou seja, os alarmes precisam ser relativamente específicos.

Ok, what do I do with this ?

C. Quando o alarme tocar, deve ter um problema

No item anterior, de certa forma, estávamos falando sobre “falso negativo”, que ocorre quando fazemos um teste e este teste não aponta um resultado. Ou seja, nessa hipótese, o seu código que verifica as condições de erro te diz que não há erro, mas infelizmente o erro existe e não sabemos.
Nesse item, estamos falando do falso positivo. O alarme está tocando, seu time recebeu email, SMS ou sinal de fumaça dizendo que o sistema está com erro, mas quando o time vai verificar, percebe que está tudo normal.
Os casos de falso positivo acabam diminuindo a credibilidade do seu alarme. Como consequência, a equipe começa a ignorar os avisos, pensando que é apenas mais um alarme falso. Exatamente como na fábula de Esopo sobre o menino e o lobo.

Ao tentar diminuir os casos de falsos positivos, podemos também, inadvertidamente, retirar uma condição real de problema dos alarmes e, com isso, transformamos um caso de falso positivo no caso anterior.
Geralmente é melhor termos um falso positivo que um falso negativo, então antes de ligar um alarme ou relaxar uma condição de testes, pense se essa alteração vai fazer com que você não veja um problema efetivo no sistema.
Veja mais sobre Binary Classification.

D. Alarmes precisam de ações

Não adianta o alarme tocar e te acordar no meio da noite se não houver nada que possamos fazer. Nesse caso, melhor não ver o alarme e ter uma boa noite de sono.
Um alarme faz sentido quando ele é actionable, ou seja, quando podemos agir ao saber do evento.
Por exemplo, o processador de um servidor bate 100%. Isso pode ser sinal de problemas, e seria bom saber quando isso acontece para agirmos, olharmos os processos e vermos se tem algum que não está se comportando bem.
Ao mesmo tempo, podemos ter situações em que seu servidor está executando uma tarefa em batch, nas quais gostaríamos que ficasse com o processador em 100%. Talvez, quando este job rodar de madrugada, o processador sempre fique em 100% durante alguns minutos, ou com o comportamento esperado.
Assim, se colocarmos um alarme para nos avisar quando o processador fica em 100%, vamos acordar todos os dias sem motivo. Não há nada para fazer com relação ao serviço rodando de madrugada. Acordamos sem motivo.
Está claro que, para o caso em que esperamos uma situação anormal o alarme não deveria tocar. Em compensação, em outros momentos a mesma situação precisa obter nossa atenção.

Tell me what you CAN do

No caso extremo, considere que nem sempre é a mesma equipe que apaga todos os incêndios. Tem casos que não podemos fazer mais do que observar a floresta queimando e esperar que a guarda nacional consiga resolver o problema…

Burning Forest

E. Monitoramento é uma questão contínua

Depois de acertarmos os alarmes e a monitoria podemos nos sentir relaxados e a tendência é até mesmo nos esquecermos de que as condições na qual os sistemas funcionam também mudam com o tempo.

Camels on the Beach
Photo used under Creative Commons from David Sh.

Acontece que as condições mudam, os volumes de dados tratados aumentam, os arquivos de log podem crescer, as tabelas podem ficar com índices desatualizados, alguma coisa na manutenção pode não estar automatizada, etc.
Então, minha última dica é criar uma rotina de verificação dos seus próprios instrumentos. Marque para cada ambiente uma frequência de verificação, digamos, uma vez por mês.
A intenção é revisar o ambiente, olhar os alarmes, olhar os sistemas de monitoria, e pensar se os alarmes estão adequados e se vale a pena criar mais algum tipo de automação ou monitoria.
E é isso, relaxe e aproveite a vida. Se alguma coisa acontecer, o seu sistema vai te avisar!

Cat sleeping over keybord
Sleeping cats on designswan.