Como escolher uma estratégia para gerenciar webhooks

Ao longo desta série, enfatizamos que enfrentar problemas com webhooks em produção é inevitável. Também vimos que corrigir esses problemas exige um esforço considerável. Precisamos encontrar um equilíbrio para garantir que o esforço das pessoas do time se concentre nas questões mais críticas.

Este artigo mostra como identificar os problemas de webhooks que mais afetam o seu negócio e quanto esforço vale a pena investir de acordo com a natureza de cada problema.

Avaliando o risco de falha de webhooks

Antes de definir a sua estratégia para lidar com problemas de webhooks, você precisa primeiro definir o que considera um problema. Embora qualquer falha na sua infraestrutura de webhooks peça atenção e possa acabar prejudicando o negócio, nem todos os problemas têm o mesmo peso. Nesta seção, vamos discutir como determinar o quão crítica é cada falha em potencial.

SLIs e SLOs

Para determinar o quão críticos são os seus problemas de webhooks, você precisa conseguir avaliar o desempenho do seu sistema com base nos seus SLIs e SLOs.

Um SLI (service level indicator) é uma métrica que mede um aspecto do nível de serviço entregue por um serviço aos seus usuários. Em termos simples, um SLI mede uma característica de desempenho do seu serviço de processamento de webhooks.

Para um serviço de processamento de webhooks, algumas das principais características de desempenho são:

• Tempo de resposta
• Taxa de erros
• Throughput
• Disponibilidade

Um SLI é calculado como uma medida do ”bom” em relação ao total. Por exemplo, se queremos manter o tempo de resposta abaixo ou igual a 100 milissegundos para mil webhooks concorrentes, um SLI para o tempo de resposta é:

Número de webhooks com tempo de resposta ≤ 100ms / Número total de webhooks

Digamos que 990 webhooks tiveram resposta menor ou igual a 100ms, enquanto 10 webhooks tiveram tempos de resposta acima de 100ms; o SLI é: 990/1000 = 0,99, ou podemos dizer que 100ms está no percentil 99.

Já um SLO (service level objective) define a faixa de valores aceitáveis para um SLI dentro da qual o seu serviço de processamento de webhooks é considerado saudável.

Por exemplo, 100ms no percentil 99 é mais aceitável do que 100ms no percentil 45. Se o tempo de resposta de mais da metade dos nossos webhooks está acima do nosso limite de alerta, o sistema não está nada saudável.

Resumindo, um SLI nos dá uma medida das características de desempenho, enquanto um SLO ajuda a determinar se o sistema está ou não saudável.

Para mais detalhes sobre como definir limites de desempenho para a sua infraestrutura de webhooks, veja o nosso artigo “Monitoramento de desempenho, ajuste de escalabilidade e estimativa de recursos para infraestrutura de webhooks”.

Definindo o seu error budget

Ao definir SLIs e SLOs que refletem os níveis ideais de desempenho da sua infraestrutura de webhooks, você precisa considerar quanta degradação pode ser tolerada em um período sem gerar consequências graves para o negócio.

Por exemplo, um SLO pode definir que 97% dos webhooks devem ter tempo de resposta abaixo de 150ms, medido ao longo de 7 dias.

Essa definição de SLO significa que é aceitável que 3% dos webhooks tenham latência maior que 150ms nesse mesmo período.

Esses 3% são o error budget, que representa a quantidade de falhas que o sistema pode tolerar no período especificado.

Esses números ajudam os administradores a configurar alertas e a determinar quando e quanto esforço investir na correção de um problema específico de webhooks.

Como abordar a solução de problemas de webhooks

Não fazer nada

Se não está quebrado, não conserte.

Se você está dentro do seu error budget, pode deixar de lado ações mais sérias ou abordagens abrangentes para corrigir os webhooks que estão fora dos seus limites de desempenho. Além disso, o esforço para resolver o pequeno volume de problemas é gerenciável.

No entanto, essa situação pode mudar rapidamente diante de aumentos de volume de webhooks que os seus cálculos deveriam ter previsto. E o processo de remediação ainda vai envolver o ciclo frustrante de atividades rotineiras, como:

• Perder muito tempo investigando o problema;
• Lidar com problemas reportados por usuários finais;
• Vasculhar logs para diagnosticar problemas;
• Montar um ambiente de desenvolvimento manual para diagnóstico (ngrok, Postman, configuração de dev, etc.);

e muito mais.

Reinventar a roda

Se você notar desvios significativos dos seus SLIs e SLOs, deve considerar construir a infraestrutura de webhooks padrão discutida no artigo anterior.

O modelo de processamento assíncrono usado nesse design vai ajudar você a resolver a maior parte dos problemas que os webhooks enfrentam em produção, assumir o controle de vários aspectos do pipeline de dados dos webhooks e ter visibilidade completa.

Porém, não existe uma solução pronta para esse design, o que significa que você vai ter que reinventar a mesma roda que outras equipes de desenvolvimento já construíram para resolver problemas de webhooks. Seguir por esse caminho envolve o cenário de caixa de Pandora descrito no artigo anterior, resumido abaixo:

• 2 a 6 meses de implementação até acertar tudo;
• Monitoramento e manutenção de ferramentas e versões de software;
• Escrita de scripts para funcionalidades customizadas;
• Problemas recorrentes de escala; e
• Um sistema complicado que continua difícil de entender para uma pessoa desenvolvedora média.

Usar o Hookdeck para cuidar dos seus webhooks.

Como pessoa desenvolvedora solo/equipe de desenvolvimento/administrador/engenheiro de DevOps, etc., que quer processar webhooks de forma eficaz: você quer lidar com todo o peso das arquiteturas, das definições de SLI e SLO, do ferramental extenso e da curva de aprendizado das arquiteturas orientadas a eventos?

Meu palpite é NÃO.

Você prefere delegar toda essa responsabilidade a um serviço confiável que garanta a entrega dos seus webhooks. É aí que entra o Hookdeck.

O Hookdeck é uma infraestrutura de webhooks construída para resiliência, que ajuda você a receber webhooks de forma confiável mesmo depois de quedas de servidor.

Junto com isso vem um conjunto de recursos como respostas automáticas, rate limiting, pausa de webhooks e fan-out de webhooks, além de um dashboard intuitivo que dá a você e ao seu time controle e visibilidade totais sobre a atividade dos seus webhooks.

Com o Hookdeck, você pode parar de se preocupar com a confiabilidade dos seus webhooks e aproveitar a experiência de desenvolvimento no tratamento deles, focando mais em construir o seu produto.

Você pode começar com o Hookdeck hoje mesmo criando uma conta gratuita

Conclusão

Neste artigo, vimos como abordar os seus problemas de webhooks de forma científica e traçar uma estratégia para resolvê-los. Da medição de características de desempenho à definição de SLOs e de um error budget, você consegue determinar como os seus problemas de webhooks afetam o negócio e quanto esforço e atenção dedicar a eles.

Em seguida, apresentamos o Hookdeck, um serviço de tratamento de webhooks que tira de você o peso da confiabilidade e ao mesmo tempo entrega controle e visibilidade completos sobre os seus webhooks. No próximo artigo, aprofundo por que a abordagem do Hookdeck é a forma que recomendamos para lidar com os seus webhooks.