Atlassian 2022: quando um script de manutenção apaga 400 clientes por duas semanas
Ouvir estudo
gerado ao ouvirGerado apenas no primeiro play
Com tecnologia Amazon Polly + OmniVoice
Em abril de 2022, um script de manutenção mal parametrizado executou hard deletes em ~400 sites de clientes Atlassian Cloud, incluindo Jira, Confluence e outros produtos. A ausência de soft-delete, a falta de dry-run obrigatório e a inexistência de ferramentas de restauração em massa transformaram um erro operacional de minutos em uma indisponibilidade de até 14 dias. Este post-mortem examina a cadeia de falhas, o blast radius real e as lições estruturais que todo time de plataforma deveria internalizar.
Fatos do Incidente
- Empresa
- Atlassian
- Data de início
- 5 de abril de 2022
- Duração total da recuperação
- Até 14 dias para os clientes mais afetados
- Clientes impactados
- ~400 sites (aprox. 0,18% da base de clientes cloud)
- Produtos afetados
- Jira Software, Jira Service Management, Jira Work Management, Confluence, Atlassian Access, Statuspage, Atlassian Access
- Tipo de falha
- Hard delete acidental via script de manutenção com IDs incorretos
- Causa raiz primária
- Script recebeu lista de IDs de um app legado, mas apagou IDs de sites de produção ativos
- Stack relevante
- Atlassian Cloud (multi-tenant SaaS), sistemas internos de provisionamento e desprovisionamento
- Fonte oficial
- Post-Incident Review publicado pela Atlassian Engineering
Erros operacionais acontecem. O que diferencia um incidente contido de uma catástrofe de duas semanas não é a ausência do erro — é a ausência das camadas de defesa que deveriam existir antes, durante e depois dele. O caso Atlassian de abril de 2022 é um manual do que não fazer quando se opera uma plataforma SaaS multi-tenant em escala: um script sem dry-run obrigatório, hard deletes sem soft-delete como rede de segurança, e a descoberta tardia de que restaurar 400 sites individualmente, sem tooling adequado, levaria semanas. Este post-mortem não é sobre culpa — é sobre arquitetura.
O que aconteceu
A Atlassian opera um processo contínuo de limpeza de dados para remover instâncias de aplicativos legados que foram descontinuados ou desconectados por clientes. Em 5 de abril de 2022, a equipe responsável executou um script de manutenção com o objetivo de desprovisionar um conjunto específico de instâncias de um app legado — o Atlassian Insight (posteriormente integrado ao Jira Service Management). O script foi parte de um processo maior de consolidação de produtos.
O problema central foi de parametrização: o script recebeu como entrada uma lista de IDs de instâncias do app legado a serem removidas, mas o mecanismo de execução interpretou esses IDs no contexto errado — aplicando-os como identificadores de sites de clientes ativos na plataforma Atlassian Cloud. O resultado foi a execução de hard deletes em aproximadamente 400 sites de produção, varrendo dados de múltiplos produtos por site: Jira Software, Jira Service Management, Confluence, Atlassian Access e outros.
O termo "hard delete" aqui é preciso e crítico: não se tratou de uma marcação lógica para remoção futura, nem de um soft-delete reversível por operação administrativa. Os dados foram permanentemente excluídos dos sistemas de armazenamento primário. Não havia um mecanismo de rollback imediato. A recuperação dependeria inteiramente de backups — e a restauração de backups, por site, de forma manual, para centenas de clientes, revelou-se o verdadeiro gargalo do incidente.
Linha do Tempo
- 1
5 abr — Script executado
Equipe de manutenção executa script de desprovisionamento do app Insight legado. O script recebe IDs incorretos e executa hard deletes em ~400 sites de clientes ativos. A execução ocorre sem dry-run prévio em produção.
- 2
5 abr — Detecção inicial
Clientes começam a reportar indisponibilidade total de seus sites. Alertas internos disparam. A equipe de engenharia identifica que sites inteiros foram removidos — não apenas instâncias de app específicas.
- 3
5–6 abr — Escopo do dano avaliado
A Atlassian confirma ~400 sites afetados. Descobre-se que não existe processo automatizado de restauração em massa. Cada site precisa ser restaurado individualmente a partir de backups, o que exige engenharia manual intensiva.
- 4
6–10 abr — Comunicação pública e triagem
A Atlassian publica comunicados no status page e começa a contatar clientes afetados diretamente. A empresa prioriza clientes com maior impacto (maior número de usuários, contratos enterprise). Críticas públicas crescem pela falta de ETA claro.
- 5
10–18 abr — Restauração em ondas
A engenharia monta força-tarefa dedicada. O processo de restauração é parcialmente automatizado ao longo dos dias, mas ainda requer validação manual por site. A maioria dos clientes é restaurada entre os dias 10 e 18 de abril.
- 6
18 abr — Último cliente restaurado
Aproximadamente 14 dias após o início do incidente, o último site afetado é restaurado. A Atlassian confirma que nenhum dado foi permanentemente perdido — todos os dados foram recuperados dos backups, mas o tempo de indisponibilidade variou de horas a duas semanas.
- 7
Abr 2022 — Post-Incident Review publicado
A Atlassian publica sua análise pós-incidente oficial, detalhando causas, linha do tempo e ações corretivas planejadas. O documento é notavelmente transparente para padrões da indústria.
Fluxo de Falha: Como o Script Apagou Sites de Produção
O diagrama reconstrói o fluxo de execução do script de manutenção e como a confusão de IDs propagou hard deletes para os sistemas de armazenamento de múltiplos produtos. As setas tracejadas indicam o caminho que deveria ter existido (dry-run, soft-delete) mas não existia.
- Engenheiro · de Manutenção
- Script de · Desprovisionamento
- Lista de IDs · (Insight legado)
- API de · Provisionamento
- Registro de Sites · (IDs de produção)
- Motor de · Deleção
- Jira Software · + JSM Data
- Confluence · Data
- Atlassian Access · + outros
- Backups · (restauração manual)
- Dry-Run · (não existia)
- Soft-Delete · (não implementado)
- Restore em Massa · (não existia)
Causa Raiz: Três Ausências, Não Um Erro
A causa raiz imediata foi a confusão de namespaces de IDs: o script tratou IDs de instâncias de um app legado como IDs de sites de produção, e o motor de deleção não validou o contexto. Mas o verdadeiro root cause sistêmico é a ausência de três camadas de defesa independentes:
1. Sem dry-run obrigatório: O script foi executado diretamente em produção sem uma fase de simulação que listasse o que seria deletado sem efetivamente deletar. Um dry-run teria exposto o erro antes de qualquer dano.
2. Sem soft-delete: O sistema de desprovisionamento executava hard deletes diretamente. Um padrão de soft-delete — marcar o recurso como PENDING_DELETION com um período de retenção de 24–72h — teria permitido reversão imediata após a detecção do erro.
3. Sem tooling de restauração em massa: A Atlassian tinha backups. O problema não foi a ausência de dados recuperáveis — foi a ausência de infraestrutura para restaurar centenas de sites em paralelo. O processo manual foi o multiplicador de tempo que transformou um incidente de horas em um de semanas.
O Blast Radius Real e Por Que Demorou Duas Semanas
É tentador reduzir este incidente a "0,18% dos clientes" e seguir em frente. Mas o blast radius precisa ser medido em termos de impacto por cliente afetado, não apenas em proporção da base total.
Cada um dos ~400 sites era uma organização com múltiplos usuários, projetos ativos, histórico de tickets, documentação em Confluence, fluxos de aprovação e integrações. Para essas organizações, a indisponibilidade foi total — não degradada, não parcial. Jira inacessível significa que times de engenharia não conseguem rastrear bugs, times de suporte não conseguem abrir chamados, releases ficam bloqueados. Duas semanas nesse estado para uma empresa de médio porte é um dano operacional mensurável.
O que prolongou a recuperação foi a ausência de automação no caminho de restauração. A Atlassian mantinha backups regulares — isso foi fundamental para garantir que nenhum dado foi permanentemente perdido. Mas o processo de restauração era essencialmente: identificar o backup correto para aquele site específico, provisionar um ambiente de restauração, executar a restauração, validar integridade dos dados, reconectar integrações e notificar o cliente. Multiplicado por 400, sem paralelismo automatizado, isso se torna uma operação de semanas mesmo com uma força-tarefa dedicada.
Há também um aspecto de priorização que merece atenção: a Atlassian priorizou clientes enterprise e aqueles com maior número de usuários. Isso é racionalmente defensável do ponto de vista de impacto agregado, mas para as organizações menores que ficaram no final da fila, a experiência foi de abandono. A comunicação sobre ETAs foi consistentemente criticada como vaga — "estamos trabalhando nisso" sem datas concretas é insuficiente quando uma empresa inteira está parada.
Remediação e o Que a Atlassian Comprometeu
No post-incident review oficial, a Atlassian foi notavelmente específica sobre as ações corretivas — o que é raro e merece reconhecimento. As principais categorias de remediação anunciadas foram:
Prevenção de execução incorreta:
- Implementação de dry-run obrigatório para scripts de manutenção que afetam dados de produção
- Validação de namespace de IDs antes da execução: o sistema deve verificar que os IDs fornecidos correspondem ao tipo de entidade esperado (instância de app vs. site de cliente)
- Revisão por pares obrigatória e aprovação separada para scripts de desprovisionamento em produção
- Limitação de blast radius por design: scripts de manutenção devem ter limites explícitos no número de entidades que podem afetar em uma única execução
Melhoria do caminho de recuperação:
- Desenvolvimento de tooling de restauração em massa para permitir recuperação paralela de múltiplos sites
- Implementação de soft-delete com período de retenção antes da destruição permanente de dados
- Melhoria nos processos de comunicação com clientes afetados, incluindo ETAs mais granulares
Observabilidade e detecção:
- Alertas proativos para operações de deleção em massa que excedam thresholds definidos
- Melhoria no monitoramento de operações de manutenção para detecção mais rápida de execuções anômalas
O que me chama atenção nessa lista é que nenhum item é tecnicamente complexo. Dry-run, soft-delete, validação de tipos de ID — essas são práticas de engenharia bem estabelecidas. O problema não foi falta de conhecimento técnico; foi a ausência de um processo que tornasse essas práticas obrigatórias para operações de alto risco. Isso é um problema de cultura de engenharia e de processo, não de capacidade técnica.
Lições Estruturais
Trabalhei com sistemas financeiros onde deleção acidental de dados tem implicações regulatórias além do dano operacional — então este caso ressoa de forma particular. O que me incomoda não é o erro em si, mas a ausência de redundância nos controles de segurança.
Em qualquer sistema que gerencia dados de terceiros em escala, eu trato operações de deleção como operações de alto risco por definição — independente de quão rotineiro o processo pareça. Minha abordagem padrão para scripts de manutenção destrutivos:
1. Dry-run como primeira classe: O script não tem modo de execução real sem passar pelo dry-run primeiro. Não é uma flag opcional — é o fluxo padrão. O output do dry-run vai para revisão humana antes de qualquer aprovação de execução real.
2. Soft-delete com janela de retenção: Nunca hard delete direto em produção para recursos de clientes. O recurso vai para PENDING_DELETION por no mínimo 24h. Qualquer alerta durante esse período cancela a deleção automaticamente.
3. Limite de blast radius hardcoded: O script tem um parâmetro --max-entities com um default conservador (ex: 10). Para executar em escala maior, é necessário override explícito com justificativa logada. Isso força consciência sobre o escopo.
4. Validação de tipo antes de qualquer operação: IDs passam por uma camada de validação que confirma o tipo de entidade antes de qualquer operação. Isso é trivial de implementar e elimina toda uma classe de erros de namespace.
5. Runbook de restore testado regularmente: O processo de restauração é testado em ambiente de staging mensalmente. Se você não testou o restore, você não tem backup — você tem dados armazenados cuja recuperabilidade é uma hipótese.
O que a Atlassian viveu aqui é, na essência, um problema de ausência de cultura de operações seguras para scripts de manutenção — uma área que frequentemente fica fora do escopo dos processos de engenharia mais rigorosos aplicados ao código de produto. Scripts de manutenção são código de produção. Devem ser tratados como tal.
Veredicto
O incidente Atlassian de abril de 2022 não foi causado por uma tecnologia falha, uma arquitetura inadequada ou um engenheiro incompetente. Foi causado pela ausência sistemática de controles operacionais que são conhecidos, documentados e implementáveis — e que simplesmente não foram aplicados a scripts de manutenção com o mesmo rigor aplicado ao código de produto. A lição mais importante não está na lista de remediações técnicas, mas na pergunta que toda equipe de plataforma deveria fazer regularmente: quais são as operações que, se executadas incorretamente, causam dano irreversível ou de recuperação lenta — e essas operações têm controles proporcionais ao seu risco? Para scripts de manutenção que tocam dados de clientes, a resposta correta é: dry-run obrigatório, soft-delete, validação de tipo de entidade, limite de blast radius, aprovação multi-parte e tooling de restore testado. Nenhum desses itens é tecnicamente sofisticado. Todos são culturalmente difíceis de manter quando a pressão operacional é alta e o script parece rotineiro. A Atlassian teve a integridade de publicar um post-mortem detalhado e honesto. Isso é raro e valioso. O custo foi pago pelos ~400 clientes que ficaram sem acesso por até duas semanas. O aprendizado é gratuito para todos nós.
Post-mortems, ADRs e deep dives de arquitetura no seu email — do jeito que um arquiteto lê.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Receba uma resposta focada sobre este estudo do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar — você também recebe a newsletter. Sem senha.