GitHub теряет доступность из-за AI-агентов: Microsoft вынуждена роутить трафик через AWS

Когда доступность GitHub в июне 2026 года упала до 88,4% — значительно ниже порога SLA в 99,9%, на который рассчитывают корпоративные клиенты — Microsoft приняла решение, казавшееся немыслимым ещё два года назад: начала роутить трафик GitHub через Amazon Web Services, своего главного конкурента в облачном рынке. Причиной стали не планы миграции и не оптимизация затрат. Причиной стали AI coding-агенты.

Что произошло

16 июня 2026 года Business Insider сообщил, что Microsoft добавляет мощности AWS к GitHub после того, как всплеск AI-разработки перегрузил платформу и спровоцировал серию сбоев. Представитель Microsoft подтвердил договорённость, заявив: «Невероятный рост agentic-разработки, начавшийся в конце прошлого года, вышел за пределы возможностей нашей инфраструктуры».

Цифры объясняют масштаб кризиса. Количество коммитов в GitHub шло к отметке 14 миллиардов в 2026 году — против 1 миллиарда в 2025-м. Еженедельные вычислительные минуты GitHub Actions выросли с 500 миллионов в 2023 году до 2,1 миллиарда за одну неделю в начале 2026-го. Pull request'ы, открытые AI-агентами, выросли с 4 миллионов в сентябре 2025 года до более чем 17 миллионов к марту 2026-го. В мае 2026 года платформа зафиксировала девять инцидентов, повлиявших на качество сервиса.

Сооснователь HashiCorp Митчелл Хашимото публично написал, что GitHub «больше не место для серьёзной работы, если он блокирует тебя на несколько часов в день». CTO GitHub сам признал в феврале и марте, что платформа нарушила обязательства по доступности в три девятки.

Изначально Microsoft планировала к 2027 году полностью перевести GitHub на Azure. Теперь скорость роста AI-спроса превысила способность Azure его поглотить — и Amazon заполнил образовавшуюся брешь.

Почему это важно для AI engineering-команд

По существу, эта история не о конкуренции Microsoft и Amazon. Она о том, что происходит, когда внедрение AI-агентов масштабируется быстрее, чем инфраструктура, призванная его поддерживать.

Большинство команд, запускающих Claude Code, Copilot, Cursor или собственные coding-агенты через GitHub Actions, построили свои CI/CD-пайплайны в расчёте на то, что GitHub — надёжная корпоративная платформа. Это допущение теперь публично опровергнуто — и в том масштабе, при котором даже Microsoft не удаётся справиться без мощностей конкурента.

Для команд, автоматизировавших развёртывание, тестирование или code-review поверх GitHub, последствия прямые:

• Риск нарушения SLA: Если production-пайплайн деплоя работает на GitHub Actions, показатель доступности 88,4% означает около 130 часов потенциального простоя в месяц — это значительно выше порога, приемлемого для критической инфраструктуры.
• Агенты усиливают нестабильность: Те же AI coding-агенты, что повышают продуктивность разработчиков, генерируют коммиты и PR-активность, перегрузившую платформу. Команды, запускающие несколько параллельных агентов против одного репозитория, вносят прямой вклад в нагрузку, вызвавшую эти сбои.
• Одноклаудный CI/CD теперь документально подтверждённый риск: Годами разговоры о multi-cloud велись применительно к роутингу AI-моделей. Кризис GitHub показывает, что этот принцип распространяется на каждый уровень AI-расширенного стека — включая репозиторий и инфраструктуру пайплайна.

Router/operator-угол

Последовательность сбоев GitHub несёт переносимый инженерный урок: любая зависимость от единственного провайдера в AI-стеке — это риск надёжности в масштабе агентов.

Когда разработчики пишут код вручную, объём коммитов ограничен рабочими часами людей. Когда AI-агенты автономно пишут, ревьюят код и открывают PR, объём ограничен API-квотами и пропускной способностью моделей. Команды, относящиеся к CI/CD-провайдеру так же, как к модельному провайдеру — без fallback — столкнутся с той же проблемой доступности, которую сейчас решает Microsoft.

Операторам, активно использующим GitHub Actions, стоит оценить следующее:

1. Fallback-пути для пайплайнов: Смогут ли ваши CI/CD-задачи запуститься на альтернативном runner (GitLab CI, Bitbucket Pipelines, self-hosted Actions runner, Buildkite) при деградации GitHub? Затраты на поддержание тёплого резерва теперь обоснованная статья бюджета.
2. Throttle-контроль для агентов: Параллельные PR от агентов суммируют нагрузку на платформу. Команды должны проверить логику диспетчеризации агентов: сколько агентов одновременно открывают PR и триггерят Actions, и имеет ли смысл ввести rate limit на уровне агентов.
3. Дедупликация коммитов: Агентские коммиты, запускающие полный прогон тестов на каждое инкрементальное изменение, не просто неэффективны — в масштабе они напрямую провоцируют ту платформенную нагрузку, которая вызвала проблемы GitHub.
4. SLA-based роутинг для критических пайплайнов: Если определённые деплой-воркфлоу критически важны для бизнеса, рассмотрите их перевод на self-hosted runner или вторичный CI-провайдер с собственным SLA — по аналогии с тем, как команды роутят latency-sensitive вызовы моделей через выделенного провайдера с гарантиями надёжности.

Базовый архитектурный вопрос один и тот же — роутите ли вы трафик AI-моделей или CI/CD-пайплайнов: ваш дизайн предполагает, что единственный провайдер всегда доступен, или рассматривает каждую upstream-зависимость как отдельный домен отказа?

Что стоит проверить пользователям TheRouter

Команды, уже роутящие запросы AI-моделей через несколько провайдеров с помощью TheRouter, понимают принцип multi-provider надёжности на уровне моделей. Инцидент с GitHub распространяет эту логику выше — на уровень пайплайна.

Если вы деплоите Claude Code или Copilot в CI/CD-пайплайн через GitHub Actions, сейчас самое время проверить: обладает ли сам пайплайн тем же fallback-мышлением, что применяется к роутингу моделей? Coding-агент, способный переключиться на резервного модельного провайдера при сбое, но не имеющий запасного CI/CD-runner, обеспечивает лишь половину отказоустойчивости.

Для команд, оценивающих multi-cloud стратегии пайплайнов: AWS CodeBuild и GitLab CI сегодня являются наиболее распространёнными fallback-целями для GitHub Actions в production. Ни один из них не требует миграции репозиториев — оба могут запускать пайплайны против кода, размещённого на GitHub, через OAuth-доступ, обеспечивая резервирование на уровне инфраструктуры без полного переезда платформы.

Также стоит пересмотреть опцию self-hosted Actions runners. Если план Microsoft перенести GitHub на Azure к 2027 году уже сдвигается, ожидаемая конвергенция инфраструктуры GitHub и Azure наступит позже, чем многие команды предполагали.