Git-инфраструктура под нагрузку от AI-агентов
GitHub перестраивает архитектуру хранения репозиториев. Причина — не рост числа разработчиков, а нагрузка от AI-агентов, которые коммитят и пушат на порядки чаще людей. Инженер команды Git-инфраструктуры GitHub Брайан Селенза рассказал о масштабе проблемы и принципах нового дизайна 6 октября 2026 года.
Краткий ответ
Флоты AI-агентов создают write throughput, который текущая архитектура GitHub не тянет: пуши выросли в 4,9 раза за год. GitHub разделяет хранение и вычисления — авторитетные данные репозитория переезжают в Azure Blob Storage, а чтение и запись масштабируются независимо друг от друга. Для платформенных команд это повод проверить собственный Git-стек на похожую нагрузку от CI и агентов.
Насколько выросла нагрузка на Git
Цифры из поста показывают масштаб сдвига. Между сентябрём 2025 и августом 2026 общая Git-активность на GitHub выросла более чем вдвое: с 218,2 млрд событий в месяц до 473,3 млрд. В сентябре 2026 разработчики и агенты сделали 7,38 млрд коммитов — в пять раз больше, чем годом ранее.
Пуши выросли в 4,9 раза год к году: с 0,69 млрд до 3,35 млрд в месяц. GitHub Actions отработал 3,26 млрд раз в сентябре — в четыре раза больше, чем год назад. Количество слияний pull request выросло почти вчетверо. Самый нагруженный репозиторий на GitHub получил около миллиарда запросов за август 2026 года.
За этими цифрами стоит простая механика: человек делает несколько коммитов в день, агент в тесном цикле коммитит или делает checkpoint почти после каждого действия. При тысячах агентов, работающих в одном репозитории, это превращается в устойчивый поток записи, который сходится в одну точку архитектуры.
Где текущая архитектура GitHub упирается в потолок
Сегодня каждый репозиторий хранится в системе Spokes: полные копии на локальных дисках нескольких файл-серверов, по умолчанию пяти. Трёхфазный протокол коммита через кворум гарантирует, что CI, веб-интерфейс и API видят одно и то же состояние репозитория.
Проблема в том, что механизм надёжности и механизм масштабирования — одно и то же. Каждая реплика участвует в каждой записи, поэтому добавление читающей реплики замедляет пуши. Потеря реплики снижает читающую ёмкость, а потеря кворума останавливает запись полностью. Для большинства репозиториев такой компромисс работает. При агентной нагрузке он превращается в потолок.
Ещё одна точка давления — слияния на один ref. Trunk-based development, release trains и merge queues сводят всю работу к одной ветке, которая должна поглощать каждый merge. При тысячах агентов это уже не очередь, а затор.
Что меняется в архитектуре: хранение отдельно от вычислений
GitHub перестраивает систему вокруг трёх принципов. Первый — минимизация координации: единственное, что реально требует согласования при пуше, — обновление ссылки. Хранение объектов, проверка связности и secret scanning могут идти параллельно другим записям, поэтому критический путь пуша сужается до минимального шага.
Второй принцип — разделение хранения и вычислений. Авторитетная копия репозитория переезжает в Azure Blob Storage, который уже обеспечивает надёжность и репликацию на своём уровне. Поверх него работают лёгкие вычислительные воркеры с кешем для обслуживания запросов. Читающая ёмкость растёт без добавления новых durable-копий, а значит — без замедления записи. Потеря воркера становится ближе к cache miss: замена стартует сразу и заполняет кеш из хранилища по мере поступления трафика.
Третий принцип — вынос обслуживания с serving path. Компакция и сборка мусора сейчас идут на тех же хостах, что отвечают на живые Git-запросы. В новой схеме этим занимаются отдельные воркеры, работающие напрямую с хранилищем, поэтому тяжёлое обслуживание больше не замедляет пуши и фетчи.
Что это значит для платформенных команд
Для команд, которые эксплуатируют собственный Git-хостинг, история GitHub — повод свериться с реальностью. Если флоты агентов уже пишут в ваши репозитории или только начинают, стоит честно посмотреть на три вещи.
Первое — рост write throughput за последние 12 месяцев и наблюдаемость за merge queue latency: именно здесь агентная нагрузка проявляется раньше всего. Второе — поведение CI fan-out при параллельных агентных запусках, когда один пуш порождает тысячи чтений одной и той же ветки. Третье — архитектурная связка хранения и вычислений: если у вас, как и у GitHub до перестройки, каждая читающая реплика участвует в каждой записи, рост нагрузки от агентов рано или поздно упрётся в тот же потолок.
Это не повод переписывать инфраструктуру по примеру GitHub. Но проверить, где в вашем стеке совпадает механизм надёжности и механизм масштабирования, стоит уже сейчас, пока нагрузка растёт линейно, а не скачками.
Security и контроль над машинным кодом
Security-аспект в посте не детализирован, но он неотделим от архитектуры. При тысячах агентов, пишущих в один репозиторий, branch protections, required reviews и audit logs перестают быть настройками по умолчанию и становятся инфраструктурным требованием. Селенза прямо называет это одним из принципов новой архитектуры: люди, которые владеют кодом, должны сохранять возможность проверить, понять и одобрить его, даже если агенты выполняют большую часть работы.
Для платформенной команды это означает, что валидация и отслеживание машинного кода перед merge — не опциональная практика, а базовое требование наравне с масштабированием записи.
Почему это важно
GitHub строит инфраструктуру для самых нагруженных репозиториев и поднимает планку для всех остальных: те же изменения получат и команда с тысячами агентов, и студент, открывающий первый pull request. Если нагрузка от агентов продолжит расти такими темпами, похоже, любая Git-архитектура, где хранение и вычисления жёстко связаны, рано или поздно столкнётся с похожим потолком.
Что дальше
Пост — первый в серии. GitHub обещает следующий материал с деталями будущей архитектуры и историей пути к ней, без указания конкретных дат. Перестройка идёт без maintenance window: платформа продолжает работать, пока меняется фундамент. Во внутренних бенчмарках, по словам GitHub, новая архитектура показала до 35-кратного роста write throughput — это собственные данные компании, независимого подтверждения цифры пока нет.
FAQ
Почему агенты создают принципиально другую нагрузку на Git?
Человек делает несколько коммитов в день. Агент в тесном цикле коммитит или делает checkpoint почти после каждого действия. При тысячах агентов в одном репозитории это превращается в устойчивый поток записи, который сходится в одну точку архитектуры и обнажает места, где координация была избыточной.
Что такое Spokes и почему GitHub от него уходит?
Spokes — текущая система хранения GitHub: полные копии репозитория на локальных дисках нескольких файл-серверов. Она хорошо работает для большинства репозиториев, но при агентной нагрузке упирается в потолок, потому что каждая читающая реплика участвует в каждой записи.
Как новая архитектура влияет на надёжность?
Разделение хранения и вычислений упрощает восстановление после сбоев. Потеря вычислительного воркера не означает потерю данных: замена стартует сразу и заполняет кеш из durable-хранилища. Авторитетным слоем становится Azure Blob Storage с собственной репликацией.
Что это значит для команд на self-hosted Git?
GitHub перестраивает свою инфраструктуру, но архитектурные принципы универсальны. Если платформа работает на GitLab, Gitea или Bitbucket Data Center, стоит проверить, как она справляется с ростом write throughput от CI и параллельных агентных запусков, особенно если команда начала внедрять AI-агентов в разработку.
Когда новая архитектура GitHub станет доступна?
GitHub не называет конкретных дат. Брайан Селенза пишет, что работа уже ведётся, а следующий пост серии раскроет детали архитектуры и путь к ней.