Чому GitHub був недоступний майже вісім годин 17 серпня?

GitHub — платформа, де розробники зберігають код і запускають автоматизовані тести. Співпраця над програмним забезпеченням теж відбувається тут. 17 серпня вона перестала працювати майже на цілий робочий день.

Збой почався, коли трафік досяг нового піку. Критичний компонент інфраструктури в дата-центрі Central US не зміг масштабуватися під цим навантаженням. Тиск поширився системою. Спричинило це помилки автентифікації і одночасне вимкнення кількох сервісів.

Відновлення вимагало кількох узгоджених кроків. Команди перенаправили трафік і ізолювали постраждалу інфраструктуру. Сервіси піднімали поетапно. Більшість повернулася раніше того ж дня. Copilot відновлювався довше: помилки в цих сервісах запустили цикл повторних запитів на стороні клієнта, що додало трафіку під час відновлення. Цю поведінку довелося виправити, перш ніж трафік можна було безпечно відновити.

Жоден інцидент не виник через зміну коду

Помилка 6 серпня в Actions і збой 17 серпня мають спільну причину. Обидва — це відмови потужності. Жоден деплой коду чи зміна конфігурації їх не спричинили. GitHub просто не встиг масштабувати критичні компоненти до моменту, коли попит перевищив їхню ємність.

З квітня щомісячні коміти зросли з 1,4 мільярда до 2,9 мільярда. Цей ріст пояснює тиск. Він не виправдовує простої.

Додавання заліза та міграція в хмару

Як частину зобов'язань щодо надійності, оголошених на початку року, GitHub зосередився на трьох пріоритетах. Це додавання потужності та підвищення ефективності. Третій — усунення архітектурних вузьких місць. Компанія вже додала понад 3 мільйони ядер CPU. Також 120 петабайт швидкого сховища і значну мережеву пропускну здатність.

Команди встановили стільки заліза, скільки дозволяла наявна потужність у існуючих дата-центрах. Одночасно прискорили міграцію в Azure. Сьогодні Azure обробляє приблизно 58 % навантаження платформи GitHub і половину всіх Git-операцій. У травні ця цифра становила 12 % навантаження платформи.

Розширена інфраструктура також підтримала ріст запусків завдань GitHub Actions. Інфраструктура Azure прискорила роботу з масштабування найбільших монорепозиторіїв.

Читання на масштабі

Наступний етап — архітектура, де потужність читання масштабується лінійно з кількістю читачів. Це дасть можливість необмеженої кількості операцій читання. Внедрення буде поступовим, починаючи з найбільших монорепозиторіїв.

Масштаб — не єдиний виклик. Оскільки темп і складність змін зростали, існуючі операційні практики не встигали за ними. GitHub переспрямував команди та ресурси на доступність. Інвестиції включають краще тестування та безпечніші релізи. Покращується спостережуваність та ефективніший алертинг. Прогрес є, але робота не завершена.

Розділення залежностей

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

Інциденти 6 і 17 серпня призвели до двох негайних змін. Перше — GitHub впроваджує єдині ліміти повторних спроб та бюджети повторів для взаємодії між сервісами. Будуть також примусові змінні таймаути, щоб запобігти бурям повторних запитів та каскадному навантаженню. Друге — компанія переглядає алерти низького пріоритету по CPU та пам'яті, щоб виявити компоненти, що можуть відмовити при різких стрибках трафіку.

Чого в дописі немає

Оголошення не квантує, скільки розробників чи організацій постраждало. Воно не розкриває, чи втрачено якісь дані. Не зазначає, чи тривав інцидент 6 серпня подібну тривалість. Не надає термінів, коли архітектура лінійного читання досягне загальної доступності.