Sua equipe de engenharia está enfrentando fadiga de alerta? Faça estas 8 perguntas

A fadiga de alertas é um problema comum entre as equipes de engenharia que lidam com operações e mantêm a infraestrutura.

O problema geralmente decorre de uma abordagem aleatória para escrever alertas à medida que as equipes crescem e começam a usar mais infraestrutura de complexidade crescente. Isso é bastante normal – à medida que uma empresa ou equipe cresce, muitas vezes leva tempo para que uma cultura de observabilidade e práticas de alerta sólidas tomem forma.

É fácil criar alertas muito sensíveis, muito barulhentos e muito cautelosos. No início, tudo parece digno de alerta simplesmente porque é melhor ter cuidado e maximizar o sinal de produção nos estágios iniciais de um produto.

“À medida que o número e a complexidade dos recursos e da infraestrutura aumentam, melhorar os alertas geralmente está na lista de prioridades”

Naturalmente, essa abordagem não se adapta muito bem, mas à medida que o número e a complexidade dos recursos e da infraestrutura aumentam, a melhoria dos alertas geralmente fica muito abaixo da lista de prioridades. O resultado são muitos alertas semi-significativos, ruído, troca de contexto e multitarefa para o engenheiro de plantão. Em casos extremos, os colegas de equipe se esgotam, os alertas são ignorados e sua equipe de plantão passa da melhoria da qualidade do serviço para o combate constante a incêndios sem impacto significativo.

Como todas as empresas, a Intercom não está imune a essas ineficiências. Por isso, criamos um processo relativamente leve para combater a fadiga de alerta.

Como pensamos sobre a estratégia de alertas

O conceito de “disciplina de alerta” está no centro de manter os alertas sob controle. Assim como o trabalho de recursos, os alertas e a estratégia de alerta devem ser abordados de maneira deliberada e estruturada. Ao contrário do trabalho de recursos, no entanto, não é algo que possa ser bem planejado com antecedência.

Afinal, é altamente improvável que você consiga prever a integridade operacional e o ruído de seu novo recurso antes de enviá-lo. Você precisa monitorar os alertas de maneira regular e planejada para que o trabalho de alerta não chegue a níveis insustentáveis.

8 perguntas para fazer ao avaliar os alertas da sua equipe

Introduzimos sessões regulares de revisão de alertas para equipes que lidam com alertas frequentes. Inicialmente, eles ocorriam uma vez – ou várias vezes – por ciclo de engenharia de seis semanas, mas ficaram mais espaçados à medida que o estado dos alertas e monitores melhorou para um nível mais gerenciável.

Cada sessão de revisão de alertas começa com uma lista ordenada de alertas disparados no período anterior, ordenados por frequência de disparo. Usamos a plataforma PagerDuty como nossa fonte de alerta, e seus recursos de análise nos fornecem as informações necessárias para detalhar a frequência e a resposta dos alertas. Os alertas que mais contribuem para o ruído geral (ou seja, fogo com mais frequência) são revisados ​​primeiro.

Cada alerta é então passado por uma lista de verificação de perguntas:

1. O alerta ainda é relevante?

Quaisquer alertas acionados por sistemas desatualizados ou sem manutenção não devem incomodar o engenheiro de plantão e devem ser removidos imediatamente.

2. O alerta é acionável?

Se um engenheiro de plantão receber o alerta, ele pode fazer algo agora para corrigir ou melhorar a causa subjacente? Se o alerta não for acionável e útil, ele deverá ser removido. Um resumo semanal de problemas ou degradações de desempenho pode ser um local melhor para as informações no alerta.

3. As informações do alerta são imediatamente úteis, mesmo que não sejam acionáveis?

Podemos dividir as informações de alerta em duas grandes categorias.

• Sinais: Esses alertas avisam sobre um sistema operando no limite, mas não significam necessariamente que o serviço está sendo afetado. Um exemplo seria um dos seus servidores rodando a 100% da CPU. Se o serviço ainda estiver funcionando bem, o plantão deve gastar um tempo valioso investigando? Afinal, seu servidor está apenas funcionando com a melhor relação custo-benefício!
• Sintomas: esses alertas são acionados quando a experiência do cliente é afetada. Um exemplo aqui seria o número de erros HTTP 5XX que seu serviço está retornando aos chamadores.

Essas duas categorias funcionam melhor em conjunto. Uma pessoa de plantão deve reagir e solucionar os sintomas e olhar para os sinais apenas como uma fonte adicional de informação.

4. Se o alerta for acionável e de paginação, ele precisa ser tratado imediatamente?

Se o problema não precisar ser tratado imediatamente, não deve acordar ninguém no meio da noite. A equipe deve decidir sobre formas alternativas de exibir as informações no alerta nessas situações, por exemplo, uma notificação do Slack ou do painel ou uma tarefa aberta em um mecanismo de rastreamento de problemas.

5. Se for acionável, há um runbook ou link de solução de problemas? As etapas são claras o suficiente para serem seguidas por qualquer engenheiro da equipe?

Uma das piores experiências de ser um engenheiro de plantão – especialmente um novo – é a quantidade de conhecimento tribal que se acumula nas equipes de engenharia ao longo do tempo. É intimidante pular em um incidente de produção de alta gravidade apenas para perceber que você não está familiarizado com essa área do sistema e não está bem documentado.

“ Manter as informações de solução de problemas de alertas claras, simples e atualizadas ajuda bastante a reduzir o tempo médio de mitigação e recuperação de um incidente ”

Mesmo que você tenha a experiência, você pode ter escrito o código há tanto tempo que não se lembra claramente do que deveria estar fazendo. Manter as informações de solução de problemas de alerta claras, simples e atualizadas ajuda bastante a reduzir o tempo médio de mitigação e recuperação de um incidente (MTTM e MTTR).

6. Se for acionável, existe um link de painel e mostra todas as causas potenciais conhecidas?

Os painéis são uma ótima maneira de exibir grandes quantidades de informações do sistema de uma só vez, o que significa que os engenheiros não precisam pesquisar vários logs, métricas e rastreamentos para descobrir a causa de um problema. Agregar dados em um painel e fornecer o link como parte do alerta permite uma solução de problemas muito mais rápida.

7. O alerta é muito sensível ou não é específico o suficiente? Ela se beneficiaria com a dessensibilização ou mudança de escopo?

Muitos alertas são úteis, mas calibrados incorretamente. Eles podem ser muito amplos e não disparar sempre que deveriam, ou muito específicos e disparar várias vezes para o mesmo incidente, o que só aumenta o barulho.

8. Finalmente, um ser humano tem que fazer a remediação?

De certa forma, todo código de computador automatiza algo que um ser humano pode fazer. Então, por que não automatizar a correção dos problemas que acionam os alertas? Embora certos alertas mais complicados sejam difíceis de corrigir automaticamente, como um bug no código ou um problema de desempenho no sistema, ações automatizadas podem resolver muitos problemas comuns.

Isso é especialmente verdadeiro se você estiver executando em uma plataforma de nuvem como a AWS e puder provisionar infraestrutura sem precisar se preocupar em solicitar hardware adicional. Por exemplo, se um nó em seu cluster de pesquisa estiver mostrando discos com falha, por que não substituí-lo automaticamente? Se o serviço estiver com poucos recursos de computação devido ao aumento do tráfego, por que não aumentar a escala e adicionar VMs ou contêineres adicionais? Os detalhes da correção podem ser enviados à equipe por meio de canais sem alerta para que eles possam revisar quando quiserem.

Você respondeu “não” a alguma dessas perguntas?

Responder não a qualquer uma dessas perguntas gera uma tarefa de alta prioridade para a equipe fazer algum trabalho para melhorar o alerta – seja para interromper a paginação, melhorar as etapas de solução de problemas, automatizá-lo ou simplesmente corrigir o problema subjacente do sistema.

O cerne da abordagem é fazer isso de forma regular e planejada. Ele mantém os níveis de ruído baixos e seus operacionais e engenheiros de plantão felizes e produtivos. Eles podem se concentrar em melhorar a qualidade e gerar impacto em vez de combate a incêndios.

Está interessado na forma como trabalhamos na Intercom? Adoraríamos falar com você – confira nossas funções de engenharia abertas.