17 августа GitHub пережил сбой, продолжавшийся 7 часов 47 минут. Этот сбой нарушил работу github.com, аутентификации, GitHub Actions, API, pull request, issue и Copilot, затронув разработчиков и организации по всему миру. Если в тот день вы пытались выпустить программное обеспечение, мы вас подвели.
Это был второй серьезный инцидент в августе после сбоя Actions 6 августа. В марте и апреле я рассказывал о работе, которую мы проводили для повышения надежности GitHub. Мы добились прогресса, однако эти инциденты ясно показали, что нам необходимо ускорить эту работу.
Что произошло
Наше расследование показало, что сбой начался после того, как трафик достиг нового пикового значения, а критически важный компонент инфраструктуры в нашем дата-центре в центральной части США не смог масштабироваться в соответствии с этим трафиком. Возникшее в результате давление на мощности распространилось на наши системы, привело к ошибкам аутентификации и нарушило работу нескольких сервисов GitHub.
Для восстановления потребовалось предпринять несколько скоординированных шагов. Команды перенаправили трафик, изолировали затронутую инфраструктуру и поэтапно восстановили работу сервисов. Большинство сервисов GitHub восстановилось еще в тот день, однако некоторым сервисам Copilot потребовалось больше времени. Ошибки в этих сервисах вызвали клиентский цикл повторных попыток, который увеличивал трафик во время восстановления. Прежде чем мы смогли безопасно вернуть трафик, нам сначала пришлось смягчить это поведение. Комплексный анализ первопричины включает подробную техническую хронологию.
Обеим сбоям не стали причиной изменения кода или конфигурации. В основе обоих инцидентов лежала нехватка мощности. Мы не смогли масштабировать критически важные компоненты до того, как спрос превысил доступную мощность. С апреля ежемесячное количество коммитов выросло с 1,4 миллиарда до 2,9 миллиарда. Этот рост объясняет нагрузку на наши системы, но не оправдывает эти сбои.
Что мы сделали и что будет дальше
В рамках обязательств по обеспечению надежности, взятых в начале этого года, мы сосредоточились на трех приоритетах: наращивании мощности, повышении эффективности и устранении архитектурных узких мест. С тех пор мы добавили более 3 миллионов ядер CPU, 120 петабайт высокоскоростного хранилища и значительно увеличили сетевую мощность. В существующих дата-центрах мы устанавливали оборудование в пределах доступной мощности, одновременно ускоряя переход на Azure.
Сегодня Azure обслуживает примерно 58% платформенной нагрузки GitHub и половину всех операций Git; в мае этот показатель составлял 12% платформенной нагрузки. Эта расширяющаяся инфраструктура также поддержала рост количества запусков заданий GitHub Actions, показанный ниже.
Инфраструктура и мощности Azure также ускорили наши усилия по масштабированию крупнейших монорепозиториев. Следующая важная веха для нас — архитектура, которая масштабирует пропускную способность чтения линейно относительно количества читателей и делает возможным неограниченное количество операций чтения.
Мы будем постепенно вводить ее в эксплуатацию, начиная с крупнейших монорепозиториев.
Масштаб — не единственная проблема, с которой мы столкнулись. По мере роста скорости и сложности изменений наши текущие операционные практики перестали успевать за ними. Мы направили команды и ресурсы на обеспечение доступности, инвестировали в более тщательное тестирование, более безопасные процессы развертывания, улучшенную наблюдаемость и более эффективные механизмы оповещения. Мы добились прогресса, однако эта работа еще не завершена.
Кроме того, мы изолируем критически важные системы друг от друга и устраняем общие зависимости между ними. Эта работа направлена на снижение вероятности возникновения сбоя и ограничение его воздействия в случае сбоя.
Мы извлекаем уроки из каждого сбоя и добавляем новые задачи в план работ по обеспечению доступности. События 6 августа и 17 августа привели к двум неотложным изменениям.
Во-первых, чтобы предотвратить штормы повторных попыток и каскадную нагрузку, мы внедряем согласованные ограничения на количество повторных попыток, бюджеты повторных попыток и переменные значения тайм-аутов во взаимодействии между сервисами. Во-вторых, мы пересматриваем предупреждения низкого приоритета о CPU и памяти, чтобы выявлять компоненты, которые могут выйти из строя во время резких скачков трафика.
Наша приверженность высокой доступности — это не просто техническое обещание.