Alertas acionáveis
Neste módulo, até agora, exploramos maneiras de pensar, medir e interagir com a confiabilidade dos nossos sistemas. Mas existe também uma maneira de a confiabilidade interagir com nós: os alertas. É fácil configurar o Azure Monitor e outras ferramentas para enviar alertas com base em várias métricas e sinais, incluindo os SLIs e SLOs que vimos anteriormente. O Azure também pode enviar alertas com base em problemas do serviço por meio do recurso Integridade do Serviço do Azure.
O poder de enviar alertas com facilidade traz um perigo em potencial. E é aí que entre em cena a palavra sustentável da definição de SRE que vimos anteriormente:
a Engenharia de Confiabilidade do Site é uma disciplina de engenharia dedicada a ajudar as organizações a alcançarem de maneira sustentável o nível de confiabilidade apropriado nos sistemas, serviços e produtos.
Os alertas são projetados para notificá-lo quando existe um problema com seus sistemas. No entanto, quando os alertas são configurados incorretamente, isso pode prejudicar seu objetivo de criar uma prática de operações sustentáveis. É possível inviabilizar todo o esforço que você fez para trazer SLIs e SLOs para a sua organização se isso se traduzir em uma tempestade de alertas para o seu pessoal. A fadiga de alertas é uma doença bem conhecida na comunidade de operações. Essa unidade visa ajudar você a evitar que ela ocorra em sua organização.
Um dos principais Colaboradores da fadiga de alertas são os alertas que não são acionáveis. Vamos saber como evitar criar esses alertas.
O que são (e o que não são) os alertas
Para entender por que um sistema ineficaz de alertas pode criar problemas, você precisa pensar sobre a finalidade dos alertas e como eles diferem dos demais sinais operacionais.
Alertas acionáveis não são:
Logs: os alertas não são registros de eventos; esse é um trabalho para os logs. Se estiver apenas tentando registrar a ocorrência de um evento, escreva-o em um arquivo de log, não em um pager.
Notificações: os comunicados não se destinam a anunciar ocorrências não críticas, como a conclusão de uma construção de software. Você não precisa interromper alguém, atrapalhando sua concentração e foco, apenas para compartilhar uma informação.
Pulsações: os alertas não devem ser utilizados como um lembrete de que seu sistema ainda está em execução. Já vimos situações em que a pessoa diz algo como "Se eu não receber pelo menos uma página por hora desse sistema é porque algo está errado e precisa ser verificado". Essa é uma péssima ideia.
Alertas acionáveis são usados para casos que necessitam da intervenção humana para investigar e intervir a fim de corrigir problemas. Os alertas devem ser usados como notificações de que ocorreu algo excepcional ou inesperado que requer a atenção de alguém.
Se o evento for algo com que o sistema possa lidar por meio de processos automatizados, como a colocação em escala de recursos dentro de um limite predefinido, não será necessário um alerta. O sistema deverá apenas tratar o evento e gravar uma linha em um log. Não faz sentido ele enviar uma notificação para o seu pager às 2h da madrugada só para informar que uma situação atípica foi gerenciada com sucesso.
Criar alertas acionáveis
Para um alerta ser acionável, ele precisa ter:
Simplicidade: você não deseja fazer um alerta que exija que o destinatário tenha que se preocupar com ele antes de saber o que fazer. Se o alerta for muito complexo, a pobre pessoa que acabou de ser acordada no meio da noite perderá um tempo de importância tentando entender o que ele significa.
Escopo: uma das primeiras coisas que a pessoa que está recebendo a mensagem terá de fazer para poder fazer uma triagem eficaz é determinar o escopo do problema. O problema é com um só servidor? Um serviço? Uma região inteira? Em todo o mundo? Para facilitar para o destinatário, coloque essas informações no alerta.
Contexto: o que a pessoa que vai receber esse alerta precisa saber para começar a lidar com ele? Vamos nos aprofundar nessa parte.
Forneça o contexto no alerta
Vamos examinar alguns elementos que um alerta acionável deve sempre incluir para que o destinatário tenha acesso ao contexto necessário:
De onde está vindo o alerta? Muitas organizações têm vários sistemas de monitoramento em uso ao mesmo tempo, além de uma série de sistemas interconectados. Alguém pode economizar muito tempo se o alerta disser "Este alerta para o sistema de folha de pagamento THX-1138 está vindo da assinatura 'prod' do Azure Monitor."
Qual expectativa foi violada? Um alerta que apenas descreve o estado atual das coisas não é tão útil quanto poderia ser. Compare "O servidor de banco de dados está sendo executado com 80% da carga total" com "O servidor de banco de dados está sendo executado com 80% da carga total nas últimas duas horas, mas deveria estar sendo executado com 60% (ou menos) da carga total".
Por que isso é um problema (para o cliente)? Informações sobre o efeito ou o impacto que a situação teve ou poderá ter sobre o cliente permitem determinar a importância e avaliar adequadamente a reação.
Quais são as próximas etapas a serem executadas? Se possível, o alerta deve incluir o que a pessoa que está respondendo deve fazer em seguida, mesmo que seja um ponteiro para um guia de solução de problemas ou alguma outra documentação para ajudar você a diagnosticar e corrigir esse problema.
Incluir esse contexto útil e trabalhar para tornar seus alertas acionáveis pode tornar as práticas de operações mais sustentáveis e facilitar a resposta a esses alertas.