GitHub опубликовал подробный отчёт о работе своих сервисов в апреле 2026 года. По данным компании, за месяц произошло 10 инцидентов, которые ухудшили производительность различных сервисов GitHub, включая поиск кода, Copilot, GitHub Pages, Codespaces, Actions и другие компоненты платформы.
Компания отмечает, что для повышения прозрачности в конце апреля был опубликован отдельный пост с разбором крупных сбоев 23 и 27 апреля, а также добавлено больше деталей на страницу статуса GitHub.
1 апреля 2026 года GitHub столкнулся сразу с двумя инцидентами.
Первый затронул сервис поиска кода. С 14:40 до 17:00 UTC поиск был полностью недоступен: 100% запросов завершались ошибкой. К 17:00 сервис восстановили в частично рабочем состоянии с устаревшими результатами, а к 23:45 UTC индекс полностью догнали до актуального состояния. Причиной стала череда ошибок при плановом обновлении инфраструктуры системы сообщений, поддерживающей поиск: автоматическое изменение было применено слишком агрессивно, нарушило координацию внутренних сервисов и остановило индексацию, а затем незапланированный деплой очистил внутреннее состояние маршрутизации и привёл к полной остановке поиска. Команда восстановила инфраструктуру через контролируемый перезапуск, переинициализировала индекс на момент до сбоя и провела полную переиндексацию. Репозитории не пострадали, так как поиск использует вторичный индекс, построенный на основе Git-хранилищ. В ответ GitHub вводит более поэтапные обновления с расширенными проверками состояния, защиту от нежелательных деплоев во время инцидентов, более быстрые инструменты восстановления и улучшенную изоляцию трафика.
Второй инцидент 1 апреля затронул сервис журнала аудита. С 15:34 до 16:02 UTC, в течение 28 минут, журнал аудита потерял соединение с базой данных из-за ошибочной ротации учётных данных. История аудита была недоступна через API и веб-интерфейс, что привело к ошибкам 5xx для 4 297 API-актеров и 127 пользователей github.com. События, созданные в этот период, задержались до 29 минут, но в итоге были успешно записаны и переданы, потерь данных не было. Пользователи GitHub Enterprise Cloud с требованиями к размещению данных не пострадали. Команда обнаружила проблему через 6 минут, восстановила работу перезапуском среды и усилила процесс ротации учётных данных, а также сделала мониторинг более чувствительным для ускорения обнаружения подобных сбоев.
9 апреля 2026 года проблемы затронули сервис Copilot coding agent. В течение двух промежутков, с 09:05 до 19:05 UTC и с 16:05 до 20:36 UTC, пользователи сталкивались с серьёзными задержками при запуске новых сессий агента. Около 84% запросов на создание сессий были задержаны в рамках четырёх волн инцидента, время ожидания в очереди достигало 54 минут при обычных 15–40 секундах. Средний уровень ошибок составил 83,9% с пиком в 97,5%, было задержано или прервано примерно 22 700 созданий workflow. Причина — ошибка в логике ограничения частоты запросов, которая применяла лимит глобально ко всем пользователям вместо изоляции по конкретной установке. Ситуацию усугубил рост API-трафика в 3–4 раза из-за обновления клиента, что ускорило исчерпание лимитов. Повторный инцидент был связан с превышением лимитов внутренним сервисом и ошибкой кеширования, которая удерживала состояние «превышен лимит» дольше, чем полагалось. Проблему обнаружили за 15 минут, снизили влияние, отключив некорректный механизм кеширования и переведя вызовы API на учётные данные уровня установки, чтобы лимиты применялись по отдельным инсталляциям. Задержанные задания были обработаны после восстановления сервиса. GitHub добавил автоматический мониторинг для этого типа отказов, оптимизировал кеширование для снижения избыточного трафика и продолжает работу по более строгой изоляции лимитов по типам клиентов.
13 апреля 2026 года произошёл крупный сбой GitHub Pages. С 18:53 до 20:30 UTC средний уровень ошибок достигал 10,58% с пиком 12,77%, в результате чего около 17,5 миллиона запросов завершились ответом HTTP 500. Причиной стала ошибка автоматизированного DNS-инструмента, который удалил запись для одного из backend-хостов хранения GitHub Pages после того, как вышестоящий источник данных периодически не возвращал эту запись, и система посчитала её устаревшей. По мере истечения кешей запись перестала резолвиться, и сервера Pages потеряли доступ к хосту хранения, что вызвало ошибки части запросов. После обнаружения команда оперативно восстановила DNS-запись, сервис стабилизировался к 20:30 UTC, а к 20:35 UTC инцидент был полностью закрыт. Обнаружение заняло около 53 минут из-за плавного роста ошибок и пробела в системе оповещений. Для предотвращения повторения GitHub внедряет маршрутизацию с учётом зон доступности, чтобы при недоступности хоста происходил автоматический переход на здоровые, добавляет защиту от автоматического удаления DNS-записей, за которые отвечают другие системы, и улучшает логирование и алертинг ошибок DNS в цепочке обработки GitHub Pages.
16 апреля 2026 года сбой произошёл в GitHub Codespaces. С 09:30 до 17:15 UTC около 40% операций запуска сред разработки через редактор VS Code завершались неудачно. Подключения по SSH при этом работали штатно. Проблему вызвали сбои во внешнем сервисе, который не позволял получать VS Code Server при запуске Codespace. Влияние снизили через обходное решение с альтернативным путём загрузки, когда основной endpoint деградирован, параллельно команда внешней зависимости устраняла первопричину. GitHub улучшает механизм резервного пути и ускоряет развёртывание подобных изменений для сокращения последствий подобных сбоев.
20 апреля 2026 года GitHub столкнулся с долгосрочным ухудшением работы сервисов code scanning, оценки качества кода и проектных досок. С 10:28 до 15:04 UTC наблюдалась деградация этих функций, а восстановление затронутых проектных досок продолжалось до 05:04 UTC 21 апреля. В течение этого времени не запускались проверки code scanning по умолчанию и анализ качества кода для новых pull request, а новые задачи не появлялись на проектных досках. Причиной стала ошибка сериализации, которая блокировала корректный запуск этих процессов. Проблему обнаружили примерно через 40 минут и устранили деплоем исправления, восстановив публикацию событий для code scanning и качества кода. Для проектных досок потребовалось дополнительное изменение потребителей событий и переиндексация элементов проектов. В ответ GitHub усиливает проверку схем данных, улучшает мониторинг падения публикаций по ключевым темам и проводит аудит остальных частей системы на предмет аналогичных ограничений.
22 апреля 2026 года пользователи столкнулись с ошибками при работе с Copilot Chat на github.com и Copilot Cloud Agent. С 15:16 до 19:18 UTC эти сервисы были недоступны, а функциональность Copilot Memory (в предварительном просмотре) также отсутствовала в сессиях агента. Причиной стало изменение конфигурации инфраструктуры, вызвавшее проблемы с подключением к базам данных. Команда выявила источник и восстановила соединения, Copilot Chat и Cloud Agent на github.com вернулись в строй к 18:16 UTC, остальные региональные развертывания восстанавливали поэтапно до 19:18 UTC. GitHub принял меры, чтобы аналогичные изменения инфраструктуры не приводили к такому типу операций с базами данных в будущем.
23 апреля 2026 года произошёл крупный инцидент, затронувший сразу несколько сервисов: GitHub Copilot, Webhooks, Git Operations, GitHub Actions, миграции и деплойменты. С 16:03 до 17:30 UTC ошибки и задержки коснулись примерно 5–7% общего трафика. Для Copilot около 7% запросов к моделям ИИ завершались неудачей, 10% сессий Copilot cloud agent были затронуты, 9% запросов к панели Copilot Insights возвращали ошибки. Для Webhooks до 0,35% API-запросов на пике завершались ошибкой, до 10% трафика испытывали задержки более 3 секунд. Git-операции в среднем давали 1,25% ошибок с пиком 2,07%. В GitHub Actions обновление статуса workflow задерживалось до 8 секунд. В миграциях 0,88% активных миграций репозиториев завершились неудачей, у 79% возросло время выполнения. Деплойменты были временно заблокированы на период инцидента. Причиной стала деградация DNS-инфраструктуры в одном из дата-центров, из-за чего периодически переставали резолвиться адреса сервисов, а зависимые от DNS компоненты начинали массово выдавать ошибки. Корневой причиной оказался новый механизм балансировки трафика, который внедряли поэтапно для масштабирования; при определённой нагрузке он приводил к отказам резолверов. Локальный DNS-кеш частично сгладил эффект, поэтому пострадала часть трафика, а не всё обслуживание. После безуспешного отката конфигурации команда перезапустила затронутую DNS-инфраструктуру, и сервисы начали восстанавливаться в течение нескольких минут, полностью нормальная работа вернулась к 17:30 UTC. Потери данных не зафиксированы. Для предотвращения похожих инцидентов GitHub повышает устойчивость DNS-инфраструктуры к сбоям целых дата-центров, внедряет более безопасные сценарии выката и проверки изменений на стендах с нагрузкой, близкой к боевой, инвестирует в более быстрое автоматическое обнаружение и самовосстановление при сбоях DNS, а также пересматривает зависимости сервисов от общей инфраструктуры для уменьшения масштаба влияния.
27 апреля 2026 года проблемы затронули поисковые сервисы GitHub. С 16:15 до 22:46 UTC наблюдалась деградация соединений из-за перегрузки уровня балансировки нагрузки перед поисковой инфраструктурой. Это привело к прерывистым отказам сервисов, которые используют поиск, включая Issues, Pull Requests, Projects, репозитории, Actions, Package Registry и Dependabot Alerts. В зависимости от типа поиска отдельные сервисы видели до 65% таймаутов или ошибок между 16:15 и 18:00 UTC. Инцидент был зафиксирован по падению доли успешных поисковых запросов в 16:21 UTC, как частично устранён — в 21:33 UTC, а окончательно закрыт в 22:46 UTC. Причиной стала крупная волна распределённого анонимного сканирования, которая была специально сформирована так, чтобы обходить публичные лимиты API. Этот трафик составил около 30% всего поискового трафика дня, но был концентрирован в четырёхчасовом окне и исходил более чем с 600 000 уникальных IP-адресов с одинаковой акторной информацией в запросах. Действующий мониторинг не классифицировал рост такого трафика как риск, и этот фактор выявили уже в процессе борьбы с инцидентом. Для снижения нагрузки команда сосредоточилась на разгрузке балансировщиков, масштабировании уровня балансировки, блокировке аномального трафика и настройке параметров работы балансировщиков до полного восстановления. В дальнейшем GitHub расширил мощность уровня балансировки, оптимизировал обработку и переиспользование соединений для снижения вероятности повторной перегрузки, добавил новые механизмы контроля и ограничений анонимного трафика и усиливает защиту от крупномасштабных автоматизированных злоупотреблений.
GitHub напоминает, что следить за текущим состоянием сервисов и краткими отчётами после инцидентов можно на странице статуса платформы. Дополнительные технические детали и материалы о внутренней инженерной работе публикуются в разделе engineering в блоге GitHub.
Источник: блог GitHub.
