Alertas acionáveis
Neste módulo até agora, exploramos maneiras de pensar, medir e interagir com a confiabilidade de nossos sistemas. Mas há também uma maneira como a fiabilidade interage connosco através de nós: 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 antes. O Azure também pode enviar alertas baseados em problemas de serviço através da funcionalidade Azure Service Health.
Com o poder de enviar alertas facilmente, surge um perigo potencial. E é aí que entra em cena a palavra sustentável na definição SRE que vimos antes:
Engenharia de Confiabilidade de Site é uma disciplina de engenharia dedicada a ajudar as organizações a alcançar de forma sustentável o nível apropriado de confiabilidade em seus sistemas, serviços e produtos.
Os alertas são projetados para notificá-lo quando houver 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ável. É possível inviabilizar todo o esforço que você fez para trazer SLIs e SLOs para sua organização se isso se traduzir em uma tempestade de alertas para sua equipe. A fadiga de alerta é uma doença bem conhecida na comunidade de operações. Esta unidade tem como objetivo ajudá-lo a evitar que isso ocorra na sua organização.
Um dos principais contribuintes para a fadiga de alerta são os alertas que não são acionáveis. Vamos aprender a evitar a sua criação.
O que são (e não são) alertas
Para entender por que alertas ruins podem criar um problema, você precisa pensar sobre a finalidade dos alertas e como eles diferem de outros sinais operacionais.
Os alertas acionáveis não são:
Logs: Alertas não são registros de eventos; Esse é um trabalho para logs. Se você estiver apenas tentando registrar que um evento aconteceu, escreva-o em um arquivo de log, não em um pager.
Notificações: Os alertas não se destinam a anunciar ocorrências não críticas, como a conclusão de uma compilação de software. Você não deveria ter que interromper alguém, quebrando sua concentração e foco, apenas para entregar uma notícia.
Heartbeats: Os alertas não devem ser usados como um lembrete de que seu sistema ainda está funcionando. Já vimos situações em que as pessoas dizem "Oh, se eu não recebo pelo menos uma página desse sistema a cada hora, sei que algo está errado e tenho que lidar com isso". Esta é uma péssima ideia.
Os alertas acionáveis são usados para situações em que você precisa de um humano para investigar e intervir para remediar o problema. Os alertas devem ser comunicações de que algo excecional ou inesperado aconteceu exigindo a atenção de alguém.
Se o evento for algo que o sistema pode lidar por meio de processos automatizados, como dimensionar recursos dentro de um limite predefinido, um alerta não é necessário. O sistema deve apenas lidar com isso e escrever uma linha em um log. Não deve chamá-lo às 2 da manhã para lhe dizer que houve uma situação que foi resolvida com sucesso.
Crie alertas acionáveis
Para que um alerta possa ser acionado, tem de ter:
Simplicidade: Você não quer fazer um alerta que exija que o destinatário tenha que se confundir antes de saber o que fazer. Se o alerta for muito complexo, a pobre pessoa que acabou de ser acordada no meio da noite vai perder um tempo valioso apenas tentando descobrir o que isso significa.
Escopo: Uma das primeiras coisas que uma pessoa que recebe a mensagem terá que fazer para poder triá-la efetivamente é determinar o escopo do problema. O problema é com um único servidor? Um serviço? Uma região inteira? Em todo o mundo? Para facilitar a vida do 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 mergulhar mais nesta parte.
Fornecer contexto no alerta
Vejamos alguns elementos que um alerta acionável deve sempre incluir para que os destinatários tenham o contexto de que precisam:
De onde vem o alerta? Muitas organizações têm vários sistemas de monitoramento em uso ao mesmo tempo e um grande número de sistemas interconectados. Pode poupar muito tempo a alguém se o alerta disser "Este alerta para o sistema de folha de pagamento THX-1138 vem da subscrição 'prod' do Azure Monitor."
Que expectativa foi violada? Um alerta que apenas descreva o estado atual das coisas não é tão útil quanto poderia ser. Compare "o servidor de banco de dados está sendo executado a 80% de carga" com "o servidor de banco de dados está sendo executado a 80% de carga nas últimas duas horas, quando deveria estar sendo executado a 60% de carga ou menos."
Por que isso é um problema (para o cliente)? A informação sobre o efeito ou impacto que a situação teve ou potencialmente terá no cliente dá-nos uma forma de determinar a importância e avaliar adequadamente a nossa reação.
Quais são os próximos passos a dar? Se possível, o alerta deve incluir o que a pessoa que está respondendo deve fazer em seguida, mesmo que isso seja um indicador para um guia de solução de problemas ou alguma outra documentação para encontrar ajuda no diagnóstico e correção desse problema.
Incluir esse contexto útil e trabalhar para tornar seus alertas acionáveis pode tornar as práticas operacionais mais sustentáveis e facilitar a resposta a esses alertas.