Збій GitHub 17 серпня: 7 годин 47 хвилин і відмова потужностей, а не коду

17 серпня GitHub зазнав збою, який тривав 7 годин 47 хвилин і порушив роботу github.com, автентифікації, GitHub Actions, API, pull request'ів, issue та Copilot для розробників і організацій по всьому світу.

Це був другий значний інцидент компанії в серпні — після збою Actions 6 серпня. Раніше GitHub публікував оновлення про надійність у березні та квітні; за словами компанії, нові інциденти показують, що цю роботу треба прискорити.

Що сталося

Розслідування встановило, що збій почався, коли трафік досяг нового піку, а критичний компонент інфраструктури в дата-центрі на центральному заході США не зміг масштабуватися відповідно. Тиск на потужності поширився системами GitHub, спричинивши збої автентифікації та порушення роботи кількох сервісів одночасно.

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

Потужності, а не код

За словами GitHub, жоден зі збоїв не був спричинений зміною коду чи конфігурації: обидва були відмовами потужностей, коли критичні компоненти не масштабували до того, як попит перевищив їхні можливості. Від квітня місячна кількість комітів на платформі зросла з 1,4 млрд до 2,9 млрд. Компанія додала понад 3 мільйони ядер CPU, 120 петабайт швидкісного сховища та значну мережеву потужність, встановивши стільки обладнання, скільки дозволяла наявна енергія, і прискоривши перехід на Azure. Нині Azure обслуговує близько 58% навантаження платформи й половину всіх Git-операцій — проти 12% навантаження в травні.

Робота попереду

Пріоритети — нарощування потужностей, підвищення ефективності та усунення архітектурних вузьких місць. Наступна віха — архітектура, яка масштабує читання лінійно за кількістю читачів і дає необмежені операції читання; її впроваджуватимуть поетапно, починаючи з найбільших monorepo. Компанія також ізолює критичні системи й прибирає спільні залежності між ними, інвестуючи в сильніше тестування, безпечніші розгортання, кращу спостережуваність і дієвіші сповіщення.

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