Cloudflare 18 Kasım 2025 Kesintisi Sonrası Analizi

(blog.cloudflare.com)

23 puan yazan GN⁺ 2025-11-19 | 8 yorum | WhatsApp'ta paylaş

18 Kasım 2025 11:20'de (UTC) Cloudflare ağının çekirdek trafik iletim işlevi durdu ve dünya genelindeki kullanıcılar hata sayfaları gördü
Nedeni, veritabanı izin değişikliği nedeniyle Bot Management sisteminin feature dosyasının anormal şekilde büyümesi olup, siber saldırıyla ilgisi yoktu
Bu dosya boyutu artışı nedeniyle trafik yönlendirme yazılımı sınır değeri aşıp başarısız oldu ve büyük ölçekte HTTP 5xx hataları oluştu
Yaklaşık 14:30'da sorunlu dosyanın dağıtımı durdurulup önceki sağlıklı sürümle değiştirilerek çekirdek trafik geri yüklendi; 17:06'da tüm hizmetler normale döndü
Cloudflare bu olayı 2019'dan bu yana en kötü kesinti olarak değerlendiriyor ve yapılandırma dosyası doğrulamasını güçlendirme ile küresel kill switch ekleme gibi tekrarını önleyici adımlar atıyor

Kesintinin özeti

11:20 civarında Cloudflare ağında çekirdek trafik iletiminde başarısızlık yaşandı ve kullanıcılar Cloudflare iç hata sayfalarını gördü
Nedeni siber saldırı veya kötü niyetli bir eylem değildi; doğrudan sebep veritabanı sistemindeki izin değişikliğiydi
Bu değişiklik nedeniyle Bot Management sisteminin kullandığı feature dosyasının boyutu iki katına çıktı ve ağ geneline dağıtıldı
Trafik yönlendirme yazılımı bu dosyayı okurken dosya boyutu sınırını aştı ve sistem hatası oluştu
İlk aşamada büyük ölçekli bir DDoS saldırısı sanıldı, ancak neden belirlendikten sonra önceki sağlıklı dosyayla değiştirilerek kurtarma başlatıldı

Kesintinin ilerleyişi ve etkisi

11:20 öncesinde 5xx hata oranı normal seviyedeydi, ancak sonrasında hatalı feature dosyasının dağıtılmasıyla hatalar hızla arttı
ClickHouse veritabanı kümesindeki bazı düğümlerde yanlış sorgu sonuçları 5 dakikalık aralıklarla üretildi; sağlıklı ve sağlıksız dosyalar dönüşümlü dağıtıldığı için sistem tekrar tekrar toparlanıp yeniden başarısız oldu
14:30'dan itibaren sorunlu dosya üretimi durduruldu ve sağlıklı dosya elle eklendi; çekirdek proxy yeniden başlatılarak kurtarma sağlandı
17:06'da tüm hizmetler normale döndü

Hizmet	Etki
Core CDN ve güvenlik hizmetleri	HTTP 5xx hataları oluştu
Turnstile	Yüklenemedi, giriş yapılamadı
Workers KV	Gateway başarısızlığı nedeniyle 5xx hataları keskin biçimde arttı
Dashboard	Turnstile arızası nedeniyle giriş yapılamadı
Email Security	Spam tespit doğruluğu geçici olarak düştü, bazı otomatik taşıma işlemleri başarısız oldu
Access	Çok sayıda kimlik doğrulama hatası oluştu, mevcut oturumlar korundu

Kesinti süresince CDN yanıt gecikmesi arttı; bunun nedeni debug sistemindeki CPU kullanımının keskin biçimde yükselmesiydi

Kesintinin nedeni: Bot Management sistemi

Cloudflare'ın Bot Management modülü, istek bazında bot puanı üretmek için makine öğrenimi modeli kullanıyor
Model girdisi olarak kullanılan feature yapılandırma dosyası birkaç dakikada bir ağın tamamına dağıtılarak güncel tehditlere yanıt veriyor
ClickHouse sorgu davranışındaki değişiklik nedeniyle çok sayıda yinelenen feature satırı eklendi ve dosya boyutu arttı
Bunun sonucunda Bot Management modülü hata verdi ve HTTP 5xx yanıtları döndürdü; Workers KV ve Access de etkilendi
Yeni proxy motoru FL2 üzerinde 5xx hataları oluşurken, eski FL sürümünde bot puanı 0'a ayarlanarak yanlış pozitifler arttı

ClickHouse sorgu davranışındaki değişiklik

11:05'te ClickHouse'un veritabanı erişim izni değişikliği dağıtıldı
Önceden yalnızca default veritabanının metadata'sı sorgulanabiliyordu; değişiklikten sonra r0 veritabanının metadata'sı da görünür hale geldi
Bot Management'ın feature dosyası üretim sorgusu veritabanı adı filtresi olmadan çalıştı ve sonuç olarak yinelenen sütunlar döndürdü
Bu yüzden feature dosyasındaki satır sayısı iki kattan fazla arttı ve sistem sınırını aştı

Belleğin önceden ayrılması ve sistem panic durumu

Bot Management modülü en fazla 200 makine öğrenimi feature'ı sınırı koyarak belleği önceden ayırıyor
Hatalı dosya 200'den fazla feature içerince Rust kodunda panic oluştu ve
thread fl2_worker_thread panicked: called Result::unwrap() on an Err value hatası çıktı
Bunun sonucunda büyük ölçekte HTTP 5xx hataları meydana geldi

Diğer etkiler ve kurtarma süreci

Workers KV ve Access'in çekirdek proxy'ye bağımlı olması, kesintinin etkisini büyüttü
- 13:04'te Workers KV'nin proxy'yi bypass etmesi için yama uygulandı ve hata oranı düştü
Dashboard, Turnstile ve Workers KV bağımlılığı nedeniyle giriş yapılamadı
- 11:30~13:10 ve 14:40~15:30 aralıklarında iki kez erişilebilirlik düştü
- Backlog ve yeniden deneme istekleri nedeniyle gecikme arttı; yaklaşık 15:30'da düzeldi
14:30 sonrasında hizmetlerin çoğu normale döndü, 17:06'da tam kurtarma sağlandı

Tekrarını önleme adımları

Cloudflare tarafından üretilen yapılandırma dosyaları için girdi doğrulamasının güçlendirilmesi
Küresel işlev kapatma anahtarının (kill switch) genişletilmesi
Hata raporlamasının sistem kaynaklarını tüketmesini önleme
Çekirdek proxy modülleri genelinde hata koşullarının gözden geçirilmesi

Zaman çizelgesi özeti (UTC)

Saat	Durum	Açıklama
11:05	Normal	Veritabanı erişim kontrolü değişikliği dağıtıldı
11:28	Etki başladı	Müşteri trafiğinde ilk hata oluştu
11:32–13:05	İnceleme sürüyor	Workers KV hata nedeni analiz edildi, hafifletme denendi
13:05	Etki azaldı	Workers KV ve Access için bypass uygulandı
13:37	Kurtarma çalışmaları yoğunlaştı	Bot Management yapılandırma dosyası rollback hazırlığı
14:24	Sorunlu dosya dağıtımı durduruldu	Sağlıklı dosya testi tamamlandı
14:30	Ana etki giderildi	Sağlıklı dosya küresel olarak dağıtıldı, hizmet kurtarması başladı
17:06	Tam kurtarma	Tüm hizmetler tamamen normale döndü

Sonuç

Bu kesinti, Bot Management yapılandırma dosyası üretim mantığı ile veritabanı izin değişikliğinin etkileşimi nedeniyle meydana geldi
Cloudflare bunu 2019'dan bu yana en ciddi ağ kesintisi olarak değerlendiriyor
Şirket, gelecekte sistem dayanıklılığını güçlendirmek için yapısal iyileştirmeler ve otomatik savunma mekanizmalarını artırmayı planlıyor

8 yorum

t7vonn 2025-11-19

Yapılandırma dosyasıyla ilgili arızalar her yerde ortaya çıkıyor.

princox 2025-11-19

Cloudflare çalışmayınca her türlü hizmet aksadı, tam bir cehennemdi..

epdlemflaj 2025-11-19

Kök neden analizi belgesi epey hızlı yayımlandı vay canına

epdlemflaj 2025-11-19

Bu arada, bu yazının yazarı CEO'ymuş.

GN⁺ 2025-11-19

Hacker News görüşleri

Bu, milyonlarca dolarlık bir .unwrap() kaza hikâyesi
İnternetin çekirdek altyapı yolunda .unwrap() çağırmak, "bu asla başarısız olmaz; başarısız olursa da iş parçacığını hemen öldür" demekle aynı şey
Rust derleyicisi başarısızlık olasılığını açıkça ifade etmeye zorlar, ama onlar bunu zarif biçimde ele almak yerine panic seçmiş
Bunun tipik bir "parse, don’t validate" anti-pattern örneği olduğunu düşünüyorum
- Birçok kişinin .unwrap() konusunda bir kör noktası var gibi görünüyor. Belki örnek kodlarda sık görünmesindendir
  Gerçek üretim kodunda .unwrap() ya da .expect() bir panic gibi review edilmelidir
  Üretim kodunda .unwrap() kullanılıyorsa mutlaka "INFALLIBILITY" yorumu eklenmeli ve bu clippy::unwrap_used ile zorunlu tutulabilir
- Bu yazının ana noktası, tek bir nedenden çok normal bileşenlerin birleşiminin soruna yol açması gibi görünüyor
  Mesele sadece .unwrap() değil; sorgu veritabanlarını ayırmadığı için payload büyüdü ve ClickHouse daha fazla DB’yi görünür kıldı
  "unwrap yüzünden" diye kestirip atmaktan ziyade, global kill switch ya da sistem kaynaklarının ezilmesini önleyecek tasarım iyileştirmeleri daha önemli bence
- Aslında bu, Rust yolunun dışında da başarısız oldu. Çünkü bot yönetim sistemi tüm trafiği bot olarak sınıflandırdı
  FL2 katmanında her bileşenin panic durumunu yakalamak gerekir, ama fail-open her zaman daha iyi değildir
  Panic’in yakalanıp işlenip işlenmeyeceğine FL2 seviyesinde açıkça karar verilmesini sağlayacak mantık eklenmeli
- Eğer bunu zarif biçimde ele alsalardı muhtemelen performans düşüşü olurdu (yine de bunun güvenilirlik kaybından daha iyi olduğunu düşünüyorum)
  Sharded sistemlerde neden kademeli rollout ve izleme olmadığını da merak ediyorum
- Swift’te örtük ! unwrap ve açık ? unwrap var
  Ben örtük unwrap’i neredeyse hiç kullanmıyorum. Değer garanti edilmiş olsa bile her zaman açıkça ele alıyorum
  Örneğin @IBOutlet weak var someView! yerine @IBOutlet weak var someView? tanımlıyorum
  Bu biraz belt & suspenders yaklaşımı
Kesintiden 24 saat bile geçmeden post mortem yayımlamaları gerçekten etkileyici
- Bunu bu kadar hızlı ve şeffaf biçimde yayımlamayı mümkün kılan iç politikanın ne olduğunu merak ediyorum
  Çoğu büyük şirkette çeşitli stakeholder incelemeleri yüzünden bu düzeyde açıklama yapmak neredeyse imkânsız olurdu
- Üstelik yazının kendisi de iyi yazılmış. AWS postmortem’leriyle karşılaştırınca neredeyse edebiyat gibi
Cloudflare’ın kesinti açıklamasını okurken, "neden toparlanmaları bu kadar uzun sürdü" diye düşündüm
Kesintinin nedenini anladım ama ağın büyük kısmı çöktüyse yakın zamandaki yapılandırma değişikliğini geri almak ilk öncelik olmalı diye düşündüm
Elbette sonradan bakınca net görünüyor ama 7 dakika içinde incelemeye başlamış olmaları etkileyici
- Başta bunu saldırı sandılar. Sonra sorunu anladılar ama bozulmuş dosyayı kuyrukta değiştirecek bir yolları yoktu ve dünya çapında sayısız makineyi yeniden başlatmaları gerekti
Bu olay bana CrowdStrike vakasını hatırlatıyor
Otomatik üretilen bir yapılandırma dosyası yazılımı bozdu ve tüm ağa yayıldı
Hızlı dağıtım ihtiyacını anlıyorum ama bu olay kademeli rollout ve rollback stratejisinin eksikliğini ortaya koyuyor
- Buna CI/CD dağıtımı demektense, dağıtık bot tespit sisteminin kontrol kanalı demek daha doğru
- Simülatör olmadan doğrudan production’a push etmiş olmaları şaşırtıcı
- Yine de bunun sonucunda iyileştirmeler yapılacağına inanıyorum
Cloudflare’ın duyurduğu ileriye dönük iyileştirme planlarına bakınca,
- Cloudflare tarafından üretilen yapılandırma dosyalarının doğrulamasını güçlendirme
- Global kill switch ekleme
- Core dump veya hata raporlarının kaynak tüketimine yol açmasını önleme
- Proxy modülünün hata modlarını gözden geçirme
  gibi maddeler var
  Ama canary deployment ya da kademeli yapılandırma dağıtımı yok
  Global switch riskli olabilir ve tek bir bug ile tüm sistemi durdurabilir
- Bot yönetimi yapılandırmasının hızlı yayılması gerekiyor olabilir ama önce tek bir instance’ta test edilseydi panic önceden yakalanabilirdi
  ClickHouse’u neden feature flag deposu olarak kullandıkları da soru işareti. ClickHouse deduplication dokümanı bile risklere işaret ediyor
- Yapılandırma servisinde kademeli rollout vardı ama bunu tüketen servisler fazla sık otomatik güncellendiği için küçük bir hata oranı bile herkesi etkiledi
- Global yapılandırma hızlı müdahale için yararlı ama hızlı rollback mekanizması şart
  Servisler arası bağımlılık haritalaması olsaydı kök neden takibi çok daha kolay olurdu
- Sonuçta büyük çaplı kesintilerin çoğu config push yüzünden oluyor
  Kod dağıtımı dikkatli yapılıyor ama yapılandırma dağıtımı aynı ciddiyetle ele alınmıyor. Yapılandırmanın da kod olduğunun kabul edilmesi gerekiyor
Status sayfasının da düşmesi ve bunun saldırı sanılması ilginç
Cloudflare altyapısından tamamen ayrı olduğu söyleniyor ama neden onunla birlikte çöktüğüne dair bir açıklama yok
- Muhtemelen trafik patlaması nedeniyle altyapının ölçeklenememesi söz konusuydu
- Aslında Cloudflare bağımlılığı olmadığını düşünüyor olabilirlerdi ama internetin önemli bir bölümü CloudFront kullandığı için tamamen bağımsız da olmayabilirlerdi
- Nedeni anlamak için statuspage.io’nun postmortem’i gerekir. Bu, Atlassian tarafından işletilen bir servis
- Sadece Cloudflare’ın ölçeği o kadar büyük olabilir ki trafik oraya yığılmıştır
Ben Turnstile’ı fail-open stratejisiyle entegre ettim ve bu kesintide bunun faydasını gördüm
JS yüklenmezse dummy token ile gönderime izin veriyorum; backend’de doğrulama başarısız olsa bile fail-open davranıyorum
Bazı kullanıcılar yine de engellendi ama toplam etki azaldı
Bu, elimde başka bot azaltma araçları olduğu için mümkün olan bir yaklaşım
- O zaman saldırganların script’i engelleyerek CAPTCHA’yı aşamayacağı mı soruluyor
  Ama bu muhtemelen yalnızca hedefli olmayan saldırılarda işe yarar
Cloudflare kodunda neden .unwrap() kullanımına izin verildiği soru işareti
En azından expect("Bu asla olmaz") yazmaları gerekirdi
Hataları değer olarak ele alma felsefesi zaten bu tür sorunları önlemek için var; ayrıca teşhis de çok daha kolay olurdu
- Cloudflare çalışanı değilim ama Rust’ı epey kullanıyorum
  Ağ çağrıları içeren kodlarda başarısızlık ihtimali çok fazla
  Geliştirme sırasında .unwrap() kullanıyorum ama production’da bazen expect() bırakıyorum. Çünkü bazen ilerlemenin başka yolu olmuyor
Asıl ders, çok fazla işlevin az sayıdaki oyuncuya bağımlı hâle gelmiş olması
Kazanan hepsini alır yapısı güçlendikçe sistemin dayanıklılığı azalıyor
Elbette bu konuma yetenekleriyle geldiler ama internetin her zaman “çalışır durumda” olacağını beklemek fazla iyimser gibi
"Rust olunca her şey güvenli" söylemi abartı
Hangi dil olursa olsun, yanlış kullanılırsa silahı kendi ayağına doğrultmak gibi olur

barca105 2025-11-19

CF gibi bir şirkette bile .unwrap() kullanılıyor ha vay be
O kod prodüksiyona nasıl alınmış?

skageektp 2025-11-19

Sorunun unwrap ile ilgili olmadığını düşünüyorum