GitHub опубликовал подробное обращение технического директора Владимира Фёдорова о двух недавних инцидентах и планах по масштабированию инфраструктуры и повышению доступности сервиса на фоне резкого роста нагрузок, связанных с использованием ИИ и новых подходов к разработке.
По словам Фёдорова, в октябре 2025 года компания начала план по увеличению мощности инфраструктуры в 10 раз для улучшения отказоустойчивости. Однако к февралю 2026 года стало понятно, что необходимо проектировать платформу уже под 30-кратное увеличение текущего масштаба. Основная причина — быстрые изменения в способах разработки: с конца декабря 2025 года резко выросло использование агентных сценариев разработки, а также активность по созданию репозиториев, pull request, обращений к API, автоматизации и работе с крупными репозиториями.
Фёдоров отмечает, что рост нагрузки затрагивает сразу несколько подсистем. Один pull request может обращаться к хранилищу Git, проверкам слияния, защите веток, GitHub Actions, поиску, уведомлениям, правам доступа, вебхукам, API, фоновым задачам, кешам и базам данных. На больших масштабах небольшие неэффективности накапливаются: очереди растут, промахи кеша превращаются в нагрузку на базы данных, индексы отстают, повторные запросы усиливают трафик, а медленная зависимость ухудшает сразу несколько пользовательских сценариев.
Компания обозначила приоритеты: сначала доступность, затем ёмкость, затем новые функции. GitHub сокращает лишнюю работу, совершенствует кеширование, изолирует критичные сервисы, устраняет единичные точки отказа и выносит наиболее нагруженные участки в специализированные системы. Это включает уменьшение скрытых связей между сервисами, ограничение масштабов сбоев и плавное ухудшение работы отдельных функций при перегрузке подсистем.
В краткосрочной перспективе GitHub устранял разные узкие места, которые проявились быстрее, чем ожидалось. Среди шагов — перенос вебхуков с MySQL на другой бэкенд, переработка кеша пользовательских сессий, изменение схем аутентификации и авторизации для заметного снижения нагрузки на базы данных. Дополнительно компания использовала переезд в Azure, чтобы оперативно запустить больше вычислительных ресурсов.
Далее команда сосредоточилась на изоляции критичных сервисов, таких как git и GitHub Actions, от остальных нагрузок и на минимизации масштабов воздействия сбоев за счёт устранения единичных точек отказа. Работа началась с подробного анализа зависимостей и разных типов трафика, чтобы понять, какие компоненты нужно разделить и как уменьшить влияние атак на легитимный трафик. После этого задачи решались в порядке риска. Параллельно ускорили перенос производительно критичного кода из монолита на Ruby в Go.
Параллельно GitHub, уже начавший миграцию из собственных небольших дата-центров в публичное облако, приступил к планированию мультиоблачной архитектуры. По словам компании, долгосрочный переход к нескольким облачным провайдерам необходим для достижения нужного уровня устойчивости, низких задержек и гибкости.
Отдельный вызов — быстрый рост количества крупных монорепозиториев. За последние три месяца GitHub активно инвестирует в улучшения внутри системы git и в опыт работы с pull request для таких репозиториев. В ближайшее время появится отдельная публикация с описанием проделанной работы и новым дизайном API для повышения эффективности и масштабируемости, включая оптимизацию операций очереди слияния, что критично для репозиториев с тысячами pull request в день.
Фёдоров подробно описал два недавних инцидента, которые стали поводом для усиления фокуса на доступности и изоляции систем.
23 апреля произошла регрессия, затронувшая операции очереди слияния pull request. В случаях, когда группа слияния содержала более одного pull request и использовался метод squash-слияния, формировались неверные коммиты слияния: изменения из ранее объединённых pull request и прежних коммитов могли быть непреднамеренно отменены последующими слияниями. В период инцидента были затронуты 230 репозиториев и 2 092 pull request. Изначально GitHub публиковал немного большие числа из-за осторожной первичной оценки. Проблема не затронула pull request, объединённые вне очереди слияния, а также группы, использовавшие методы merge или rebase.
По данным GitHub, потери данных не было — все коммиты сохранились в Git. Однако состояние затронутых основных веток оказалось некорректным, и компания не смогла безопасно автоматически восстановить каждый репозиторий. Дополнительные подробности GitHub обещает предоставить в отдельном разборе причин инцидента. Этот случай выявил несколько проблем в процессах, которые теперь будут изменены, чтобы предотвратить повторение подобных ошибок.
27 апреля произошёл ещё один инцидент, связанный с подсистемой Elasticsearch, которая обслуживает функции поиска в разных частях GitHub, включая элементы pull request, задач и проектов. Причины всё ещё анализируются, детальный отчёт будет опубликован отдельно. На текущий момент известно, что кластер оказался перегружен, вероятно, из-за атаки ботнета, и перестал возвращать результаты поиска. Потери данных не было, операции Git и API не пострадали, однако части интерфейса, зависящие от поиска, не показывали результаты, что привело к серьёзному сбою в работе.
Фёдоров отметил, что система поиска ещё не была полностью изолирована как компонент, отказ которого нельзя допускать, так как другие зоны имели более высокий приоритет в плане рисков. Такое влияние компания считает недопустимым и применяет тот же подход анализа зависимостей и масштабов сбоев, чтобы снизить вероятность и эффект подобных отказов в будущем.
GitHub также получил от клиентов ясный сигнал, что им нужна большая прозрачность во время инцидентов. В ответ компания обновила страницу статуса, добавив данные о доступности, и взяла обязательство публиковать информацию о сбоях как крупного, так и малого масштаба, чтобы пользователям не приходилось гадать, проблема на их стороне или на стороне платформы.
Компания улучшает классификацию инцидентов, чтобы их масштаб и охват было проще понять, и работает над более удобными способами для клиентов сообщать о проблемах и передавать сигналы во время сбоев.
Фёдоров напомнил, что задача GitHub — поддерживать разработчиков на открытой и расширяемой платформе. Он подчеркнул, что команда внимательно относится к обратной связи: читает электронные письма, сообщения в соцсетях и обращения в поддержку. Руководство приносит извинения за доставленные неудобства и подчёркивает, что компания обязуется повышать доступность, укреплять устойчивость, масштабироваться под будущее разработки и более открыто коммуницировать о ходе этой работы.
В конце обращения кратко представлен профессиональный путь Владимира Фёдорова. Он занимает должность технического директора GitHub, имеет многолетний опыт в инженерном руководстве и выступает за повышение продуктивности разработчиков. До GitHub он соосновал стартап UserClouds, занимавшийся управлением данными и приватностью, 12 лет работал в Facebook (ныне Meta) на позиции старшего вице-президента, руководя командами более чем из 2 000 инженеров в направлениях приватности, рекламы и платформы, ранее работал в Microsoft. Фёдоров получил степени бакалавра и магистра по информатике в Caltech и входит в совет директоров Codepath.org, некоммерческой организации, которая готовит новое поколение инженеров и технических лидеров с фокусом на ИИ.
Источник: обращение Владимира Фёдорова, технического директора GitHub.
*Организация Meta (владелец Facebook и Instagram) признана экстремистской организацией и ее деятельность запрещена на территории России.
