Instabilidade na criação de processos - IDCloud

Update timeline

1. identified Apr 29, 2026, 12:23 AM UTC

   Prezado Cliente, Identificamos uma instabilidade em nossos serviços que pode ter impactado a disponibilidade de uma parcela mínima de nossas requisições para os fluxos do IDCloud(ByUnico e ByClient) Nossa engenharia já está totalmente mobilizada para identificar o motivador do incidente e monitorando o ambiente. Os picos de erros iniciaram por volta das 19:44BRT e foram resolvidos as 20:07BRT pelo nosso time de engenharia. Reforçamos nosso compromisso com a transparência e enviaremos novas atualizações assim que houver novidades sobre a resolução. Equipe Unico.

2. monitoring Apr 29, 2026, 12:26 AM UTC

   Prezado Cliente, Informamos que as ações corretivas foram executadas com sucesso e o ambiente já apresenta estabilidade. Neste momento, nossas equipes de engenharia e operações iniciaram um período de monitoramento rigoroso e acompanhamento assistido de indicadores para garantir a consistência da performance em toda a nossa malha de serviços. Os serviços já podem ser utilizados normalmente, mas permaneceremos atentos a qualquer oscilação residual. Reiteramos que o impacto atingiu apenas uma parcela mínima de requisições. Seguiremos acompanhando o comportamento do ambiente e enviaremos novas atualizações em breve. Equipe Unico.

3. resolved Apr 29, 2026, 12:52 AM UTC

   Prezado Cliente, Incidente resolvido. Informamos que as ações corretivas foram executadas com sucesso e o ambiente já apresenta estabilidade. Neste momento, nossas equipes de engenharia e operações iniciaram um período de monitoramento rigoroso e acompanhamento assistido de indicadores para garantir a consistência da performance em toda a nossa malha de serviços. Os serviços já podem ser utilizados normalmente. Pedimos desculpas pelo transtorno e em breve compartilharemos mais detalhes do ocorrido através de um PostMortem. Atenciosamente, Equipe Unico.

4. postmortem May 21, 2026, 01:59 PM UTC

   ## Relatório de Incidente \(Postmortem Público\) ### Resumo No dia 28 de abril de 2026, nossos serviços de autenticação e validação enfrentaram uma degradação de disponibilidade, caindo para menos de **95%**. O serviço recuperou-se sem intervenção manual e os tempos de resposta voltaram ao normal em poucos minutos. ### Impacto Múltiplos serviços dependentes foram afetados devido à exaustão de um pool de conexões em nossa infraestrutura de retaguarda. Clientes de diversos segmentos \(incluindo bancos, fintechs, varejo e plataformas de entretenimento\) experienciaram falhas de sessão e validação biométrica, gerando centenas de erros internos em cascata. O problema atingiu nosso ambiente de forma uniforme, confirmando que não foi um incidente isolado de um único cliente. ### Causa Raiz A degradação foi desencadeada por uma convergência de dois fatores simultâneos: * **Remoção prévia de índices de banco de dados:** No dia anterior, índices específicos haviam sido removidos de uma de nossas tabelas como medida corretiva para conter um pico de uso de CPU. A ausência desses índices impediu que as consultas utilizassem varreduras eficientes, forçando operações distribuídas que dependiam da comunicação entre diferentes nós da infraestrutura. * **Instabilidade no provedor de nuvem:** Houve um evento de instabilidade de rede em nosso provedor de nuvem, afetando a região _us-east_. Essa falha amplificou severamente a degradação de desempenho já causada pela falta dos índices. A combinação destes fatores fez com que o tempo de resposta do nosso banco de dados aumentasse drasticamente, atingindo um pico de aproximadamente **9.750ms**. A lentidão na resposta segurou as conexões ativas por muito mais tempo do que o normal, saturando nosso pool de conexões e impedindo que novas requisições fossem processadas, o que gerou falhas para os serviços subsequentes. ### Resolução O incidente foi autossolucionado pela infraestrutura. Os tempos de resposta retornaram ao normal naturalmente à medida que os picos de latência transitórios foram absorvidos pelo ambiente. ### Itens de Ação * Recriação imediata dos índices de banco de dados que haviam sido removidos. * Aumento da capacidade mínima de processamento em nossa configuração de escalonamento automático \(autoscaling\) para reduzir o risco de lentidões repentinas causadas por flutuações de demanda. ### Lições Aprendidas * **Análise de risco em alterações de infraestrutura:** A remoção dos índices corrigiu um problema pontual \(consumo de CPU\), mas criou outro ao degradar a performance de leitura. Há a necessidade de um processo mais estruturado para avaliar compensações entre leitura e gravação antes de aplicar alterações estruturais em tabelas de alto tráfego. * **Monitoramento pós-mudança:** A degradação gerada pela remoção dos índices não foi detectada até se tornar um incidente completo no dia seguinte. A implementação de um monitoramento rigoroso e validação contínua \(como acompanhamento de latência\) nas horas seguintes a alterações críticas poderia ter antecipado o problema. * **Ajuste de infraestrutura base:** A configuração mínima do nosso escalonamento automático era muito baixa, permitindo que o sistema ficasse operando no limite. Elevar esse limite mínimo reduz significativamente a probabilidade de falhas e picos de latência durante aumentos rápidos de demanda.