Instabilidade Parcial na Prova de Vida/Liveness

Update timeline

1. monitoring Mar 13, 2026, 10:32 PM UTC

   Prezado Cliente, Informamos que a instabilidade que afetava o serviço de Prova de Vida (Liveness) foi identificada e corrigida. No momento, o cenário encontra-se totalmente estabilizado, com o impacto limitado a um período parcial com início às 18:55 e fim às 19:10. Nossa equipe de engenharia já implementou as ações corretivas e seguimos em fase de monitoramento para garantir a plena performance da funcionalidade.

2. monitoring Mar 13, 2026, 10:41 PM UTC

   Prezado Cliente, Informamos que a instabilidade que afetava o serviço de Prova de Vida (Liveness) foi identificada e corrigida. No momento, o cenário encontra-se totalmente estabilizado, com o impacto limitado a um período parcial com início às 18:55 e fim às 19:10. Nossa equipe de engenharia já implementou as ações corretivas e seguimos em fase de monitoramento para garantir a plena performance da funcionalidade. Atenciosamente, Equipe Unico!

3. resolved Mar 13, 2026, 11:45 PM UTC

   Atualização de Incidente: Resolvido Resumo Executivo e Impacto Informamos que a instabilidade parcial identificada em nosso motor de liveness foi totalmente resolvida. O incidente ocorreu entre 18:55 e 19:10, totalizando aproximadamente 15 minutos de impacto direto. Durante este intervalo, registramos um volume de aproximadamente 15% de erros. Ressaltamos que não houve qualquer perda ou comprometimento de integridade de dados durante o período. Compromisso e Próximos Passos A estabilidade do ecossistema já foi validada e o serviço segue operando dentro dos parâmetros de normalidade. Nossa prioridade agora volta-se para a análise de resiliência a longo prazo: Postmortem: Um relatório detalhado (Postmortem) será elaborado e compartilhado em breve, aprofundando os gatilhos do evento e as melhorias estruturais. Refinamento de Auto-scaling: Revisaremos as políticas de escalonamento automático para garantir respostas ainda mais ágeis a variações bruscas de tráfego. Lamentamos sinceramente pelo impacto causado em sua operação e reafirmamos nosso compromisso com a excelência técnica e a disponibilidade de nossos serviços. Equipe Unico.

4. postmortem Mar 24, 2026, 01:18 PM UTC

   # Postmortem: Instabilidade Parcial na Prova de Vida/Liveness ## **Sumário** No dia 13 de março de 2026, entre 19:00 e 19:15 \(BRT\), o serviço **Liveness Platform Predict** apresentou uma degradação significativa, com a disponibilidade caindo para aproximadamente **85%**. O incidente foi desencadeado por um pico atípico e repentino de tráfego que excedeu a capacidade de processamento imediata da infraestrutura e dos mecanismos de escalonamento automático. ‌ ## **Impacto** * **Duração:** Aproximadamente 15 minutos. * **Experiência do Usuário:** Cerca de **15% das transações** falharam durante a janela de pico. * **Erros Observados:** Os usuários enfrentaram erros de limite de taxa \(HTTP 429\), erros internos do servidor \(HTTP 500\) e falhas de conexão devido a desconexões prematuras \(timeout\). * **Conformidade de SLO:** A conformidade do nível de serviço caiu de uma meta de 99,8% para a faixa de 84-85%, consumindo totalmente o orçamento de erro planejado para o período. ## **Causa Raiz** O incidente foi resultado de uma combinação de três fatores principais: 1. **Pico de Tráfego Exacerbado:** Um único locatário apresentou um volume de requisições de aproximadamente **6.000 por segundo**, superando drasticamente o limite acordado de 350 TPS. 2. **Headroom de Latência Reduzido:** O componente principal de processamento estava operando com uma latência de linha de base muito próxima ao seu limite de _timeout_ de 6 segundos. Sob carga extra, as requisições excederam esse limite, impedindo o processamento bem-sucedido. 3. **Instabilidade na Camada de Rede \(Escalonamento Agressivo\):** O sistema de escalonamento automático reagiu tentando criar centenas de novas instâncias simultaneamente. Essa rápida expansão sobrecarregou o plano de controle da rede e esgotou os recursos de IP disponíveis no cluster, gerando falhas de conexão em vez de alívio de carga. ## **Resolução** A equipe de engenharia detectou a queda de disponibilidade em menos de 2 minutos através de alertas automáticos. A mitigação foi alcançada através das seguintes ações: ‌ * **Ajuste de Capacidade Mínima:** O número mínimo de instâncias ativas foi elevado manualmente para 500. * **Estabilização da Latência:** Com o aumento da capacidade fixa, a latência de processamento retornou ao patamar de **3 segundos**, estabilizando o serviço e restabelecendo a disponibilidade normal. ## **Lições Aprendidas** * **Revisão de Timeouts:** Identificamos que a derivação gradual da latência base precisa ser acompanhada de revisões periódicas nas configurações de _timeout_ para garantir margem de segurança operacional. * **Refinamento de Escalonamento:** O comportamento de escalonamento automático agressivo pode ser contraproducente se a infraestrutura de rede subjacente não estiver preparada para a velocidade da expansão. * **Governança de Tráfego:** É necessário reforçar os limites de tráfego por cliente antes que picos inesperados possam impactar a plataforma de forma global. * **Mapeamento de Erros:** Certos padrões de erro de rede não estavam adequadamente mapeados em nossos sistemas de interrupção de circuito, o que dificultou a contenção automática da falha. ‌ 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.