Instabilidade no Serviço de Alerta de comportamento ID Trust

Update timeline

1. investigating Mar 19, 2026, 06:48 PM UTC

   Prezado Cliente, Identificamos uma instabilidade nas requisições do produto Alerta de Comportamento (ID Trust), gerando aumento no tempo de resposta ou erros nas requisições. Nossa equipe técnica está trabalhando para identificar as causas e solucionar brevemente. Em breve retornamos com atualizações.

2. identified Mar 19, 2026, 07:12 PM UTC

   Prezado Cliente, Identificamos a causa da instabilidade nas requisições do produto Alerta de Comportamento (ID Trust), gerando aumento no tempo de resposta ou erros nas requisições. Nossa equipe técnica está trabalhando para resolver o problema e normalizar o ambiente. Em breve traremos novas atualizações.

3. identified Mar 19, 2026, 08:11 PM UTC

   Prezado Cliente, Nosso time segue trabalhando para corrigir a instabilidade nas requisições do produto Alerta de Comportamento (ID Trust), gerando aumento no tempo de resposta e erros nas requisições. Em breve traremos novas atualizações. Pedimos desculpas pelo transtorno.

4. monitoring Mar 19, 2026, 08:36 PM UTC

   Prezado Cliente, Informamos que nossa equipe técnica executou as ações corretivas necessárias e o ambiente do produto Alerta de Comportamento (ID Trust) já apresenta estabilidade. Durante a nossa atuação, identificamos e removemos de forma definitiva a infraestrutura específica que estava operando com degradação e causando o aumento no tempo de resposta das 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. Nossa equipe permanece dedicada e atenta a qualquer oscilação antes de declararmos o incidente como totalmente encerrado. Em breve retornaremos com a atualização final. Equipe Unico.

5. resolved Mar 19, 2026, 09:19 PM UTC

   Prezado Cliente, Informamos que o período de monitoramento assistido foi concluído com sucesso e o incidente no produto Alerta de Comportamento (ID Trust) encontra-se oficialmente Resolvido. A performance do sistema está totalmente estabilizada e operando dentro dos nossos padrões de excelência. Resumo Executivo e Impacto Durante o período de instabilidade, observamos uma degradação na disponibilidade, resultando em aumento no tempo de resposta (latência) e erros de timeout nas requisições do produto Alerta de Comportamento. Gostaríamos de reforçar que a integridade do sistema foi mantida e não houve nenhuma perda de dados ou impacto na segurança das informações durante este evento. Causa Raiz e Resolução A instabilidade originou-se de um gargalo de alocação de recursos em nossa infraestrutura em nuvem. Componentes críticos do serviço foram alocados em um nó de processamento que atingiu 100% de sua capacidade. Isso ocorreu porque essa mesma infraestrutura estava processando, simultaneamente, novas cargas de trabalho internas de alta exigência computacional, sem as regras adequadas de isolamento. Adicionalmente, uma limitação temporária de recursos no provedor de nuvem impediu o escalonamento automático imediato dos nossos servidores. Conforme adiantado em nossa atualização anterior, a equipe técnica mitigou o problema realizando o aumento manual da capacidade de instâncias do serviço e removendo definitivamente o nó de processamento sobrecarregado. Com o tráfego totalmente redirecionado para servidores saudáveis, a latência retornou à normalidade. Compromisso e Próximos Passos A confiabilidade dos nossos serviços é nossa prioridade máxima. Como medida preventiva imediata, nossa equipe de engenharia já está implementando regras mais rígidas de isolamento de carga de trabalho na infraestrutura, garantindo que processos de alto consumo operem em ambientes totalmente separados dos serviços críticos voltados aos clientes. 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

6. postmortem Mar 30, 2026, 05:35 PM UTC

   # Postmortem: Instabilidade no Serviço de Alerta de comportamento ID Trust ## Resumo No dia 19 de março de 2026, o serviço de **Avaliação de Risco** apresentou uma degradação significativa na disponibilidade e um aumento acentuado na latência. O problema foi originado por uma falha de isolamento de recursos em nosso cluster Kubernetes \(GKE\), onde uma carga de trabalho crítica foi afetada pelo consumo excessivo de CPU de um processo secundário no mesmo nó. A recuperação total foi alcançada após a identificação do nó sobrecarregado e o ajuste na escala do serviço. ‌ ## Impacto * **Disponibilidade:** O índice de disponibilidade do fluxo de Avaliação de Risco caiu abaixo do limite de **98,5%** estabelecido pelo SLO \(Service Level Objective\). * **Latência:** Usuários finais enfrentaram atrasos severos e erros de _timeout_ devido ao aumento no tempo de resposta das inferências de modelos. * **Serviços Afetados:** O serviço de identidade que consome este fluxo foi diretamente impactado pela lentidão. ## Causa Raiz A investigação técnica identificou que o incidente foi causado pela combinação de três fatores principais: 1. **Contenção de Recursos:** Um pod crítico do servidor de modelos foi escalonado em um nó de alta capacidade \(80 vCPUs\) que já estava operando com **100% de uso de CPU** devido a um processo de processamento de dados intensivo e recém-implantado. 2. **Falta de Isolamento:** O cluster não possuía regras de afinidade ou restrições \(_taints/tolerations_\) configuradas para impedir que cargas de trabalho de processamento em lote \(batch\) fossem executadas no mesmo hardware que serviços de baixa latência em tempo real. 3. **Indisponibilidade de Recursos na Nuvem:** Durante a tentativa de remediação, uma escassez temporária de recursos na zona de disponibilidade do provedor de nuvem impediu que o autoescalador provisionasse novos nós rapidamente para diluir a carga. ## Resolução O incidente foi resolvido através das seguintes etapas: * **Esconamento de Emergência:** O número mínimo de réplicas do servidor de modelos foi aumentado de **241 para 300** para garantir que a carga fosse distribuída entre novos pods saudáveis. * **Remoção do Nó Problemático:** A equipe de infraestrutura identificou e removeu o nó sobrecarregado do cluster, forçando o reescalonamento dos serviços para instâncias com recursos disponíveis. * **Estabilização:** Após a remoção do nó e o aumento das réplicas, a latência retornou aos níveis normais e os erros de timeout cessaram. ## Lições Aprendidas * **Necessidade de Guardrails de Agendamento:** A ausência de políticas de isolamento para novas cargas de trabalho de alta CPU demonstrou ser um risco para serviços críticos compartilhados no mesmo cluster. * **Detecção de Outliers:** Embora os alertas de SLO tenham funcionado, a identificação de um único "pod lento" em meio a centenas levou tempo. É necessário melhorar a observabilidade para destacar anomalias individuais de forma automática. * **Gestão de Nós Grandes:** Máquinas com muitas CPUs podem apresentar comportamentos de performance distintos \(como efeitos de memória NUMA\) que afetam inferências de ML, exigindo configurações específicas de pinning de CPU e memória. ‌ 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.