Executar o ajuste contínuo para reduzir os alertas sem sentido
Nesta unidade, você aprenderá sobre os processos que podem ser implementados para monitorar a confiabilidade do site. Você também aprenderá sobre o ajuste contínuo de seus alertas para reduzir alertas sem sentido.
Monitoramento e alertas
O monitoramento e o alerta permitem que um sistema informe as pessoas quando ele está com defeito ou está prestes a ficar com defeito. Se alguém precisar investigar o problema, o alerta deverá fornecer informações relevantes para que a pessoa saiba por onde começar.
Ao examinar os alertas existentes ou escrever novas regras de alerta, considere estas diretrizes para manter seus alertas relevantes e sua rotação durante a chamada mais satisfeita:
- Alertas que chamam a atenção de um humano devem ser urgentes, importantes, orientados a ações e reais.
- Os alertas devem representar problemas contínuos ou iminentes com o serviço.
- Remova os alertas com ruído. O monitoramento excessivo é um problema mais difícil de resolver do que o submonitoramento.
- Classifique o problema em uma destas categorias:
- Disponibilidade e funcionalidade básica.
- Latency.
- Exatidão.
- Problemas específicos de recursos.
- Os sintomas são uma forma melhor de capturar problemas de modo abrangente e robusto com menos esforço.
- Inclua informações baseadas em causas em páginas baseadas em sintoma ou em painéis, mas evite alertas diretamente nas causas.
- Quanto mais detalhada for sua pilha de serviços, mais problemas distintos você vai capturar em uma só regra. Mas não exagere de modo a não conseguir distinguir o suficiente o que está acontecendo.
- Se você deseja uma rotação durante a chamada silenciosa, tenha um sistema para lidar com problemas que precisam de uma resposta em tempo hábil, mas que não são iminentemente críticos.
Monitoramento para os usuários
O monitoramento para seus usuários também é chamado de monitoramento baseado em sintoma. Isso está em contraste com o monitoramento baseado em causa. Os usuários não se preocupam se o push de dados está falhando, eles se preocupam com seus resultados estarem atualizados.
Em geral, os usuários se preocupam com:
- Disponibilidade básica e correção: qualquer coisa que interrompa o serviço principal de alguma forma deve ser categorizada como indisponibilidade.
- Latência: as páginas devem ser carregadas rapidamente.
- Integridade, atualização e durabilidade: Os dados de seus usuários devem estar seguros, devem retornar prontamente e os índices de pesquisa devem estar atualizados.
- Tempo de atividade: mesmo que o serviço esteja temporariamente não disponível, os usuários deverão ter confiança total de que o serviço voltará a estar ativo em breve.
- Funcionalidade: os usuários se preocupam com o funcionamento de todos os recursos do serviço. Monitore quanto qualquer item que seja um aspecto 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 ficarem não disponíveis e os dados do usuário ficarem não disponíveis. O primeiro é uma causa imediata, o segundo, um sintoma.
Os alertas baseados em causa têm seu lugar
Às vezes, não há sintoma para alertar, mas você ainda precisa ser alertado sobre uma situação. Um exemplo é ficar com pouca memória. Você deseja que as regras notifiquem você sobre questões que podem se tornar um problema antes que causem um sintoma. Nesse caso, você pode escrever uma regra para alertar sobre essa condição.
No entanto, não escreva regras baseadas em causas que disparem alertas na chamada para sintomas que você possa detectar de outra forma.
Tíquetes, relatórios e email
Alertas que precisam de atenção em breve, mas não imediatamente, são alertas subcríticos. Aqui estão algumas sugestões para o registro em log de alertas subcríticos para acompanhamento posterior:
- Os sistemas de rastreamento de bug ou tíquete podem ser úteis para este tipo de alerta: um alerta pode abrir um bug, desde que o mesmo alerta seja colocado corretamente em um único tíquete ou bug. Esses bugs podem então passar por um processo de triagem para serem atribuídos a alguém para acompanhamento. É importante que esses tipos de problemas sejam resolvidos antes de se tornarem críticos. Leve em consideração quanto tempo dos membros da equipe pode ser dedicado a corrigir o bug.
- 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 mostra todos os alertas ativos. Atribua alguém para fazer a triagem deste relatório diariamente.
- Cada alerta deve ser rastreado por meio de um sistema de fluxo de trabalho: isso garante que eles sejam vistos e tratados.
Em geral, crie um sistema que promova a responsabilidade pela capacidade de resposta, mas não tenha o alto custo de intervenção humana imediata.
Guias estratégicos
Os guias estratégicos, às vezes chamados de runbooks, são uma parte importante de um sistema de alertas. Tenha uma entrada no guia estratégico que explique o que fazer para cada alerta ou família de alertas que captam um sintoma.
Acompanhamento e responsabilidade
Se alguém receber um alerta e determinar que não há nada de errado, você precisará remover a regra, rebaixá-la ou coletar dados de alguma outra maneira. Alertas com precisão inferior a 50% são considerados com defeito. Mesmo aqueles que disparam falsos positivos 10% das vezes merecem reavaliação.
Ter uma revisão semanal de todos os alertas acionados por chamada e analisar as estatísticas de alerta trimestral pode ajudá-lo a ver padrões que não são percebidos ao focar alertas individuais.
Quando buscar a exceção à regra?
Aqui estão alguns motivos pelos quais você pode não seguir as diretrizes acima:
Você tem uma causa conhecida que, na verdade, fica abaixo do ruído em seus sintomas: por exemplo, se seu serviço tiver 99,99% de disponibilidade, mas você tiver um evento comum que causa falha em 0,001% das solicitações, não será possível alertá-lo como um sintoma porque está no ruído, mas você pode captar o evento causador.
Você não pode monitorar no ponto de entrada porque perde a resolução dos dados: por exemplo, você tolera alguns pontos de extremidade lentos, como validação de cartão de crédito. Em seus balanceadores de carga, essa distinção pode ser perdida. Você precisará percorrer a pilha e alertar do lugar mais alto em que há a distinção.
Seus sintomas não aparecem até que seja tarde demais: por exemplo, você esgotou a cota. Você precisa alertar alguém antes que seja tarde demais e, às vezes, isso significa encontrar uma causa com relação à qual alertar. Por exemplo, seu uso é superior a 80% e se esgotará em menos de quatro horas na 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, sua cota está acima de 90% e vai se esgotar em menos de quatro dias à taxa de crescimento do último dia. Esse conjunto de circunstâncias detectará a maioria dos casos. Você então pode lidar com o problema como um alerta por email ou tíquete ou um relatório de problema diário, em vez do escalonamento de última instância que um alerta representa.
Sua configuração de alerta é mais complexa do que os problemas que está tentando detectar: o objetivo deve ser avançar para sistemas simples, robustos e autoprotetores.