Отказ GitHub, вызванный ростом трафика из-за ИИ и ошибкой конфигурации

9 февраля этого года, поздно ночью по пекинскому времени, миллионы разработчиков по всему миру открыли GitHub и увидели одну и ту же страницу.

Не 404, а что-то более тревожное — желтая предупреждающая полоса, от которой у всех инженеров мурашки по спине, плюс ряды индикаторов на странице статуса, постепенно меняющих цвет с зеленого на красный.

github.com недоступен.

API отключен.

GitHub Actions не работает.

Операции Git не работают — даже Copilot не смог этого избежать.

В ту ночь у кого-то конвейер CI/CD остановился на самом критическом этапе, у кого-то автоматическое развертывание застряло посреди процесса, а кто-то ждал, пока не будет объединен PR, который так и не мог быть принят — за всем этим стояла функция, ожидающая запуска, и реальные пользователи, ожидающие ее.

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

Два дня назад инженерная команда из-за желания как можно скорее запустить новую модель изменила время обновления «кэша настроек пользователя» с 12 часов на 2 часа. Именно это изменение одного числа в конфигурации.

В результате кэширование, которое обычно распределялось на 12 часов, было сжато в течение 2 часов, создав плотную «штормовую волну перезаписи кэша». Асинхронная очередь задач была мгновенно перегружена, компоненты общей инфраструктуры вышли из строя, цепная реакция распространилась на сервис, отвечающий за проксирование HTTPS-операций Git, и в конечном итоге привела к исчерпанию всех соединений на платформе.

Число изменено с 12 на 2.

GitHub был сломан собственным изменённым конфигурационным файлом.

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

Инцидент 9 февраля — это не изолированный случай.

На самом деле, в первые три месяца 2026 года GitHub пережил как минимум восемь крупных инцидентов. Только в феврале было зафиксировано 37 сбоев различной степени тяжести. Позже технический директор GitHub Влад Федоров признал в блоге, что за эти два месяца GitHub не смог обеспечить обещанную предприятиям-клиентам доступность «три девятки» — 99,9%.

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

2 февраля: сбой у поставщика вычислительных услуг Azure, GitHub Actions был недоступен почти 4 часа, затронуты Copilot, CodeQL и Dependabot.

9 февраля: шторм перезаписи кэша, перегрузка базы данных аутентификации.

5 марта: сбой кластера Redis, 95% рабочих процессов GitHub Actions не могли запуститься в течение 5 минут, средняя задержка составила 30 минут.

18 марта: задержка вебхука увеличилась в 32 раза по сравнению с нормальным уровнем.

Каждый инцидент выглядит как «несчастный случай», и каждое прямое причинное звено различно. Но объяснение Федорова связывает их в одну единую историю. Он утверждает, что за этими инцидентами стоят три общих структурных причины: «быстрый рост нагрузки, тесная связанность между сервисами, приводящая к распространению локальных сбоев, и отсутствие в системе защиты от трафика необычных клиентов».

С точки зрения инженера, фундамент GitHub уже начал трескаться под давлением новой нагрузки.

А у этой «новой нагрузки» есть конкретное название.

Ключевые данные

Общее количество коммитов за 2025 год: около 1 миллиарда

Количество коммитов за одну неделю в 2026 году: 275 миллионов

При текущем темпе прогнозируется на весь 2026 год: 14 миллиардов (рост на 14 раз в годовом исчислении)

Объем вычислений GitHub Actions: 5 миллиардов минут в неделю в 2023 году → 10 миллиардов в 2025 году → 21 миллиард минут в одну из недель в начале 2026 года

Если бы вы были инженером инфраструктуры GitHub, сравнение панелей мониторинга за 2025 и 2026 годы, вероятно, оставило бы вас в шоке.

В 2025 году GitHub обработал около 1 миллиарда коммитов кода. Это число само по себе огромно и является результатом многолетнего накопления на платформе GitHub. Однако в 2026 году объем коммитов за одну неделю достиг 275 миллионов. Пересчитаем — если эта скорость сохранится в течение всего года, общий объем коммитов в 2026 году приблизится к 14 миллиардам, что в 14 раз превышает показатель 2025 года.

Это не плавная кривая роста, а резкий подъем. Данные по вычислительным мощностям GitHub Actions лучше всего это иллюстрируют: в 2023 году еженедельно потреблялось 5 миллиардов минут, в 2025 году — удвоилось до 10 миллиардов, а в одну из недель в начале 2026 года — резко подскочило до 21 миллиарда минут.

Что за безумное отправление кода?

Не человеческий разработчик.

Данные GitHub показывают, что AI-агенты становятся самым активным «пользователем» на этой платформе. Только один инструмент — Claude Code — сейчас обеспечивает 4,5% всех публичных коммитов в репозиториях GitHub. Еженедельно — 2,6 миллиона коммитов, тогда как в конце сентября 2025 года этот показатель составлял всего 100 000 — рост в 25 раз за три месяца.

Количество PR, открытых с помощью ИИ, также взрывно растет. В сентябре 2025 года сгенерированные ИИ PR составляли около 4 миллионов в месяц, а к марту 2026 года это число выросло до 17 миллионов — более чем в четыре раза за полгода.

Есть изображение, которое поможет вам понять, что это значит.

Раньше «пользователями» GitHub в основном были человеческие программисты. Они работали днем, спали ночью, отдыхали по выходным, каждый коммит требовал размышлений, колебаний, а скорость ввода имела предел. Нагрузка на систему следовала графику человека — была пиковыми и низкими точками и могла быть предсказана.

Сегодня всё больше «пользователей» — это AI-агенты. Они не спят, не отдыхают и не колеблются; можно одновременно запустить несколько параллельных агентов для одной задачи, и каждый агент может отправлять больше кода за час, чем реальный инженер за неделю. Более того, они не просто отправляют код — они постоянно создают новые репозитории, рассматривая репозитории как «результаты рабочего процесса», а не как «рабочее пространство» для людей.

Инженеры по инфраструктуре GitHub столкнулись не с более масштабной версией той же проблемы, а с проблемой совершенно другого характера.

Частые сбои — это лишь одна сторона проблемы; у GitHub есть еще одна более серьезная проблема — при расчетах выясняется, что есть убытки.

Исходная логика ценообразования Copilot основывалась на разумном предположении: пользователи в основном используют сервис для вспомогательного автодополнения, при этом каждое взаимодействие кратковременно и вычислительные ресурсы предсказуемы. Модель с ценой 10 долларов США в месяц для личной версии и 19 долларов США в месяц для корпоративной версии, с оплатой за место, в течение нескольких лет работала успешно.

Затем появился агентный ИИ.

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

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

В ответ на эту ситуацию GitHub действовал прямо — сначала ограничил поток, затем изменил цену.

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

1 июня GitHub завершил более фундаментальную реформу ценообразования: Copilot полностью перешел на оплату по использованию, заменив прежние тарифные планы на «AI Credits» — 1 AI Credit равен 1 центу, а использование рассчитывается в реальном времени по расходу токенов.

Эпоха платы за место подошла к концу перед лицом агентного ИИ.

Это изменение — не только проблема GitHub. Это коллективный кризис ценообразования, который вся индустрия инструментов ИИ переживает в 2026 году — когда ИИ начинает заменять людей в выполнении полных рабочих процессов, а не просто «помогать» людям в работе, вся логика подписки «за человека в месяц» перестаёт работать.

Вернемся к проблеме инфраструктуры. Как именно GitHub планирует справиться с этим «14-кратным ростом»?

Здесь есть деталь, которая показывает серьезность проблемы:

В конце декабря 2025 года рабочие процессы Agentic внезапно начали ускоряться. Инженеры GitHub осознали, что десятикратного увеличения недостаточно. К февралю 2026 года, после того как произошел серьезный сбой, GitHub объявила, что необходимо перепроектировать архитектуру с учетом масштаба, в 30 раз превышающего текущий.

Не расширение, а полная переработка.

Разница между этими двумя терминами огромна. Масштабирование означает увеличение количества существующих серверов и добавление памяти к существующим базам данных — направление остается тем же, меняется только масштаб. Перепроектирование означает, что текущие архитектурные допущения системно перестанут работать при увеличении масштаба в 30 раз, и необходимо полностью пересмотреть подходы к разделению сервисов, потокам данных и изоляции сбоев на низком уровне.

Конкретные направления, раскрытые на GitHub, включают декомпозицию ключевых сервисов для предотвращения каскадных сбоев, внедрение механизмов обратной связи и способности снижения трафика, развертывание отдельных серверов для горячих сервисов, устранение единой точки отказа, а также более совершенное управление изменениями — избегая таких операций, как изменение TTL кэша с 12 часов на 2 часа без достаточного стресс-тестирования.

Стоит отметить, что GitHub не одинок.

Stripe уже столкнулась с проблемой массового создания аккаунтов с помощью AI Agent, AWS в настоящее время разрабатывает специализированную систему идентификации, систему логирования и механизмы контроля производства для агентов. Эти действия — не профилактические меры, а реакция на сигналы, уже появившиеся на мониторах наблюдения.

GitHub — это только первый, кто был проникнут — потому что он находится в самом центре цепочки инструментов ИИ.

Остановитесь и подумайте о природе всей этой ситуации.

Что такое GitHub? Самый наглядный ответ — это место, где программисты хранят свой код. Но глубже — это инфраструктура человеческой программной совместной работы: коммиты — это следы сотрудничества, PR — контейнеры для обсуждений, Issues — сохранение намерений, Actions — каналы выполнения. Вся система создана под ритм работы, мышление и модели сотрудничества людей.

AI-агент изменил всё.

Когда AI-агент может отправлять сотни коммитов в день, и за каждым «коммитом» нет человеческого размышления и взвешивания, а только шаг в цикле выполнения задачи — всё ещё является ли репозиторий кода «контейнером для сотрудничества»?

Когда инструменты ИИ автоматически создают репозитории, автоматически открывают PR, автоматически запускают CI и автоматически сливают — остаются ли разработчики основными участниками этого процесса, или они уже превратились в «рецензентов» или даже «зрителей»?

Генеральный директор GitHub при описании этого кризиса использовал термин «быстрый рост нагрузки». Однако этот термин, вероятно, недооценивает суть проблемы — это не просто увеличение объема, а качественное изменение способа использования. В старой модели GitHub был «инструментом для разработчиков»; в новой модели GitHub превращается в «выпускной канал для ИИ», канал вывода автоматизированных рабочих процессов.

Для GitHub это пока не имеет однозначного ответа. Увеличение масштаба в 30 раз может решить проблему трафика, но не решит переопределение бизнес-модели и вопрос «Кто мои настоящие пользователи».

Недавно наблюдалось довольно значимое явление: после простоя GitHub опубликовал множество инженерных блогов, подробно описав коренные причины каждой аварии, достигнув почти неожиданного уровня прозрачности. Некоторые считают, что GitHub сознательно строит доверие, другие полагают, что он обменивает прозрачность на терпение сообщества разработчиков — ведь в предстоящий период рефакторинга будет еще больше нестабильности.

Платформе, которая была прорвана собственным успехом, нужно разобрать себя и перестроить — а сам этот процесс также является испытанием на способность выдержать нагрузку.

В ту ночь 9 февраля инженер, ожидавший слияния PR, вероятно, в конце концов, получил зеленый свет. Но он, возможно, не осознавал, что этот сбой, из-за которого он ждал, был не случайностью GitHub, а звонком, объявившим о начале новой эры в индустрии разработки программного обеспечения.

Эта статья взята из официального аккаунта WeChat «Гик-парк» (ID: geekpark), автор: Юань Ханьюань