Instabilidade parcial no serviço de integração By Unico e ByClient

Update timeline

1. identified May 19, 2026, 02:39 PM UTC

   Prezado Cliente, Detectamos um impacto nos retornos das requisições no fluxo do ByUnico e ByClient, gerando instabilidade aos clientes em uma parcela mínima de requisições Foram cerca de 814 erros durante o período de 11:10am até 11:16am, o ambiente já está normalizado nesse momento, estamos iniciando um monitoramento para garantir a saúde do sistema. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

2. monitoring May 19, 2026, 02:40 PM 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!

3. resolved May 19, 2026, 03:00 PM UTC

   Prezado Cliente, Incidente resolvido. 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. postmortem Jul 07, 2026, 02:27 PM UTC

   **Resumo** Em 19 de maio de 2026, entre 11h10 e 18h02 \(horário de Brasília\), o serviço de orquestração de liveness apresentou taxas de erro acima de 2%, gerando 814 erros em uma janela de 4 minutos. A causa foi um incidente de infraestrutura da nuvem que gerou latência extrema, impactando os nós que executavam as cargas de trabalho do serviço. A latência fez com que as sondas de saúde dos contêineres falhassem e os pods entrassem em ciclo de reinicialização, amplificado por um defeito conhecido no sandbox de execução que impedia a recuperação automática dos pods afetados. **Impacto** Usuários que utilizavam o fluxo de validação biométrica via SDK tiveram requisições negadas com erros de timeout \(504\). A taxa de erro atingiu mais de 2% durante o período de pico. A degradação se estendeu por um período mais longo do que o necessário devido ao defeito no mecanismo de recuperação dos contêineres, que manteve pods permanentemente impactados mesmo após a estabilização parcial da infraestrutura. **Causa Raiz** A causa raiz foi uma dependência externa: o provedor de infraestrutura de nuvem registrou um incidente ativo de latência em disco na zona us-east1-b, elevando a pressão de I/O nos nós afetados em aproximadamente 30 vezes acima do nível normal. Isso fez com que as respostas dos pods ultrapassassem o limite de timeout do proxy de serviço \(~8 segundos\), levando o orquestrador de contêineres a matar e reiniciar os pods. Um defeito conhecido no sandbox de execução impediu que alguns pods se recuperassem corretamente após os reinícios, transformando uma interrupção transitória em uma degradação prolongada. A equipe não possuía monitoramento de pressão de I/O nos nós de produção, nem integração entre os alertas de saúde da infraestrutura do provedor e os canais internos, o que atrasou significativamente a identificação da causa raiz. **Resolução** A equipe isolou o problema na zona us-east1-b por meio de análise comparativa entre clusters e zonas. A mitigação foi realizada drenando o pool de nós afetado e migrando as cargas de trabalho para um pool saudável. Após a migração, a latência voltou ao nível normal imediatamente, sem novas falhas nos 35 minutos seguintes. **Lições Aprendidas** * A ausência de monitoramento de pressão de I/O nos nós de produção tornou a degradação de infraestrutura completamente invisível até que ela se manifestasse como falhas na camada de aplicação. Implementar alertas de I/O com limiares adequados é a melhoria mais crítica identificada neste incidente. * Não havia integração entre os alertas de saúde de infraestrutura do provedor de nuvem e os canais internos de monitoramento. O incidente de I/O estava ativo há horas antes de ser descoberto manualmente pela equipe. * O defeito no sandbox de execução amplificou o impacto ao impedir a recuperação automática de pods afetados, transformando uma falha transitória em uma degradação sustentada. Esse risco permanece aberto até que o defeito seja corrigido na versão em uso. * A metodologia de investigação por eliminação comparativa — comparando comportamento entre clusters, pools de nós e zonas — foi altamente eficaz para isolar o problema e deve ser documentada como padrão de investigação para incidentes de infraestrutura.