Instabilidade no Serviço de Integração IDunico, IDtoken e IDTrust

Update timeline

1. investigating Apr 02, 2026, 11:25 PM UTC

   Identificamos uma instabilidade na capacidade de criação de processos em nossa plataforma, o que pode impactar a disponibilidade de serviços como o IdUnico, Idtoken e IDTrust. Nossa equipe de engenharia já está mobilizada para o diagnóstico e trabalhando com prioridade máxima para entender a origem dessa oscilação. Nosso foco inicial é a restauração da plena estabilidade das funcionalidades afetadas. Reforçamos que novas atualizações serão enviadas em breve assim que tivermos mais detalhes sobre a evolução do cenário. Equipe Unico.

2. identified Apr 02, 2026, 11:27 PM UTC

   Informamos que a origem da instabilidade no produto IDunico e IDToken foi mapeada. Identificamos uma queda abrupta na disponibilidade de instâncias de processamento na nossa camada de orquestração, o que gerou erros intermitentes e latência nos serviços de criação de processos. O time de operações já iniciou a implementação das medidas corretivas, incluindo o escalonamento de recursos e ajuste de réplicas para garantir a resiliência do ambiente. O incidente está sendo tratado com prioridade máxima. Status: Em correção. Equipe Unico.

3. monitoring Apr 02, 2026, 11:28 PM UTC

   Informamos que as ações corretivas na camada de orquestração e nos serviços de processamento foram executadas com sucesso. No momento, o ambiente apresenta estabilidade e os indicadores de disponibilidade retornaram aos níveis normais. Iniciamos agora um período de acompanhamento assistido e monitoramento rigoroso para garantir a consistência da performance em todos os fluxos impactados O serviço já pode ser utilizado normalmente. Nossa equipe permanece atenta a qualquer oscilação para garantir a continuidade da operação. Equipe Unico.

4. resolved Apr 02, 2026, 11:31 PM UTC

   Comunicamos o encerramento do incidente relacionado à disponibilidade do serviço Create Process. Resumo Executivo e Impacto No dia 02/04/2026, entre 19:30 e 19:32 (-03), observamos uma degradação severa na criação de processos e serviços síncronos. O impacto teve duração de aproximadamente 2 minutos, resultando em erros de resposta e indisponibilidade momentânea em fluxos que utilizam o motor biométrico. Causa Raiz e Resolução A instabilidade foi causada por uma queda crítica no número de réplicas ativas na nossa camada de orquestração de serviços, reduzindo drasticamente a capacidade de processamento. A rápida atuação da engenharia permitiu o reestabelecimento automático e manual dos recursos, normalizando o tráfego em poucos minutos. Confirmamos que não houve qualquer perda de dados ou comprometimento da integridade das informações. Compromisso e Próximos Passos Como medida preventiva para evitar reincidências, revisamos e ajustamos as configurações de réplicas mínimas para garantir maior resiliência em períodos de alta demanda. Um Postmortem detalhado com os planos de ação de longo prazo será compartilhado com os interessados em breve. Pedimos sinceras desculpas pelo transtorno causado e reafirmamos nosso compromisso com a transparência e excelência de nossos serviços. Equipe Unico.

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

   **Resumo** No dia 2 de abril de 2026, entre 19:31 e 19:34 \(horário local\), experimentamos uma breve e severa degradação em um de nossos processos internos de criação. A disponibilidade do serviço caiu abaixo da nossa meta estabelecida de 99.3%. ‌ **Impacto** Durante o período de aproximadamente três minutos, a indisponibilidade afetou a jornada crítica do usuário, causando elevação na latência e retorno de erros \(HTTP 5xx\). O problema impactou diversos clientes devido a falhas de comunicação interna que resultavam em respostas nulas por parte dos nossos serviços de orquestração. ‌ **Causa Raiz** O evento inicial foi desencadeado pela perda simultânea de quatro instâncias de processamento em nuvem do tipo "spot". Embora esse comportamento seja nativo da infraestrutura em nuvem, o impacto foi amplificado por duas vulnerabilidades internas: ‌ * **Concentração de Carga:** A configuração de implantação da aplicação não impunha uma regra estrita de separação \(anti-afinidade\). Isso permitiu que 14 das 15 réplicas de um serviço fundamental se concentrassem nesses exatos quatro nós que foram desligados. * **Atraso de Roteamento:** Houve um atraso de cerca de três minutos na atualização das tabelas de roteamento da nossa malha de serviços de rede. Isso fez com que o tráfego continuasse sendo enviado para endereços IP inativos, gerando erros aos solicitantes muito tempo após o desligamento dos componentes. **Resolução** A falha foi detectada de forma rápida e precisa pelos nossos alertas de monitoramento automatizados, que indicaram imediatamente a queda na disponibilidade. A equipe de engenharia isolou rapidamente a causa da instabilidade. Como mitigação imediata, foi aplicada e ativada uma regra de anti-afinidade rígida para a implantação do serviço em produção, forçando o espalhamento das réplicas e reduzindo a probabilidade de uma perda simultânea no futuro. ‌ **Ações Preventivas** * Garantir a exigência rigorosa de regras de anti-afinidade em todas as implantações afetadas. * Trabalhar ativamente para investigar e reduzir o atraso de descoberta e propagação de roteamento interno. * Reavaliar a infraestrutura em nuvem e estudar a viabilidade de migrar componentes mais críticos de instâncias temporárias \("spot"\) para instâncias sob demanda. **Lições Aprendidas** * O comportamento padrão de distribuição dos orquestradores de contêineres não é suficiente para garantir a segurança operacional de cargas de trabalho sensíveis sem configurações explícitas de separação. * A interrupção repentina de máquinas do tipo "spot" é um comportamento normal e esperado da nuvem, e nossos serviços precisam estar arquitetados para tolerar e absorver essa volatilidade como parte de sua operação diária. * O tempo de atualização da infraestrutura de roteamento afeta severamente a recuperação do sistema. Mesmo quando as aplicações realizam desligamentos graciosos e seguros, os usuários podem enfrentar falhas se a camada de rede demorar a reconhecer que um destino não está mais disponível.