Instabilidade no Serviço de Integração By Unico e ByClient

Update timeline

1. investigating May 19, 2026, 03:09 AM UTC

   Prezado Cliente, Identificamos um comportamento irregular nas capacidades de retorno do ByUnico e ByClient. Embora a causa exata ainda esteja sob investigação, isso pode se manifestar como lentidão ou intermitência no serviço em uma parcela mínima de requisições. A equipe de tecnologia está executando todos os procedimentos de diagnóstico no ambiente para identificar as causas. Em breve retornamos com atualizações. Atenciosamente,

2. identified May 19, 2026, 03:14 AM UTC

   Prezado Cliente, Detectamos o motivo do impacto nos retornos das requisições no fluxo do ByUnico e ByClient, podendo causar instabilidade aos clientes. A equipe de tecnologia está ativamente analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

3. monitoring May 19, 2026, 03:26 AM UTC

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. resolved May 19, 2026, 11:36 AM UTC

   Prezado Cliente, Confirmamos que o comportamento inesperado nos fluxos do ByUnico e ByClient foi totalmente resolvido e todos os serviços estão operando normalmente, com total estabilidade. Nossa equipe seguiu monitorando o ambiente após as correções e valida que o fluxo de requisições está regularizado. Conforme mencionado, compartilharemos nos próximos dias um Postmortem com o detalhamento do ocorrido. Agradecemos a paciência, pedimos desculpas pelo transtorno e seguimos à disposição através dos nossos canais de atendimento para qualquer dúvida. Atenciosamente, Equipe Unico

5. postmortem Jun 29, 2026, 01:35 PM UTC

   **Resumo** Em 18 de maio de 2026, entre 09h55 e 10h23 \(horário de Brasília\), a taxa de sucesso de conclusão de jornadas caiu abruptamente para todos os usuários. O impacto durou aproximadamente 28 minutos e afetou todos os fluxos de autenticação e cadastro via web. A causa foi uma implantação que introduziu uma mudança defeituosa e foi aplicada a 100% do tráfego sem rollout gradual. O rollback foi aplicado às 10h23 e o serviço voltou ao normal logo em seguida. **Impacto** Todos os usuários que utilizavam o fluxo de autenticação via web foram impactados. As jornadas ficaram travadas especialmente na etapa de validação facial — os usuários conseguiam iniciar o processo, mas não avançavam para a etapa de biometria. O volume de criação de processos manteve-se elevado enquanto o volume de conclusões caiu significativamente, com o throughput caindo de ~16-19 mil para ~6-8 mil requisições. O impacto foi generalizado para todos os clientes ativos em múltiplos fluxos. **Causa Raiz** A causa raiz foi um erro operacional: uma implantação realizada na manhã do incidente introduziu uma configuração defeituosa que corrompeu o comportamento do fluxo de validação facial. A implantação foi aplicada a 100% do tráfego de forma simultânea, sem estratégia de rollout gradual — o processo de implantação do SDK web não suporta releases em canário. Mudanças em arquivos de configuração também não estavam disparando processos automáticos de rollout/rollback como esperado pela equipe, pois esse comportamento só é acionado por chamadas específicas do frontend ao backend. Por fim, o indicador de qualidade do serviço para detecção dessa anomalia estava configurado com um limite de tolerância muito permissivo \(75% em 1 hora\), o que atrasou o alerta em aproximadamente 14 minutos após o início do impacto. **Resolução** A equipe identificou a implantação causadora por meio dos alertas de anomalia no indicador de qualidade do serviço. O rollback foi aplicado e o sistema começou a se recuperar imediatamente. Às 10h23, o fluxo retornou à normalidade e o incidente foi encerrado após confirmação de estabilidade. Os limites do indicador foram ajustados para 95% em 15 minutos após o incidente. **Lições Aprendidas** * A ausência de rollout gradual para o componente de SDK web fez com que 100% dos usuários fossem impactados imediatamente por uma mudança defeituosa. A implementação de estratégias de rollout gradual para esse componente é a melhoria de maior prioridade identificada. * Os limites de tolerância a falhas para o indicador de qualidade do serviço estavam configurados de forma muito permissiva \(75% em 1 hora\), resultando em um atraso de ~14 minutos na detecção. Os limites foram ajustados para valores mais restritivos \(95% em 15 minutos\). * Mudanças em arquivos de configuração não estavam disparando processos automáticos de rollout/rollback, contrariando a expectativa da equipe. Isso aumentou o tempo de resposta durante o incidente e representa um risco para situações futuras semelhantes. * A ausência de alertas orientados a jornadas do usuário no lado do cliente \(frontend\) fez com que a detecção dependesse exclusivamente de métricas de backend, que introduzem um atraso mínimo de 3 minutos por design. Alertas de jornadas críticas no frontend são uma lacuna urgente a ser endereçada.