Instabilidade no Serviço de Integração By Unico

Update timeline

1. identified Mar 27, 2026, 02:46 AM UTC

   Prezado Cliente, Detectamos um impacto nos retornos do ByUnico, podendo causar instabilidade aos clientes. A equipe de tecnologia está ativamente analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

2. monitoring Mar 27, 2026, 02:47 AM UTC

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

3. resolved Mar 27, 2026, 03:13 AM UTC

   Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. postmortem Apr 27, 2026, 02:45 PM UTC

   **Postmortem: Instabilidade no Serviço de Integração By Unico** ‌ **Resumo** No dia 26 de março de 2026, um de nossos serviços de processamento de documentos sofreu uma degradação temporária. A disponibilidade global da operação afetada caiu para 93,89%, ficando abaixo da nossa meta estabelecida de 97%. ‌ **Impacto** Durante o pico do incidente, a operação apresentou uma taxa de erro de 15,6%. Aproximadamente 2.000 requisições de clientes falharam ao longo de uma janela concentrada de quatro minutos, especificamente entre 23:03 e 23:07 \(horário de Brasília\). Serviços dependentes relataram erros de instabilidade e conexões recusadas durante esse período de indisponibilidade. O impacto foi encerrado e a estabilidade restaurada por volta das 23:38. ‌ **Causa Raiz** A análise detalhada confirmou que a interrupção foi causada pela saturação de recursos no nosso banco de dados, que atingiu 100% de utilização de CPU. Esse esgotamento foi desencadeado por um aumento substancial e não previsto no volume de tráfego de um cliente específico durante um evento de grande visibilidade ao público. O pico de acessos coincidiu com um processo interno de otimização de cache em execução no mesmo período, gerando uma severa contenção no banco de dados. Como consequência, o número de conexões abertas disparou de uma média de 80 para cerca de 500, resultando em até 300 processos bloqueados simultaneamente. Adicionalmente, a sobrecarga causou falhas nas verificações de integridade da aplicação, levando a reinicializações que agravaram a disponibilidade temporariamente. ‌ **Resolução** Nossos sistemas de alerta automatizados detectaram a violação de disponibilidade imediatamente, e a equipe de resposta a incidentes reconheceu e iniciou a atuação em apenas 1 a 2 minutos após o primeiro disparo. A equipe conseguiu identificar rapidamente a janela de impacto e isolar as falhas nos primeiros 10 minutos. Após a dissipação do surto repentino de tráfego, os serviços e o banco de dados estabilizaram-se sozinhos e a disponibilidade retornou aos níveis normais de operação. ‌ **Aprendizados** * **Eficiência na Detecção:** Nossas ferramentas de observabilidade provaram ser eficientes, permitindo que a equipe correlacionasse sinais em múltiplos serviços quase em tempo real e de forma estruturada. * **Gestão de Carga:** Identificamos que a configuração atual do banco de dados não está dimensionada de forma ideal para gerenciar o volume massivo de conexões concorrentes geradas por surtos anômalos de requisições. * **Impacto de Processos Internos:** Operações pesadas de otimização de cache durante picos de tráfego representam um risco para a estabilidade da aplicação. **Ações Preventivas** * **Otimização de Consultas:** Refatorar o padrão de consultas e as atualizações de cache no banco de dados para minimizar a latência e o consumo excessivo de recursos de CPU. * **Revisão de Provisionamento:** Avaliar e ajustar os limites de capacidade e resiliência do banco de dados e da infraestrutura subjacente para suportar aumentos extremos de carga com maior fluidez de conexão.