В августе GitHub столкнулся с пятью инцидентами, вызвавшими ухудшение производительности ряда сервисов. Компания признаёт, что месяц оказался сложным по доступности, хотя работа по повышению устойчивости продолжается.
GitHub сообщил, что активно инвестирует в архитектурные улучшения и перенос инфраструктуры в Azure, что должно дать больше ресурсов. При этом платформа продолжает быстро расти, поэтому команда фокусируется на задачах с наибольшим эффектом, понимая, что полностью устранить риск инцидентов нельзя.
По итогам августовских сбоев GitHub улучшил мониторинг и управление ёмкостью, политику повторных запросов и устойчивость ключевых сервисов. Компания также продвинулась в нескольких долгосрочных технических направлениях.
11 августа GitHub впервые запустил основной MySQL-сервер в продакшене из Azure. Переход прошёл без заметного влияния на клиентов. 27 августа этот сценарий повторили ещё для двух основных баз, а в ближайшие недели запланированы новые, более сложные переключения.
Нагрузка на чтение достигла рекордных значений: до 60,4% чтений с перенесённых сервисов и до 64,3% чтений с монолита GitHub выполнялись из Azure. Чтения Git-репозиториев достигли 54%.
Помимо региональной миграции, группа из 24 таблиц аутентификации была перенесена с самого старого общего кластера mysql1, что убрало около 1 млн запросов в секунду с его реплик. Отдельные изменения в запросах снизили нагрузку ещё на 120 тыс. запросов в секунду и устранили примерно 59 тыс. секунд лишней работы базы в час.
GitHub Actions получил дополнительную ёмкость. Из-за перераспределения нагрузки 33% задач были перенесены с перегруженного продакшн-кластера на свободные ресурсы, что снизило пиковую загрузку CPU в кеше с 98% до 80% и дало оценочно три месяца запаса. В компании подчёркивают, что это временная мера, а долгосрочная изоляция и расширение ресурсов продолжаются.
Работа по изоляции pull request также продвинулась. Если раньше отдельно обслуживался только неаутентифицированный трафик, то теперь аутентифицированные чтения для первой продакшн-группы тоже полностью вынесены.
В рамках защиты от перегрузки Git-сервера было обслужено на 6,4% больше трафика при улучшении 95-го перцентиля времени ответа на 24% и максимальной задержки на 78%. На уровне периметра расширены механизмы «сброса нагрузки», которые применялись при смягчении августовских инцидентов.
GitHub также усилил мониторинг и телеметрию. Для pull request теперь отдельно измеряются сбои мерджей, отзывов и комментариев, чтобы высокая доля успешных чтений не скрывала проблемы с записью. С 21 августа автоматическое обнаружение инцидентов высокой значимости начало совмещать сигналы технической телеметрии и обращений в поддержку.
Мониторинг API был перенастроен и проверен в течение 30 дней, что снизило шум и повысило качество сигналов. Эти изменения должны ускорить обнаружение и реакцию на сбои.
В ближайший месяц GitHub планирует продолжить перенос основных баз данных и сервисов в Azure, улучшать состояние общих баз, расширять автоматизацию управления ёмкостью и авто-масштабирования, а также распространять обработку отказов зависимостей на большее число сценариев работы с pull request.
Компания подчёркивает базовый приоритет: сначала доступность, затем ёмкость, затем новые функции.
Один из крупных инцидентов начался с планового деплоя внутреннего сервиса GitHub Actions, который обрабатывает входящие события и создаёт задания. Сам код деплоя не был причиной сбоя, это подтвердили откатом. Проблема возникла из-за того, что замена pod во время раскатки временно снизила ёмкость в одном дата-центре и перегрузила остальные, на которые ушёл трафик.
Сервисы, связанные с Actions, работали близко к пределам по ёмкости и параллелизму. Кратковременное снижение числа pod привело к исчерпанию запаса ресурсов. В результате sidecar-компоненты сервисной mesh-сети начали испытывать throttling по CPU и перезапуски из-за нехватки памяти, что вызвало каскад ошибок кэша, DNS и API в нескольких кластерах. Входной сервисный mesh также имел небольшой запас, поэтому не смог компенсировать временную потерю ёмкости.
Во время восстановления проявилась скрытая ошибка в логике назначения задач: раннерам выдавались уже отозванные задания, и они зацикливались на их повторных попытках вместо того, чтобы брать новую работу. Это сформировало самусиливающийся хвост очереди и замедлило возвращение к норме.
Отдельный инцидент был связан с новым пиком трафика, который вывел балансировщики нагрузки одного дата-центра за пределы их возможностей. Один из sidecar-компонентов mesh-сети достиг лимита параллельных соединений и не масштабировался, что привело к накоплению запросов.
Часть узлов балансировщика в этом дата-центре достигла предельного числа сетевых соединений. Это ухудшило работу общего шлюза аутентификации и вызвало значительные задержки и ошибки авторизации во многих сервисах, использующих этот путь.
Скрытая ошибка в логике повторных запросов клиентов усилила нагрузку на внутреннюю точку аутентификации, что замедлило восстановление сервиса токенов Copilot. Ключевой слабостью стало то, что sidecar не масштабировался, а поведение повторов не сдерживало рост нагрузки при частичной деградации.
В период инцидента был задет Copilot cloud agent. Задачи агента продолжали выполняться, данные не потерялись, но статус и результаты отображались с задержкой. После догонки обработки информация корректно обновлялась.
По данным GitHub, как минимум 54 организации столкнулись с тем, что статус и результаты задач Copilot cloud agent значительно отставали от привычного уровня. Максимальное зафиксированное влияние для клиентов составило 37,5% измеренной активности по статусам задач в минуту.
Copilot cloud agent хранит статус и результаты задач в управляемой облачной базе данных. В одном из регионов этой базы произошёл сбой на стороне провайдера, и вызовы на чтение и запись статусов начали работать медленно и с ошибками.
Процессы, которые потоково отправляют обновления статусов в эту базу, стали отставать, так как их пропускная способность ограничена числом разделов обработки, рассчитанных на нормальные задержки с запасом. Во время инцидента задержки превысили этот запас, из-за чего очередь обновлений начала расти, а не очищаться.
Дополнительно конфигурация хранения в базе замедлила переключение региона. Первые попытки failover не сработали, и восстановление заняло больше времени, чем ожидалось.
Зависимые сервисы, такие как Copilot code review и часть деплоев GitHub Pages, которые используют Actions, также испытывали проблемы в период инцидентов. В большинстве случаев задержанные прогоны запускались после обработки очереди, а прогоны, не стартовавшие вовремя, успешно проходили при повторном запуске.
Небольшая часть задач, созданных в самом начале одного из инцидентов, не могла быть восстановлена повторным запуском и требовала создания заново.
GitHub констатирует, что общие инфраструктурные сервисы не успевают за ростом нагрузки GitHub Actions и пиковыми значениями трафика. В одном из случаев всплеск входящих событий при уже высокой нагрузке вывел базу данных за пределы возможностей, время запросов выросло, а основной сервер базы был полностью загружен.
Когда база оказалась перегружена, внутренний сервис, который превращает входящие события в назначения задач для раннеров, не смог обрабатывать их в нужном темпе. В результате запуски Actions не стартовали и скапливались в очереди сильно дольше обычного.
Переключение основного сервера базы дало лишь частичное облегчение. Ограничители входящего трафика были настроены чуть выше необходимого, и база продолжала перегружаться, поэтому защитные меры пришлось усиливать вручную и постепенно.
В архитектуре не было автоматического механизма, который бы снижал входящий поток Actions при ранних признаках перегрузки базы, поэтому регулировать нагрузку пришлось вручную. GitHub отмечает это как одно из ключевых технических выводов.
Отдельный инцидент затронул клиентов, которые использовали модель Kimi K3 в GitHub Copilot. Пользователи, работавшие с другими моделями или переключившиеся на них, не пострадали.
Copilot предоставляет выбор моделей ИИ. Одна из них, Kimi K3, обслуживается внешним провайдером. У этого поставщика произошла деградация сервиса, из-за чего значительная часть запросов к Kimi K3 завершалась ошибками. Запросы к другим моделям и режиму Auto, который направляет запросы на другую модель, оставались стабильными.
Пока провайдер не применил свою меру смягчения, доля неуспешных запросов оставалась высокой. В пике более половины запросов к Kimi K3 завершалось сбоем.
GitHub рекомендует отслеживать оперативную информацию и постфактум-отчёты об инцидентах на странице статуса, а также следить за техническими подробностями и работой по повышению устойчивости в инженерном разделе блога компании.
По данным GitHub, в июле было восемь инцидентов с ухудшением работы сервисов, а в июне — шесть. Отдельно компания опубликовала подробный отчёт по сбою 17 августа и мерам по улучшению устойчивости.
Источник: блог GitHub.
