OKUR MODUOkuma deneyimini kendine göre ayarla.
100%

GitHub kullanılabilirlik raporu ne söylüyor?

GitHub kullanılabilirlik raporu, Ağustos 2026 boyunca hizmetlerde performans düşüşü yaratan beş olay yaşandığını bildiriyor. Şirket, ayın kullanılabilirlik bakımından zorlayıcı geçtiğini belirtirken, olayları tamamen ortadan kaldırmanın mümkün olmadığını; buna karşılık olaylardan elde edilen bulgularla önceliklerin yeniden düzenlendiğini ifade ediyor.

Raporun odağında tek tek kesintilerin ayrıntılarından çok, olaylardan sonra yapılan kapasite, dayanıklılık ve gözlemlenebilirlik çalışmaları bulunuyor. Bu yaklaşım, platformun hangi alanlarda darboğaz gördüğünü ve bu alanlarda hangi ölçümlerin izlendiğini görünür kılıyor. GitHub ayrıca mimari iyileştirmelere ve Azure’a taşınmaya yatırım yaptığını, bu geçişin daha fazla kapasite sağlamasının beklendiğini aktarıyor.

Azure geçişinde okuma trafiği ölçümleri

GitHub, 11 Ağustos’ta üretimdeki birincil MySQL veritabanını ilk kez Azure’dan çalıştırdığını açıkladı. Şirkete göre geçiş sırasında istemcilerin gözlemlediği yazma etkisi sınırlı kaldı ve müşteri etkisi oluşmadı. Aynı düzen, 27 Ağustos’ta iki ek birincil veritabanında tekrarlandı. İlerleyen haftalar için daha karmaşık geçişler planlanırken, şirket her failover deneyiminden öğrenerek kapsamı artıracağını belirtiyor.

Geçirilen hizmetlerden gelen okuma trafiği yüzde 60,4 ile zirve yaptı. GitHub’ın monolit uygulamasındaki Azure okuma oranı ise yüzde 64,3’e ulaştı; Git okuma trafiğinde kaydedilen oran yüzde 54 oldu. Bu oranlar, Azure’a taşınan trafik miktarını tanımlıyor; rapor, bunları doğrudan beş olayın nedeni ya da çözümü olarak sunmuyor.

Veritabanı yükünde düşüş kaydedildi

Rapor, bölgesel geçişin dışında paylaşımlı veritabanı yükünü azaltmaya dönük bir çalışmayı da aktarıyor. Kimlik doğrulama çekirdeğindeki 24 tabloluk grup, GitHub’ın en eski paylaşımlı veritabanı olarak nitelenen mysql1’den taşındı. Bu değişiklik, söz konusu veritabanının replikalarından saniyede yaklaşık bir milyon sorgunun kaldırılmasını sağladı.

Ayrı sorgu hijyeni düzenlemeleriyle saniyede 120 bin ek sorgu azaltıldı. GitHub’ın hesabına göre bu işlem, saatte yaklaşık 59 bin saniyelik gereksiz veritabanı çalışmasını ortadan kaldırdı. Rapor, veri tabanı sağlığını özellikle paylaşımlı veritabanlarında iyileştirme hedefinin sonraki ay da sürdüğünü söylüyor.

GitHub Actions için kısa vadeli kapasite hamlesi

GitHub Actions tarafında iş yönlendirme değişiklikleri, işleri kapasitesi kısıtlı bir üretim kümesinden boş kapasiteye taşıdı. Bu düzenleme ile işlerin yüzde 33’ü farklı kapasiteye yönlendirildi. Rapor, en yüksek önbellek CPU kullanımının yüzde 98’den yüzde 80’e gerilediğini ve yaklaşık üç aylık ek kapasite payı oluştuğunu belirtiyor.

Ancak GitHub bu hamleyi kalıcı çözüm olarak nitelemiyor. Şirket, bunu kısa vadeli bir sınırlandırma önlemi olarak tanımlıyor; Ağustos’taki olayların daha kalıcı kapasite ve yalıtım ihtiyacını pekiştirdiğini ekliyor. Uzun vadeli yalıtım çalışmaları bu nedenle devam ediyor.

Pull request ve Git korumalarında gözlenen sonuçlar

Pull request yalıtım çalışmasında, ilk üretim grubundaki kimliği doğrulanmış okuma istekleri yüzde 100’e ulaştı. Rapor, daha önce kimlik doğrulaması olmayan trafiğin de bu altyapıdan sunulduğunu belirtiyor. Bu veri, yalıtımın ilk üretim grubundaki okuma kapsamını gösteriyor; tüm pull request işlemlerine ilişkin genel bir kullanılabilirlik oranı vermiyor.

Git aşırı yük korumalarına yönelik yatırımların ardından yüzde 6,4 daha fazla trafiğe hizmet verildiği bildirildi. Aynı dönemde 95. yüzdelik dilimdeki süre yüzde 24, azami gecikme ise yüzde 78 iyileşti. Kenardaki daha geniş yük azaltma korumaları da ilerletildi ve GitHub, bu korumaların Ağustos olaylarının etkisini azaltmakta kullanıldığını söylüyor.

İzleme sistemleri daha ayrıntılı sinyal toplamaya yöneldi

Raporun önemli veri başlıklarından biri de tespit mekanizmaları. Pull request izleme sistemi artık birleştirme, inceleme ve yorum başarısızlıklarını ayrı ayrı ölçüyor. GitHub’a göre yüksek okuma hacmi, aksi hâlde başarısız bir yazma yolunu maskeleyebiliyor; ayrıştırılmış metrikler bu riski görünür kılmayı amaçlıyor.

21 Ağustos’ta yüksek etkili olayların otomatik tespiti, müşteri destek sinyallerini hizmet telemetrisiyle birleştirmeye başladı. API izleme sistemi de 30 gün boyunca yeniden kalibre edilip doğrulandı. Şirket, bu süreçle gürültünün azaltıldığını ve sinyal kalitesinin yükseltildiğini bildiriyor. Bu değişikliklerin hedefi, olayların daha iyi tespit edilmesi ve müdahalenin iyileştirilmesi.

Sonraki çalışmaların kapsamı

GitHub, gelecek dönemde yeni birincil veritabanlarını taşımayı, hizmetleri ve ilgili trafiği Azure’a geçirmeyi sürdüreceğini açıkladı. Plan ayrıca paylaşımlı veritabanlarının sağlığını geliştirmeyi, kapasite yönetimi ile otomatik ölçeklendirmede daha fazla otomasyon eklemeyi içeriyor.

Ağustos verileri, platformun aynı anda kapasite, veritabanı yükü, trafik yalıtımı ve olay tespiti üzerinde çalıştığını gösteriyor. Bununla birlikte rapor, yapılan iyileştirmelerin gelecekteki olayları bütünüyle engelleyeceği sonucuna varmıyor; GitHub, riskin tamamen ortadan kaldırılamayacağını açıkça vurguluyor.

HİP AIAkıllı formatlama · AI endpoint henüz bağlı değil
HİKÂYEYİ DÖNÜŞTÜR

Bir içerik, dört format.

Okumaya vaktin yoksa özetle; paylaşacaksan platforma göre yeniden düzenle.

GitHub’ın Ağustos 2026 kullanılabilirlik raporu, beş olayın hizmetlerde performans düşüşüne yol açtığını ortaya koyuyor. Şirketin verileri, kapasite yönetimi, Azure geçişi ve izleme sistemlerindeki çalışmanın ölçülebilir sonuçlarını da kayda geçiriyor.

• GitHub kullanılabilirlik raporu ne söylüyor?
• Azure geçişinde okuma trafiği ölçümleri
• Veritabanı yükünde düşüş kaydedildi

Bu önizleme yalnızca sayfadaki editoryal veriyi yeniden biçimlendirir. Gerçek yapay zekâ üretimi Core tarafında güvenli bir sunucu endpoint’iyle bağlanacak.

Bir yeni fikir, bir sonraki sekmede.