GitHub'daki Kesinti, Yapay Zeka Tabanlı Trafiğin Artışı ve Yapılandırma Hatası Nedeniyle

9 Şubat'ta, Pekin zamanıyla gece yarısı, milyonlarca geliştirici GitHub'a aynı sayfayı gördü.

404 değil, mühendislerin sırtını ürperten sarı uyarı çubuğu ve durum sayfasındaki yeşilden kırmızıya dönen ışıklar.

github.com erişilemiyor.

API çalışmıyor.

GitHub Actions çalışmıyor.

Git işlemi başarısız oldu—Copilot bile kurtulamadı.

O gece, bazılarının CI/CD akışları en kritik noktada durdu, bazılarının otomatik dağıtım sistemleri yarı yolda takıldı, bazıları ise uzun süredir birleştirilemeyen bir PR'nin beklenmesiyle karşı karşıya kaldı—arkasında gerçek kullanıcılar için bekleyen bir özellik vardı.

Sonrasında GitHub olay raporunu yayınladı. Teknik dilde temel neden, "kimlik doğrulama ve kullanıcı yönetimiyle sorumlu olan temel veritabanı kümesinin aşırı yüklenmesiydi". Ancak bu birkaç kelimenin ardında korkutucu bir tetikleme zinciri gizliydi—

İki gün önce, mühendis ekibi, kullanıcılar için yeni bir modeli en kısa sürede yayınlamak amacıyla bir “kullanıcı ayar önbelleği” güncelleme süresini 12 saatten 2 saate değiştirdi. Sadece bu yapılandırma sayısının değişimi.

Sonuç olarak, 12 saat boyunca dağıtılmış olan önbellek yeniden yazma işlemi, 2 saat içinde sıkıştırıldı ve yoğun bir “önbellek yeniden yazma fırtınası” oluştu; asenkron görev kuyruğu anında aşırı yüklendi, paylaşılan altyapı bileşenleri çöktü, zincirleme etki HTTPS Git işlemlerini yöneten hizmete yayıldı ve nihayetinde tüm platformun bağlantıları tükendi.

12'den 2'ye değiştirilen bir sayı.

GitHub, kendi değiştirdiğiniz bir yapılandırma nedeniyle çöktü.

Ancak sadece bu yapılandırma değişikliğini görüyorsanız, muhtemelen hikayenin en önemli kısmını kaçırdınız.

9 Şubat'taki olay, izole bir olay değildir.

Aslında, 2026 yılının ilk üç ayında GitHub en az sekiz büyük arıza yaşadı. Şubat ayı tek başına 37 adet küçük ve büyük arıza kaydı içeriyordu. GitHub CTO'su Vlad Fedorov, daha sonra blogunda bu iki ayda GitHub'ın kurumsal müşterilere söz verdiği %99,9 kullanılabilirliği sağlayamadığını kabul etti.

Bu iki ayın arıza dosyalarını incelediğinizde, her bir kaza gibi görünen olayın farklı nedenlere sahip olduğunu fark edersiniz.

2 Şubat'ta: Azure hesaplama sağlayıcısında sorun yaşandı, GitHub Actions yaklaşık 4 saat boyunca durdu, Copilot kodlama ajanı, CodeQL ve Dependabot da etkilendi.

9 Şubat: Önbellek yazma fırtınası, doğrulama veritabanı aşırı yükleniyor.

5 Mart: Redis kümesi arızası, GitHub Actions’ın %95’i 5 dakika içinde başlatılamadı, ortalama gecikme 30 dakika.

18 Mart: Webhook gecikmesi, normal seviyenin 32 katına çıktı.

Her biri "rastgele" gibi görünüyor, her birinin doğrudan nedeni farklı. Ancak Fedorov'un açıklaması bunları aynı hikâyeye bağlıyor. O, bu kazaların arkasında üç ortak yapısal neden olduğunu söylüyor: "hızlı yük artışı, hizmetler arasındaki sıkı bağımlılık nedeniyle yerel arızaların yayılması ve sistemin anormal istemci trafiği için koruma yeteneğinin eksikliği."

Mühendislerin ifadesiyle, GitHub'ın temeli, yeni yükün altında çatlaklar başlamıştır.

Bu "yeni yükün" ise özel bir adı vardır.

Kritik Veriler

2025 yılı boyunca toplam taahhüt miktarı: yaklaşık 1 milyar

2026 yılında tek haftalık commit sayısı: 275 milyon

Bu hızla 2026 yılının tamamında tahmini: 14 milyar (yıllık bazda 14 kat artış)

GitHub Actions hesaplama miktarı: 2023'te haftada 5 milyar dakika → 2025'te 10 milyar → 2026 başlarında bir haftada 21 milyar dakika

Eğer GitHub'ın altyapı mühendisiyseniz, 2025 ve 2026 yılları için izleme panolarının karşılaştırması sizi şaşkına çevirecektir.

2025 yılında GitHub, yaklaşık 1 milyar kod gönderimi işlemi gerçekleştirdi. Bu rakam kendisi büyük bir sayıdır ve GitHub platformunun yıllarca birikiminden kaynaklanmaktadır. Ancak 2026 yılında, tek bir haftada 275 milyon gönderim yapıldı. Bunu yıllık bir temele dönüştürürsek—bu hızla ilerlerse—2026 yılındaki toplam gönderim sayısı yaklaşık 14 milyar olacak ve 2025 yılının toplamına göre tam olarak 14 katı olacaktır.

Bu, düzgün bir artış eğrisi değil, dik bir yamaçtır. GitHub’ın Actions hesaplama yükündeki değişim bu durumu daha iyi gösterir: 2023 yılında haftalık 5 milyar dakika tüketilirken, 2025 yılında bu rakam 10 milyara katlanır ve ardından 2026 yılının başlarında bir haftada doğrudan 21 milyar dakikaya çıkar.

Ne kod gönderiminde çılgınca davranıyor?

İnsan geliştirici değil.

GitHub verileri, AI Agent'ların bu platformda en aktif "kullanıcı" haline geldiğini gösteriyor. Claude Code tek bir araç olarak, GitHub'daki tüm açık depo gönderimlerinin %4,5'ini oluşturuyor. Haftada 2,6 milyon gönderim; 2025 yılının Eylül sonunda bu sayı yalnızca 100.000 idi — üç ay içinde 25 kat artış sağlandı.

AI Agent tarafından açılan PR sayısı aynı şekilde patlıyor. Eylül 2025'te AI tarafından üretilen PR sayısı aylık yaklaşık 4 milyon iken, Mart 2026'da bu rakam 17 milyona yükseldi—yani altı ay içinde dört katından fazla.

Bunu ne anlama geldiğini anlamak için bir ekran var.

Daha önce, GitHub'ın "kullanıcıları" çoğunlukla insan programcılarydı. Gün içinde çalışırlar, gece uyurlar, hafta sonları dinlenirler, her gönderimde düşünürler, tereddüt ederler ve el hızları sınırlıdır. Sistem yükü insanların günlük düzenine göre hareket eder, zirve ve dip noktaları vardır ve öngörülebilir.

Şu anda, giderek daha fazla "kullanıcı" AI Agent'ıdır. Bunlar uyumaz, dinlenmez, tereddüt etmez; bir görev için aynı anda birden fazla paralel Agent başlatılabilir ve her Agent saatteki gönderim miktarı, bir gerçek mühendisin bir haftalık iş yükünü kolayca aşar. Daha da önemlisi, bunlar sadece kod göndermiyor; aynı zamanda sürekli yeni depolar oluşturuyorlar—depoları, insanların "çalışma alanı" değil, iş akışının "çıktı ürünü" olarak kullanıyorlar.

GitHub'in altyapı mühendisleri, daha büyük bir trafik sorunuyla değil, tamamen farklı bir sorunla karşı karşıya kaldı.

Sık sık oluşan arızalar sorunun yalnızca bir yüzüdür; GitHub'da daha da rahatsız edici bir başka sorun da hesap yaparken kayıp fark etmektir.

Copilot'un ilk fiyatlandırma mantığı, kullanıcının çoğunlukla "yardımcı tamamlama" amaçlı kullandığı, her etkileşimin kısa ve hesaplama yükü öngörülebilir olduğu mantıksal bir varsayım üzerine kurulmuştur. Kişisel sürüm aylık 10 dolar, ticari sürüm aylık 19 dolar olarak, koltuk bazlı ücretlendirme modeli, geçen yıllar boyunca iyi çalışmıştır.

Ardından, Agentic AI geldi.

Agentic iş akışları ve geleneksel tamamlama iki farklı türdür. Standart kod tamamlamada istekler doğrusal ve öngörülebilir olup, hesaplama döngüleri kısadır. Ancak bir Agentic kodlama oturumu saatlerce sürebilir, aynı anda birden fazla paralel iş parçacığı başlatır, çok adımlı çıkarım yapar, kendi kendini düzeltir ve çoklu depo arasında yeniden yapılandırır—bir oturum, ortalama bir kullanıcının bir aylık abonelik maliyetini kolayca aşar.

GitHub, az sayıda yoğun Agentic kullanıcısının, aylık birkaç dolarlık bir ücretle yüzlerce dolarlık hesaplama kaynaklarını tükettiği durumla karşı karşıya.

Bu durum karşısında GitHub'ın tepkisi doğrudan——önce akışı kontrol et, ardından fiyatı değiştir.

Yıl başından beri GitHub, Copilot için iki paralel akış kontrol mekanizması başlatmıştır: oturum süresi sınırı ve haftalık kullanım sınırı; her iki boyut da token tüketim miktarı ile model hesaplama ağırlığının çarpımıyla hesaplanmaktadır. Aynı zamanda, bazı bireysel Copilot abonelikleri için yeni kullanıcı kayıtları durdurulmuştur.

1 Haziran'da GitHub, daha temel bir fiyatlandırma reformu gerçekleştirdi: Copilot, abonelik ücretlerinin yerini almak üzere tamamen kullanım tabanlı faturalandırmaya geçti; 1 AI Kredisi 1 sente eşit olacak şekilde ve kullanım miktarı token tüketimiyle gerçek zamanlı olarak hesaplanacak.

Koltuk başına ücret alma dönemi, Agentic AI karşısında sona erdi.

Bu dönüşüm sadece GitHub'ın bir sorunu değil. 2026 yılında, AI'nin insanları yalnızca "yardım etmekten" ziyade tam iş akışlarını yerine getirmeye başlamasıyla, tüm AI araçları endüstrisi bir fiyatlandırma krizini yaşıyor.

Altyapı sorununa geri dönelim. GitHub bu “14 kat büyüme”ye nasıl yanıt verecek?

Sorunun ciddiyetini gösteren bir detay var:

2025 yılının Aralık sonunda, Agentic iş akışı aniden hızlanmaya başladı. GitHub mühendisleri, 10 katın yeterli olmadığını fark etti. 2026 yılının Şubat ayında, o ciddi kesintiden sonra, GitHub mimarinin bugünün ölçeğinin 30 katına göre yeniden tasarlanmasını açıkladı.

Yeniden tasarlanıyor, ölçeklendirme değil.

Bu iki terim arasındaki fark büyük. Ölçeklendirme, mevcut makineleri çoğaltmak ve mevcut veritabanlarına bellek eklemektir — yön değişmez, sadece boyut büyür. Yeniden tasarım ise, mevcut mimarinin 30 kat büyüklükte sistematik olarak başarısız olacağını ve hizmet bölümlendirme, veri akışı ve hata izolasyonu yöntemlerinin temelden yeniden düşünülmesi gerektiğini anlamaktadır.

GitHub tarafından belirtilen özel yönler arasında, kaskat başarısızlıkları önlemek için kritik hizmetlerin ayrılması, geri basın mekanizmaları ve trafik düşürme yeteneklerinin eklenmesi, sıcak hizmetler için ayrı sunucuların dağıtılması, tek bir hata noktası kaldırılması ve daha kapsamlı değişiklik yönetimi—özellikle önbellek TTL'sini 12 saatten 2 saate değiştirmek gibi yeterli yük testi yapılmadan doğrudan üretim ortamına alınması—yer alıyor.

Dikkat edilmesi gereken nokta, GitHub'ın yalnız olmadığınıdır.

Stripe, AI Agent'lerin birden fazla hesap oluşturması sorunuyla karşılaştı; AWS, Agent'lar için özel kimlik sistemi, günlük sistemi ve üretim kontrol mekanizmaları geliştiriyor. Bu adımlar önleyici önlemler değil, izleme panellerinde çözülmesi gereken sinyallerin zaten ortaya çıkması sonucu alınan tedbirler.

GitHub, AI araç zincirinin en merkezinde olduğu için sadece ilk hedeftir.

Bu olayın doğasını bir düşünün.

GitHub nedir? En doğrudan cevap, programcıların kodlarını sakladıkları yerdir. Ancak daha derin bir bakışla, bu, insan yazılım işbirliğinin altyapısıdır—commits işbirliğinin izidir, PR'ler tartışmaların kaplarıdır, Issues niyetlerin kalıcı kayıtlarıdır, Actions ise yürütmenin borularıdır. Bu tam sistem, insan iş ritmini, düşünce biçimini ve işbirliği modelini tasarlamak için oluşturulmuştur.

AI Agent bunu değiştirdi.

Bir AI aracının bir günde yüzlerce kez kod gönderebilmesi durumunda, her bir “gönderinin” arkasında insan düşüncesi ve dengesi değil, yalnızca bir görev döngüsünün ilerleme adımı bulunuyorsa, kod deposu hâlâ “işbirliğinin bir konteyneri” mi?

AI araçları deposu otomatik oluşturuyor, otomatik PR açıyor, CI’yi otomatik çalıştırıyor, otomatik merge ediyor—geliştiriciler hâlâ bu sürecin ana unsuru mu, yoksa yalnızca “denetleyici” hale mi geldiler, hatta “seyirci” mi?

GitHub CTO, bu krizi tanımlarken "yükün hızlı büyümesi" terimini kullandı. Ancak bu terim, sorunun özünü muhtemelen az değerlendirmektedir—bu sadece bir miktar artışı değil, kullanım şeklinin niteliksel bir değişimidir. Eski modelde GitHub, "geliştiricilerin aracındı"; yeni modelde GitHub, otomatikleştirilmiş bir iş akışının çıkış kanalı olan "AI'nın egzoz borusu" haline gelmektedir.

GitHub için bunun ne anlama geldiğine henüz cevap verilmedi. 30 kat ölçeklendirme trafiği çözebilir, ancak iş modelinin yeniden tanımlanmasını veya "gerçek müşterim kim?" sorusuna kimlik sorununu çözemez.

Son zamanlarda dikkat çekici bir fenomen gözlemleniyor: GitHub, kesintiden sonra birçok mühendislik blogu yayınladı ve her bir kazaın temel nedenini oldukça ayrıntılı bir şekilde açıkladı; bu düzeyde şeffaflık neredeyse şaşırtıcı düzeyde. Bazıları bunun GitHub'ın aktif olarak güven oluşturmak istediğini, diğerleri ise gelecek yeniden yapılandırma döneminde daha fazla kararsızlık yaşanacağı için geliştirici topluluğunun sabrını şeffaflıkla satın aldığını düşünüyor.

Kendi başarısıyla delinmiş bir platform, kendini parçalara ayırmak ve yeniden inşa etmek zorunda kalır—ve bu süreç, dayanıp dayanamayacağını test eder.

9 Şubat'ta PR birleşimini bekleyen mühendis, sonunda yeşil ışığı almayı beklemiş olabilir. Ancak beklemesine neden olan arıza, GitHub'ın rastgele bir hatası değil, yazılım geliştirme endüstrisinin yeni bir çağa girdiğini gösteren bir ses olabileceğini fark etmemiş olabilir.

Bu yazı, WeChat hesabından "GeekPark" (ID: geekpark) tarafından yayınlanmıştır, yazar: Uygar Ape