GitHub опубликовал июньский отчёт о работе платформы и инфраструктуры, уделив внимание инцидентам с доступностью сервисов и прогрессу в переносе нагрузки в Azure. В течение месяца произошло шесть инцидентов с деградацией производительности различных компонентов GitHub.
Компания продолжила перенос monolith-трафика и Git в Azure. Доля monolith-трафика в Azure в регионе Central US достигла 45%, но рост замедлили после инцидента 21 мая и ввели новый шаговый контроль стабильности перед каждым увеличением нагрузки. Трафик Git в Azure вырос с 30% до пика в 43%, при этом целевой показатель в 50% в июне не достигнут: команда сознательно ограничила рост, чтобы не увеличивать задержки для пользователей, и временно не называет новые целевые значения.
GitHub сообщил о внутреннем прогрессе в разделении монолита. Новый сервис pullsd теперь обрабатывает 100% анонимных чтений pull request, разгрузив монолит. Сервис reposd стал первым вынесенным репозиторием-сервисом, который обслуживает REST-трафик из Azure, успев подняться до 50% чтений до временного снижения из‑за ограничения по Redis; инцидента при этом не произошло. Новый users-сервис снимает около 500 000 запросов в секунду с основной базы данных, а таблицы аутентификации и авторизации переносятся физически в начале июля.
Другие улучшения: примерно 97% решений по лимитам API теперь принимаются на уровне Gateway, а не внутри монолита; механизм «сброса нагрузки» на стороне клиента проверяется на 5% реального продакшн‑трафика; для доступа в продакшн и изменений через ChatOps введено обязательное подтверждение двумя людьми с единой аудиторской трассировкой. GitHub подчёркивает, что приоритеты остаются прежними: сначала доступность, затем ёмкость, затем новые функции.
4 июня 2026 года с 17:30 до 18:55 UTC служба Copilot code review столкнулась с повышенным уровнем сбоев при обработке запросов на github.com. В этот период в среднем 81,6% запросов на ревью завершались ошибкой, с пиковым уровнем 93,9%, всего было около 36 800 неуспешных запросов. GitHub Enterprise Cloud с привязкой данных по регионам не пострадал.
Причиной стал новый релиз зависимости, используемой в workflow обработки Copilot code review, несовместимый с текущим окружением. Workflow автоматически подтянул последнюю версию без достаточной проверки совместимости, что привело к сбоям обработки. Часть задач не завершалась быстро с ошибкой, а доходила до тайм‑аута. Инцидент устранили, удалив проблемную версию зависимости и перевывши соответствующий сервис; к 18:55 UTC уровень ошибок вернулся к нормальным значениям, а к 19:59 UTC были обработаны оставшиеся зависшие задачи.
Для предотвращения повторения GitHub закрепляет версии зависимостей вместо автоматического использования последних релизов, добавляет проверки совместимости будущих версий, улучшает механизм быстрого завершения задач при невозможности запуска процессора ревью, сокращает тайм‑ауты в workflow и усиливает мониторинг завершения ревью.
8 июня 2026 года примерно с 06:30 до 08:36 UTC пользователи без авторизации столкнулись с устойчивым ростом ошибок HTTP 504 при доступе к pull request, issues, релизам, patch‑диффам и другим страницам github.com. В период инцидента около 17% неаутентифицированных запросов к этим endpoint возвращали gateway timeout, с пиком примерно 34% около 06:50 UTC. Часть GitHub Actions workflow также пострадала, если зависела от загрузки релизов или связанных endpoint. Запросы авторизованных пользователей не были затронуты.
Инцидент вызвал резкий рост вредоносного анонимного трафика к конкретным endpoint github.com. Поскольку неаутентифицированные запросы обслуживаются выделенным пулом web‑серверов, это ухудшило способность обрабатывать такие запросы и привело к накоплению очередей сверх порогов тайм‑аута. Проблему устранили с помощью таргетированных блокировок на уровне балансировщика и приложения; после вступления блокировок в силу показатели ошибок вернулись к норме.
Для снижения риска повторения GitHub улучшает автоматическое выявление и блокировку подобных шаблонов трафика, совершенствует аварийный процесс развёртывания блокировок и изучает изменения маршрутизации для endpoint, используемых одновременно гостями и автоматизированными workflow.
10 июня 2026 года с 15:05 до 16:25 UTC GitHub API испытывал сниженную доступность из‑за периодических ошибок аутентификации примерно для 9% запросов. Были затронуты как REST, так и GraphQL API. Клиенты наблюдали «выброс» из сессий и повторные циклы аутентификации в интеграциях первого и сторонних поставщиков. Из‑за повторных попыток аутентификации средняя задержка для затронутых запросов выросла примерно на 800 мс.
Причиной стал релиз сервиса‑прокси для memcached во внутренней инфраструктуре API, из‑за чего служба аутентификации получила некорректную конфигурацию хостов и периодически не могла выполнить запросы в кэш. Инцидент был решён изменением конфигурации memcached с указанием правильного хоста.
В дальнейшем GitHub планирует перенести систему аутентификации на новую инфраструктуру кэширования, чтобы повысить её устойчивость, а также научить gateway лучше различать временные ошибки инфраструктуры аутентификации и реальные неверные учётные данные, чтобы временные сбои не выглядели для пользователей как выход из системы.
16 июня 2026 года с 17:20 до 18:15 UTC модель Opus 4.8 в GitHub Copilot испытывала сниженную доступность. Часть запросов к Opus 4.8 завершалась ошибками, при этом другие модели Copilot оставались доступны и могли использоваться как альтернатива. Причиной стала проблема у внешнего провайдера модели. На время инцидента GitHub включил специальные сообщения о работе в «урезанном режиме»; после устранения неисправности на стороне провайдера команда наблюдала за метриками до полного восстановления.
Для снижения зависимости от одного поставщика GitHub перераспределяет мощность по нескольким inference‑поставщикам для каждой модели, чтобы трафик можно было оперативно перевести на здоровую инфраструктуру. Отдельно улучшены инструменты для обновления публичной статус‑страницы, чтобы информация об инцидентах публиковалась стабильно.
17 июня 2026 года примерно с 03:50 до 04:44 UTC GitHub Copilot работал с деградацией: большинство frontier‑чат‑моделей были временно недоступны во всех регионах. В интерфейсах web, редакторов и CLI модели исчезали из списка или возвращали ошибку «model not available». Клиенты могли продолжать работу, выбрав оставшиеся доступные модели; инцидент пришёлся на непиковое время, что снизило масштаб влияния.
Проблема возникла из‑за изменения конфигурации, которое продакшн‑система посчитала недопустимым. Команда вернулась к предыдущей конфигурации, после чего модели автоматически восстановились. Сейчас GitHub внедряет постепенный rollout конфигурационных изменений с более жёсткой валидацией, алертами на резкое уменьшение числа доступных моделей и автоматическим откатом изменений, которые вызывают такие события.
25 июня 2026 года с 17:33 до 17:55 UTC сервис фоновых задач испытывал деградацию, что привело к росту задержек обработки pull request, push в репозиторий, GitHub Actions workflow и webhook. Максимальная задержка достигала 7 минут. Причиной стали проблемы на уровне гипервизора и всплеск входящего трафика, что вызвало тайм‑ауты, массовые переподключения и постоянные ребалансировки.
Инцидент был смягчён заменой проблемного узла в 17:49 UTC, после чего все сервисы вернулись к нормальной работе к 18:07 UTC. Для будущих ситуаций GitHub сделал обработку фоновых задач более устойчивой к резким скачкам трафика, уменьшил риск массовых переподключений при деградации, убрал совместное размещение критичных узлов, чтобы сбой одного не влиял на другие, и добавил более ранние алерты на условия, подобные тем, что привели к этой деградации.
Компания рекомендует следить за страницей статуса GitHub для получения оперативной информации о текущем состоянии сервисов и пост‑инцидентных отчётов, а также обещает продолжать делиться техническими подробностями в разделе Engineering в GitHub Blog. В отчёте также напомнили, что в мае произошло девять инцидентов с деградацией производительности, а в апреле — десять.
GitHub дополнительно делится аналитикой и новостями: новые данные Innovation Graph показывают ускоренный рост сообществ разработчиков по всему миру и рост коллаборации в разных экономиках; компания публикует позицию по точечным поправкам в регулирование для устранения конфликтов с лицензиями open source и согласования с международными требованиями к прозрачности при сохранении исходных целей регуляторов.
Источник: GitHub Blog / ежемесячный отчёт о доступности и инфраструктуре.
