Звіт GitHub: неправильно налаштована політика Istio і «шторм» повторів за збоєм тривалістю 7 год 47 хв

GitHub опублікував звіт про інцидент, який 17 серпня 2026 року порушив роботу платформи. Збій почався о 13:28 UTC, тривав 7 годин 47 хвилин і був повністю усунений о 21:15 UTC.

Що сталося

Перше публічне оновлення з'явилося о 13:40 UTC: компанія повідомила, що досліджує скарги на постраждалу продуктивність кількох сервісів. О 13:45 вона заявила про приблизно 20% помилок у Pull Requests, Issues та інших розділах, а подальші оновлення відзначали деградацію API-запитів, Actions, Webhooks і Pages. На піку рівень помилок у веб- та API-трафіку сягав близько 20%, а в завантаженні архівів і необробленого вмісту репозиторіїв — приблизно 50%. Постраждали також автентифікація SAML і OIDC, SCIM і Team Sync, а разом із ними — робочі процеси Actions у GitHub Enterprise Cloud з Data Residency, які залежать від публічних визначень кроків робочих процесів, розміщених на GitHub.com.

Більшість сервісів відновилися до 16:36 UTC, коли відновився дата-центр Central US. Actions залишався деградованим приблизно до 18:03 UTC, а Copilot Token Service повністю відновився о 21:02 UTC.

Причина: перевантаження балансувальників і «шторм» повторів

За даними GitHub, безпосередньою причиною стало насичення мережі балансувальників навантаження в дата-центрі Central US через новий пік трафіку. Pod з бічним контейнером (sidecar) Istio досяг своїх меж паралелізму і не зміг правильно масштабуватися автоматично, бо політика була налаштована відстежувати ліміти хост-сервісу, але не ліміти sidecar. Збій поширився каскадом, доки чотири вузли HAProxy не вичерпали свої ліміти потоків, що призвело до деградації шляху автентифікації на шлюзі та до масових затримок і збоїв автентифікації. Оптимістична логіка повторів погіршила ситуацію, перевантаживши внутрішні балансувальники; призупинення HAProxy на цих вузлах дало негайне й широке відновлення.

До першої проблеми додалася друга: затримані відповіді одного внутрішнього ендпоінта запустили приховану помилку повторів у VS Code, яка посилила трафік приблизно вдесятеро. Запити до Copilot Token Service зросли з типових 7–9 тис. на секунду до 70–100 тис. на секунду. Компанія загасила цей «шторм», тимчасово зменшивши логіку повторів на шлюзі та заблокувавши вхідні запити токенів Copilot на балансувальниках відповіддю 403, після чого поступово повертала трафік по кожному майданчику. Відновлення ускладнювали також скрейпінгові атаки на ендпоінти codeload.

Що GitHub планує змінити

У звіті перелічено п'ять подальших дій: виправити політики автомасштабування, щоб вони враховували паралелізм і потужність sidecar сервісної мережі; провести аудит лімітів запитів, паралелізму та масштабування Istio в уражених сервісах; переглянути ліміти повторів і поведінку відступу на шлюзах і в клієнтах; виправити поведінку повторів у VS Code, яка посилила трафік токенів Copilot; і покращити моніторинг потужності балансувальників разом із засобами регіонального перемикання.