Instabilidade nos fluxos de Prova de Vida (Liveness)

Update timeline

1. identified Feb 10, 2026, 06:29 PM UTC

   Instabilidade nos serviços de Prova de Vida (Liveness) Resumo do Incidente: Detectamos uma oscilação na disponibilidade dos serviços de liveness, impactando as taxas de sucesso das requisições de liveness da Unico. Impacto ao Cliente: Clientes que utilizam essas funcionalidades via SDK podem encontrar dificuldades ou falhas intermitentes ao realizar processos de captura e validação biométrica. Ações em Andamento: Nossa equipe de engenharia já identificou a origem da instabilidade e está trabalhando na mitigação. Como primeira medida corretiva, estamos realizando o escalonamento de serviços para normalizar o processamento das requisições. Próximos Passos: Seguimos com a investigação técnica para determinar a causa raiz e garantir a estabilidade total do ambiente. Traremos novas atualizações assim que houver mudança no status ou a normalização do serviço.

2. identified Feb 10, 2026, 06:49 PM UTC

   We are continuing to work on a fix for this issue.

3. identified Feb 10, 2026, 07:08 PM UTC

   Atualização: Instabilidade nos serviços de Liveness Status: Em investigação Componentes Afetados: Liveness Informações Atualizadas: Seguimos trabalhando na resolução da instabilidade que afeta os serviços de Liveness. O cenário reportado anteriormente permanece, com a disponibilidade operando abaixo dos níveis normais devido a falhas na captura e validação de biometria. Ações em curso: Nossa equipe de engenharia continua atuando diretamente na infraestrutura para estabilizar o serviço. O processo de escalonamento dos recursos críticos segue sendo monitorado para mitigar o impacto nas requisições via SDK. Permanecemos em análise intensiva para garantir o reestabelecimento da taxa de sucesso. Novas atualizações serão fornecidas assim que houver evolução na recuperação do serviço.

4. identified Feb 10, 2026, 07:33 PM UTC

   Informações Atualizadas: Seguimos com o monitoramento e a análise técnica da instabilidade que afeta os serviços de captura de dados e biometria (Liveness). O cenário de oscilação reportado anteriormente persiste, e nossa equipe permanece dedicada à solução. Ações em curso: - Nossos times de engenharia continuam mobilizados com prioridade máxima na correção do problema. - Estamos aplicando medidas de reforço em nossa infraestrutura para normalizar a taxa de sucesso das validações. - O serviço permanece sob observação constante até que a estabilidade total seja confirmada. Lamentamos o impacto causado e reforçamos que todos os esforços estão sendo empenhados para o restabelecimento completo da operação. Traremos novas informações assim que houver evolução no cenário.

5. monitoring Feb 10, 2026, 07:52 PM UTC

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado, o ambiente retornou a sua normalidade a partir das 16:25. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

6. resolved Feb 10, 2026, 07:59 PM UTC

   Resumo Executivo Impacto: Informamos que, no dia 10 de fevereiro, identificamos uma instabilidade nos serviços de Prova de Vida (Liveness) iniciada às 15h06. O incidente resultou em falhas intermitentes e aumento de latência para uma parcela das validações biométricas. Após a atuação prioritária do nosso time de engenharia, a disponibilidade foi totalmente restabelecida às 16h25, momento em que os indicadores de sucesso retornaram aos níveis operacionais normais. Resolução e Investigação: A mitigação do impacto foi alcançada através da identificação e reinicialização de componentes da nossa infraestrutura de processamento que apresentavam comportamento degradado. No momento, os serviços operam com estabilidade e seguem sob monitoramento rigoroso. Próximos Passos: Nossa equipe técnica permanece dedicada à investigação profunda para determinar a causa raiz desta oscilação, incluindo a análise conjunta com nossos provedores de infraestrutura. Em breve, disponibilizaremos um relatório pós-incidente (post-mortem) detalhando os achados técnicos e as ações preventivas adotadas. Reiteramos nosso compromisso com a transparência e com a melhoria contínua de nossa plataforma para garantir a melhor experiência e confiabilidade aos nossos clientes. Equipe Unico.

7. postmortem Mar 16, 2026, 01:18 PM UTC

   # Postmortem: Instabilidade nos fluxos de Prova de Vida \(Liveness\) ### Resumo No dia 10 de fevereiro de 2026, identificamos uma instabilidade em nossa camada de orquestração de liveness \(biometria facial\), que resultou em erros intermitentes \(HTTP 500\) para diversas funcionalidades. O incidente foi provocado por falhas de comunicação interna entre microsserviços após um evento de rebalanceamento de infraestrutura. A situação foi normalizada após a reinicialização estratégica de instâncias do serviço afetado. ‌ ### Impacto O incidente teve início às **12:07 BRT** e foi totalmente mitigado às **16:37 BRT**. Durante esse período, usuários podem ter enfrentado lentidão ou falhas ao tentar realizar fluxos de captura de dados e validação biométrica. O erro manifestava-se como um _timeout_ de 10 segundos quando o sistema tentava se comunicar com capacidades internas específicas. ‌ ### Causa Raiz A investigação técnica revelou uma falha na propagação de atualizações de rede dentro do nosso cluster de serviços \(Istio/ASM\). ‌ 1. **Evento de Infraestrutura:** Cerca de 15 nós de processamento foram removidos simultaneamente durante um processo de redimensionamento automático \(_scale-down_\) na nuvem. 2. **Sobrecarga do Plano de Controle:** A remoção abrupta de mais de 46 pods gerou uma carga de eventos de rede três vezes maior que o normal, sobrecarregando o sistema de controle de tráfego. 3. **Endpoints Obsoletos:** Devido a essa sobrecarga, alguns serviços tentaram enviar tráfego para endereços de IP de instâncias que já haviam sido encerradas, resultando em falhas de conexão e _timeouts_. 4. **Ausência de Limites de Evicção:** A inexistência de configurações de orçamento de interrupção \(_PodDisruption Budget_\) permitiu que muitos componentes críticos fossem removidos ao mesmo tempo, impedindo uma transição gradual da rede. ### Resolução A equipe de engenharia identificou três instâncias do orquestrador que mantinham registros de rede inconsistentes. Às **16:00 BRT**, foi realizado o _restart_ dessas instâncias, o que forçou a atualização das tabelas de roteamento e cessou imediatamente os erros 5xx. O sistema retornou à estabilidade total logo em seguida. ‌ ### Lições Aprendidas * **Gerenciamento de Escala:** Identificamos a necessidade de implementar mecanismos de remoção gradual de instâncias para evitar picos de carga no plano de controle de rede. * **Resiliência de Configuração:** A importância de utilizar políticas de interrupção de pods para garantir que serviços críticos nunca fiquem abaixo de um limiar mínimo de disponibilidade durante manutenções automáticas. * **Observabilidade:** Reforçamos a necessidade de alertas específicos sobre a taxa de eventos de processamento interno para detectar sobrecargas antes que elas impactem o usuário final. Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.