ИИтог

GitHub объяснил сбой 17 августа: второй крупный отказ за август из-за нехватки мощностей

инфраструктураРедакция ИИтогHacker News🔥75Рейтинг ИИтог75Влияние70Новизна35Релевантность85Неожиданность40Участники85Достоверность85

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

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

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

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

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

Текст опубликован от лица компании, ведётся от первого лица и заканчивается биографией технического директора GitHub Владимира Федорова: до GitHub он был сооснователем стартапа UserClouds, специализирующегося на управлении данными и защите приватности, а до этого 12 лет проработал в Facebook (ныне Meta) старшим вице-президентом и руководил инженерными командами общей численностью более 2000 человек в направлениях приватности, рекламы и платформы; ещё раньше работал в Microsoft; степени бакалавра и магистра по компьютерным наукам получил в Caltech.

Ключевые факты

  • 17 августа сбой GitHub длился 7 часов 47 минут и задел github.com, аутентификацию, GitHub Actions, API, пул-реквесты, задачи и сервисы Copilot.
  • Это второй крупный отказ GitHub за август: 6 августа уже отказывал GitHub Actions.
  • Причина обоих инцидентов, нехватка мощности инфраструктуры (компонент в дата-центре Central US не справился с новым пиком трафика), а не ошибка в коде или конфигурации.
  • С апреля число коммитов на платформе выросло с 1,4 млрд до 2,9 млрд в месяц, рост нагрузки, который GitHub называет причиной, но не оправданием сбоев.
  • GitHub добавил более 3 млн ядер CPU и 120 петабайт хранилища и ускоряет перенос на Azure: сейчас на него приходится около 58% нагрузки платформы и половина операций с Git против 12% в мае.

Почему это важно

Это уже второй крупный сбой GitHub за август: 6 августа отказывал GitHub Actions, а 17 августа на 7 часов 47 минут легла сама платформа вместе с аутентификацией, Actions, API, пул-реквестами, задачами и Copilot. GitHub прямо признаёт: оба инцидента, не баг в коде и не ошибка конфигурации, а неспособность инфраструктуры вовремя масштабироваться под трафик, который вырос кратно (ежемесячные коммиты, с 1,4 млрд до 2,9 млрд с апреля). Иными словами, рост нагрузки на платформу обгоняет возможности инфраструктуры GitHub, и повторение подобных сбоев не исключено, пока капитальные вложения не закроют этот разрыв.

Кому это важно

В первую очередь, разработчикам и командам, чьи процессы завязаны на GitHub: без аутентификации и Actions останавливаются сборка, тестирование и доставка кода, ревью и мердж пул-реквестов, работа с задачами и Copilot. Дальше, инженерным руководителям, отвечающим за эксплуатацию (DevOps), которые оценивают риск полной зависимости от одного облачного хостинга для Git. И наконец, Microsoft: перенос GitHub на Azure (сейчас около 58% нагрузки платформы и половина операций с Git против 12% в мае), часть той же истории с мощностями, и её темп напрямую завязан на устойчивость GitHub.

Как это применить

Из поста следуют практические выводы для команд, зависящих от GitHub: не завязывать критичные релизы исключительно на доступность GitHub Actions и иметь запасной путь для выкладки кода на случай простоя; при подозрении на сбой сверяться со страницей статуса GitHub, а не тратить время на диагностику у себя; закладывать в собственные сервисы лимиты и бюджеты повторных запросов с переменными тайм-аутами, GitHub прямо называет неконтролируемый цикл повторных запросов в сервисах Copilot фактором, который продлил простой, и вводит аналогичные ограничения у себя между сервисами.

Можно ли доверять

Это первоисточник от самой компании: официальный блог GitHub, изложение от первого лица, в конце, биография технического директора Владимира Федорова. Пост честно называет причину (нехватка мощностей) и приводит конкретные цифры, длительность простоя, число добавленных ядер и объём хранилища, долю Azure, но это самоотчёт без независимой проверки: полный разбор первопричин и технический таймлайн упомянуты, но не приведены, точное название отказавшего инфраструктурного компонента не названо, а год у обеих августовских дат в тексте не указан.

Риски и подводные камни

Пока рост числа коммитов и автоматизации опережает планы GitHub по наращиванию мощностей, повторные сбои такого рода исключить нельзя, сама компания говорит только о том, что «ускоряет» эту работу, а не о том, что проблема закрыта. Ускоренный перенос на Azure, это ещё и рост зависимости от чужой инфраструктуры на фоне и без того возросшей сложности систем. А шторм повторных запросов в сервисах Copilot, который продлил простой 17 августа, показывает, что защитные механизмы вроде лимитов на повторные запросы появились у GitHub только сейчас, постфактум. Наконец, в тексте нет ни слова о компенсациях или скидках по SLA для пострадавших пользователей.

«Если в этот день вы пытались выпустить своё программное обеспечение, мы вас подвели.»

— GitHub, пост о сбое 17 августа

Компания Meta Platforms признана экстремистской организацией, её деятельность на территории РФ запрещена.