В июле GitHub зафиксировал восемь инцидентов, приведших к деградации производительности ряда сервисов, включая Actions, Copilot, SSH-аутентификацию и систему pull request. Компания описала технические причины сбоев, их влияние на пользователей и запланированные изменения инфраструктуры.
Отдельно GitHub отметил серьёзный инцидент с GitHub Actions 6 августа, когда длительный сбой нарушил запуск рабочих процессов. Компания признала, что это противоречит приоритету по обеспечению доступности сервиса, и сообщила о работе над детальным разбором причин и ускорением архитектурных изменений в Actions.
GitHub продолжает переносить ключевые компоненты инфраструктуры из собственных дата-центров в Azure. В июле более 50% чтений монолита обслуживались из Azure Central US, а трафик Git достиг 47%. Около 29% репозиториев получили вторую реплику в Central US, что снижает последствия деградации отдельных регионов.
Компания сокращает зависимость от общих баз данных и инфраструктуры. Первые таблицы аутентификации перенесены на выделенные сервисы, что уменьшает нагрузку на старую общую базу, а выделенный сервис pull request почти достиг полной функциональной совместимости с монолитом для аутентифицированных чтений. Это снижает риск того, что проблемы в одном компоненте затронут другие пользовательские сценарии.
GitHub сообщает о снижении нагрузки на критические участки: общее время запросов к таблице артефактов удалось сократить вдвое, а кэширование в пути авторизации уменьшило нагрузку на сервис авторизации на 18,2% при росте объёма запросов. Все поисковые нагрузки теперь обслуживаются из Central US с дополнительным запасом мощности.
Компания меняет подход к контролю устойчивости инфраструктуры. Теперь оценивается не только состояние систем, но и здоровье ключевых пользовательских сценариев, например работы с pull request. GitHub также переводит рискованные операции в продакшене на автоматизацию и строгие процедуры, чтобы уменьшить зависимость от ручных действий.
Переход к Azure рассматривается как процесс в несколько этапов. Цель на ближайший квартал — 70% трафика на чтение и 30% трафика на запись через Central US, с последующим подключением второй Azure-региональной площадки для региональной устойчивости. GitHub рассчитывает вывести продакшен-трафик dotcom из собственных дата-центров к концу 2026 календарного года.
Ниже приведены краткие итоги инцидентов июля.
8 июля 2026 года с 15:07 до 22:13 UTC часть сервисов GitHub (Web UI, REST API, GraphQL API, Actions, Packages, Copilot и Git-операции) была недоступна в средах Enterprise Cloud с требованием хранения данных. Пользователи сталкивались с ошибками 5xx, сбоями входа, провалами API-запросов и запусков workflow. На пике в одном из окружений около 84% активных арендаторов испытывали массовые отказы, а уровень ошибок 5xx достигал примерно 96%.
Проблему вызвало некорректное изменение конфигурационного значения через автоматический процесс управления метаданными инфраструктуры. Защитный механизм, который должен блокировать подобные изменения на работающих виртуальных машинах, в этом случае не сработал. Неверное значение нарушило сервис-дискавери и оставило маршрутизаторы трафика без доступных бэкендов. Восстановление заняло несколько часов из‑за большого количества машин и дополнительного сбоя из‑за нехватки памяти в одном из инфраструктурных компонентов.
GitHub вводит неизменяемость метаданных, удаляет рискованные сценарии перезаписи и улучшает поэтапное внедрение изменений. Дополнительно компания усиливает мониторинг пустых пулов бэкендов у маршрутизаторов трафика и развивает более безопасные инструменты восстановления всего парка машин.
9 июля 2026 года с 03:29 до 13:39 UTC GitHub Actions испытывал задержки и сбои старта задач на GitHub-хостed раннерах. Также задерживались или проваливались сборки Pages и задания Copilot Cloud Agent и Copilot Code Review, зависящие от Actions. На пике около 8% запусков задерживались более чем на 5 минут, а около 2% не стартовали.
Причиной стал нездоровый статус бекенд-сервиса данных, отвечающего за выделение раннеров. Один из шардов с наибольшей нагрузкой перегрузился и не мог корректно синхронизироваться между регионами. После восстановления системы репликации и обработки накопившейся очереди работа Actions вернулась к норме.
GitHub усилил мониторинг, операционные инструкции и управление нагрузкой для подобных сервисов. Планируются дополнительные меры по лучшему распределению запросов, защите сервисов во время восстановления и снижению задержек при резком росте трафика, а также долгосрочные улучшения устойчивости данных и пропускной способности.
16 июля 2026 года с 08:50 до 09:50 UTC инструмент web_search сервера GitHub MCP столкнулся с повышенным уровнем ошибок. Средний уровень ошибок составил 42%, пиковый — 82% для запросов к этому инструменту. Остальные инструменты MCP не пострадали. Причиной стала деградация у внешнего провайдера веб-поиска.
Инцидент завершился после восстановления работы провайдера. GitHub улучшил обработку запросов, мониторинг и инструкции для реагирования: поиск теперь выполняется с ограничением по времени, отдельно контролируется надёжность инструмента, а внутренние инструкции помогают быстрее выявлять сбои на стороне поставщика.
Компания внедряет допзащиту в виде «предохранителя», который будет помечать поиск как недоступный при длительных ошибках, чтобы не допускать массовых провалов каждого запроса в отдельности. Однако дать ответы в отсутствие провайдера это не сможет, поэтому GitHub оценивает варианты резервного источника результатов.
19 июля 2026 года с 18:00 до 20:11 UTC массовая переконфигурация DNS привела к серьёзной деградации работы github.com и сред с требованием хранения данных. Пользователи видели повышенный уровень ошибок при работе с GitHub Actions, вебхуками, Copilot и другими сервисами. В одном из регионов максимальный уровень ошибок 5xx достигал 9,9%, а отправка вебхуков была приостановлена примерно на 40 минут.
Проблема началась из‑за сбоя подключения к базе данных внутренней DNS‑системы, после чего неполные данные были ошибочно восприняты автоматической системой переконфигурации DNS как валидные. По мере истечения кешированных записей часть сервисов перестала разрешать внутренние адреса. Мониторинг зафиксировал воздействие на клиентов примерно через минуту, а восстановление шло по мере возвращения доступности базы и восстановления кешей.
После инцидента GitHub внедрил защиту, сохраняющую последнюю корректную DNS‑конфигурацию и отклоняющую неполные данные, а также блокирующую массовые разрушающие изменения. Уменьшена длительность кеширования отрицательных DNS‑ответов и улучшен мониторинг доступности базы данных DNS-контроллера.
С 19 июля 2026 года 23:05 UTC по 20 июля 03:55 UTC GitHub Actions испытывал задержки и сбои старта задач на self-hosted и крупных раннерах. Стандартные GitHub-хостed и macOS‑раннеры не затронуло. В среднем 9% запусков workflow получили задержку, с пиковым значением 21,4%. Для отдельных категорий раннеров до 78,99% задач на больших хостед-раннерах, 29,8% на scale-set и 8,7% на self-hosted ждали более пяти минут. Дополнительный трафик переподключений увеличил нагрузку на API GitHub и время ответа на несколько секунд.
Причиной стал сбой в управлении жизненным циклом сертификата одного из внутренних сервисов: истечение SSL‑сертификата нарушило подключение раннеров. Сертификат использовался для механизма контроля минимальной версии раннера и распространялся вручную. Хотя новый сертификат был сгенерирован, автоматического развёртывания после срабатывания алерта не было. Восстановление началось после ротации сертификата, а к 03:55 UTC очередь накопившихся задач была обработана.
GitHub добавляет независимый мониторинг сроков действия сертификатов, улучшает автоматизацию их продления и обновляет процессы оповещения и реагирования, чтобы подобные проблемы выявлялись и устранялись раньше.
21 июля 2026 года с 07:41 до 11:57 UTC сервис SSH‑аутентификации на github.com работал с перебоями. В среднем 12,2% запросов аутентификации по SSH отклонялись, на пике — 15,7%. Ошибки затрагивали как пользовательские RSA‑ключи, так и deploy‑ключи.
Сбой вызвала регрессия, внесённая при несвязанном инфраструктурном изменении. Она затронула менее распространённый метод аутентификации по публичному ключу — схему с прямой подписью ключа, активно используемую deploy‑ключами и системами автоматизации. Валидные попытки по этому пути ошибочно отклонялись.
Инцидент устранили откатом изменения, после чего SSH‑аутентификация вернулась к нормальной работе. GitHub расширяет автоматизированное тестирование сценариев аутентификации по SSH‑ключам и улучшает наблюдаемость и алертинг по отказам аутентификации.
24 июля 2026 года с 19:17 до 20:02 UTC пользователи не могли создавать pull request через веб-интерфейс, командную строку и API из‑за изменения vschema в базе Vitess. Было затронуто 113 930 попыток создания pull request у 50 904 пользователей. Сообщается о среднем уровне ошибок 1,75% и максимальном 2,25% по запросам к сервису pull request; существующие pull request и остальной функционал работали, хотя завязанные на создание новых PR процессы также страдали.
Корень проблемы связан с backfill‑процессом в Vitess‑keyspace, где хранятся данные pull request. Ошибки при выполнении команды backfill и рост задержки VReplication привели к отмене workflow. Отмена запустила недооценённый путь в Vitess, который удалил таблицу из целевого keyspace, оставив ссылку на несуществующую таблицу и, как следствие, ошибки при создании PR.
Для устранения проблемы GitHub откатил изменения в базе и удалил ссылку vschema на удалённую таблицу, после чего создание pull request сразу восстановилось. Компания подготовила операционные инструкции по backfill индексов и задокументировала неожиданное поведение при отмене, а также работает над более строгой проверкой перед изменениями, использованием проверенных сценариев и полноформатным тестированием в нижних средах до выхода в продакшен.
25 июля 2026 года GitHub Actions пережил две связанные деградации, вызвавшие задержки запусков workflow более чем на пять минут и инфраструктурные сбои.
Первая фаза шла с 08:45 до 09:13 UTC. Во время планового конфигурационного изменения кластера Redis на критическом пути Actions один регион остался в нестабильном состоянии. Параллельно другая операция по ёмкости временно вывела из кластера другой регион и перенаправила его трафик в проблемный, что создало рассинхронизацию состояния назначений задач между регионами. В результате часть запусков задерживалась, исчерпывала попытки или завершалась с ошибкой инфраструктуры. На пике около 7% запусков задерживались более 5 минут, а 25% завершались с инфраструктурной ошибкой.
Вторая фаза произошла с 12:08 до 12:48 UTC. При смягчении последствий первого инцидента трафик вернули в регион, где ещё продолжалось наращивание мощности. Несколько узлов Redis в этом регионе вышли из строя, нагрузка сместилась на оставшиеся узлы, и многие из них достигли лимитов по подключению. На пике 30% запусков задерживались более 5 минут, а 60% заканчивались с инфраструктурной ошибкой. Проблему устранили перераспределением трафика от масштабируемого региона.
GitHub усилил проверки здоровья и ёмкости регионов перед обслуживанием, ввёл обязательный период стабильного наблюдения перед возвратом трафика и продолжает развивать автоматическое восстановление подключений и обнаружение разбалансировки шардинга. Параллельно продолжается работа по повышению устойчивости и масштабируемости этого участка инфраструктуры GitHub Actions.
Компания напоминает, что в мае было зафиксировано девять, а в июне — шесть инцидентов с деградацией производительности GitHub‑сервисов. Одновременно GitHub публикует аналитические данные об экосистеме разработчиков, включая новый набор данных Innovation Graph, который показывает ускорение роста глобальных сообществ и усиление коллаборации в разных экономиках.
GitHub также освещает инициативы в сфере регулирования ПО и открытого исходного кода. Компания выступает за точечные поправки, которые устранят конфликты с лицензированием open source и согласуют регуляторные требования с международными стандартами прозрачности, сохраняя исходные цели регулирования.
Материал подготовлен по данным GitHub.
