Instabilidade na Prova de Vida/Liveness

Update timeline

1. investigating Mar 06, 2026, 10:21 PM UTC

   Prezado Cliente, Identificamos uma instabilidade que afeta a capacidade de Prova de Vida (Liveness) em nossos serviços. Nossa equipe de engenharia já está mobilizada e trabalhando intensamente no diagnóstico para restabelecer a normalidade o mais breve possível. Entendemos a importância dessa funcionalidade para sua operação e priorizamos a resolução deste cenário. Reforçamos nosso compromisso com a transparência e enviaremos novas atualizações assim que tivermos mais informações sobre a evolução do reparo. Atenciosamente, Equipe Unico.

2. identified Mar 06, 2026, 10:29 PM UTC

   Atualização de Status: Incidente Identificado Prezado Cliente, Informamos que a origem da instabilidade na capacidade de Prova de Vida (Liveness) foi mapeada por nossa equipe de especialistas. Status: Em correção Identificamos um cenário de saturação em nossa infraestrutura que está gerando erros de limite de requisições (429). Nossa engenharia já iniciou o escalonamento de recursos e a implementação de medidas corretivas para aliviar a carga do sistema e normalizar o processamento das validações com prioridade máxima. Estamos acompanhando a propagação dessas melhorias em tempo real e manteremos você atualizado sobre a recuperação do serviço. Atenciosamente, Equipe Unico.

3. monitoring Mar 06, 2026, 10:42 PM UTC

   Status: Em Monitoramento (Estabilidade Reestabelecida) Prezado Cliente, Informamos que as ações corretivas para normalizar o serviço de Prova de Vida/Liveness foram finalizadas e o ambiente já apresenta estabilidade. Ações Tomadas e Diagnóstico: Nossa equipe de engenharia identificou que a instabilidade foi causada por uma saturação nas instâncias do motor de liveness. Um volume atípico de requisições por minuto (RPM) proveniente de fluxos de alta escala disparou o rate limit do microsserviço, gerando um efeito cascata de erros 429 e 5xx que impactou a disponibilidade aos clientes. Para resolver o cenário, realizamos o escalonamento emergencial das instâncias, aumentando a capacidade de processamento e aliviando a carga sobre o sistema. Com essa medida, os tempos de resposta (latência) e a taxa de sucesso voltaram aos patamares normais. Próximos Passos: Entramos agora em fase de acompanhamento assistido. Nossa equipe permanece em monitoramento rigoroso da infraestrutura para garantir que o sistema suporte as novas faixas de tráfego sem oscilações. O serviço já pode ser utilizado integralmente. Lamentamos o transtorno e seguimos à disposição. Equipe Unico

4. resolved Mar 06, 2026, 10:50 PM UTC

   Atualização de Status: Incidente Resolvido Prezado Cliente, Informamos que a instabilidade que afetou a disponibilidade da capacidade de Prova de Vida (Liveness) foi totalmente resolvida. O serviço opera em normalidade desde as 19:09 (Horário de Brasília). Abaixo, apresentamos o resumo executivo dos eventos: 1. Resumo Executivo e Impacto O incidente ocorreu entre 18:56 e 19:09, totalizando 13 minutos de instabilidade. Durante este período, uma parcela das requisições de biometria enfrentou erros de limite de processamento (429) e falhas intermitentes de conexão (5xx). 2. Causa Raiz e Resolução A instabilidade foi desencadeada por um aumento súbito e atípico no volume de requisições simultâneas em nossa plataforma, superando a capacidade de resposta imediata da infraestrutura compartilhada. Causa Raiz: O volume abrupto de tráfego saturou as instâncias do nosso motor de processamento biométrico. Embora o sistema possua mecanismos de escalonamento automático, a velocidade da demanda causou uma exaustão temporária de recursos de rede (endereçamentos de IP), o que impediu a subida imediata de novas réplicas para absorver a carga excedente. Resolução: Nossa equipe de engenharia realizou uma intervenção emergencial para expandir a infraestrutura e otimizar a distribuição de recursos de rede. Com a ativação de novas instâncias de processamento, o serviço foi estabilizado e os erros cessaram às 19:09. 3. Compromisso e Próximos Passos A Unico reafirma seu compromisso com a resiliência e a alta disponibilidade de suas operações. Como medidas preventivas, já iniciamos: Um Postmortem detalhado será elaborado e compartilhado em breve, detalhando as melhorias estruturais de longo prazo. Lamentamos sinceramente o impacto causado em sua operação e permanecemos à disposição. Atenciosamente, Equipe Unico.

5. postmortem Mar 10, 2026, 08:09 PM UTC

   **Data do Incidente:** 10 de fevereiro de 2026 **Duração do Impacto:** 12:07 às 16:37 \(Horário de Brasília\) **Status:** Resolvido ### Resumo Executivo Em 10 de fevereiro de 2026, nossa infraestrutura de orquestração de biometria experimentou instabilidade parcial, resultando em retornos de erro \(HTTP 500\) para alguns serviços internos de captura de dados. O incidente foi desencadeado por uma sobrecarga no sistema de controle de tráfego de rede \(Service Mesh\) durante um evento de redimensionamento automático de capacidade \(scale-down\) na nuvem. A falha gerou problemas de comunicação entre micros-serviços por meio de conexões interrompidas \(timeouts\). A normalidade do serviço foi restaurada com a reinicialização das instâncias de aplicação afetadas. ### Impacto Durante a janela de degradação, certas requisições de clientes falharam intermitentemente devido ao esgotamento do tempo limite de conexão \(10 segundos\) no sistema de orquestração biométrica. Os usuários finais dessas conexões específicas experimentaram falhas ou instabilidade ao acessar nossos serviços de biometria. ### Causa Raiz A investigação concluiu que a instabilidade foi causada por uma dependência externa aliada a uma falha na atualização ágil da tabela de rotas internas. 1. **Redimensionamento Abrupto:** Ocorreu um evento automático de _scale-down_ na infraestrutura de nuvem, onde múltiplos nós de processamento temporários \(_spot nodes_\) foram removidos simultaneamente. Isso causou a deleção massiva de instâncias \(pods\) de uma só vez, sem remoção gradual. 2. **Sobrecarga no Plano de Controle:** Essa remoção abrupta gerou uma carga excessiva de eventos no plano de controle de tráfego da rede, excedendo sua capacidade de processar e distribuir as novas configurações para os agentes de rede. 3. **Rotas Desatualizadas:** Devido à sobrecarga, as instâncias de orquestração mantiveram rotas desatualizadas \(_stale endpoints_\), tentando rotear o tráfego para instâncias que já haviam sido removidas. 4. **Falha de Comunicação:** Como as instâncias de destino não existiam mais, as requisições aguardavam até o limite máximo de tempo \(10 segundos\) antes de falharem com erro de conexão. ### Resolução e Mitigação Assim que a anomalia de rede foi identificada, nossa equipe de resposta a incidentes localizou instâncias específicas do orquestrador de biometria que estavam retendo as rotas de tráfego antigas. * **Ação Imediata:** A equipe forçou a reinicialização \(restart\) dessas instâncias afetadas. Essa ação exigiu que as instâncias adquirissem as tabelas de roteamento mais recentes e estabilizadas diretamente da infraestrutura da nuvem. * **Resultado:** Com as novas tabelas de rotas restabelecidas, os erros cessaram imediatamente, restaurando a comunicação estável na plataforma de biometria. * **Acompanhamento:** Adicionalmente, foi acionado o suporte do provedor de nuvem para auxiliar na investigação detalhada sobre o comportamento atípico do controle de tráfego de rede durante o evento de escalonamento. ### Lições Aprendidas Para evitar a recorrência deste problema e fortalecer nossa operação, destacamos os seguintes aprendizados: * **Gestão de Desligamento Gradual:** A ausência de configurações apropriadas para limitar a terminação simultânea de recursos em nuvem \(_PodDisruption Budget_\) expõe o sistema a perturbações massivas de roteamento. Devemos garantir limites seguros em nossas configurações de escala. * **Tempo de Propagação \(Grace Period\):** A falta de tempos de espera adequados \(_preStop hooks_\) antes da destruição total de uma instância impediu que as ferramentas de malha de serviço atualizassem as regras de acesso em tempo hábil. A infraestrutura precisa acomodar latências operacionais comuns de ferramentas nativas de rede. * **Visibilidade de Sobrecarga Interna:** Detectar falhas orientadas a eventos e processamento interno de rede exige monitoramento especializado focado no tempo de sincronização e na taxa de transferência de infraestruturas do tipo Service Mesh.