Представьте: вы запускаете AI-агента для кодинга, идете пить кофе, а он молча сжигает ваш SSD. Это не фантастика — это реальный инцидент с агентом на базе OpenAI Codex, который вскрылся в феврале 2026 года. Итог? Один агент генерировал 640 терабайт записи в год. Цифра, от которой у любого DevOps дергается глаз.
Как агент превратил логи в «писающего мальчика»
Всё началось с безобидной фичи: разработчики добавили в агента детальное логирование через OpenTelemetry. Каждый вызов инструмента, каждый шаг размышлений, каждая ошибка — всё попадало в TRACE-логи. Звучит разумно? В теории — да. На практике — ночной кошмар для NAND-памяти.
Суть бага: AI-агент совершал сотни вызовов в секунду (вызов функций, чтение файлов, запросы к LLM). Каждый вызов порождал 2-3 строчки TRACE-логов. Логи писались в локальный SQLite через стандартный драйвер Python. И тут начинается веселье.
SQLite при каждой вставке делает commit — даже если вы не просили. А commit означает перезапись WAL-файла. Это классический write amplification: один байт данных превращается в 50 байт записи на диск. Агент работал 24/7. Через неделю SSD показал 2 TBW (Total Bytes Written) — при том, что полезных данных было всего 40 ГБ. Экстраполяция дала те самые 640 ТБ/год. Для среднего NVMe с ресурсом 300 TBW это означало смерть диска за полгода.
Разбор анатомии: почему так вышло
Проблема сложилась из четырех китов:
- TRACE-уровень без контроля — OpenTelemetry по умолчанию пишет всё. В агенте не было фильтрации: даже успешные вызовы кэша уходили в лог.
- Синхронная запись — каждый span вызывал блокирующий write() в SQLite. При 500 вызовах/сек — 500 fsync в секунду. Гроб для SSD.
- Отсутствие ротации — база росла бесконечно. SQLite при переполнении страниц делал vacuum, который еще сильнее нагружал диск.
- Журналирование самого агента — кроме трейсов, Codex писал свои логи (промпты, ответы, стеки) в отдельный файл. И это тоже было без ограничений.
Похожие проблемы с доверием к AI-агентам уже освещались: Claude Code случайно удалил продакшн, а AI-агент атаковал разработчика на GitHub. Но там были другие механизмы — здесь же банальная неоптимальная конфигурация.
Как это исправить (с кровью и потом)
Команда разработчиков потратила две недели на рефакторинг. Вот что сработало.
1 Буферизация и асинхронность
Вместо прямой записи в SQLite — очередь в памяти (на базе collections.deque или asyncio.Queue). Сброс на диск раз в 5 секунд или при достижении 10 000 событий. Это снизило количество fsync с 500 до 1-2 в секунду.
2 Уровни логирования с умолчанием WARN
TRACE-логи теперь включаются только при явном флаге --debug-trace. В продакшене — WARN и выше. Фильтрация на уровне сэмплера: 1 из 1000 вызовов попадает в лог, если не ошибка.
3 Ротация и лимиты
Внедрили RotatingFileHandler для файловых логов (макс 10 файлов по 50 МБ). Для SQLite — автоудаление записей старше 24 часов через background job. Размер базы не превышает 100 МБ.
4 Мониторинг записи
Добавили метрики: disk.write_bytes и предупреждение при превышении 10 ГБ/сутки. Интегрировали с Grafana — теперь инженеры видят аномалии до того, как SSD скажет «прощай».
Долгий хвост: что еще пошло не так
Баг Codex — не единичный случай. Недавно хакеры взламывали Copilot через один клик, а атака на Claude через MCP показала, как уязвимости в агентском стеке превращаются в инструмент кибершпионажа. Но здесь история другая — не злой хакер, а собственная безалаберность.
Разработчики AI-агентов часто фокусируются на качестве ответов, забывая о инфраструктуре. А зря. Один лишний console.log внутри цикла — и ваш MacBook начинает таять. Вспомните историю с ClawdBot — тот случай показал, что промпт может украсть пароли. Здесь же «украденным» оказался ресурс диска.
Особенно остро проблема стоит для агентов, работающих в автоматическом режиме. Как безопасно запускать кодинг-агентов, мы разбирали в отдельной статье — включая режим YOLO, который отключает любые предупреждения. И именно в таком режиме баг с логами проявил себя максимально агрессивно.
Неочевидный совет: проверьте свои `docker-compose`
Многие разработчики запускают AI-агентов в Docker. И там есть подводный камень: по умолчанию контейнер пишет логи в stdout/stderr, которые Docker-демон сливает в JSON-файлы на хост-системе. Без ограничений размера эти файлы тоже могут убить SSD. Добавьте logging: driver: json-file, options: { max-size: "10m", max-file: "3" } — и спите спокойно.
Проблема write amplification будет только расти с появлением автономных AI-агентов, которые работают 24/7. Каждая микросекунда задержки на запись — это не просто цифры, это ресурс диска. И если вы еще не внедрили буферизованное асинхронное логирование — сделайте это сегодня. Завтра может быть поздно.
