GitHub'ın Ağustos raporu: Azure göçü sürerken beş olay ve 10 saatlik Actions kesintisi öne çıkıyor

GitHub'ın GitHub Blog'da yayımlanan aylık kullanılabilirlik raporuna göre, Ağustos 2026'da servislerinde performansı düşüren beş olay yaşandı. Şirket, Ağustos'un kullanılabilirlik açısından zor bir ay olduğunu belirterek, olayları öncelikleri yeniden sıralamak için kullandığını söyledi; mimari iyileştirmelere ve Azure'a geçişe yatırım yapsa da riskin tam olarak ortadan kaldırılamayacağını kabul etti. Rapor, iki olay için ayrıntılı keşif raporları sunarken veritabanları, Actions ve izleme alanlarındaki iyileştirme çalışmalarını özetliyor.

6 Ağustos Actions kesintisi

Ayrıntıları verilen en uzun olay 6 Ağustos'ta 15:22 UTC'de başladı ve 10 saat 42 dakika sürdü. Gelen olayları workflow job'larına dönüştüren dahili bir GitHub Actions servisine yapılan rutin bir deployment, bir sitedeki pod kapasitesini kısa süreliğine düşürdü. GitHub, deployment'ın içeriğinin neden olmadığını doğrulamak için geri aldı; asıl sorun, trafiğin diğer sitelere kaymasıyla kalan siteleri sınırlarının ötesine iten geçici kapasite kaybının kendisiydi.

Etkilenen servisler zaten kapasite ve eşzamanlılık sınırlarına yakın çalışıyordu, bu yüzden daha az pod sayısı bile payları tüketmeye yetti. Service mesh sidecar'ları CPU throttling'e maruz kaldı ve bellek yetersizliğinden yeniden başlatıldı; arızalar birden fazla cluster'da cache, DNS ve API hatalarına kademeli olarak yayıldı. En kötü anında Actions workflow çalıştırmalarının büyük bir kısmı başlatılamadı ya da tamamlanamadı.

Job atama yolundaki gizli bir hata kurtarmayı yavaşlattı: runner'lara zaten iptal edilmiş job'lar verildi ve geçerli işleri almak yerine bunları tekrar tekrar deneyerek bekleyen iş kuyruğunu büyüttüler. GitHub genel bir olay ilan etti, doygun servisler için kapasiteyi artırdı ve webhook ile tetiklenen gelen işleri kısıtladı. Ardından runner'ların geçersiz job'ları almasını durduran düzeltmeler yayımladı, kuyrukları boşalttı ve kurtarmayı yavaşlatan iç rate limitlerini yükseltti. Bazı self-hosted runner'ların elle kurtarılması gerekti ve olay penceresine ait bazı olaylar otomatik olarak yeniden oynatılamadı.

Takip çalışmaları arasında service mesh ingress'i ve etkilenen Actions servisleri için pay ve autoscaling eklenmesi, rollout'ların artık kapasiteyi düşürmemesi için deployment süreçlerinin değiştirilmesi, olaydan önceki doygunluk ve veritabanı proxy koşullarının izlenmesi ile gelecek runner ve ARC sürümlerinde self-hosted Actions Runner Controller runner'ları için otomatik kurtarma yer alıyor.

17 Ağustos kimlik doğrulama olayı

İkinci olay 17 Ağustos'ta 13:40 UTC'de başladı ve 7 saat 35 dakika sürdü. Yeni bir trafik zirvesi, bir veri merkezinin load balancer'larını sınırlarının ötesine taşıdı ve bir service-mesh sidecar, ölçeklenmeden eşzamanlılık sınırına ulaştı. Talepler biriktikçe birkaç load-balancer düğümü ağ akışı sınırlarını tüketti, paylaşılan gateway kimlik doğrulama yolunu bozdu ve o veri merkezinden geçen servislerde yaygın kimlik doğrulama gecikmesi ve hatalarına neden oldu. Rapor ayrıca, dahili bir kimlik doğrulama servisine gelen trafiği şiddetle artıran gizli bir istemci retry hatasına işaret ediyor.

Azure göçü kilometre taşları

11 Ağustos'ta GitHub ilk kez üretimde bir MySQL primary'sini Azure'dan çalıştırdı; geçiş sırasında istemci tarafında gözlemlenen yazma etkisi en az düzeyde kaldı ve müşteri etkisi yaşanmadı. 27 Ağustos'ta aynı alıştırma iki primary ile daha tekrarlandı ve karmaşıklığı giderek artan ek failover'lar planlandı. Okuma trafiği de yeni zirvelere ulaştı: göçü tamamlanmış servislerden gelen okumalar %60,4 ile zirve yaptı, GitHub'ın monolith'inden gelen okumalar Azure'da %64,3'e ulaştı ve Git okumaları %54'e vardı.

Veritabanı, Actions ve Git kapasite çalışmaları

24 tabloluk kimlik doğrulama çekirdeği kümesi, GitHub'ın en eski paylaşımlı veritabanı olan mysql1'den taşındı ve replika'larından saniyede yaklaşık bir milyon sorgu kaldırıldı. Ayrı sorgu hijyeni değişiklikleri de saniyede 120.000 sorguyu daha ortadan kaldırdı ve saatte yaklaşık 59.000 saniyelik israf edilen veritabanı işini yok etti.

Actions için job yönlendirme değişiklikleri, job'ların %33'ünü sıkışmış bir üretim cluster'ından boş kapasiteye taşıdı; tepe cache CPU kullanımını %98'den %80'e düşürdü ve tahmini üç aylık bir pay kazandırdı. GitHub bunu geçici bir çözüm olarak nitelendiriyor ve Ağustos kesintisinin daha kalıcı kapasite ve izolasyon ihtiyacını pekiştirdiğini belirtiyor. Pull request izolasyon çalışması sürdü; ilk üretim kümesi için kimlik doğrulamalı okumalar, kimliksiz trafiğin zaten sunulmaya başlanmasının ardından %100'e ulaştı.

Git aşırı yük koruması, 95. yüzdelik süreyi %24 ve maksimum gecikmeyi %78 iyileştirirken %6,4 daha fazla trafik sundu. Edge'deki yeni load-shedding kolları Ağustos olaylarının hafifletilmesinde fiilen kullanıldı.

İzleme ve tespit

Pull request izleme artık merge, inceleme ve yorum hatalarını ayrı ayrı takip ediyor; böylece yoğun okuma trafiği başarısız bir yazma yolunu gizleyemiyor. 21 Ağustos'ta otomatik yüksek etkili olay tespiti, müşteri desteği sinyallerini servis telemetrisiyle birleştirmeye başladı ve API izlemesi, gürültüyü azaltmak için 30 gün boyunca yeniden kalibre edilip doğrulandı. Sırada daha fazla veritabanı primary taşıması, servislerin ve trafiğin Azure'a göçünün sürdürülmesi, daha fazla kapasite yönetimi otomasyonu ve autoscaling ile pull request deneyiminde daha geniş kapsamlı bağımlılık arızası yönetimi var. GitHub'ın tümüne rehberlik ettiğini söylediği öncelik sırası ise şöyle: önce kullanılabilirlik, sonra kapasite, sonra özellikler.

Neden önemli

GitHub, yazılım geliştirmenin büyük bir bölümü için temel altyapıdır ve Actions kesintileri doğrudan build ve deployment'ları engeller. 6 Ağustos keşif raporu, sınırlarına çok yakın çalışan servislerin rutin bir rollout tarafından devrildiği ve gizli hataların kurtarma sırasında hasarı büyüttüğü ders kitabı örneğidir. Rapor ayrıca, kullanım büyümeye devam ederken bu ölçekteki bir platformu Azure'a taşımanın ne gerektirdiğine dair alışılmadık bir şeffaflık sunuyor; bu da bir workflow bir gün başlatılamadığında faydalı bir bağlam sağlıyor.