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