GitHub: 7 часов 47 минут простоя 17 августа и план ускорения работ по надёжности
The August 17 outage, and the work ahead
17 августа GitHub пережил сбой, длившийся 7 часов 47 минут, который затронул github.com, аутентификацию, GitHub Actions, API, pull request'ы, issues и Copilot. Компания сообщает, что причиной стал новый пик трафика, с которым не справился критический компонент инфраструктуры в центральном дата-центре США; ни код, ни конфигурация не были причиной. C апреля по август месячное число коммитов выросло с 1,4 млрд до 2,9 млрд. GitHub уже добавил более 3 млн CPU-ядер и 120 петабайт высокоскоростного хранилища, а Azure теперь обслуживает около 58% нагрузки платформы и половину всех Git-операций (в мае — 12%).
Если вы пытались в тот день выпустить программное обеспечение, мы вас подвели.
- afc
> Обе инцидента по своей сути были отказами из-за нехватки ёмкости. Мы не смогли масштабировать критически важные компоненты до того, как спрос превысил их ёмкость.
Это неправильный подход к проблеме, потому что бесконечной ёмкости не существует. Большая распределённая система будет одновременно в основном простаивать и (в некоторых подкомпонентах) перегружена. Корневая причина не в том, что «компоненту не хватило ёмкости (из-за сбоев автоскейлинга)», а в том, что «эта сложная система разрушается (а не деградирует плавно), когда спрос превышает ёмкость».
Когда компоненты достигают пределов ёмкости, избыточный трафик самого низкого приоритета должен отклоняться. Отклонённый трафик не должен повторяться — на самом деле, клиенты не только не должны повторять эти ошибки, эти ошибки должны вызывать троттлинг на стороне клиента. Должна применяться изоляция трафика — если причиной перегрузки является одна клиентская/пользовательская система, никакая другая система не должна страдать.
Почти десять лет назад я писал о некоторых методах, которые мы применяли в Google для реализации этих защит: https://sre.google/sre-book/handling-overload/ Большинство других крупных интернет-сервисов с тех пор их скопировали, насколько я знаю.
- prennert
Почему GitHub не разделяет бесплатные предложения и корпоративные, или ещё лучше, все платные?
Недопустимо, что корпоративные планы страдают от трафика на бесплатных и публичных репозиториях. Наши репозитории не на бесплатном плане и не открыты. У нас не было больше ИИ-активности за последние недели. Наш трафик стабилен. Готов поспорить, что у большинства предприятий не было внезапного скачка трафика. Даже если и был, мы платим за наши квоты. Всё равно наши GitHub Actions ломались, и наши PR иногда не отображались.
Я надеюсь, что эта нестабильность вызовет кембрийский взрыв форджей, и если это произойдёт, GitHub станет первой жертвой ИИ-революции.
Я сейчас работаю над по-настоящему децентрализованным / локальным ревью кода, и большая часть моей мотивации — это то, насколько плохим стал GitHub. Не знаю, хватит ли мне времени на CI, но надеюсь, что другие сделают. Иначе я просто откачусь к Jenkins.
- blakesterz
"С апреля ежемесячное количество коммитов выросло с 1,4 миллиарда до 2,9 миллиарда."
Вау, это невероятный рост за очень короткое время.
- madrox
Я аплодирую GitHub. Однако думаю, что, какими бы доблестными они ни были, им не выбраться из этой ямы. Проблема масштаба будет только усугубляться, и она усугубляется так, что, по-моему, не приносит им больше денег. Рано или поздно им придётся брать плату за то, что сейчас бесплатно.
Я уже давно это говорю: https://news.ycombinator.com/item?id=47534499
- aesthetics1
> С апреля ежемесячное количество коммитов выросло с 1,4 миллиарда до 2,9 миллиарда
С ума сойти.
Видно, что вся индустрия в «панике по продуктивности», и вот ещё одно доказательство. Где-то фанатик скорости плачет от радости.
- arn3n
Все, кто предлагает просто брать с пользователей плату за коммиты, чтобы отпугнуть активных пользователей ИИ, забывают, что GitHub принадлежит Microsoft, у которой есть большой стимул продолжать использовать ИИ разработчиками.
Подозреваю, что Microsoft даже предпочла бы, чтобы GitHub работал в убыток, если бы этот убыток был из-за того, что все его пользователи используют их модели и платят за подписки OpenAI для генерации кода.
- jdm2212
> Ошибки в этих сервисах вызвали цикл повторных попыток на стороне клиента, который увеличил трафик во время восстановления.
В самых худших сбоях, в которых я участвовал, всегда есть какая-то версия этого :(
- cube00
> Ошибки в этих сервисах вызвали цикл повторных попыток на стороне клиента, который увеличил трафик во время восстановления
Симптом более широкой тенденции избегать показа ошибки пользователю любой ценой, даже если это означает, что они сидят и смотрят на спиннер 7 часов.
> Задержки ответов на одну внутреннюю конечную точку вызвали скрытую ошибку повторных попыток в VS Code, которая увеличила трафик примерно в 10 раз и привела к задержке восстановления Copilot Token Service.
Подробный анализ первопричины пытается выдать это за «баг». Вы не можете серьёзно утверждать, что у клиентских повторных попыток нет юнит-теста, который гарантирует, что поведение экспоненциальной задержки работает точно так, как задумано. В данном случае агрессивно пытаясь скрыть проблемы, если ответы токен-сервиса становятся нестабильными.
- altcognito
Распределение по разным сервисам было бы неплохой идеей...
Всё равно не могу не испытывать некоторую благодарность за то, что они делают на бесплатной стороне. Я знаю, что это не альтруизм, и знаю, что никому не нужно защищать корпорацию с миллиардным оборотом, но...
Назовите другой сервис, который делает то же самое БЕСПЛАТНО (и без рекламы) в таком масштабе. Это нелегко. У Википедии, вероятно, больше использования, но это более простая задача (кроме модерации, это просто потрясающе). Open Street Map? Меньше и проще. Internet Archive? Опять же, меньше и проще. Зеркала дистрибутивов Linux? Опять же, меньше и проще, чем то, что GitHub делает бесплатно.
- Quarrelsome
Плохи ли повторные попытки?
Именно такие причины вызывают у меня общий дискомфорт. Я понимаю, что они могут быть полезны в сценариях, где связь по своей сути проблематична (например, мобильная связь), но для очень подключённого и очень настольного сервиса я бы предпочёл не повторять много, если вообще повторять. Это скрывает, когда что-то действительно пошло не так, и этот худший случай трагичен.
Мне кажется, что я немного глуп, пытаясь выставить повторные попытки ересью, но я не уверен.