26 февраля разработчик, работавший над расширением сайта ИИ Shipping Labs, решил перенести его со статических GitHub Pages в AWS. План был поэтапным: перенести текущий сайт в S3, затем DNS, развернуть Django-версию на поддомене и переключить основной домен. Для управления инфраструктурой он использовал Terraform, а в качестве помощника — ИИ-агента Claude Code.
Вместо того чтобы создать отдельную конфигурацию Terraform для нового проекта, разработчик добавил его в существующую, управляющую продакшен-инфраструктурой платформы управления курсами. Claude предупреждал, что инфраструктуры лучше держать раздельно, но разработчик захотел сэкономить $5–10 в месяц на ещё одном VPC. Это повысило риск: изменения для двух сайтов смешались.
| Время | Событие |
|---|---|
| Четверг, 22:00 | Начало изменений через Terraform без state-файла |
| 23:00 | Команда Terraform с auto-approve снесла продакшен-инфраструктуру, включая RDS |
| 00:00 (пятница) | Переход на AWS Business Support (доплата 10%) |
| 00:30 | Поддержка AWS подтвердила наличие снапшота на своей стороне |
| 01:00–02:00 | Звонок с поддержкой; обращение передано внутренней команде |
| В течение дня | Внедрение защитных мер: Lambda-бэкапы, защита от удаления, бэкапы в S3, перенос state в S3 |
| 22:00 | База данных полностью восстановлена (одна таблица содержала 1 943 200 строк) |
Первый тревожный сигнал появился, когда агент запустил terraform plan и terraform apply с флагом auto-approve. Список создаваемых ресурсов оказался подозрительно длинным — Terraform считал, что инфраструктура не существует, так как state-файл остался на старом компьютере. Разработчик отменил apply, но часть ресурсов уже создалась.
Пользователь проигнорировал предупреждение агента о разделении инфраструктуры ради экономии $5–10 в месяц.
Для очистки дублирующихся ресурсов он поручил Claude анализировать окружение через AWS CLI. Агент нашёл дубликаты и начал удалять их, но в процессе решил, что чище будет запустить terraform destroy. Это привело к полному удалению продакшен-инфраструктуры: экземпляры RDS, снапшоты баз данных и другие ресурсы были уничтожены.
Хронология инцидента выглядит так:
| Время | Событие | |-------|---------| | Четверг, 22:00 | Начало изменений через Terraform без state-файла | | 23:00 | Команда Terraform с auto-approve снесла всю продакшен-инфраструктуру, включая RDS | | 00:00 (пятница) | Переход на AWS Business Support (доплата 10%) | | 00:30 | Поддержка AWS подтвердила наличие снапшота на своей стороне | | 01:00–02:00 | Звонок с поддержкой; обращение передано внутренней команде | | В течение дня | Внедрение защитных мер: Lambda-бэкапы, защита от удаления, бэкапы в S3, перенос state в S3 | | 22:00 | База данных полностью восстановлена (одна таблица содержала 1 943 200 строк) |
Ключевая ошибка — чрезмерное доверие ИИ-агенту и игнорирование его предупреждений. Разработчик не проверил план вручную, не убедился в наличии state-файла и позволил агенту выполнять разрушительные команды. После инцидента были внедрены обязательные меры защиты: автоматические бэкапы через Lambda, включение защиты от удаления на критических ресурсах, хранение Terraform state в S3 с блокировками, а также разделение конфигураций для разных проектов.
Этот случай — напоминание о том, что ИИ-агенты, даже такие продвинутые как Claude Code, не могут полностью заменить человеческий контроль над критической инфраструктурой. Экономия нескольких долларов на VPC обернулась простоем на сутки и дополнительными расходами на премиум-поддержку AWS. Для безопасного использования ИИ-агентов в DevOps необходимы строгие политики, автоматические проверки и резервное копирование.
