Облачные вычисления и центры обработки данных

GitHub раскрывает причины сбоя 17 августа и объявляет меры по повышению надёжности платформы

GitHub заявила, что сбой 17 августа продолжался 7 часов 47 минут и был в основном вызван неспособностью критически важного компонента в центре обработки данных в США справиться с пиковым спросом, что привело к перебоям в работе сервисов платформы по всему миру. Компания намерена увеличить мощности, изолировать критически важные системы и ужесточить управление операциями повторных попыток и реакцией на внезапные нагрузки.

2026-08-20
3 мин. чтения
14 просмотров
فريق تحرير certi.news
GitHub раскрывает причины сбоя 17 августа и объявляет меры по повышению надёжности платформы

GitHub сообщила, что сбой, затронувший её платформу 17 августа и продолжавшийся 7 часов 47 минут, стал результатом неспособности критически важного инфраструктурного компонента масштабироваться при достижении трафиком рекордного уровня в центре обработки данных в центральном регионе США. Возникшее ограничение мощности привело к распространению проблем на несколько систем: пострадали github.com, аутентификация, GitHub Actions, API, запросы на слияние и задачи, а также Copilot. Последствия сбоя затронули разработчиков и организации по всему миру.

Этот инцидент стал вторым крупным происшествием, с которым GitHub столкнулась в августе, после сбоя в Actions 6 августа. Компания пояснила, что расследование не выявило связи между этими инцидентами и изменениями в коде или конфигурации; в обоих случаях причиной стала недостаточная мощность: ключевые компоненты не были масштабированы до того, как спрос превысил их возможности. По данным GitHub, количество ежемесячных операций отправки изменений выросло с 1,4 миллиарда в апреле до 2,9 миллиарда с того времени, однако компания признала, что рост использования не освобождает её от ответственности за предотвращение сбоев.

Как сервисы восстановились?

Для восстановления потребовались перенаправление трафика, изоляция затронутой инфраструктуры и поэтапный запуск сервисов. Большинство сервисов GitHub возобновили работу в тот же день, однако некоторым сервисам Copilot потребовалось больше времени. Ошибки в этих сервисах вызвали цикл повторных попыток на стороне клиента, что увеличило трафик во время восстановления и вынудило команды ограничить такое поведение, прежде чем безопасно перенаправить трафик.

GitHub заявляет, что полный отчёт с анализом первопричины содержит подробную техническую временную шкалу, а компания продолжает выполнять ранее объявленные обязательства по повышению доступности и надёжности.

Что меняется на практике?

План GitHub сосредоточен на увеличении мощности, повышении эффективности и устранении архитектурных узких мест. Компания объявила, что добавила более 3 миллионов ядер CPU и 120 петабайт высокоскоростного хранилища, а также дополнительные сетевые ресурсы. Кроме того, она установила максимально возможный объём оборудования в пределах доступной мощности в своих существующих центрах обработки данных и одновременно ускорила переход на Azure.

В настоящее время Azure обслуживает около 58% нагрузки платформы GitHub и половину операций Git по сравнению с 12% нагрузки платформы в мае. Это расширение также помогло поддержать рост числа запусков заданий GitHub Actions. Компания работает над новой архитектурой, которая позволит линейно увеличивать пропускную способность операций чтения в крупных репозиториях вместе с числом читателей, теоретически обеспечивая неограниченное количество операций чтения; её поэтапное внедрение начнётся с крупнейших монорепозиториев.

Сокращение масштаба сбоев и предотвращение штормов

GitHub не считает одного лишь масштабирования достаточным: компания направила дополнительные команды и ресурсы на обеспечение доступности, инвестировала в более строгие тесты, более безопасные процессы развёртывания, улучшенный мониторинг и более эффективные оповещения. Она также изолирует критически важные системы и устраняет общие зависимости между ними, чтобы снизить вероятность сбоя и ограничить его последствия, если он произойдёт.

На основании инцидентов 6 и 17 августа компания введёт единые ограничения и бюджеты для повторных попыток, а также переменные тайм-ауты при взаимодействии между сервисами, чтобы предотвратить штормы повторных попыток и каскадные нагрузки. Кроме того, она пересматривает низкоприоритетные оповещения о загрузке CPU и памяти, чтобы выявлять компоненты, которые могут выйти из строя во время внезапных скачков трафика. Эти меры имеют непосредственное значение для разработчиков и организаций, которые используют GitHub для создания, поставки и эксплуатации программного обеспечения, поскольку восстановление платформы зависит не только от возобновления работы сервиса, но и от предотвращения повторения сбоя и ограничения его масштаба, если он всё же произойдёт.

Источник новости
ف
Автор

فريق تحرير certi.news

В той же категории

Вам также может понравиться

Все новости