Содержание
Claude Code в связке с Terraform удалил продакшен-инфраструктуру разработчика Алексея Григорьева в AWS. Под нож ушли оба сайта, база данных с 2,5 года записей и даже снапшоты, на которые он рассчитывал как на бэкап.
История закончилась без катастрофы. Данные вернули через поддержку Amazon примерно за один день. Но сам кейс получился показательный: когда у ИИ-агента есть права на «красную кнопку», ошибка оператора превращается в «terraform destroy» по живому.
Как переезд в AWS закончился массовым удалением
Григорьев переносил свой сайт AI Shipping Labs в AWS. Он хотел, чтобы проект жил в одной инфраструктуре с DataTalks.Club. Сам Claude советовал так не делать, но разработчик решил, что два отдельных контура — это лишние траты и возня.
Для управления инфраструктурой он использует Terraform. Это тот самый инструмент, который по описанию в коде поднимает сети, балансировщики, базы и серверы. И так же легко сносит всё до нуля, если команда и состояние сходятся.
Дальше началась цепочка мелких ошибок, которые сложились в большую.
Ключевая ошибка: не загрузили state-файл Terraform
Сначала Григорьев попросил Claude выполнить Terraform plan для новой конфигурации. Но он не загрузил важный state-файл — файл состояния, который описывает, что уже существует в инфраструктуре «прямо сейчас».
Без state Terraform не понимает, какие ресурсы уже созданы. В итоге Claude начал создавать дубликаты ресурсов. Оператор остановил процесс на середине.
Затем Григорьев попросил агента найти дубликаты, чтобы всё поправить. После этого он загрузил state-файл и решил, что теперь Claude продолжит чистку дублей, а потом сверится с состоянием.
Но Terraform работает иначе. Как только у него появился state, он стал ему следовать. И Claude запустил Terraform destroy, чтобы «подготовить площадку» и развернуть всё заново уже правильно.
Почему снесло сразу два проекта и даже снапшоты
В state-описании оказалась инфраструктура не только AI Shipping Labs, но и DataTalks.Club. Поэтому уничтожение затронуло оба сайта.
Удаление оказалось полным. Пропала база данных с 2,5 года записей. Пропали и снапшоты базы, которые разработчик воспринимал как страховку.
Восстанавливать пришлось через Amazon Business support. По словам Григорьева, данные подняли примерно за сутки.
Что разработчик меняет после инцидента
После разборов полётов Григорьев описал меры, которые внедряет, чтобы такое не повторилось. В центре идеи простые: чаще проверять восстановление, меньше доверять агенту разрушительные команды, и жёстче ограничивать удаление на уровне облака и прав.
- Тест восстановления: он настраивает периодическую проверку восстановления базы из бэкапов.
- Защита от удаления: включает delete protection в Terraform и ограничивает AWS-права для опасных операций.
- Хранение state: переносит Terraform state в S3, а не держит его локально.
- Ручной контроль: он признал, что «over-relied on the AI agent to run Terraform commands» и теперь сам будет запускать разрушительные действия после проверки плана.
Подробное описание инцидента и таймлайн Григорьев выложил отдельным постом: wipe years’ worth of records.
AI Shipping Labs как проект доступен по адресу aishippinglabs.com.
