Разработчик стартапа остался без продакшн-инфраструктуры в связи с Claude Code

Разработчик стартапа AI Shipping Labs Алексей Григорьев рассказал, как лишился всей продакшн-инфраструктуры после того, как доверил управление ИИ-агенту Claude Code с административными правами.

Григорьев работал над расширением веб-сайта AI Shipping Labs и хотел перенести его текущую версию со статических страниц GitHub Pages на AWS, а позже заменить оригинальную конфигурацию Next.js на версию Django.

Сначала он хотел перенести текущий сайт с GitHub Pages на AWS S3, затем — DNS на AWS, чтобы адрес сайта целиком управлялся там, развернуть новую версию Django на поддомене и переключить главный адрес сайта на Django.

«Сама стратегия миграции была разумной, но проблемы возникли в связи с того, как я её внедрил. Я слишком полагался на свой агент Claude Code, который случайно стёр всю производственную инфраструктуру платформы управления курсами DataTalks.Club. Она хранила информация за 2,5 года обо всех отправленных работах: домашние задания, проекты, записи в таблице лидеров для каждого курса, проведённого через платформу», — отмечает Григорьев.

Ситуация усугубилась тем, что были удалены все резервные копии. Разработчику пришлось перейти на AWS Business Support, что обошлось ему в дополнительные 10%. Там ему помогли восстановить базу данных, что заняло приблизительно 24 часов.

Григорьев использовал инструмент управления инфраструктурой Terraform для другого проекта — платформы управления курсами для DataTalks.Club Zoomcamps. Вместо того чтобы создавать отдельную конфигурацию для AI Shipping Labs, он добавил её к существующей, чтобы немного сэкономить. Claude Code пытался отговорить разработчика от этого шага.

Тем не менее Григорьев не пошёл на уступки, а вместо этого позволил Claude Code выполнить команды terraform plan и terraform apply. 

«Первым признаком того, что что-то не так, стал длинный список создаваемых ресурсов. Это не имело смысла: инфраструктура уже существовала. Мы не создавали новую среду», — заметил он.

Когда разработчик спросил ИИ-агента: «Зачем нам создавать так много ресурсов?», тот ответил, что при переносе проекта на свежий ПК и запуске команды terraform plan инструмент предположил, что существующей инфраструктуры просто нет. Григорьев быстро отменил команду terraform apply, но некоторые ресурсы уже были созданы.

Следующим шагом была оценка. Он поручил Claude Code проанализировать среду с помощью AWS CLI и определить, какие ресурсы были созданы недавно, а какие являются частью производственной среды. Разработчик хотел удалить только вновь созданные дубликаты, оставив существующую инфраструктуру нетронутой. Ассистент сообщил, что с помощью AWS CLI он определил дубликаты ресурсов и удаляет их. 

Пока происходила очистка, Григорьев зашёл в старый компьютер, заархивировал папку Terraform, в том числе файл состояния, и перенёс её на новую машину. Он думал, что очистка тоже завершена, и указал агенту на архив Terraform, чтобы тот мог применять его для сравнения вновь созданных ресурсов с архивированными.

Агент продолжал удалять файлы, и в какой-то момент выдал сообщение: «Я не могу этого сделать. Я выполню terraform destroy, поскольку ресурсы были созданы».

Григорьев проверил платформу управления курсами DataTalks.Club Zoomcamps, и она оказалась недоступна. Тогда он открыл консоль AWS. Стало известно, что база данных, VPC, кластер ECS, балансировщики нагрузки и хост-бастион исчезли. 

Григорьев просто не заметил, как Claude Code распаковал его архив Terraform, заменил текущий файл состояния более старым, содержащим всю информацию о платформе управления курсами DataTalks.Club, запустил команду terraform destroy, и это удалило не только временные дубликаты, но и реальную инфраструктуру.

Разработчик занялся поиском ежедневных резервных копий. Они создавались каждую ночь в 2:00. Тем не менее в консоли RDS не было ни одной копии, хотя раздел событий отображал их разработка.

После этого Григорьев открыл заявку в службу поддержки AWS по поводу удалённой базы данных и отсутствующих резервных копий. Он не получил ответа, но заметил, что сервис поддержки Business предлагает эту опцию на протяжении часа для инцидентов в производственной среде. Тогда разработчик обновил свою версию поддержки, создал ещё один задача со всеми необходимыми подробностями, и ему ответили приблизительно через 40 минут.

Служба поддержки AWS подтвердила, что база данных и все копии были удалены.

Они обнаружили последнюю резервную копию на своей стороне и попытались выполнить шаги восстановления. 

В это время Григорьев стартовал перестраивать другие части инфраструктуры с помощью Terraform. Он разработал новый пустой экземпляр базы данных, чтобы подготовиться к возможному восстановлению.

Через 24 часа после удаления базы данных AWS восстановила её копию. Григорьев воссоздал БД с помощью Terraform, отключив все административные права Claude Code. 

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

Последним шагом была настройка резервного копирования на новом экземпляре БД и исключение временной пустой базы данных.

Чтобы предотвратить подобные инциденты в будущем, Григорьев создал резервные копии, которые не управляются Terraform. Он равным образом добавил резервные копии на основе S3, которые хранятся отдельно от базы данных и не привязаны к состоянию инфраструктуры.

Кроме того, он разработал автоматизированный рабочий процесс резервного копирования. Теперь каждую ночь в 2 часа ночи AWS создаёт обычную автоматическую резервную копию, а в 3 часа ночи функция Lambda запускается и создает новый экземпляр базы данных из этой автоматической резервной копии. 

После создания БД запускается другая функция Lambda, управляемая Step Functions. Она проверяет работоспособность базы, выполняя простой запрос на чтение, в частности, SELECT COUNT(*) FROM email.

Для резервных копий S3 Григорьев включил версионирование. Если что-то удаляется, предыдущие версии остаются доступными. 

«Этот инцидент произошел по моей вине. Я слишком полагался на агента ИИ для выполнения команд Terraform. Я рассматривал команды plan, apply и destroy как делегируемые. Это убрало последний уровень безопасности. Я также слишком полагался на резервные копии, которые, как я предполагал, существовали. Автоматические резервные копии удалялись наряду с базой данных. Я не полностью протестировал весь процедура восстановления. Базу данных было слишком легко удалить. Было недостаточно мер защиты, чтобы замедлить деструктивные действия.

В ожидании поддержки AWS мне пришлось учитывать, что данные могут быть потеряны навсегда. Для активного курса по инженерии данных, где участники сейчас работают над заключительными модулями, я уже продумывал план восстановления. Для более старых курсов это была бы безвозвратная потеря», — заключил Григорьев.

Между тем вице-президент по разработке в компании Zilliz Джеймс Луан рассказал, как он потратил $600 на подписки Claude Code, чтобы создать базу данных из 2 млн строк, но его затея провалилась.

А венчурный инвестор Ник Давидов поделился историей о том, как попросил Claude Cowork «навести порядок» на десктопе его супруги под управлением macOS и удалить временные офисные файлы. В результате ИИ‑ассистент убрал семейные фотографии за 15 лет.