17 Ağustos’ta GitHub, 7 saat 47 dakika süren bir kesinti yaşadı. Bu kesinti github.com’u, kimlik doğrulamayı, GitHub Actions’ı, API’leri, pull request’leri, issue’ları ve Copilot’u aksatarak dünyanın dört bir yanındaki geliştiricileri ve kuruluşları etkiledi. O gün yazılım yayımlamaya çalışıyorsanız sizi yarı yolda bıraktık.
Bu, 6 Ağustos’taki Actions arızasının ardından Ağustos ayındaki ikinci önemli olayımızdı. Mart ve Nisan aylarında GitHub’ın güvenilirliğini artırmak için yürüttüğümüz çalışmaları paylaşmıştım. İlerleme kaydettik, ancak bu olaylar bu çalışmaları hızlandırmamız gerektiğini açıkça ortaya koyuyor.
Ne oldu
İncelememiz, trafiğin yeni bir zirveye ulaşması ve Orta ABD veri merkezimizdeki kritik bir altyapı bileşeninin bu trafiğe ayak uyduracak şekilde ölçeklenememesiyle kesintinin başladığını ortaya koydu. Bunun sonucunda oluşan kapasite baskısı sistemlerimize yayıldı; kimlik doğrulama hatalarına yol açtı ve birden fazla GitHub hizmetini aksattı.
Kurtarma için birkaç koordineli adım atılması gerekti. Ekipler trafiği yeniden yönlendirdi, etkilenen altyapıyı izole etti ve hizmetleri aşamalı olarak geri yükledi. GitHub hizmetlerinin çoğu o gün daha erken toparlandı, ancak bazı Copilot hizmetleri daha uzun sürdü. Bu hizmetlerdeki hatalar, kurtarma sırasında trafiği artıran istemci taraflı bir yeniden deneme döngüsünü tetikledi. Trafiği güvenli bir şekilde geri yükleyebilmemiz için önce bu davranışı hafifletmemiz gerekti. Kapsamlı kök neden analizi, ayrıntılı bir teknik zaman çizelgesini içeriyor.
Her iki kesintiye de kod veya yapılandırma değişikliği neden olmadı. Her iki olayın temelinde kapasite yetersizliği vardı. Talep kapasitesini aşmadan önce kritik bileşenleri ölçekleyemedik. Nisan ayından bu yana aylık commit sayısı 1,4 milyardan 2,9 milyara çıktı. Bu büyüme sistemlerimiz üzerindeki baskıyı açıklıyor, ancak bu kesintileri mazur göstermiyor.
Neler yaptık ve sırada ne var
Bu yılın başında verdiğimiz güvenilirlik taahhütlerinin bir parçası olarak üç önceliğe odaklandık: kapasite eklemek, verimliliği artırmak ve mimari darboğazları ortadan kaldırmak. O zamandan bu yana 3 milyondan fazla CPU çekirdeği, 120 petabayt yüksek hızlı depolama ve önemli ölçüde ağ kapasitesi ekledik. Mevcut veri merkezlerimizde, mevcut güç kapasitesinin izin verdiği kadar donanım kurarken Azure’a geçişimizi de hızlandırdık.
Bugün Azure, GitHub’ın platform yükünün yaklaşık %58’ine ve tüm Git işlemlerinin yarısına hizmet veriyor; bu oran, mayıs ayındaki platform yükünün %12’sinden yükseldi. Bu genişleyen altyapı, aşağıda gösterilen GitHub Actions iş çalıştırmalarındaki büyümeyi de destekledi.
Azure’ın altyapısı ve kapasitesi, en büyük monorepo’ları ölçeklendirme çalışmalarımızı da hızlandırdı. Sıradaki kilometre taşımız, okuma kapasitesini okuyucu sayısıyla doğrusal olarak ölçekleyen ve sınırsız okuma işlemini mümkün kılan bir mimari.
Bunu kademeli olarak devreye alacağız ve en büyük monorepo’larla başlayacağız.
Ölçek, karşılaştığımız tek zorluk değil. Değişimin hızı ve karmaşıklığı arttıkça mevcut operasyonel uygulamalarımız ayak uyduramadı. Ekipleri ve kaynakları erişilebilirliğe yönlendirdik; daha güçlü testlere, daha güvenli kullanıma sunma süreçlerine, daha iyi gözlemlenebilirliğe ve daha etkili uyarı mekanizmalarına yatırım yaptık. İlerleme kaydettik, ancak bu çalışma henüz tamamlanmadı.
Buna ek olarak kritik sistemleri birbirinden yalıtıyor ve aralarındaki ortak bağımlılıkları kaldırıyoruz. Bu çalışma, bir kesinti yaşanma olasılığını azaltmak ve bir kesinti meydana geldiğinde etkisini sınırlamak üzere tasarlandı.
Her kesintiden ders çıkarıyor ve erişilebilirlik iş kalemimize yeni çalışmalar ekliyoruz. 6 Ağustos ve 17 Ağustos olayları iki acil değişikliğe yol açtı.
İlk olarak, yeniden deneme fırtınalarını ve zincirleme yükü önlemek için hizmetler arası etkileşimlerde tutarlı yeniden deneme sınırları, yeniden deneme bütçeleri ve değişken zaman aşımı süreleri uyguluyoruz. İkinci olarak, ani trafik artışları sırasında arızalanabilecek bileşenleri belirlemek için düşük öncelikli CPU ve bellek uyarılarını gözden geçiriyoruz.
Yüksek erişilebilirliğe bağlılığımız yalnızca teknik bir vaat değil.