GitHub, %99,9 kullanılabilirliği korumakta bile zorlanıyor gibi görünüyor

 (theregister.com)
4 puan yazan GN⁺ 2026-03-24 | 5 yorum | WhatsApp'ta paylaş
  • Son dönemde GitHub'da sık hizmet kesintileri yaşanırken, sektör standardı kabul edilen '5 nines (%99,999)' bir yana, '3 nines (%99,9)' seviyesine ulaşmak bile zor görünüyor
  • 9 Şubat'ta Actions, Pull Request, bildirimler, Copilot gibi temel özellikler aynı anda kesinti yaşadı ve bazı hizmetlerde saatler süren gecikmeler meydana geldi
  • Copilot politika yayılımı sorunu nedeniyle bazı kullanıcılar 10 Şubat sabahına kadar model görüntüleme hatası yaşadı
  • GitHub'ın durum sayfası yapısını değiştirmesi, son 90 güne ait kullanılabilirlik takibini zorlaştırdı; gayriresmî verilerde kullanılabilirliğin %90'ın altına indiği dönemler de görüldü
  • Enterprise Cloud SLA'sı %99,9 uptime belirtse de bu fiilen tüm kullanıcılara garanti edilmiyor; bu da kesinti odaklı operasyon stratejilerine olan ihtiyacı artırıyor

GitHub'da düşen kullanılabilirlik ve sık hizmet kesintileri

  • Bulut hizmetlerinde sık kesintilerin sıradanlaştığı bir dönemde, GitHub da istikrar sorunları yaşıyor
    • "Neredeyse kesintisiz geçen bir gün bile yok" ifadesi kullanılırken, '5 nines (%99,999)' bir yana '1 nine (%90)' seviyesinin bile zor olduğu belirtiliyor
  • 9 Şubat'ta (UTC'ye göre) GitHub'ın temel özellikleri olan Actions, Pull Request, bildirimler ve Copilot aynı anda sorun yaşadı
    • GitHub, 15:54 civarında "bazı hizmetlerde sorun var" duyurusu yaptı ve bildirim gecikmesinin yaklaşık 50 dakika olduğunu açıkladı
    • 17:57'de gecikmenin yaklaşık 30 dakikaya düştüğünü, 19:29'da ise normale döndüğünü bildirdi
  • Copilot ile ilgili kesinti daha uzun sürdü
    • 9 Şubat 16:29'dan 10 Şubat 09:57'ye kadar bazı kullanıcılar için Copilot politika yayılımı sorunu yaşandı
    • Bu nedenle yeni etkinleştirilen modellerin kullanıcılara görünmemesi sorunu bildirildi
  • GitHub, durum sayfası yapısını değiştirerek son 90 güne ait kullanılabilirlik takibini zorlaştırdı
    • Ayrıntılar sunulsa da genel uptime eğilimini görsel olarak kavramayı zorlaştıran bir yapıya geçildi
    • Gayriresmî kurtarma sayfası (mrshu.github.io/github-statuses/) verilerinde, 2025'te bir dönemde kullanılabilirliğin %90'ın altına düştüğü görüldü
  • GitHub'ın Enterprise Cloud SLA'sı %99,9 uptime belirtse de bunu tüm kullanıcılara garanti etmiyor
    • Sektörde '5 nines' ideal ölçüt olarak görülse de, bazı sağlayıcıların %90'ı korumakta bile zorlandığı değerlendiriliyor
    • Bu durum, müşterilerin kesintiyi varsayan operasyon planları hazırlaması gerektiğine işaret ediyor

İlgili bağlam ve örnekler

  • GitHub son dönemde yapay zeka özellikleri ve politika değişiklikleri nedeniyle çeşitli tartışmalar yaşadı
    • Pull Request'lerde yapay zeka kodunu engellemek için bir 'kill switch' değerlendirilmesi

    • Self-hosted runner ücret planından geri adım atılması

      • Zig dil projesinin, Microsoft'un yapay zeka odaklı politikalarını gerekçe göstererek GitHub'dan ayrıldığı bir örnek bulunuyor
      • Bu olaylarla birlikte hizmet istikrarındaki düşüş, geliştirici topluluğundaki memnuniyetsizliği büyüten bir unsur oldu

Sonuç

  • GitHub'daki son kesintiler, 'üç tane 9' (%99,9) seviyesine bile ulaşmakta zorlanan bir kullanılabilirlik sorununu ortaya koyuyor
  • Copilot gibi çekirdek özelliklerdeki istikrarsızlığın sürmesi, bulut tabanlı geliştirme platformlarında güvenilirliğin sağlanmasını önemli bir gündem haline getiriyor
  • Kesintilere karşı strateji oluşturma ihtiyacı bir kez daha vurgulanıyor

İlgili okumalar

5 yorum

 
elbanic 2026-03-26

GitHub ücretsiz bir hizmet; ondan yüksek erişilebilirlik beklemek bile...
 
cosine20 2026-03-27

KakaoTalk’ta bir kesinti olsa yine aynı şeyi söyler misiniz...
 
malkeu 2026-03-26

Muhtemelen git reset --hard yapmak yeterlidir.
 
master6559 2026-03-25

GitHub'da kesinti çıkmadığı sürece şu anki hali iyi.
 
GN⁺ 2026-03-24
Hacker News görüşleri

  • Github'ın çalışma süresi (uptime) sorununun açıkça ciddi olduğu doğru, ancak tüm özellikler aynı anda durdu diye “GitHub tamamen çöktü” demek bana abartılı geliyor
    Ben Copilot'u neredeyse hiç kullanmadığım için o servis sık sık dursa da umursamıyorum
    Asıl önemli olan Git, web sitesi, API, Actions gibi çekirdek işlevlerin kararlılığı

    • Katılıyorum. Ama son 90 gün içinde tek bir hizmet bile 3x9 (%99,9) çalışma süresine ulaşamadı
      GitHub'ın Enterprise SLA belgesine göre hizmet başına en az %99,9 garanti edilmeli, fiili değerler ise burada görülebilir
    • “GitHub çöktü” ifadesinin abartılı olduğu doğru, ama gerçekte API bile yalnızca %99,69, yani iki tane 9 seviyesinde
      Copilot bir tane 9 düzeyinde, çekirdek hizmetler olan Git ve Actions da aynı durumda
    • Bu şirket 1 trilyon dolarlık küresel bir şirketin portföyünde yer alıyor
      Bu kadar kaynağa sahip bir şirketin müşterileri kendi haline bırakmasının mazereti olamaz
    • Bugünlerde büyük şirketlerin sözünü ettiği “5 nines” neredeyse tamamen bir yanılsama
      Gerçekte hata yanıtları bile “normal çalışıyor” diye sayılıyor
      Ağ sektöründeki gibi gerçekten %99,999'a ulaşan durumlar nadir; çoğu yerde yalnızca veri dilimleme hileleriyle durum sayfası yeşil tutuluyor

  • 2025'te GitHub CTO'su “Azure'a tamamen geçerek güvenilirliği artıracağız” dediği andan beri içim rahat değil
    Eskiden topluluk “yeni özellikleri daha hızlı ekleyin” diye bağırırdı, şimdi ise istikrar ve güvenilirlik çok daha acil

    • Yine de GitHub yeni özellik ekleme konusunda da hâlâ yavaş
    • Yalnızca büyük platformları kullanmıyorsanız, küçük ama sıkıcı derecede kararlı alternatifler de var
    • Ben o dönemde katılmıştım ve depomu herkese açık paylaşabilmek bile bana büyüleyici gelmişti
    • Genel olarak sektörün tamamında kararlılık arttı, ama artık sayısız bağımlılık birbirine dolanmış durumda; tek bir yerde sorun çıksa bütün sistem sarsılıyor
    • Azure'a tamamen geçerken IPv6 erişimini yanlışlıkla unutmaları umuluyor

  • GitHub şu anda Azure geçişi, yapay zeka tabanlı altyapı değişiklikleri ve yapay zeka trafiğindeki patlama şeklinde üçlü bir baskı altında
    Popüler projelere, issue açıldıktan birkaç dakika sonra yapay zeka tarafından üretilmiş onlarca PR yağıyor
    Bu tür yükü kaldırmak zor; yapay zeka öncesinin “N 9s” seviyesiyle sonrasının “N 9s” seviyesi tamamen farklı zorluklar

    • Doğru. GitHub en başta bu tür bir yapay zeka ajanı seli varsayımıyla tasarlanmadı

  • GitHub'ın durum sayfasına bakınca fiili seviyenin %90,21, yani tek 9 düzeyi olduğu görülüyor
    Geçmişteki 2019 arşivinde ayda 1 ila 4 kesinti varken şimdi neredeyse günde bir tane var

    • Bu sayının kötü olmasının nedeni yalnızca kesinti değil, düşük performansı (degraded performance) da içermesi
    • Yine de şaka yollu olarak Claude'un status.claude.com sayfasından daha iyi olduğu söyleniyor

  • GitHub yapay zeka özelliklerine takılıp kalmışken, platformun güvenliği çöküyor
    Kısa süre önce Aqua Security saldırıya uğradı ve birçok repo enfekte oldu; bu olay GitHub Actions'taki mutable reference zafiyetinin istismar edilmesiyle gerçekleşti
    GitHub bu sorunu bildiği hâlde düzeltmedi

    • Geçici önlem olarak Actions sürümünü hash ile sabitlemek (pin) iyi olur
      Örneğin: uses: actions/checkout@11bd7190...
      Otomasyon aracı için mheap/pin-github-action bağlantısına bakılabilir
    • CI/CD'nin YAML tabanlı karmaşıklık yüzünden gereğinden fazla dolaştığını düşünüyorum
      Eskiden dağıtım Jenkins ile yapılır, basit testler script'lerle halledilirdi; şimdi ise tam bir dağınık YAML cehennemi oldu
    • GHA güvenliğinin “İsviçre peynirinden daha delik deşik” denecek kadar kötü olduğu söyleniyor
    • Bu sorunların yıllardır görmezden gelindiğini gösteren bir topluluk tartışması da var

  • %90 çalışma süresi tüm hizmetleri kapsayan bir sayı olduğu için fiili kullanıcı deneyimi farklı olabilir
    Ama Copilot'un %96,47 seviyesi bile yalnızca tek 9 demek
    GitHub “tüm özellikleri birlikte kullanın” diye teşvik ediyor, ama bunu yaptıkça güvenilirlik hızla düşüyor

    • Üstelik “yavaş ama çalışıyor” vakaları istatistiklere girmiyor
      Örneğin basit bir PR diff'ini açmak bile 30 saniyeden fazla sürebiliyor
    • Bazı kesintiler resmî olarak geç bildiriliyor
      CI/CD, git ve PR işlevlerinin tamamen durduğu örnekler de oldu
    • 2019 verileriyle karşılaştırınca durumun 10 kattan fazla kötüleştiği görülüyor
    • %96 gerçekten korkunç bir oran

  • GitHub Enterprise Server'ı bizzat işletmiş biri olarak bu sorunlar bana şaşırtıcı gelmiyor
    Active-active desteği yok, kesintisiz yükseltme mümkün değil, rollback yok; yani temel yüksek erişilebilirlik gereksinimlerini karşılamıyor
    Hata çıkarsa yedekten geri yükleme dışında çözüm yok ve bu süreçte veri kaybı yaşanıyor
    Böyle bir ürünün yüksek ücret ödeyen müşterilere satılması, erişilebilirliğe kayıtsızlığın kanıtı

    • Bizim şirket de sonunda GHES'ten vazgeçip GHEC'e migration yaptı

  • Microsoft'un iyi ürünleri bozma konusunda bir yeteneği var
    Skype bunun en bilinen örneği; Windows, Notepad ve Explorer için de aynısı söylenebilir
    Office → Office 365 → Microsoft 365 → Copilot 365 şeklindeki markalama karmaşası da ciddi boyutta

    • “GitHub for Business”ın çıkacağı gün de pek uzak görünmüyor

  • Bizim şirket her PR için GitHub Actions ile güvenlik taraması çalıştırıyor
    GitHub durunca güvenlik kapısı da duruyor ve geliştiriciler doğrulama olmadan merge yapıyor
    Böyle durumlarda zafiyetli kod içeri giriyor ama GitHub tüm insan gücünü Copilot'a ayırıyor

    • Buna dair kamuya açık örnekler olup olmadığını soranlar da vardı

  • IPv6'yı görmezden gelmek, GitHub'ın teknik özensizliğinin bir simgesi
    Daha büyük soru ise bu durumdayken nasıl hâlâ güvenlik denetimlerinden geçebildikleri
    GitHub'ın güvenlik belgelerine bakınca bunun büyük ölçüde göstermelik olduğu görülüyor

    • Denetim kalitesi de mimari seviyesi kadar kötü