GitHub объяснил семичасовой сбой 17 августа перегрузкой инфраструктуры

· Технологии
Технический директор GitHub рассказал, что второй за август крупный сбой был вызван не ошибкой в коде, а нехваткой мощностей: сервис не успел масштабироваться под рекордный трафик.

cover.svg

17 августа GitHub был недоступен 7 часов 47 минут. Сбой затронул github.com, аутентификацию, GitHub Actions, API, работу с pull request'ами, issues и Copilot — пострадали разработчики и организации по всему миру. Технический директор компании Владимир Фёдоров признал: «Если в тот день вы пытались выпустить свой продукт, мы вас подвели».

Это уже второй серьёзный инцидент за август — 6-го числа отказали GitHub Actions. По словам Фёдорова, ни один из сбоев не был вызван изменениями в коде или конфигурации. В обоих случаях причиной стала нехватка мощностей: критические компоненты не успели масштабироваться прежде, чем спрос превысил их возможности.

Что произошло

Сбой 17 августа начался, когда трафик достиг нового пика, а ключевой компонент инфраструктуры в дата-центре Central US не смог масштабироваться вслед за нагрузкой. Возникшее давление на ёмкость распространилось по системам, вызвав отказы аутентификации. Восстановление шло поэтапно: команды перенаправляли трафик, изолировали затронутую инфраструктуру и поэтапно возвращали сервисы. Дольше всего восстанавливался Copilot — ошибки в нём запустили цикл повторных запросов на стороне клиента, из-за чего трафик рос прямо во время восстановления, и этот эффект пришлось гасить отдельно.

Причину роста нагрузки Фёдоров объясняет масштабом самого сервиса: с апреля число ежемесячных коммитов выросло с 1,4 до 2,9 миллиарда. «Это объясняет давление на наши системы, но не оправдывает сбои», — подчёркивает он.

Что уже сделано

В рамках заявленных ранее обязательств по надёжности GitHub добавил более 3 миллионов ядер CPU, 120 петабайт высокоскоростного хранилища и заметно нарастил сетевую ёмкость — установив столько оборудования, сколько позволяли энергетические лимиты существующих дата-центров, и одновременно ускорив миграцию в Azure. Сегодня на Azure приходится около 58% нагрузки платформы и половина всех Git-операций против 12% в мае.

Следующая веха — архитектура, в которой ёмкость чтения растёт линейно с числом читателей, что снимает ограничения на операции чтения. Её будут разворачивать постепенно, начиная с крупнейших монорепозиториев.

По итогам обоих августовских инцидентов приняты два немедленных изменения. Во-первых, для взаимодействий между сервисами вводятся единые лимиты и «бюджеты» повторных запросов, а также переменные тайм-ауты — чтобы предотвращать «штормы» ретраев и каскадную нагрузку. Во-вторых, компания пересматривает низкоприоритетные оповещения по CPU и памяти, чтобы находить компоненты, способные отказать при внезапных всплесках трафика. Параллельно GitHub изолирует критические системы и убирает общие зависимости между ними.

«Доверие мы заработаем масштабированием и надёжностью платформы», — заключает Фёдоров.


Источник: GitHub Blog

Комментарии

Войдите, чтобы комментировать.

  • Пока нет комментариев.