GitHub birkaç saat erişilemez olduğunda yalnızca kod görüntüleme durmaz; giriş, API, pull request, Actions ve dağıtım zinciri aynı anda kilitlenebilir. 17 Ağustos 2026’daki büyük kesinti tam olarak bunu gösterdi. Bu rehber, Türkiye’de GitHub’a bağımlı çalışan küçük ekiplerin “servis geri gelsin” diye beklemek yerine bir sonraki kesintiye ölçülü bir dayanıklılık planıyla hazırlanmasını sağlar.

GitHub kesintisinde doğrulanan tablo

Doğrulanmış bilgi: GitHub’ın 20 Ağustos 2026 tarihli açıklamasına göre 17 Ağustos kesintisi 7 saat 47 dakika sürdü; github.com, kimlik doğrulama, GitHub Actions, API’ler, pull request’ler, Issues ve Copilot etkilendi. Şirket, olayın trafik yeni bir zirveye ulaştığında Central US veri merkezindeki kritik bir altyapı bileşeninin yeterince ölçeklenememesiyle başladığını belirtiyor. Kurtarma sırasında bazı Copilot istemcilerindeki yeniden deneme döngüsü trafiği artırdı.

GitHub ayrıca bunun Ağustos ayındaki ikinci önemli olay olduğunu, 6 Ağustos’ta Actions tarafında ayrı bir arıza yaşandığını söylüyor. Açıklamaya göre aylık commit sayısı nisan ayındaki 1,4 milyardan 2,9 milyara çıktı. Şirket kapasite, verimlilik ve mimari darboğazlar üzerinde çalıştığını; Azure’ın platform yükünün yaklaşık yüzde 58’ini ve Git işlemlerinin yarısını taşıdığını duyurdu.

Editoryal değerlendirme: Bu sayılar “GitHub güvensizdir” sonucunu çıkarmaz. Daha doğru ders, tek bir sağlayıcı ne kadar güçlü olursa olsun geliştirme ve dağıtım sürecinin tamamını tek erişim noktasına bağlamamaktır.

Kesinti neden sadece geliştiricinin sorunu değil?

Bir ajansın müşteri sitesine acil düzeltme göndermesi, e-ticaret ekibinin ödeme hatasını geri alması veya mobil uygulamanın yeni sürümünü hazırlaması GitHub üzerindeki birden fazla hizmete bağlı olabilir. Kod yerelde bulunsa bile paket deposu, CI sırrı, inceleme onayı ya da dağıtım iş akışı erişilemiyorsa iş durur. Özellikle küçük ekiplerde bu bağımlılıklar yazılı olmadığı için kesinti anında asıl zaman teknik arızadan çok “şimdi ne yapacağız?” tartışmasına gider.

Burada amaç GitHub’ı terk etmek değil. Ama kod imzalama zincirinde olduğu gibi, kritik sürecin hangi halkasının dış hizmete bağlı olduğunu açıkça görmek gerekir.

Üç katmanlı dayanıklılık planı

1. Kodun ikinci okunabilir kopyasını tutun

Git zaten dağıtık çalışır; her geliştiricinin güncel yerel kopyası temel bir güvence sağlar. Bunun üzerine salt okunur ikinci bir uzak depo eklenebilir. Her push’ı eşzamanlı olarak başka bir sağlayıcıya göndermek şart değildir; fakat ana dalların düzenli aynalanması, acil durumda kodu görmeyi ve temiz bir çalışma ortamı kurmayı kolaylaştırır.

  • Ana dalın en son ne zaman aynalandığını kaydedin.
  • Alt modül, LFS ve özel paket bağımlılıklarının aynada gerçekten bulunduğunu test edin.
  • Yedek depoya kimlerin erişebildiğini altı ayda bir gözden geçirin.

2. Derleme tarifini sağlayıcıdan ayırın

Yalnızca web arayüzündeki bir Actions işine güvenmek yerine derleme ve test komutlarını depodaki taşınabilir betiklerde tutun. Böylece aynı komut yerel makinede ya da geçici bir runner üzerinde çalışabilir. Üretim sırlarını geliştiricinin dizüstü bilgisayarına kopyalamak çözüm değildir; acil erişim için ayrı, süreli ve kayıt altına alınan bir yöntem tasarlayın.

3. Manuel dağıtımı kontrollü hale getirin

“CI yoksa FTP’den atalım” yaklaşımı hızlı görünür ama denetimsiz değişiklik üretir. Bunun yerine imzalı paket, iki kişiyle onay, geri alma dosyası ve işlem kaydı içeren dar bir acil dağıtım yolu tanımlayın. Kullanılmadığı zaman kapalı duran bu yol, yılda birkaç kez tatbik edilmelidir.

Yeniden deneme fırtınası nasıl önlenir?

GitHub’ın açıklamasındaki önemli ayrıntılardan biri, kurtarma sırasında istemci yeniden denemelerinin yükü artırmasıdır. Bir API çağrısı başarısız olduğunda her istemcinin aynı saniyede tekrar denemesi, iyileşmekte olan servise ikinci darbe vurur. Uygulamalar için üstel bekleme, rastgele gecikme, toplam deneme sınırı ve devre kesici kullanılmalıdır. İnsan tarafında da aynı ilke geçerlidir: ekip üyelerinin sürekli “yenile” yapması yerine tek kişi durum sayfasını izler ve belirlenmiş aralıklarla bilgi verir.

30 dakikalık kesinti tatbikatı

  1. GitHub’a erişimin tamamen kapalı olduğunu varsayın.
  2. Son kararlı sürümün kodunu ve kurulum belgesini başka bir kaynaktan açın.
  3. Testleri sağlayıcıya özel olmayan komutla çalıştırın.
  4. Üretime çıkmadan bir staging ortamına acil paket oluşturun.
  5. Geri alma adımını uygulayın ve süreyi kaydedin.
  6. Eksik sır, izin, belge ve kişi bağımlılıklarını listeleyin.

Tatbikat sonunda “dağıtım yaptık” kadar “kim karar verdi, hangi kayıt oluştu?” sorusuna da cevap verebilmelisiniz. Dayanıklılık yalnızca yedek kopya değil, güvenli karar akışıdır.

Türkiye’de hizmet veren ekipler ayrıca mesai dışı saatleri hesaba katmalı. Yurt dışındaki bir sağlayıcının açıklaması gelirken yerel müşteri desteği kapalı kalabilir. Nöbetçi kişi, Türkçe durum metni ve tahmini olmayan dürüst güncelleme şablonu önceden hazırlanırsa kesinti teknik ekibin omzunda iletişim krizine dönüşmez. “Sorun araştırılıyor, şu işlevler etkileniyor, bir sonraki bilgilendirme şu saatte” biçimindeki kısa mesaj çoğu zaman kesin olmayan bitiş tahmininden daha yararlıdır.

Kısa kontrol listesi

  • GitHub Status bağlantısı ekip iletişim kanalında sabit mi?
  • Ana dalın ikinci, salt okunur kopyası güncel mi?
  • Derleme komutu geliştirici bilgisayarında tekrarlanabiliyor mu?
  • Acil dağıtım için süreli yetki ve geri alma planı var mı?
  • API istemcilerinde yeniden deneme bütçesi bulunuyor mu?
  • Kesinti sırasında müşteriye kimin bilgi vereceği belli mi?

Kaynaklar