GitHub-ის 17 აგვისტოს ავარია: 7 საათი და 47 წუთი და სიმძლავრის, არა კოდის, პრობლემა

17 აგვისტოს GitHub-ს ავარია მოუვიდა, რომელიც 7 საათსა და 47 წუთს გაგრძელდა და დააზარალა github.com, ავთენტიფიკაცია, GitHub Actions, API-ები, pull request-ები, issue-ები და Copilot მთელ მსოფლიოში მყოფი დეველოპერებისა და ორგანიზაციებისთვის.

ეს კომპანიის რიგით მეორე მნიშვნელოვანი ინციდენტი იყო აგვისტოში — 6 აგვისტოს Actions-ის ჩავარდნის შემდეგ. GitHub-ს საიმედოობის შესახებ განახლებები მარტსა და აპრილშიც ჰქონდა გამოქვეყნებული; კომპანიის თქმით, ახალი ინციდენტები ცხადყოფს, რომ ეს სამუშაო უნდა დაჩქარდეს.

რა მოხდა

გამოძიებით დადგინდა, რომ ავარია მაშინ დაიწყო, როცა ტრაფიკმა ახალ პიკს მიაღწია და ცენტრალური აშშ-ის მონაცემთა ცენტრში არსებულმა კრიტიკულმა ინფრასტრუქტურულმა კომპონენტმა ვერ გაუძლო ამ ზრდას. შედეგად წარმოქმნილი სიმძლავრის დეფიციტი GitHub-ის სისტემებში გავრცელდა, რამაც ავთენტიფიკაციის ჩავარდნები და ერთდროულად რამდენიმე სერვისის შეფერხება გამოიწვია.

აღდგენა რამდენიმე კოორდინირებულ ნაბიჯს მოითხოვდა: გუნდებმა ტრაფიკი გადაამისამართეს, დაზარალებული ინფრასტრუქტურა იზოლირეს და სერვისები ეტაპობრივად აღადგინეს. სერვისების უმეტესობა იმავე დღეს დაბრუნდა, თუმცა ზოგიერთ Copilot-ის სერვისი უფრო დიდხანს ჩერდა — მათში არსებულმა შეცდომებმა კლიენტის მხრიდან გამოძახების ციკლი (retry loop) გამოიწვია, რამაც აღდგენის დროს ტრაფიკი გაზარდა და სანამ ტრაფიკის უსაფრთხოდ დაბრუნება მოხერხდებოდა, ჯერ ეს ქცევა უნდა შეეჩერებინათ. დეტალური ტექნიკური ქრონოლოგია ძირეული მიზეზის ანალიზშია გამოქვეყნებული.

სიმძლავრე და არა კოდი

GitHub-ის თქმით, არც ერთი ავარია არ გამოწვეულა კოდის ან კონფიგურაციის ცვლილებით: ორივე სიმძლავრის უკმარისობა იყო — კრიტიკული კომპონენტები ვერ გაიზარდა იმაზე სწრაფად, ვიდრე მოთხოვნა მათ შესაძლებლობებს გადააჭარბებდა. აპრილიდან პლატფორმაზე თვიური commit-ების რაოდენობა 1,4 მილიარდიდან 2,9 მილიარდამდე გაიზარდა. კომპანიამ უკვე დაამატა 3 მილიონზე მეტი CPU ბირთვი, 120 პეტაბაიტი მაღალსიჩქარიანი საცავი და მნიშვნელოვანი ქსელური სიმძლავრე. დღეს Azure პლატფორმის დატვირთვის დაახლოებით 58%-ს და ყველა Git ოპერაციის ნახევარს ემსახურება — მაისში ეს მაჩვენებელი 12% იყო.

რა სამუშაოა წინ

პრიორიტეტებია სიმძლავრის დამატება, ეფექტიანობის გაზრდა და არქიტექტურული ბარიერების მოშორება. შემდეგი ეტაპია არქიტექტურა, რომელიც წაკითხვის სიმძლავრეს მკითხველთა რაოდენობის პროპორციულად ზრდის და შეუზღუდავ წაკითხვის ოპერაციებს იძლევა; ის ეტაპობრივად დაინერგება, დაწყებული უდიდესი monorepo-ებით. კომპანია ასევე იზოლირებს კრიტიკულ სისტემებს, აცილებს მათ შორის საერთო დამოკიდებულებებს და ინვესტირებს უფრო ძლიერ ტესტირებასა და უკეთეს დაკვირვებადობაში.

აგვისტოს ინციდენტების შემდეგ ორი დაუყოვნებელი ცვლილება დაინერგა: სერვისებს შორის ურთიერთქმედებაში ერთიანი გამოძახების ლიმიტები, ბიუჯეტები და ცვლადი დროის შეზღუდვები, რათა აღარ მოხდეს გამოძახებების ქარიშხალი და დატვირთვის კასკადური ზრდა, და დაბალი პრიორიტეტის CPU-ისა და მეხსიერების გაფრთხილებების გადახედვა.