Na AbacatePay, confiabilidade e transparência são princípios centrais. Quando falhamos, entendemos que é nossa responsabilidade explicar claramente o que aconteceu, o impacto causado e quais ações estamos tomando para evitar que isso volte a ocorrer.
Resumo
Durante uma migração planejada para o lançamento de uma nova versão da plataforma, enfrentamos uma sequência de falhas que resultaram em indisponibilidade significativa dos nossos serviços.
Embora a AbacatePay utilize uma estratégia multi-cloud, nem todos os componentes críticos da plataforma estavam replicados entre provedores. Isso limitou severamente nossa capacidade de realizar rollback ou failover rápido quando a infraestrutura principal apresentou falhas.
O incidente resultou em mais de 36 horas de impacto intermitente e contínuo, afetando principalmente transações, acesso a contas e operações financeiras.
Assumimos total responsabilidade pelo ocorrido.
Impacto
- Indisponibilidade para login e uso do painel
- Falha no envio e recebimento de pagamentos
- Degradação severa de performance em momentos de recuperação parcial
- Impacto em quase toda a base ativa de clientes durante o período
Não houve perda de dados financeiros ou inconsistência de saldos confirmada.
O que aconteceu
A migração tinha como objetivo colocar no ar uma nova versão da plataforma (v2), mantendo a versão anterior disponível para possível rollback. O plano envolvia:
- Preparar uma nova infraestrutura de aplicação
- Migrar dados de forma controlada
- Alterar gradualmente o roteamento via Cloudflare
Apesar de múltiplos testes prévios, surgiram falhas não previstas durante a execução real da migração. Após o corte de acesso ao banco de dados e a aplicação das mudanças estruturais, não foi possível restaurar a versão anterior com rapidez.
O principal fator agravante foi que a infraestrutura principal de produção não podia ser recriada ou replicada de forma imediata em outro ambiente, seja no mesmo provedor ou em outro cloud provider, sem a construção manual de uma nova infraestrutura do zero.
Tentativas de recuperação no mesmo provedor falharam de forma recorrente, incluindo instabilidades severas em máquinas virtuais e perda de acesso administrativo. Isso nos forçou a acelerar a criação de uma nova infraestrutura em outro provedor de cloud, processo que levou várias horas até atingir estabilidade operacional.
Linha do tempo
Todos os horários em Horário de Brasília (UTC-3)
16 de Janeiro
- 00:20 — A API de produção teve o acesso ao banco de dados interrompido para início da migração.
- 00:25 — Todos os jobs assíncronos finalizaram o processamento pendente.
- 00:30 — Iniciamos o dump completo do banco de dados em um ambiente separado.
- 00:45 — Executamos o script de migração nos dados clonados.
- 01:35 — A migração foi concluída e o banco principal foi restaurado a partir dos dados migrados.
- 01:45 — A nova infraestrutura de aplicação foi colocada no ar e passou por testes automatizados e de carga, sem falhas aparentes.
- 01:50 — O DNS de
app.abacatepay.comfoi atualizado para apontar para a nova versão da plataforma. - 01:52 — O novo dashboard foi publicado separadamente e apresentou estabilidade inicial.
- 02:15 — Bugs funcionais no novo dashboard foram identificados e priorizados.
- 03:00 — Observamos crescimento anormal de uso de disco na nova infraestrutura até o limite, causando perda de resposta da aplicação.
- 03:20 — O volume de disco foi expandido para análise do problema.
- 03:40 — A infraestrutura principal começou a apresentar falhas intermitentes e perda de resposta em certos momentos.
- 04:10 — Identificamos falhas de build e deploy no frontend relacionadas à estrutura do repositório monorepo.
- 04:45 — Confirmamos inconsistências no deploy do dashboard que causavam comportamento semelhante a erro de DNS onde
abacatepay.comcontinha o build deapp.abacatepay.com. - 06:10 — Ajustes permitiram builds independentes e estáveis do frontend.
- 06:15 — Identificamos que a infraestrutura principal estava fora do ar sem alertas de monitoramento serem recebidos.
- 06:35 — Tentativas de recuperação da VM principal falharam, com perda de conectividade administrativa.
- 07:03 — Após múltiplas reinicializações da VM v2, foi identificado gargalo crítico em conexões com o banco de dados.
- 07:17 — Uma nova VM foi provisionada para a API principal, mas apresentou falhas recorrentes de inicialização.
- 07:45 — A equipe concentrou esforços na estabilização da nova versão da plataforma até outra equipe assumir.
- 08:53 — A nova equipe constatou nova perda de acesso às VMs recém-criadas, tanto da API principal quanto da v2.
- 09:15 — Após recuperação manual, os containers foram reiniciados e o deploy realizado novamente.
- 16:30 — A infraestrutura voltou a ficar completamente inacessível com necessidade de provisionamento de nova VM.
- 22:40 — Uma nova tentativa de provisionamento de mais uma VM foi realizada no mesmo provedor após novas instabilidades na v2.
17 de Janeiro
- 07:40 — Decidimos provisionar a infraestrutura da v2 em outro provedor de cloud.
- 12:15 — A nova infraestrutura apresentou estabilidade funcional, porém com latência elevada.
- 13:20 — Identificamos que o time anterior não havia habilitado proxy no DNS, resultando em tentativas de tráfego malicioso. Juntamente com clientes voltando a operar na plataforma. Resultando em uma performance comprometida.
- 13:30 — Proteções foram reativadas e endereços de rede rotacionados.
- 15:00 — Os sistemas foram considerados estáveis.
- 16:00 — O suporte iniciou atendimento ativo para clientes impactados.
Por que demoramos para recuperar
Embora sejamos uma empresa com presença multi-cloud, nossa infraestrutura crítica ainda não possuía replicação ativa entre provedores.
Na prática, isso significa que:
- Apenas partes da plataforma estavam distribuídas entre clouds
- A infraestrutura principal não podia ser recriada automaticamente em outro provider
- O provedor falhou em permitir um bom SLA e gerenciamento da instâncias, deixando o time sem acesso ou controle das VMs
- Não foi possível encontrar o real problema das VMs pararem de funcionar
- A recuperação exigiu criação manual de um novo ambiente completo em um provedor diferente
Esse conjunto aumentou drasticamente o tempo necessário para restaurar os serviços.
O que estamos fazendo para evitar que ocorra novamente
- Janelas de manutenção claras e comunicadas previamente
- Replicação efetiva de componentes críticos entre clouds
- Infraestrutura totalmente reprodutível e versionada como código
- Estratégia de rollback testada com janelas maiores
- Critérios rigorosos de go / no-go para mudanças críticas
- Planejamento formal de gestão de risco
- Sistema de alertas interno e externo que reflita a realidade
- Redução de pontos únicos de falha na cadeia crítica
- Separação clara de ambientes, domínios e responsabilidades de deploy
- Checklists obrigatórios para operações de alto risco
- Simulações periódicas de incidentes (chaos engineering)
- Documentação viva de arquitetura e dependências críticas
- Validação pós-deploy antes de exposição total
- Processo consistente de comunicação externa em incidentes
- Time dedicado para resposta a incidentes críticos
- Investimento contínuo em observabilidade e diagnóstico rápido
Compromisso
Sabemos que esse incidente gerou frustração, prejuízos operacionais e perda de confiança. Pedimos desculpas a todos os clientes impactados.
Nosso compromisso é aprender com esse evento, fortalecer nossa plataforma e garantir que a AbacatePay evolua com a resiliência que um sistema financeiro exige.
Seguiremos compartilhando melhorias relevantes sempre que necessário.
Precisa de ajuda? ajuda@abacatepay.com
Construiu algo legal? Marca a gente. @abacatepay em todas redes sociais.