Платформа раскрыла дадатковыя падрабязнасці маштабнага збою 17 жніўня, які працягваўся 7 гадзін 47 хвілін. Кампанія прызнала, што не паспела маштабаваць крытычную інфраструктуру ўслед за рэзкім ростам нагрузкі.
Платформа раскрыла дадатковыя падрабязнасці маштабнага збою 17 жніўня, які працягваўся 7 гадзін 47 хвілін. Кампанія прызнала, што не паспела маштабаваць крытычную інфраструктуру ўслед за рэзкім ростам нагрузкі.
Збой закрануў GitHub.com, аўтарызацыю, API, pull request, Issues, GitHub Actions і Copilot. Паводле тэхнічнага дырэктара GitHub Улада Фёдарава, праблемы пачаліся ў момант, калі трафік дасягнуў новага піку, а адзін з крытычна важных кампанентаў у датацэнтры ў цэнтральнай частцы ЗША не змог справіцца з нагрузкай.
«Мы не маштабавалі крытычныя кампаненты да таго, як попыт перавысіў іх магчымасці», — прызналі ў GitHub. Кампанія падкрэсліла, што ні збой 17 жніўня, ні іншы буйны інцыдэнт 6 жніўня не былі выкліканы абнаўленнем кода або канфігурацыі. У аснове абодвух ляжала нястача вылічальнай магутнасці.
Пасля першапачатковага збою сітуацыю пагоршылі паўторныя запыты. Памылкі некаторых сервісаў Copilot запускалі цыклы паўторных спробаў на баку кліентаў, якія стваралі дадатковы трафік і запавольвалі аднаўленне. У падрабязным тэхнічным справаздачы GitHub таксама звязваў сплёск запытаў з паводзінамі Visual Studio Code.
Рост нагрузкі на платформу ў апошнія месяцы рэзка паскорыўся. Калі ў красавіку карыстальнікі стваралі каля 1,4 мільярда камітаў у месяц, то цяпер паказчык дасягнуў 2,9 мільярда. Адначасова колькасць аб’яднаных pull request наблізілася да 130 мільёнаў у месяц, а новых рэпазіторыяў — прыкладна да 24 мільёнаў.
GitHub сцвярджае, што ўжо значна пашырыў інфраструктуру: з пачатку праграмы павышэння надзейнасці кампанія дадала больш за 3 мільёны працэсарных ядраў, 120 петабайт высакахуткаснага сховішча і дадатковыя сеткавыя магутнасці.
Паралельна GitHub паскарае перанос нагрузкі ў Microsoft Azure. Цяпер воблака абслугоўвае каля 58% нагрузкі платформы і палову ўсіх Git-аперацый. Яшчэ ў траўні доля Azure складала толькі 12%.
Пасля жнівеньскіх збояў кампанія вырашыла ўвесці адзіныя абмежаванні на паўторныя запыты, бюджэты паўторных спробаў і дынамічныя тайм-аўты паміж сервісамі, каб прадухіляць так званыя retry storms — сітуацыі, калі велізарная колькасць паўторных зваротаў сама ўзмацняе перагрузку.
Рэлацыраваліся? Цяпер вы можаце каментаваць без верыфікацыі акаўнта.