Unico Outage History

## Relatório Pós-Incidente: Instabilidade no Serviço de Assinatura de Documentos **Data:** 24 de fevereiro de 2026 **Status:** Resolvido ### Resumo No dia 24 de fevereiro de 2026, nosso serviço de assinatura de documentos apresentou instabilidade significativa devido a uma latência excessiva no método de execução de módulos. O problema foi desencadeado por um volume atípico de requisições que sobrecarregou a base de dados, resultando em falhas nas operações de assinatura baseadas em envelopes. ### Impacto Durante o período do incidente, todas as operações de assinatura de documentos que utilizavam fluxos de envelopes foram interrompidas. Isso causou uma interrupção total nos fluxos de trabalho de clientes que dependiam da conclusão de assinaturas digitais em tempo real. ### Causa Raiz A investigação técnica identificou um erro de software no componente de interface \(frontend\). Uma falha na implementação de um gancho de renderização \(`useEffect`\) fez com que uma função de busca de dados fosse tratada como uma nova dependência a cada ciclo de atualização. Como a função era declarada de forma embutida, sua referência mudava a cada renderização do componente pai, criando um **loop infinito de requisições**. Esse comportamento gerou um tráfego massivo para a API, resultando em consultas intensivas na tabela de acessos do banco de dados e levando à degradação total da performance do sistema. ### Resolução Para restabelecer o serviço, nossa equipe de engenharia adotou as seguintes medidas de mitigação: * **Escalonamento de Infraestrutura:** A capacidade do banco de dados foi aumentada temporariamente de 8 vCPU para 32 vCPU para absorver a carga e processar a fila de requisições pendentes. * **Reciclagem de Serviços:** Os pods responsáveis pelo núcleo de assinatura e pelo processamento de tarefas em segundo plano foram reiniciados para limpar conexões presas e reduzir a carga do sistema. * **Ajuste de Carga:** O número de réplicas do serviço de assinatura foi reduzido temporariamente para controlar a quantidade de conexões simultâneas ao banco de dados até que a estabilidade fosse alcançada. O serviço foi declarado estável e totalmente restabelecido após o monitoramento dos indicadores de performance. ### Lições Aprendidas * **Gestão de Dependências em UI:** Reforçamos a necessidade de utilizar padrões de memorização \(como `useCallback`\) para funções passadas como dependências em efeitos, evitando execuções redundantes ou loops. * **Mecanismos de Proteção \(Guards\):** Identificamos a oportunidade de implementar camadas de proteção no armazenamento de dados \(store\) para impedir chamadas concorrentes idênticas enquanto uma requisição ainda está em processamento. * **Observabilidade de Transações:** O incidente destacou a importância de enriquecer os logs de transação com identificadores mais granulares para acelerar o diagnóstico em cenários de requisições duplicadas.

## Relatório de Incidente: Instabilidade no Serviço de entrega de WebHook \(IDCloud\) ### Resumo Em 17 de fevereiro de 2026, nosso serviço de notificação de eventos \(Webhooks\) apresentou instabilidade e queda na taxa de sucesso, operando abaixo da meta estabelecida de **97,6%**. O incidente foi desencadeado por uma falha técnica no componente de captura de dados, que parou de processar eventos devido a uma instabilidade externa. Após o restabelecimento manual do serviço, o volume acumulado de mensagens causou uma sobrecarga temporária em nossa infraestrutura de entrega. ### Impacto * **Duração do Impacto Total:** Aproximadamente 1 hora e 7 minutos. * **Serviços Afetados:** Fluxo de criação de eventos via Webhook. * **Experiência do Cliente:** Alguns clientes enfrentaram atrasos no recebimento de notificações de finalização de jornada. Devido a esse atraso, houve um aumento nas tentativas manuais de reprocessamento e consultas de status \(GET\), o que resultou em erros temporários de limite de taxa \(_rate limiting_ - HTTP 429\). ### Causa Raiz O incidente foi originado por uma combinação de fatores técnicos e de infraestrutura: 1. **Instabilidade Externa:** Uma oscilação transiente na infraestrutura de mensageria em nuvem \(Pub/Sub\) causou falhas de conexão no worker de processamento. 2. **Falha na Recuperação Automática:** Devido à ausência de configurações específicas de tempo limite de encerramento \(_shutdown timeout_\) e de verificações de integridade, o serviço entrou em um estado de "travamento" silencioso. Ele parou de consumir dados, mas não reiniciou automaticamente para recuperar a conexão. 3. **Efeito Cascata:** Durante os 18 minutos em que o serviço ficou inativo, uma grande quantidade de eventos acumulou-se na fila. Ao ser reiniciado manualmente, o sistema tentou processar todo o backlog de uma só vez, gerando um pico de tráfego que saturou as conexões do banco de dados do serviço de webhook. ### Resolução A mitigação foi realizada por nossa equipe de engenharia de confiabilidade \(SRE\) através do **reinício manual dos serviços travados**. Após o restart, o sistema passou por um período de instabilidade enquanto drenava o backlog acumulado, estabilizando-se completamente às 15h55 BRT. O monitoramento subsequente confirmou que a taxa de sucesso retornou aos níveis normais de SLO e o volume de requisições dos clientes foi normalizado. ### Lições Aprendidas * **Resiliência a Falhas Externas:** Identificamos que o componente de captura de dados precisa de configurações de _timeout_ mais agressivas para garantir que o processo finalize e reinicie em caso de latência de rede externa. * **Necessidade de Throttling:** A ausência de um mecanismo de controle de vazão \(_throttling_\) na drenagem de backlogs torna o sistema vulnerável a surtos de tráfego após períodos de inatividade. * **Automação do MTTR:** Depender de intervenção manual e escalonamento de permissões aumenta o tempo médio de recuperação \(MTTR\). A implementação de verificações de saúde automatizadas é essencial para a autorrecuperação.

# Postmortem: Instabilidade nos fluxos de Prova de Vida \(Liveness\) ### Resumo No dia 10 de fevereiro de 2026, identificamos uma instabilidade em nossa camada de orquestração de liveness \(biometria facial\), que resultou em erros intermitentes \(HTTP 500\) para diversas funcionalidades. O incidente foi provocado por falhas de comunicação interna entre microsserviços após um evento de rebalanceamento de infraestrutura. A situação foi normalizada após a reinicialização estratégica de instâncias do serviço afetado. ‌ ### Impacto O incidente teve início às **12:07 BRT** e foi totalmente mitigado às **16:37 BRT**. Durante esse período, usuários podem ter enfrentado lentidão ou falhas ao tentar realizar fluxos de captura de dados e validação biométrica. O erro manifestava-se como um _timeout_ de 10 segundos quando o sistema tentava se comunicar com capacidades internas específicas. ‌ ### Causa Raiz A investigação técnica revelou uma falha na propagação de atualizações de rede dentro do nosso cluster de serviços \(Istio/ASM\). ‌ 1. **Evento de Infraestrutura:** Cerca de 15 nós de processamento foram removidos simultaneamente durante um processo de redimensionamento automático \(_scale-down_\) na nuvem. 2. **Sobrecarga do Plano de Controle:** A remoção abrupta de mais de 46 pods gerou uma carga de eventos de rede três vezes maior que o normal, sobrecarregando o sistema de controle de tráfego. 3. **Endpoints Obsoletos:** Devido a essa sobrecarga, alguns serviços tentaram enviar tráfego para endereços de IP de instâncias que já haviam sido encerradas, resultando em falhas de conexão e _timeouts_. 4. **Ausência de Limites de Evicção:** A inexistência de configurações de orçamento de interrupção \(_PodDisruption Budget_\) permitiu que muitos componentes críticos fossem removidos ao mesmo tempo, impedindo uma transição gradual da rede. ### Resolução A equipe de engenharia identificou três instâncias do orquestrador que mantinham registros de rede inconsistentes. Às **16:00 BRT**, foi realizado o _restart_ dessas instâncias, o que forçou a atualização das tabelas de roteamento e cessou imediatamente os erros 5xx. O sistema retornou à estabilidade total logo em seguida. ‌ ### Lições Aprendidas * **Gerenciamento de Escala:** Identificamos a necessidade de implementar mecanismos de remoção gradual de instâncias para evitar picos de carga no plano de controle de rede. * **Resiliência de Configuração:** A importância de utilizar políticas de interrupção de pods para garantir que serviços críticos nunca fiquem abaixo de um limiar mínimo de disponibilidade durante manutenções automáticas. * **Observabilidade:** Reforçamos a necessidade de alertas específicos sobre a taxa de eventos de processamento interno para detectar sobrecargas antes que elas impactem o usuário final. 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.

**Data do Incidente:** 10 de fevereiro de 2026 **Duração do Impacto:** 06:30 às 11:31 \(Horário de Brasília\) **Status:** Resolvido ### Resumo Executivo Em 10 de fevereiro de 2026, nossa plataforma de pagamentos enfrentou uma falha que impediu a inicialização do fluxo de captura de biometria facial. O incidente foi desencadeado por uma nova validação de segurança introduzida na atualização recente do nosso Web SDK de biometria. A equipe de engenharia isolou a falha e normalizou o serviço após reverter \(aplicar _rollback_\) a versão do componente na infraestrutura. ### Impacto Durante o período de degradação, os clientes finais não conseguiram concluir os processos que exigiam a captura facial. A falha na renderização gerou uma tela em branco no carregamento da câmera, sem o devido mapeamento de erros visíveis, o que prejudicou a geração de alertas automatizados no monitoramento padrão. O impacto iniciou às 06:30, mas, pela ausência de alarmes de sistema, o problema só foi confirmado às 10:12 a partir do aumento de contatos dos clientes aos canais de suporte. A estabilização completa ocorreu às 11:31. ### Causa Raiz A instabilidade foi causada por uma incompatibilidade técnica entre uma biblioteca de terceiros e a nova camada de validação do Web SDK de captura. * A versão atualizada do Web SDK introduziu uma checagem de integridade que avalia se operações nativas do JavaScript foram modificadas por outras bibliotecas. * A plataforma de pagamentos utiliza uma biblioteca que realiza uma modificação em uma função estrutural nativa da web. * Ao detectar essa modificação de terceiros, o SDK lançou imediatamente um erro de segurança e bloqueou o carregamento da câmera. A incompatibilidade não foi percebida durante os testes pré-implantação \(ambiente de homologação\) devido a uma regra temporária que dividia o tráfego do ambiente em 50% entre dois provedores de biometria diferentes. As capturas com sucesso foram roteadas para o provedor secundário, mascarando o erro na nova versão do componente principal sob teste. ### Resolução Ao confirmar a falha na atualização, a equipe de engenharia iniciou imediatamente a reversão \(_rollback_\) do Web SDK de biometria para a sua versão anterior estável. O tempo de resolução, no entanto, foi prolongado devido a uma inconsistência na execução do _rollback_ em nossos ambientes distribuídos geograficamente. A reversão falhou na propagação inicial para uma das regiões de infraestrutura em nuvem, mantendo erros isolados por cerca de 40 minutos adicionais. Ao identificar o tráfego de falhas residual nessa região, a equipe forçou a atualização do ambiente de forma isolada, mitigando completamente o problema. ### Ações Preventivas Para fortalecer a governança técnica da nossa plataforma e evitar cenários semelhantes, os seguintes passos foram incorporados ao planejamento de engenharia: * **Cobertura de Reversões:** Aprimorar o processo automatizado de reversões \(_rollbacks_\) para garantir de forma explícita que atualizações de contingência sejam simultaneamente aplicadas e validadas em todas as regiões globais. * **Paridade de Ambientes:** Ajustar as políticas de balanceamento do ambiente de testes para que componentes críticos em fase de avaliação recebam 100% da carga de tráfego esperada, desativando regras de divisão estatística que possam mascarar falhas. * **Mapeamento de Exceções:** Refatorar o mecanismo de tratamento de exceções do Web SDK, assegurando que quaisquer colisões ou falhas graves de componentes gerem retornos \(callbacks\) mensuráveis de erro ao invés de encerramentos silenciosos \(como telas em branco\). ### Lições Aprendidas * **Rigor em Ambientes de Homologação:** Processos de roteamento dividido \(como Testes A/B\) implementados diretamente na camada de rede da homologação podem invalidar a precisão dos testes de regressão. É imperativo que os testes reflitam com fidelidade o uso real. * **Complexidade Multi-Região:** Intervenções manuais ou parciais em infraestruturas baseadas em múltiplas regiões na nuvem são inerentemente propensas a falhas humanas. Mitigações críticas exigem ferramentas de orquestração atômica \(aplicando a todos ou nenhum\). * **Importância Crítica da Observabilidade:** Sistemas voltados para interação de usuários precisam falhar de forma explícita e mapeável. Falhas silenciosas prolongam significativamente a detecção de incidentes, transferindo a notificação do problema para os canais de atendimento ao cliente, ao invés do monitoramento pró-ativo de sistemas.