GitHub, 17 Ağustos'ta platformunu etkileyen ve 7 saat 47 dakika süren kesintinin, ABD'nin merkez bölgesindeki veri merkezinde trafiğin rekor seviyeye ulaşmasıyla kritik bir altyapı bileşeninin ölçeklenememesinden kaynaklandığını açıkladı. Ortaya çıkan kapasite baskısı birden fazla sisteme yayıldı; github.com, kimlik doğrulama, GitHub Actions, API'ler, çekme istekleri ve sorunlar ile Copilot etkilendi. Kesintinin etkisi dünya genelindeki geliştiricilere ve kuruluşlara da yansıdı.
Bu olay, GitHub'ın ağustos ayında karşılaştığı ikinci büyük olay oldu; ilkinde 6 Ağustos'ta Actions hizmeti arızalanmıştı. Şirket, soruşturmanın iki olaydan hiçbirinin kod veya yapılandırma değişikliğiyle bağlantılı olmadığını ortaya koyduğunu belirtti. Her iki olayın temelinde kapasite yetersizliği vardı; talep kapasite sınırlarını aşmadan önce temel bileşenler genişletilmemişti. GitHub'a göre aylık gönderim sayısı nisanda 1,4 milyardan o tarihten bu yana 2,9 milyara yükseldi. Ancak şirket, kullanım artışının kesintileri önleme sorumluluğunu ortadan kaldırmadığını kabul etti.
Hizmetler nasıl kurtarıldı?
Kurtarma süreci, trafiğin yeniden yönlendirilmesini, etkilenen altyapının izole edilmesini ve hizmetlerin aşamalı olarak yeniden devreye alınmasını gerektirdi. GitHub hizmetlerinin çoğu aynı gün içinde yeniden çalışmaya başladı, ancak bazı Copilot hizmetleri daha uzun sürdü. Bu hizmetlerdeki hatalar istemci tarafında bir yeniden deneme döngüsüne yol açarak kurtarma sırasında trafiği artırdı. Bunun üzerine ekipler, trafiği güvenli biçimde yeniden yönlendirmeden önce bu davranışı sınırlamak zorunda kaldı.
GitHub, kök neden analizine ilişkin tam raporun ayrıntılı bir teknik zaman çizelgesi içerdiğini ve şirketin kullanılabilirlik ile güvenilirliği iyileştirmek için daha önce açıkladığı taahhütleri uygulamayı sürdürdüğünü belirtiyor.
Uygulamada neler değişiyor?
GitHub'ın planı kapasiteyi artırmaya, verimliliği yükseltmeye ve mimari darboğazları ortadan kaldırmaya odaklanıyor. Şirket, ek ağ kapasitesinin yanı sıra 3 milyondan fazla CPU çekirdeği ve 120 petabayt yüksek hızlı depolama eklediğini açıkladı. Ayrıca mevcut veri merkezlerindeki kullanılabilir güç kapsamında mümkün olduğunca fazla donanım kurdu ve Azure'a geçişini hızlandırıyor.
Azure şu anda GitHub platformu yükünün yaklaşık %58'ini ve Git işlemlerinin yarısını çalıştırıyor; bu oran mayıs ayında platform yükünün %12'siydi. Bu genişleme, GitHub Actions görev çalıştırmalarındaki büyümeyi desteklemeye de yardımcı oldu. Şirket, büyük depolardaki okuma kapasitesini okuyucu sayısıyla doğrusal biçimde artıracak yeni bir mimari üzerinde çalışıyor. Bu mimari teorik olarak sınırsız okuma işlemi sağlayacak ve ilk olarak en büyük monorepolarda kademeli biçimde kullanıma sunulacak.
Arızaların kapsamını azaltmak ve fırtınaları önlemek
GitHub, yalnızca ölçeklendirmenin yeterli olmadığını düşünüyor. Şirket kullanılabilirlik için ek ekipler ve kaynaklar görevlendirdi; daha güçlü testlere, daha güvenli dağıtım süreçlerine, daha iyi izlemeye ve daha etkili uyarılara yatırım yaptı. Ayrıca kritik sistemleri izole ediyor ve aralarında paylaşılan bağımlılıkları kaldırarak kesinti yaşanma olasılığını azaltıyor ve kesinti meydana geldiğinde etkisini sınırlıyor.
Şirket, 6 ve 17 Ağustos olaylarına dayanarak yeniden denemeler için birleşik sınırlar ve bütçeler ile hizmetler arası iletişimde değişken zaman aşımı süreleri uygulayacak. Amaç, yeniden deneme fırtınalarını ve zincirleme yükleri önlemek. Şirket ayrıca ani trafik artışları sırasında arızalanabilecek bileşenleri tespit etmek için düşük öncelikli CPU ve bellek uyarılarını gözden geçiriyor. Bu önlemler, yazılım geliştirmek, yayımlamak ve çalıştırmak için GitHub'a güvenen geliştiriciler ve kuruluşlar açısından doğrudan önem taşıyor; çünkü platformun kurtarılması yalnızca hizmetin yeniden sağlanmasına değil, arızanın tekrarlanmasının önlenmesine ve meydana geldiğinde kapsamının sınırlandırılmasına da bağlı.