GitHub’un Mart 2026 Dersi: Dayanıklılık Kağıt Üstünde Değil

⏱️ 7 dk okuma📅 9 Nisan 2026👁️ 1 görüntülenme

Mart ayı kapandı ve aklımda net kalan bir şey var (eh, fena değil). Büyük platformlarda mesele salt (söylemesi ayıp) “çalışıyor mu?” değil — “bir şey ters giderse ne kadar hızlı toparlıyor?” sorusu. GitHub’ın Mart 2026 availability raporu da tam bunu yüzümüze vuruyor. İki ayrı olay, farklı kök nedenler… ama hissiyat aynı: geliştiricinin akışı bir anda sekteye uğrayınca zincirleme etki baya sert oluyor.

Açık konuşayım. Bu tip raporları okurken ben teknik kısmın çok ötesine bakıyorum, çünkü 20+ yıllık sistem. Bulut işinde şunu defalarca gördüm: cache, load balancer ya da Redis gibi parçalar tek başına “ufak detay” gibi görünür — ta ki üretimde patlayıncaya kadar. 2021’de bir finans müşterisinde benzer bir gecikme yaşamıştık; tek bir ara katman yanlış davranınca sadece API’ler değil, ekibin moralini de etkileyen bir domino başlamıştı. Ciddi bir domino.

Evet, doğru duydunuz.

İşin aslı şu. GitHub gibi devasa bir platformda küçük görünen bir ayar bile kullanıcıya büyük kriz olarak döner; hele Actions, API, Copilot ve git operasyonları aynı anda etkileniyorsa — orada artık “sadece performans düştü” demek biraz hafif kalıyor, hani gerçekten hafif.

Martta Ne Oldu? Kısa Cevap: Bir Değil İki Ayrı Sarsıntı

Raporun omurgası iki önemli olaydan oluşuyor. İlki 3 Mart’ta yaşanan. Github.com ile API’den Copilot’a kadar geniş bir alanı etkileyen degradasyon; ikincisi işe 5 Mart’taki GitHub Actions olayı. Yanı tek servis değil, ekosistemin farklı noktaları ayrı ayrı tökezlemiş.

Bak şimdi, Burada özellikle şuna dikkat çekmek istiyorum. Kullanıcı tarafında sonuç aynı görünse de operasyonel tarafta sebep bambaşka olabiliyor. Birinde cache yazma yükü kontrolden çıkıyor, diğerinde Redis altyapısına yapılan değişiklik yanlış yapılandırmala prod’a sızıyor. Semptom benzer — gecikme, hata, kuyruk — ama teşhis apayrı.

Bir müşteride 2024 Nisan’ında Azure üzerinde yaptığımız gözlemde de benzer bir şey görmüştük; uygulama takımı “API yavaş” diyordu, altyapı takımı “hayır network iyi” diyordu, sonra loglara gömülünce asıl problemin arka plandaki dağıtılmış cache invalidation olduğu ortaya çıktı. Hani bazen suçlu en görünmez yerde olur ya — aynen öyle.

Büyük platformlarda sorun çoğu zaman tek noktada başlamaz; küçük bir değişiklik, yeterince büyük ölçek varsa neredeyse tüm sistemi yankıyla vurur.

3 Mart Olayı: Cache Patladıysa Her Şey Sarsılır

İlk olayda ana hikâye user settings caching mekanizması etrafında dönüyor. Yazılan veri miktarı artmış, ekip bunu azaltmak için değişiklik yaparken ufak ama hayatı bir bug çıkmış: her kullanıcının cache’i expire olmuş, yeniden hesaplanmış ve tekrar yazılmış. Bu da yükü büyütmüş, replikasyon gecikmeleri zincirleme şekilde servisleri etkilemiş. Klasik ama acı.

Bence burada en öğretici kısım şu. Cache’i hızlandırmak için attığın adım bazen tam tersi sonuç veriyor. Kulağa absürt geliyor ama gerçek hayat böyle işte — ben de ilk birkaç kez gördüğümde inanamadım açıkçası. Geçen yıl Logosoft’ta bir e-ticaret müşterisinde buna yakın bir durum yaşadık; profil verilerini hızlandırmak için yapılan optimizasyon yanlış TTL politikasıyla birleşince database tarafında anı bir dalga oluştu.

Kısa bir not düşeyim buraya.

GitHub’ın yaptığı rollback doğru refleks olmuş. Zaten üretimde bazen kahramanlık değil, hızlı geri dönüş kurtarır (evet, doğru duydunuz). AZ-104 ve AZ-305 çalışırken de hep şunu söylerim: mimariyi iyi kurmak kadar geri alma planını da iyi kurmak lazım — yoksa güzel tasarım kağıtta kalır, sadece kağıtta.

💡 Bilgi: Cache hatalarında asıl tehlike çoğu zaman “tek seferlik hata” değil; hatalı davranışın tüm kullanıcı kitlesine yayılmasıdır. Bu yüzden killswitch ve ayrıştırılmış host yaklaşımı bayağı işe yarar.

Neden bu kadar yayıldı?

Çünkü cache katmanı yalnızca kendisi için yaşamıyordu. Başka servislerin de bağımlısıydı. Replikasyon gecikmesi başlayınca sorun servis sınırlarını aşıyor ve git işlemlerinden Copilot’a kadar uzanıyor — bulutta sık gördüğümüz klasik hikâye bu zaten: bağımlılıklar görünmezken sakın, görünürken işe gürültülü oluyorlar.

İşte tam da bu noktada devreye giriyor.

Tabii burada monitöring eksikliği değil belki ama yeterince erken uyarı olmaması can yakmış gibi dürüyor. GitHub’ın sonradan killswitch eklemesi. Izlemeyi güçlendirmesi doğru adım; keşke o adımlar önce gelmiş olsaydı dedirti insana, hep öyle. Bu konuyla ilgili GitHub Copilot’un PR Etkisi Ölçülüyor: Yeni Metrikler yazımıza da göz atmanızı tavsiye ederim.

5 Mart Olayı: Actions Kuyruğa Takıldı

İkinci olay daha spesifik. Ama etkisi az değil. GitHub Actions tarafında workflow run’ların yüzde 95’i beş dakika içinde başlayamamış, ortalama gecikme 30 dakikaya çıkmış ve yüzde 10’u altyapı hatası almış. Bir CI/CD hattında bu rakamlar kulağa hiç hoş gelmiyor — hatta baya moral bozucu, gerçekten. Daha fazla bilgi için AG-UI ile Çoklu Ajan Arayüzü: Gerçek Zamanlı Demo yazımıza bakabilirsiniz. Bu konuyla ilgili GitHub Copilot for Eclipse Açık Kaynağa Dönüyor: Neden Önemli? yazımıza da göz atmanızı tavsiye ederim.

Garip gelecek ama, Kök neden Redis altyapısı güncellemeleri sırasında yapılan yanlış yapılandırmalar olmuş; load balancer iç trafiği yanlış host’a yönlendirmiş ve iki ayrı incident tetiklenmiş. Burada beni düşündüren — ki bu tartışılır — şu oldu: otomasyon iyileştirmek isterken yapılandırma güvenliği zayıf kalırsa sonuç tam tersine dönebiliyor. İşte tam da bu yüzden config değişikliklerine kod deploy etmekten daha mı temkinli yaklaşmak lazım diyorum bazen (en azından benim deneyimim böyle)

Şunu söyleyeyim, 2023’te İstanbul’da bir kurumda benzer biçimde load balancer seviyesinde rota kayması yaşamıştık; uygulamalar çalışıyordu ama trafik yanlış node’a gidiyordu diye herkes birbirine bakıyordu — hani klasik. O gün öğrendiğim ders hâlâ geçerli: prod’da config değişimi, kod deploy etmekten bile daha hassas olabiliyor.

Konu	Etkisi	Ders
User settings cache	Tüm yüzeye yayılan degradasyon	Cache izolasyonu şart
Redis LB config	Actions job gecikmeleri ve hata oranı	Yanlış config’in prod’a sızması engellenmeli
Kuyruk boşaltma süreci	Sorun düzelse bile etki devam etti	Tam iyileşme ile hizmet toparlanması farklı şeylerdir

Bence Asıl Mesaj Teknik Değil Operasyonel

Bak şimdi, Lafı gevelemeden söyleyeyim. Bu rapor bana dayanıklılığın sadece mimarı diyagram olmadığını yeniden hatırlattı. Dayanıklılık; monitöring, rollback disiplini, change freeze zamanı, config kontrolü ve ekip koordinasyonu birlikte çalışınca ortaya çıkıyor — bunlardan biri eksikse zincir o noktadan kopuyor.

Küçük startup ile enterprise arasındaki fark da tam burada netleşiyor. Startup tarafında hızlı hareket etmek avantaj, ama aynı hızla hata da yayılıyor çünkü genelde fazla koruma katmanı yok. Enterprise tarafında süreç var, ama süreç ağırsa müdahale yavaşlıyor. Yanı iki uçta da bedel (belki yanılıyorum ama) ödüyorsun — biri hızdan, diğeri hantallıktan. Maalesef. github ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.

Küçük ekiplerde en kilit konu basitliktir.
Büyük yapılarda en kritik konu izolasyondur.
Tüm yapılarda ortak ihtiyaç işe gözlemlenebilirliktir.
Koddan çok config yönetimi çoğu zaman kaderi belirler.

Maliyet mi dayanıklılık mı?

FinOps açısından bakınca bazı önlemler ilk etapta pahalı görünür — mesela dedicated host’a taşıma ya da ekstra monitöring katmanı ekleme maliyet yaratır gibi gelir. Hmm, ama incident maliyetiyle kıyaslayınca tablo hemen değişiyor. Geçen ay Ankara’daki bir müşteri toplantısında bunu uzun uzun konuştuk; küçük tasarrufların bazen büyük kesinti faturası doğurduğunu anlatmak artık zor olmuyor, insanlar bizzat yaşamış çoğu zaman.

Neyi iyi yaptılar?

Araya gireyim: Rollback kararının hızlı verilmiş olması değerliydi bence. Bir de açık iletişim kurmaları önemliydi — çünkü geliştirici topluluğu belirsizliği hiç sevmez, gerçekten hiç. Şeffaflık yoksa güven kaybı başlıyor; o kısım çok daha yavaş onarılıyor maalesef.

Peki Biz Buradan Ne Çıkarmalıyız?

Eğer kendi ortamınızda Azure DevOps pipeline’ları, GitHub Actions ya da herhangi bir CI/CD hattı işletiyorsanız şu soruyu kendinize sorun: “Bir config hatası prod’a ulaşmadan önce nerede dürüyor?” Basit görünüyor. Ama cevap zayıfsa problem de büyüktür — bu kadar net.

Ben AZ-500 hazırlığında özellikle saldırgan senaryolar kadar operasyonel riskleri de düşünmeye alıştım. Güvenlik sadece dış tehdit değil; yanlış yetkilendirme, aşırı izinli otomasyon veya denetlenmeyen değişiklik akışı da ciddi risk yaratıyor. Bu ne anlama geliyor? İşin içine AI araçları girince bu daha da hassaslaşıyor — Copilot’un değeri yüksek, ama arkasındaki platform sağlam olmazsa faydası da sınırlı kalıyor (evet, doğru duydunuz)

# Basit kontrol listesi
1) Config change review var mı?
2) Rollback süresi ölçülüyor mu?
3) Monitoring alarm'ları gerçekten işe yarıyor mu?
4) Kritik bağımlılıklar izole mi?
5) Incident sonrası aksiyonlar kapatılıyor mu?

Sahada işe yarayan birkaç pratik öneri

– Kritik cache mekanizmalarını mümkünse ayrı host ya da ayrı kümede tutun.
– Load balancer değişikliklerini otomatik test olmadan prod’a bırakmayın — bırakmayın gerçekten.
– Gözlemleme eşikleri yalnızca alarm vermesin; kullanıcı etkisini önceden sezsin.
– Freeze dönemleri kötü değildir… doğru zamanda kullanılırsa hayat kurtarır.
– En önemlisi postmortem’i dosyada bırakmayın, gerçekten takip edin — o dosya kapanmadan bir sonraki incident gelmesin.

Sıkça Sorulan Sorular

GitHub March 2026 availability report ne anlatıyor?

Mart ayında yaşanan iki ana incident üzerinden GitHub servislerinde görülen performans düşüşlerini anlatıyor. En çok da cache mekanizması ve Redis altyapısı kaynaklı sorunlar öne çıkıyor.

Bu tür incident’lerde en büyük risk ne?

Şunu söyleyeyim, En büyük risk zincirleme etkidir.Teknik olarak küçük görünen bir problem API’den CI/CD’ye kadar birçok servisi etkileyebilir.Kullanıcı tarafında işe iş akışı direkt durur.

GitHub Actions neden bu kadar etkilendi?

Doğrusu, Yanlış Redis load balancer konfigürasyonu iç trafiği hatalı host’a yönlendirdiği için workflow başlangıçlarında ciddi gecikmeler oldu.Kuyruk dolunca etki daha da uzadı.

Kurumlar bu rapordan ne öğrenmeli?

Doğrusu, Kritik yapı taşlarını izole etmek, change management disiplinini sıkı tutmak. Rollback planını hazır bulundurmak gerekiyor. Hele bir de CI/CD sistemlerinde config doğrulaması çok önemli.