GitHub розкрив деталі нещодавнього збою: що сталося

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Якщо пам’ятаєте, пару днів назад GitHub добряче штормило. Проблеми зачепили вебверсію, API, Actions, Issues, Pull Requests, Webhooks, Git Operations, Pages, авторизацію та Copilot. На піку близько 20% запитів до вебверсії та API завершувалися помилками, а для завантаження архівів і raw-файлів error rate доходив до 50%.

Тепер GitHub запостив детальний постмортем інциденту. І саме тому ми всі тут зібралися, правда ж?

Що саме сталося

Інцидент почався 17 серпня о 13:28 UTC у дата-центрі GitHub у Central US. На тлі нового піку трафіку один із допоміжних контейнерів Istio вперся у встановлений ліміт одночасних запитів.

За нормального сценарію тут мало б допомогти автоматичне масштабування, але система стежила за ресурсами основного сервісу і не враховувала навантаження на сам Istio. Тож основний сервіс ще виглядав достатньо здоровим і масштабування не запускалося.

Далі чотири вузли HAProxy вичерпали доступні ліміти з’єднань, що вдарило по автентифікації та інших сервісах GitHub. Ситуацію додатково погіршили повторні запити. Невдалі запити почали надсилатися знову й створювати ще більше навантаження на вже перевантажені внутрішні балансувальники.

Коли інженери призупинили проблемні вузли HAProxy і почали переводити частину трафіку з Central US у Northern Virginia, більшість сервісів поступово почала відновлюватися.

Але тут вилізла ще одна проблема :)

VS Code збільшив навантаження на Copilot у 10 разів

Затримані відповіді одного внутрішнього сервісу активували прихований баг у механізмі повторних запитів VS Code. Якщо отримати токен Copilot не вдавалося, клієнт міг створити кілька додаткових запитів, які теж починали повторюватися. У результаті Copilot Token Service, який зазвичай отримував приблизно 7000–9000 запитів на секунду, почав отримувати 70 000–100 000 RPS.

Важливо, що VS Code не спричинив початковий збій GitHub. На той момент основний інцидент уже тривав. Але лавина повторних запитів суттєво затягнула відновлення Copilot.

Щоб її зупинити, GitHub зменшив кількість повторних запитів на шлюзах, а потім почав повертати HTTP 403 для частини запитів до Copilot Token Service. Після стабілізації навантаження трафік повертали поступово.

Додатково відновленню заважали атаки з масовим автоматичним завантаженням даних із сервісів codeload. Причиною аварії вони не були, але створювали додаткове навантаження на інфраструктуру під час інциденту.

Таймлайн інциденту

Час (UTC)

Подія

13:28

Початок проблем

13:40

GitHub повідомляє про інцидент

14:04

~20% помилок у web/API, до ~50% під час завантаження архівів і необроблених файлів

16:36

Більшість основних сервісів суттєво відновилася

18:03

Відновився GitHub Actions

21:02

Відновився Copilot Token Service

21:15

Інцидент повністю закрито

Загалом збій тривав 7 годин 47 хвилин.

Після інциденту GitHub планує змінити правила автоскейлингу, щоб вони враховували навантаження на допоміжні компоненти Istio, провести аудит встановлених для нього обмежень, переглянути кількість повторних запитів і затримки між ними, а також виправити відповідний баг у VS Code. Окремо компанія планує покращити моніторинг навантаження на балансувальники та механізми перемикання трафіку між регіонами.

От і вийшло, що почалося все з одного ботлнеку, якого не помітила система, а далі механізми, покликані зробити систему стійкішою, допомогли розтягнути збій майже на вісім годин :)

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі