Instabilidade nos Serviços do IDPAY

Update timeline

1. identified Jan 19, 2026, 01:30 PM UTC

   Prezado Cliente, Identificamos uma instabilidade nas requisições do produto IDPay, gerando instabilidade momentânea na criação de transações. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. A instabilidade ocorreu entre 09:45 e 10:10(BRT) Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

2. monitoring Jan 19, 2026, 01:34 PM UTC

   Prezado Cliente, Incidente resolvido. Identificamos uma instabilidade nas requisições do produto IDPay, gerando instabilidade momentânea na criação de transações. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. A instabilidade ocorreu entre 09:45 e 10:10(BRT) 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 Jan 19, 2026, 01:36 PM UTC

   Relatório Pós-Incidente: Instabilidade nos Serviços do IDPAY Resumo Executivo e Impacto: No dia 19 de janeiro de 2026, entre 09:45 e 10:10 BRT, o serviço IDPAY apresentou uma degradação crítica em sua disponibilidade, afetando APIs fundamentais de transação, definições de retenção (holds) e validações de processos. Durante este intervalo de 25 minutos, a conformidade com os níveis de serviço (SLO) caiu para 76,5%, resultando em uma interrupção sustentada que impediu o processamento de requisições enviadas pelos parceiros. O incidente foi detectado via alertas automáticos assim que o volume de erros ultrapassou as margens de segurança estabelecidas para a operação. Causa Raiz e Resolução: A instabilidade foi causada por uma falha estrutural ocorrida durante a execução de uma migração de banco de dados, parte de uma atualização de versão do sistema. A alteração gerou inconsistências imediatas no processamento das APIs do IDPAY, elevando drasticamente a taxa de erros. A resolução foi concluída às 10:10 após a equipe técnica realizar a reversão manual da migração diretamente na camada de dados. Com o restabelecimento da configuração estável anterior, o serviço retornou à normalidade e a taxa de sucesso das transações foi totalmente recuperada. Agradecemos a compreensão e a parceria durante a resolução deste incidente. Nossa prioridade absoluta é garantir a resiliência e a estabilidade do IDPAY, e já estamos trabalhando no aprimoramento dos nossos processos de validação de infraestrutura para evitar que falhas em migrações voltem a impactar a sua operação. Reforçamos nosso compromisso com a transparência e permanecemos à disposição para quaisquer esclarecimentos adicionais por meio dos nossos canais oficiais de suporte. Atenciosamente, Equipe Unico

4. postmortem Jan 27, 2026, 12:47 PM UTC

   # Postmortem: Instabilidade nos Serviços do IDPAY ‌ ## Resumo No dia 19 de janeiro de 2026, entre 09:45 e 10:10 \(Horário de Brasília\), nossos serviços de processamento de pagamentos e validação de transações apresentaram uma degradação significativa. O incidente foi causado por uma alteração no esquema do banco de dados que gerou uma incompatibilidade com a versão do código em execução no ambiente de produção. A estabilidade foi restabelecida após a reversão manual das alterações no banco de dados. ‌ ## Impacto Durante o período de 25 minutos do incidente, a disponibilidade dos serviços caiu para **76,5%**. Os usuários enfrentaram erros intermitentes e falhas ao tentar criar ou validar transações e acessar funções de carteira. No pico da instabilidade, a taxa de erro chegou a aproximadamente **98%** para as APIs afetadas. ‌ ## Causa Raiz A falha foi originada por uma atualização de banco de dados em uma tabela crítica de configuração. Embora a migração e o novo código da aplicação tenham sido testados com sucesso em ambientes de homologação, houve uma divergência no tempo de execução entre o banco de dados e a implantação do código em produção. ‌ Isso criou uma "janela de incompatibilidade" onde o banco de dados já esperava uma estrutura nova, mas o serviço ainda operava com a lógica anterior. A ausência de um mecanismo de rollback automatizado para o banco de dados estendeu o tempo de recuperação, pois exigiu intervenção manual dos engenheiros. ‌ ## Resolução O incidente foi identificado às 09:56 após alertas de monitoramento. Após o diagnóstico da incompatibilidade, a equipe técnica realizou uma reversão manual dos procedimentos de migração diretamente no banco de dados. O serviço foi totalmente restaurado às 10:10, seguido por um período de monitoramento para garantir a estabilização das taxas de erro. ‌ ## Lições Aprendidas * **Estratégias de Migração Segura:** Mudanças em tabelas críticas devem adotar padrões de "expansão e contração", onde novas colunas são adicionadas sem remover as antigas imediatamente, garantindo compatibilidade com versões anteriores do código. * **Paridade de Ambientes:** É essencial que o sequenciamento e o tempo de implantação em ambientes de teste repliquem exatamente o comportamento do ambiente de produção para capturar condições de corrida e incompatibilidades temporais. * **Automação de Rollback:** Processos manuais em momentos de crise aumentam o tempo médio de recuperação \(MTTR\) e o risco de erro humano. A automação da reversão de esquemas de banco de dados é uma prioridade para serviços críticos. * **Monitoramento em Tempo Real:** A presença de uma política de acompanhamento em dupla durante implantações críticas permite uma detecção e resposta mais ágil a anomalias. ‌ Estamos comprometidos com a estabilidade de nossos ambientes e atuaremos nas ações preventivas, mitigando impactos similares no futuro. ‌ Agradecemos a compreensão e estamos à disposição para esclarecer quaisquer dúvidas.