GitHub местами недоступен: что известно

У части пользователей появились проблемы с доступом к GitHub: сайт может долго загружаться, соединение с репозиториями — обрываться, а некоторые запросы — зависать. В обсуждениях быстро появилась версия о проблеме во Франкфурте: при проверке маршрута трафик у некоторых пользователей перестает нормально проходить в районе DE-CIX Frankfurt, крупнейшей европейской точки обмена интернет-трафиком.

Глобальное падение самого GitHub при этом не подтверждается. На момент проверки GitHub Status показывает штатную работу Git Operations, API, Pull Requests, Actions, Packages, Pages, Copilot и остальных основных компонентов. Независимый монитор Down for Everyone or Just Me также не фиксирует массового сбоя и показывает лишь отдельные пользовательские жалобы.

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

GitHub работает под собственной автономной системой AS36459. Реестр PeeringDB показывает, что сеть компании действительно присутствует в DE-CIX Frankfurt и имеет там два действующих подключения для обмена IPv4- и IPv6-трафиком. В том же реестре указаны подключения GitHub к Equinix Ashburn и SIX Seattle.

DE-CIX Frankfurt — интернет-узел, где сети операторов, облачных компаний, хостингов и крупных сервисов могут напрямую обмениваться трафиком. Сейчас к площадке подключено больше тысячи сетей. Сам DE-CIX называет Франкфурт одним из крупнейших мировых узлов обмена трафиком.

18 сентября там зарегистрировали новый рекорд: пиковая скорость передачи данных впервые достигла 20,02 Тбит/с. Суммарный трафик на площадках DE-CIX в тот же момент превысил 30 Тбит/с. Оператор связал рекорд в том числе с большим объемом видеотрансляций футбольных матчей.

Проверить путь до сервера можно с помощью traceroute или MTR. Они последовательно отправляют диагностические пакеты и показывают сетевые узлы, через которые проходит соединение.

Если после определенного маршрутизатора в выводе появляются звездочки или резко растут потери, возникает соблазн считать именно этот узел причиной сбоя. На практике все сложнее.

Маршрутизатор может нормально пересылать обычный пользовательский трафик, но игнорировать или ограничивать служебные пакеты, которые используются traceroute. Операторы делают это для снижения нагрузки и защиты сетевого оборудования.

Поэтому схема «до Франкфурта ответы есть, после Франкфурта звездочки» сама по себе не доказывает аварию DE-CIX.

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

Публичных данных о крупной аварии DE-CIX Frankfurt 20 сентября обнаружить не удалось. Более того, еще 18 сентября оператор сообщал о рекордном трафике на франкфуртской площадке. Это не доказывает отсутствие локальной неисправности двумя днями позже, но массового отказа всей платформы в открытых данных сейчас не видно.

При этом на DE-CIX действительно запланированы технические работы. Провайдер dataforest опубликовал уведомление о работах на франкфуртской пиринговой платформе с 23:00 21 сентября до 06:00 22 сентября по центральноевропейскому летнему времени. Другой европейский оператор указывает более короткое окно внутри этого периода — с 21:00 до 22:00 UTC 21 сентября. Эти работы начинаются позже нынешних жалоб, поэтому объяснить ими проблемы 20 сентября нельзя.

GitHub может работать через VPN. Такой сценарий вполне укладывается в проблему маршрутизации. Интернет не доставляет пакеты из точки А в точку Б по единственному постоянному маршруту. Сети операторов используют BGP — протокол обмена информацией о доступных маршрутах между автономными системами.

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

Если проблема возникла на конкретном пиринговом соединении или маршруте, GitHub способен одновременно работать у пользователей одного оператора и быть практически недоступным у другого.

VPN в такой ситуации иногда помогает не из-за какого-то специального режима работы GitHub. Он просто меняет точку выхода в интернет и сетевой маршрут до сервиса.

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

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

17 августа GitHub пережил сбой, который продолжался почти восемь часов и затронул github.com, авторизацию, Actions, API, pull request, Issues и Copilot. Компания установила, что трафик достиг нового максимума, а критический компонент в дата-центре Central US не смог вовремя увеличить пропускную способность. В результате начались перегрузка балансировщиков, задержки и массовые ошибки.

Месячный отчет GitHub показывает, что август оказался особенно тяжелым: компания зарегистрировала пять инцидентов с ухудшением работы сервисов. 6 августа более десяти часов продолжался инцидент с GitHub Actions, 17 августа произошел крупный общий сбой, 20 августа возникли проблемы с отображением состояния задач Copilot Cloud Agent, 26 августа снова пострадал Actions, 27 августа ошибки затронули одну из моделей в Copilot.

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

13 сентября произошел еще один крупный сбой. Ухудшение работы затронуло около 28 сервисов, включая Issues, Pull Requests, Actions, Codespaces, Pages, Notifications, Code Scanning и Git LFS. Веб-интерфейс создания Issues на пике не выполнял около 96% попыток, а ошибки регистрации новых учетных записей превышали 90%. Причиной GitHub назвал внутреннюю задачу очистки данных, которая перегрузила общую базу с информацией о правах доступа. 18 и 19 сентября новых аварий GitHub на официальной странице состояния уже не регистрировалось.

Вопросы и ответы

GitHub сейчас упал?

Глобального сбоя на момент проверки нет. Официальная страница состояния GitHub показывает штатную работу основных сервисов, а независимый монитор не фиксирует массовой аварии.

Проблема точно в DE-CIX Frankfurt?

Нет. GitHub действительно подключен к DE-CIX Frankfurt, но сам факт появления этой точки в трассировке не доказывает ее отказ.

Что такое DE-CIX?

Это крупная точка обмена интернет-трафиком. Во Франкфурте через нее связаны более тысячи сетей операторов, облачных платформ и интернет-сервисов.

Почему GitHub может открываться через VPN?

VPN меняет маршрут трафика. Соединение может пройти через других операторов и обойти проблемный сетевой стык.

DE-CIX проводит технические работы?

Да, работы на франкфуртской пиринговой платформе запланированы на 21–22 сентября. Они начинаются позже нынешних проблем и не объясняют сбои 20 сентября.

Мог ли GitHub сломаться из-за роста ИИ-кода?

Таких данных нет. GitHub действительно сообщал о росте нагрузки и нехватке запаса мощности в отдельных системах, но нынешний эпизод с ИИ-разработкой компания не связывала.

GitHub раньше падал из-за перегрузки?

Да. 17 августа новый пик трафика перегрузил часть инфраструктуры GitHub в Central US. Инцидент затронул сайт, авторизацию, API, Actions, pull request, Issues и Copilot.

Это блокировка Роскомнадзора?

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