Инженер Авито Александр Моргунов опубликовал разбор миграции основного хранилища мессенджера с MongoDB на Apache Cassandra. Масштаб системы: 80 млрд сообщений, 9 млрд чатов, 6 млн активных пользователей в день. Работы заняли один квартал, выполнял их один архитектор, продакшн-код генерировали ИИ-агенты. Классическая оценка такой миграции силами инженеров: минимум один год работы специалистов высокой квалификации.
Ниже разбор опубликованного кейса. Это не отчёт о собственных тестах: цифры, этапы и выводы взяты из статьи автора и сопутствующих источников, ссылки стоят по тексту.
Что именно произошло: миграция мессенджера Авито с MongoDB на Cassandra
Мессенджер Авито сменил основное хранилище: вместо MongoDB данные обслуживает Apache Cassandra. Продуктовые команды продолжали выпускать фичи в обычном темпе, миграция шла параллельно. В продакшн не ушла ни одна строка кода, написанная человеком вручную.
Масштаб системы: 80 млрд сообщений, 9 млрд чатов, 6 млн DAU
В системе суммарно хранится 80 миллиардов сообщений и 9 миллиардов чатов при 6 миллионах пользователей DAU, которые ежедневно заходят в мессенджер, чтобы обсудить сделку, доставку или оплату товара.
Данные критичны для бизнеса: ошибка в переезде затрагивает цепочки доставки и оплаты, а часть переписки могла быть потеряна. Речь о хранилище, от которого зависит сделка между продавцом и покупателем, и цена ошибки здесь измеряется не в часах простоя, а в сорванных сделках и потерянных сообщениях.
Почему MongoDB стала проблемой: 600 репликасетов и 2400 инстансов
Репликасет (replica set) в MongoDB - группа узлов с одинаковыми данными, один из которых принимает запись. Фактор репликации 4 означает, что каждая запись хранится на четырёх узлах. Схема даёт отказоустойчивость и горизонтальное масштабирование: падение отдельного узла не останавливает чтение и запись.
Плата за надёжность оказалась высокой. Для мессенджера развернули 600 репликасетов с фактором репликации 4, что в абсолютных числах даёт 2400 инстансов MongoDB. Содержать и обслуживать такой кластер непомерно дорого: это тысячи машин, их мониторинг, обновления, репликация и дежурные команды.
Cassandra решает ту же задачу иначе. Данные распределяются по кольцу узлов, число копий задаётся фактором репликации на уровне keyspace, а мощность наращивают добавлением узлов. Для мессенджера с огромным потоком записей на запись такая модель обходится дешевле в эксплуатации. Конкретных цифр экономии автор кейса не приводит, поэтому считать Cassandra «в N раз дешевле» оснований нет.
Почему классическая оценка требовала года работы команды
Ручная миграция с Mongo на Cassandra с учётом огромного количества взаимосвязей, легаси-кода и продуктовых сценариев требовала минимум одного года работы инженеров высокой квалификации - так оценивает объём работ автор кейса.
Сложность создаёт поведение системы, а не перенос схемы. Различия в модели данных и гарантиях консистентности двух СУБД требуют отдельной проверки на каждом участке: где-то меняется порядок записей, где-то по-другому читаются данные при конкурирующих операциях. Каждое расхождение нужно найти, объяснить и закрыть проверкой, иначе оно всплывёт уже в продакшене.
Ограничения: нет команды, нет года, продукт нельзя останавливать
Отдельной выделенной команды под миграцию в компании не было. Остановить развитие продукта на год ради техдолга невозможно: продуктовые команды должны были выпускать новые функции в обычном темпе. Третий ограничитель - критичность данных: сбой в переезде бьёт по доставке, оплате и переписке пользователей.
Эти три условия делают выбор варианта вынужденным. Один архитектор плюс ИИ-агенты оказались конфигурацией, которая влезала в квартал без остановки продукта, и это решение диктовалось рамками, а не модой на агентов.
Как один архитектор и ИИ-агенты уложились в квартал
Фактический результат: квартал, один архитектор, ни одной строки продакшн-кода, написанной руками. Код генерировали ИИ-агенты.
Что делал архитектор, а что - агенты
Архитектор отвечал за декомпозицию задачи, формулировки, критерии корректности, разбор результатов и решение о выкатке. Агенты писали код, правили файлы, запускали тесты, работали с git.
Формулировка «не написал ни строчки кода» описывает тип работы, а не её объём. Основной режим сместился к постановке задач и верификации: чем больше кода производит агент, тем дороже проверить, что он делает именно то, что нужно. Этот эффект подробно разбирается в материале о том, почему разработка с ИИ-агентами стала тяжелее, а не легче: производство кода подешевело, а проверка результата подорожала и требует понимания того, что система обязана сохранять при замене компонентов.
Узким местом становится проектирование системы: без модели данных, контрактов и границ модулей агенту нечего исполнять корректно. Как превратить архитектурные схемы в задания для агента, разобрано в статье про проектирование вместо кода.
Claude Code как пример агентного инструмента
Кейс говорит об ИИ-агентах в целом. Пример такого класса инструментов - Claude Code, агент для программирования от Anthropic. Он работает прямо в терминале и IDE разработчика: читает весь проект, сам редактирует файлы, запускает тесты, работает с git и доводит задачу до результата, без копирования фрагментов кода в чат и обратно.
Условия доступа: активная подписка Claude Pro, Max, Team или Enterprise, либо аккаунт Claude Console, либо подключение через поддерживаемого облачного провайдера. Корпоративные пользователи могут подключиться через Amazon Bedrock, Google Cloud и Microsoft Foundry. Поверхности: терминал (CLI), расширения для VS Code и JetBrains, десктоп и веб. Все они используют один движок и общие файлы CLAUDE.md, настройки и MCP-серверы, поэтому переключение между поверхностями не ломает конфигурацию.
Важная оговорка: в источнике по кейсу Авито не указано, какие именно агенты применялись. Claude Code здесь приведён как представитель класса инструментов, а не как подтверждённый инструмент миграции. Как выглядит работа с таким агентом на реальном проекте, видно в кейсе про пет-проект на Java и оркестратор задач на Claude Code.
Градации доверия к ИИ: безусловное, обусловленное и авансированное
Автор кейса разделяет доверие к ИИ на три вида: безусловное, обусловленное и авансированное. Разница проявляется в момент, когда агент выдаёт результат.
- Безусловное доверие: сгенерированный код уходит в работу без проверки. Быстро и дешёво ровно до первого инцидента.
- Авансированное доверие: кредит выдан заранее, под репутацию модели. Доказательств пока нет, а решения уже принимаются на основе её вывода.
- Обусловленное доверие: объём доверия равен объёму доказательств. Агент получает больше свободы на участках, где проверка подтвердила корректность, и меньше там, где подтверждений нет.
Чем опасны безусловное и авансированное доверие
Оба режима копят скрытые дефекты. В миграции БД цена ошибки растёт вместе с объёмом данных: чем позже найден дефект, тем дороже откат и тем больше записей успело испортиться. Психологию сопротивления агентам и обратную крайность в виде слепой веры разбирает материал о том, почему часть разработчиков не хочет отдавать код ИИ-агентам.
Обусловленное доверие убирает обе крайности: агент работает автономно там, где есть чем подтвердить корректность, и останавливается на ревью там, где подтверждений нет.
Пять стадий принятия ИИ-агентов в разработке
В кейсе описаны пять стадий принятия ИИ в разработке: от тотального отрицания до системного кризиса доверия. Между ними есть и наивный оптимизм, стадия, когда агент кажется всемогущим и проверки выглядят лишней тратой времени.
Последовательность типичная. Сначала инженер не верит, что агент способен на что-то серьёзное. Затем пробует и удивляется скорости генерации. Дальше начинается самое дорогое.
Системный кризис доверия: код компилируется, тесты проходят, дефекты остаются
Кризис наступает, когда сгенерированный код компилируется и проходит тесты, но содержит критические дефекты - этот этап описан в кейсе. Зелёный прогон означает, что проверено только то, что вы решили проверять.
Причины три. Неполное покрытие тестами: проверены счастливые пути, краевые случаи остались за кадром. Разная семантика старого и нового хранилища: запрос, который был корректен для MongoDB, в Cassandra ведёт себя иначе. Общие предположения агента: тест, написанный тем же инструментом, что и код, часто воспроизводит ту же ошибку, потому что исходит из той же неверной модели задачи.
Кризис не повод отказаться от агентов. Это точка, в которой генерация перестаёт быть узким местом, а узким местом становится верификация.
«Лестница независимых доказательств»: как проверять код от ИИ
Ответ кейса на кризис - инженерный фреймворк «Лестница независимых доказательств» и «Пирамида зрелого доверия к ИИ». Смысл лестницы: каждый следующий уровень проверки независим от предыдущего и добавляет новое доказательство корректности. Тесты, написанные тем же агентом, что и код, дают слабое доказательство. Сверка с независимым источником данных даёт доказательство сильное.
Опубликованный текст кейса обрывается на описании рисков потери сообщений, поэтому детали реализации лестницы и пирамиды приведены в том объёме, в котором их раскрывает автор.
Шесть уровней корректности: от синтаксиса до продуктовых сценариев
Пирамида зрелого доверия к ИИ содержит шесть уровней корректности. Каждый отвечает на свой вопрос и ловит свой класс дефектов.
| Уровень | Что проверяет | Какие дефекты ловит |
|---|---|---|
| 1. Синтаксис | Код компилируется, линтеры проходят | Опечатки, несовместимые типы, битые импорты |
| 2. Локальные тесты | Юнит-тесты отдельных модулей | Ошибки в логике функции на типовых данных |
| 3. Интеграционные проверки | Связка с БД, очередями, внешними API | Нарушенные контракты, неверные конфигурации |
| 4. Дифференциальные сравнения данных | Одни и те же запросы к MongoDB и Cassandra, сверка результатов | Расхождения семантики, потерянные и искажённые записи |
| 5. Операционная безопасность | Нагрузка, отказоустойчивость, деградация, права доступа | Падения в пике, утечки, отказы при потере узла |
| 6. Продуктовые сценарии | Реальные пути пользователя: отправка сообщения, чат сделки, доставка | Формально верный код с неверным поведением для пользователя |
Практический смысл в порядке прохождения. Уровни снизу дешёвые и быстрые, уровни сверху дорогие, но именно они дают доказательства, которые нельзя получить автоматически. Пропускать нижние уровни нельзя: дифференциальная сверка бессмысленна, если сервис не собирается.
Дифференциальные сравнения данных как ключевой уровень
Четвёртый уровень заслуживает отдельного внимания. Идея: одни и те же запросы выполняются к старому и новому хранилищу, а результаты сравниваются - построчно или по агрегатам, если объём слишком велик для построчной сверки. Так ловятся расхождения семантики, невидимые для юнит-тестов.
Объём данных задаёт требования к проверке. При 80 млрд сообщений и 9 млрд чатов выборочная проверка на нескольких тысячах записей не даёт основания считать перенос полным. Поэтому сверку строят как постоянный процесс на период миграции: старый и новый контуры работают параллельно, а расхождения разбираются как инциденты, а не как статистический шум.
Ограничение у уровня тоже есть. Дифференциальное сравнение требует эталона: пока старое хранилище доступно на чтение и содержит актуальные данные, сверять есть с чем. После вывода MongoDB из эксплуатации этот источник доказательств исчезает, и проверять корректность становится сложнее.
Безопасность при работе с внешним ИИ: что нельзя отдавать агенту
В кейсе отдельно затронуты вопросы безопасности при работе с внешним ИИ и запрет на передачу сенситивных данных во внешний контур. Для хранилища с перепиской и платежами это базовое требование к архитектуре, а не бюрократическая формальность.
Где проходит граница внешнего контура
Внешний контур - любой сервис, который компания не контролирует: облачные API моделей, веб-интерфейсы, сторонние плагины и расширения к IDE. Даже локально установленный агент может обращаться к внешней модели, если так задана конфигурация, поэтому «инструмент стоит на моей машине» не означает «данные не уходят наружу».
Что относят к сенситивным данным в такой задаче: персональные данные пользователей, платёжная информация, внутренние ключи и токены, а также фрагменты продакшн-базы, попавшие в контекст. Схема подключения к боевому хранилищу, выгруженная в промпт, тоже утечка, даже если самих данных в ней нет.
Варианты снижения риска: локальные модели с открытыми весами на своём железе, корпоративные контуры с изолированным доступом, обезличивание данных перед отправкой, ограничение объёма контекста до необходимого минимума. У каждого варианта цена. Локальные модели требуют GPU, памяти и обслуживания. Обезличивание не всегда возможно без потери смысла задачи. Выбор зависит от того, что именно вы защищаете и насколько чувствителен контекст.
Что из этого кейса применимо к вашему проекту
Кейс описывает одну миграцию в одной компании с конкретными ограничениями. Копировать его как готовый рецепт рискованно: результат зависел от квалификации архитектора, зрелости процессов тестирования и возможности держать два хранилища параллельно.
Когда подход не сработает
Ситуации, где схема рискует: нет эталона для сравнения данных, нельзя запустить старое и новое хранилище параллельно, покрытие тестами слабое, отсутствует человек, способный верифицировать результат, команда не готова к тому, что ревью станет основным режимом работы. Без этих условий агенты ускоряют производство дефектов, а не разработку.
Условия воспроизводимости: эталонный источник данных для дифференциальных сравнений, период параллельной работы старого и нового контуров, культура доказательной верификации, архитектор с правом остановить выкатку. Отдельно стоит вложение в контекстную инфраструктуру: без знаний о системе агент работает вслепую. Как такая инфраструктура выглядит и почему она оказалась важнее самого агента, показано в истории про побочный продукт ИИ-агента.
Смежный контекст про организационную часть: по опросу Gartner среди 223 руководителей, отвечающих за данные и аналитику (март 2026 года), сопротивление изменениям на культурном уровне встречается как причина неудачи инициатив чаще ограничений финансирования: 60% против 40%. Технический фреймворк не компенсирует отсутствие готовности команды работать по новым правилам.
И главное ограничение: ответственность за продакшн не делегируется. Агент не приходит на разбор инцидента и не отвечает за потерянное сообщение. Отвечает тот, кто поставил задачу и принял результат.
Главные выводы кейса Авито
- Миграция критичного хранилища с 80 млрд сообщений и 9 млрд чатов выполнена за квартал силами одного архитектора и ИИ-агентов.
- Классическая оценка давала минимум год работы инженеров высокой квалификации, поэтому схема с агентом и одним архитектором была вынужденной, а не показной.
- «Ни строчки кода руками» не означает «ничего не делал»: работа сместилась к постановке задач, декомпозиции и верификации.
- Доверие к ИИ работает, когда оно обусловленное: объём свободы агента равен объёму доказательств его корректности.
- Зелёные тесты не гарантируют корректность; для миграций БД обязателен уровень дифференциальных сравнений данных с эталонным хранилищем.
- Сенситивные данные не должны уходить во внешний контур; локальные модели, корпоративные контуры и обезличивание снижают риск, но у каждого варианта своя цена.
Практический вопрос к своему проекту: какие из шести уровней корректности у вас уже закрыты, а какие пока принимаются на веру? Начинать разумно с уровня, который в вашей задаче ловит самый дорогой дефект. Для миграций БД это обычно сверка данных, для сервисов с платежами - сочетание операционной безопасности и продуктовых сценариев.