Claude Code выполнил terraform destroy в продакшн-среде DataTalks.Club

Незадолго до 23:00 26 февраля 2026 года агент Claude Code запустил terraform destroy в отношении аккаунта AWS, на котором работала платформа курсов DataTalks.Club, и удалил продакшен-стек: VPC, кластер ECS, балансировщики нагрузки, bastion-хост и базу данных PostgreSQL на Amazon RDS. На платформе хранились студенческие решения, домашние задания, проекты и записи таблицы лидеров за 2,5 года для каждого курса, проводившегося через неё, а автоматические резервные копии RDS пропали в тот же момент, не оставив в консоли ничего, из чего можно было бы восстановиться. Алексей Григорьев, который руководит DataTalks.Club и опубликовал 6 марта 2026 года разбор инцидента от первого лица, вернул данные примерно через 24 часа только потому, что поддержка AWS нашла внутренний снимок, который его собственный аккаунт не видел. Полная запись, включая список источников и оценку достоверности, находится в Orca AI Incident Archive вместе с другими вызванными агентами инфраструктурными инцидентами, которые он индексирует.

Доказательная база уже, чем предполагают пересказы, и об этом стоит сказать прямо, прежде чем переходить к хронологии. Все конкретные сведения здесь восходят к Григорьеву. В AI Incident Database есть два отчёта об инциденте — его пост в Substack «Как я удалил нашу production-базу данных и теперь плачу за AWS на 10% больше» и материал Tom's Hardware от 7 марта 2026 года авторства Бруно Феррейры, — причём второй представляет собой краткое изложение первого. Интервью, опубликованное компанией по управлению инцидентами Rootly, добавляет подробности его собственными словами. Не было опубликовано ни заявления Anthropic, ни заявления AWS, ни заключения регулятора по этому событию. В отношении того, что было удалено, все версии сходятся; там, где история в том виде, в каком она распространялась, расходится с тем, что он действительно написал, в этой статье указано, что есть что.

Два решения, которые заложили основу

Переезд был обычной работой. Григорьев хотел перенести сайт AI Shipping Labs с GitHub Pages на AWS, а затем переписать его на Django. Вместо создания второго окружения он добавил сайт в конфигурацию Terraform, которая уже управляла платформой курсов, стоящей за курсами Zoomcamp от DataTalks.Club — системой, хранящей отправленные задания, домашние работы, проекты и записи в таблице лидеров за 2,5 года. В своём посте он оценивает экономию в $5–$10 в месяц и отмечает, что агент возражал против такого решения: «Claude пытался отговорить меня, говоря, что мне следует держать это отдельно». Он всё равно велел ему разместить всё в существующей VPC, потому что не хотел ещё одну.

Второе решение было более тихим. Файл состояния Terraform — это его запись о том, что уже существует. Григорьев недавно перешёл на новый компьютер и не перенёс этот файл, поэтому, когда развёртывание началось примерно в 22:00 26 февраля, план счёл аккаунт пустым и начал создавать дубликат инфраструктуры. Он увидел длинный список создаваемых ресурсов, остановил apply и спросил, почему. Ответ агента, по его словам, был таким: Terraform считал, что ничего не существует.

Уничтожение

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

Когда этот state уже был на месте, следующее предложение агента подчинялось его собственной логике. В посте, который цитирует Григорьев, он говорит: «Я не могу этого сделать. Я выполню terraform destroy. Поскольку ресурсы были созданы через Terraform, уничтожить их через Terraform будет чище и проще, чем через AWS CLI». Он согласился и сказал Rootly: «Да, Claude выполнил terraform destroy, я это видел и не остановил его». Он также сказал о подмене state: «Я не знал, что state был подменён». Команда выполнилась с auto-approve около 23:00, поэтому ничего не приостановилось, чтобы спросить во второй раз.

Два рассказа передают предложение агента по-разному — в интервью Rootly оно звучит как «удалять их по одному скучно, может, мне просто запустить terraform destroy?» — но оба описывают одну и ту же картину: destroy предлагается как наведение порядка, а оператор, считавший, что в область действия входят только дубликаты, позволяет ему выполниться. Механизм сбоя не в том, что агент неправильно понял команду. А в том, что агент рассуждал правильно, исходя из файла состояния, описывавшего production, а его оператор никак не мог увидеть, что файл изменился.

Что было уничтожено?

Файл состояния, с которым теперь работал агент, описывал production, поэтому destroy запланировал удаление production. Григорьев перечисляет, что было удалено:

• VPC, содержавшая всю среду.

• Кластер ECS, в котором работает приложение.

• Балансировщики нагрузки перед ним.

• Бастионный хост, используемый для доступа к частной сети.

• База данных Amazon RDS, в которой хранятся данные платформы курсов.

• Автоматические снимки RDS, которые должны были обеспечить возможность восстановления всего вышеперечисленного.

Последний пункт — это то, что превратило сбой в угрозу потери данных. В интервью Rootly Григорев объясняет это тем, что удаление управляемой базы данных в AWS также удаляет связанные с ней автоматические резервные копии; в публикации поддержка AWS подтвердила ему, что его база данных и все снимки были удалены и что «запрос API явно указывал AWS удалить всё». Как бы ни распространялось удаление, значение имел эффект в 23:00: копия, на которую он полагался, была удалена той же операцией, что и оригинал.

Восстановление за 24 часа

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

Около полуночи он открыл обращение в поддержку, а затем перевёл аккаунт на AWS Business Support, заметив обязательство по часовому времени реакции для производственных инцидентов. Апгрейд добавил примерно 10 процентов к его счёту за AWS — отсюда и название его поста. Поддержка ответила примерно через 40 минут, подтвердила удаление и сообщила ему, что на стороне AWS существует снимок, который он не видит в своей консоли. Последовал звонок длительностью 40–60 минут, и вопрос был эскалирован во внутреннюю команду. Ровно через 24 часа после удаления базы данных AWS восстановила снимок, и он появился в его консоли; он пересоздал экземпляр из него через Terraform. Пока он ждал, он перестроил окружающую инфраструктуру и объединил несколько балансировщиков нагрузки в один.

В восстановленной базе данных было 1 943 200 строк вcourses_answer — таблице, которую он приводит в качестве проверки того, что восстановление было полным. Эту цифру часто повторяют как масштаб потери. Это число строк одной таблицы, используемое как доказательство того, что данные вернулись, — а не общий итог по базе данных и не количество пострадавших студентов, которое не приводит ни один из источников.

Предупреждение, которого не было

В нескольких пересказах встречается утверждение, что Claude заранее предупредил Григорьева, но его проигнорировали. То, что подтверждают источники, уже, и эта разница меняет то, примером чего является данный случай. Агент действительно возражал против общей конфигурации Terraform до какого-либо разрушения, и этот совет был отклонён. Ни в одной из версий Григорьева не описывается, что агент предупреждал о том, что destroy затронет production. Он говорит, что не знал о подмене файла состояния, и в обеих версиях предложение агента подаётся как наведение порядка, а не как риск, о котором сообщили и который отклонили. Проигнорированное предупреждение касалось архитектуры, раньше по ходу миграции, а не команды.

Это различие разделяет два разных сбоя. Агент, который видит опасность, но чьё решение отменяют, — это история про управление, о человеческом решении. Агент, который не знает о существовании опасности, потому что файл, описывающий мир, изменился под ним, — это история про инструментарий: о состоянии, правах доступа и шлюзах согласования. Версия Григорьева — вторая, и собственная классификация архива это отражает: запись несёт метку ROGUE архива для действия агента, отклонившегося от замысла его оператора, а соответствующая запись в AI Incident Database классифицирует умысел как непреднамеренный — по таксономии MIT 7.3, «недостаток возможностей или устойчивости», в риск-домене «безопасность систем ИИ, сбои и ограничения», на этапе после развёртывания. База данных добавляет к своему списку сущностей приставку «alleged» — стандартную формулировку для случая, о котором сообщили сами участники и который не был рассмотрен ни одним органом.

На кого легла вина

Григорьев не распространяет его. «Этот инцидент произошёл по моей вине», — пишет он, перечисляя три причины: он считал, что plan, apply и destroy можно делегировать; он доверял резервным копиям, которые ни разу не проверял восстановлением; и базу данных было слишком легко удалить. Он отмечает, что, пока ждал ответа от AWS, ему пришлось допустить, что данные могли быть утрачены навсегда, — для курса Data Engineering, который тогда проходил последние модули, он уже планировал восстановление, а для более старых курсов неудачное восстановление означало бы их конец.

Оценка Tom's Hardware, опубликованная на следующий день после его поста, по сути та же: «ошибки можно объяснить ненадлежащим надзором». Её критика идёт дальше его критики, указывая на широкий набор учётных данных, предоставленных агенту, и разрешения, которые так и не ограничили для производственной среды. Ни один регулятор, орган по стандартизации или поставщик не занял позицию. Здесь нет ни CVE, ни раскрытия уязвимости, ни джейлбрейка модели: агента не обманули — ему слишком доверяли.

Что изменилось после этого

Григорьев внедрил меры защиты, пока AWS всё ещё работал над восстановлением, и опубликовал их в виде списка. Его словами и в его порядке:

• Резервные копии, которыми Terraform не управляет, а также копии на основе S3, хранящиеся отдельно от базы данных и состояния инфраструктуры.

• Ежедневная ночная проверка восстановления: автоматическая резервная копия, создаваемая в 2:00, примерно в 3:00 используется для создания нового экземпляра базы данных, что занимает 20–30 минут, после чего Lambda, оркестрируемая Step Functions, проверяет его работоспособность простым запросом на чтение, а затем экземпляр останавливается, а не удаляется. Вчерашняя копия удаляется, поэтому одна недавняя реплика всегда доступна.

• Защита от удаления на двух уровнях: в конфигурации Terraform и в самом AWS. Он отмечает, что их всё равно может удалить любой, кто явно отключит их, но что они создают дополнительное препятствие.

• Версионирование резервных копий в S3: при удалении сохраняются предыдущие версии, а чтобы очистить бакет, сначала нужно удалить его содержимое.

• Состояние Terraform перенесено в S3, что устраняет условие, с которого всё началось, — файл состояния, существовавший только на одном ноутбуке и пропадавший при смене машины.

• Агент больше вообще не выполняет Terraform. «Все разрешения отключены. Никакого автоматического выполнения. Никакой записи файлов», — пишет он. Теперь рабочий процесс состоит в том, чтобы сгенерировать план, вручную проверить его и запустить команды самому. У нового проекта также появилась собственная отдельная конфигурация Terraform.

Не все рекомендации были приняты. В интервью Rootly он говорит, что оставил один аккаунт AWS, сочтя отдельные аккаунты для разработки и продакшена и конвейер согласований вроде Atlantis излишними для оператора-одиночки. Такова честная картина последствий: исправления реальны, и это исправления, которые один человек может поддерживать в одиночку.

Что представляет собой эта запись — и чем она не является

Это документированный, самостоятельно заявленный операционный инцидент с реальным финансовым ущербом и ущербом для доступности, и он необычно понятен, потому что человек, с которым это произошло, записал всю последовательность, включая те части, которые были его собственной ошибкой. Это не доказательство того, что модель преследовала собственную цель, и тег ROGUE в архиве следует читать как описание расхождения между действием агента и намерением его оператора, а не как указание на какое-либо намерение со стороны агента.

Та деталь, которую стоит запомнить, — это то, что спасло данные. Собственные резервные копии Григорьева были удалены вместе с базой данных, которую они защищали, а его ночной снимок был для него невидим, хотя журнал событий настаивал, что он существует. То, что восстановило 2,5 года курсовых работ, оказалось копией на стороне AWS, о существовании которой он не знал и которую не мог протестировать. Резервная копия, из которой вы не восстанавливались, — это убеждённость, а не средство контроля, и в этом случае убеждённость оказалась истинной только потому, что кто-то другой хранил вторую копию.