· kaynak GitHub Blog
GitHub Eylül ayında iki olay bildirdi: veritabanı doygunluğu ve sessiz Copilot review hataları
GitHub'ın Eylül 2026 kullanılabilirlik raporu, 88 dakikalık paylaşımlı veritabanı doygunluğu olayını ve bazı Copilot kod incelemelerinin sessizce tamamlanmadan kaldığı 52 dakikalık bir arızayı ayrıntılarıyla ele alıyor.

İki olay, birbirinden çok farklı iki arıza modu
GitHub, Eylül 2026 kullanılabilirlik raporunu yayımladı ve hizmetleri genelinde performansı düşüren iki olayı açıkladı: 13 Eylül'de arka planda çalışan bir temizlik işinin paylaşımlı bir veritabanını tüketmesiyle tetiklenen yaklaşık 88 dakikalık bir kesinti ve 28 Eylül'de bazı Copilot kod incelemelerinin herhangi bir çıktı üretmeden tamamlanmış sayılmasıyla sonuçlanan 52 dakikalık bir arıza. O ay ayrı bir baskı yayımlanmadığı için Ağustos'u da kapsayan rapor, her iki olayı daha geniş kapsamlı güvenilirlik çalışmaları çerçevesinde ele alıyor.
Temizlik işi paylaşımlı bir veritabanını doyurdu
İlk olay 13 Eylül'de saat 09:16 UTC'de başladı ve bir saat 28 dakika sürdü. GitHub'a göre, arka plandaki bir veri temizleme işi, veritabanı replicaları geride kaldığında yazma işlemlerini yavaşlatacak bir fren mekanizması içeriyordu — ancak bu fren, birincil sunucuda biriken yükü hiç izlemiyordu. İş bu nedenle yazmaya devam etti ve birincil sunucu bağlantı limitine ulaştı; ardından bağımlı hizmetlerdeki istekler başarısız oldu ya da yavaşladı.
GitHub durumu kötüleştiren iki etken belirledi. Veritabanı çağrılarında hızlı bir timeout yoktu; bu yüzden istek işleyicileri hızlıca başarısız olmak yerine takılan bir veritabanında askıda kaldı. Ayrıca token oluşturma çevresindeki bir retry döngüsü, zaten başarısız olan yazma işlemlerini sürekli yeniden göndererek veritabanını doygunlukta tuttu. Otomatik izleme olayı yakaladı; müdahale ekipleri iç yükü kesti, işi duraklattı ve hata oranları normale döndü.
Yapılacak takip çalışmaları arasında, arka plan işlemlerini gerçek veritabanı kapasitesine göre kısıtlamak, arıza sırasında gereksiz retry'leri azaltmak, yavaş veritabanı isteklerinin etki alanını sınırlamak ve kısa bağlantı sorunlarının kurtarmayı sabote etmemesi için servis başlatmayı sağlamlaştırmak yer alıyor.
Copilot code review sonuç olmadan başarı bildirdi
İkinci olay 28 Eylül'de saat 21:16 UTC'de başladı ve 52 dakika sürdü. Copilot code review, incelemeleri sonuçların iki kopyasını döndüren ayrı bir servise devreder: yorumlar içermeyen sınırlı bir sürüm ve tamamlanmış incelemeyi içeren tam bir sürüm. İncelemeler yalnızca tam kopyadan gönderilir. Bu servisteki bir değişiklik, bazı müşteriler için yalnızca sınırlı kopyayı iletmeye başladı; bu da incelemenin oluşturulamaması anlamına geliyordu — ancak iş başarıyla tamamlandı olarak raporlandı.
Eksik sonuçları izleyen hiçbir mekanizma olmadığından sorun, yalnızca bazı incelemeler 30 dakikadan uzun süre tamamlanmamış durumda bekleyince ve ilk müdahale ekiplerine bir alarm tetikleyince ortaya çıktı. GitHub değişikliği geri aldı, geri alma işlemi kontrollerinden geçerken durum sayfasında bildirim yayımladı ve müşterilerden etkilenen incelemeleri yeniden talep etmelerini istedi. Planlanan düzeltmeler arasında inceleme hattı genelinde teslimat güvenceleri, başarısız incelemeler için otomatik kurtarma, sorunların daha erken bildirimi ve daha sıkı izleme ile rollout kontrolleri yer alıyor.
Azure migrasyonu ilerliyor ama deadline'ı kaçırıyor
Raporda ayrıca Azure'un Central US bölgesine devam eden migrasyon özetleniyor. GitHub'a göre 7 Ekim itibarıyla 160 üretim servisinin 120'si bu bölgeye deploy edildi ve 51 birincil MySQL veritabanının 13'ü taşındı. Azure, çekirdek uygulama için okuma trafiğinin %65,4'ünü, Git okuma trafiğinin %48,3'ünü ve stream-processing trafiğinin %80,2'sini karşılıyordu — bu yüzdeler farklı iş yüklerini ölçer ve toplanmamalıdır.
Migrasyon zorluklarla karşılaştı. GitHub, kapasitenin availability zone'lar arasında dengesiz dağılması nedeniyle 11 Eylül'de Central US deploy'larını ve trafik artışlarını duraklattı; geçici rahatlamanın ardından 18 Eylül'de kalıcı artışlara kaldığı yerden devam etti ve tam kapasite için Ekim sonu hedeflendi. Şirket ayrıca bölgedeki her üretim servisini deploy etme yönündeki iddialı 30 Eylül hedefini kaçırdı. Ayrı olarak, planlı bir veritabanı failover'ı sırasında otomatik bir acil durum süreci Central US veritabanı kopyalarının bağlantısını kesti ve bölgedeki müşterileri aksattı; GitHub, kurtarmayı iyileştirirken planlı geçişlerde bu süreci devre dışı bıraktı.
Başka alanlarda ölçülebilir ilerleme kaydedildi. Yirmi dört authentication-core tablosu, GitHub'ın en eski paylaşımlı veritabanından taşındı ve replicalarından saniyede yaklaşık bir milyon sorgu kaldırıldı. Issue'ların ve pull request'lerin arkasındaki küme, yaklaşık 980 milyon gereksiz düzenleme geçmişi satırından kurtuldu ve tahmini 1,8 terabayt yer açıldı; haftalık deadlock'lar Haziran zirvesine göre yaklaşık %77 azaldı.
Actions için kapasite payı ve aşırı yük kontrolleri
GitHub Actions için yapılan üretim değişiklikleri, ölçülen Redis işlemlerini yaklaşık %28, göreli CPU kullanımını yaklaşık %30 azalttı. Ayrı bir altyapı önbelleği, Redis bant genişliğini %84, ortalama yanıt süresini %66, birincil envanter isteğinin medyan yanıt süresini %96 ve kuyruktaki istekleri %95 azalttı.
Örneklenen pull request trafiğinin yaklaşık yarısı, paylaşılan bir bağımlılık arızalandığında artık azaltılmış bir modda çalışmaya devam edebiliyor ve veritabanı trafiği yönlendirmesi yük altında otomatik olarak ölçekleniyor — bir grup, 23 Eylül'deki pull request etkinliği sırasında 14 örnekten 19 örneğe çıktı. Yeni bir aşırı yük kontrolü, müdahale ekiplerinin sistemi doyurmadan önce kritik API ve web iş akışlarını korumak için daha düşük öncelikli istekleri düşürmesine olanak tanıyor.
Neden önemli
Eylül'deki iki arıza, dağıtık sistemler ders kitabından örnekler: yanlış sinyali izleyen bir güvenlik mekanizması, eksik timeout'lar, bir retry fırtınası ve boş çıktıyı fark edecek izlemenin bulunmadığı bir başarı yolu. GitHub'ın raporu, kaçırılan migrasyon deadline'ı ve müşterileri mağdur eden bir failover da dahil olmak üzere düzeltmeler ve aksaklıklar konusunda alışılmadık ölçüde açık. Paylaşımlı veritabanları veya async hatları işleten herhangi bir ekip için önerilen çareler — kapasite farkındalıklı arka plan işleri, hızlı başarısız olma (fail-fast) çağrıları ve başarıyla sonuçlanıp hiçbir şey üretmeyen işler için alarmlar — doğrudan uygulanabilir.
- #github
- #availability
- #copilot
- #devops
- #cloud-migration