GitHub, Eylül 2026 kullanılabilirlik raporunda hizmetlerinin performansını etkileyen iki olayı açıkladı. Bu olaylar, altyapının yeniden dağıtılması ve veritabanlarının baskıya dayanma kapasitesinin iyileştirilmesi yönündeki ilerlemeyle aynı dönemde gerçekleşti. Şirket, yüksek yük veya ortak bileşenlerden birinin arızalanması durumunda kesinti risklerini azaltmayı amaçlayan değişiklikler uygulanmış olsa da düzeltme çalışmalarının henüz tamamlanmadığını belirtiyor.
7 Ekim itibarıyla 160 üretim hizmetinin 120'si Central US bölgesinde yayımlanmıştı; 51 temel MySQL veritabanının 13'ü de taşınmıştı. Azure, temel GitHub uygulamasının okuma trafiğinin %65,4'ünü, Git okuma trafiğinin %48,3'ünü ve akış işleme trafiğinin %80,2'sini işledi. Şirket, bu oranların farklı iş yüklerine ait olduğunu ve toplanmaması gerektiğini vurguluyor.
Altyapı taşımasında ilerleme, ancak takvim gerisinde
GitHub, kullanılabilirlik bölgeleri arasındaki kapasite farklılığı nedeniyle 11 Eylül'de Central US bölgesindeki dağıtımları ve trafik artışlarını durdurdu. Geçici kapasite sağlanmasının ardından kalıcı artışlar 18 Eylül'de yeniden başlatıldı; ancak uzun vadeli kapasite çalışmaları, mevcut kapasitenin tamamını ekim sonuna kadar kullanılabilir hâle getirme hedefiyle sürüyor. Şirket, tüm üretim hizmetlerini 30 Eylül'e kadar burada yayımlama yönündeki iddialı hedefine ulaşamadı.
Planlı bir veritabanı geçişi sırasında otomatik bir acil durum işlemi, Central US bölgesindeki veritabanı replikalarının ayrılmasına yol açarak bölgedeki müşterilerde aksamalara neden oldu. GitHub, kurtarma mekanizmalarını iyileştirene kadar planlı geçişler sırasında bu işlemi devre dışı bıraktı.
Veritabanı baskısını azaltma ve arızaları sınırlama
GitHub, temel kimlik doğrulama sistemine ait 24 tabloyu en eski ortak veritabanından taşıdı. Bu, ikincil replikalardan saniyede yaklaşık 1 milyon sorguyu kaldırdı. Issues ve Pull Requests'i destekleyen kümedeki değişiklik geçmişinden yaklaşık 980 milyon gereksiz kayıt da silindi; böylece kurtarılabilir yaklaşık 1,8 terabayt depolama alanı sağlandı. İşlemler arasındaki çakışmaların haftalık sayısı, haziran ayındaki zirveye kıyasla yaklaşık %77 azaldı.
Örnekleme kapsamındaki Pull Requests trafiğinin yarısı, ortak bir bağımlılık devre dışı kaldığında sınırlı işlevlerle çalışmayı sürdürebilir hâle geldi. Veritabanı trafiği yönlendirmesi de artışlar sırasında otomatik olarak kapasite ekleyebiliyor; 23 Eylül'de Pull Requests etkinliğindeki artış sırasında gruplardan biri 14 replikadan 19 replikaya genişledi. GitHub, hizmetler daha geniş çapta doygunluğa ulaşmadan önce daha düşük öncelikli istekleri reddetmeye olanak tanıyan bir yük kontrol mekanizması ekledi.
Eylül ayındaki iki olay
13 Eylül'de arka planda yürütülen bir veri temizleme işlemi, ortak bir veritabanı üzerindeki yükün artmasına neden oldu. Koruma mekanizması replikaların geride kalmasını izliyordu, ancak kullanılabilir bağlantı sınırına ulaşan birincil sunucudaki birikmiş yükü izlemiyordu. Sorgular için kısa bir zaman aşımının bulunmaması, istek işleyicilerinin beklemeye devam etmesine yol açtı; ayrıca bir yeniden deneme döngüsü başarısız yazma işlemlerini göndermeyi sürdürdü. Olay 1 saat 28 dakika sürdü ve iç yükün azaltılması ile görevin durdurulmasının ardından sona erdi.
28 Eylül'de Copilot kod incelemelerini çalıştıran hizmette yapılan bir değişiklik, bazı müşterilere yorumları içeren tam sürüm yerine inceleme sonuçlarının sınırlı bir sürümünün gönderilmesine yol açtı. Bu nedenle görevler tamamlanmış görünürken incelemeler pull request'lerde görünmedi. Olay 52 dakika sürdü. GitHub değişikliği geri alarak sorunu giderdi ve müşterilerden etkilenen incelemeleri yeniden istemelerini talep etti.
Uygulamada ne değişiyor?
İki olay, kapasite iyileştirmelerinin tek başına yeterli olmadığını gösteriyor; güvenilirlik aynı zamanda arızanın erken tespit edilmesine, yararsız yeniden denemelerin durdurulmasına ve bir görevin çıktıları gerçekten teslim edilmeden başarıyla tamamlandığının ilan edilmemesinin sağlanmasına bağlı. GitHub, arka plan işlemleri için denetimler eklemek, hizmetlerin başlatılma davranışını iyileştirmek ve Copilot code review sonuçlarının izlenmesini ve teslim edilmesini güçlendirmek üzere çalışıyor.
GitHub Actions'a özgü altyapıda da iyileşme kaydedildi; ölçülen Redis işlemleri yaklaşık %28, göreli işlemci kullanımı ise yaklaşık %30 azaldı. Ayrı bir önbellekleme katmanı, Redis tarafından kullanılan bant genişliğini %84, ortalama yanıt süresini %66, temel stok isteğinin medyan yanıt süresini %96 ve bekleyen istekleri %95 azalttı. Açık sorular, şirketin kapasite çalışmalarını tamamlama ve gerçek üretim koşullarında ortak bağımlılıkların arızalarının tekrarlanmasını önleme becerisiyle bağlantılı olmaya devam ediyor.