GitHub Yaşadığı Kesintilerle Nasıl Başa Çıkıyor?

github.com birkaç saat yanıt vermezse yazılım dünyasının yarısı durur. Pull request açamazsın, Actions kuyruğu şişer, paket indirme takılır. Asıl tuhaflık başka yerde: GitHub kendi kaynak kodunu da github.com üzerinde tutuyor. Yani site düştüğünde, düzeltmeyi yayınlamak için ihtiyaç duydukları araç da aynı çatı altında kalabiliyor.¹

Bu paradoks yalnızca bir şirket hikâyesi değil. Büyük dağıtık sistemlerin klasik sınavı: bozulunca kendini nasıl onarırsın, onarım aracı bozulan parçaya yaslanmadan kalır mı? GitHub'ın son yıllardaki yanıtı, bu soruyu mühendislik ve şeffaflık olarak iki koldan ele almak.

Döngüsel bağımlılık tuzağı

GitHub mühendisleri bunu net yazıyor: siteyi kurtarmak için yine siteye ihtiyaç duymak. Buna döngüsel bağımlılık deniyor. Doğrudan hali basit. Deploy skripti bir aracı github.com'dan indirmeye çalışır; site zaten düşmüşse skript tamamlanamaz. Gizli hali daha sinsidir. Diskte duran bir araç çalışırken güncelleme kontrolü için GitHub'a bakar; cevap gelmezse asılı kalır. Geçici hali ise bir iç servisin başka bir servisi çağırıp o servisin yine GitHub'a gitmesidir. Zincir kırılır, kurtarma gecikir.

Bu yüzden ayna kopya ve geri alma paketleri yetmez. Kurtarma yolunun kendisinin, kurtardığı sistemden bağımsız kalması gerekir. Dağıtık sistemlerde klasik bir kuraldır bu: onarım aracı, bozulan parçaya yaslanmamalı. Aksi halde olayın süresi, kök neden kadar "düzeltmeyi nasıl ulaştıracağız" sorusunda uzar.

eBPF ile kurtarma yolunu açık tutmak

Nisan 2026'da yayımlanan mühendislik yazısında GitHub, yeni host tabanlı dağıtım sisteminde eBPF kullandığını anlatıyor. eBPF, Linux çekirdeğine küçük programlar yüklemeni sağlar. GitHub'ın yaptığı şu: yalnızca deploy skriptini bir cgroup içine koyuyor, o sürecin dışarı çıkan ağ trafiğini seçici biçimde denetliyor.¹

DNS sorguları bir vekile yönlendiriliyor. Vekil, engelli listesindeki alan adlarını eBPF haritalarıyla iletişim kurarak kesiyor. Engellenen çağrı hangi komuttan geldiyse ekibe log olarak düşüyor. Amaç, canlı müşteri trafiğini bozmadan "deploy sırasında github.com'a yaslanma" riskini önceden yakalamak. Tüm makinede github.com'u kapatmak işe yaramazdı; çünkü aynı makineler hâlâ müşteri isteklerini karşılıyor. Çözüm, yasağı yalnızca dağıtım sürecine uygulamak oldu.

Altı aylık bir yayından sonra sistem canlıya alınmış. Yanlışlıkla eklenen bir bağımlılık, olay anında değil, dağıtım sırasında görünür oluyor. Bu, kaos mühendisliğinin gösterişli tarafı değil. Daha sakin bir iş: kurtarma yolunu, kesinti olmadan test edilebilir kılmak.

Patlama yarıçapı ve yük atma

Mart 2026'daki şirket yazısı, yakın dönemdeki büyük kesintileri üç başlıkta topluyor: hızlı kullanım artışı, yerel bir sorunun kritik servislere yayılmasına izin veren mimari bağlantı, ve kötü davranan istemciden yükü yeterince atamamak.²

Şubat 2026'da kimlik ve kullanıcı yönetimi veritabanı kümesi aşırı yüklenmiş. Önde gelen istemci uygulamalarındaki istemeden gelen API artışı, önbellek yenileme süresinin kısaltılması ve hafta başı zirve yükü aynı güne binmiş. Veritabanı kimlik doğrulamayı da taşıdığı için etki genişlemiş. Actions tarafında ise yedekleme çözümünün beklenen gibi çalışmadığı veya gizli bir yapılandırma hatasının yedekleme sonrası yazılabilir birincil bırakmadığı olaylar anlatılmış.

Ortak dil şu: patlama yarıçapını küçült. Git ve Actions gibi kritik yolları paylaşılan altyapı sorunlarından ayır. Spikelerde aşağı akış bileşenlerini koru, kritik trafiğe öncelik ver. Azure'a taşınma ve monolit parçalama da aynı hedefin uzun vadeli yüzü: bağımsız ölçek, yerel yük atma, daha dar etki alanı. Şirket, kısa vadede kullanıcı önbelleğini yeniden tasarlamak ve kritik veri-hesap altyapısını denetlemek gibi acil işleri de aynı pakette sayıyor.

Açık defter: status ve aylık rapor

GitHub her büyük bozulmayı status sayfasında özetliyor. Aylık availability raporlarında ise zaman çizelgesi, kök neden ve sonraki mühendislik adımları yazılıyor. Bu raporlar pazarlama metni gibi okunmuyor; hangi alarm eşiğinin kaçırıldığı, hangi dağıtımın geri alındığı, hangi üçüncü tarafın pazarlama sayfalarını düşürdüğü tek tek geçiyor.³

Örneğin Aralık 2024 raporunda planlı bakımın canlı güncelleme servisini bozduğu, istemcilerin sayfayı agresif yenilemesiyle sunucuların daha da zorlandığı anlatılıyor. Çözüm geri alma ve ölçekleme olmuş; ama asıl ders, alarmların sunucu aşırı yükündeyken yanlış kapsam göstermesi. Yani şeffaflık yalnızca "özür" değil; bir sonraki alarm eşiğinin nereden ayarlanacağını da yazıyor.

Şeffaflık kesintiyi silmiyor. Ama aynı sınıf hatanın ikinci kez aynı kör noktadan gelme ihtimalini düşürüyor. Çünkü ekip, dışarıya yazdığı taahhüdü içeride de takip etmek zorunda kalıyor.

GitHub'ın kesintiyle başa çıkma biçimi, tek bir sihirli düğme değil. Döngüyü kırmak, etki alanını daraltmak, yükü bilinçli atmak ve bunu her ay kamuya yazmak. Büyük sistemlerin bilimi çoğu zaman bu dört işin sıkıcı tekrarıdır. Site bir daha düştüğünde asıl soru "neden düştü" kadar "kurtarma yolu açık mıydı" sorusudur.

kafa1milyon

Meraklı bir kafa. Bilimsel makaleleri, arşiv belgelerini ve saha notlarını okuyup gündelik dile çeviriyor; bilinmeyeni bilinmiyor diye yazmaktan çekinmiyor.