Instabilidade na Integração das capacidades que utilizam IdScore

Update timeline

1. investigating Apr 04, 2026, 04:44 PM UTC

   Prezado Cliente, Identificamos uma instabilidade na capacidade de geração do Score de Autenticação, que está apresentando lentidão no processamento de fluxos assíncronos. Essa oscilação pode impactar o tempo de recebimento das respostas de análise e, em alguns casos, resultar no cancelamento de processos em aberto. Nossa engenharia já está mobilizada para o diagnóstico e trabalhando na identificação da causa raiz para normalizar o serviço o mais breve possível. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar o impacto. Reforçamos que novas atualizações serão enviadas em breve. Equipe Unico.

2. identified Apr 04, 2026, 04:45 PM UTC

   Prezado Cliente, Confirmamos que a origem da lentidão no Score de Autenticação foi mapeada. Identificamos uma contenção de recursos em nossa camada de banco de dados, causada por uma consulta específica que está gerando bloqueios e impedindo o processamento fluido das informações. O time de operações já iniciou a implementação de medidas corretivas, incluindo a interrupção das sessões problemáticas e o reescalonamento de recursos para escoar o volume de processos acumulados. Estamos tratando este cenário com prioridade máxima e senso de urgência para restabelecer a performance padrão. Status: Em correção. Equipe Unico.

3. monitoring Apr 04, 2026, 05:07 PM UTC

   Prezado Cliente, Informamos que as ações corretivas para eliminar os bloqueios na camada de dados foram executadas e o ambiente já apresenta estabilidade. O volume de processos acumulados está sendo processado e os índices de latência do Score de Autenticação retornaram aos níveis esperados. Iniciamos agora um período de acompanhamento assistido e monitoramento rigoroso para garantir a consistência da performance e evitar novas oscilações. O serviço já pode ser utilizado normalmente, mas nossa equipe permanece atenta a qualquer comportamento atípico. Equipe Unico.

4. resolved Apr 04, 2026, 05:18 PM UTC

   Prezado Cliente, Comunicamos o encerramento do incidente relacionado à latência no Score de Autenticação onde impactou IDscore e IDunico(apenas fluxo que derivaram para o Check). Resumo Executivo e Impacto No dia 04/04/2026, entre 12h13 e 14h01 (horário local), identificamos uma degradação na performance do processamento assíncrono do Score. O impacto manifestou-se através de uma lentidão sistêmica na entrega de resultados de análise, afetando a experiência de verificação em tempo real e o tempo de resposta das capacidades integradas ao IdScore. Causa Raiz e Resolução A causa raiz foi identificada como uma contenção de escrita (locks) em nossa camada de banco de dados, originada por uma rotina de consulta que não utilizava parâmetros de leitura otimizados. Isso gerou um efeito em cadeia que travou atualizações e inserções de novos dados, resultando em um acúmulo de processos pendentes. A resolução consistiu na terminação das sessões causadoras do bloqueio e na aplicação de ajustes emergenciais para liberar o fluxo de processamento e escoar o volume represado. Ressaltamos que não houve perda de dados durante o evento. Compromisso e Próximos Passos Para evitar recorrências, nossa equipe de engenharia aplicará uma correção definitiva no código das consultas identificadas e revisará os índices de performance da camada de dados. Um Postmortem detalhado será compartilhado em breve com as lições aprendidas e as melhorias estruturais implementadas. Pedimos sinceras desculpas pelo impacto causado em sua operação e agradecemos a compreensão. Equipe Unico.

5. postmortem May 05, 2026, 01:55 PM UTC

   ## Relatório de Incidente \(Postmortem\) **Resumo** No dia 4 de abril de 2026, nossa plataforma enfrentou um incidente que causou degradação severa na latência do processamento assíncrono de pontuações de autenticação. Uma consulta sistêmica ao banco de dados começou a gerar bloqueios \(locks\) em cascata, afetando a performance geral e comprometendo o nosso nível de serviço \(SLO\). A equipe atuou prontamente para mitigar o problema, isolando a regra causadora e restaurando a estabilidade da plataforma. ‌ **Impacto** * O nível de conformidade do nosso SLO de latência sofreu uma queda de aproximadamente 98-100% para índices críticos de 30-35%. * O orçamento de erro \(error budget\) designado para o serviço foi completamente esgotado. * Ocorreu uma lentidão sistêmica no processamento de itens de pré-análise, impactando o desempenho para múltiplos clientes simultaneamente. * O impacto total da degradação durou 1 hora e 48 minutos, ocorrendo entre 12:13 e 14:01 \(horário local\). **Causa Raiz** A instabilidade teve como causa raiz a saturação dos recursos de processamento do banco de dados principal. Uma etapa do sistema desenhada para consultar históricos antigos estava executando consultas sem as otimizações e diretrizes adequadas para o controle de concorrência — especificamente, a ausência de comandos apropriados \(como `WITH (NOLOCK)`\). Ao realizar varreduras extensas, essa consulta reteve bloqueios prolongados nas tabelas, o que impediu outras operações críticas de inserção e atualização no banco. Essa contenção criou um efeito cascata no sistema: as conexões ativas no banco saltaram de uma média de 20-30 para até 150-170, e as transações abertas geraram picos de 40 a 60 processos retidos. O acúmulo travou momentaneamente as validações de diversos inquilinos da plataforma, gerando a latência relatada. ‌ **Resolução** Assim que os sistemas de monitoramento apontaram a queda de métricas e a equipe identificou a consulta problemática retendo transações, a ação de mitigação imediata consistiu em desabilitar temporariamente a regra de negócio geradora dos bloqueios. Por tratar-se de uma validação inicial no funil de processamento, essa foi uma ação direcionada que não causou prejuízos aos fluxos de negócios, pois as regras subsequentes do fluxo assumiram o tratamento das divergências de validação. A desativação aliviou de imediato a contenção no banco de dados, liberando as inserções e atualizações e normalizando os serviços em tempo real. ‌ **Ações Futuras** * Realizar uma auditoria sistêmica em outras consultas de processamento para identificar e refatorar padrões de código que operem sobre dados históricos sem o uso de diretrizes de bloqueio seguras. * Analisar estruturalmente e refatorar a regra de negócio temporariamente suspensa, visando a sua reativação de maneira segura e otimizada. * Estudar e avaliar a implementação de estratégias de isolamento entre clientes \(tenant isolation\) e particionamento de recursos, minimizando assim o raio de impacto de problemas em bancos de dados compartilhados. **Lições Aprendidas** * **Detecção Eficaz:** Os alertas de degradação rápida baseados em SLO funcionaram de maneira extremamente eficaz, permitindo que a falha fosse detectada rapidamente e engajasse os engenheiros com agilidade. * **Mitigação Documentada:** A existência de procedimentos operacionais \(runbooks\) voltados à desativação pontual de regras se provou inestimável, garantindo que a mitigação ocorresse de forma controlada, segura e com impacto mínimo. * **Oportunidades Preventivas:** O incidente destacou a importância de mantermos revisões proativas contínuas nas arquiteturas de consultas complexas. * **Melhorias de Observabilidade:** Evoluir os sistemas automáticos para criar alertas específicos ou circuit breakers voltados à contenção excessiva em níveis de banco de dados nos permitirá detectar e resolver anomalias ainda mais precocemente.