Разработчики объяснили, с чем связаны два последних инцидента с доступностью 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 аптайм проекта начал незначительно, но стабильно снижаться.
ссылка на оригинал статьи https://habr.com/ru/articles/1031774/