Сбои GitHub из разряда «ну бывает» превратились в системную проблему: за последние 12 месяцев платформа пережила сотни инцидентов, затронувших поиск, GitHub Actions и завязанные на них CI/CD-процессы. Для русскоязычных команд это важный сигнал: крупнейший хаб разработки больше не выглядит как невидимая коммунальная услуга, а значит, надежность внешней платформы снова становится предметом инженерного расчета, а не веры.
Об этом сообщает The New Stack со ссылкой на разговор с операционным директором GitHub Кайлом Дейглом, который также занимает должность CMO of Developer в Microsoft. По его словам, компания пытается не просто «пережить» период нестабильности, а вернуть доверие разработчиков за счет радикального пересмотра масштаба. Если раньше GitHub исходил из сценариев привычного облачного роста, то теперь ориентируется на систему, способную выдержать увеличение нагрузки в 30-40 раз уже в течение следующего года.
Причина у этой спешки довольно прозаическая: GitHub сам помог ускорить рынок AI-кодинга, а теперь расплачивается инфраструктурой. По данным компании, за весь 2025 год сервис обработал 1 млрд коммитов. Сейчас речь уже идет о 1,4 млрд коммитов в месяц. Отдельная метрика выглядит еще красноречивее: одни только агенты генерируют более 17 млн pull request в месяц. На таком фоне классическая логика «добавим еще машин и размажем нагрузку по горизонтали» перестает работать. Когда поток изменений начинает измеряться не ростом в проценты, а скачком в порядки, старые архитектурные компромиссы быстро выходят на сцену без грима.
Отсюда и главный тезис GitHub: проблема не сводится к нехватке железа. Компания продолжает переезд из собственного дата-центра в Azure, но сама подача показательная: дело не только в емкости, а в том, как устроены внутренние узлы платформы. GitHub пришлось разбираться с узкими местами в базах данных, пересматривать скрытые системные зависимости и переписывать те части платформы, которые годами работали в фоне и мало кого интересовали, пока не начали падать в прайм-тайм. Для бизнеса это знакомый сюжет: масштабирование часто ломается не в модных слоях продукта, а в старом добром фундаменте, который слишком долго считали достаточно прочным.
Часть этих работ GitHub уже раскрыл раньше через CTO Влада Федорова. Компания устранила конкуренцию за ресурсы в MySQL, полностью вынесла webhooks из MySQL, переработала session cache и потоки аутентификации, чтобы снизить давление на базу. Для GitHub Actions пришлось переписать механизм диспетчеризации задач на раннеры. Параллельно платформа меняет архитектурную изоляцию ключевых сервисов: идея в том, чтобы проблемы в одном контуре не валили остальные. В практическом переводе это означает, что Git, Actions и другие критичные компоненты должны реже тянуть друг друга на дно. Еще один штрих: чувствительный к производительности код GitHub постепенно переносит из Ruby-монолита в Go. Не самый романтичный разворот, зато очень в духе времени: меньше магии, больше предсказуемости под нагрузкой.
Здесь есть легкая ирония, от которой GitHub уже не отвертеться. Платформа одной из первых институционализировала AI-помощь разработчикам через Copilot и, по сути, научила рынок жить с постоянной генерацией кода. Теперь этот же рынок присылает обратно лавину коммитов, issue и pull request, а GitHub вынужден публично объяснять, почему базовая доступность стала новостью сама по себе. Для инженерных команд это полезное напоминание: любой сервис, который стимулирует кратный рост активности пользователей, обязан заранее переписывать собственную математику устойчивости. Иначе продуктовый успех быстро превращается в SRE-репутацию с трещинами.
На вопрос, почему GitHub продолжает выпускать новые функции, пока чинит стабильность, у компании тоже есть ответ. По версии Дейгла, не все продуктовые поверхности одинаково рискованны для базовой платформы. CLI и новое приложение Copilot можно развивать быстрее, потому что они не так тесно связаны с критическим контуром github.com. Иными словами, внешне GitHub все еще бежит спринт, а внутри команды инфраструктуры в это время таскают мешки с цементом. Аргумент логичный, хотя для пользователя он работает ровно до следующего сбоя: новые интерфейсы мало радуют, если встает Actions и у команды зависает релизное окно.
При этом важно, что GitHub не пытается замкнуть спасательную операцию только на себе. Дейгл прямо говорит об усиленной поддержке со стороны Microsoft, включая инженеров, которые уже масштабировали системы сопоставимого уровня. Это, пожалуй, одна из самых практичных деталей всей истории. Когда платформа выходит на режим, где рост измеряется уже не год к году, а относительно прежней архитектурной модели в десятки раз, культурой «разберемся силами своей команды» можно только красиво оформить постмортем.
Для разработчиков и IT-руководителей из России и СНГ эта история важна не только как хроника чужих проблем. Сбои GitHub бьют по пайплайнам, зеркалам репозиториев, скоростям ревью и SLA внутренних платформ, даже если сама команда давно живет в гибридном режиме и держит часть процессов локально. Чем глубже рынок входит в эпоху агентного кодинга, тем меньше смысл воспринимать GitHub как просто хостинг репозиториев. Это уже слой глобальной инженерной инфраструктуры, где надежность напрямую влияет на стоимость разработки, на темп поставки и на то, сколько ручных страховок компании готовы держать у себя.
Главный вопрос теперь не в том, сможет ли GitHub добавить еще серверов, а в том, успеет ли он превратить нынешний всплеск AI-нагрузки в новую устойчивую архитектуру раньше, чем разработчики начнут серьезнее инвестировать в обходные сценарии. Доверие к платформе возвращается медленнее, чем уезжают pull request, и в этом смысле ближайшие месяцы для GitHub будут проверкой не маркетинга, а инженерной дисциплины.