Instabilidade nos disparos de Webhook nas capacidades IDCloud e IDPay

Postmortem: Incidente de Disponibilidade no Serviço de Notificações (Webhook) - 14 de Abril de 2025

Sumário

No dia 14 de abril de 2025, entre 07:35 e 09:28 (horário local), nosso serviço responsável pelo envio de notificações via webhook esteve indisponível. O incidente ocorreu durante uma janela de manutenção programada para realizar alterações na infraestrutura de rede, especificamente para direcionar o tráfego de alguns serviços através de um novo gateway de API. Uma ferramenta interna de gerenciamento automático de DNS removeu inesperadamente o registro DNS necessário para o funcionamento do serviço de webhook, tornando-o inacessível externamente. A restauração do serviço envolveu a recriação do registro DNS afetado.

Impacto

Durante aproximadamente 1 hora e 53 minutos (das 07:35 às 09:28), os clientes que utilizam o serviço de webhook não receberam notificações sobre atualizações de status de seus processos. Isso resultou em um atraso na visibilidade do estado final de operações para alguns clientes e produtos dependentes desta funcionalidade. Houve um acúmulo de mensagens na fila de envio durante o período de indisponibilidade, que foram processadas após a restauração do serviço. A detecção do problema foi manual, reportada por clientes, pois os sistemas de monitoramento interno não identificaram a falha devido à ausência do registro DNS, que impedia a resolução do endereço do serviço.

Causa Raiz

A causa raiz do incidente foi uma falha durante um procedimento de mudança na infraestrutura. Durante a migração de tráfego para um novo gateway de API, tentou-se remover o gerenciamento automático de DNS para o serviço de webhook, desativando configurações específicas (anotações em recursos de orquestração de containers). A expectativa era que a ferramenta de automação de DNS parasse de gerenciar aquele registro específico, permitindo uma configuração manual. No entanto, a ferramenta interpretou a remoção das configurações como uma instrução para deletar os registros DNS (tipos A e TXT) associados ao serviço de webhook. Esse comportamento não foi observado em testes realizados em ambientes de pré-produção nem afetou outros serviços modificados na mesma janela. A razão exata para a discrepância de comportamento da ferramenta entre os ambientes e serviços não foi completamente esclarecida durante a resposta inicial ao incidente. A ausência de monitoramento externo específico para a disponibilidade do endpoint do webhook e para a fila de mensagens contribuiu para o atraso na detecção.

Resolução

O serviço foi restaurado às 09:28 (horário local), quando a equipe de engenharia reverteu a tentativa de remoção do gerenciamento automático, forçando a ferramenta de automação a recriar os registros DNS (A e TXT) para o serviço de webhook. Com a restauração do DNS, o serviço tornou-se acessível novamente e as notificações que estavam enfileiradas começaram a ser processadas.

Ações Corretivas

Para prevenir recorrências e melhorar a resposta a incidentes semelhantes, as seguintes ações foram identificadas:

• Revisar e aprimorar o processo de Gerenciamento de Mudanças (GMUD), incluindo testes mais detalhados e planos de rollback validados.
• Implementar monitoramento sintético para validar a acessibilidade e funcionalidade de endpoints externos críticos, como o de webhook.
• Investigar e documentar o comportamento da ferramenta de gerenciamento automático de DNS, buscando formas de controlar ou pausar seu gerenciamento de forma segura.
• Reforçar na documentação técnica e no processo de integração de novos clientes a importância da implementação de mecanismos de fallback (como polling periódico) ao utilizar webhooks.

Lições Aprendidas

• Melhoria no Monitoramento: Falhas que afetam a resolução de DNS ou a conectividade externa podem não ser detectadas por monitores de aplicação. Monitoramento sintético a partir de pontos externos é essencial para validar a disponibilidade real do serviço para os clientes.
• Visibilidade de Sistemas Auxiliares: Filas de mensagens e outros componentes auxiliares devem ter monitoramento adequado, pois podem indicar problemas mesmo quando o serviço principal aparenta estar funcional.
• Validação de Ferramentas de Automação: Ferramentas de automação podem apresentar comportamentos inesperados ou diferentes entre ambientes. Mudanças que dependem dessas ferramentas exigem testes rigorosos e validação em todos os ambientes, incluindo produção.
• Robustez de Processos de Mudança: Processos de mudança de infraestrutura devem incluir planos de validação pós-implementação abrangentes e planos de rollback testados e claros.
• Design Resiliente para Integrações: Ao oferecer mecanismos como webhooks, é crucial comunicar e incentivar os clientes a implementar estratégias de fallback (como polling) para garantir a resiliência contra falhas temporárias na entrega das notificações.

Recomendação de implementação mecanismo fallback para clientes

• A Unico recomenda o uso da implementação de webhook como funcionalidade primária para obtenção de atualizações sobre processamentos de requisições.
• No entanto, reforçamos que o cliente implemente um mecanismo de contingência (fallback) que consiste em, ao identificar falhas no método de webhook, se utilize o método GetProcess garantindo a continuidade do status das transações, sem afetar sua operação.

Para mais informações, verifique nossa documentação.

‌

Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.

Atenciosamente, Equipe Unico.