9 февраля этого года, глубокой ночью по пекинскому времени, десятки миллионов разработчиков по всему миру открыли GitHub и увидели одну и ту же страницу.
Не 404, но она вызывала больше беспокойства, чем 404 — это была жёлтая предупреждающая полоса, от которой у всех инженеров пробегал холодок по спине, а также множество индикаторов на странице статуса, сменивших цвет с зелёного на красный.
github.com не работает.
API не работает.
GitHub Actions не работает.
Git-операции не работают — даже Copilot не уцелел.
В ту ночь у кого-то конвейеры CI/CD остановились на самом критическом этапе, чьё-то автоматическое развертывание зависло на полпути, а кто-то ждал PR, который никак не мог быть смержен — за этим стояла функция, ожидающая выхода, а за ней — реальные пользователи.
Позже GitHub опубликовал отчёт об инциденте. Первопричина, говоря техническим языком, — «перегрузка кластера критически важной базы данных, отвечающей за аутентификацию и управление пользователями». Но за этими словами скрывалась ужасающая цепочка событий —
За два дня до этого инженерная команда, чтобы быстрее доставить пользователям новую модель, изменила время обновления «кэша пользовательских настроек» с 12 часов на 2 часа. Всё из-за изменения всего одной конфигурационной цифры.
В итоге, перезапись кэша, которая ранее распределялась на 12 часов, оказалась сжата в 2 часа, создав интенсивную «бурю перезаписи кэша». Асинхронные очереди задач были мгновенно перегружены, общие инфраструктурные компоненты рухнули, каскадный эффект распространился на службу, отвечающую за проксирование HTTPS Git-операций, и в конечном итоге привёл к исчерпанию всех соединений платформы.
Одна цифра, с 12 на 2.
GitHub был пробит собственным изменением конфигурации.
Но если вы увидели только это изменение конфигурации, то, вероятно, упустили самую важную часть этой истории.
01 Не единичный случай, а десять
Инцидент 9 февраля не был изолированным событием.
Фактически, за первые три месяца 2026 года GitHub пережил как минимум 8 серьёзных инцидентов. Только в феврале было зафиксировано 37 сбоев разной степени серьёзности. Технический директор GitHub Владислав Фёдоров позже признал в блоге, что за эти два месяца GitHub не смог поддерживать обещанную корпоративным клиентам «три девятки» доступности — 99,9%.
Изучая архив сбоев за эти два месяца, можно заметить любопытную закономерность: каждый инцидент, казалось бы, имел разную причину.
2 февраля: Проблемы у поставщика вычислений Azure, GitHub Actions простаивал почти 4 часа, пострадали агент кодирования Copilot, CodeQL, Dependabot.
9 февраля: Буря перезаписи кэша, перегрузка базы данных аутентификации.
5 марта: Сбой кластера Redis, 95% рабочих процессов GitHub Actions не могли запуститься в течение 5 минут, средняя задержка — 30 минут.
18 марта: Задержки вебхуков взлетели до 32 раз от нормального уровня.
Каждый раз казалось, что это «несчастный случай», каждый раз непосредственная причина была разной. Но объяснение Фёдорова связало их в одну историю. Он сказал, что за этими инцидентами стоят три общие структурные причины: «быстрый рост нагрузки, сильная связанность сервисов, приводящая к распространению локальных сбоев, и отсутствие в системе способности защищать трафик от аномальных клиентов».
Говоря языком инженеров, фундамент GitHub начал трескаться под тяжестью новой нагрузки.
И у этой «новой нагрузки» есть конкретное имя.
02 275 миллионов коммитов в неделю
Ключевые данные
Общее количество коммитов за 2025 год: примерно 1 миллиард
Количество коммитов за неделю в 2026 году: 275 миллионов
При такой скорости, прогноз на весь 2026 год: 14 миллиардов (рост в 14 раз)
Объём вычислений GitHub Actions: 2023 год — 500 млн минут в неделю → 2025 год — 1 млрд → начало 2026 года, какая-то неделя — 2,1 млрд минут
Если бы вы были инженером по инфраструктуре GitHub, сравнение мониторинговых дашбордов за 2025 и 2026 годы, вероятно, поразило бы вас.
За весь 2025 год GitHub обработал около 1 миллиарда коммитов. Это само по себе огромная цифра, результат многолетнего накопления платформы GitHub. Но к 2026 году еженедельное количество коммитов достигло 275 миллионов. Если пересчитать — если эта скорость сохранится в течение всего года, общее количество коммитов в 2026 году приблизится к 14 миллиардам, что в целых 14 раз больше, чем за весь 2025 год.
Это не плавная кривая роста, а крутой подъём. Изменение объёма вычислений GitHub Actions лучше иллюстрирует проблему: в 2023 году еженедельно потреблялось 500 миллионов минут, в 2025 году удвоилось до 1 миллиарда, а затем в одну из недель начала 2026 года подскочило до 2,1 миллиарда минут.
Что так бешено коммитит код?
Не люди-разработчики.
Данные GitHub показывают, что ИИ-агенты становятся самыми активными «пользователями» на этой платформе. Один только инструмент Claude Code сейчас отвечает за 4,5% всех коммитов в публичных репозиториях GitHub. 2,6 миллиона коммитов в неделю, тогда как в конце сентября 2025 года эта цифра составляла всего 100 000 — рост в 25 раз за три месяца.
Количество PR, создаваемых ИИ-агентами, также взрывно растёт. В сентябре 2025 года ИИ генерировал около 4 миллионов PR в месяц, а к марту 2026 года эта цифра подскочила до 17 миллионов — более чем в 4 раза за полгода.
Есть картина, которая поможет понять, что это означает.
Раньше «пользователями» GitHub в основном были люди-программисты. Они работали днём, спали ночью, отдыхали на выходных, каждый раз думали, прежде чем сделать коммит, могли сомневаться, скорость их печати была ограничена. Нагрузка на систему следовала человеческому графику, имела пики и спады, её можно было прогнозировать.
Теперь всё больше «пользователей» — это ИИ-агенты. Они не спят, не отдыхают, не сомневаются, могут запускать несколько параллельных агентов для одной задачи, каждый агент за час легко делает больше коммитов, чем реальный инженер за неделю работы. Что ещё важнее, они не только коммитят код, но и постоянно создают новые репозитории — рассматривая репозиторий как «продукт вывода» рабочего процесса, а не как «рабочее пространство» человека.
Инженеры по инфраструктуре GitHub сталкиваются уже не с той же проблемой, только с большим трафиком, а с проблемой совершенно иной природы.
03 Денег Copilot уже не хватает
Участившиеся сбои — лишь одна сторона проблемы, у GitHub есть ещё одна головная боль — при подсчёте обнаруживается убыток.
Изначальная логика ценообразования Copilot основывалась на разумном предположении: пользователи в основном используют его как «инструмент автодополнения», каждое взаимодействие кратковременно, объём вычислений предсказуем. Персональная версия за 10 долларов в месяц, бизнес-версия за 19 долларов в месяц, оплата за место — эта модель хорошо работала последние несколько лет.
И вот пришёл агентный ИИ.
Агентные рабочие процессы и традиционное автодополнение — это два разных вида. Стандартное дополнение кода — запросы линейны, предсказуемы, циклы вычислений коротки. Агентная сессия кодирования может работать несколько часов, запуская несколько параллельных потоков, выполняя многошаговые рассуждения, самокоррекцию, рефакторинг между репозиториями — количество токенов, потребляемых за одну сессию, легко превышает месячную стоимость подписки обычного пользователя.
GitHub столкнулся с ситуацией, когда небольшое количество активных пользователей агентных сценариев за несколько долларов в месяц расходуют вычислительные ресурсы, эквивалентные сотням долларов.
Столкнувшись с этим, GitHub отреагировал напрямую — сначала ограничить поток, затем изменить цены.
С начала этого года GitHub ввёл для Copilot две параллельные системы ограничения: лимит на продолжительность сессии и еженедельный лимит использования, оба измеряются по объёму потреблённых токенов, умноженному на весовой коэффициент модели. В то же время регистрация новых пользователей для некоторых персональных тарифов Copilot была приостановлена.
1 июня GitHub завершил более фундаментальную реформу ценообразования: Copilot полностью перешёл на оплату по фактическому потреблению, заменив старые тарифные планы на «AI Credits», где 1 AI Credit равен 1 центу, а потребление рассчитывается в реальном времени по объёму использованных токенов.
Эпоха оплаты за место подошла к концу перед лицом агентного ИИ.
Этот переход — не только головная боль GitHub. Это коллективный кризис ценообразования, который переживает вся индустрия ИИ-инструментов в 2026 году — когда ИИ начинает заменять человека в выполнении полных рабочих процессов, а не просто «помогать» человеку, вся логика подписки по принципу «столько-то в месяц с человека» перестаёт работать.
04 В 30 раз, а не в 10
Возвращаясь к инфраструктурной проблеме. Как же GitHub планирует справиться с этим «ростом в 14 раз»?
Есть одна деталь, которая показывает серьёзность проблемы:
В конце декабря 2025 года агентные рабочие процессы внезапно начали ускоряться. Инженеры GitHub осознали, что роста в 10 раз недостаточно. К февралю 2026 года, уже после того серьёзного простоя, GitHub объявил, что необходимо перепроектировать архитектуру, исходя из масштаба в 30 раз больше сегодняшнего.
Не масштабирование, а перепроектирование.
Разница между этими двумя словами велика. Масштабирование — это увеличение количества существующих машин, добавление памяти к существующим базам данных — направление то же, просто масштаб больше. Перепроектирование означает, что текущие архитектурные допущения системно перестанут работать при 30-кратном масштабе, необходимо заново продумать способы разделения сервисов, потоки данных, изоляцию сбоев с самого низа.
Раскрытые GitHub конкретные направления включают разделение критических сервисов для предотвращения каскадных отказов, внедрение механизмов обратного давления и возможности снижения нагрузки, выделение отдельных хостов для горячих сервисов, устранение единых точек отказа, а также более совершенное управление изменениями — чтобы избежать внедрения таких операций, как «изменение TTL кэша с 12 часов на 2 часа», без достаточного нагрузочного тестирования.
Стоит отметить, что GitHub не одинок.
Stripe уже столкнулась с проблемой массового создания аккаунтов ИИ-агентами, AWS строит системы идентификации, логирования и контроля производства, предназначенные специально для агентов. Эти действия — не подготовка к будущему, а реакция на сигналы на мониторинговых дашбордах, которые уже требуют решения.
GitHub просто оказался первым, кого пробили — потому что он находится в самом ядре ИИ-инструментария.
05 Репозиторий кода превращается в выхлопную трубу ИИ
Остановимся и подумаем о сути всего этого.
Что такое GitHub? Самый простой ответ — это место, где программисты хранят код. Но на более глубоком уровне это инфраструктура для совместной работы людей над программным обеспечением — история коммитов это следы сотрудничества, PR — контейнеры для обсуждений, Issues — сохранённые намерения, Action — каналы выполнения. Вся эта система была разработана под человеческий рабочий ритм, образ мышления и модель взаимодействия.
ИИ-агенты меняют всё это.
Когда ИИ-агент может делать сотни коммитов в день, и за каждым «коммитом» нет человеческих размышлений и взвешиваний, а лишь шаг выполнения в цикле задачи — остаётся ли репозиторий кода «контейнером для совместной работы»?
Когда ИИ-инструменты автоматически генерируют репозитории, автоматически создают PR, автоматически запускают CI, автоматически мержат — остаются ли разработчики субъектами этого процесса или они деградировали до «рецензентов» или даже «наблюдателей»?
Технический директор GitHub, описывая этот кризис, использовал слова «быстрый рост нагрузки». Но эти слова, вероятно, недооценивают суть проблемы — это не только количественный рост, это качественное изменение способа использования. По старой модели GitHub был «инструментом разработчика»; по новой модели GitHub превращается в «выхлопную трубу ИИ», канал вывода для автоматизированных рабочих процессов.
Что это означает для GitHub, на самом деле пока нет ответа. Увеличение в 30 раз решит проблему с трафиком, но не решит переопределение бизнес-модели и не даст ответа на вопрос идентичности «кто мой настоящий пользователь».
В последнее время наблюдается весьма показательное явление: после простоя GitHub открыл множество инженерных блогов, очень подробно описывающих первопричину каждого инцидента, достигнув почти неожиданной степени прозрачности. Некоторые считают, что GitHub активно строит доверие, другие — что он обменивается прозрачностью на терпение сообщества разработчиков — потому что в предстоящий период рефакторинга будет ещё больше нестабильности.
Платформа, пробитая собственным успехом, должна разобрать и перестроить себя — и сам этот процесс также является испытанием на прочность.
В ту ночь 9 февраля тот инженер, ждавший мержа PR, вероятно, всё же дождался зелёного света. Но он, возможно, не осознал, что простой, заставивший его ждать, был не случайностью для GitHub, а громким сигналом о вступлении всей индустрии разработки программного обеспечения в новую эпоху.
Статья из WeChat Official Account «极客公园» (ID:geekpark), автор: 宇航猿
