Instabilidade no Serviço de Assinatura Digital (Unico Sign)

Update timeline

1. identified Feb 24, 2026, 06:37 PM UTC

   Identificamos a causa da instabilidade na funcionalidade de Assinatura Digital da Unico (Unico SIGN) e nosso time de tecnologia está atuando para a resolução. Em breve traremos atualizações.

2. identified Feb 24, 2026, 06:47 PM UTC

   Prezado Cliente, Nossa equipe de engenharia está atuando no incidente do produto Unico Sign. Neste instante todos os clientes que consomem o serviço de assinatura da Unico, poderão ter seus processos afetados durante a criação. A equipe de tecnologia está tratando o incidente com prioridade máxima. Em breve retornamos com atualizações.

3. monitoring Feb 24, 2026, 07:02 PM UTC

   Aplicamos as medidas corretivas necessárias e o serviço de assinatura digital já apresenta comportamento estável. Permaneceremos em monitoramento rigoroso pelos próximos períodos para assegurar que a performance se mantenha nos níveis ideais.

4. resolved Feb 24, 2026, 07:27 PM UTC

   Resumo Executivo e Impacto Comunicamos que o incidente técnico que afetou as operações de assinatura de documentos no Unico Sign foi totalmente resolvido. O serviço já se encontra estabilizado e as operações foram normalizadas após o período de indisponibilidade reportado. Durante a fase de monitoramento assistido, confirmamos que o sistema recuperou sua performance integral. Ressaltamos que não houve qualquer perda de dados ou comprometimento da integridade dos documentos processados durante este evento. Causa Raiz e Resolução Nossa investigação técnica identificou que a instabilidade foi causada por um volume atípico de tentativas de reprocessamento, o que gerou uma sobrecarga na nossa camada de armazenamento de dados. Esse comportamento impediu que o sistema processasse novas assinaturas com a agilidade necessária. Para solucionar o cenário, nosso time de tecnologia executou as seguintes ações: Expansão de Recursos: Aumentamos em quatro vezes a capacidade de processamento do banco de dados para absorver a demanda acumulada. Otimização de Serviços: Reiniciamos os componentes críticos de assinatura e reajustamos a distribuição de carga do sistema para aliviar a pressão na infraestrutura, garantindo um fluxo estável e seguro. Controle de Vazão: Calibramos a comunicação entre os serviços para assegurar que a retomada das operações não gerasse novas oscilações. Compromisso e Próximos Passos A Unico prioriza a transparência e a confiabilidade de seus serviços. Por isso, nossas equipes já iniciaram a elaboração de um Postmortem detalhado, que será compartilhado nos próximos dias para fornecer uma visão técnica aprofundada e descrever as melhorias estruturais que adotaremos para evitar recorrências. Lamentamos o transtorno causado e seguimos à disposição através de nossos canais de atendimento para qualquer suporte adicional. Atenciosamente, Equipe Unico

5. postmortem Mar 06, 2026, 01:27 PM UTC

   ## 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.