Relatório de Incidente: Instabilidade nos Serviços de Autenticação em 21 de Maio de 2025
No dia 21 de maio de 2025, enfrentamos uma instabilidade em nossos sistemas que afetou os serviços de autenticação. Este relatório detalha o ocorrido, seu impacto, a causa raiz, as ações de resolução e os principais aprendizados.
Resumo
No dia 21 de maio de 2025, entre 15:51 e 16:19 (horário local), ocorreu uma instabilidade em nossos serviços de autenticação. Este incidente afetou a capacidade de autenticação de contas de usuário e de serviço, resultando em latência na emissão de tokens e, por um período, indisponibilidade de funcionalidades de autenticação. Nossas equipes de engenharia agiram prontamente para identificar e mitigar o problema, restaurando a normalidade dos serviços.
Impacto
O incidente teve início às 15:51 do dia 21 de maio de 2025, manifestando-se inicialmente como latência na autenticação e na geração de tokens para contas de serviço. A partir das 15:55, o sistema de autenticação de contas de usuário e de serviços evoluiu para um quadro de indisponibilidade. Consequentemente, alguns serviços dependentes que utilizam este sistema de autenticação, como o ID DOCs, também foram impactados. O serviço foi completamente restabelecido e normalizado às 16:19 do mesmo dia. A interrupção total dos serviços de autenticação durou 28 minutos.
Causa Raiz
A análise do incidente identificou que a causa raiz foi uma combinação de fatores durante a implantação de uma nova versão do componente de gerenciamento de autenticação, que é parte de nossos serviços de Identidade.
Os principais fatores contribuintes foram:
- Configuração da Estratégia de Implantação (Rollout): A estratégia de implantação configurada para o serviço de gerenciamento de autenticação permitia que as novas instâncias da aplicação fossem consideradas prontas (saudáveis) de forma muito rápida, em aproximadamente 20 segundos. No entanto, esse tempo não era suficiente para que estivessem totalmente preparadas para processar o volume de requisições existentes. Isso resultou em um ciclo em que as novas instâncias, ao receberem carga, falhavam e reiniciavam constantemente (crashloopback).
- Verificação de Saúde (Health Check) Incompleta: O mecanismo de verificação de saúde do serviço retornava um status positivo sem validar adequadamente se todas as suas dependências internas críticas estavam carregadas e operacionais. Não havia também um atraso configurado para o início da verificação de saúde, o que permitiria a completa inicialização do serviço.
- Redução de Réplicas Mínimas: Previamente ao incidente, houve uma otimização de recursos que incluiu a redução do número mínimo de instâncias (réplicas) do serviço. Embora essa alteração tenha sido gradual, a capacidade reduzida tornou o sistema mais sensível aos problemas desencadeados pela estratégia de implantação e pela verificação de saúde inadequada durante o deploy da nova versão.
Esses elementos combinados levaram à sobrecarga do componente Authentication-Manager, reduzindo sua capacidade de processamento e causando a indisponibilidade observada.
Resolução
Ao detectar a instabilidade, nossa equipe de engenharia iniciou imediatamente as ações de mitigação. A primeira medida foi tentar reverter a implantação para a versão anterior estável do componente (rollback). Em paralelo, e como ação efetiva para a normalização, foi realizado o escalonamento horizontal manual das instâncias do serviço Authentication-Manager. Este aumento na capacidade de processamento permitiu que o serviço se estabilizasse e fosse completamente restabelecido às 16:19, com os pods respondendo com sucesso.
Lições Aprendidas
Este incidente reforçou a importância de melhorias contínuas em nossos processos e configurações de sistema. As principais lições aprendidas são:
- Robustez das Verificações de Saúde (Health Checks): É crucial que as verificações de saúde dos serviços sejam abrangentes, validando não apenas o estado da aplicação em si, mas também a conectividade e a prontidão operacional de todas as suas dependências críticas antes que o serviço seja considerado apto a receber tráfego.
- Estratégias de Carregamento de Dependências: Revisar e ajustar as estratégias de carregamento de configurações e dependências. Para componentes críticos, considerar o carregamento de todos os recursos essenciais durante a inicialização da aplicação (conhecido como "eager loading"), em vez de aguardar a primeira requisição ("lazy loading"). Isso pode garantir que um serviço esteja verdadeiramente pronto quando seu health check o indicar como saudável.
- Segurança nas Estratégias de Implantação (Rollout): As estratégias de implantação de novas versões devem ser configuradas para garantir uma transição gradual e segura. É fundamental alocar tempo suficiente para que as novas instâncias se tornem totalmente operacionais e sejam validadas sob condições de carga real antes que as instâncias da versão anterior sejam desativadas, minimizando o risco de degradação ou indisponibilidade, especialmente em serviços de alta criticidade.
Estamos comprometidos em aplicar esses aprendizados para fortalecer ainda mais a resiliência e a confiabilidade de nossos serviços.
Atenciosamente, Equipe Unico!