Кратко

  • По данным GitHub, инцидент 17 августа длился 7 часов 47 минут. Ошибки веб-интерфейса и API достигали примерно 20%, загрузки архивов и необработанного содержимого — около 50%. Были затронуты Issues, Pull Requests, Actions, корпоративная идентификация и Copilot.
  • Sidecar Istio достиг лимита параллелизма, но не масштабировался должным образом. Затем четыре узла HAProxy исчерпали лимиты потоков, а повторные попытки увеличили нагрузку на Copilot Token Service с обычных 7–9 тысяч до 70–100 тысяч запросов в секунду.

Резервная площадка в Northern Virginia успешно обслужила часть запросов, не проходивших через Central US. Однако каждый медленный ответ мог порождать новые запросы и переносить перегрузку дальше.

В подробном обновлении инцидента zkxwbgr0cnmx GitHub указывает интервал с 13:28 до 21:15 UTC 17 августа. Ошибки и задержки наблюдались в Issues, Pull Requests, API, Actions и Copilot. На пике доля ошибок составляла около 20% для веб-интерфейса и API и около 50% для загрузки архивов и raw-содержимого репозиториев.

Проблема затронула и корпоративные контуры управления. GitHub перечисляет SAML- и OIDC-аутентификацию, SCIM и Team Sync. Workflows Actions в GitHub Enterprise Cloud с резидентностью данных пострадали, если использовали публичные определения шагов на GitHub.com. Это не доказывает потерю данных или нарушение выбранного региона хранения. Публичная запись подтверждает зависимость исполнения от другой поверхности сервиса.

Непосредственной причиной компания называет сетевое насыщение балансировщиков нагрузки в дата-центре Central US во время нового пика трафика. Pod sidecar Istio достиг предела параллелизма. Политика автомасштабирования следила за хост-сервисом, но не за лимитом sidecar, поэтому мощность не увеличилась именно в ограниченном компоненте.

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

Часть неудачных запросов перенесли в Northern Virginia, где они обслуживались во время диагностики Central US. Большинство сервисов восстановилось к 16:36 UTC. Actions оставался в ухудшенном состоянии примерно до 18:03.

Copilot восстанавливался дольше из-за обратной связи. Задержки одного внутреннего endpoint активировали скрытую ошибку повторных попыток в VS Code. Неудачная операция с token могла породить несколько дополнительных запросов и войти в цикл. Нагрузка Copilot Token Service выросла с обычных 7–9 тысяч до 70–100 тысяч запросов в секунду.

Для стабилизации потребовалось остановить усиление, а не только добавить маршрут. GitHub временно сократил повторы на gateway, начал отвечать HTTP 403 на часть входящих запросов Copilot token на балансировщиках, а затем возвращал трафик по площадкам постепенно. Token Service полностью восстановился около 21:02 UTC, запись закрыли в 21:15.

Несколько scraping-атак на endpoints codeload усложнили восстановление. Компания не указывает их долю в насыщении и не называет их исходной причиной. Опубликованная цепочка начинается с лимита sidecar и неполной политики масштабирования, продолжается исчерпанием потоков HAProxy и заканчивается усилением повторных запросов.

Документация объясняет пересечение зависимостей. Повторно используемые конфигурации workflow могут обращаться к определениям в публичных репозиториях. Справочник GitHub-hosted runners относит GitHub.com, API, домены Actions и codeload.github.com к адресам, необходимым для запуска jobs и загрузки actions.

Идентификация также находится на критическом пути. GitHub описывает SAML SSO и SCIM как основные средства управления доступом и жизненным циклом учетных записей. В обзоре Enterprise Cloud с резидентностью данных указаны выделенные поддомены GHE.com и выбор регионов. Место хранения данных и путь аутентификации или получения workflow — связанные, но разные параметры.

GitHub планирует учитывать параллелизм sidecar при autoscaling, проверить лимиты Istio, пересмотреть retries и backoff в шлюзах и клиентах, исправить поведение VS Code, улучшить контроль мощности балансировщиков и региональный failover. Пока это заявленные действия, а не проверенный результат. Следующим доказательством станет их реализация и поведение системы при новой задержке.

Клиенты могут разделить проверку восстановления: чтение репозитория, API, SSO, изменение состава команды, загрузка публичного определения workflow, запуск runner и получение Copilot token. Возврат основной веб-страницы не означает одновременного восстановления всех этих путей.

Рекомендации для REST API требуют учитывать Retry-After, время сброса лимита и увеличивать паузу после повторных ошибок. Этот документ адресован внешним интеграциям и не раскрывает внутренний код инцидента. Но принцип тот же: повтор без бюджета превращает задержку в дополнительную нагрузку.

Источники