GitHub, Ağustos 2026 boyunca hizmetlerinin kullanılabilirliğini etkileyen beş olayın ayrıntılarını açıkladı. Bunlar arasında GitHub Actions kesintileri, Copilot Cloud Agent sonuçlarında gecikme ve Kimi K3 modeli isteklerinde başarısızlık yer aldı. Şirket, olayları platformun büyümesi ve daralan kapasite marjlarının yanı sıra otomatik ölçeklendirme, yeniden deneme politikaları ve kurtarma mekanizmalarındaki kusurlarla ilişkilendiriyor.
GitHub, mimari yapısını iyileştirmeye ve daha fazla hizmeti Azure'a taşımaya yatırım yaptığını; önceliğin kullanılabilirlik, ardından kapasite ve sonra özellikler olduğunu söylüyor. Şirket ayrıca kapasite izleme, kuyruk yönetimi, yeniden deneme politikaları ve temel hizmetlerin dayanıklılığı konusunda iyileştirmeler duyurdu.
Farklı nedenlere sahip beş olay
- 6 Ağustos: Olay 10 saat 42 dakika sürdü. Actions içindeki bir dahili hizmete yapılan rutin dağıtım, sitelerden birinde kapasitenin geçici olarak azalmasına yol açtı. Bu durum hizmetlerin doygunluğa ulaşmasına ve hataların önbelleğe alma, DNS ve API arayüzlerine yayılmasına neden oldu; görev atama yolundaki bir kusur da kurtarma sürecini yavaşlattı. İş akışlarının büyük bir bölümü başarısız oldu veya gecikti ve bazı olayların manuel olarak yeniden başlatılması gerekti.
- 17 Ağustos: Düşüş 7 saat 35 dakika sürdü. Bunun nedeni, bir veri merkezindeki yük dengeleyicilerin kapasite sınırına ulaşması ve hizmet ağı içindeki bir yan bileşenin eşzamanlılık sınırına ulaşmasına rağmen ölçeklenmemesiydi. Bu durum ortak kimlik doğrulama yolunda gecikmelere ve başarısızlıklara yol açtı; etki Issues, Pull Requests, API arayüzleri, Actions ve Copilot'a yayıldı. Yeniden denemedeki bir kusur da istek trafiğini dahili bir kimlik doğrulama noktasına iki katına çıkardı.
- 20 Ağustos: Olay 9 saat 54 dakika sürdü ve en az 54 kuruluşta Copilot Cloud Agent görevlerinin durumu ile sonuçlarını etkiledi. Görev durumlarını depolayan bulut veritabanı sağlayıcısının bir bölgesinde kesinti yaşandı ve bir depolama ayarı nedeniyle bölgesel geçiş hızlı biçimde gerçekleşemedi; bunun sonucunda durum güncellemeleri birikti. Görevlerin kendisi kaybolmadı, ancak işleme yeniden başlatılıp kuyruk boşaltılana kadar sonuçların görüntülenmesi gecikti.
- 26 Ağustos: Düşüş 2 saat 50 dakika sürdü. Bir olay dalgası, sınırına yakın çalışan ortak bir veritabanını doygunluğa itti. Bu durum Actions işlemlerinin başlatılmasını geciktirdi ve Copilot Code Review ile bazı GitHub Pages işlemleri gibi buna bağlı hizmetleri etkiledi. GitHub, gelen yükü kademeli olarak sınırlamak zorunda kaldı; çünkü stres göstergeleri ortaya çıktığında korumayı etkinleştirecek otomatik bir devre kesici bulunmuyordu.
- 27 Ağustos: Olay 2 saat 8 dakika sürdü ve yalnızca Copilot içindeki Kimi K3 modeline yönlendirilen istekleri etkiledi; bunun nedeni harici model sağlayıcısındaki düşüştü. Olayın zirvesinde bu isteklerdeki hata oranı yarıyı aştı; diğer modeller ve Auto ayarı kullanılabilir durumda kaldı.
Pratikte ne değişti?
Açıklanan önlemler, GitHub'ın olayları yalnızca münferit dağıtım hataları olarak değil, kapasite, yalıtım ve kurtarma sorunları olarak ele aldığını gösteriyor. Şirket, Actions işlerinin %33'ünü kısıtlı bir üretim kümesinden yedek kapasiteye taşıdı. Bu, yoğun saatlerde önbellek işlemcisi kullanımını %98'den %80'e düşürdü ve kendi tahminine göre yaklaşık üç aylık ek marj sağladı. Azure'a taşınan hizmetlerden gelen okumalar %60,4'e, monolitik sistem okumaları %64,3'e ve Git okumaları %54'e ulaştı.
Veritabanları açısından ilk Azure üretim MySQL primary'si, müşterilerin gözlemlediği yazma işlemleri üzerinde kayda değer bir etki olmadan 11 Ağustos'ta çalıştırıldı; aynı yaklaşım 27 Ağustos'ta iki temel veritabanıyla daha tekrarlandı. GitHub ayrıca eski bir veritabanı kopyasından saniyede yaklaşık bir milyon sorguyu kaldırdı; diğer değişiklikler de saniyede 120 bin sorguyu ve her saat boşa harcanan yaklaşık 59 bin saniyelik işi azalttı.
Bu rapor neden önemli?
Olaylar, hizmetler veritabanlarını, kimlik doğrulama yollarını veya ortak bir Actions altyapısını paylaştığında yalnızca yatay ölçeklendirmeye güvenmenin yeterli olmadığını gösteriyor. Ayrıca kontrolsüz yeniden denemeler kısmi bir düşüşü daha geniş bir yüke dönüştürebilir; bölgeler arasındaki geçişin gecikmesi ise temel görevler kaybolmasa bile durumların birikmesine yol açabilir. Azure planı, yalıtım önlemleri ve yük devre kesicileri hâlâ uygulanma aşamasında olduğundan rapor, risklerin ortadan kaldırıldığını kanıtlamıyor. Bunun yerine GitHub'ın gelecekteki çalışmalarını yoğunlaştıracağı alanları açıklıyor: ek temel veritabanlarını taşımak, kapasite yönetimini otomatikleştirmek ve bağımlılık arızalarını ele alma kapsamını genişletmek.