Instabilidade e Degradação de Performance - IDLive

Update timeline

1. identified Apr 27, 2026, 02:08 AM UTC

   Identificamos a causa raiz da instabilidade. A degradação e o aumento de latência ocorreram devido a um pico atípico e massivo de requisições, que acabou impactando uma parcela de nossos clientes. Gostaríamos de tranquilizá-los informando que nossa equipe de engenharia já mapeou a origem do problema e iniciou imediatamente a implementação das medidas corretivas. O escalonamento de recursos e os ajustes de tráfego já estão em curso para estabilizar totalmente o produto e garantir que a volumetria seja absorvida sem novos impactos. Enviaremos uma nova atualização em breve. Equipe Unico.

2. monitoring Apr 27, 2026, 02:09 AM UTC

   Gostaríamos de informar que as ações corretivas foram executadas com sucesso. Realizamos o escalonamento de recursos necessários para a absorção da volumetria atípica de requisições e o ambiente já apresenta estabilidade. Vale ressaltar que o impacto sistêmico ocorreu apenas para uma parcela mínima de clientes. Portanto, caso a sua operação não tenha registrado um aumento no número de erros durante o período de instabilidade, ela não foi afetada. O motor sistema já pode ser utilizado normalmente em suas operações. No entanto, por precaução, manteremos o ambiente sob acompanhamento assistido. Nossa equipe de engenharia segue realizando um monitoramento rigoroso das métricas para garantir a consistência da performance e atuará imediatamente diante de qualquer oscilação. Agradecemos a compreensão de todos durante as tratativas. Equipe Unico.

3. resolved Apr 27, 2026, 02:20 AM UTC

   Resumo Executivo e Impacto: Informamos que o incidente que afetou a disponibilidade do IDLive foi totalmente mitigado e o serviço encontra-se operando com estabilidade e dentro dos parâmetros normais. A instabilidade ocorreu hoje, das 22:30 às 22:46, resultando em elevação de latência e degradação temporária do nosso motor de liveness. Reforçamos que o impacto sistêmico ocorreu apenas para uma parcela mínima de clientes. Caso a sua operação não tenha registrado um aumento no número de erros durante este curto intervalo, ela consequentemente não foi afetada. Além disso, destacamos de forma categórica que este evento não resultou em qualquer tipo de comprometimento ou perda de dados. Nossa equipe de engenharia atuou rapidamente para realizar a normalização do ambiente. O sistema voltou à estabilidade às 22:46 e, após um período de monitoramento rigoroso e acompanhamento assistido, confirmamos a normalização total da performance. Um documento de Postmortem detalhado será compartilhado em breve, contendo análises aprofundadas e o mapeamento completo das ações preventivas que serão implementadas em nossa infraestrutura. Pedimos sinceras desculpas por qualquer inconveniente que este evento possa ter causado às suas operações e agradecemos a confiança e a parceria de sempre. Equipe Unico.

4. postmortem May 12, 2026, 05:26 PM UTC

   **Relatório de Incidente** **Resumo** No dia 26 de abril de 2026, enfrentamos um aumento repentino e expressivo de tráfego que sobrecarregou nossos serviços, resultando em 16 minutos de indisponibilidade. **Impacto** * O serviço apresentou indisponibilidade entre 22h30 e 22h46 \(Horário de Brasília\) para todos os usuários. * A maioria das requisições falhou durante esse período, retornando principalmente erros do tipo 429 e 500. * Clientes que mantinham um volume de tráfego dentro da normalidade também foram impactados pela sobrecarga, enfrentando uma taxa de erro generalizada de aproximadamente 87%. **Causa Raiz** * O incidente foi desencadeado por um pico repentino e simultâneo de tráfego originado por um grupo específico de clientes, o qual multiplicou o volume normal de requisições em cinco vezes em um intervalo de menos de 10 minutos. * O nosso sistema de escalonamento automático de infraestrutura atuou de forma reativa e levou cerca de 10 minutos para conseguir provisionar a capacidade necessária para absorver o impacto. * Como a política de limitação de requisições do sistema estava configurada de forma global \(e não individualizada por cliente\), a plataforma atingiu sua saturação e começou a rejeitar conexões de forma indiscriminada. **Resolução** * A estabilidade da plataforma e a disponibilidade dos serviços foram restauradas naturalmente assim que o pico anômalo de tráfego diminuiu. * O sistema voltou a operar de forma estável e sem erros às 22h46. **Ações de Melhoria** * Revisão e expansão dos limites mínimos de capacidade da plataforma para garantir uma margem de segurança imediata contra picos súbitos. * Implementação de controles e limites de taxa de requisição individualizados por cliente, garantindo isolamento. * Ajuste nas políticas do escalonamento automático para garantir uma resposta arquitetural mais agressiva a aumentos de carga. **Lições Aprendidas** * Arquiteturas de escalonamento que dependem puramente de comportamentos reativos são insuficientes para gerenciar picos de tráfego abruptos e simultâneos de múltiplos clientes. * A falta de uma limitação de tráfego segmentada permite que eventos isolados de alto volume de uso prejudiquem severamente usuários com comportamento regular \(efeito de "vizinho barulhento"\). * O provisionamento prévio de infraestrutura \(capacidade pré-aquecida\) é essencial para eliminar o tempo de inicialização de novos recursos durante flutuações extremas de demanda.