Alertas bem elaborados

Alertar é o que nos notifica quando um problema surge ou está prestes a surgir, para que a ação possa ser tomada.

Criar alertas oportunos e significativos não são fáceis, mas são necessários, já que as pessoas tendem a ignorar os alertas quando sentem que não são precisos .

Alertas são problemas

Primeiro, alertas que requerem a atenção de um humano, muitas vezes conhecido como Pages, ou também aqueles alertas que vão acordar alguem de madrugada ou tirar a atenção de alguem durante o dia devem ser urgentes, importantes, passiveis de ação e reais. O problema de ter o over-monitoring ou mais alertas do que podemos controlar significa que que os analistas responsaveis vão parar de dar atenção para os alertas, ignorar eles quando acontecerem.

Um resumo é que um alerta tem que representar um PROBLEMA, e esse problema deve ter uma ação relacionada a ele. As ações podem ser conduzir uma investigação, alguma ação como remover um servidor defeituoso do balanceamento, criar uma ação de bugfix, ou até mesmo disparar uma ação de capacity planning.

Alertas bem elaborados

• Precisão :
  • Basicamente é a taxa de verdadeiro positivo
  • 100% de precisão significa que cada alerta corresponde a um evento significativo.
• Recall :
  • 100% de recall significa que todo evento significativo gerou um alerta.Ou seja, com isso não temos eventos significativos acontecendo que não estamos alarmando.
  • Ele é a proporção de eventos significativos que são detectados e transformados em alertas. 
• Tempo de detecção :
  • Quanto tempo leva para uma condição ser detectada e transformada em alertas
• Tempo de reinicialização :
  • Quanto tempo leva para que os alertas parem de disparar depois que a condição raiz for resolvida.
• Alertas baseados em sintomas
  • Seus usuários se importam se seus servidores MySQL está com alto consumo de CPU? Não, eles se importam se suas consultas estão demorando
  • Seus usuários se importam se um binário de suporte (ou seja, caminho sem serviço) está em um loop de reinicialização? Não, eles se importam se seus recursos estão falhando.
  • Os usuários, em geral, se preocupam com um pequeno número de coisas:
    • Disponibilidade e correção básicas. sem “Oops!”, sem 500s, sem solicitações travadas ou páginas carregadas pela metade ou Javascript ou CSS ausentes ou imagens ou vídeos. Qualquer coisa que interrompa o serviço principal de alguma forma deve ser considerada indisponibilidade.
    • Latência. Rápido, mas somente o suficiente.
    • Completude/frescura/durabilidade. Os dados de seus usuários devem estar seguros, devem retornar quando você solicitar e os índices de pesquisa devem estar atualizados. Mesmo que esteja temporariamente indisponível, os usuários devem ter total fé de que ele voltará.
    • Features. Seus usuários se preocupam que todos os recursos do serviço funcionem – você deve monitorar qualquer coisa que seja um aspecto importante do seu serviço, mesmo que não seja a funcionalidade/disponibilidade principal
• Runbooks
  • Importante que os alertas tenham playbooks ou runbooks, com informações sobre o que fazer, diagramas, informações sobre logs, dashboards etc. Devemos desenvolver sistemas como se quando eles derem problema seremos acordados a noite, e para evitar o esforço cognitivo de quem esta acabando de acordar eles devem conter bons runbooks, com os problemas conhecidos e melhores praticas de throbleshotting.
• Rastreaveis
  • Os alertas precisam ser rastreáveis. Precisamos conseguir chegar facilmente na fonte do alerta.