GitHub-ın 17 avqust nasazlığı: 7 saat 47 dəqiqə və kod deyil, tutum problemi

17 avqustda GitHub 7 saat 47 dəqiqə davam edən və dünyada developerlərlə təşkilatlar üçün github.com, autentifikasiya, GitHub Actions, API-lər, pull request-lər, issue-lar və Copilot xidmətlərini pozan nasazlıq yaşadı.

Bu, şirkətin avqustdakı ikinci mühüm hadisəsi idi — 6 avqustda Actions-da baş verən nasazlıqdan sonra. GitHub mart və apreldə etibarlılıq işləri barədə yeniləmələr dərc etmişdi; şirkətə görə yeni hadisələr bu işin sürətləndirilməli olduğunu göstərir.

Nə baş verdi

Araşdırma göstərdi ki, nasazlıq trafikin yeni zirvəyə çatdığı anda başlayıb və ABŞ-ın Mərkəzi bölgəsindəki data mərkəzində kritik infrastruktur komponenti buna miqyaslana bilməyib. Yaranan tutum təzyiqi GitHub-ın sistemlərinə yayıldı, autentifikasiya xətalarına səbəb oldu və bir neçə xidməti eyni vaxtda iflic etdi.

Bərpa bir neçə əlaqələndirilmiş addım tələb etdi: komandalar trafiki yönləndirdi, zədələnmiş infrastrukturu təcrid etdi və xidmətləri mərhələli şəkildə qaytardı. Xidmətlərin çoxu həmin gün geri döndü, bəzi Copilot xidmətləri isə daha uzun çəkdi — oradakı xətalar müştəri tərəfində təkrar cəhd dövrü yaradaraq bərpa zamanı trafiki artırdı və trafik təhlükəsiz şəkildə qaytarılmadan əvvəl bu davranış aradan qaldırılmalı idi. Ətraflı texniki xronologiya kök səbəb analizində dərc olunub.

Tutum, kod deyil

GitHub-a görə nasazlıqların heç biri kod və ya konfiqurasiya dəyişikliyindən qaynaqlanmayıb: hər ikisi tutum çatışmazlığı idi — kritik komponentlər tələb imkanlarını aşmadan əvvəl miqyaslandırılmamışdı. Apreldən platformada aylıq commit sayı 1,4 milyardan 2,9 milyarda yüksəlib. Şirkət 3 milyondan çox CPU nüvəsi, 120 petabayt yüksəksürətli saxlama və əhəmiyyətli şəbəkə tutumu əlavə edib. Hazırda Azure platforma yükünün təxminən 58%-nə və bütün Git əməliyyatlarının yarısına xidmət edir; mayda bu göstərici platforma yükünün 12%-i idi.

Qarşıdakı işlər

Prioritetlər tutum əlavə etmək, səmərəliliyi artırmaq və arxitektura maneələrini aradan qaldırmaqdır. Növbəti mərhələ oxuma tutumunu oxuyucu sayına uyğun xətti miqyaslandıran və limitsiz oxuma əməliyyatlarına imkan verən arxitekturadır; ən böyük monorepo-lardan başlayaraq mərhələli şəkildə tətbiq olunacaq. Şirkət həmçinin kritik sistemləri təcrid edir, aralarındakı ortaq asılılıqları aradan qaldırır və daha güclü testlərə, daha təhlükəsiz yerləşdirmələrə, daha yaxşı müşahidə olunmağa və daha effektiv xəbərdarlıqlara investisiya edir.

Avqust hadisələrindən sonra iki təcili dəyişiklik edildi: təkrar cəhd fırtınalarının və kaskad yükün qarşısını almaq üçün xidmətlər arası qarşılıqlı əlaqələrdə vahid təkrar cəhd limitləri, büdcələr və dəyişən taymautlar, və trafik kəskin artanda çökə biləcək komponentləri müəyyən etmək üçün aşağı prioritetli CPU və yaddaş xəbərdarlıqlarının nəzərdən keçirilməsi.