Instabilidade no Serviço de Integração By Unico, IDTtrust, IDunico e liveness

Update timeline

1. identified Apr 15, 2026, 07:49 PM UTC

   Prezado Cliente, Identificamos uma instabilidade na capacidade de criação de processos em nossa plataforma, o que pode impactar a disponibilidade e a performance do produto IDCloud (Create Process). Nossa engenharia já está mobilizada para o diagnóstico e identificação da causa raiz. No momento, observamos um aumento na latência e interrupções pontuais na jornada de processamento. Estamos tratando o caso com prioridade máxima para restabelecer a normalidade o mais breve possível. Novas atualizações serão enviadas em breve. Equipe Unico.

2. identified Apr 15, 2026, 08:31 PM UTC

   Prezado Cliente, Status: Em correção Confirmamos que a origem do problema foi mapeada. Identificamos uma latência elevada em serviços internos de processamento, o que gerou um efeito cascata de timeouts na criação de processos do IDCloud. Nossa equipe já iniciou medidas corretivas, incluindo a reinicialização de componentes específicos. O time de engenharia permanece atuando com urgência para garantir que o fluxo de requisições seja normalizado imediatamente. Equipe Unico.

3. monitoring Apr 15, 2026, 08:32 PM UTC

   Prezado Cliente, Informamos que as ações corretivas, como o restart de serviços e a contenção de processos auxiliares, foram executadas e o ambiente já apresenta sinais de recuperação e estabilidade. O serviço já pode ser utilizado, porém manteremos um acompanhamento assistido e um monitoramento rigoroso dos indicadores de latência e disponibilidade pelos próximos minutos. Nossa equipe permanece em prontidão para atuar diante de qualquer nova oscilação na performance. Equipe Unico.

4. resolved Apr 15, 2026, 09:23 PM UTC

   Prezado Cliente, Informamos o encerramento do incidente relacionado ao IDCloud. Resumo Executivo e Impacto Entre 16:25 e 17:33, observamos uma queda na disponibilidade e alta latência no fluxo de criação de processos (IDUnico Sync). O impacto manifestou-se através de erros de timeout e falhas pontuais na jornada de autenticação e no motor de liveness. O serviço foi totalmente restabelecido e as métricas de performance retornaram aos níveis operacionais. Ressaltamos que não houve perda ou comprometimento de dados. Causa Raiz e Resolução A instabilidade foi causada por um conflito na atualização de configurações interna durante um processo de escalonamento automático. Isso gerou uma sobrecarga nos componentes de comunicação em um pool de recursos que apresentava baixa folga de processamento. A resolução envolveu a reinicialização dos componentes travados, o isolamento de nós de infraestrutura degradados e o aumento planejado de capacidade em zonas de redundância. Compromisso e Próximos Passos Como medida preventiva, estamos revisando as políticas de escalonamento automático e a compatibilidade de versões dos componentes de rede para evitar novos conflitos de configuração. Um Postmortem detalhado será compartilhado em breve com o detalhamento das ações de longo prazo. Pedimos desculpas pelo impacto e agradecemos a compreensão. Equipe Unico.

5. postmortem May 12, 2026, 02:21 PM UTC

   **PostMortem: Instabilidade no Serviço de Integração By Unico, IDTtrust, IDunico e liveness** ‌ **Resumo** Em 15 de abril de 2026, nossa plataforma registrou uma degradação expressiva na disponibilidade do serviço de criação de processos. A taxa de disponibilidade, que possui como meta um nível de serviço \(SLO\) de 95%, chegou a cair para cerca de 83% a 84% durante o período afetado. Todos os indicadores já foram totalmente recuperados para os parâmetros normais e não há mais nenhum impacto contínuo sendo observado para nossos clientes. ‌ **Impacto** O incidente afetou diretamente as operações de criação de processos entre, aproximadamente, 16h18 e 18h26 \(Horário de Brasília\). Durante essa janela, a disponibilidade caiu de forma generalizada abaixo do limite esperado de 95%. Múltiplos clientes relataram ter recebido mensagens de erro interno \(erros 500\) e esgotamento de tempo limite \(timeouts\) em solicitações feitas aos nossos serviços. ‌ **Causa Raiz** O incidente foi causado por uma saturação severa de recursos nos servidores que compõem nossa infraestrutura em nuvem. Identificamos que o componente interno responsável pela exportação e leitura de logs sofreu uma falha em seu plugin de saída de dados, ficando sem resposta. Devido à ausência de uma configuração que limitasse seu uso de memória, o componente continuou acumulando dados ininterruptamente, crescendo cerca de 30MB a cada 2 minutos. Esse acúmulo forçava a infraestrutura a reiniciar o processo repetidas vezes quando este atingia seu limite máximo, criando um ciclo de instabilidade. Esse comportamento consumiu excessivamente a CPU e a memória das máquinas virtuais, além de gerar altos picos de espera em operações de disco. A saturação dos servidores impediu que as aplicações vitais para o negócio recebessem os recursos necessários para processar o tráfego de rede, gerando atrasos em cascata, travamento de contêineres e a perda de disponibilidade observada. ‌ **Resolução** Nossos sistemas de alerta detectaram o incidente nos primeiros minutos e a equipe de plantão iniciou a investigação imediatamente. A resolução técnica consistiu na identificação cirúrgica dos nós e contêineres degradados. Para mitigar o impacto, a equipe de engenharia isolou os servidores afetados e removeu os componentes degradados do cluster de serviços. A reinicialização das instâncias dos serviços de aplicação restabeleceu a performance, trazendo a disponibilidade de volta para acima da marca de 95%. ‌ **Ações Futuras** * Revisar as políticas de alocação de recursos do cluster e regras de escalonamento automático para aumentar a resiliência do sistema como um todo. * Investigar e aplicar medidas de correção definitivas no componente de logs para evitar cenários crônicos de esgotamento de memória e reinicializações forçadas. **Lições Aprendidas** * **Detecção Ágil:** Nossas ferramentas de observabilidade dispararam alertas assertivos sobre a degradação de imediato. A rapidez com que o comitê de crise foi acionado permitiu uma coordenação veloz das tarefas de mitigação. * **Abordagem de Mitigação:** A equipe evitou ações drásticas e de longo alcance, acertando ao isolar seletivamente as partes problemáticas da infraestrutura, o que minimizou interrupções adicionais. * **Prevenção de Instabilidades Subjacentes:** O problema de vazamento de memória do plugin de logs já vinha ocorrendo de forma mais isolada por mais de uma semana antes do incidente produtivo. O monitoramento dessas degradações ocultas precisa ser tratado de forma mais proativa antes que culminem em indisponibilidade.