Unico incident

Instabilidade na Prova de Vida/Liveness

Resolved after 2 hours 34 minutes, affecting API, on March 12, 2026.

postmortem Mar 24, 2026, 08:49 PM UTC

# Postmortem: Incidente de Disponibilidade na Plataforma de Biometria e Liveness ## Resumo Em 12 de março de 2026, nossa plataforma de captura de dados e biometria enfrentou uma degradação significativa de serviço. O incidente foi desencadeado por um pico repentino de tráfego que sobrecarregou o servidor de modelos de _liveness_, levando a um aumento drástico na latência e a uma queda acentuada na disponibilidade para o processamento de inferências. ## Impacto Entre **09:10 e 09:22 \(BRT\)**, a disponibilidade para os fluxos de biometria e _liveness_ caiu para níveis próximos a **1%**, afetando todos os clientes que utilizavam esses serviços no período. O sistema apresentou lentidão extrema e erros de tempo de resposta \(_timeout_\), impactando a experiência do usuário final. A estabilidade total das métricas foi confirmada às 17:31, após a implementação de ajustes estruturais. ## Causa Raiz A investigação identificou uma falha de design na forma como o sistema lidava com saturação de carga. O incidente seguiu a seguinte progressão: 1. **Pico de Requisições:** Um aumento inesperado no volume de tráfego proveniente de setores específicos sobrecarregou o servidor de modelos. 2. **Degradação Silenciosa:** A aplicação de inferência aceitou mais conexões simultâneas do que sua capacidade de processamento permitia. Em vez de rejeitar o excesso de carga com erros rápidos, o sistema tentou processar todas as requisições, o que causou uma disputa de recursos de CPU. Isso elevou o tempo de resposta de 2 segundos para mais de 30 segundos. 3. **Invisibilidade do Circuit Breaker:** Os mecanismos de proteção da rede não detectaram a falha, pois as desconexões dos clientes por lentidão e as respostas de limite de taxa \(_Rate Limit_\) foram interpretadas como eventos normais de rede, impedindo o isolamento automático dos componentes degradados. 4. **Efeito Cascata:** O tempo de inicialização de novos recursos para escala automática foi insuficiente para absorver o impacto imediato, sobrecarregando ainda mais as instâncias ativas. ## Resolução Para mitigar o problema e restaurar o serviço, foram tomadas as seguintes medidas: * **Ajuste de Configurações:** Revertemos alterações recentes nos limites de detecção de anomalias que se mostraram contraproducentes sob estresse. * **Gestão de Tráfego:** Implementamos novos limites locais de taxa de transferência e consolidamos as janelas de escalonamento para garantir que o sistema estivesse melhor preparado para picos de demanda. * **Estabilização:** As alterações foram implantadas via ferramentas de entrega contínua, e a estabilidade da latência foi confirmada após o deploy final às 17:31. ## Lições Aprendidas * **Falha por Lentidão vs. Falha por Erro:** Aprendemos que o sistema deve ser configurado para "falhar rápido" \(_fail fast_\). Aceitar requisições além da capacidade nominal causa degradação silenciosa, que é mais difícil de detectar e corrigir do que erros explícitos. * **Visibilidade do Mesh:** Identificamos a necessidade de tornar erros de limite de taxa \(429\) e desconexões de clientes visíveis para os mecanismos de auto-recuperação da malha de serviços. * **Backpressure:** A ausência de limites estritos de fila de conexões impediu a geração de pressão reversa \(_backpressure_\) necessária para proteger a integridade do sistema. ‌ 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.

Started
Mar 12, 2026, 12:10 PM UTC
Resolved
Mar 12, 2026, 02:45 PM UTC
Duration
2h 34m
Detected by Pingoru
Mar 12, 2026, 12:10 PM UTC

Affected components

API

Update timeline

  1. identified Mar 12, 2026, 12:27 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 12, 2026, 12:53 PM UTC

    Prezado Cliente Nossa equipe de tecnologia segue atuando proativamente para identificar a causa raiz e restabelecer a normalidade do serviço de Prova de Vida. Manteremos todos informados com novas atualizações sobre o progresso e a resolução do incidente em breve. Agradecemos a sua compreensão e paciência.

  3. monitoring Mar 12, 2026, 01:28 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!

  4. resolved Mar 12, 2026, 02:45 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 09:07 e 09: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. 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 09: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.

  5. postmortem Mar 24, 2026, 08:49 PM UTC

    # Postmortem: Incidente de Disponibilidade na Plataforma de Biometria e Liveness ## Resumo Em 12 de março de 2026, nossa plataforma de captura de dados e biometria enfrentou uma degradação significativa de serviço. O incidente foi desencadeado por um pico repentino de tráfego que sobrecarregou o servidor de modelos de _liveness_, levando a um aumento drástico na latência e a uma queda acentuada na disponibilidade para o processamento de inferências. ## Impacto Entre **09:10 e 09:22 \(BRT\)**, a disponibilidade para os fluxos de biometria e _liveness_ caiu para níveis próximos a **1%**, afetando todos os clientes que utilizavam esses serviços no período. O sistema apresentou lentidão extrema e erros de tempo de resposta \(_timeout_\), impactando a experiência do usuário final. A estabilidade total das métricas foi confirmada às 17:31, após a implementação de ajustes estruturais. ## Causa Raiz A investigação identificou uma falha de design na forma como o sistema lidava com saturação de carga. O incidente seguiu a seguinte progressão: 1. **Pico de Requisições:** Um aumento inesperado no volume de tráfego proveniente de setores específicos sobrecarregou o servidor de modelos. 2. **Degradação Silenciosa:** A aplicação de inferência aceitou mais conexões simultâneas do que sua capacidade de processamento permitia. Em vez de rejeitar o excesso de carga com erros rápidos, o sistema tentou processar todas as requisições, o que causou uma disputa de recursos de CPU. Isso elevou o tempo de resposta de 2 segundos para mais de 30 segundos. 3. **Invisibilidade do Circuit Breaker:** Os mecanismos de proteção da rede não detectaram a falha, pois as desconexões dos clientes por lentidão e as respostas de limite de taxa \(_Rate Limit_\) foram interpretadas como eventos normais de rede, impedindo o isolamento automático dos componentes degradados. 4. **Efeito Cascata:** O tempo de inicialização de novos recursos para escala automática foi insuficiente para absorver o impacto imediato, sobrecarregando ainda mais as instâncias ativas. ## Resolução Para mitigar o problema e restaurar o serviço, foram tomadas as seguintes medidas: * **Ajuste de Configurações:** Revertemos alterações recentes nos limites de detecção de anomalias que se mostraram contraproducentes sob estresse. * **Gestão de Tráfego:** Implementamos novos limites locais de taxa de transferência e consolidamos as janelas de escalonamento para garantir que o sistema estivesse melhor preparado para picos de demanda. * **Estabilização:** As alterações foram implantadas via ferramentas de entrega contínua, e a estabilidade da latência foi confirmada após o deploy final às 17:31. ## Lições Aprendidas * **Falha por Lentidão vs. Falha por Erro:** Aprendemos que o sistema deve ser configurado para "falhar rápido" \(_fail fast_\). Aceitar requisições além da capacidade nominal causa degradação silenciosa, que é mais difícil de detectar e corrigir do que erros explícitos. * **Visibilidade do Mesh:** Identificamos a necessidade de tornar erros de limite de taxa \(429\) e desconexões de clientes visíveis para os mecanismos de auto-recuperação da malha de serviços. * **Backpressure:** A ausência de limites estritos de fila de conexões impediu a geração de pressão reversa \(_backpressure_\) necessária para proteger a integridade do sistema. ‌ 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.

Your product runs on more than Unico

Add the vendors you depend on and get one message when any of them reports trouble. Free for 3 vendors, no card.

Add your stack →