GitHub опубликовал развёрнутый отчёт о работе своей платформы за август и сентябрь, сосредоточившись на инцидентах с производительностью, миграции сервисов в Azure и улучшении устойчивости ключевых компонентов, включая GitHub Actions, базу данных и сервисы на базе ИИ.
В августе было зафиксировано пять инцидентов с деградацией работы сервисов GitHub, в июле — восемь. В сентябре компания столкнулась ещё с двумя случаями ухудшения производительности.
По данным GitHub, к 7 октября в регионе Azure 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 ТБ потенциально восстанавливаемого пространства. Число блокировок (deadlocks) за неделю снизилось примерно на 77% от июньского максимума, при этом непрерывная очистка теперь препятствует повторному бесконтрольному росту данных.
GitHub также улучшил устойчивость работы с pull requests. Теперь половина проверенного трафика pull requests может продолжать обработку с частично ограниченным функционалом при отказе общей зависимости. В продукционном контуре часть операций чтения оставалась доступной даже во время инцидента с общей базой данных.
Маршрутизация трафика баз данных получила возможность автоматического добавления ресурсов при всплесках нагрузки. Например, одна группа экземпляров увеличилась с 14 до 19 во время роста активности по pull requests 23 сентября. В продукционную среду введён механизм контроля перегрузки, который позволяет приоритетно защищать более важные API и веб-сценарии, заранее отклоняя низкоприоритетные запросы до наступления общего насыщения. Документация и обучение операторов по этим процедурам завершены.
Отдельное внимание уделено GitHub Actions. Внесённые изменения снизили зафиксированное число операций Redis примерно на 28% и относительную загрузку CPU на 30%. Дополнительный уровень кеширования инфраструктуры уменьшил потребление полосы Redis на 84%, среднее время ответа — на 66%, медианное время ответа для основного запроса инвентаризации — на 96%, а число запросов в очереди — на 95%.
GitHub подчёркивает, что инциденты 6 августа (сбой GitHub Actions), 17 августа (сбой github.com), сентябрьский сбой при переключении базы данных и контролируемая пауза по наращиванию мощностей показывают: измеримые улучшения важны только тогда, когда они снижают риск для клиентов в реальных условиях. Основной принцип приоритезации работ формулируется как «сначала доступность, затем ёмкость, затем новые функции».
Во время одного из инцидентов пользователи могли сталкиваться с ошибками, задержками и «подвисшими» запросами при открытии или обновлении issues и pull requests, вызове API, создании токенов доступа, запуске GitHub Actions и регистрации новых аккаунтов. По данным компании, около 96% запросов на создание issues через веб-интерфейс столкнулись с проблемами, 90% новых регистраций и примерно 4% workflow GitHub Actions испытывали прерывистые сбои.
Причиной стал фоновый процесс очистки данных, который увеличил нагрузку на общую базу. У задачи был защитный механизм, замедляющий запись при отставании реплик, но он не учитывал приходящую нагрузку на основной сервер базы данных. В результате задача продолжала работу, пока основной сервер не исчерпал лимит подключений. Когда лимит был достигнут, зависящие от этой базы запросы перестали выполняться стабильно.
Два дополнительных фактора усилили эффект и затянули восстановление. Во-первых, у запросов к базе не было короткого тайм-аута, поэтому обработчики запросов ждали ответа от зависшей базы вместо быстрого отказа. Во-вторых, механизм повторных попыток при создании токенов отправлял записи, которые уже не проходили, и этим удерживал базу в насыщенном состоянии, не давая ей восстановиться.
Общая продолжительность этого инцидента составила около 2 часов 45 минут.
Отдельно GitHub описал инцидент с сервисом Copilot code review, который затронул github.com и регионы с требованиями к размещению данных (GHEC). Нагрузка пришлась на Copilot code review, где клиенты наблюдали, как сервис «зависает» в состоянии проверки без появления результата. Задержки достигали до 2 часов, при этом часть запросов обрабатывалась с задержкой около 30 минут.
Некоторые проверки на github.com завершались успешно, но в регионах с привязкой данных к месту хранения этого не происходило. Часть клиентов получала отложенные сообщения об ошибках по запросам, сделанным в период сбоя.
Copilot code review использует отдельный сервис, который возвращает два варианта результата: ограниченную версию без комментариев и полную с готовым обзором кода. Публикация происходит только на основе полной версии. Изменение в этом сервисе привело к тому, что полная версия возвращалась только части клиентов, а остальным отправлялась лишь ограниченная копия.
В такой конфигурации Copilot code review не мог сформировать итоговый обзор, но одновременно сообщал, что задача завершилась успешно. Недостаточный мониторинг не позволил сразу заметить отсутствие полной версии результата. Инцидент был обнаружен только после того, как некоторые проверки оставались незавершёнными более 30 минут и сработало оповещение для дежурных.
GitHub напоминает, что актуальную информацию о статусе сервисов и послерелизные разборы инцидентов можно отслеживать на странице статуса платформы и в инженерном разделе GitHub Blog. Компания также публикует материалы по ИИ и машинному обучению, DevSecOps с применением автоматизации, лучшим практикам разработки в распределённых командах и использованию подхода retrieval-augmented generation (RAG) для работы с данными.
Источник: инженерный блог GitHub и статус-отчёты компании.
