Postmortem: Indisponibilidade do Serviço de Biometria Facial 1:N
Resumo
Em 4 de julho de 2025, entre 13:28 BRT e 14:31 BRT, nosso serviço de reconhecimento facial 1:N experimentou uma indisponibilidade total para todos os nossos clientes. A causa principal foi a saturação do nosso banco de dados de busca vetorial, desencadeada por um volume de tráfego inesperadamente alto de um cliente e por um comportamento de novas tentativas (retries) agressivas de sistemas internos. A situação foi exacerbada por um pico de latência no banco de dados durante um processo de redução automática de nós.
Impacto
Durante o período do incidente, todas as chamadas para as capacidades de validação facial 1:N, que incluem serviços de confiança de identidade, pontuação de identidade e token biométrico, resultaram em erros ou timeouts para os clientes. Isso significa que as operações que dependiam dessas funcionalidades ficaram completamente indisponíveis.
- Início da Degradação: 04/07/2025, 13:28 BRT
- Fim/Estabilização: 04/07/2025, 14:31 BRT
- Duração Total: 1 hora e 4 minutos
- Detecção: 04/07/2025, 13:28 BRT (via alertas de alta taxa de erros)
Causa Raiz
A indisponibilidade foi resultado de uma combinação de fatores:
- Tráfego Inesperado e Falha no Controle de Fluxo: Um cliente gerou um volume de requisições significativamente acima do esperado. Nossas regras de controle de tráfego, que deveriam limitar esse volume, não foram aplicadas corretamente devido a uma configuração específica em um cabeçalho de autorização, permitindo que o tráfego excessivo bypassasse os controles.
- Pico de Latência no Banco de Dados: Um processo de redução automática de nós no nosso banco de dados de busca vetorial (Spanner) gerou um pico de latência. Esse comportamento, embora conhecido em certas condições de redução de nós, foi o gatilho inicial para uma cascata de problemas.
- Retries Agressivos de Sistemas Internos: Em resposta aos erros de timeout gerados pelo pico de latência no banco de dados, nossos sistemas internos iniciaram um volume agressivo de novas tentativas de requisição. A lógica de tratamento de erros em um de nossos componentes não estava configurada para ativar um mecanismo de proteção (circuit breaker), o que impediu que essas novas tentativas fossem contidas, sobrecarregando ainda mais o banco de dados.
Resolução
Para restabelecer o serviço, as seguintes ações imediatas foram tomadas:
- Desativação temporária de serviços internos que estavam contribuindo para a sobrecarga.
- Ajuste manual da configuração do banco de dados para evitar novas reduções automáticas de nós e garantir capacidade máxima.
- Restabelecimento gradual do ambiente para evitar saturação adicional da infraestrutura.
Com essas ações, o ambiente se estabilizou e os serviços foram restabelecidos por volta das 14:31 BRT.
Lições Aprendidas
Este incidente nos proporcionou valiosos aprendizados, que serão utilizados para fortalecer a resiliência de nossos sistemas:
- Prevenção: A necessidade de implementar controles de tráfego mais robustos e granulares por endpoint, além de revisar as exceções existentes para garantir que não haja brechas.
- Detecção: A importância de instrumentar todas as aplicações que interagem com nossos serviços críticos para ter visibilidade completa do fluxo de requisições, especialmente em cenários de alto volume.
- Mitigação: Aprimorar o tratamento de erros em nossos componentes para garantir que os mecanismos de proteção, como os circuit breakers, sejam ativados corretamente em caso de degradação do serviço. Além disso, buscaremos melhorias junto aos nossos provedores de infraestrutura para mitigar picos de latência durante operações de escalonamento de banco de dados.
Estamos empenhados em garantir estabilidade de nossa plataforma com ações de melhoria contínua.
Agradecemos a compreensão, Equipe Unico!