Instabilidade no Serviço de Alerta de comportamento ID Trust

Update timeline

1. monitoring Mar 20, 2026, 06:42 PM UTC

   Prezado Cliente, Tivemos uma pequena instabilidade entre as 15:00 até as 15:06 no produto Alerta de Comportamento (ID Trust) gerando aumento no tempo de resposta ou erros nas requisições. O serviço já pode ser utilizado normalmente em suas operações. Contudo, iniciamos agora uma fase de monitoramento rigoroso e acompanhamento assistido para garantir a consistência da performance e a estabilidade das taxas de latência. Um relatório detalhado (Postmortem) com a análise profunda da causa raiz e a matriz completa de ações preventivas será compartilhado em breve. Pedimos sinceras desculpas por qualquer impacto ou transtorno gerado em sua operação e agradecemos a confiança e compreensão durante nossa atuação. Atenciosamente, Equipe Unico

2. resolved Mar 20, 2026, 07:03 PM UTC

   Prezado Cliente, Tivemos uma pequena instabilidade entre as 15:00 até as 15:06 no produto Alerta de Comportamento (ID Trust) gerando aumento no tempo de resposta ou erros nas requisições. O serviço já pode ser utilizado normalmente em suas operações. Contudo, iniciamos agora uma fase de monitoramento rigoroso e acompanhamento assistido para garantir a consistência da performance e a estabilidade das taxas de latência. Um relatório detalhado (Postmortem) com a análise profunda da causa raiz e a matriz completa de ações preventivas será compartilhado em breve. Pedimos sinceras desculpas por qualquer impacto ou transtorno gerado em sua operação e agradecemos a confiança e compreensão durante nossa atuação. Atenciosamente, Equipe Unico

3. postmortem Mar 30, 2026, 03:05 PM UTC

   # Postmortem: Instabilidade no Serviço de Alerta de comportamento ID Trust ## Sumário Em 20 de março de 2026, entre 15:00 e 15:06 BRT, nosso componente de **Avaliação de Risco** apresentou uma queda de disponibilidade, operando abaixo do limite estabelecido de **98.5%**. O incidente foi desencadeado por uma redução súbita na capacidade de processamento de nossa infraestrutura de nuvem, resultando em erros de conexão e tempo de resposta \(timeouts\) para diversos serviços dependentes. ‌ ## Impacto O impacto durou aproximadamente **6 minutos**. Durante este intervalo, foram identificados 664 erros de timeout afetando operações críticas de identificação e validação. ‌ * **Serviços Afetados:** APIs de sincronização e motores de processamento biométrico. * **Clientes Impactados:** O incidente afetou múltiplos parceiros de grande porte em diversos setores. * **Métricas:** A conformidade do SLO de disponibilidade caiu para **99,19%**, consumindo integralmente o orçamento de erro do período. ## Causa Raiz A falha foi originada por um evento de **preempção de instâncias \(Spot VMs\)** no cluster de produção do Google Kubernetes Engine \(GKE\). ‌ 1. O número de nós do cluster caiu abruptamente de 107 para 89 na zona afetada. 2. Devido à migração recente para um novo cluster, uma configuração crítica de ciclo de vida do Pod \(**preStop hook**\) não foi replicada. 3. Sem essa configuração, os serviços foram finalizados de forma abrupta antes que o tráfego pudesse ser drenado adequadamente, causando falhas nas requisições em andamento e erros de redefinição de conexão \(upstream reset\). Além disso, identificamos que o motor de processamento mascarava falhas internas ao retornar códigos de sucesso \(HTTP 200\) para erros que deveriam ser reportados como indisponibilidade \(HTTP 503\), dificultando a detecção imediata através de monitoramento padrão. ‌ ## Resolução O incidente foi detectado automaticamente por alertas de monitoramento às 15:27 BRT. A equipe de engenharia identificou rapidamente o padrão de preempção de máquinas, dado que eventos similares ocorreram recentemente. ‌ * A estabilização ocorreu de forma automática assim que a infraestrutura de nuvem recompôs a capacidade de nós necessária. * Para mitigar a recorrência, foram abertas solicitações de alteração para reinserir os _hooks_ de desligamento gracioso em todos os serviços críticos. ## Lições Aprendidas * **Validação de Migrações:** Processos de migração de infraestrutura devem incluir validações automatizadas para garantir que configurações de ciclo de vida e resiliência não sejam perdidas \(drift de configuração\). * **Observabilidade e Padronização:** É essencial que os serviços propaguem códigos de erro HTTP semanticamente corretos para garantir que a visibilidade do impacto seja precisa e imediata. * **Design para Instâncias Efêmeras:** O uso de instâncias de baixo custo \(Spot\) exige um design de aplicação deliberado para desligamento gracioso, incluindo o uso adequado de `preStop hooks` e períodos de carência de terminação. * **Cobertura de Alertas:** Identificamos a necessidade de revisar os limites de alerta em serviços secundários para garantir que degradações de latência também acionem respostas rápidas ‌ 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.‌ Atenciosamente, Equipe Unico.