Сбой GitHub: шесть продуктов и потеря четверти сети

Краткое содержание

Сбой начался 24 июля в 16:04 UTC; подробный отчёт о первопричине GitHub опубликовал 29 июля в 02:36:25 UTC.
Нарушилась связь между магистральными коммутаторами одной вычислительной ячейки и уровнем агрегации в одной из трёх физических зон доступности дата-центров GitHub.
Оставшиеся пути оказались перегружены, что вызвало потерю пакетов после утраты 25\u00A0% доступной ёмкости сетевых межсоединений.
В период влияния 10\u00A0% заданий Actions завершились сбоем, ещё 5\u00A0% начались с задержкой, 27\u00A0% операций в Issues были медленными или завершились по тайм-ауту, а 4\u00A0% запросов Copilot и 4\u00A0% операций git push пострадали.
GitHub перенаправил соединения на волоконно-оптические линии, зарезервированные для будущих модернизаций, восстановил достаточную ёмкость в 17:07, а все пути — к 17:36, и сообщает, что ускоряет перевод старых ячеек с интерфейсов 100 Гбит/с на 400 Гбит/с.

Полезный сюрприз в отчёте GitHub не в том, что многие продукты столкнулись с общим сбоем, а в том, насколько по-разному одна и та же потеря пакетов проявилась на уровне приложений. Задание могло завершиться ошибкой, начаться с опозданием или выполниться нормально. Операция в Issues могла зависнуть. Для push могла потребоваться проверка. Запрос Copilot мог быть автоматически повторён. Аутентификация в основном оставалась работоспособной, но замедлилась.

Это не взаимозаменяемые симптомы, и они требуют разных действий по восстановлению. Поэтому отчёт о первопричине даёт операторам два перечня для сверки: физическую ёмкость, которую восстановил GitHub, и действия на уровне приложений, которые клиентам, возможно, нужно повторить, подтвердить или осознанно оставить без изменений.

Новое событие — это раскрытие информации, а не второй сбой

Основной инцидент произошёл 24 июля. В статусной записи GitHub отражена последовательность событий по сервисам в тот день, включая API Requests, Issues, Pages, Actions, Pull Requests и Copilot. Решение-значимое изменение появилось позже: подробное обновление инцидента было изменено 29 июля в 02:36:25 UTC, уже в текущем окне отчётности.

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

Новый отчёт по-прежнему не называет инициировавшее устройство, работы по обслуживанию или иной триггер, из-за которого пропала связь. Он объясняет механизм отказа после потери путей — уцелевшие каналы перегрузились, и пакеты начали отбрасываться, — но не причину потери исходных каналов. Этот пробел должен оставаться заметным.

Отказ одной ячейки затронул шесть сервисных границ

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

Опубликованные масштабы необычно точны. Десять процентов заданий Actions завершились сбоем, тогда как 5\u00A0% успешно выполнились после задержки запуска. Двадцать семь процентов операций в Issues были медленными или завершились по тайм-ауту. Четыре процента запросов Copilot вызвали ошибки, хотя GitHub отмечает, что большинство из них были автоматически повторены. Четыре процента операций git push пострадали. Задержка аутентификации выросла, но доля ошибок осталась ниже 1\u00A0%.

Знаменатели относятся к разным продуктам и действиям, поэтому проценты нельзя складывать в вымышленный глобальный показатель отказов. Они показывают распространение: ограниченная ёмкость сети превращалась в очереди, тайм-ауты или ошибки в зависимости от политики повторных попыток, модели состояния и бюджета задержек каждого сервиса.

Восстановление заимствовало завтрашнюю ёмкость

GitHub смягчил последствия инцидента, перенаправив затронутые соединения на волоконно-оптические линии, выделенные для будущего расширения ёмкости. Достаточная для устранения потери пакетов ёмкость была восстановлена в 17:07 UTC. Большинство сервисов показали полное восстановление к 17:16, а все пути были восстановлены, и сервисы стали работоспособными к 17:36.

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

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

Каждый процент оставляет свою очередь очистки

Неудачные задания Actions требуют оценки перед повторным запуском. Документация GitHub позволяет пользователям с правом записи повторно запускать неудачные задания, отдельные задания или весь рабочий процесс. Повторный запуск использует привилегии исходного исполнителя, SHA фиксации и Git ref. Это сохраняет контекст выполнения, но не делает безопасным автоматическое повторение изменяющих состояние развёртываний, платежей, релизов или миграций баз данных.

5\u00A0% заданий, начавшихся с опозданием, ставят другой вопрос: они могли завершиться уже после того, как начался более новый запуск. Командам нужно сравнивать идентификаторы запусков, среды развёртывания и внешние побочные эффекты, а не слепо повторять всё, что выглядело задержанным. Для git push правильным ответом будет проверить, продвинулась ли удалённая ссылка, прежде чем отправлять снова. Для операций в Issues тайм-аут клиента не доказывает, что комментарий или правка не сохранились.

Автоматические повторные попытки Copilot снижают видимую долю ошибок, но создают другую проблему измерения: успех приложения после повторной попытки может скрывать ухудшение надёжности первой попытки. Аутентификация с долей ошибок ниже 1\u00A0% тоже не означает «не пострадала», когда задержка растёт. Отчёт о первопричине поддерживает отдельные проверки восстановления, а не один общий сигнал «всё чисто».

Четыреста гигабит — это исправление, а не посмертный анализ

GitHub сообщает, что старые ячейки используют сетевые интерфейсы 100 Гбит/с, и ускоряет запланированные переходы на 400 Гбит/с. Большая пропускная способность на каждом уровне фабрики должна повысить устойчивость к потере пути или устройства. Это обязательство существенно, потому что оно непосредственно отвечает на перегрузку — механизм, превративший потерю каналов в влияние на пользователей.

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

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

Что клиентам и GitHub следует измерять дальше

Клиенты могут сохранить доказательства инцидента уже сейчас: идентификаторы неудачных и задержанных рабочих процессов, результаты push, операции в Issues с тайм-аутом, задержки аутентификации и любые доступные счётчики повторных попыток Copilot. Проверки восстановления должны сверять состояние, а не просто повторять запросы. Регламент действий должен отличать идемпотентные операции чтения от записей с внешними эффектами.

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

Обновление от 29 июля ценно тем, что снова делает общую зависимость от облачного сервиса физически осязаемой. Шесть сервисных меток не отказали независимо. Исчезла четверть ёмкости межсоединений, оставшиеся пути заполнились, и каждый продукт превратил потерю пакетов в собственную видимую пользователю очередь.