# Atlassian 2022: quando um script de manutenção apaga 400 clientes por duas semanas 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. - URL: https://fernando.moretes.com/studies/atlassian-2022-deletion-outage - Markdown: https://fernando.moretes.com/studies/atlassian-2022-deletion-outage/study.md?lang=pt - Type: Post-mortem - Company: Atlassian - Domain: Deploy/Dados - Date: 2022-04-05 - Tags: postmortem, atlassian, data-loss, incident-response, soft-delete, operational-safety, cloud-platform, deploy - Reading time: 9 min --- ## 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. ### 🛠️ Operação de Manutenção / Maintenance Operation - Engenheiro de Manutenção (user) - Script de Desprovisionamento (ci) - Lista de IDs (Insight legado) (storage) ### ⚙️ Plataforma de Provisionamento / Provisioning Platform - API de Provisionamento (compute) - Registro de Sites (IDs de produção) (data) - Motor de Deleção (compute) ### 💾 Armazenamento de Dados / Data Storage - Jira Software + JSM Data (storage) - Confluence Data (storage) - Atlassian Access + outros (storage) - Backups (restauração manual) (storage) ### 🚫 Controles Ausentes / Missing Controls - Dry-Run (não existia) (security) - Soft-Delete (não implementado) (security) - Restore em Massa (não existia) (security) ### Fluxos - operator -> script: executa com IDs errados - id_list -> script: IDs do app legado - script -> prov_api: envia IDs para deletar - prov_api -> site_registry: resolve IDs como sites ativos - site_registry -> delete_engine: ~400 sites identificados - delete_engine -> jira_db: HARD DELETE - delete_engine -> confluence_db: HARD DELETE - delete_engine -> access_db: HARD DELETE - backup -> jira_db: restauração manual (dias) - backup -> confluence_db: restauração manual (dias) - script -> dry_run: deveria validar aqui - delete_engine -> soft_delete: deveria marcar, não apagar - backup -> mass_restore: deveria automatizar > **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 - **Soft-delete não é opcional em SaaS multi-tenant**: Qualquer operação de deleção em um sistema que gerencia dados de múltiplos clientes deve passar por um estado intermediário reversível. Hard deletes diretos em produção são uma dívida técnica com juros compostos. - **Dry-run obrigatório para operações destrutivas**: Scripts que modificam ou deletam dados em produção devem ter uma fase de simulação que liste o escopo exato da operação antes de qualquer execução real. Isso deve ser enforçado pelo sistema, não apenas recomendado como boa prática. - **Validação de tipo de entidade é uma camada de segurança**: Quando um script recebe IDs como input, o sistema deve validar que esses IDs correspondem ao tipo de entidade esperado. Confusão de namespaces é um vetor de erro clássico e prevenível. - **Backups sem tooling de restore são necessários mas insuficientes**: Ter backups é o mínimo. A capacidade de restaurar centenas de entidades em paralelo, com automação e validação, é o que determina o RTO real em um incidente de escala. - **Limite de blast radius por design**: Scripts de manutenção devem ter limites explícitos e hardcoded no número de entidades que podem afetar em uma única execução. Um script que pode deletar 400 sites em uma execução é um script que não deveria existir nessa forma. - **Comunicação de incidente requer ETAs concretos**: "Estamos trabalhando nisso" sem datas é insuficiente para clientes com operações paradas. A comunicação deve incluir estimativas honestas, mesmo que conservadoras, e atualizações frequentes. > **Minha Leitura Sênior:** 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. ## Referências - [Atlassian Engineering — Post-Incident Review: April 2022 Outage](https://www.atlassian.com/engineering/post-incident-review-april-2022-outage) ## Fontes do caso - [Atlassian — Post-Incident Review (April 2022 outage)](https://www.atlassian.com/engineering/post-incident-review-april-2022-outage)