Lentidão no cadastro de produto do Hiper Gestão

Update timeline

1. identified Aug 13, 2026, 01:05 PM UTC

   Descrição do caso: identificamos um aumento de consumo das instâncias do banco de dados de leitura do cadastro de produto que está ocasionando lentidão em operações relacionadas ao cadastro de produto, como: pesquisa de produtos, listagem de produtos, pesquisa de produtos no faturamento do Hiper Gestão e sincronização. O problema foi identificado às 09h33, nossos times estão atuando para normalizar o problema.

2. identified Aug 13, 2026, 01:37 PM UTC

   Atualização do caso: identificamos a causa do problema e estamos implementando um ajuste nos índices do banco de dados para normalizar a performance do ambiente.

3. identified Aug 13, 2026, 02:32 PM UTC

   Atualização do caso: identificamos a causa do incidente como sendo um problema na escolha do plano de execução do banco de dados, após a criação do novo índice, o tempo para escolha do plano de execução aumentou drasticamente, ocasionando lentidão na execução de algumas consultas. O índice problemático já foi desativado, estamos atuando para limpar o cache das coleções do banco de dados e restabelecer a performance do ambiente.

4. identified Aug 13, 2026, 03:01 PM UTC

   Atualização do caso: até o momento, duas instâncias já limparam o cache e os indicadores de CPU e tempo de resposta normalizaram. As demais instâncias do banco de dados estão em processo de limpeza de cache. Em paralelo, estamos realizando um upgrade de capacidade do cluster para garantir que as estatísticas sejam compiladas adequadamente, melhorando a performance das consultas. Neste momento, o acesso ao cadastro de produto do Hiper Gestão está normalizado. Nossos times seguem acompanhando o ambiente para garantir que nenhum impacto adicional seja evidenciado.

5. resolved Aug 14, 2026, 09:51 AM UTC

   Atualização do caso: após o monitoramento ostensivo do ambiente durante a tarde de hoje, não identificamos mais nenhum impacto proveniente do incidente evidenciado durante o período da manhã, dessa forma, consideramos estamos encerrando a tratativa deste incidente. Nos próximos dias, o artigo de revisão do incidente será publicado aqui na página de status com o detalhamento do ocorrido.

6. postmortem Sep 18, 2026, 03:03 PM UTC

   Esta publicação tem por objetivo detalhar os eventos que envolveram o incidente do dia 13/08/2026 afetando a performance e operações de leitura no cadastro de produto do Hiper Gestão. No decorrer do relatório serão apresentadas informações gerais do incidente, causas, ações de remediação e próximos passos. ‌ **Código:** 2026081301 **Data:** 13/08/2026, quinta-feira **Horário de início:** 09h33 \(horário de Brasília\) **Horário de resolução:** 11h50 \(horário de Brasília\) **Tempo total de impacto:** 02 horas e 17 minutos **Impacto:** degradação de performance em operações de leitura no cadastro de produto do Hiper Gestão e na sincronização de produtos para o Hiper Caixa, Hiper Loja e Hiper Vendas. ‌ **Detalhamento do incidente** Foi identificado um aumento no consumo de CPU do _cluster_ de hospedagem do banco de dados do cadastro de produto do Hiper Gestão. O _cluster_ de banco de dados é composto por servidores de escrita e servidores de leitura. Durante o incidente foi identificado que os servidores de leitura apresentaram alto consumo de CPU. Durante o incidente, os sintomas do alto consumo de CPU apontavam para consultas que utilizam expressões regulares, utilizadas principalmente na pesquisa pelo nome de produtos no Hiper Gestão. Não ficou claro naquele momento o motivo de o consumo subir abruptamente, levando em consideração que estas consultas não sofreram alteração recente. Após diversas análises, a causa raiz identificada é decorrente da soma de ao menos dois fatores, sendo eles: * Grande quantidade de índices nas coleções consultadas \(~34 índices\), onerando a escolha do plano de execução pelo _multi-planner;_ * Utilização de expressão regular para pesquisa de texto parcial em qualquer lugar da _string._ Na noite anterior ao incidente foi realizada a criação de um índice na coleção envolvida no incidente, corroborando para que a causa esteja associada à degradação da performance do _multi-planner_, associada à consultas não performáticas que utilizam expressão regular. Para conter o incidente, a ação efetiva foi a realização de um _upgrade_ de capacidade do _cluster_. O _cluster_ utilizado permite que o _upgrade_ seja realizado sem _downtime_, mitigando totalmente o impacto após o _upgrade_ ser concluído. As ações para resolução do incidente não eram possíveis de serem aplicadas durante o incidente, pois exigiam a redução da quantidade de índices das coleções afetadas, bem como uma refatoração nas consultas que utilizam expressão regular, ações estas que não são possíveis de serem tomadas no decorrer do incidente. Como próximos passos, nossos times irão realizar uma análise dos índices utilizados, permitindo a redução da quantidade total de índices das coleções, resultando na redução do tempo para escolha do plano de execução das consultas. Além disso, será feita uma análise para refatoração das consultas que utilizam expressão regular para utilizarem o mecanismo de consulta Atlas Search. Somente após a aplicação destas ações é que será avaliado um possível _downgrade_ de capacidade do _cluster_ para o tamanho normal.