Execute ajustes contínuos para reduzir alertas sem significado

6 minutos

Nesta unidade, você aprende sobre os processos que podem ser implementados para monitorar a confiabilidade do site. Você também aprende sobre o ajuste contínuo de seus alertas para reduzir alertas sem sentido.

Monitorização e alertas

O monitoramento e o alerta permitem que um sistema diga às pessoas quando está quebrado, ou talvez para dizer-lhes o que está prestes a quebrar. Se alguém precisar investigar o problema, o alerta deve fornecer informações relevantes para que a pessoa saiba por onde começar.

Ao revisar alertas existentes ou escrever novas regras de alerta, considere estas diretrizes para manter seus alertas relevantes e sua rotação de plantão mais feliz:

Os alertas que acionam a atenção de um ser humano devem ser urgentes, importantes, orientados para a ação e reais.
Os alertas devem representar problemas contínuos ou iminentes com o seu serviço.
Remova alertas barulhentos. A monitorização excessiva é um problema mais difícil de resolver do que a submonitorização.
Classifique o problema em uma destas categorias:
- Disponibilidade e funcionalidade básica.
- Latência.
- Exatidão.
- Problemas específicos de recursos.
Os sintomas são uma maneira melhor de capturar os problemas de forma abrangente e robusta com menos esforço.
Inclua informações baseadas em causas em páginas baseadas em sintomas ou em painéis, mas evite alertar diretamente sobre as causas.
Quanto mais acima sua pilha de serviço você for, mais problemas distintos você pega em uma única regra. Mas não vá tão longe que você não consiga distinguir suficientemente o que está acontecendo.
Se você quiser um rodízio silencioso de plantão, tenha um sistema para lidar com problemas que precisam de uma resposta em tempo hábil, mas não são iminentemente críticos.

Monitorize os seus utilizadores

O monitoramento para seus usuários também é chamado de monitoramento baseado em sintomas. Isto contrasta com a monitorização baseada em causas. Seus usuários não se importam se o envio de dados está falhando, eles se preocupam se os resultados são novos.

Em geral, os usuários se preocupam com:

Disponibilidade básica e correção: Qualquer coisa que quebre o serviço principal de alguma forma deve ser categorizada como indisponibilidade.
Latência: as páginas devem ser carregadas rapidamente.
Exaustividade, atualidade e durabilidade: os dados dos seus utilizadores devem estar seguros, devem voltar imediatamente e os índices de pesquisa devem estar atualizados.
Uptime: Mesmo que o serviço esteja temporariamente indisponível, os usuários devem ter total fé de que o serviço será retomado em breve.
Recursos: Seus usuários se preocupam que todos os recursos do serviço funcionem. Monitore qualquer coisa que seja um aspeto importante do seu serviço, mesmo que não seja a funcionalidade principal.

Há uma diferença sutil, mas importante, entre os servidores de banco de dados estarem indisponíveis e os dados do usuário estarem indisponíveis. A primeira é uma causa imediata, a segunda é um sintoma.

Os alertas baseados em causas têm o seu lugar

Às vezes, não há nenhum sintoma para alertar, mas você ainda precisa ser alertado para uma situação. Um exemplo é a falta de memória. Você quer que as regras notifiquem você sobre problemas que podem se tornar um problema antes que eles causem um sintoma. Nesse caso, você pode escrever uma regra para alertar sobre essa condição.

No entanto, não escreva regras baseadas em causa que disparem alertas de chamada para sintomas que você pode detetar de outra forma.

Tickets, relatórios e e-mail

Alertas que precisam de atenção em breve, mas não imediatamente, são alertas subcríticos. Aqui estão algumas sugestões para registrar alertas subcríticos para acompanhar mais tarde:

Sistemas de rastreamento de bugs ou tíquetes podem ser úteis para esse tipo de alerta: um alerta pode abrir um bug, desde que o mesmo alerta seja colocado corretamente em um único ticket ou bug. Esses bugs podem passar por um processo de triagem para serem atribuídos a alguém para acompanhar. É importante que esses tipos de problemas sejam abordados antes de se tornarem críticos. Tenha em conta quanto do tempo dos membros da sua equipa pode ser dedicado à correção de bugs.
Um relatório diário (ou mais frequente) pode ser útil: escreva alertas subcríticos de longa duração, por exemplo, o banco de dados está mais de 90% cheio, em um relatório que mostre todos os alertas ativos. Designe alguém para fazer a triagem diária deste relatório.
Todos os alertas devem ser rastreados através de um sistema de fluxo de trabalho: isso garante que eles estão sendo vistos e endereçados.

Em geral, criar um sistema que promova a responsabilização pela capacidade de resposta, mas não tenha o alto custo da intervenção humana imediata.

Manuais de Procedimentos

Playbooks, às vezes referidos como runbooks, são uma parte importante de um sistema de alerta. Tenha uma entrada no manual que explique o que fazer para cada alerta ou família de alertas que detetam um sintoma.

Acompanhamento e responsabilização

Se alguém receber um alerta e determinar que não há nada de errado, isso é um sinal de que você precisa remover a regra, rebaixá-la ou coletar dados de alguma outra forma. Os alertas com menos de 50% de precisão são considerados quebrados. Mesmo aqueles que desencadeiam falsos positivos 10% das vezes merecem reavaliação.

Ter uma revisão semanal de todos os alertas de plantão acionados e analisar estatísticas de alertas trimestrais pode ajudá-lo a ver padrões que se perdem quando se concentra em alertas individuais.

Quando buscar a exceção da regra?

Aqui estão algumas razões pelas quais você pode quebrar as diretrizes acima:

Você tem uma causa conhecida que realmente fica abaixo do ruído em seus sintomas: Por exemplo, se o seu serviço tem 99,99% de disponibilidade, mas você tem um evento comum que faz com que 0,001% das solicitações falhem, você não pode alertá-lo como um sintoma porque está no ruído, mas você pode capturar o evento causador.
Você não pode monitorar no ponto de entrada porque perde a resolução de dados: por exemplo, você tolera que alguns pontos de extremidade sejam lentos, como a validação de cartão de crédito. Em seus load balancers, essa distinção pode ser perdida. Você precisará descer a pilha e alertar a partir do lugar mais alto onde você tem a distinção.
Seus sintomas não aparecem até que seja tarde demais: por exemplo, você ficou sem cota. Você precisa alertar alguém antes que seja tarde demais, e às vezes isso significa encontrar uma causa para alertar. Por exemplo, a sua utilização é superior a 80% e esgotar-se-á em menos de quatro horas à taxa de crescimento da última hora.

No entanto, você também deve ser capaz de encontrar uma causa semelhante que seja menos urgente. Por exemplo, a sua quota é superior a 90% e esgotar-se-á em menos de quatro dias à taxa de crescimento do último dia. Esse conjunto de circunstâncias irá apanhar a maioria dos casos. Em seguida, você pode lidar com o problema como um alerta de tíquete ou e-mail ou relatório diário de problemas, em vez do escalonamento de última vala que um alerta representa.
Sua configuração de alerta é mais complexa do que os problemas que está tentando detetar: o objetivo deve ser avançar para sistemas simples, robustos e autoprotetores.