Instabilidade no Serviço de Captura e Reaproveitamento de Documentos (ID DOCS)

Update timeline

1. resolved Mar 02, 2026, 01:48 PM UTC

   Resumo Executivo e Impacto Durante uma janela de atualização de rotina, identificou-se uma instabilidade que afetou o processamento de requisições para uma parcela dos usuários. Entre as 09:54 e 10:34, aproximadamente 391 chamadas falharam com erros internos (HTTP 500) devido a falhas de conectividade com o provedor de modelos de linguagem (Vertex). O incidente foi detectado rapidamente pela equipe de monitoramento, que iniciou os procedimentos de contingência para restaurar a disponibilidade total do sistema. Causa Raiz e Resolução A falha foi originada por uma inconsistência na configuração do ambiente durante o processo de rollout de uma nova versão. Uma variável de ambiente obrigatória para a versão legada foi removida do mapeamento de configurações prematuramente. Como alguns serviços sofreram reinicializações automáticas durante a atualização, eles carregaram as novas configurações incompletas enquanto ainda executavam o código anterior, resultando na perda de conexão com a API externa. A resolução consistiu na reversão imediata das configurações para o estado estável anterior e na reinicialização dos serviços afetados, garantindo que todos os nós operassem com os parâmetros de conectividade corretos. Atenciosamente, Equipe Unico

2. postmortem Mar 10, 2026, 06:39 PM UTC

   **Data do Incidente:** 02 de março de 2026 **Duração:** 40 minutos \(09:54 às 10:34\) **Status:** Resolvido **Resumo Executivo** No dia 02 de março de 2026, nossa plataforma apresentou instabilidade em serviços relacionados à funcionalidade de salvamento de documentos. O incidente resultou em indisponibilidade temporária do serviço por 40 minutos. A causa do problema foi identificada como uma falha de conexão com um serviço de inteligência artificial, originada por uma incompatibilidade nas configurações de ambiente durante o processo de liberação de uma nova versão do sistema. A equipe de engenharia atuou rapidamente para isolar e reverter a configuração afetada, normalizando a operação. **Impacto** Durante a janela de impacto, os usuários finais enfrentaram os seguintes problemas: * **Falhas de Requisição:** Foram registradas 391 chamadas que falharam ao tentar salvar documentos. * **Erros Apresentados:** Os usuários receberam mensagens de erro de servidor \(HTTP 500 - Internal Server Error\) nas requisições afetadas. **Causa Raiz** O incidente ocorreu devido a uma dessincronização entre as versões de código e os arquivos de configuração durante um procedimento de _deploy_ gradual \(canary\). 1. Durante a liberação da nova versão do serviço, uma variável de configuração crítica foi removida do sistema central de configurações, pois assumiu-se que o código mais recente não dependia mais dela. 2. No entanto, algumas instâncias da aplicação que ainda rodavam a versão antiga do código sofreram reinicializações automáticas devido a limites de uso de memória \(Out of Memory\). 3. Ao reiniciar, essas instâncias antigas carregaram a configuração recém-atualizada, que não continha mais a variável obrigatória para o seu funcionamento. 4. Sem essa configuração, o serviço falhou ao tentar estabelecer conexão com a infraestrutura de inteligência artificial, resultando em erros de DNS ao tentar localizar a região correta dos servidores. A ausência de um sistema automatizado para validar a compatibilidade entre o código em execução e o arquivo de configurações permitiu que a falha ocorresse no ambiente produtivo. **Resolução** Nossos sistemas de monitoramento e a mobilização rápida da equipe garantiram um diagnóstico ágil do problema. O processo de resolução seguiu as seguintes etapas: * **Mitigação Inicial:** A região de conectividade afetada foi temporariamente removida do balanceamento de carga para aliviar o volume de falhas. * **Correção:** Instância específica da aplicação que operava com a configuração incorreta foi identificada e reiniciada forçadamente para forçar o recarregamento com os parâmetros corretos. * **Reversão:** A equipe executou um roll\_back\_ na atualização da configuração, garantindo o retorno da estabilidade do serviço. A normalização completa foi confirmada às 10:34. **Ações Preventivas \(Action Items\)** Para garantir que esse cenário não se repita, as seguintes frentes de trabalho foram estabelecidas: * Implementar a validação sistemática de compatibilidade entre as versões de código e configurações diretamente nos pip\_elines\_ de integração e entrega contínua \(CI/CD\). **Lições Aprendidas** * **Validação de Configurações Críticas \(Fail Fast\):** Serviços críticos devem sempre checar a presença das variáveis de ambiente necessárias durante o processo de inicialização. Caso algum parâmetro esteja ausente, o serviço deve falhar imediatamente, evitando que instâncias degradadas entrem no balanceamento de tráfego. * **Sincronização em Deploys Graduais:** O processo de liberação gradual \( c\_anary\_ \) deve incluir não apenas a validação da saúde do código em si, mas também testar a compatibilidade das configurações vigentes com todas as versões do código que estarão ativas simultaneamente no ambiente. * **A importância da Observabilidade:** A existência de métricas granulares e logs detalhados foi fundamental para que a equipe de resposta a incidentes pudesse identificar, isolar e agir de forma cirúrgica na instância que estava apresentando o comportamento incorreto.