Unico experienced a minor incident on January 26, 2026 affecting Verificação Identidade (API) and Portal Cliente and 1 more component, lasting 4m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- identified Jan 26, 2026, 09:26 PM UTC
Prezado cliente, Estamos com indisponibilidade na funcionalidade Getselfie. O impacto é restrito aos usuários que tentam acessar este recurso específico, recebendo erros de carregamento ou ausência de dados. Esta é uma indisponibilidade resultante da desativação de uma configuração global para proteger a estabilidade do banco de dados principal devido ao incidente anterior. Nosso time ja esta trabalhando para reestabelecer o serviço.
- monitoring Jan 26, 2026, 09:53 PM UTC
Ambiente normalizado. Resumo Executivo e Impacto A funcionalidade de getselfie foi totalmente restabelecida e o serviço opera agora em níveis normais de desempenho. Após um breve período de indisponibilidade parcial do recurso — necessário para garantir a integridade da infraestrutura — a correção técnica foi aplicada com sucesso. Não há mais relatos de latência ou erros nas consultas de detalhes de processos para a base de clientes. Causa Raiz e Resolução A resolução definitiva foi alcançada através da implementação de um hotfix que otimizou a lógica de consulta ao banco de dados, adicionando os filtros de partição necessários que estavam ausentes. Com a eficiência da consulta garantida, a configuração de funcionalidade (feature flag) foi reativada de forma segura. O sistema foi monitorado durante a reativação e não apresentou novos picos de consumo de memória ou contenção de leitura, confirmando a eficácia da correção aplicada. Duração das 16h15m as 18h43m
- monitoring Jan 26, 2026, 09:57 PM UTC
Ambiente normalizado. Resumo Executivo e Impacto A funcionalidade de getselfie foi totalmente restabelecida e o serviço opera agora em níveis normais de desempenho. Após um breve período de indisponibilidade parcial do recurso — necessário para garantir a integridade da infraestrutura — a correção técnica foi aplicada com sucesso. Não há mais relatos de latência ou erros nas consultas de detalhes de processos para a base de clientes. Causa Raiz e Resolução A resolução definitiva foi alcançada através da implementação de um hotfix que otimizou a lógica de consulta ao banco de dados, adicionando os filtros de partição necessários que estavam ausentes. Com a eficiência da consulta garantida, a configuração de funcionalidade (feature flag) foi reativada de forma segura. O sistema foi monitorado durante a reativação e não apresentou novos picos de consumo de memória ou contenção de leitura, confirmando a eficácia da correção aplicada. Duração das 16h15m as 18h43m
- resolved Jan 26, 2026, 09:58 PM UTC
Ambiente normalizado. Resumo Executivo e Impacto A funcionalidade de getselfie foi totalmente restabelecida e o serviço opera agora em níveis normais de desempenho. Após um breve período de indisponibilidade parcial do recurso — necessário para garantir a integridade da infraestrutura — a correção técnica foi aplicada com sucesso. Não há mais relatos de latência ou erros nas consultas de detalhes de processos para a base de clientes. Causa Raiz e Resolução A resolução definitiva foi alcançada através da implementação de um hotfix que otimizou a lógica de consulta ao banco de dados, adicionando os filtros de partição necessários que estavam ausentes. Com a eficiência da consulta garantida, a configuração de funcionalidade (feature flag) foi reativada de forma segura. O sistema foi monitorado durante a reativação e não apresentou novos picos de consumo de memória ou contenção de leitura, confirmando a eficácia da correção aplicada. Duração das 16h15m as 18h43m
- postmortem Feb 05, 2026, 12:57 PM UTC
# Postmortem: ## **Resumo** No dia 26 de janeiro de 2026, entre **15:10 e 16:10**, nosso serviço de autenticação e processamento \(TCA\) apresentou degradação significativa, resultando em alta latência e erros de conexão para diversos clientes. O incidente foi desencadeado por uma saturação no pool de recursos do banco de dados, causada por consultas ineficientes durante um processo de migração de dados e agravada por uma configuração de funcionalidade específica. ## **Impacto** * **Duração:** 1 hora. * **Serviços Afetados:** O portal de gerenciamento e as APIs de consulta de detalhes de processos e selfies. * **Experiência do Usuário:** Clientes enfrentaram erros de timeout \(500\) e falhas na conclusão de jornadas que dependiam da visualização de dados de biometria. * **Escopo:** Inicialmente limitado a consultas específicas, o problema evoluiu para uma degradação generalizada de todas as jornadas do serviço devido ao esgotamento de conexões do banco de dados. ## **Causa Raiz** A causa raiz foi a **saturação de recursos no banco de dados**. 1. **Consultas Ineficientes:** Durante uma migração de dados, o volume de requisições aumentou, executando consultas em tabelas particionadas sem a identificação do índice de partição. 2. **Full Scans:** Sem o índice, o banco realizava varreduras completas em mais de 300 partições para cada busca, consumindo rapidamente o pool de "locks" disponíveis. 3. **Efeito Cascata:** O esgotamento desses recursos causou lentidão generalizada. Em resposta, o sistema tentou escalar automaticamente, o que abriu ainda mais conexões, limpando o cache de memória do banco e degradando a performance global. 4. **Configuração de Feature:** Uma funcionalidade ativada recentemente também realizava consultas sem índices, contribuindo para a carga excessiva. ## **Resolução** Para restaurar a estabilidade, a equipe técnica adotou as seguintes medidas: * **Suspensão da Migração:** O processo de importação de dados foi interrompido imediatamente para reduzir a carga. * **Desativação de Funcionalidade:** A configuração de consulta de selfies foi desabilitada globalmente, o que permitiu a recuperação imediata da performance do banco de dados. * **Troca de Réplica:** Tentou-se o redirecionamento do tráfego para diferentes instâncias de leitura para mitigar o gargalo. * **Hotfix:** Foi aplicado um ajuste emergencial no código para garantir que todas as consultas utilizassem obrigatoriamente os índices de partição corretos. ## **Lições Aprendidas** * **Visibilidade de Recursos:** Identificamos a necessidade de monitorar métricas específicas de exaustão de recursos de banco de dados \(como locks\) que não estavam em nosso monitoramento padrão. * **Validação de Índices:** Reforçamos a importância de garantir que novos endpoints ou processos de migração nunca realizem buscas em tabelas particionadas sem os filtros adequados. * **Gestão de Configurações:** Melhorar a correlação entre a ativação de funcionalidades \(flags\) e métricas de performance para reduzir o tempo de identificação de problemas \(MTTR\). 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.