В GitHub объяснили инциденты с недоступностью платформы

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

«К февралю 2026 года стало ясно, что нам необходимо проектировать систему для будущего, требующего 30-кратного увеличения масштабов по сравнению с сегодняшними», — объяснили авторы.

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

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

Недавно на GitHub удалось устранить ряд узких мест: от переноса веб-хуков на иной бэкэнд (из MySQL) и перепроектирования кэша пользовательских сессий до переработки потоков аутентификации и авторизации для существенного снижения нагрузки на базу данных. Платформа равным образом использовала миграцию в Azure для развёртывания значительно большего количества вычислительных ресурсов.

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

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

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

Тем не менее, в апреле произошло два инцидента, которые различались по причинам и последствиям.

23 апреля в работе запросов на слияние произошла регрессия, затронувшая операции очереди слияния. Запросы на слияние, объединённые через очередь с использованием метода слияния squash, приводили к некорректным коммитам, если группа содержала более одного запроса. В результате изменения из ранее объединённых запросов на слияние и предыдущих коммитов непреднамеренно отменялись последующими слияниями.

В течение периода воздействия были затронуты 658 репозиториев и 2092 запроса на слияние. Проблема не затронула запросы на слияние, объединённые вне очереди, а также группы очереди, использующие методы слияния или перебазирования. При этом все коммиты остались сохранёнными в Git. Однако состояние затронутых веток по умолчанию было некорректным, и авторы не могли безопасно восстановить каждый репозиторий автоматически. 

27 апреля произошёл инцидент, затронувший подсистему Elasticsearch, которая обеспечивает работу нескольких поисковых систем GitHub, в том числе части запросов на слияние, задач и проектов. Пока известно, что кластер был перегружен (вероятно, из-за атаки ботнета) и перестал выдавать результаты поиска. Потери данных не произошло, операции Git и api не пострадали. Однако части пользовательского интерфейса, зависящие от поиска, не отображали результаты, что вызвало значительные сбои.

«Это одна из систем, которую мы ещё не полностью изолировали, чтобы исключить её как единую точку отказа, поскольку другие области были более приоритетными в нашей работе по обеспечению надёжности с учётом рисков. Такое воздействие неприемлемо, и мы используем тот же аналитика зависимостей и радиуса поражения, описанный выше, чтобы снизить вероятность и последствия подобных сбоев в будущем», — рассказывают разработчики.

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

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