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

9 Şubat 2026 Pazartesi günü GitHub'da kimlik doğrulama ve kullanıcı yönetimini taşıyan veritabanı kümesi aşırı yüklendi; oturum açmaya bağlı bütün servisler etkilendi. Şirketin teknoloji direktörü Vlad Fedorov 11 Mart'ta yayımladığı açıklamada bu kesintiyi 2 Şubat ve 5 Mart'takilerle birlikte son haftaların en ağır üç olayı arasında saydı. github.com yanıt vermediğinde pull request açılmaz, Actions kuyruğu şişer, paket indirme takılır.²

Bu kesintilerin GitHub'a özgü bir yan etkisi var: şirket kendi kaynak kodunu da github.com üzerinde tutuyor. Mühendisler Lawrence Gripper ve Aleksey Levenstein 16 Nisan 2026'da bunu açıkça yazdı. GitHub'ı dağıtmak için GitHub gerekiyordu; site düşerse düzeltmeyi yayınlayacak araç da erişilemez oluyordu. Kodun bir aynası ve geri dönüş için hazır paketler bu en basit döngüyü kırıyor, ama dağıtım betiklerinin içine gizlenen döngüler daha zor yakalanıyor.¹

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.²

9 Şubat kesintisinin hazırlığı günler önce başlamış. Şubat başında çok kullanılan iki istemci uygulaması, istemeden yapılan bir değişiklikle sunuculara on kattan fazla okuma isteği göndermeye başlamış. 7 Şubat Cumartesi günü kullanıcı ayarlarını tutan önbelleğin yenilenme süresi 12 saatten 2 saate indirilmiş. Pazartesi sabahı hafta başı zirvesi, uygulamayı güncelleyen kullanıcılar ve yeni bir model sürümü üst üste binince küme dayanamamış. 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ş; raporun altını çizdiği nokta ise 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.

Mart açıklamasındaki takvim bu işlerin ne kadar sürdüğünü de gösteriyor. 11 Mart'ta GitHub trafiğinin yüzde 12,5'i Azure'un Central US bölgesinden sunuluyordu; şirket bu oranı Temmuz'a kadar yüzde 50'ye çıkarmayı hedefledi.² Döngüsel bağımlılık denetimi ise altı aylık kademeli yayını tamamlamış, 16 Nisan 2026'da duyurulduğunda canlıdaydı.¹

kafa1milyon

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