GitHub-ის ანგარიში: არასწორად კონფიგურირებული Istio პოლიტიკა და retry-ების ქარიშხალი 7 სთ 47 წთ-იანი გათიშვის მიღმა

GitHub-მა გამოაქვეყნა ანგარიში 2026 წლის 17 აგვისტოს ინციდენტზე, რომლის დროსაც პლატფორმის მუშაობა დარღვეული იყო. შეფერხება 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-ის workflow-ები GitHub Enterprise Cloud-ში Data Residency-ით, რომლებიც GitHub.com-ზე განთავსებულ საჯარო workflow საფეხურებს იყენებენ.

სერვისების უმეტესობა 16:36 UTC-ისთვის აღდგა, როდესაც Central US-ის მონაცემთა ცენტრი ნორმალურად დაბრუნდა. Actions გაფუჭებული დარჩა დაახლოებით 18:03 UTC-მდე, ხოლო Copilot Token Service სრულად 21:02 UTC-ზე აღდგა.

მიზეზი: ბალანსირების გადატვირთვა და retry-ების ქარიშხალი

GitHub-ის თანახმად, უშუალო მიზეზი Central US-ის მონაცემთა ცენტრში ქსელური გაჯერება იყო, რაც ტრაფიკის ახალმა პიკმა გამოიწვია. Istio-ს sidecar pod-მა კონკურენტულობის ზღვარს მიაღწია და ავტომასშტაბირება ვერ შეძლო, რადგან პოლიტიკა არასწორად იყო კონფიგურირებული — ის მხოლოდ ჰოსტ სერვისის ლიმიტებს აკვირდებოდა და არა sidecar-ისას. შეცდომა კასკადურად გავრცელდა, სანამ ოთხმა HAProxy კვანძმა საკუთარი ნაკადის ლიმიტები არ ამოწურა, რამაც gateway-ის ავთენტიფიკაციის გზა გააფუჭა და ავთენტიფიკაციის ფართო შეფერხებები და წარუმატებლობები გამოიწვია. სიტუაცია გააუარესა ოპტიმისტურმა retry ლოგიკამ, რომელმაც შიდა ბალანსირები გადატვირთა; HAProxy-ის შეჩერებამ ამ კვანძებზე მყისიერად და ფართოდ აღადგინა მუშაობა.

მეორე პრობლემა პირველს დაერთო: ერთი შიდა endpoint-ის დაგვიანებულმა პასუხებმა VS Code-ში ფარული retry-ს ხარვეზი გაააქტიურა, რომელმაც ტრაფიკი დაახლოებით 10-ჯერ გაზარდა. Copilot Token Service-ზე მოთხოვნები ჩვეულებრივი წამში 7–9 ათასიდან წამში 70–100 ათასამდე გაიზარდა. კომპანიამ ეს ქარიშხალი დროებით შეამცირა gateway-ის retry ლოგიკა და ბალანსირებზე Copilot-ის token-ის შემომავალი მოთხოვნები 403 პასუხით დაბლოკა, შემდეგ კი ტრაფიკი ეტაპობრივად, საიტების მიხედვით აღადგინა. აღდგენას ართულებდა codeload endpoint-ებზე თავდასხმები-სქრაპინგიც.

რას შეცვლის GitHub

ანგარიში ხუთ შემდგომ ნაბიჯს ჩამოთვლის: ავტომასშტაბირების პოლიტიკების გასწორება ისე, რომ ისინი service-mesh sidecar-ის კონკურენტულობასა და სიმძლავრეს ითვალისწინებდნენ; Istio-ს მოთხოვნების, კონკურენტულობისა და მასშტაბირების ლიმიტების აუდიტი დაზარალებულ სერვისებში; retry ლიმიტებისა და backoff-ის ქცევის გადახედვა gateway-ებსა და კლიენტებში; VS Code-ის იმ retry ქცევის გამოსწორება, რომელმაც Copilot-ის token-ის ტრაფიკი გააძლიერა; და ბალანსირების სიმძლავრის მონიტორინგის გაუმჯობესება რეგიონული failover-ის დაცვის მექანიზმებთან ერთად.