GitHub'ın Eylül kesintileri ve ajan ölçeğinde Git altyapısı planı

Eylül 2026'da GitHub iki kesinti yaşadı ve aynı dönemde Git altyapısını yapay zekâ ajanlarının ürettiği yük için yeniden inşa etme planını açıkladı. İkisi bağlantılı: kesintiler ölçek çalışmasının neden bu kadar zor olduğunu, yeni mimari planı ise nereye gidildiğini gösteriyor.

Kendi sistemini işleten biri için asıl değer, GitHub'ın hangi hatayı nasıl yaptığında ve bundan hangi tasarım kararlarını çıkardığında. Aşağıda Eylül raporundaki bulguları ve yeni Git mimarisinin ilkelerini uygulanabilir biçimde ayırdım.

Eylül'de iki kesinti, yarım kalan bir taşınma

13 Eylül'de UTC 09:16'da başlayan 1 saat 28 dakikalık kesinti bir arka plan veri temizleme işinden çıktı. İşin yavaşlatma koruması replika gecikmesini izliyordu ama birincil sunucudaki yükü hesaba katmıyordu; birincil bağlantı limitine ulaşınca ona bağlı istekler karşılanamadı. Etkiyi büyüten iki ayrıntı vardı: veritabanı çağrılarında hızlı bir zaman aşımı yoktu ve token oluşturma etrafındaki yeniden deneme döngüsü zaten başarısız olan yazmaları tekrar gönderiyordu. (GitHub availability report)

28 Eylül'de 52 dakika süren ikinci kesinti Copilot kod incelemesini vurdu. Servis, sonuçların iki kopyasını döndürüyor: yorum içermeyen sınırlı kopya ve tam kopya; inceleme yalnızca tam kopyadan yayınlanıyor. Bir değişiklik tam kopyayı yalnızca bazı müşterilere göndermeye başladı, diğerlerinde inceleme oluşturulamadı ama iş başarılı olarak raporlandı. Eksik sonuçlar izleme yokluğu yüzünden fark edilmedi; kesinti, bazı incelemelerin 30 dakikadan uzun süre tamamlanmamasıyla tetiklenen uyarıyla yakalandı ve değişiklik geri alınarak giderildi.

Taşınma tarafında tablo karışık. 7 Ekim itibarıyla 160 üretim servisinin 120'si Central US'a taşınmış, 51 birincil MySQL veritabanının 13'ü taşınmış durumda. Azure, çekirdek uygulamanın okuma trafiğinin %65,4'ünü taşıyor. 11 Eylül'de bölgeler arası kapasite dengesizliği nedeniyle dağıtımlar duraklatıldı, 18 Eylül'de sınırlı olarak sürdürüldü ve 30 Eylül'de tüm üretim servislerini taşıma hedefi tutturulamadı.

Ajanlar yazma yolunu zorluyor

GitHub'ın ikinci yazısı ölçeği somut sayılarla koyuyor. Eylül 2025 ile Ağustos 2026 arasında toplam Git etkinliği ayda 218,2 milyar olaydan 473,3 milyara çıktı; iki katından fazla. Push sayısı yıllık 4,9 kat artarak ayda 0,69 milyardan 3,35 milyara yükseldi. (Building Git infrastructure)

Artışın niteliği önemli. Bir ajan neredeyse her eylemden sonra commit veya checkpoint üretiyor, yani hızı tek bir push'un tamamlanma süresiyle sınırlı. İnsanın fark etmeyeceği gecikme ajan için darboğaz haline geliyor; tek bir repoda kendi dallarında çalışan binlerce ajan, yazma yükünü mimaride tek bir noktaya yöneltiyor.

Okuma ölçeklenirken yazma neden yavaşlıyor

Mevcut mimaride her repo varsayılan olarak beş fileserver'ın yerel disklerinde tam kopya halinde tutuluyor; bir push referansı güncellediğinde üç fazlı commit protokolü, CI, web arayüzü ve API istemcilerinin tutarlı bir durum görmesini sağlıyor. Sorun, dayanıklılık mekanizmasının aynı zamanda ölçekleme mekanizması olması: disklerdeki kopyalar doğruluk kaynağı olduğundan okuma kapasitesi eklemek yeni bir dayanıklı replika eklemek anlamına geliyor ve her replika her yazmaya katılıyor. Sonuç olarak bir push, kümesindeki en yavaş replika kadar hızlı.

Yeni yaklaşım bu bağı çözüyor. Koordinasyon gerektiren tek adım referans güncellemesinin kendisi; nesneleri depolamak, bağlantıyı doğrulamak ve secret taraması paralel yürütülebiliyor. Bakım işleri canlı isteklere cevap veren makinelerden ayrı çalışan işçilere taşınıyor. Yetkili repo verisi Azure Blob Storage'da dururken okuma kapasitesi önbellekleyen hafif işçilerden geliyor; böylece bir işçi kaybı, tam bir repo kopyasını yeniden oluşturmak yerine bir önbellek ıskasına benziyor. GitHub, iç kıyaslamalarda yazma veriminde 35 kata kadar artış bildiriyor.

Kendi altyapınıza taşıyabileceğiniz dersler

Tekrarlayan hata kalıpları, GitHub'a özgü ayrıntılardan daha öğretici:

• Yükü hesaba katmayan koruma, koruma değildir. Yalnızca replika gecikmesini izleyen bir fren, birincil üzerindeki baskıyı görmez. Otomatik işleri hem okuma hem yazma tarafındaki baskıyı izleyecek şekilde kurun.
• Zaman aşımı ve yeniden deneme politikası bir güvenlik ağıdır. Yavaş bir bağımlılıkta bekleyen istekçiler ve başarısız yazmaları tekrarlayan döngüler toparlanmayı geciktirir; hızlı başarısız olma ve geri çekilme şart.
• Biten iş ile tamamlanan iş ayrıdır. Copilot kesintisinde iş başarılı raporlandı ama ortada çıktı yoktu. Tamamlanma sinyalini değil, üretilen sonucu izleyin.
• Aşırı yük kontrolü önceliklendirmedir. GitHub, doygunluk yayılmadan önce düşük öncelikli istekleri reddederek yüksek öncelikli API ve web akışlarını koruyan bir kontrol devreye aldı. Hangi isteğin önce reddedileceğini şimdi belirleyin.

Sınırlar ve dikkat edilmesi gerekenler

35 kat yazma verimi bir üretim ölçümü değil, GitHub'ın kendi iç kıyaslaması; bağımsız doğrulaması yok ve yeni mimari henüz tam olarak devrede değil. Metindeki Azure yüzdeleri farklı iş yüklerini ölçüyor ve toplanamaz. Taşınma da tamamlanmadı: 30 Eylül hedefi tutturulamadı, kapasite çalışmaları sürüyor. Raporda anlatılan iyileştirmelerin bir kısmı planlanan önlem; gerçek koşullardaki etkisini görmek için sonraki raporları beklemek gerekiyor. GitHub'ın kendi ifadesiyle öncelik sırası net: “availability, then capacity, then features”. Yeni bir özellik eklemeden önce bu sırayı kendi sisteminizde test edin.