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

Update timeline

1. resolved Mar 20, 2026, 03:12 PM UTC

   Prezado Cliente, Informamos que, a partir das 10:49 até 11:20, identificamos uma instabilidade que afetou os fluxos e funcionalidades que dependem da capacidade IDsign. Aplicamos as medidas corretivas necessárias e o serviço já apresenta comportamento estável. Permaneceremos em monitoramento pelos próximos períodos para assegurar que a performance se mantenha nos níveis ideais. Lamentamos o transtorno causado e seguimos à disposição através de nossos canais de atendimento para qualquer suporte adicional. Equipe Unico.

2. postmortem Apr 06, 2026, 08:59 PM UTC

   **PostMortem: Instabilidade no Serviço de Assinatura Digital \(ID Sign\)** ### Resumo Em 20 de março de 2026, observamos uma degradação na disponibilidade do nosso fluxo de criação de processos. Durante um período de aproximadamente 31 minutos, falhas inesperadas impediram a criação de processos que possuíam envelopes de assinatura. ### Impacto O incidente ocorreu entre 10:49 e 11:20 \(Horário de Brasília\). Durante essa janela de tempo, múltiplos clientes foram afetados pelas falhas. Como consequência, a taxa de disponibilidade do serviço de criação de processos caiu para abaixo do limite da nossa meta de nível de serviço \(SLO\). ### Causa Raiz O problema foi desencadeado pelo envio repentino de cargas de dados contendo documentos vazios \(com tamanho de 0 bytes\) entre os serviços internos. O serviço responsável por criar os envelopes de assinatura não possuía uma validação adequada para exigir um tamanho mínimo de documento. Como resultado, o sistema aceitava os arquivos vazios e tentava prosseguir com o processamento. Ao falhar na etapa de upload, o serviço retornava um erro genérico de servidor, em vez de rejeitar imediatamente a requisição inválida com uma mensagem clara de validação. A causa raiz exata que levou o serviço de origem a enviar esses arquivos vazios de forma repentina ainda está sob investigação, visto que o problema começou e parou de forma uniforme e sem que nenhuma alteração de código ou configuração tivesse sido feita. ### Resolução O incidente foi resolvido espontaneamente ao final da janela de impacto de 31 minutos. O envio de documentos com conteúdo válido foi normalizado, e o fluxo de serviços se recuperou sozinho, sem a necessidade de intervenções manuais, reversões \(rollbacks\) ou implantações por parte da nossa equipe. ### Ações Futuras * **Validação de Dados:** Implementar validações defensivas rigorosas para rejeitar arquivos vazios ou inválidos logo na entrada, retornando um erro claro indicando argumentos inválidos em vez de falhas genéricas de servidor. * **Investigação de Origem:** Continuar a investigação interna para entender o motivo pelo qual o serviço de origem gerou o envio temporário de dados vazios, prevenindo futuras recorrências. * **Melhoria na Comunicação:** Aprimorar o processo para garantir que as atualizações em nossa página de status sejam publicadas mais rapidamente durante incidentes que afetam múltiplos clientes. ### Lições Aprendidas * **O que funcionou bem:** Nossos sistemas de monitoramento baseados em métricas de SLO detectaram a degradação e alertaram a equipe rapidamente, antes mesmo de percepções manuais. Além disso, a equipe conseguiu investigar e correlacionar os erros com os tamanhos de arquivo quase imediatamente, isolando a falha em menos de uma hora. * **Oportunidades de melhoria:** A ausência de uma validação defensiva estrita entre as fronteiras dos nossos serviços permitiu que dados inválidos se propagassem de forma silenciosa e gerassem erros confusos. Também identificamos que a declaração formal do incidente ocorreu com atraso. Uma comunicação oficial mais rápida melhorará a coordenação e a transparência contínua com nossos clientes.