Как Anthropic построила Scion и перенесла монорепозиторий за пять месяцев.
Nick G. и команда source controlКонспект · 8 минутОригинал · ~22 минуты
Главный тезис
Если почти все клиенты постоянно онлайн, контроль версий можно строить как сервис запросов и неизменяемых объектов. Тогда агентам не нужна локальная копия истории, а многим задачам — даже рабочая директория.
История main приблизилась к 100 ГБ, сжатая рабочая копия превысила 25 ГБ. При наивном получении 25 миллионов копий для CI трафик превысил бы 600 ПБ в день. Это оценка гипотетического трафика, а не объём фактической передачи.
Рост числа принятых изменений: 30 401 за 9 сентября 2026 года; чёрная линия — среднее за семь дней. Источник ↗
Shallow clone, sparse checkout, promisor remotes, зеркала и снимки в blob-хранилище уже использовались. На пике работало несколько сотен зеркал. Но снимки всё сильнее отставали от main, а история и blame на частичных клонах требовали всё больше усилий.
Прежняя схема Git: кэш packfile, реплики зеркал и периодические снимки репозитория. Источник ↗
Git даёт каждому клону автономность. Anthropic фактически использовала централизованный источник истины, а её агенты и задания всё равно работали онлайн. Scion построили вокруг этих условий.
Клиент рассчитывает на доступность сервера и запрашивает данные по мере необходимости. Автономность полноценного Git-клона не входит в эту модель.
2 · Сервер и клиент несимметричны
Сервер создаёт изменения, вычисляет историю и выполняет merge и rebase. Клиент раскладывает файлы, отслеживает изменения файловой системы и управляет локальным кэшем.
3 · Все запросы доступны через API
Инструменты bisect и revert могут спрашивать о связях коммитов и строках напрямую. Для многих операций локальный репозиторий не нужен.
4 · Каждый компонент масштабируется
Данные распределены; полной материализованной копии репозитория нет даже на сервере. Packfile отсутствуют, обслуживать их не требуется.
5 · Коммит стоит пропорционально изменению
Создание changeset не требует блокировок и общей координации серверов. Refs — указатели веток и тегов — используют ограниченно, чтобы не множить глобальное состояние.
6 · Рабочая копия необязательна
Sparse checkout получает выбранные директории. Виртуализированный checkout создаёт файлы при обращении. Часть чтений и записей обходится одним API.
Changeset — запись в журнале предварительной записи, или WAL. Она содержит изменённые файлы относительно первого родителя и ссылки по хэшу на сжатое содержимое. В Git коммит ссылается на дерево; в Scion дерево выводится из изменений.
Changeset хранит метаданные и изменённые файлы; дерево вычисляет сервер, содержимое файлов хранится отдельно. Источник ↗
Метаданные находятся в Spanner, содержимое файлов — в облачном blob-хранилище. Создание changeset отделено от перемещения refs: указатель обновляется операцией compare-and-swap в одной строке Spanner.
Для быстрых запросов сервер строит производные структуры: blame, историю путей, skip list для графа коммитов, индексы поиска копий и файлов. Значение для changeset рекурсивно вычисляется из значений его родителей.
Вычислять сразу или по запросу
Для каждого вида производных данных выбирают eager или lazy вычисление. Это позволяет не строить то, что никто не читает.
Менять структуру без обновления клиента
Клиент не видит внутреннее устройство индексов. Сервер может добавлять и оптимизировать их по мере роста нагрузки.
Протокол scn не перечисляет серверу всё, что уже есть у клиента. Клиент начинает с корневого дерева, сам находит отсутствующие деревья и blobs, затем запрашивает их по идентификаторам.
Scion разделяет управляющие запросы и получение объектов: daemon на узле → региональный cache → сервер и хранилища. Источник ↗
Каждый запрос относится к конкретному неизменяемому объекту. Любой кэш может ответить; загрузка возобновляется без повторной передачи единого многогигабайтного packfile. Для sparse checkout достаточно не запрашивать ненужные деревья.
На узле задания делят кэш scion-daemon. Он стартует с периодического снимка и обращается к региональному scion-cache. При промахе тот запрашивает scion-server, который читает Spanner или Cloud Storage. Кэш отдаёт данные из памяти сразу в дисковом формате daemon, без вычисления разницы и delta compression.
Одинаковый RPC не означает произвольную топологию.
Все уровни поддерживают один протокол, но порядок обращений строго ограничен. Иначе отказ регионального кэша перенаправит нагрузку на основные серверы и может обрушить всю систему.
У каждого уровня доля попаданий в кэш превышает 99%. Серверы также кэшируют неизменяемые данные и при необходимости вычисляют производные структуры, сохраняя результат в Spanner.
Так авторы оценивают инфраструктуру Scion относительно прежних Git-зеркал. Это сравнение инфраструктурных затрат, а не всех операций.
25% CPU-мощности высвободилось в CI
Текст сообщает об ускорении checkout в CI и исследовательских заданиях на два порядка. График ниже показывает отдельные медианы с ускорением ×8,0 и ×8,8; методика, связывающая эти показатели, не раскрыта.
Медианное время операций Git и scn на монорепозитории Anthropic. Это внутренние измерения, не универсальный бенчмарк. Источник ↗
Выборка из графика: медианное время на внутреннем монорепозитории. Коэффициенты приведены как в источнике; они могут отличаться от деления округлённых значений.
Семь человек построили Scion, Antique и ещё около шести связанных систем, завершив миграцию за пять месяцев. Claude Mythos Preview и Claude Tag одновременно увеличивали поток кода и помогали построить инфраструктуру для него.
Число изменений в Scion и Antique по неделям. С января принято 12 257 изменений. Источник ↗
Указать правильный источник ответа
Агенты пытались найти момент слияния линейным чтением журнала коммитов, хотя ответ был в системе ревью. Инженеры останавливали подходы, нарушавшие архитектурные ограничения.
Не принимать каждое замечание ревью
Adversarial review помогало находить проблемы, но иногда порождало лишнюю защиту от доверенного сервиса. Люди оценивали замысел каждого изменения и удерживали сложность под контролем.
Использовать скорость для проверки
Команда создала герметичные симуляции нетривиальных взаимодействий, fuzzing и ограничение нагрузки. Переписанный Claude прототип загрузки Git → Scion потреблял в 20 раз меньше памяти и работал в 4 раза быстрее.
Наблюдать за отдельными компонентами
Агенты «superfans» следят за телеметрией daemon, cache и очереди Antique в выделенных Slack-каналах. Они дополняют обычные оповещения поиском новых и малозаметных отклонений.
Права доступа задаются и на уровне репозитория, и на уровне директорий. Правила ревью различают, например, изменения комментариев и чувствительную логику, чтобы сосредоточить внимание людей на последствиях.
CI тоже пришлось пересмотреть.
Пока идут тесты, в main могут попасть сотни или тысячи изменений. Вместо глобальной блокировки очереди команда вложилась в автоматические проверки после слияния и перед развёртыванием. Это допускает конфликты параллельных изменений; по словам авторов, Claude обычно быстро их исправляет.
Scion рассчитан на огромные монорепозитории с десятками тысяч разработчиков или множеством активно пишущих агентов. Для большинства репозиториев авторы считают распределённую модель Git подходящей.
Стоимость миграции — весь цикл разработки
Scion существенно расходится с Git. Нужны собственные ревью, поиск и CI; внутренние инструменты Anthropic слишком специализированы для простой передачи другим компаниям.
Ресурсы Anthropic нетипичны
Компания может расходовать на внутренние задачи намного больше токенов, чем большинство организаций готовы оплачивать. Результат нельзя переносить без учёта этого условия.
Авторы предлагают переносить удачные идеи в Git: развивать серверные API, менять серверную архитектуру независимо от клиента, улучшать согласованную работу sparse и shallow режимов и пересматривать negotiation — протокол согласования передачи объектов. Прогноз о распространении подобных проблем за 6–12 месяцев остаётся прогнозом авторов.
Практические шаги по мотивам статьи. Это рекомендации конспекта, а не план миграции, предложенный авторами.
✓
Измерьте издержки получения кода. Соберите число checkout, объём трафика, время обновления зеркал и CPU на обслуживание репозитория. Сопоставьте это со временем выполнения самих заданий. Основание ↗
✓
Уберите checkout из задач, которым нужны метаданные. Найдите задания, которые получают репозиторий только ради diff, blame или ancestry. Проверьте возможность отвечать через серверный API. Основание ↗
✓
Испытайте общий кэш неизменяемых объектов. Начните с узла или региона. Измеряйте cache hit rate и нагрузку при промахах; заранее проверьте отказ регионального уровня. Основание ↗
✓
Запишите ограничения для агентов и ревьюеров. Укажите источники истины и недопустимые алгоритмы, например линейное чтение истории в горячем пути. Проверяйте замысел и стоимость изменения. Основание ↗
✓
Проверьте гонки между CI и слияниями. Смоделируйте параллельные изменения, задайте условия проверок после merge и до deploy и порядок восстановления. Не переносите риск конфликтов молча. Основание ↗
Content addressing — обращение к объекту по хэшу содержимого. Blame — история авторства строк. Derived data — вычисляемые структуры для быстрых запросов. Refs — изменяемые указатели на коммиты.
Все шесть иллюстраций взяты из статьи. Данные и оценки принадлежат Anthropic; независимая проверка результатов в источнике не приведена.
