В отчёте о доступности за сентябрь 2026 года GitHub раскрыла подробности двух инцидентов, повлиявших на производительность её сервисов, одновременно сообщив о прогрессе в перераспределении инфраструктуры и повышении устойчивости баз данных к нагрузке. Компания отмечает, что работы по устранению проблем ещё не завершены, несмотря на внедрение изменений, направленных на снижение риска сбоев при росте нагрузки или отказе общего компонента.
По состоянию на 7 октября в регионе Central US были развёрнуты 120 из 160 производственных сервисов, а также перенесены 13 из 51 основной базы данных MySQL. На Azure приходилось 65,4% трафика чтения основного приложения GitHub, 48,3% трафика чтения Git и 80,2% трафика обработки потоков. Компания подчёркивает, что эти показатели относятся к разным нагрузкам и их не следует складывать.
Прогресс в переносе инфраструктуры с отставанием от графика
11 сентября GitHub приостановила развёртывания и увеличение трафика в Central US из-за дисбаланса ёмкости между зонами доступности. Постоянное наращивание было возобновлено 18 сентября после предоставления временной ёмкости, однако долгосрочные работы по увеличению ёмкости всё ещё продолжаются; цель — обеспечить всю доступную ёмкость к концу октября. Компания не достигла амбициозной цели развернуть там все производственные сервисы к 30 сентября.
Во время плановой миграции базы данных автоматическая аварийная процедура отключила реплики баз данных в Central US, что вызвало сбои в работе клиентов в регионе. GitHub отключила эту процедуру во время плановых переключений до улучшения механизмов восстановления.
Снижение нагрузки на базы данных и локализация сбоев
GitHub перенесла 24 таблицы из основной системы аутентификации со своей старейшей общей базы данных, что устранило около миллиона запросов в секунду на репликах. Кроме того, из кластера, поддерживающего Issues и Pull Requests, удалили около 980 миллионов ненужных записей из истории изменений, освободив примерно 1,8 терабайта восстанавливаемого хранилища. Еженедельное число конфликтов между транзакциями снизилось примерно на 77% по сравнению с пиковым значением в июне.
Половина попавших в выборку операций Pull Requests теперь может продолжаться с ограниченной функциональностью при отказе общей зависимости. Маршрутизация трафика баз данных также может автоматически добавлять ёмкость во время пиков: одна из групп расширилась с 14 до 19 реплик во время роста активности Pull Requests 23 сентября. GitHub добавила механизм управления нагрузкой, позволяющий отклонять запросы с более низким приоритетом до того, как сервисы достигнут более широкого насыщения.
Два сентябрьских инцидента
13 сентября фоновая задача очистки данных увеличила нагрузку на общую базу данных. Механизм защиты отслеживал задержку реплик, но не контролировал накопленную нагрузку на основном сервере, которая достигла предела доступных подключений. Отсутствие короткого тайм-аута для запросов заставило обработчики запросов оставаться в ожидании, а цикл повторных попыток продолжил отправлять неудачные операции записи. Инцидент продолжался 1 час 28 минут и завершился после снижения внутренней нагрузки и остановки задачи.
28 сентября изменение в сервисе, выполняющем проверки кода Copilot, привело к отправке некоторым клиентам ограниченной версии результатов проверки вместо полной версии с комментариями. Поэтому задачи выглядели завершёнными, хотя проверки не отображались в запросах на слияние. Инцидент продолжался 52 минуты; GitHub устранила его, откатив изменение, и попросила клиентов повторно запросить затронутые проверки.
Что меняется на практике?
Эти два инцидента показывают, что одних улучшений ёмкости недостаточно: надёжность также зависит от раннего обнаружения сбоев, прекращения бесполезных повторных попыток и гарантии того, что задача не будет объявлена успешной до фактической передачи её результатов. GitHub работает над добавлением средств управления фоновой обработкой, улучшением поведения сервисов при запуске, а также усилением мониторинга и доставки результатов Copilot code review.
GitHub также зафиксировала улучшения в инфраструктуре GitHub Actions: число измеренных операций Redis снизилось примерно на 28%, а относительное использование процессора — примерно на 30%. Отдельный уровень кэширования сократил используемую Redis пропускную способность на 84%, среднее время отклика — на 66%, медианное время отклика основного запроса к хранилищу — на 96%, а число ожидающих запросов — на 95%. Открытые вопросы по-прежнему связаны со способностью компании завершить работы по увеличению ёмкости и предотвратить повторение сбоев общих зависимостей в реальных производственных условиях.