Bir Copilot retry fırtınası, GitHub'daki küçük bir kapasite aksaklığını neredeyse 8 saatlik bir kesintiye dönüştürdü

Ne oldu

17 Ağustos 2026'da GitHub, kullanıcılara neredeyse sekiz saat boyunca kesintisiz hata döndürdü. Olayı inceleyen dev.to'daki bir yazıya göre bozulma 13:28'den 21:15 UTC'ye kadar — 7 saat 47 dakika — sürdü ve Git operasyonlarını, Actions'ı, Issues'u, pull request'leri ve Copilot'u etkiledi. Web ve API isteklerinin yaklaşık yüzde 20'si başarısız oldu; arşiv ve ham içerik indirmelerinde hata oranı kabaca yüzde 50'ye ulaştı.

Tetikleyici, kimsenin autoscale etmediği bir proxy'idi

Dev.to'daki yazı, ilk arızayı eşzamanlılık (concurrency) limitine takılan bir Istio sidecar proxy'sine bağlıyor. Daha büyük sorun ise bunun etrafındaki körlük noktasıydı: GitHub'ın autoscaling mekanizması reportedly sidecar'ın doygunluğunu değil, host uygulamanın metriklerini izliyordu. Autoscaler'ın bakış açısından her şey sağlıklı görünüyordu, dolayısıyla ek instance'a ihtiyaç duyulmadı. Fazla trafik taşarak dört HAProxy düğümünü kapasite limitlerinin ötesine itti ve gateway katmanını bozdu.

Yazarın savına göre bu, tek başına ele alındığında çözülebilir bir kapasite sorunuydu. Bunu bir serüvene dönüştüren şey ise istemci tarafında yaşandı.

İyileşmekte olan bir servise yönelen bir retry döngüsü

Dev.to'daki yazıya göre VS Code Copilot eklentisindeki gizli bir hata, istemcilerin Copilot Token Service'ten defalarca yeni kimlik doğrulama token'ı istemesine yol açtı. Servis backend hatası döndürdüğünde istemciler dayanıklı olduklarını düşündükleri şeyi yaptılar: hemen, tekrar tekrar denemek.

Rakamlar çarpıcı. Token Service normalde saniyede 7.000 ila 9.000 istek işliyor. Olay sırasında saniyede 70.000 ila 100.000 istek aldı — normal yükünün sekiz ila on dört katı, tamamı da aynı anda toparlanmaya çalışan bir altyapıya yönelmişti.

Yazıda alıntılandığı gibi GitHub CTO'su Vlad Fedorov durumu şöyle özetledi: backend hataları "kurtarma süreci sırasında trafiği artıran istemci tarafı bir retry döngüsünü tetikledi."

Naive retry'ler kesintileri neden kötüleştirir

Yazarın ana tezi, retry'lerin rutin olarak bedava dayanıklılık olarak görülmesi ama hiç de öyle olmaması. Sınırsız ve anında bir retry döngüsü fiilen kazara yapılmış bir hizmet dışı bırakma (denial-of-service) saldırısıdır; her yardımcı olmaya çalışan istemci, kendi işletmecisinin finanse ettiği bir botnet'in bir düğümü gibi davranır. Bir retry'yi bir çığlumaya dönüştüren üç eksik özellik vardır:

• Bütçe yok: istemciler sınırsız retry yapar, dolayısıyla eklenen yükün bir tavanı olmaz.
• Backoff yok: retry'ler anında tetiklenir ve zorlanan servise nefes alma payı bırakmaz.
• Jitter yok: herkes aynı saatle retry yapar, dolayısıyla istekler senkronize dalgalar halinde ulaşır.

Yazıda belirtildiği gibi toparlanma için nefes payı gerekir ve naive retry'ler, hatalar başladığı anda mevcut tüm nefes payını tüketir. Jitter içermeyen üstel backoff bile bir thundering herd'i yeniden yaratabilir, çünkü her istemci aynı süreyi bekler ve aynı anda ateş eder.

Düzeltmeler gösterişsiz ama kanıtlanmış

Yazı iki standart çözüm öneriyor. Bir retry bütçesi, retry'leri toplam trafiğin bir kesriyle sınırlar — örneğin retry'ler isteklerin yüzde 10'unun altında kalmalıdır. Sınıra ulaşıldığında istemciler tekrar denemek yerine hızlıca başarısız olur. GitHub örneğinde bu tek kural, Token Service'teki yük patlamasını normal hacmin 14 katına tırmanmasına izin vermek yerine sınırlayabilirdi.

Jitter'lı backoff ise zamanlamayı halleder: gecikmeler retry'leri yayar hasarlı bir servis nefes alabilir ve rastgele bekleme süreleri istemcilerin dalgalara senkronize olmasını engeller.

Neden önemli

Bu olay, dayanıklılığın istemciler ve sunucular arasında paylaşılan bir sorumluluk olduğuna dair bir vaka çalışması. Yaygın olarak kurulu bir editördeki hatalı bir eklenti, GitHub'ın kendi kimlik doğrulama altyapısına fiilen dağıtık bir saldırı düzenledi — tasarım gereği değil, ama dağıtık sistemler literatürünün onlarca yıldır önerdiği korumaların atlanması sonucu.

İki kitlenin dikkat etmesi gerekiyor. Platform operatörleri, doyabilecek her katmanın — sidecar proxy'ler dahil — metrikleri üzerinden autoscale yapmalı; aksi takdirde kapasite sistemi "normal" raporlarken servis erir. Ve istemci kodu yazan herkes retry mantığını gözden geçirmeli. Dev.to yazarının hükmü net: bir retry anında, sonsuza kadar ve bedavayla yapılabiliyorsa, bu bir dayanıklılık kalıbı değildir — bir kesintiyi bekleyen bir hatadır.