Instabilidade no Serviço de Integração IDToken e IDTrust

Update timeline

1. investigating Apr 02, 2026, 09:45 AM UTC

   Prezado Cliente, Identificamos uma instabilidade que afeta a disponibilidade e a latência em nossos serviços de processamento de fluxos. No momento, nossa engenharia já está mobilizada para o diagnóstico técnico e a identificação da causa raiz. Pedimos desculpas pelo transtorno e reforçamos que novas atualizações serão enviadas em breve assim que tivermos mais detalhes sobre a normalização. Equipe Unico.

2. identified Apr 02, 2026, 09:46 AM UTC

   Prezado Cliente, Confirmamos que a origem da instabilidade foi mapeada. Identificamos um pico atípico de requisições que gerou uma degradação momentânea na latência na disponibilidade da API de criação de processos. Neste momento, o time técnico já iniciou o escalonamento de recursos para absorver a demanda e restabelecer a performance ideal do ambiente. O incidente é tratado com prioridade máxima. Equipe Unico.

3. monitoring Apr 02, 2026, 09:46 AM UTC

   Prezado Cliente, Informamos que as ações corretivas de escalonamento foram executadas com sucesso e o ambiente já apresenta estabilidade. Os serviços de biometria e processamento voltaram a operar dentro dos parâmetros de normalidade. Entramos agora em fase de acompanhamento assistido e monitoramento rigoroso para garantir a consistência da performance. O serviço já pode ser utilizado normalmente, enquanto nossa equipe permanece atenta a qualquer oscilação. Equipe Unico.

4. resolved Apr 02, 2026, 09:51 AM UTC

   Status: Resolvido Prezado Cliente, Informamos o encerramento do incidente relacionado à instabilidade no processamento de fluxos (Idtoken e IDtrust). Abaixo, apresentamos o resumo executivo: Resumo Executivo e Impacto No dia 02/04/2026, entre 05:41 e 05:47, nossos sistemas apresentaram uma degradação de performance que impactou a latência e a disponibilidade da API de criação de processos (erros 500). O impacto foi breve (aproximadamente 6 minutos) e a estabilização completa ocorreu às 05:48. Causa Raiz e Resolução A causa foi identificada como um pico súbito e concentrado de requisições que excedeu a capacidade momentânea das instâncias. A resolução ocorreu de forma automática e assistida através do escalonamento de novos nós (nodes) no cluster, permitindo que as camadas de processamento e servidores de modelos absorvessem a carga. Compromisso e Próximos Passos Ressaltamos que não houve perda ou comprometimento de dados. Nossa equipe de engenharia já está trabalhando em um Postmortem detalhado para revisar os gatilhos de escalonamento automático e evitar que picos similares impactem a experiência dos usuários no futuro. Lamentamos sinceramente qualquer inconveniente causado. Equipe Unico.

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

   ### Resumo No dia 2 de abril de 2026, entre 05:41 e 05:47 \(horário de Brasília\), o serviço de avaliação de risco sofreu uma breve degradação de disponibilidade e latência. Durante esta janela, a disponibilidade do serviço caiu abaixo da nossa meta de 98,5%. O sistema se recuperou de forma automática logo após a janela de impacto, sem a necessidade de intervenção manual da equipe. ### Impacto * Múltiplos clientes foram impactados brevemente por erros de servidor \(código 5xx\). * Parte das requisições afetadas sofreu com atrasos, ficando retidas por cerca de 10 segundos antes de falharem por tempo limite excedido \(timeout\). * Adicionalmente, um alerta de limitação de taxa \(rate limit\) foi disparado para um cliente específico, resultando em um aumento de respostas com código 429. ### Causa Raiz * O incidente teve origem em um evento de manutenção de infraestrutura, quando ocorreu o encerramento de um nó computacional temporário que hospedava um contêiner de orquestração interna. * Devido a um atraso conhecido na atualização das tabelas de rotas da nossa malha de serviço \(service mesh\), uma parte do tráfego continuou sendo direcionada para o endpoint que já havia sido encerrado. * Como resultado, em vez de retornar um erro imediato, essas requisições ficaram pendentes até atingirem o limite de tempo estipulado pelo cliente ou pela malha, gerando os erros e timeouts observados. * Concomitantemente, um aumento no volume de tráfego gerado por um cliente específico ampliou a carga interna do sistema \(fan-out\), o que aumentou a quantidade de requisições impactadas por essa breve falha de roteamento. ### Resolução * O sistema se estabilizou de forma autônoma e não foi necessário aplicar medidas manuais de mitigação durante o incidente. * Os timeouts cessaram naturalmente assim que a malha de serviço convergiu suas rotas e deixou de enviar tráfego para o endpoint do contêiner encerrado. * Em resposta paralela ao aumento de tráfego, nossos mecanismos de escalonamento automático \(autoscaling\) atuaram corretamente, provisionando capacidade computacional extra logo após o término da degradação. ### Lições Aprendidas * O atraso na propagação de atualizações na malha de serviço durante o encerramento de nós pode transformar manutenções rotineiras de infraestrutura em falhas visíveis \(timeouts\) para o usuário final. * O volume de requisições recebido na borda do sistema não representa de forma direta a carga suportada pelos serviços internos, uma vez que o processamento gera múltiplas chamadas simultâneas. * Para investigar problemas de saturação em arquiteturas com múltiplos saltos, os registros gerados pela malha de serviço fornecem sinais mais precisos do que o monitoramento isolado de aplicação. ### Ações Futuras * Implementar mecanismos mais claros de detecção e mitigação para tratar possíveis atrasos no roteamento da malha de serviço durante o encerramento de nós computacionais. * Avaliar a adoção de estratégias de cache interno para evitar o reprocessamento desnecessário de operações idênticas submetidas consecutivamente. * Conduzir um estudo aprofundado sobre os limites de comparação e carga gerada por fluxos complexos, visando otimizar a escalabilidade dos serviços sem comprometer a eficácia do sistema.