- Разработчик стартапа AI Shipping Labs Алексей Григорьев лишился всей продакшн-инфраструктуры из-за чрезмерного доверия ИИ-агенту Claude Code при управлении Terraform.
- При попытке очистки ресурсов Claude Code случайно выполнил terraform destroy с устаревшим состоянием, что привело к удалению базы данных и ключевых компонентов инфраструктуры DataTalks.Club.
- Восстановление данных заняло около суток и было обеспечено службой поддержки AWS Business Support, после чего Григорьев внедрил более надёжную систему резервного копирования и контроля доступа.
Алексей Григорьев, разработчик стартапа AI Shipping Labs, столкнулся с серьёзными проблемами после того, как поручил управление продакшн-инфраструктурой ИИ-агенту Claude Code с административными правами. Его задача заключалась в миграции веб-сайта с GitHub Pages на AWS и последующей замене конфигурации с Next.js на Django.
Первоначально Григорьев планировал перенести статический сайт на AWS S3, затем настроить управление доменом через AWS DNS и постепенно внедрить новую платформу на Django. Стратегия казалась логичной, однако реализация вызвала серьёзные сложности. Главная ошибка заключалась в чрезмерной зависимости от Claude Code при работе с инструментом управления инфраструктурой Terraform.
Разработчик решил добавить конфигурацию AI Shipping Labs к уже существующему проекту DataTalks.Club в одной Terraform-конфигурации вместо создания отдельной. Несмотря на предупреждения агента, он разрешил выполнить команды terraform plan и terraform apply. Результатом стал неожиданный запуск множества ресурсов, которые должны были отсутствовать, что вызвало подозрения.
Когда Григорьев поручил ИИ-агенту проанализировать и очистить дублирующиеся ресурсы с помощью AWS CLI, агент в итоге запустил команду terraform destroy, используя устаревшее состояние Terraform, которое случайно было распаковано из архива. Это привело к уничтожению всей продакшн-инфраструктуры платформы DataTalks.Club, включая базу данных, VPC, кластер ECS и балансировщики нагрузки.
Ключевой проблемой оказалось отсутствие резервных копий: автоматические backup’ы, создаваемые каждую ночь, исчезли вместе с удалённой базой. После обращения в службу поддержки AWS, с которой пришлось перейти на платный тариф Business Support, данные смогли восстановить примерно за 24 часа.
В дальнейшем Алексей Григорьев внедрил комплекс мер для предотвращения подобных инцидентов в будущем. Были созданы независимые резервные копии, не управляемые Terraform, организована отдельная система резервного копирования на основе S3 с версионированием, а также автоматизированный процесс проверки работоспособности восстановленных баз данных с использованием AWS Lambda и Step Functions.
Григорьев признал свою ошибку в чрезмерном доверии ИИ-агенту и недостаточной проработке мер безопасности, подчеркнув важность тестирования процессов восстановления и контроля доступа при работе с критичной инфраструктурой. Этот инцидент служит наглядным примером необходимости аккуратного подхода к автоматизации с участием ИИ в управлении IT-инфраструктурой.
