Unico incident
IDLive - Instabilidade na capacidade de Prova de Vida
Unico experienced a major incident on April 15, 2026 affecting Prova de Vida (API), lasting 4h 37m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- identified Apr 15, 2026, 01:19 PM UTC
Prezado Cliente, Nossa monitoração identificou um impacto no retorno das requisições da capacidade de Prova de Vida (IDLive). Afetando uma pequena porcentagem de requisições. Nossa equipe de engenharia já foi mobilizada e está atuando com prioridade máxima no diagnóstico da causa raiz para restabelecer a normalidade o quanto antes. Reforçamos nosso compromisso com a estabilidade de sua operação e enviaremos novas atualizações assim que tivermos mais detalhes sobre a evolução do caso. Atenciosamente, Equipe Unico.
- monitoring Apr 15, 2026, 01:24 PM UTC
Prezado Cliente, Informamos que as ações corretivas necessárias foram executadas com sucesso por nossa equipe técnica e o motor de liveness já apresenta estabilidade em sua operação. O ajuste foi implementado e o ambiente encontra-se normalizado. Iniciamos agora uma fase de monitoramento rigoroso e acompanhamento assistido para garantir a consistência da performance em todas as transações. O serviço já pode ser utilizado normalmente, e nossa equipe permanece em alerta para assegurar a continuidade da estabilidade. Manteremos a observação ativa para confirmar a total integridade do ecossistema. Atenciosamente, Equipe Unico.
- resolved Apr 15, 2026, 05:44 PM UTC
Prezado Cliente, Informamos o encerramento do incidente relacionado ao IDCloud (IDLive). Resumo Executivo e Impacto Entre 09:27 e 10:15, identificamos uma degradação na disponibilidade do motor de liveness. Durante este intervalo, uma pequena porcentagem das requisições recebeu respostas de erro (rate limiting), ocasionando falhas pontuais de processamento. O serviço foi totalmente restabelecido e opera dentro dos padrões de normalidade. Ressaltamos que não houve qualquer perda ou comprometimento de dados. Causa Raiz e Resolução A instabilidade foi causada por um comportamento atípico durante a fase de implantação (canary deploy) de uma nova versão, que gerou um desbalanceamento na distribuição de carga entre os servidores. A resolução foi alcançada através da promoção total da versão e do rebalanceamento das instâncias na camada de processamento, garantindo a equalização do tráfego. Compromisso e Próximos Passos Nossa equipe de engenharia já está trabalhando em melhorias estruturais no processo de deploy para mitigar este tipo de comportamento em atualizações futuras. Um Postmortem detalhado será compartilhado em breve com os detalhes técnicos e as ações preventivas adotadas. Pedimos desculpas pelos transtornos causados e reforçamos nosso compromisso com a transparência e a excelência de nossos serviços. Equipe Unico.
- postmortem May 21, 2026, 01:30 PM UTC
## Resumo No dia 15 de abril de 2026, enfrentamos um incidente que reduziu a disponibilidade de um de nossos serviços. Durante o evento, a taxa de disponibilidade caiu abaixo do nosso limite aceitável de 99,7%. O problema foi rapidamente identificado por nossos sistemas de monitoramento e a equipe técnica restabeleceu o serviço completamente em aproximadamente 15 minutos. Entendemos a importância da estabilidade para nossos clientes e estamos implementando melhorias estruturais para evitar que isso ocorra novamente. ## Impacto * O impacto ocorreu no dia 15 de abril de 2026, com início às 10:07 e mitigação total às 10:22 \(horário local\). * Durante esse período, uma parcela dos clientes enfrentou falhas ao realizar requisições, recebendo respostas de erro HTTP 5xx e 429 \(limitação de taxa\). * As falhas foram causadas pela sobrecarga momentânea em um subconjunto específico de instâncias de processamento, que não suportaram o volume de tráfego roteado para elas. ## Causa Raiz * O incidente foi desencadeado durante o processo de implantação gradual de uma nova atualização do serviço. * Durante a fase de aumento de tráfego redirecionado para a nova versão \(de 30% para 70%\), as requisições foram distribuídas de forma irregular entre as instâncias disponíveis. * A investigação detalhada demonstrou que 93,3% dos recursos de processamento estavam concentrados em uma única zona de disponibilidade física. * Esse desequilíbrio geográfico na infraestrutura, interagindo com a mudança de roteamento de tráfego, fez com que cargas desproporcionais fossem enviadas a instâncias específicas, superando suas capacidades individuais. ## Resolução * Nossos sistemas automatizados de alerta dispararam instantaneamente, permitindo que a equipe de engenharia iniciasse a resposta em cerca de um minuto. * A equipe rapidamente identificou o padrão de desequilíbrio no tráfego e optou por acelerar a implantação, realizando a promoção completa da nova versão. * Essa ação corretiva forçou imediatamente o rebalanceamento da distribuição de requisições por toda a infraestrutura, mitigando a sobrecarga e restaurando a disponibilidade normal para os clientes. ## Ações Futuras \(Action Items\) * Implementar mecanismos de gerenciamento de tráfego sensíveis à topologia, garantindo que implantações distribuam cargas de maneira uniforme entre as zonas de disponibilidade. * Aplicar regras e restrições rigorosas na orquestração da infraestrutura para impedir a concentração excessiva de instâncias em uma única zona. * Automatizar a elevação de privilégios de acesso emergencial para líderes de resposta a incidentes, eliminando gargalos de permissão e permitindo ações corretivas mais rápidas. ## Lições Aprendidas * **Gerenciamento Estrutural de Tráfego:** Implantações graduais interagem de forma ineficiente com topologias de infraestrutura desiguais. É imperativo adaptar as configurações de balanceamento de carga para considerar a distribuição zonal durante essas transições. * **Resiliência e Espalhamento de Carga:** A concentração de grande parte da infraestrutura em uma única zona representa um risco significativo de disponibilidade. Configurações que forçam a distribuição equilibrada de recursos são cruciais para a tolerância a falhas. * **Agilidade na Mitigação:** Atrasos técnicos na obtenção de permissões de sistema limitam a capacidade da equipe de isolar componentes defeituosos de forma imediata, prolongando o tempo de impacto para o cliente. Otimizar as ferramentas de resposta é vital para reduzir a duração dos incidentes.