GitHub Ağustos 2026 Kullanılabilirlik Raporunu Yayımladı
GitHub, Ağustos 2026’daki kullanılabilirlik olaylarını ve ardından yapılan iyileştirmeleri paylaştı. Rapora göre şirket, Azure’a geçişe, kapasite yönetimine, GitHub Actions izolasyonuna, yük azaltma mekanizmalarına ve izleme altyapısına odaklanıyor.
Ağustos ayında dört önemli olay yaşandı
GitHub, Ağustos ayının kullanılabilirlik açısından zorlu geçtiğini belirtiyor. Platform büyümeye devam ederken şirket, mimari iyileştirmelere ve daha fazla kapasite sağlaması beklenen Azure geçişine yatırım yapıyor. GitHub, riskin tamamen ortadan kaldırılamayacağını da kabul ediyor; öncelik sırası “kullanılabilirlik, ardından kapasite, sonra özellikler” ilkesiyle belirleniyor.
Ay içinde yaşanan olaylar GitHub Actions, pull request ve issue özellikleri, API’ler, Copilot servisleri, kimlik doğrulama ve GitHub Pages gibi farklı bileşenleri etkiledi.
6 Ağustos: GitHub Actions kapasite sorunu
6 Ağustos’ta GitHub Actions’ı yöneten dahili bir servise yapılan rutin dağıtım, bir veri merkezindeki çalışan pod sayısını geçici olarak azalttı. Trafik diğer bölgelere kayınca bu bölgelerdeki kapasite aşıldı. Olay başlığında kesinti süresi 10 saat 42 dakika, etki özetinde ise yaklaşık 9 saat olarak veriliyor.
GitHub-hosted ve self-hosted runner’ların yanı sıra Copilot coding agent, Copilot code review, GitHub Pages derlemeleri, Dependabot ve depo geçişleri gibi Actions’a bağlı özellikler de etkilendi. En az 74 kuruluşta iş akışları başlatılamadı, yarıda kaldı veya normalden uzun süre kuyrukta bekledi. Bazı Actions API istekleri hata döndürdü, bazı iş akışlarında da beklenmeyen oran sınırlamaları görüldü.
Actions servisleri kapasite ve eşzamanlılık sınırlarına yakın çalışıyordu. Dağıtım sırasında ortaya çıkan kısa süreli kapasite kaybı, servis ağı yan bileşenlerinde CPU kısıtlamasına ve bellek yetersizliği nedeniyle yeniden başlatmalara yol açtı. Sorun daha sonra önbellek, DNS ve API hatalarına yayıldı. Kurtarma sırasında ortaya çıkan başka bir hata da runner’ların iptal edilmiş işleri tekrar tekrar almaya çalışmasına, bunun sonucunda geçerli işlerin gecikmesine neden oldu.
GitHub etkilenen servislerin kapasitesini artırdı, webhook kaynaklı işleri geçici olarak sınırladı, geçersiz işleri yeniden almaya çalışan runner davranışını düzeltti ve kuyrukları boşalttı. Bazı self-hosted runner’lar manuel olarak kurtarıldı. Olay sırasında oluşan bazı etkinlikler otomatik olarak yeniden oynatılamadığı için tekrar tetiklendi.
Şirketin planladığı iyileştirmeler arasında servis ağı giriş katmanı ve Actions servisleri için ek kapasite ve otomatik ölçeklendirme, dağıtımlarda kapasite düşüşünü önleyecek önlemler, doygunluk sinyallerini daha erken izleme ve büyük olaylar sırasında kuyrukları daha etkili boşaltma bulunuyor. Gelecekteki runner ve Actions Runner Controller sürümlerinde etkilenen self-hosted runner’lar için otomatik kurtarma da hedefleniyor.
17 Ağustos: Veri merkezi yük dengeleyicileri aşıldı
17 Ağustos’taki olayda, bir veri merkezindeki yük dengeleyiciler yeni trafik zirvesi nedeniyle sınırlarına ulaştı. Olay başlığında süre 7 saat 35 dakika, etki özetinde ise yaklaşık 6 saat 44 dakika olarak belirtiliyor.
Issue ve pull request sayfaları en görünür biçimde etkilenen alanlardı. REST ve GraphQL API’leri, Actions, Copilot, oturum açma ve kimlik doğrulama ile webhooks API’si de hata ve gecikmeler yaşadı. Zirve sırasında etkilenen servislere yönelen ön kapı isteklerinin yüzde 56,07’si hata verdi veya uç noktada yavaş çalıştı. Olay penceresi boyunca yaklaşık 29 bin kuruluş, toplamda 4,8 milyonun üzerinde başarısız ya da yavaş istekle karşılaştı. Veri kaybı yaşanmadı.
Bir servis ağı yan bileşeni eşzamanlılık sınırına ulaşmasına rağmen ölçeklenemedi ve istekler birikmeye başladı. Yük dengeleyici düğümlerinin ağ akışı sınırlarını tüketmesi, ortak ağ geçidi kimlik doğrulama yolunu da bozdu. İstemci tarafındaki bir yeniden deneme hatası belirli bir kimlik doğrulama uç noktasına yönelen trafiği artırarak toparlanmayı yavaşlattı.
Mühendisler trafiğin bir bölümünü başka bir veri merkezine yönlendirdi, ağ geçidi yeniden denemelerini azalttı ve doygun düğümlerdeki yük dengeleyici işlemlerini durdurdu. En fazla etkilenen dahili uç noktaya yönelik yeniden denemeyi tetikleyen istekler engellendi. Trafik kademeli olarak artırıldı; telemetri sağlıklı bir tablo gösterdikten sonra olay çözüldü.
GitHub bu olayın ardından, servis ağı yan bileşenlerini hesaba katan otomatik ölçeklendirme politikalarını düzeltmeyi, servis ağı sınırlarını denetlemeyi ve ağ geçitleriyle istemcilerdeki yeniden deneme ve geri çekilme ayarlarını gözden geçirmeyi planlıyor. Yük dengeleyici kapasitesi izlenecek, bölgesel geçiş önlemleri güçlendirilecek.
20 Ağustos: Copilot cloud agent durumları gecikti
20 Ağustos’ta Copilot cloud agent görevlerinin durumu ve sonuçları geç güncellendi. Olay başlığında süre 9 saat 54 dakika, etki özetinde yaklaşık 10 saat 40 dakika olarak veriliyor. En az 54 kuruluşta görev durumu ve sonuç gecikmeleri normal seviyelerin üzerine çıktı; bazı gecikmeler 60 ila 90 dakikaya ulaştı.
Görevlerin kendisi çalışmaya ve tamamlanmaya devam etti. Sorun, durum ve sonuç bilgilerinin işlendiği veritabanı bölgesindeki sağlayıcı kaynaklı arızadan çıktı. Veritabanı gecikmesi yükselince görev durumu güncellemelerini aktaran işlemciler geride kaldı ve birikmiş güncellemeler temizlenemedi.
İlk bölgesel geçiş denemeleri, veritabanındaki bir depolama yapılandırması nedeniyle beklenen sonucu vermedi. Ekip etkilenen bölgeyi zorla devre dışı bıraktı, işlemleri sağlıklı bir bölgeye taşıdı ve ek akış kapasitesi ekledi. Sağlayıcının bölgesi toparlanınca birikmiş güncellemeler işlendi, durum ve sonuç bilgileri normale döndü.
Planlanan düzeltmeler arasında geçişi yavaşlatan depolama yapılandırmasının kaldırılması, bölgesel geçiş prosedürlerinin iyileştirilmesi, sağlıklı geri dönüş bölgeleri için doğrulanmış bir sıra oluşturulması ve yüksek veritabanı gecikmelerinde görev durumu akışının daha dayanıklı hale getirilmesi yer alıyor.
26 Ağustos: Actions çalıştırma başlangıçları gecikti
26 Ağustos’ta GitHub Actions çalıştırmalarının başlatılması etkilendi. Olay başlığında süre 2 saat 50 dakika, etki özetinde yaklaşık 2 saat 53 dakika olarak belirtiliyor. En az 24 kuruluşta çalıştırmalar başlatılamadı veya normalden çok daha geç başladı; toplam 386 kuruluşta en azından bir miktar çalıştırma başlangıcı etkisi görüldü.
Zirve anında her dakikadaki Actions çalıştırma başlangıçlarının beşte birinden fazlası başarısız oldu veya ciddi biçimde gecikti. GitHub Pages dağıtımlarının bir bölümü ve Actions üzerinde çalışan Copilot code review da etkilendi. Geciken çalıştırmaların çoğu kuyruk boşaldıktan sonra başladı. Başlamayan bazı çalıştırmalar yeniden denemeyle başarıyla çalıştı. Olayın ilk bölümünde oluşturulan küçük bir grup çalıştırma ise yeniden denenerek kurtarılamadı ve baştan başlatılması gerekti.
Sorunun temelinde, paylaşılan altyapı servislerinin Actions’taki aylık büyüme ve yoğun trafikle aynı hızda ilerlememesi vardı. Yüksek yük altındaki veritabanına yeni bir etkinlik patlaması eklenince sorgu süreleri yükseldi ve birincil veritabanı doygunluğa ulaştı. Actions olaylarını runner atamalarına dönüştüren dahili servis de yükü karşılayamayınca çalıştırmalar başarısız olmaya ve kuyruğa girmeye başladı.
Veritabanı bir replikaya geçirildi ancak bu işlem sorunu yalnızca kısmen azalttı. Gelen olay trafiğini sınırlamak için kullanılan eşikler başlangıçta veritabanını tam olarak koruyacak kadar düşük değildi. Toparlanma bu nedenle trafiğin kademeli ve manuel biçimde ayarlanmasını gerektirdi. GitHub, veritabanındaki erken stres belirtilerinde Actions trafiğini otomatik sınırlayacak bir devre kesicinin bulunmamasını da olaydan çıkarılan dersler arasında gösteriyor.
Dayanıklılık ve Azure geçişinde ilerleme
GitHub, Ağustos olaylarının ardından kapasite izleme ve yönetiminde, yeniden deneme politikalarında ve temel servislerin dayanıklılığında iyileştirmeler yaptığını belirtiyor. GitHub Actions’a ek kapasite sağlanırken uzun vadeli izolasyon çalışmaları da sürüyor. İş yönlendirme değişiklikleri, işlerin yüzde 33’ünü kısıtlı bir üretim kümesinden boş kapasiteye taşıdı. Bu düzenleme en yüksek önbellek CPU kullanımını yüzde 98’den yüzde 80’e indirdi ve tahmini üç aylık ek kapasite payı sağladı. GitHub bunun nihai çözüm olmadığını, kısa vadeli bir sınırlama önlemi olduğunu vurguluyor.
Azure geçişinde veritabanı birincilleriyle ilgili de ilerleme kaydedildi. 11 Ağustos’ta ilk üretim MySQL birincili Azure üzerinden çalıştırıldı; istemci tarafında gözlemlenen yazma etkisi sınırlı kaldı ve geçişte müşteri etkisi oluşmadı. Aynı yöntem 27 Ağustos’ta iki birincil veritabanında daha tekrarlandı. Daha karmaşık geçişlerin, her geçişten edinilen deneyimle sürdürülmesi planlanıyor.
Azure’a taşınan servislerden gelen okuma trafiği yüzde 60,4’e, GitHub monolitinden gelen okuma trafiği Azure’da yüzde 64,3’e kadar çıktı. Git trafiğinin yüzde 54’ü Azure’a ulaştı.
Kimlik doğrulama çekirdeğine ait 24 tablolu bir grup, GitHub’ın en eski ortak veritabanı olan mysql1’den taşındı. Bu değişiklik, replikalardan saniyede yaklaşık bir milyon sorgunun kaldırılmasını sağladı. Ayrı sorgu düzenlemeleri de saniyede 120 bin sorguyu ortadan kaldırdı ve saat başına yaklaşık 59 bin saniyelik boşa giden veritabanı çalışmasını engelledi.
Pull request izolasyonunda, daha önce anonim trafiğin taşınmasına ek olarak ilk üretim grubundaki kimlik doğrulamalı okumalar da yüzde 100 seviyesine ulaştı. Git aşırı yük korumaları yüzde 6,4 daha fazla trafiği işlerken 95. yüzdelik süreyi yüzde 24, maksimum gecikmeyi ise yüzde 78 iyileştirdi. Uç katmandaki yük azaltma mekanizmaları da ilerledi ve Ağustos olaylarının etkisini sınırlamak için kullanıldı.
İzleme ve telemetri tarafında pull request izleme sistemi, birleştirme, inceleme ve yorum hatalarını birbirinden bağımsız ölçmeye başladı. Böylece yüksek okuma trafiğinin başarısız yazma yollarını maskelemesi önleniyor. 21 Ağustos’ta otomatik yüksek etkili olay algılama sistemi, müşteri destek sinyallerini servis telemetrisiyle birleştirmeye başladı. API izleme sistemi de yeniden ayarlandı ve 30 günlük doğrulamayla gürültüyü azaltıp sinyal kalitesini artırdı.
Bir sonraki çalışma döneminde yeni veritabanı birincillerinin taşınması, servislerin ve ilgili trafiğin Azure’a aktarılması, özellikle ortak veritabanlarının sağlığının iyileştirilmesi, kapasite yönetimi ve otomatik ölçeklendirme için daha fazla otomasyon eklenmesi planlanıyor. Pull request deneyiminde bağımlılık arızalarının ele alınması da genişletilecek.
Kaynaklar ve İleri Okuma
- GitHub Ağustos 2026 kullanılabilirlik raporu
- 17 Ağustos kesintisi ve sonraki çalışmalar
- GitHub sistem durum sayfası
- GitHub Actions güncellemeleri
- GitHub’da dayanıklılık çalışmaları
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments