GitHub раскрыла подробности пяти инцидентов, повлиявших на доступность её служб в августе 2026 года. Среди них — сбои в GitHub Actions, задержки результатов Copilot Cloud Agent и сбои запросов к модели Kimi K3. Компания связывает инциденты с ростом платформы и сокращением запасов ёмкости, а также с дефектами автоматического масштабирования, политик повторных попыток и механизмов восстановления.
GitHub заявляет, что инвестирует в совершенствование архитектуры и перенос дополнительных служб в Azure, отдавая приоритет доступности, затем ёмкости и затем функциям. Компания также объявила об улучшениях в мониторинге ёмкости, управлении очередями, политиках повторных попыток и устойчивости базовых служб.
Пять инцидентов с разными причинами
- 6 августа: инцидент продолжался 10 часов 42 минуты после того, как обычное развёртывание внутренней службы в Actions временно сократило ёмкость в одном из мест размещения. Это привело к насыщению служб и распространению ошибок на кэширование, DNS и API-интерфейсы, после чего дефект в процессе назначения задач замедлил восстановление. Значительная доля рабочих процессов завершалась с ошибками или задержками, а некоторые события пришлось перезапускать вручную.
- 17 августа: ухудшение продолжалось 7 часов 35 минут из-за того, что балансировщики нагрузки в центре обработки данных достигли пикового уровня ёмкости, а вспомогательный компонент сервисной сети не масштабировался, несмотря на достижение предела параллелизма. Это вызвало задержки и сбои в общем процессе аутентификации, затронув Issues, Pull Requests, API-интерфейсы, Actions и Copilot. Кроме того, дефект механизма повторных попыток увеличил поток запросов к внутренней точке аутентификации.
- 20 августа: инцидент продолжался 9 часов 54 минуты и затронул состояние и результаты задач Copilot Cloud Agent как минимум в 54 организациях. Вышла из строя зона у поставщика облачной базы данных, в которой хранилось состояние задач, а региональное переключение не сработало быстро из-за настройки хранилища, что привело к накоплению обновлений состояния. Сами задачи не были потеряны, однако отображение результатов задержалось до восстановления обработки и опустошения очереди.
- 26 августа: ухудшение продолжалось 2 часа 50 минут, когда поток событий довёл общую базу данных, работавшую почти на пределе, до состояния насыщения. Это вызвало задержки при запуске операций Actions и повлияло на зависящие от них службы, такие как Copilot Code Review и некоторые операции GitHub Pages. GitHub пришлось постепенно ограничивать входящую нагрузку, поскольку автоматического размыкателя цепи, который включал бы защиту при появлении признаков перегрузки, не было.
- 27 августа: инцидент продолжался 2 часа 8 минут и затронул только запросы к модели Kimi K3 в Copilot из-за ухудшения работы внешнего поставщика модели. В пик инцидента доля сбоев этих запросов превысила половину, тогда как другие модели и настройка Auto оставались доступными.
Что изменилось на практике?
Объявленные меры показывают, что GitHub рассматривает инциденты как проблемы ёмкости, изоляции и восстановления, а не просто как отдельные ошибки развёртывания. Компания перенесла 33% рабочих нагрузок Actions из ограниченного производственного кластера в резервную ёмкость, что снизило пиковое использование процессора кэширования с 98% до 80% и, по её оценке, добавило около трёх месяцев запаса. При этом пиковая загрузка служб, перенесённых в Azure, достигла 60,4%, загрузка монолитной системы — 64,3%, а загрузка Git — 54%.
На уровне баз данных 11 августа в Azure была запущена первая производственная первичная MySQL без заметного влияния на операции записи, наблюдаемые клиентами, а 27 августа тот же подход был повторён для двух основных баз данных. Кроме того, GitHub удалила около миллиона запросов в секунду из устаревших реплик базы данных, а другие изменения сократили ещё 120 тысяч запросов в секунду и примерно 59 тысяч секунд напрасно затрачиваемой работы в час.
Почему важен этот отчёт?
Инциденты показывают, что одной лишь горизонтальной масштабируемости недостаточно, когда службы используют общие базы данных, пути аутентификации или единую инфраструктуру Actions. Кроме того, неконтролируемые повторные попытки могут превратить частичное ухудшение в более широкую нагрузку, тогда как задержка переключения между регионами может привести к накоплению состояний даже в тех случаях, когда исходные задачи не теряются. План перехода в Azure, меры изоляции и механизмы ограничения нагрузки всё ещё находятся в процессе реализации, поэтому отчёт не доказывает, что риски устранены; он лишь показывает, на чём GitHub сосредоточит дальнейшую работу: переносе дополнительных базовых компонентов, автоматизации управления ёмкостью и расширении обработки сбоев зависимостей.