GitHub kullanılabilirliği hakkında güncelleme

 (github.blog)
2 puan yazan GN⁺ 18 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Son iki kesintinin ardından GitHub, kullanılabilirliği en yüksek öncelik haline getirerek, hızla artan geliştirme iş yükleri ve agentic development workflows doğrultusunda altyapısını ve mimarisini yeniden ele alıyor
  • Tek bir pull request bile Git deposu, Actions, arama, bildirimler, yetkiler, webhooks, API'ler, arka plan işleri, önbellekler ve veritabanlarıyla geniş ölçekte bağlantılı; küçük verimsizlikler büyüdüğünde kuyruk birikmesi ve bağımlılıkların yayılmasına yol açabiliyor
  • Kısa vadede odak noktası, webhooks için arka uç taşıması, kullanıcı oturumu önbelleğinin yeniden tasarlanması, kimlik doğrulama ve yetkilendirme akışlarının ayarlanması ve Azure tabanlı işlem kapasitesinin artırılmasıyla darboğazları ve veritabanı yükünü azaltmak
  • Uzun vadede ise çekirdek servislerin izole edilmesi, tekil hata noktalarının azaltılması, Ruby monolith'in bazı bölümlerinin Go'ya taşınması ve public cloud geçişiyle birlikte multi cloud yolu oluşturulması sayesinde dayanıklılık ve esneklik artırılıyor
  • 23 Nisan'daki merge queue regresyonu ile 27 Nisan'daki Elasticsearch aşırı yüklenmesinde veri kaybı yaşanmadı; GitHub ayrıca status page'e kullanılabilirlik metrikleri ekleyip küçük kesintileri de daha geniş kapsamda duyurarak şeffaflığı güçlendiriyor

Kullanılabilirlik çalışmalarının arka planı

  • GitHub, son iki kesintinin ardından kullanılabilirlik ve güvenilirlik iyileştirme çalışmalarının durumunu paylaştı
  • 2025 Ekim'den itibaren kapasiteyi 10 kat artırma planını uygulamaya koydu ve 2026 Şubat itibarıyla bugünkü ölçeğin 30 katına göre tasarım yapılması gerektiği netleşti
  • Bunun başlıca nedeni yazılım geliştirme biçimindeki değişim; 2025'in ikinci yarısından sonra agentic development workflows hızla ivmelendi
  • Depo oluşturma, pull request etkinliği, API kullanımı, otomasyon ve büyük depo iş yükleri hızla artıyor

Ölçeklenme sürecinde ortaya çıkan yapısal yük

  • Tek bir pull request, Git deposu, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches ve databases dahil birçok bileşeni etkileyebiliyor
  • Büyük ölçekte küçük verimsizlikler bile birikerek kuyruk birikmesine, önbellek kaçırmalarının veritabanı yüküne dönüşmesine, indeks gecikmelerine, yeniden deneme trafiğinin büyümesine ve yavaş bağımlılıkların birden fazla ürünü etkilemesine neden olabiliyor
  • Öncelik sırası önce kullanılabilirlik, sonra kapasite, ardından yeni özellikler olarak belirlendi
  • Gereksiz işlerin azaltılması, önbelleğin iyileştirilmesi, çekirdek servislerin izole edilmesi, tekil hata noktalarının kaldırılması ve performans ile ölçeğe duyarlı yolların özel sistemlere taşınması eş zamanlı yürütülüyor
  • Bir alt sistem baskı altına girdiğinde tüm sistemin çökmesini önlemek için gizli bağlılığın azaltılması, blast radius'un sınırlandırılması ve graceful degradation sağlanması temel hedefler haline geldi

Hâlihazırda yürüyen iyileştirme çalışmaları

  • Kısa vadede, beklenenden hızlı ortaya çıkan darboğazların giderilmesine odaklanılıyor
  • webhooks, MySQL dışındaki başka bir arka uca taşındı; kullanıcı oturumu önbelleği yeniden tasarlandı ve kimlik doğrulama ile yetkilendirme akışları da yeniden düzenlenerek veritabanı yükü ciddi ölçüde azaltıldı
  • Azure geçişinden yararlanılarak daha fazla işlem kaynağı da sağlandı
  • Sonraki aşamada git ve GitHub Actions gibi çekirdek servislerin izole edilmesine ve tekil hata noktalarının azaltılmasına odaklanılıyor
  • Bağımlılıklar ve trafik katmanları ayrıntılı biçimde incelenerek nelerin ayrılması gerektiği belirlendi; çeşitli saldırıların normal trafiğe etkisini en aza indirecek önlemler risk sırasına göre uygulanıyor
  • Performans ya da ölçeğe duyarlı kodun bir kısmını Ruby monolith'ten Go'ya taşıma çalışmaları da hızlandırıldı
  • Mevcut küçük ölçekli şirket içi veri merkezlerinden public cloud'a geçiş sürerken, daha uzun vadeli olarak multi cloud yolu da eş zamanlı ilerletilmeye başlandı
  • Bu uzun vadeli adım, ileride ihtiyaç duyulacak dayanıklılığı, düşük gecikmeyi ve esnekliği sağlamak için gerekli görülüyor

Büyük depolar ve merge queue çalışmaları

  • Depo sayısındaki artıştan daha zor bir ölçeklenme sorunu olarak büyük monorepo artışı öne çıkarılıyor
  • Son 3 ayda hem git sistemi hem de pull request deneyimi tarafında bu eğilime yönelik yatırımlar önemli ölçüde artırıldı
  • Daha yüksek verimlilik ve ölçeklenebilirlik için yeni API tasarımı üzerinde de çalışılıyor ve bu konu ayrı bir blog yazısıyla paylaşılacak
  • Günde binlerce pull request oluşan depolar için kritik olduğundan, merge queue iş optimizasyonuna da yatırım yapılıyor

Son kesinti 1: 23 Nisan merge queue sorunu

  • 23 Nisan'da pull request'lerin merge queue davranışında bir regresyon yaşandı
  • squash merge kullanan merge queue'da, merge group içinde iki veya daha fazla pull request yer aldığında hatalı bir merge commit oluşturuldu
  • Etkilenen durumlarda sonraki birleştirmeler, daha önce birleştirilen pull request'lerin ve mevcut commit'lerin değişikliklerini istemeden geri alan bir sonuca yol açtı
  • Etki süresince 658 depo ve 2.092 pull request etkilendi
  • İlk rakamlar ihtiyatlı belirlendiği için başlangıçta paylaşılan sayı bundan biraz daha yüksekti
  • merge queue dışında birleştirilen pull request'ler etkilenmedi; merge veya rebase kullanan merge queue grupları da etkilenmedi
  • Veri kaybı olmadı. Tüm commit'ler Git içinde kayıtlı kalmaya devam etti
  • Ancak etkilenen depoların varsayılan branch durumu hatalıydı ve tüm depoları otomatik olarak güvenli biçimde kurtarmak mümkün olmadı
  • incident root cause analysis: ek ayrıntılar burada görülebilir
  • Bu kesinti, bir dizi süreç başarısızlığını ortaya çıkardı ve aynı tür sorunların tekrarlanmaması için bu süreçler değiştiriliyor

Son kesinti 2: 27 Nisan arama sorunu

  • 27 Nisan'da, çok sayıda arama tabanlı deneyimden sorumlu Elasticsearch alt sisteminde bir kesinti yaşandı
  • Etki alanına pull requests, issues ve projects için bazı arama tabanlı kullanıcı arayüzleri de dahildi
  • Kök neden analizi henüz tamamlanma aşamasında ve yakında yayımlanacak
  • Şu ana kadar belirlenenlere göre küme aşırı yük durumuna girdi ve bunun sonucunda arama sonuçları döndürülemedi
  • Aşırı yükün nedeni olarak botnet attack olasılığı da değerlendiriliyor, ancak kök neden analizi henüz tamamlanmış değil
  • Veri kaybı yaşanmadı ve Git işlemleri ile API'ler etkilenmedi
  • Ancak aramaya bağımlı bazı kullanıcı arayüzleri hiçbir sonuç gösteremediği için ciddi karışıklık yarattı
  • Bu sistem, tekil hata noktalarını kaldırmak için tam izolasyonun henüz tamamlanmadığı alanlardan biriydi; o zamana kadar diğer alanlardaki risk önceliği daha yüksekti
  • Aynı tür bağımlılık analizi ve blast radius azaltma çalışmaları uygulanarak bu tür arızaların olasılığı ve etkisi düşürülmeye çalışılıyor

Kesinti şeffaflığının güçlendirilmesi

  • Kesintiler sırasında müşterilerin daha fazla şeffaflık istediği net biçimde ortaya çıktı
  • Yakın zamanda GitHub status page güncellendi ve artık availability metrikleri de içeriyor
  • Sadece büyük kesintiler değil, küçük kesintiler de status'ta paylaşılacak; amaç kullanıcıların sorunun kendi taraflarında mı yoksa GitHub tarafında mı olduğunu tahmin etmek zorunda kalmaması
  • Kesinti sınıflandırma yöntemi de sürekli geliştiriliyor; ölçeği ve kapsamı daha kolay anlaşılır hale getirmek hedefleniyor
  • Kesintiler sırasında müşterilerin sinyal paylaşma ve sorun bildirme biçimlerini iyileştirmeye yönelik çalışmalar da sürüyor

Bundan sonraki taahhütler

  • GitHub, kullanılabilirliği iyileştirme, dayanıklılığı artırma, gelecekteki yazılım geliştirme ölçeğine uygun biçimde büyüme ve daha şeffaf iletişim kurma taahhüdünde bulunuyor
  • 23 Nisan kesintisinden etkilenen depo sayısı, 28 Nisan 2026 itibarıyla güncellendi

İlgili okumalar

1 yorum

 
GN⁺ 18 시간 전
Hacker News yorumları

  • GitHub bu yıl şimdiden onlarca kez kesinti yaşadı ve kullanılabilirlik ile güvenilirlik geçen yıla göre gözle görülür biçimde kötüleşti.
    Bu artık gösterge paneli ve ısı haritası çıkarılacak kadar ciddi; HN ya da Reddit gibi yerlerde GitHub istikrarsızlığının meme olma seviyesine geldiğini düşünüyorum.
    Buna rağmen önceliğin "availability, capacity, new features" olduğunu söylemek, gerçek durumu fazla gevşek değerlendirmek gibi geliyor.
    Şu an öncelikler 1, 2, 3 tamamen availability olmalı; en az 6 ay başka hiçbir şey konuşmadan sadece bunu düzeltmeleri gerek.

  • 6 ay önce Azure geçişi en yüksek öncelik denilerek özellik geliştirme ertelenmişti; şimdi de kullanılabilirlik en büyük öncelik deniyor, bu yüzden anlatı pek tutarlı gelmiyor.
    O zaman AI ve Copilot talebi yüzünden Virginia veri merkezi kapasite kısıtının "existential" olduğu söylenmişti; hâlâ aynı sorunla sendelediklerini görmek bunu daha da tuhaf kılıyor.
    Özellik geliştirme ertelendi denmesine rağmen her hafta yeni özellikler ve UI değişiklikleri gelmeye devam ediyor; kısa süre önce de tekil issue görünümünü değiştirdiler.
    Microsoft kadar kaynağa sahip bir şirketin sürekli aynı noktada tökezlemesi inanması zor bir durum ve popüler geliştirici hizmetlerini satın alıp hepsini aynı platforma taşıma stratejisi de güvensiz görünüyor.

    • Bu biraz fazla kötü niyetli bir yorum gibi de duruyor.
      Büyük mühendislik organizasyonlarında öncelikler birbirini dışlayan şeyler değildir; temel önceliğe doğrudan katkı veremeyen ekipler başka özellikler üzerinde çalışmayı sürdürebilir.
    • O single issues view değişikliği, performans baskısını hafifletmek için yapılmış panikvari bir hack’e daha yakındı.
      https://news.ycombinator.com/item?id=47912521
    • Azure geçişi kullanılabilirlik sorunlarını daha da kötüleştirmiş bile olabilir.
      Özel donanım buluttan daha öngörülebilir olabilir ve "Azure’a gitmeyelim, birkaç rack daha alalım" gibi bir karar GitHub yönetiminin tek başına verebileceği bir şey olmayabilir.
    • Son 5 yılda hiç özellik değişikliği olmasaydı kimse kızmazdı ama yine de durmadan kurcalıyorlar.
      GitHub her 5 dakikada bir yeniden tasarlanacak bir site değil ve bazen yöneticiler varlık nedenlerini kanıtlamak için sırf yeni özellik olsun diye yeni özellik itiyormuş gibi görünüyor.
      Sonuçta ne kadar çok bozarlarsa kullanıcı çekme konusunda o kadar ters etki yaratıyor.
      Arama da ciddi biçimde zayıflatıldı; Google Search ya da YouTube’da olduğu gibi neden herkes eskiden düzgün çalışan aramayı sürekli bozuyor anlamıyorum.
      Üstelik Microsoft’un neredeyse terk edilmiş gibi duran bir Azure DevOps’u da var, GitHub’ı da var; ikisinde de özellikle ticket sisteminden nefret ediyorum.
      Her Jira projesinin ayarlarının farklı olmasından bıkmıştım ama artık "keşke Jira olsa" noktasına gelindi.

  • O yazıyı ciddiye alarak okumak zor gibi hissettiriyor.
    Büyük sayıların konduğu etiketsiz grafikler, gerçek deneyimle uyuşmayan öncelikler ve son 12 ayın korkunç uptime performansını yeterince kabul etmeyen tavır gerçekten rahatsız edici.

    • Grafikler tamamen berbat sayılmaz.
      Sol alttaki eksen etiketleri olmasa da, 2023→2024→2025→2026 arasında büyüme hızının çok yüksek olduğu ana mesajı veriyor.
      2026’nın başı ya da sonu civarında önceki 3 yılın toplamından bile daha büyük bir büyümeden söz ediyor gibi okunuyor; eksen sayılarını bilmeseniz de genel eğilim görülebiliyor.
      Bunun doğrusal bir grafik olduğunu varsaymak gerekiyor ama bağlam içinde bu çok da zorlayıcı görünmüyor.
      Planlanandan çok daha büyük büyüme yaşayan bir şirketin kapasite sorunu yaşaması kaçınılmaz ve artık sadece daha fazla donanım eklemekten öte backend verimliliği gerekiyor gibi duruyor.
      Yazdıkları hedefler de büyük ölçüde buna yönelmiş.
    • Sayılar burada da var.
      https://x.com/kdaigle/status/2040164759836778878
      Mevcut büyümenin üstel olduğuna inanmıyorlar mı, yoksa yıllık 10 kat büyümeyi çok da zor görmüyorlar mı, emin değilim.
    • Satın alma sonrası 6 yıl boyunca durum böyleydi demek de mümkün olabilir.
      https://damrnelson.github.io/github-historical-uptime/
    • Özetle yaklaşık 300 kelimelik bir "sizi dinliyoruz" mesajı gibi görünüyor.
    • Bu tür süslü grafikler birçok müşteri tarafında zaten benzer şekilde kullanılıyor.

  • "multi cloud yolunu başlattık" cümlesi, Microsoft’un fiilen Azure’un tek başına istedikleri güvenilirlik seviyesini veremediğini kabul etmesi gibi duyuluyor.

    • Oldukça ciddi bir sinyal gibi görünüyor ve Azure kullanmış biri olarak buna rahatlıkla inanabiliyorum.
    • Bu, kesinti sırasında para kaybeden kurumsal müşterilere yönelik bir hamle de olabilir.
      Müşteri tutma oranını korumaya yardımcı olabilir.
    • Bu ölçekte karmaşık bir sistem için tek tedarikçiye bağımlılıktan kaçınmak zaten mantıklı bir yaklaşım.
    • Eskiden burada Dave Cutler’ın Azure vizyonunun öncelikler, baskı ve yönetim nedeniyle bozulduğunu anlatan bir yazı okuduğumu hatırlıyorum.
      Aslen insan müdahalesinin neredeyse olmadığı bir operasyon hedefleniyordu ama şimdi birilerinin rack’lere ya da VM’lere seri konsolla bağlanıp elle müdahale etmesi sıradan prosedür haline gelmiş deniyordu.
      Şu an linki bulamıyorum.
    • Show HN’de gönderim zamanı sanılandan daha önemli.
      En aktif okurlar Pacific saatine göre Pazartesi-Perşembe 09:00-11:00 arasında oluyor; hafta sonu rekabet daha az ama etkileşim de daha düşük.

  • GitHub CTO’su Codepath.org yönetim kurulunda da yer alıyorsa ve oradaki açıklama "ilk AI-native nesil mühendisleri, CTO’ları ve kurucuları yetiştirmek" gibi bir şeyse, sorunun nerede olabileceğine dair az çok fikir veriyor.

  • Hissedilir düzeyde GitHub kararlılığı çok kötüleşti ve son dönemde web’de gösterdikleri verilere bile güvenmek zor.
    Dünden beri ben ve birkaç iş arkadaşım çeşitli depolarda PR listesinin eksik göründüğünü doğruladık.
    Örneğin https://github.com/gap-system/gap/pulls sayfasında sekmede "Pull requests 78" yazıyor ama liste görünümünde yalnızca "35 open" görünüyor.
    Doğru sayının 78 olduğu gh pr list ile de doğrulanabiliyor ama https://www.githubstatus.com hâlâ "all systems operational" gösteriyor.

    • Projelerimin önemli bir kısmında son 6 gündür kapanan PR görünmüyor.
      CLI üzerinden liste geliyor ama aramadan geçen web yolunda hepsi kayboluyor.
      Destek ekibi sorunu kabul etti ama sonrasında sessizlik oldu; durum sayfasında da 27’sindeki muhtemelen ilgili görünen olay dışında hiçbir şey yok.
      Bazı depolarda arada düzelmiş gibi görünse de birçok org ve repo’da hâlâ tekrar üretilebiliyor.
      https://github.com/orgs/community/discussions/193388
    • Ben de aynı şeyi gördüm ve status page’de hâlâ yok.
      Eksik PR’ları branch sayfasını kurcalayarak ancak bulabildim.
    • Bu büyük ihtimalle ölçeklenebilirlik uğruna yaklaşık sorgular kullanıp %100 doğru olmayan sonuçlar döndüren bir hack.
      Tam bir bug’dan ziyade, altyapı yükünü azaltmak için ürün açısından çok kötü bir tercih yapılmış olabilir.

  • Son birkaç yılın yeni repo/issues/commits verilerini paylaşmaları yine de ilginçti.
    Dışarıdan tahmin edildiği gibi, ajanların GitHub’a ani ve büyük bir ek yük bindirdiğini doğruluyor.
    Zaten devasa bir kullanıcı tabanına hizmet verirken aynı zamanda bir startup gibi üstel büyüme yaşayınca hedef haline gelmeleri kaçınılmaz ve organizasyonun hızlı hareket etmesi de kolay görünmüyor.
    Öte yandan, yetenek, altyapı ve finansman açısından bir startup’tan çok daha fazla şeye sahipler.

    • Hangi veriden söz edildiğini anlamadım.
      Ortada sadece etiketsiz bir grafik ve mevcut tepe sayıları var.

  • Bu grafiklerle tam olarak ne yapıldığını anlamıyorum; neredeyse bir sanatçının empresyonist işi gibi görünüyorlar.
    Commit grafiğine bakınca neden büyük bir basamak oluşup sonra yavaşça söndüğü, neden bu basamağın sabit noktalarda oluşmadığı ya da neden bazen daha büyük sıçramaların daha düşük eğime sahip olduğu açıklanmıyor.
    Diğer grafikler de tamamen farklı biçimde hareket ediyor; bu da daha da garip.

    • Çünkü bunlar klasik PowerPoint grafikleri.
      Gerçek veriyi ya da verinin anlamını göstermekten çok sadece "bir şey yükseliyor" mesajı vermek için kullanılıyorlar.

  • Bence sonunda gelecek federated forge yapılarında.
    Depoların kendi sovereign altyapısında barındırılması ve üstüne küresel kimlik ile federated metadata issue/PR katmanının gelmesi daha doğru görünüyor.
    Bu tür küresel indeksleri ayağa kaldırmak da kolay olduğundan kullanılabilirliği büyük bir sorun olmaktan çıkarabilir; biz de o yönde çalışıyoruz.

    • Fikir hoş ama çoğu kişi kendi barındırmasını yapmak istemez.
      Sonuçta üçüncü taraf barındırma kullanılınca yine 1-3 büyük oyuncunun ortaya çıkması muhtemel.
      Ayrıca kullanılabilirlik sorunundan kaçınmak için self-hosting yapsanız bile, bağımlılıklarınız GitHub gibi büyük hizmetlere bağlıysa onların kesintisinden yine kaçamazsınız.
      Bu yüzden pratik çözüm, bugün olduğu gibi kullandığınız her şeyi proxy’lemek ya da mirror’lamak olur.
    • Aslında bunu şimdiden yapmak mümkün.
      Aynı repo’yu GitHub, Codeberg ve self-host üzerinde tutup sadece ana branch tutarlılığını yönetmeniz yeterli.
      Sonrasında her yerden güncelleme yapabilirsiniz; README’ye de linkleri düzgün koyarsınız.
    • Kodlama ajanları derin VCS entegrasyonu yaparken GitHub’ı varsayılan almamış olsaydı iyi olurdu.
      Düzgün bir API ya da webhook sunan başka bir forge’u bağlayıp aynı kolaylığı elde edebilsem her şeyi self-host etmek isterdim.
      Ajan tarafının da arayüzünü açması gerekir ama plugin yapısıyla GitHub bağımlılığı kaldırılıp geri kalanının MCP ya da skills ile çözülebileceğini düşünüyorum.
    • Güzel fikir; sitemizdeki LLM üretimli içerik için de bunu kullanmak isterim.
      Büyük runner’ları self-host etmek benim için sorun değil, bu yüzden yakın zamanda Codeberg’e geçtim; küçük cron işleri içinse Codeberg’in sunduğu runner’ları kullanıyorum.
      Hatta bu tür işler için orada lazy runner bile var.
    • Bu kavramı ilk kez duyuyorum; kayıt olup denemeyi düşünüyorum.

  • Şu an yaptıkları şey bana buna benziyor.
    Token sübvansiyonu yeterince eğitim verisi topladı ve agentic junkies işi artık kendi çarkını çevirecek kadar büyüdü; şimdi bunu kesip zarar yazdıran ürünü temizlemeye çalışıyor gibiler.
    https://news.ycombinator.com/item?id=47923357