Недавно одна команда Terraform, запущенная ИИ-агентом, снесла продакшен-инфраструктуру платформы курсов. В этой статье расскажу, как это произошло и как удалось восстановить базу данных.

Ситуация: я работал над расширением сайта https://aishippinglabs.com/ и хотел перенести его текущую версию со статических GitHub Pages в AWS. А позже заменить исходную версию на Next.js вариантом на Django.

План постепенной миграции был таким:

1. перенести текущий статический сайт с GitHub Pages в AWS S3;

2. перенести DNS в AWS, чтобы домен полностью управлялся там;

3. развернуть новую Django-версию на поддомене;

4. когда всё заработает, переключить основной домен на Django.

Так вся инфраструктура уже была бы внутри AWS, а финальное переключение прошло бы безболезненно.

Сама стратегия миграции была нормальной. Проблемы начались из-за того, как я её выполнял.

Я слишком сильно положился на своего агента Claude Code, и он случайно снёс всю продакшен-инфраструктуру платформы управления курсами. На этой платформе хранились данные за 2,5 года по разным процессам: домашние задания, проекты, записи в лидербордах — по каждому запуску курсов, проходившему через платформу.

Хуже того, вместе с этим удалились все автоматические снапшоты. Мне пришлось перейти на AWS Business Support, который стоит мне дополнительные 10% обычных расходов, для доступа к более быстрой поддержке. К счастью, поддержка помогла восстановить базу данных, а полное восстановление заняло около 24 часов.

В этой статье я расскажу, как допустил такую ситуацию и что сделал, чтобы она не повторилась.

---

Хронология инцидента

Четверг, 26 февраля

• 22:00: начал выкатывать изменения сайта через Terraform, но забыл использовать state-файл: он остался на старом компьютере.

• 23:00: команда Terraform с auto-approve случайно снесла всю продакшен-инфраструктуру, включая Amazon Relational Database Service (RDS). Позже я обнаружил, что все снапшоты тоже удалены, и создал тикет в поддержку AWS.

Пятница, 27 февраля

• 00:00: перешёл на AWS Business Support, чтобы получить более быстрый ответ.

• 00:30: поддержка AWS подтвердила, что на их стороне есть снапшот.

• 01:00–02:00: созвонился с поддержкой AWS; обращение передали внутренней команде для восстановления.

• В течение дня: внедрил меры защиты — настроил Lambda-функцию для бэкапов, включил защиту от удаления, сделал бэкапы в S3 и перенёс Terraform state в S3.

• 22:00: база данных была полностью восстановлена. Только в одной таблице courses_answer оказалось 1 943 200 строк. Платформу снова подняли.

Как случилась катастрофа

Повторное использование существующей Terraform-конфигурации

У меня уже был Terraform, который управлял продакшен-инфраструктурой другого проекта — платформы управления курсами. Вместо того чтобы создать отдельную конфигурацию для AI Shipping Labs, я добавил его в существующую, чтобы немного сэкономить.

Claude пытался меня отговорить и говорил, что инфраструктуру лучше держать отдельно. Но я хотел чуть снизить расходы: у меня была схема, где всё находится внутри Virtual Private Cloud (VPC), все ресурсы размещены в приватной сети, а для доступа к машинам используется бастион.

Экономия там не такая уж большая, может быть $5–10 в месяц. Но я подумал: зачем мне ещё один VPC? И сказал агенту сделать всё там же. Это повысило сложность и риск, потому что изменения для этого сайта теперь оказались смешаны с изменениями другой инфраструктуры.

Первый тревожный сигнал

Вместо того чтобы вручную пройтись по плану, я позволил Claude Code запустить terraform plan, а затем terraform apply. Первым признаком, что что-то не так, стал длинный список создаваемых ресурсов. Это не имело смысла: инфраструктура уже существовала. Мы не поднимали новое окружение.

Я остановил Claude и спросил: «Почему создаётся так много ресурсов?» Ответ агента был простым и одновременно пугающим: Terraform считал, что ничего не существует.

Но почему? Я недавно переехал на новый компьютер и не перенёс Terraform. Когда я запустил terraform plan, он решил, что существующей инфраструктуры нет и мы начинаем с нуля.

Я быстро отменил terraform apply, но часть ресурсов уже успела создаться.

Анализ и удаление дублирующихся ресурсов через AWS CLI

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

Ассистент сообщил, что нашёл дублирующиеся ресурсы через AWS CLI и удаляет их. Звучало правильно.

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

Удаление через terraform destroy

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

Это выглядело логично: если ресурсы создал Terraform, Terraform же должен их и удалить. Поэтому я не стал останавливать агента, когда он запускал terraform destroy. Команда завершилась успешно. В тот момент я всё ещё думал, что мы чистим только свежесозданные ресурсы.

Потом я проверил платформу управления курсами, и она лежала. Я подумал: «Что происходит?» — и открыл AWS Console, чтобы разобраться.

База данных, VPC, ECS-кластер, балансировщики нагрузки и бастион исчезли. Вся продакшен-инфраструктура была уничтожена.

Когда я спросил Claude, где база данных, ответ был прямой: она удалена.

Что произошло на самом деле

Проблема была в том, что я не заметил, как Claude распаковал мой архив с Terraform. Он заменил текущий state-файл старым, где была вся информация о платформе управления курсами.

Когда Claude запустил terraform destroy, он снёс не только временные дубликаты. Фактически он уничтожил реальную инфраструктуру платформы курсов — ту самую, которая была описана в state-файле.

Поиск решения

1. Ищем бэкапы

Когда я понял, что продакшен-инфраструктура исчезла, я начал искать бэкапы. Они должны были создаваться ежедневно.

Было около 23:00, и я знал, что снапшот создаётся каждую ночь в 02:00. Я зашёл в консоль RDS и проверил доступные снапшоты, но ничего не увидел. Проверил консоль ещё раз — всё равно пусто.

События RDS в четверг. Бэкап был создан в 00:24 и отображался в AWS Console в разделе событий, но сам бэкап исчез.

Затем я открыл раздел RDS Events и увидел, что бэкап действительно был создан в 02:00, как и ожидалось. Событие было в списке, но при клике ничего не открывалось, а сам снапшот был недоступен.

В тот момент я не понимал, удалён бэкап или просто не отображается.

2. Обращение в поддержку AWS

Около полуночи я создал тикет в поддержку по поводу удалённой базы данных и пропавших бэкапов. Я также написал коллеге в AWS, но не рассчитывал на ответ так поздно.

Не получив ответа, я заметил, что Business Support обещает ответ в течение часа в случае инцидентов в продакшене. Поэтому я повысил уровень поддержки, и это добавило примерно 10% к моим облачным расходам.

Затем я создал ещё один тикет со всеми нужными деталями. Поддержка ответила примерно через 40 минут.

3. Что нашла поддержка AWS

Поддержка AWS подтвердила, что моя база данных и все снапшоты были удалены. Этого я совсем не ожидал. API-запрос явно сказал AWS удалить всё.

На своей стороне они нашли снапшот, который я не видел в консоли. Когда я указал на это, они предложили созвониться.

4. Созвон с AWS

Мы созвонились и вместе разобрали ситуацию.

Они попробовали выполнить восстановление со своей стороны. Через какое-то время инженер поддержки сказал, что ему нужно эскалировать обращение внутри AWS. Мы оставались на линии, пока они разбирались.

Пока продакшен уже лежал, я начал заново собирать остальные части инфраструктуры через Terraform. Это получилось довольно быстро. Заодно я упростил некоторые вещи: например, свёл несколько балансировщиков нагрузки к одному.

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

Звонок длился примерно 40–60 минут. В итоге они сказали, что им нужно больше времени и они вернутся с ответом, когда прояснят ситуацию.

5. Спустя 24 часа

Ровно через 24 часа после удаления базы данных AWS восстановила снапшот.

Я получил письмо с подтверждением, что восстановление снапшота завершено и он готов к использованию:

Снапшот, который раньше был невидимым, теперь появился в консоли.

6. Восстановление базы данных

Я пересоздал базу данных из восстановленного снапшота через Terraform.

На этом этапе я изменил подход к работе с Terraform через Claude Code. Все разрешения отключены. Никакого автоматического выполнения. Никакой записи в файлы.

Теперь процесс простой:

• сгенерировать план;

• вручную его проверить;

• самому выполнить команды.

После восстановления базы данных я проверил данные. В таблице courses_answer было 1 943 200 строк:

Платформа управления курсами снова заработала. Все домашние задания были видны.

Последний шаг — настроить бэкапы для нового экземпляра базы данных и аккуратно удалить временную пустую базу, созданную во время инцидента, не перепутав её с восстановленной.

Что я сделал, чтобы это не повторилось

Пока я ждал, когда AWS решит проблему со снапшотом, я начал внедрять защитные меры. Я не хотел, чтобы одна команда destroy когда-нибудь снова могла снести всё.

Вот что я изменил.

1. Бэкапы вне Terraform state

Я настроил бэкапы, которыми не управляет Terraform.

Я не ожидал, что снапшоты исчезнут вместе с базой данных. Чтобы избежать такого риска, я позаботился о том, чтобы были бэкапы, независимые от жизненного цикла Terraform.

Также я добавил бэкапы в S3. Они хранятся отдельно от базы данных и не привязаны к состоянию инфраструктуры.

2. Ежедневная проверка восстановления через Lambda и Step Functions

Я собрал автоматизированный процесс резервного копирования.

Каждую ночь в 02:00 AWS создаёт обычный автоматический бэкап. Примерно в 03:00 просыпается Lambda-функция и создаёт новый экземпляр базы данных из этого автоматического бэкапа. Так каждый день у меня появляется свежая копия продакшена. Это занимает около 20–30 минут.

Когда база создана, запускается ещё одна Lambda-функция, оркестрированная через Step Functions. Она проверяет, что базой действительно можно пользоваться: выполняет простой запрос на чтение, например SELECT COUNT(*) FROM email. После успешной проверки база останавливается, а не удаляется. Так я плачу только за хранилище, а не за вычисления.

После этого восстановленная вчера база удаляется. В любой момент времени у меня есть одна недавно восстановленная реплика.

Я сделал это по двум причинам:

• хочу регулярно проверять, что бэкапы действительно можно восстановить;

• если продакшен упадёт, я смогу переключить трафик на реплику, которую уже можно запустить.

Возможно, я не всегда буду использовать её именно так, но хочу иметь такую возможность.

3. Защита от удаления в Terraform и AWS

Я включил защиту от удаления на двух уровнях:

• в конфигурации Terraform;

• в самой AWS.

Оба уровня защищают от случайного удаления.

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

4. Защита бэкапов в S3

Для бэкапов в S3 я включил версионирование. Если что-то удалят, предыдущие версии останутся доступны. Чтобы удалить бакет, сначала нужно удалить его содержимое, а это добавляет ещё один барьер.

5. Перенос Terraform state в S3

Самое важное: я перенёс Terraform state в S3.

State больше не хранится локально на одной машине. Теперь у Terraform есть единое и согласованное представление об инфраструктуре. Это убирает исходную проблему: я думал, что state уже лежит удалённо, хотя на самом деле он оставался локально на старом компьютере. Из-за этого и начали создаваться дублирующиеся ресурсы.

Когда state хранится в S3:

• он не привязан к одному ноутбуку;

• он не может тихо пропасть при переходе на другую машину;

• у Terraform всегда есть согласованное представление об инфраструктуре.

Выводы

Этот инцидент — моя ошибка:

• Я слишком сильно положился на ИИ-агента при запуске команд Terraform. Я отнёсся к plan, apply и destroy как к тому, что можно делегировать. Так я убрал последний защитный слой.

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

• Базу данных было слишком легко удалить. Не хватало защитных механизмов, которые замедлили бы разрушительные действия.

Пока я ждал ответа поддержки AWS, мне пришлось всерьёз допустить, что данные могли исчезнуть навсегда.

Для активных курсов, где участники проходили финальные модули, я уже продумывал план восстановления. Для старых курсов это была бы безвозвратная потеря.

К счастью, поддержка AWS нашла снапшот и всё восстановила.

Что меняется теперь

Внедрённые защитные меры остаются.

Для Terraform:

• агенты больше не выполняют команды;

• каждый план проверяется вручную;

• каждое разрушительное действие запускаю я сам.

Для AI Shipping Labs я думаю использовать отдельный AWS-аккаунт для дева и прода, чтобы нормально изолировать окружения до запуска.

Инструменты

nao: open-source-фреймворк для создания и развёртывания аналитических агентов, которые позволяют пользователям запрашивать данные на естественном языке, сохраняя при этом инженерный уровень контроля и надёжности. Data-команды задают структурированный версионируемый контекст через CLI, интегрируют его с любым data stack, покрывают качество модульным тестами и безопасно хостят всё у себя с собственными LLM-ключами. Бизнес-пользователи получают чат-интерфейс со встроенными визуализациями, прозрачной логикой рассуждений и встроенными циклами обратной связи. 

Pilot Shell: профессиональная среда разработки для Claude Code, которая встраивает инженерные защитные механизмы прямо в рабочий процесс. Вместо сложной многоагентной обвязки она принудительно запускает тесты, линтинг, форматирование и проверку типов при каждом изменении, сохраняя контекст между сессиями. В результате получается агентный кодинг со встроенными продакшен-стандартами: разработчики могут делегировать задачи, отойти, а затем вернуться к проверенному коду, который соответствует соглашениям проекта и готов к отправке.

rtk (Rust Token Killer): производительный CLI-прокси, который снижает расход токенов LLM за счёт фильтрации и сжатия вывода команд до попадания в контекст модели. В типичных сессиях Claude Code он сокращает расход токенов на 60–90% для обычных операций: git, тестов, чтения файлов и поисковых команд. Это заметно снижает стоимость и повышает эффективность использования контекста. Инструмент специально сделан для разработки с участием AI, где большие выводы терминала иначе быстро забивают бюджет токенов.

Ещё три материала о том, как автоматизировать разработку и инфраструктуру, не теряя контроль над системой:

• Как работают ИИ-агенты для разработки

• Почему AI-агенты ломаются на длинных задачах — и как обвязка помогает им дописывать приложения

• Self‑service деплой: как перестать ждать DevOps и ускорить команду

Одна команда может снести прод за минуты, а восстановление занять сутки. Поэтому важно заранее понимать, где заканчивается удобная автоматизация и начинается риск для инфраструктуры.

На бесплатных открытых уроках преподаватели-практики покажут, как выстраивать устойчивые процессы, разбирать сбои и безопаснее работать с AI-инструментами:

• 22 июня, 20:00. «Роль и задачи DevOps в современном IT». Записаться

• 24 июня, 20:00. «Инцидент-менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

• 21 июля, 20:00. «Разработка ИИ-приложений с Claude Code». Записаться

На занятиях можно познакомиться с экспертами, оценить формат обучения и задать вопросы по своим рабочим кейсам.

Больше бесплатных уроков смотрите в дайджесте.