Разработчик стартапа 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 лет.
