GitHub ускоряет миграцию в Azure после майских сбоев

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

GitHub сообщает, что ускоряет миграцию на Azure для увеличения емкости и отказоустойчивости. Сейчас 40% трафика монолита обслуживается из Azure (в феврале было 8%), Git-трафик переведен на 30%, репликация репозиториев — на 99%. Параллельно завершается разукрупнение основного кластера баз данных: пользователи, аутентификация и авторизация выделяются в отдельные домены, чтобы локальная проблема не распространялась по всей платформе. Новый сервис для пользователей уже полностью переведен и обслуживает примерно вдвое больший трафик при заметно более низкой нагрузке на базу. Также внедряются бездисковые (stateless) токены аутентификации, чтобы убрать дополнительные запросы к базе при пиковых нагрузках.

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

Инцидент 4 мая: миграция схемы базы данных

4 мая 2026 года с 15:34 до 16:40 UTC на github.com произошел сбой, вызвавший повышенную задержку и рост доли неуспешных запросов во многих пользовательских сервисах. Суммарное влияние на клиентов длилось примерно 1 час 6 минут.

Сильнее всего пострадали pull request’ы, для которых статус оставался «красным» в период пика. Issues, Actions, webhooks и Git-операции испытывали задержки и периодические ошибки. Затронуты также зависимые сервисы: Codespaces, Pages, Packages, OAuth и GitHub Apps, Marketplace, Copilot. На пике около 1,3% запросов возвращали код 5xx, в среднем за время инцидента — около 0,46%.

Причиной стала штатная онлайн-миграция схемы на крупной и часто используемой таблице базы данных. Миграция несколько часов проходила без проблем, но по мере выхода трафика на недельный пик суммарная нагрузка от миграции и боевых запросов исчерпала доступные подключения к базе. Это вызвало конкуренцию запросов на основном экземпляре и цепочку таймаутов в зависящих сервисах. Инцидент обнаружили примерно через три минуты с помощью комбинации автоматического мониторинга и дежурной команды. После того как миграция была определена как причина, ее приостановили, и сервисы стали восстанавливаться. Время до смягчения последствий составило около 33 минут, полное восстановление заняло еще около 30 минут.

В качестве последующих шагов GitHub планирует жестче привязывать миграции крупных высоконагруженных таблиц к окнам низкого трафика и применять динамическое ограничение скорости, которое учитывает текущую нагрузку кластера. Будут внедрены автоматические «предохранители», приостанавливающие миграции при выходе задержек или использования подключений за безопасные пределы, а также расширен мониторинг по признакам давления от миграций (скорость записи, время блокировок, насыщение подключений), чтобы срабатывать до пользовательского влияния. Параллельно пересматриваются размеры пулов подключений, чтобы сохранять запас при выполнении миграций.

Инциденты 5–6 мая: проблемы с GitHub Actions

5 и 6 мая GitHub Actions столкнулся с деградацией работы хостируемых раннеров в двух связанных инцидентах. Исправление первой проблемы частично спровоцировало вторую.

5 мая 2026 года с 13:22 до 17:05 UTC были нарушены хостируемые раннеры GitHub Actions в регионе East US. Около 13,5% заданий со стандартным раннером завершились ошибкой, примерно 16% запросов на более крупные раннеры с приватной сетью, привязанные к East US, также либо завершились сбоем, либо запускались с задержкой более пяти минут. Затронуты запросы на код-ревью в Copilot: около 8 500 запросов истекли по тайм-ауту. Большинство запросов на раннеры автоматически перераспределились по другим регионам, но часть оставалась на East US и пострадала.

Инцидент вызвала операция масштабирования виртуальных машин для хостируемых раннеров в East US. В ходе обычной операции создание виртуальных машин уткнулось во внутренний лимит скорости при загрузке образов из хранилища. Существующая логика отката не сработала из-за кода ответа, который вернулся в этой ситуации. Проблему смягчили снижением нагрузки, что позволило системе восстановиться и обработать очередь заданий. К 15:34 UTC большинство отложенных и неудачных запусков были компенсированы, далее менее 0,5% назначений раннеров оставались затронуты до полного восстановления в 17:05 UTC.

6 мая 2026 года с 06:45 до 09:15 UTC снова наблюдалась деградация стандартных Ubuntu-раннеров GitHub Actions. Около 17,1% заданий со стандартным раннером завершились сбоем. Причиной стали неожиданные конфигурационные данные, внесенные в рамках устранения предыдущего инцидента; они блокировали новые выделения ресурсов при росте дневной нагрузки. Проблемные данные удалили в 08:51 UTC, после чего выделение раннеров возобновилось, пулы ресурсов масштабировались и восстанавливались.

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

Инцидент 6 мая: недоступность Copilot cloud agent

6 мая 2026 года с 11:02 до 11:13 UTC пользователи не могли запускать или просматривать сеансы Copilot cloud agent и удаленные сессии. В этот период все запросы к API сессий возвращали ошибки, не позволяя создавать новые сессии или просматривать существующие.

Причиной стал конфигурационный сбой в настройках сетевой маршрутизации сервиса, который по ошибке убрал входящий маршрут. Команда откатила изменение в 11:13 UTC, что восстановило работу сервиса. Инцидент оставался открытым до 11:59 UTC, пока шла проверка полного восстановления. GitHub улучшает процессы проверки развертываний, чтобы подобные изменения конфигурации не влияли на боевой трафик.

Инцидент 6 мая: сбой создания тредов ревью в pull request’ах

6 мая 2026 года с 15:12 до 19:02 UTC создание новых тредов ревью в pull request’ах на github.com не работало. Ошибка затронула новые построчные и файловые комментарии; существующие pull request’ы и уже созданные комментарии работали корректно.

Причину составило достижение максимального значения 32-битного целочисленного ключа в таблице Vitess-lookup, используемой при создании тредов ревью. Основная таблица была ранее переведена на 64-битный ключ, но lookup-таблица осталась с 32-битным типом. После того как значения в основной таблице вышли за диапазон 32-битных ID, попытки создать новые треды стали почти полностью завершаться сбоем. Проблему устранили обновлением схемы всех шардов lookup-таблицы до 64-битных типов, расширив доступный диапазон идентификаторов. Сервис полностью восстановился после завершения глобальных изменений схемы.

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

Инцидент 7 мая: задержки Copilot-агентов для pull request’ов

7 мая 2026 года с 04:12 до 06:13 UTC Copilot cloud agent и агент код-ревью для pull request’ов сталкивались с задержками запуска или ошибками старта. Во время инцидента новые сессии Copilot, инициированные pull request’ами, не создавались, а число сессий агента ревью упало примерно на 50% от базового уровня.

Инцидент был побочным эффектом восстановительных работ по отдельному событию, связанному с pull request’ами. В рамках этих работ проводилась крупная миграция базы данных, которая вызвала задержки репликации на части реплик. Хотя сами реплики не обслуживали пользовательский трафик, защитные механизмы корректно восприняли рост задержки репликации как сигнал снизить скорость записи в кластер. В результате фоновая обработка pull request’ов временно замедлилась. Именно эта обработка отвечает за внутренние события, по которым Copilot-агенты начинают работу, поэтому старт этих агентов откладывался, пока реплики не синхронизировались.

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

Инцидент 15 мая: сбой workflow’ов GitHub Actions

15 мая 2026 года с 07:43 до 08:48 UTC GitHub Actions испытывал деградацию, из-за которой часть клиентов столкнулась с ошибками запуска workflow’ов или задержками старта. Причиной стал планируемый failover поддерживающей инфраструктуры для Actions. Во время операции один из автоматических шагов обновления service discovery не распространился корректно, из-за чего трафик пошел по неверному маршруту. Это вызвало рост таймаутов в ключевой зависимости оркестрации workflow’ов.

На пике до 42% запусков Actions завершались сбоем. Затронуты зависящие от GitHub Actions сервисы, включая GitHub Pages и облачные сервисы Copilot. В 08:12 UTC команда вручную исправила конфигурацию service discovery, что привело к восстановлению показателей задержек и ошибок. Наблюдение продолжалось до подтверждения стабильности всех зависимых сервисов, после чего инцидент закрыли в 08:48 UTC.

GitHub вводит дополнительные защитные механизмы при failover, которые проверяют состояние service discovery до завершения операций, усиливает проверки целостности и улучшает устойчивость зависимостей, чтобы сократить каскадные таймауты при инфраструктурных событиях.

Инцидент 26 мая: блокировка GitHub Actions из‑за сервисного аккаунта

26 мая 2026 года с 10:40 до 12:56 UTC наблюдалась деградация GitHub Actions. С 10:40 до 12:16 UTC все новые workflow’ы не запускались, а с 12:16 до 12:56 UTC продолжали падать запускаемые задания, которым нужно было скачивать actions. Пострадали также GitHub Pages, Copilot code review, Copilot coding agent, Octoshift и GitHub Enterprise Importer, зависящие от Actions.

Причиной стало некорректное срабатывание автоматической системы проверки аккаунтов, которая по ошибке приостановила сервисный аккаунт, используемый GitHub Actions для аутентификации запусков и скачивания actions. Команда восстановила аккаунт в 12:16 UTC, отметила его как исключение из автоматических проверок в 12:20 UTC и в 12:48 UTC переразвернула связанный сервис, чтобы сбросить кэшированное состояние. Полное восстановление подтвердили в 12:56 UTC.

Во время этого инцидента небольшое количество issues, pull request’ов, комментариев и discussions было помечено как скрытое из‑за блокировки сервисного аккаунта. Данные не были потеряны: весь контент восстановили, а переиндексация поиска завершилась успешно. Для предотвращения повторения GitHub ввел список разрешенных сервисных аккаунтов, которые не могут быть приостановлены автоматическими системами, и добивается единообразного применения этих правил во всех инструментах управления аккаунтами. Улучшаются средства диагностики и сокращаются задержки распространения кэша для ускорения поиска и устранения похожих инцидентов.

Инцидент 28 мая: деградация GitHub Copilot из‑за модели GPT

28 мая 2026 года с 18:27 до 20:41 UTC сервис GitHub Copilot испытывал деградацию из‑за проблемы с Responses API внешнего поставщика моделей, которая затронула модели GPT-5.2, GPT-5.3-Codex, GPT-5.4 и GPT-5.5. Запросы к этим моделям через Responses API возвращали повышенное число ошибок, что также влияло на Copilot coding agent и Copilot code review. Другие модели работали штатно.

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

GitHub рекомендует отслеживать status-страницу для получения оперативных обновлений о состоянии сервисов и послевторичных отчетах об инцидентах. Дополнительные технические подробности и описание инфраструктурных изменений публикуются в инженерном разделе GitHub Blog.

По данным отчета GitHub о доступности сервисов за май 2026 года.

Читать новости ИИ и технологий в Telegram.


Оцените статью
Gimal-Ai