Instabilidade no Serviço de Alerta de comportamento ID Trust

Update timeline

1. identified Mar 27, 2026, 04:37 AM 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. Em breve retornaremos com a atualização final. Equipe Unico.

2. monitoring Mar 27, 2026, 04:40 AM 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

3. resolved Mar 27, 2026, 04:47 AM 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 a janela do incidente, nossa plataforma registrou um aumento atípico na latência e na taxa de erros de servidor (5xx) relacionados à funcionalidade de criação de processos. O impacto foi pontual e concentrou-se quase exclusivamente no ambiente de um cliente específico, que enfrentou falhas temporárias no serviço. Nossos sistemas de monitoramento confirmaram que os demais usuários da plataforma não sofreram degradação significativa de performance ou interrupções. Causa Raiz e Resolução: A instabilidade foi causada por falhas de comunicação e esgotamento de tempo limite (timeouts) nas requisições direcionadas a um serviço de integração de terceiros. A situação foi totalmente normalizada por volta das 00h18, momento em que a comunicação foi restabelecida e a taxa de erros caiu a zero. Todos os alertas de latência já foram encerrados e a operação segue estável desde a recuperação.

4. postmortem Apr 14, 2026, 03:00 PM UTC

   **PostMortem: Instabilidade no Serviço de Alerta de comportamento ID Trust** ## Sumário No dia **27 de março de 2026**, o serviço de Avaliação de Risco apresentou uma degradação significativa de performance, resultando em tempos de resposta elevados e falhas pontuais. O incidente foi desencadeado por um aumento repentino e massivo de tráfego proveniente de um único cliente, o que sobrecarregou nossos provedores de serviços externos \(APIs de terceiros\) localizados no México. ## Impacto O incidente teve início aproximadamente às **01:30 BRT**. Durante o período de pico, observamos os seguintes efeitos: * **Latência:** O tempo de resposta \(p99\) do processo de avaliação saltou de valores próximos de zero para um intervalo entre **8 e 9 segundos**. * **Conformidade de SLO:** A disponibilidade do serviço caiu para cerca de **97%**, ficando abaixo da meta estabelecida de 98,5%. * **Erros de Terceiros:** Nossos provedores externos começaram a retornar erros de _timeout_ \(HTTP 504\) e cancelamento de contexto devido à incapacidade de processar o volume de requisições recebido. ## Causa Raiz A causa principal foi a **saturação de recursos de terceiros** devido à falta de mecanismos de controle de tráfego por cliente no nível da nossa API Gateway. Um cliente específico iniciou um lote de requisições legítimas com um volume agressivo, atingindo cerca de **7-8 RPS** \(Requisições por Segundo\), o que representa mais de dez vezes o volume do segundo maior cliente e supera em quatro vezes o pico histórico de tráfego da região afetada. Além disso, a configuração de retentativas \(_retries_\) do sistema amplificou a carga sobre os provedores externos, agravando o cenário de saturação. ## Resolução O incidente foi mitigado através de duas frentes: 1. **Limitação de Taxa \(Rate Limiting\):** A engenharia aplicou uma regra de controle de tráfego específica para o cliente em questão, limitando o volume a 300 RPM \(Requisições por Minuto\). 2. **Segurança de Borda:** Coincidentemente, regras automatizadas de segurança da camada de rede identificaram o padrão de tráfego como anômalo e bloquearam as requisições excedentes \(HTTP 403\). Com essas medidas, o tráfego foi normalizado e a latência do sistema retornou aos níveis operacionais esperados ## Lições Aprendidas * **Proatividade no Controle de Tráfego:** A ausência de limites de taxa pré-configurados por cliente permitiu que um único usuário impactasse a infraestrutura compartilhada e outros clientes. * **Visibilidade de Erros:** Identificamos que certos erros de provedores externos estavam sendo suprimidos internamente, o que mascarou inicialmente a gravidade da falha nas métricas de aderência. * **Amplificação de Carga:** O uso de políticas de retentativa agressivas \(4 tentativas\) pode ser prejudicial durante incidentes de saturação; reduzir esse número ajuda a aliviar a carga em sistemas degradados. * **Ajuste de Políticas de Segurança:** Embora o bloqueio automático por segurança tenha ajudado na mitigação, ele não foi uma ação deliberada de infraestrutura, ressaltando a necessidade de revisar regras para evitar que tráfego legítimo de alta densidade seja confundido com ataques. 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.