17 Ağustos GitHub kesintisinde neler yaşandı?

Şirket daha sonra soruna neden olan bileşeni belirlediğini ve düzeltici adımlar attığını bildirdi. ABD Doğu Yakası saatiyle 12.36’da yayımlanan güncellemede platformun belirgin biçimde toparlandığı, ancak hizmetlerin henüz tamamen istikrara kavuşmadığı belirtildi.

Toparlanma tüm hizmetlerde aynı anda gerçekleşmedi. GitHub’ın durum sayfasında temel hizmetlerin yeniden çalışır hâle geldiği görülürken Copilot’ın bazı uygulamalarında kimlik doğrulama sorunları devam etti. Diğer olay kayıtları, genel kesintinin yaklaşık 21.15 UTC’de sona erdiğini gösteriyor. Bu da olayın en ağır performans düşüşünün yaşandığı ilk aşamadan çok daha uzun sürdüğüne işaret ediyor.

Kesinti ne kadar büyüktü?

GitHub’ın paylaştığı hata oranları etkinin boyutunu en net biçimde ortaya koyuyor:

• Web deneyimleri ve API trafiği: Yaklaşık yüzde 20 hata.
• Arşiv indirmeleri ve ham depo içeriği: Yaklaşık yüzde 50 hata.
• Geliştirici hizmetleri: Pull Requests, Issues, Actions, Webhooks, Git işlemleri ve Pages farklı zamanlarda yavaşladı veya kullanılamaz hâle geldi.
• Yapay zekâ destekli kodlama: GitHub Copilot etkilendi ve bazı temel hizmetler düzeldikten sonra da sorun yaşanmaya devam etti.
• Kurumsal kimlik yönetimi: SAML ve OIDC kimlik doğrulaması, SCIM kullanıcı provizyonu ve Team Sync özelliklerinde kesintiler bildirildi. Bu durum bazı kuruluşların kullanıcı girişlerini ve erişim yönetimini güvenilir biçimde yürütmesini engellemiş olabilir.

Bu oranlar, tüm GitHub kullanıcılarının ne kadarının erişimini kaybettiğini göstermez. Örneğin API’deki yüzde 20’lik hata oranı, müşterilerin tam olarak yüzde 20’sinin çevrim dışı kaldığı anlamına gelmez. Yüzde 50’lik oran da tüm depo trafiğini değil, etkilenen indirme isteklerini ifade eder.

Pazartesi sabahı zamanlaması neden önemliydi?

Olay, ABD’de pazartesi sabahı başladı; yani birçok mühendislik ekibi için çalışma haftasının ilk iş döngüsüne denk geldi. Kaynak koduna erişim, kod incelemeleri, sürekli entegrasyon ve teslim (CI/CD) süreçleri ile dağıtım otomasyonları çoğu ekipte günün ilk saatlerinde çalıştırılıyor. Actions, Pull Requests, API’ler ve Webhooks’un aynı olayda etkilenmesi, ekiplerin tek bir özelliğin değil, birbirine bağlı birden fazla adımın başarısız olduğunu görmesine yol açtı.

Kesinti takip servislerindeki toplamlar da zamana ve kullanılan ölçüm yöntemine göre değişti. Bir haberde Pasifik saatiyle 08.12’ye kadar 10 binden fazla Downdetector bildirimi kaydedildiği belirtilirken, başka bir toparlanma haberinde zirvenin yaklaşık 3 bin bildirim olduğu aktarıldı. Bu rakamlar etkilenen kullanıcıların kesin sayısı olarak değerlendirilmemeli. Bu platformlar kullanıcıların gönderdiği bildirimleri ölçer; toplamlar bölgeye, zamana ve raporlama yöntemine göre değişebilir.

GitHub ne yaptı, neyi açıklamadı?

GitHub’ın kamuya açık güncellemeleri, müdahalenin üç temel aşamasını ortaya koyuyor:

1. Mühendisler, birden fazla hizmetteki yükselen performans sorunlarını araştırdı.
2. Şirket, soruna dahil olan bir bileşeni tespit ederek düzeltici işlem uyguladı.
3. Ana platform hizmetleri toparlanmaya başladıktan sonra da aralıklı Copilot kimlik doğrulama hataları için önlemler uygulanmaya devam etti.

Bununla birlikte mevcut kanıtlar, hangi bileşenin arızalandığını, uygulanan düzeltmenin teknik ayrıntılarını veya kapasite baskısının bu özel olayın nedeni olduğunu göstermiyor. Yapay zekâ kaynaklı trafik artışı ve altyapı kısıtları GitHub’ın genel güvenilirlik tartışmasının bir parçası olsa da, şirketin olay sonrası incelemesi yayımlanmadan bunlar 17 Ağustos kesintisinin doğrulanmış kök nedeni olarak sunulmamalı.

Olay, GitHub’ın 2026’daki güvenilirlik sorunlarının neresinde duruyor?

Ağustos kesintisi, zorlu bir güvenilirlik döneminin ardından geldi. GitHub’ın temmuz ayı kullanılabilirlik raporunda ay boyunca sekiz olay kaydedildi. Bunlardan 8 Temmuz’da yaşanan ve yedi saatten uzun süren olayda Web arayüzü, REST API, GraphQL API, Actions, Packages, Copilot ve bazı Enterprise Cloud ortamlarındaki Git işlemleri etkilenmişti.

GitHub daha geniş bir altyapı sorununu da kabul etti. Şirketin kullanılabilirlik açıklamalarına göre trafik hızla artıyor ve bu artışın önemli bir bölümünü yapay zekâ destekli ve otonom yazılım geliştirme iş akışları oluşturuyor. GitHub’ın açıkladığı önlemler arasında daha fazla kapasiteyi Azure’a taşımak, hizmetleri birbirinden yalıtmak ve ortak arıza noktalarını azaltmak bulunuyor.

Planlanan ölçeğin büyüklüğü dikkat çekici. GitHub’ın altyapı planlarına ilişkin haberlerde, şirketin başlangıçta kapasiteyi 10 kat artırmayı hedeflediği; ancak 2026’nın başlarında mevcut ölçeğinin 30 katı için tasarım yapması gerektiği sonucuna vardığı aktarıldı. Başka haberlerde Azure’a ek olarak AWS dâhil çoklu bulut kapasitesi üzerinde çalışıldığı belirtildi. Ancak bu planlar tek başına 17 Ağustos’taki olayın nedenini açıklamıyor.

Bu bağlam, kesintiyi tek bir kötü sabahın ötesine taşıyor. GitHub artık yalnızca Git depolarının saklandığı bir yer değil; aynı zamanda iş birliği katmanı, otomasyon platformu, kimlik sistemi ve yapay zekâ destekli kodlama hizmeti. Ortak bağımlılıklardan biri başarısız olduğunda tek bir olay; depo erişimini, kod incelemelerini, derlemeleri, dağıtımları, Webhook’ları ve kodlama desteğini aynı anda aksatabiliyor.

Kuruluşlar bu olaydan ne çıkarmalı?

Bu kesinti, geliştiricilerin GitHub’ı terk etmek üzere olduğunu kanıtlamıyor. Mevcut kanıtlar yakın zamanda büyük bir platform göçü yaşanacağını söylemek için de yeterli değil. Ancak GitHub’a üretim süreçleri için bağımlı kuruluşların arıza senaryolarını yeniden gözden geçirmesi gerektiğini gösteriyor.

Pratik önlemler arasında depoların yedeklerini veya aynalarını tutmak, CI/CD yapılandırmalarını taşınabilir hâle getirmek, acil sürüm yayımlama prosedürlerini belgelemek ve SSO, Webhooks veya barındırılan runner’lar kullanılamadığında ekiplerin nasıl çalışacağını önceden belirlemek bulunuyor. Bu adımlar platform riskini ortadan kaldırmaz; ancak bir sonraki hizmet kesintisinin etki alanını daraltabilir.

17 Ağustos olayına ilişkin nihai değerlendirme, GitHub’ın yayımlayacağı olay sonrası rapora bağlı olacak. Bu rapor gelene kadar savunulabilir sonuç şu: GitHub, depo indirmeleri ve birbirine bağlı geliştirici iş akışlarında ağır etkiler yaratan geniş kapsamlı, zincirleme bir hizmet kesintisi yaşadı; hizmetler aşamalı olarak düzeldi ve şirket altta yatan arızayı henüz kamuoyuna ayrıntılı biçimde açıklamadı.