Instabilidade na Prova de Vida/Liveness

Update timeline

1. identified Mar 11, 2026, 06:16 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. monitoring Mar 11, 2026, 06:24 PM UTC

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. 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!

3. resolved Mar 11, 2026, 06:43 PM UTC

   Prezado Cliente, Informamos que a instabilidade que afetou a disponibilidade da capacidade de Prova de Vida (Liveness) foi totalmente resolvida. Resumo Executivo e Impacto No dia de hoje, identificamos uma instabilidade temporária em nosso serviço de captura de dados biométricos entre 14:57 e 15:20. Durante este intervalo, uma parcela dos usuários enfrentou dificuldades ao tentar realizar autenticações e capturas, resultando em uma queda na taxa de disponibilidade para aproximadamente 70%. Lamentamos o ocorrido e ressaltamos que o restabelecimento da normalidade foi priorizado para minimizar o impacto na experiência dos usuários finais e na operação de nossos clientes parceiros. Causa Raiz e Resolução A instabilidade foi originada por uma falha ainda sob investigação que afetou a infraestrutura de nuvem. O comportamento observado é consistente com um incidente anterior registrado junto ao provedor. A equipe de engenharia interveio e o serviço foi totalmente restabelecido às 15:20, operando com estabilidade desde então. A investigação junto ao fornecedor segue em andamento. Um Postmortem detalhado será elaborado e compartilhado em breve, detalhando as melhorias estruturais de longo prazo. Lamentamos o impacto causado em sua operação e permanecemos à disposição. Atenciosamente, Equipe Unico.

4. postmortem Mar 24, 2026, 08:59 PM UTC

   # Postmortem: Instabilidade na Prova de Vida/Liveness ## Sumário Em 11 de março de 2026, entre 14:57 e 15:20 \(BRT\), nossos serviços de biometria experimentaram uma degradação significativa na disponibilidade. O incidente foi desencadeado por uma manutenção de infraestrutura no provedor de nuvem \(Google Cloud\) que causou a remoção abrupta de nós do cluster, resultando em erros de roteamento e falhas em cascata no service mesh. ‌ ## Impacto * **Disponibilidade:** O componente de captura de dados e biometria operou abaixo de 95% por um período crítico de 2 minutos. * **Experiência do Usuário:** Clientes enfrentaram erros 503 \(Serviço Indisponível\) e 429 \(Limite de Requisições Excedido\) ao tentar realizar verificações biométricas. * **Escopo:** O erro foi isolado aos serviços de motor de processamento e não afetou a plataforma como um todo. ## Causa Raiz O incidente foi resultado da combinação de três fatores principais: 1. **Migração Ativa de Infraestrutura:** Uma migração de máquinas virtuais no Google Kubernetes Engine evitou nós de produção de forma abrupta, terminando uma quantidade substancial de instâncias \(pods\) do serviço. 2. **Atraso na Propagação do Service Mesh:** O plano de controle gerenciado \(Anthos Service Mesh\) apresentou atrasos na propagação das listas de endpoints atualizadas para os sidecars. Isso fez com que o tráfego continuasse sendo enviado para IPs de pods que já não existiam mais. 3. **Configuração de Resiliência:** A ausência de configurações de _connection pool_ e _circuit breaker_ impediu que o sistema falhasse rapidamente. Em vez disso, o sistema gerou retentativas em cascata e atingiu limites de taxa locais, sobrecarregando ainda mais o plano de controle. ## Resolução O sistema se estabilizou de forma autônoma. O mecanismo de auto-escalonamento \(_autoscaler_\) detectou a pressão e expandiu a capacidade de aproximadamente 130 para 800 instâncias, garantindo que houvesse pods saudáveis suficientes para processar a carga assim que o plano de controle convergiu com as rotas corretas. ‌ ## Lições Aprendidas * **Resiliência à Churn de Nós:** Eventos moderados de migração de nós podem causar impactos desproporcionais se o service mesh estiver configurado para propagar todos os endpoints globalmente. * **Observabilidade de Planos Gerenciados:** A dependência de serviços gerenciados sem visibilidade direta de logs \(como o plano de controle do mesh\) exige uma estratégia de diagnóstico baseada em eliminação e suporte proativo do fornecedor. * **Comunicação Inicial:** É fundamental evitar atribuições definitivas de causa raiz no início do incidente para não criar narrativas incorretas antes da análise técnica profunda. ‌ 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.‌ Atenciosamente, Equipe Unico.