Клод, удали всё. Краткое пособие, как уничтожить плоды двух лет работы за один Terraform-план

Клод, удали всё. Краткое пособие, как уничтожить плоды двух лет работы за один Terraform-план

Попытка навести порядок после дубликатов закончилась полным удалением двух связанных проектов.

image

Истории про ИИ-агентов, которые что-то «сломали», обычно читаются как анекдот с легким злорадством. Но случай разработчика Алексея Григорьева получился куда менее смешным: во время переноса сайта на AWS Claude Code по цепочке ошибочных действий удалил инфраструктуру сразу двух проектов, базу данных с записями за два с половиной года и даже снапшоты, на которые владелец рассчитывал как на резервную копию.

Проблема началась с вполне обычной задачи. Григорьев решил перенести сайт AI Shipping Labs в Amazon Web Services и разместить проект на общей инфраструктуре вместе с DataTalks.Club. Сам Claude, по словам разработчика, советовал не объединять площадки, но владелец посчитал, что поддерживать два отдельных контура слишком хлопотно и дорого.

Для управления инфраструктурой Григорьев использовал Terraform. Такой инструмент умеет не только поднимать серверы, базы данных, сети и балансировщики нагрузки, но и столь же быстро сносить всю конфигурацию целиком. Разработчик поручил Claude подготовить Terraform plan для нового сайта, однако в процессе забыл передать важнейший файл состояния. Именно state-файл хранит актуальное описание уже существующей инфраструктуры и подсказывает Terraform, что создано, что изменено и что трогать нельзя.

Без state-файла Claude выполнил задачу буквально и начал создавать ресурсы заново. В результате появились дубликаты. Операцию остановили на середине, после чего Григорьев попросил Claude найти лишние ресурсы и помочь исправить ситуацию. Затем разработчик загрузил недостающий state-файл, решив, что дальше агент спокойно дочистит дубли и приведет конфигурацию в порядок.

На практике все пошло по другому сценарию. Получив state-файл, Claude больше не «думал» в логике человека, который уже держит в голове всю историю инцидента. Агент увидел корректное описание инфраструктуры и начал действовать так, как подсказывал Terraform. Для приведения среды к «правильному» состоянию Claude инициировал destroy-операцию, то есть удаление текущих ресурсов перед повторным развертыванием.

Беда заключалась в том, что описание инфраструктуры охватывало не только AI Shipping Labs, но и сайт DataTalks.Club. В итоге команда на удаление снесла конфигурацию сразу двух площадок. Под удар попала и база данных с накопленными за 2,5 года записями. Хуже всего выглядел эпизод со снапшотами: резервные копии базы тоже исчезли, хотя именно на них Григорьев рассчитывал в случае аварии.

Спасти данные удалось только после обращения в поддержку Amazon Business. Специалисты AWS помогли восстановить информацию примерно за сутки. Без вмешательства со стороны облачного провайдера история могла закончиться куда тяжелее, поскольку обычная логика «сейчас откатимся из бэкапа» в такой схеме уже не работала.

После инцидента Григорьев подробно разобрал причины сбоя и перечислил меры, которые собирается внедрить. Среди главных шагов регулярная проверка восстановления баз данных, включение защит от удаления на уровне Terraform и AWS, а также перенос state-файла в S3 вместо локального хранения. Разработчик также признал, что слишком сильно доверил ИИ-агенту выполнение Terraform-команд. Теперь разрушительные действия он собирается запускать только после ручной проверки каждого плана.

Соблазнительно назвать историю очередным примером «глупый бот все испортил», но такой вывод слишком удобен и потому слишком поверхностен. Многие системные администраторы сразу увидят более приземленные проблемы: слишком широкие права у агента, слабые ограничения в production-среде и опасная привычка давать автоматизированному помощнику доступ к операциям, которые способны снести весь контур целиком.

Главный урок здесь, похоже, не в том, что Claude оказался ненадежным, а в том, что ИИ-агенту приписали слишком много понимания. Terraform исполнил команды без скидок на контекст, а Claude не смог догадаться, что второй сайт внутри общей инфраструктуры требует особой осторожности. Ровно так же ошибся бы и неопытный младший администратор, если бы получил широкие права, неполную картину происходящего и задачу «разобраться на месте».