Создание инфраструктуры Git для разработки в масштабе агентных систем06.10.2026 23:57

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

Разработка программного обеспечения с помощью агентов ведёт к следующему архитектурному сдвигу. Когда разработчики и агенты одновременно работают в репозиториях, куда ежедневно поступают миллионы коммитов, такие нагрузки требуют иной архитектуры Git. Мы перестраиваем инфраструктуру Git на GitHub, чтобы справиться с ними. В этой статье рассказываем о требованиях, определяющих эту работу, и принципах проектирования, лежащих в её основе.

Самые интенсивные нагрузки сегодня показывают, под какой масштаб мы создаём инфраструктуру. Разрыв между типичным репозиторием и самыми загруженными гораздо больше, чем многие ожидают. Вот примерное распределение активности репозиториев на GitHub за август 2026 года:

На крайнем участке распределения активность репозиториев резко возрастает. В августе самый загруженный репозиторий на GitHub обработал примерно миллиард запросов.

Помимо самых интенсивных нагрузок, общий объём операций Git на GitHub тоже быстро растёт: с сентября 2025-го по август 2026 года он увеличился более чем в 2 раза — с 218,2 млрд до 473,3 млрд событий в месяц.

Только за сентябрь разработчики и агенты создали на GitHub 7,38 млрд коммитов — более чем в пять раз больше, чем годом ранее.

Репозитории на вершине этой кривой показывают передовой край разработки с агентами: крупные инженерные команды запускают интенсивные конвейеры CI, а рядом с ними работают растущие парки агентов. Поддержка таких команд требует инфраструктуры Git, способной длительно обрабатывать одновременные операции чтения и записи в масштабах, которых сегодня достигают лишь немногие репозитории. Мы серьёзно инвестируем в инфраструктуру Git, чтобы справиться с требованиями разработки ПО с помощью агентов и дать командам основу для самых амбициозных нагрузок.

Чтобы обеспечить такой масштаб, необходимо решить несколько архитектурных задач:

• Скорость коммитов становится ограничением для каждого агента. Агент, работающий в коротком цикле, создаёт коммит или контрольную точку почти после каждого действия. Его скорость зависит от того, насколько быстро завершается один push, поэтому задержка, которую человек даже не заметил бы, становится узким местом.
• Потребность в пропускной способности записи растёт на порядки. За год число push выросло в 4,9 раза — с 0,69 млрд до 3,35 млрд в месяц. Тысячи агентов, работающих в собственных ветках одного репозитория, создают постоянный поток записей, который сходится в одной точке нашей архитектуры.
• При слияниях возникает конкуренция за одну ссылку. Разработка на основе основной ветки, релизные циклы и очереди слияний направляют всю эту работу на одну ссылку, которой приходится обрабатывать каждое слияние. Число слияний pull request на GitHub выросло почти в 4 раза по сравнению с прошлым годом.
• Каждый push порождает тысячи операций чтения. Например, CI и сканирование кода клонируют или получают одну и ту же вершину ветки тысячи раз в минуту, поэтому такая лавина запросов должна обходиться дёшево. Только GitHub Actions запускался в сентябре 3,26 млрд раз — более чем в 4 раза чаще, чем год назад.
• Операции с репозиторием должны оставаться быстрыми. Чтобы поддерживать высокую скорость, мы постоянно уплотняем данные репозиториев и удаляем объекты, которые больше не нужны. Каждая новая запись добавляет работы, а по мере роста объёма затраты накапливаются.

Именно поэтому одних лишь быстрых клонов недостаточно. Масштабировать чтение сравнительно просто: добавить кэши и реплики, чтобы передавать те же данные большему числу клиентов. Масштабирование чтения крайне важно, но для таких нагрузок этого недостаточно. Запись масштабировать гораздо сложнее. Каждый push необходимо надёжно сохранить и сделать доступным для всех согласованно, прежде чем следующий агент или задача CI сможет на его основе продолжить работу.

Как нынешняя архитектура справляется с новыми требованиями

Нынешняя архитектура годами хорошо служила разработчикам. Каждый репозиторий хранится в Spokes — системе, которая держит полную копию на локальных дисках нескольких файловых серверов, обычно пяти. Благодаря быстрым локальным дискам операции Git могут с низкой задержкой считывать данные репозитория в исходном формате, а дополнительные копии обеспечивают резервирование и распределяют чтение между файловыми серверами. Когда push обновляет ссылку, протокол фиксации в три этапа использует кворум, чтобы CI, веб-интерфейс и клиенты API видели согласованное состояние репозитория. Такая архитектура сегодня обслуживает миллиард репозиториев.

Однако механизм, который мы используем для обеспечения надёжности, одновременно служит и механизмом масштабирования. Поскольку источником истины являются копии на дисках, увеличение ёмкости чтения требует добавления ещё одной надёжной реплики. Каждая реплика участвует в каждой операции записи, поэтому скорость push ограничена самой медленной репликой в наборе. В итоге добавление реплик для обработки нагрузки чтения замедляет запись.

Для большинства репозиториев такой компромисс работает хорошо. Но при максимальном уровне активности он становится ограничением: дополнительные реплики чтения увеличивают нагрузку на операции записи, потеря реплики снижает пропускную способность чтения, а потеря кворума полностью останавливает запись. Чтобы удовлетворить требования, связанные с агентами, нам нужно отделить надёжность хранения от масштабирования, не утратив привычные командам возможности.

Для самых загруженных — лучше для всех

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

Мы создаём систему для самых требовательных нагрузок на GitHub: корпоративной компании, выпускающей продукты в условиях строгих нормативных требований; команды, вносящей изменения в репозиторий, на основе которого собирается операционная система; организации, запускающей тысячи агентов на единой кодовой базе. Проектирование для таких масштабов поднимает планку для всех. И сопровождающий, проверяющий вклад добровольцев из разных часовых поясов, и студент, открывающий первый pull request, получат одну и ту же более быструю и надёжную основу.

Новая архитектура также должна сохранять механизмы контроля, которыми команды уже пользуются. Сопровождающему нужны правила защиты веток и обязательные проверки, чтобы непроверенное изменение никогда не попало в ветку по умолчанию. Команде безопасности необходимы журналы аудита и видимость репозитория для расследования подозрительных событий доступа. Дежурному инженеру нужны надёжная автоматизация и достаточная наблюдаемость, чтобы понять, почему не удалось развернуть приложение.

Чтобы платформа продолжала обслуживать всех и одновременно масштабировалась под самые интенсивные нагрузки, мы руководствуемся следующими принципами:

• Опирайтесь на привычные разработчикам процессы. Команды используют такие процессы, как создание веток, проверка, слияние и работа с историей, чтобы создавать, выпускать и контролировать ПО в больших масштабах. Наша новая инфраструктура рассчитана на поддержку тех же процессов при значительно более высокой активности.
• Надёжность — прежде всего. Каждое решение мы оцениваем с точки зрения надёжности, необходимой разработчикам и организациям. Уверенность в платформе позволяет инженерной организации создавать автоматизацию, выпускать продукты по графику, выполнять требования соответствия и понимать, какое ПО она создаёт. Эта работа существенно повысит пропускную способность и масштабируемость, укрепив уже существующую основу доверия.
• Сохраняйте контроль над кодом за людьми. Если система не помогает использующим её людям и организациям и не находится под их контролем, её не стоит создавать. По мере того как агенты берут на себя всё больше работы, владельцы кода по-прежнему могут проверять его, понимать и утверждать.

Наш подход

Мы создаём новую архитектуру GitHub, способную гораздо эффективнее масштабироваться. В основе нашего подхода лежат ключевые принципы проектирования распределённых систем, применённые к требованиям параллельной работы и масштабам разработки ПО с помощью агентов. Наша цель — поддержать дальнейшее развитие сообществ открытого исходного кода и компаний по всему миру, которые создают проекты с помощью Git и GitHub, сохранив и адаптировав связанные с ними функции и механизмы контроля к новым потребностям эпохи агентных систем.

Свести координацию к минимуму

Репозиторий, в который поступает много push, должен быстро принимать и публиковать обновления. Координация важна, когда она обеспечивает корректность, но её избыток ограничивает пропускную способность записи и может превратить загруженный репозиторий в узкое место. В нынешней архитектуре некоторые компоненты тесно связаны без необходимости, что мешает масштабировать чтение и запись без серьёзных компромиссов. Мы перепроектируем систему так, чтобы сохранить координацию, требуемую семантикой Git, а всем остальным операциям позволить выполняться независимо.

• Координировать только то, что требует согласования. Единственная часть push, которая действительно требует согласования, — обновление самой ссылки. Сохранение базовых объектов, проверка связности объектов и сканирование секретов требуют гораздо больше работы, но большую её часть можно выполнять параллельно с другими операциями записи. Это сокращает критический путь push до небольшого шага, которому необходимо согласование, поэтому остальная работа больше не задерживает подтверждение.
• Перенести обслуживание за пределы основного контура обработки запросов. Уплотнение данных и сборка мусора — одни из самых ресурсоёмких операций с репозиторием, и сегодня они выполняются на тех же хостах, которые обрабатывают текущие запросы Git. В новой архитектуре отдельные рабочие процессы выполняют обслуживание непосредственно в надёжном хранилище. Загруженный репозиторий можно постоянно оптимизировать в фоновом режиме, не замедляя push и fetch.

Отделить хранение от вычислений

Сегодня полные копии репозиториев на локальных дисках служат и надёжным хранилищем, и уровнем, обрабатывающим запросы Git. Разделив эти функции, мы сможем масштабировать каждую независимо.

• Масштабировать чтение без добавления надёжных копий. В новой архитектуре пропускную способность чтения обеспечивают лёгкие рабочие процессы, кэширующие данные для обработки запросов. Эталонная копия репозитория находится в расположенном ниже уровне надёжного хранения. Благодаря этому платформа может справляться с резкими всплесками чтения из-за массовых запросов CI, парков агентов и крупных операций клонирования, не увеличивая нагрузку на каждый push.
• Поручить каждому уровню одну задачу. Эталонные данные репозитория хранятся в Azure Blob Storage, который уже обеспечивает надёжность и репликацию в масштабах Azure. Вычислительный уровень оптимизирован для высокой пропускной способности при минимальной задержке.
• Быстрее восстанавливаться после сбоев. Когда хранение и вычисления связаны, потеря хоста снижает и пропускную способность, и надёжность, а восстановление требует заново собрать полную копию репозитория. Если же эти уровни разделены, потеря вычислительного рабочего процесса больше похожа на промах кэша: заменивший его процесс может сразу начать обслуживать запросы и наполнять кэш из надёжного хранилища по мере поступления трафика.
• Подстраивать ёмкость под нагрузку. Вычислительные рабочие процессы можно добавлять или удалять по мере изменения трафика, вместо того чтобы заранее выделять ресурсы под пиковую нагрузку. Репозиторий, переживающий всплеск активности — например, выпуск релиза или запуск новой группы агентов, — может получить дополнительные мощности на это время. Когда всплеск пройдёт, эти мощности будут освобождены.

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

Что дальше

Мы создаём архитектуру, рассчитанную на максимально высокие пропускную способность и надёжность. Чтение и запись масштабируются независимо, а система плавно восстанавливается после сбоев. Внутренние тесты показали, что пропускная способность записи может быть до 35 раз выше, а ёмкость чтения масштабируется независимо и подстраивается под потребности.

По мере того как автоматизированная разработка увеличивает частоту и параллельность изменений ПО, GitHub будет развивать свою основу, не жертвуя управлением и контролем, на которые рассчитывают команды. Мы уже закладываем этот фундамент. В следующей статье цикла мы подробнее расскажем о будущей архитектуре и о пути, который привёл нас к ней.

Автор

Брайан — ведущий инженер-программист. Он работает над системами хранения данных и основными сервисами, обеспечивающими все операции с репозиториями на GitHub.