Cloudflare kontrol düzlemi ve analiz sistemi kesintisi hakkında olay sonrası analiz
(blog.cloudflare.com)- 2 Kasım 2023 11:43 UTC’den itibaren Cloudflare’ın kontrol düzlemi ve analiz hizmetleri kesintiye uğradı; pano/API değişiklikleri, günlük ve analiz işlevleri etkilendi
- Arızanın başlangıç noktası, Flexential tarafından işletilen Oregon’daki PDX-04 elektrik kesintisiydi; bu tesiste en büyük analiz kümesi ve yüksek erişilebilirlik kümesi ekipmanlarının üçte birinden fazlası bulunuyordu
- utility feed, generator, UPS ve devre kesicilerin kurtarılması zincirleme biçimde aksarken PDX-04’e özgü Kafka ve ClickHouse bağımlılıkları yüksek erişilebilirlik tasarımını bozdu
- 2 Kasım 13:40 UTC’de Avrupa’daki felaket kurtarma sitesine failover yapılmasına karar verildi; 17:57 UTC’de müşteri etkisi büyük ölçüde azaldı, ancak günlük işleme, bazı bespoke API’ler, Magic WAN manuel yapılandırması ve Stream yüklemeleri daha uzun süre etkilendi
- Cloudflare, GA ürünleri için yüksek erişilebilirlik gerekliliklerini, doğrulanmış felaket kurtarma planını, temel veri merkezinin tamamen devre dışı bırakılmasını da içeren chaos testing’i ve günlük kaybını önleme planını Code Orange kapsamında ilerletiyor
Kesintinin kapsamı ve müşteri etkisi
- 2 Kasım 2023 11:43 UTC’den itibaren Cloudflare’ın kontrol düzlemi ve analiz hizmetlerinde kesinti yaşandı
- Kontrol düzlemi, web sitesi ve API’ler dahil müşteriye dönük arayüzleri ifade eder
- Analiz hizmetleri, loglama ve analiz raporlamasını kapsar
- Olayın tamamı 2 Kasım 11:44 UTC’den 4 Kasım 04:25 UTC’ye kadar sürdü
- 2 Kasım 17:57 UTC’de kontrol düzleminin büyük bölümü felaket kurtarma tesisinde geri yüklendi
- Felaket kurtarma tesisi çevrimiçi olduktan sonra çoğu üründe birçok müşteri sorun yaşamamış olabilir
- Bazı hizmetlerin toparlanması daha uzun sürdü ve bu hizmetleri kullanan müşteriler, tamamen çözülene kadar sorun görebildi
- Ham günlük hizmetleri, olay süresinin büyük bölümünde çoğu müşteri için kullanılamadı
- Cloudflare’ın ağ ve güvenlik hizmetleri olay boyunca beklendiği gibi çalıştı
- Müşterilerin bu hizmetlerde değişiklik yapamadığı dönemler oldu
- Cloudflare ağından geçen trafik etkilenmedi
Özgün tasarım: Oregon’daki 3 veri merkezi üzerine kurulu yüksek erişilebilirlik
- Cloudflare’ın kontrol düzlemi ve analiz sistemleri ağırlıklı olarak Oregon, Hillsboro çevresindeki 3 veri merkezindeki sunucularda çalışır
- 3 veri merkezi birbirinden bağımsızdır; her birinde birden fazla utility power feed ve birden fazla yedekli, bağımsız ağ bağlantısı bulunur
- Tesisler, doğal afetlerin aynı anda etkilemesini zorlaştıracak kadar birbirinden uzak, ancak active-active yedekli veri kümeleri çalıştırabilecek kadar yakın konumlarda seçildi
- Üç tesis verileri sürekli senkronize eder
- Tasarıma göre bir tesis çevrimdışı olsa bile kalan tesislerin çalışmaya devam edebilmesi gerekiyordu
- Bu yüksek erişilebilirlik tasarımı 4 yıl önce uygulanmaya başlandı
- Temel kontrol düzlemi sistemlerinin çoğu yüksek erişilebilirlik kümesine taşındı
- Bazı yeni ürünlerin hizmetleri henüz yüksek erişilebilirlik kümesine dahil edilmemişti
- Loglama sistemi kasıtlı olarak yüksek erişilebilirlik kümesine dahil edilmedi
- Günlükler, network edge’de kuyruğa alındıktan sonra Oregon core’a veya bölgesel loglama tesislerine gönderilen dağıtık bir sorun olarak ele alındı
- Loglama tesisi çevrimdışıysa analiz günlüklerinin edge’de beklemesi ve analiz gecikmesi kabul edilebilir olarak değerlendirildi
PDX-04 elektrik kesintisinin başlangıcı
- Oregon’daki 3 tesisin en büyüğü Flexential tarafından işletilen PDX-04’tür
- Cloudflare en büyük analiz kümesini burada barındırır
- Yüksek erişilebilirlik kümesi ekipmanlarının üçte birinden fazlası da bu tesistedir
- Yüksek erişilebilirlik kümesine onboarding yapılmamış hizmetlerin varsayılan konumu da burasıdır
- Cloudflare, bu tesisin toplam kapasitesinin yaklaşık %10’unu kullanan görece büyük bir müşteridir
- 2 Kasım 08:50 UTC’de PDX-04’e elektrik sağlayan Portland General Electric’in (PGE) bağımsız güç feed’lerinden birinde plansız bir bakım olayı meydana geldi
- Bu olay PDX-04’e gelen feed’lerden birini kesti
- Flexential, kesilen feed’i telafi etmek için generator’ı devreye aldı
- Flexential, Cloudflare’a generator gücüne failover yaptığını bildirmedi
- Cloudflare’ın gözlem araçları güç kaynağının değiştiğini algılamadı
- Önceden bildirim olsaydı Cloudflare tesisi yakından izleyebilir ve o tesise bağımlı kontrol düzlemi hizmetlerini başka yere taşıyabilirdi
- Flexential’ın kalan utility feed ile generator’ı aynı anda çalıştırması da olağandışıydı
- Flexential, yedekli üniteler dahil 10 generator işletir ve tesisin tüm yükünü karşılayabilir
- Tesisi yalnızca kalan utility feed ile işletmek de mümkündü
- Cloudflare, Flexential’ın utility power ve generator power’ı neden birlikte kullandığına dair net bir yanıt alamadı
Doğrulanmamış neden ve generator’ların durması
- Sonraki olayların kök nedeni ve bazı kararlar Flexential tarafından net biçimde doğrulanmadı
- Olası nedenlerden biri olarak Flexential’ın PGE’nin DSG programına katılmış olma ihtimali sürüyor
- DSG, yerel elektrik şirketinin veri merkezi generator’larını kullanarak şebekeye ek güç sağlayabilmesine olanak tanıyan bir programdır
- Karşılığında elektrik şirketi generator bakımı ve yakıt tedarikini destekler
- Cloudflare, Flexential’ın DSG programını bildirdiğine dair bir kayıt bulamadı
- Olay sırasında DSG’nin etkin olup olmadığına dair de yanıt alamadı
- 11:40 UTC civarında PDX-04’ün PGE transformer’ında ground fault oluştu
- Cloudflare, bu transformer’ın veri merkezine gelen ikinci feed’in voltajını düşüren ekipman olduğunu düşünüyor, ancak bunu doğrulatamadı
- Bu ground fault’un, ilk feed’i etkileyen PGE’nin plansız bakımından kaynaklanıp kaynaklanmadığı da doğrulanmadı
- 12.470 V yüksek gerilim hattındaki ground fault durumunda elektrik sistemleri, hasarı önlemek için hızlıca kapanacak şekilde tasarlanır
- Bu koruma önlemi PDX-04’teki tüm generator’ları da durdurdu
- Sonuç olarak hem utility line hem de 10 generator’ın tamamı çevrimdışı kaldı
- PDX-04’te tesisi yaklaşık 10 dakika ayakta tutabildiği belirtilen UPS batarya bankaları vardı
- Bu süre, elektrik kesintisi ile generator’ların otomatik yeniden başlatılması arasını kapatmak içindir
- Cloudflare ekipman arızası gözlemlerine göre bataryalar 4 dakika içinde başarısız olmaya başladı
- Flexential’ın generator’ları geri yüklemesi 10 dakikadan çok daha uzun sürdü
Elektrik geri yüklemesindeki gecikme ve ilk bildirim
- Cloudflare resmi doğrulama alamamış olsa da Flexential çalışanlarından, generator geri yüklemesini engelleyen üç faktör duydu
- Ground fault’un devreyi trip ettirme şekli nedeniyle generator’lara fiziksel olarak erişilip manuel yeniden başlatma yapılması gerekiyordu
- Flexential’ın erişim kontrol sistemi batarya yedek gücüyle beslenmediği için çevrimdışıydı
- Gece vardiyasında deneyimli operasyon veya elektrik uzmanı yoktu; yalnızca güvenlik personeli ve işe bir hafta önce başlamış, yanında refakatçisi olmayan bir teknisyen vardı
- 11:44–12:01 UTC arasında generator’lar tamamen yeniden başlatılamamışken UPS bataryaları boşaldı ve veri merkezindeki tüm müşteriler elektriğini kaybetti
- Flexential bu süreçte Cloudflare’a tesis sorununu bildirmedi
- Cloudflare, 11:44 UTC’de tesisi dış dünyaya bağlayan 2 router’ın çevrimdışı olmasıyla veri merkezi sorununu ilk kez fark etti
- Router’lara doğrudan veya out-of-band management ile erişemeyince Flexential ile iletişime geçti ve yerel ekibi tesise gönderdi
- Flexential’ın Cloudflare’a gönderdiği ilk kesinti mesajı 12:28 UTC’de geldi
- Mesajda PDX-04 elektrik sorununun 12:00 UTC civarında başladığı, mühendislerin kurtarma üzerinde çalıştığı ve her 30 dakikada bir ilerleme durumu bildirileceği yazıyordu
Yüksek erişilebilirlik tasarımında ortaya çıkan bağımlılık sorunu
- PDX-04 inşaat öncesinde Tier III sertifikalı tasarım aldı ve yüksek erişilebilirlik SLA’sı sunması bekleniyordu; ancak Cloudflare bu tesisin çevrimdışı kalma olasılığını da planladı
- Beklenen etki; analiz kesintisi, edge’de günlük kuyruğu birikmesi ve gecikme, yüksek erişilebilirlik kümesine entegre edilmemiş düşük öncelikli hizmetlerin geçici olarak durmasıydı
- Diğer iki veri merkezinin yüksek erişilebilirlik kümesini üstlenerek temel hizmetleri çevrimiçi tutması genel olarak planlandığı gibi çalıştı
- Sorun, yüksek erişilebilirlik kümesinde olması gereken bazı hizmetlerin yalnızca PDX-04’te çalışan hizmetlere bağımlı olmasıydı
- Günlük işleme ve analizden sorumlu Kafka ve ClickHouse yalnızca PDX-04’te sağlanıyordu
- Yüksek erişilebilirlik kümesinde çalışan bazı hizmetler bunlara bağımlıydı
- Bu bağımlılık daha gevşek olmalı, daha zarif biçimde başarısız olmalı ve önceden tespit edilmeliydi
- Cloudflare, yüksek erişilebilirlik kümesi testlerinde diğer iki tesisin her birini ve ikisini birlikte tamamen çevrimdışı hale getirmişti
- PDX-04’ün yüksek erişilebilirlik kısmını çevrimdışı yapma testi de gerçekleştirilmişti
- Ancak PDX-04 tesisinin tamamını tamamen çevrimdışı yapma testi yapılmamıştı
- Yeni ürünlerin ve ilgili veritabanlarının yüksek erişilebilirlik kümesine entegre edilmesini gerektiren standartlar da fazla gevşekti
- Ürün ekiplerinin alpha aşamasına giden yolları birbirinden farklıydı
- Zamanla backend’i en iyi uygulamalara taşıma yaklaşımı vardı, ancak GA ilanından önce bu resmi bir gereklilik yapılmadı
- Sonuçta yedekli koruma ürünlere göre tutarsız çalıştı
Felaket kurtarma sitesine geçiş
- 12:48 UTC’de Flexential generator’ları yeniden başlattı ve tesisin bir kısmına elektrik geri geldi
- Veri merkezi elektriğinin geri yüklenmesi genellikle devre devre kademeli olarak yapılır
- Cloudflare devrelerini tekrar açma aşamasında devre kesicilerin arızalı olduğu anlaşıldı
- Bu kesicilerin ground fault veya surge nedeniyle mi arızalandığı, yoksa önceden mi sorunlu olduğu bilinmiyor
- Flexential arızalı kesicileri değiştirmeye başladı
- Tesis içindeki stoktan daha fazla kesici arızalandığı için yeni kesicilerin tedarik edilmesi gerekti
- Cloudflare, beklenenden fazla hizmetin çevrimdışı olduğunu ve Flexential’ın kurtarma süresi veremediğini görünce 13:40 UTC’de Avrupa’daki felaket kurtarma sitesine failover yapmaya karar verdi
- Tüm kontrol düzleminin yalnızca küçük bir oranının failover edilmesi gerekiyordu
- Hizmetlerin çoğu kalan iki core veri merkezindeki yüksek erişilebilirlik sistemlerinde çalışmaya devam etti
- 13:43 UTC’de felaket kurtarma sitesinde ilk hizmet çalıştırıldı
- Bu site, felaket durumunda temel kontrol düzlemi hizmetlerini sağlamak üzere tasarlandı
- Bazı günlük işleme hizmetlerini desteklemiyordu
- Hizmet devreye alındıktan sonra başarısız olan API çağrıları yığılınca thundering herd sorunu oluştu
- Cloudflare, istek hacmini kontrol etmek için rate limit uyguladı
- Bu dönemde çoğu ürün müşterisi, pano veya API üzerinden değişiklik yaparken aralıklı hatalar görebildi
- 17:57 UTC’ye kadar felaket kurtarma sitesine taşınan hizmetler kararlı hale geldi ve çoğu müşterinin doğrudan etkisi azaldı
- Magic WAN gibi bazı sistemlerde hâlâ manuel yapılandırma gerekiyordu
- Günlük işleme ve bazı bespoke API ile ilgili hizmetler PDX-04 geri yüklenene kadar kullanılamadı
Bazı ürünlerde gecikmeli kurtarma ve PDX-04’ün yeniden başlatılması
- Bazı ürünler felaket kurtarma sitesinde düzgün çalışmadı
- Bunlar çoğunlukla felaket kurtarma prosedürleri tamamen uygulanmamış ve test edilmemiş yeni ürünlerdi
- Yeni video yüklemeleri için Stream hizmeti ve bazı diğer hizmetler buna dahildi
- Cloudflare ekipleri iki yolu aynı anda yürüttü
- Bu hizmetleri felaket kurtarma sitesinde yeniden uygulamak
- Yüksek erişilebilirlik kümesine taşımak
- Flexential arızalı devre kesicileri değiştirdi, iki utility feed’i geri yükledi ve 22:48 UTC’de kararlı elektriği doğruladı
- Cloudflare, ekip tüm gün acil durum müdahalesi yaptığı için personelin çoğunun dinlenmesine ve ertesi sabah PDX-04’e dönüş çalışmalarının başlatılmasına karar verdi
- Bu karar genel kurtarmayı geciktirdi, ancak ek hata yapma olasılığını azaltmaya yönelik bir değerlendirmeydi
- 3 Kasım sabahından itibaren PDX-04 hizmetlerinin kurtarılması başladı
- Ağ ekipmanı fiziksel olarak boot edildi
- Binlerce sunucu açıldı ve hizmetler geri yüklendi
- Olay sırasında birkaç kez güç döngüsü yaşanmış olabileceği için veri merkezindeki hizmetlerin durumu bilinmiyordu
- Güvenli kurtarma prosedürü, tüm tesisin tam bootstrap sürecini izlemekti
- Yapılandırma yönetimi sunucuları manuel olarak çevrimiçi hale getirildi ve yeniden kurulum 3 saat sürdü
- Ardından kalan sunucular bootstrap yöntemiyle yeniden kuruldu
- Her sunucunun yeniden kurulumu 10 dakika ile 2 saat arasında sürdü
- Birçok sunucuda paralel çalışıldı, ancak hizmetler arası bağımlılıklar nedeniyle bazıları için sıralı kurtarma gerekti
- Tüm hizmetler 4 Kasım 2023 04:25 UTC’de tamamen geri yüklendi
- Çoğu müşteri için analiz verileri Avrupa core veri merkezinde de saklandığından, pano ve API’deki analizlerin çoğunda veri kaybı beklenmiyor
- AB’ye replike edilmemiş bazı veri setlerinde kalıcı boşluklar kaldı
- Logpush kullanan müşteriler için olay süresinin büyük bölümünde günlükler işlenmedi ve alınamayan günlükler geri getirilmeyecek
Code Orange ve iyileştirme planı
- Cloudflare’ın Flexential’dan yanıt alması gereken birçok soru var, ancak tüm bir veri merkezi arızasının da beklenmesi gerektiği sonucuna vardı
- Google’ın Code Yellow ve Code Red süreçlerine benzer şekilde, önemli olaylar veya krizlerde mühendislik kaynaklarını sorunu çözmeye odaklayan kendi süreci Code Orange’ı devreye aldı
- Kritik olmayan mühendislik işlevleri, kontrol düzleminin yüksek güvenilirliğini sağlamaya yönelik çalışmalara kaydırıldı
- Planlanan değişiklikler şunlar
- Tüm hizmetlerin kontrol düzlemi yapılandırmalarında core veri merkezi bağımlılıklarını kaldırmak ve mümkün olduğunda Cloudflare’ın dağıtık ağının önce çalışacağı şekilde taşımak
- Tüm core veri merkezleri çevrimdışı olsa bile ağ üzerinde çalışan kontrol düzleminin işlevini sürdürmesini garanti etmek
- Core veri merkezlerine bağımlı GA ürünleri ve özelliklerinin, belirli bir tesise yazılımsal bağımlılık olmadan yüksek erişilebilirlik kümesine dayanmasını zorunlu kılmak
- GA ürünleri ve özelliklerinin test edilmiş, güvenilir bir felaket kurtarma planına sahip olmasını zorunlu kılmak
- Sistem arızalarının blast radius’unu test etmek ve arızadan etkilenen hizmet sayısını en aza indirmek
- Her core veri merkezi tesisinin tamamen devre dışı bırakılması dahil tüm veri merkezi işlevleri için daha sıkı chaos testing uygulamak
- Tüm core veri merkezlerini kapsamlı biçimde denetlemek ve standartlara uyumu sağlamak için yeniden denetim planı oluşturmak
- Tüm core tesis arızası senaryolarında bile günlüklerin kaybolmaması için loglama ve analiz felaket kurtarma planı hazırlamak
- Cloudflare, gerekli sistem ve prosedürlere sahip olmasına rağmen bunlara uyulmasını ve bilinmeyen bağımlılıkların test edilmesini zorunlu kılacak katılıktan yoksun olduğunu özetledi
1 yorum
Hacker News yorumları
Yazının büyük bölümünü belirli bir tedarikçi adını vererek sorumluluğu ona yıkmaya ve kök nedeni tahmin etmeye ayırmaları garip bir tercih olmuş.
Tesisteki büyük bir müşteri olduklarını açıklamaları ve tedarikçinin Confidential olarak işaretlediği elektrik diyagramlarını bile olay sonrası analize koymaları da epey uygunsuz görünüyor.
Olayı tetikleyen etkeni ve bağlamı açıklamalarını anlıyorum, ama olay sonrası analizin odağı tedarikçi değil Cloudflare’in kesintisi olmalı.
Flexential da kendi olay sonrası analizini yapacaktır, ama Cloudflare’in onun yerine tahmin yürütüp bunu kamuya açıklamasına gerek yok.
Birileri önce hikâyeyi kurmadan Cloudflare’in proaktif biçimde açıklama yapma amacı da olabilir.
Üç tarafın ve birden çok bağlantılı sistemin iç içe geçtiği bir durumda, Cloudflare’in bundan sonra bu tür bileşik arıza modlarını tasarımına yansıtabilmesi için ne olduğunu sonuna kadar bilmek istemesi makul.
Şahsen Cloudflare’in paylaştığı bilgiler için minnettarım.
Sorumluluğun %99’u, temel görevini yerine getiremeyen Cloudflare’de.
Üçüncü bir tarafı bu kadar derinlemesine didiklemeleri, aslında bu işin Cloudflare için ne kadar utanç verici olduğunu gösteriyor.
Devre kesici bakımını da doğru düzgün yapmamış gibi görünüyorlar; tesis görece yeni olmasına rağmen jeneratör akülerini şarj etmek için gereken 10 saatin yarısını bile sağlayamamışlar.
Bu bakım sırasında tamamen jeneratörlere geçmiş olmaları gerekirdi; muhtemelen PGE’ye yardımcı oldukları için bunu yapamadılar.
Cloudflare CEO’sunun haklı olduğunu düşünüyorum. Veri merkezi hizmetlerinde tam yedeklilik bekleyerek para ödüyorsunuz; bu lokasyonda 18MW olduğu söyleniyor ama görünen kadarıyla yalnızca 2 besleme mi var, o bile belirsiz.
Bir besleme ölürse 2N yapı devreye girmeli ve jeneratör varsa sorun olmamalı.
Öyleyse şimdiye kadar tespit edilen ilk olay açıklamasının yer alması da doğru.
Devam analizinin gelme olasılığı yüksek görünüyor.
https://twitter.com/eastdakota/status/1720688383607861442?t=...
Alıntılanan içeriğe bakılırsa kesintinin kök nedeni tek bir veri merkezine bağımlılıktı.
Temel kontrol düzlemi sistemlerinin çoğunu yüksek erişilebilirlikli kümelere taşımışlar, ama bazı yeni ürünler henüz taşınmamış; yüksek erişilebilirlikli kümede olması gereken bazı servisler PDX-04’te çalışan servislere bağımlıymış ve bazı ürünler felaket kurtarma sitesinde düzgün ayağa kalkmamış.
İnternetin önemli bir kısmını ayakta tutan Cloudflare gibi bir şirket için epey utanç verici.
Cloudflare, birden çok ekibin hızlı inovasyon yapmasına izin verdiği için ürünlerin ilk alfaya kadar farklı yollar izlediğini; zamanla en iyi uygulamalara taşındıklarını, ancak bunu genel kullanıma çıkıştan önce zorunlu koşul yapmadıklarını söylemiş.
Bu tam bir yönetim başarısızlığı. Müşterilere, Cloudflare’in iç standartlarına göre alfa kalitesinde yazılım satılmış olmuyor mu?
https://news.ycombinator.com/item?id=38113503
Öz farkındalık eksikliği var gibi görünüyor.
Bu amatörce bir seviye ve özellikle yeni servislerin yüksek erişilebilirlik olmadan yayınlanmış olması ciddi.
Bu kesintiden biraz etkilenmiş biri olarak, bu olay sonrası analizin yetersiz olduğunu düşünüyorum.
%75’i PDX-04’teki güç arızasını ve Flexential’ın sorumluluğunu ele alıyor; metne bakılırsa orada yaşananlar felakete yakınmış, bu yüzden bunu anlıyorum.
Ama 2 Kasım UTC itibarıyla güç tamamen geri gelmişti ve bundan sonra Cloudflare’in tam toparlanması yaklaşık 30 saat daha sürmüş deniyor.
Toparlanma kesintiden daha uzun sürmüş, fakat yazı yalnızca çok fazla servisin birbirine bağımlı olduğunu söylüyor. Tüm operasyonun yeniden ayağa kalkmasının neden bu kadar uzun sürdüğünü daha ayrıntılı bilmek isterdim.
Toparlanma sürecinin kendisinden çıkarılan hiçbir ders yok muydu? Yoksa gerçekten yalnızca verileri uçtan “beyne” yeniden senkronize etmek mi o kadar zaman aldı?
Ayrıca eksik kalan bir başka kısım da özellikle kurumsal müşterilerle iletişim eksikliği. Cloudflare desteği, durum sayfası dışında fiilen sessizdi; gerçekçi olarak yapabilecekleri çok şey olmasa bile iletişim kurma çabası gerekliydi.
Olay sonrası analizde Flexential’ın iletişim eksikliğini suçladıktan sonra bu daha da önemli; Cloudflare ürünlerini seviyorum ama bu olaydan daha fazla sonuç çıkarmaları gerektiğini düşünüyorum.
Yine de buna olay sonrası analiz demek biraz ters. Tam bir olay sonrası analizde yukarıda söylenen düzeyde ayrıntı olmalı.
Loglama çökerse tam olarak hangi servisler başarısız oluyor? İstemeden mi böyle tasarlandı? Neden kimse fark etmedi?
Cloudflare’ın olay sonrası analizinin kapsamlı olması iyi
Dürüst ve şeffaf açıklama, neredeyse tüm diğer şirketlerin muğlak iletişim stratejileriyle karşılaştırıldığında ferahlatıcı
Biz de etkilendik ama bu tür yazılar yüzünden tam tersine ayrılmak istemiyorum. Herkes hata yapabilir ve kötü bir gün geçirebilir; farkı yaratan, sonrasında nasıl karşılık verdiğinizdir
Elektrik kesintisi için bir paragraf yeterliydi; sonrasında Cloudflare tarafına geçilmeliydi. Veri merkezi arızaları yaşanabilir
Asıl öğrenilecek nokta, bu durumu düzgün hesaba katıp toparlanamayan Cloudflare’ın müdahalesinde
Biz CloudFlare Images’a ciddi şekilde bağımlıyız ve son 30 günde 67 saatten fazla kapalı kaldı
9 Ekim’de 22 saat, 2–4 Kasım’da 42 saat, aralarda da yaklaşık 1 saatlik kesintiler oldu; geçen ayki erişilebilirlik %90,6 idi
Şeffaflık, %99,9 erişilebilirlik bandında yarışan sağlayıcılar arasında harika bir farklılaştırıcıdır; ama tek haneli 9’u bile zar zor aşıyorsanız pek anlamı kalmaz
Davranışı iyileştirmeye pek yardımcı olmaz ve teşvikleri daha kötü hale getirebilir
Buradaki süreç hatalarını düzelteceklerini söylemelerini takdir ediyorum. Yine de hızlı hareket etmekle işi sağlam yapmak arasında bir gerilim var
Genelde bu tür şeyler hava durumu gibi ele alınır; yağmurda ıslandıktan sonra yağmurluk almak gibi yönetilir
Geliştirmeyi süreçlere boğmadan güvenilirliği kültürün bir parçası haline getirmenin yolunu merak ediyorum
Sistemleri yazılımla modelleyip bu modeli trafik analiziyle doğrulamak da mümkün. Sanal deneylerle güvenilirlik deneyi maliyetini düşürebilirsek, belki yayın öncesinde daha fazlasını yakalayabiliriz
Bu yazıyı okuyunca Cloudflare’a olan güvenimin azalması garip
Flexential’ın profesyonel olmayan şekilde davrandığını güçlü biçimde öne sürüyorlar; böyle olmuş olabilir
Ama insanların bağımlı olduğu tüm sistemin çökmesi, Cloudflare tarafında devasa bir yedeklilik başarısızlığı. Böyle bir veri merkezi kaybedilse bile hizmetin sürmesi gerekir
Özellikle amaçlanan tasarımın “Cloudflare’ın kontrol düzlemi ve analiz sistemleri ağırlıklı olarak Oregon Hillsboro yakınındaki 3 veri merkezindeki sunucularda çalışır” diye başlaması endişe verici
Dünyanın her yerinden insanların kullandığı bir kontrol düzlemi için çok daha geniş coğrafi dağıtım gerekir. Bunun kusurlu bir uygulama değil de tasarımın kasıtlı bir parçası olması daha da şaşırtıcı
Tüketiciye yeni bir ürün sunuyorsanız yedeklilik tasarımının en yüksek öncelik olması gerekmez mi? Bunun isteğe bağlı bir konu olması bile şaşırtıcı
Ben de bazı sistemlerde Cloudflare kullanıyorum; çünkü böyle bir olay yaşansa bile mükemmel bir failover olacağına inanıyordum. Şimdi Cloudflare Workers’ın bu tür tasarım kararlarından gerçekten güvende olup olmadığını yeniden düşünüyorum
Felaket kurtarma sitesi açıldığında başarısız olan API çağrılarının yığılıp hizmeti boğması da, bence sonuçta Cloudflare’ın temel tasarımının yeterince yedekli olmamasından kaynaklanıyor
Sorumluluğu Flexential’a kaydırmaya çalışan bu yazı beni hayal kırıklığına uğrattı. Müşteri olarak Flexential yarın bir depremle yok olsa bile Cloudflare’ın bunu zarifçe yönetmesini beklerim
Bu kadar kritik bir kümenin tamamını bilinen bir deprem ve tsunami risk bölgesine koymak iyi bir fikir mi?
Avrupa felaket kurtarması da düzgün çalışmamış gibi görünüyor
“PDX-04 tesisinin tamamını tamamen çevrimdışına alma testi hiç yapmamıştık” ifadesi acı bir ders
Ama veri merkezinin elektriğini fiziksel olarak kapatmadıkça ya da en azından dış dünyayla ağ bağlantısını kesmedikçe gerçek bir felaketi test etmiş sayılmazsınız
Tesis işletmecisini suçlayabilirsiniz, ama sonuçta bir veri merkezi tamamen çevrimdışı kalıp bir daha hiç geri dönmese bile toparlanabilmeniz gerekir
Doğal afet o tesisi yeryüzünden silebilir
“Ekip tüm gücüyle gün boyu acil müdahale yürüttüğü için, çoğunluğun dinlenmesine ve sabah PDX-04’e geri dönüş çalışmalarına başlamasına karar verdik. Bu karar tam toparlanmayı geciktirdi, ancak ek hataların üst üste binme olasılığını azalttığına inanıyoruz” kısmı hoşuma gitti
Bu tür raporlarda insan yorgunluğu sık sık hafife alınır. Aşırı yorgun halde büyük bir kesintiyi düzeltmeye çalışmak, yalnızca kaçınılabilir hataları artırır
Cloudflare ölçeğinde bir organizasyonda nasıl işler bilmiyorum ama biz de büyük bir kesinti olduğunda çalışanların vardiyalı çalışıp uyuması için bir plana sahibiz
Sorun, uyanan veya yeni bağlanan personele mevcut kesinti durumunu devretmenin bir yoluna ihtiyaç olması
Mike Tyson’ın dediği gibi, yüzüne bir yumruk yiyene kadar herkesin bir planı vardır
Yazının yapısı oldukça şaşırtıcı. Blogun %75’ini üçüncü taraf hikâyesiyle doldurup Cloudflare’ın kendi toparlanma çabalarını çok daha az paragrafla ele alıyor
İleriye dönük yolu ortaya koymaları olumlu, ancak neden şimdi yalnızca başarısızlığı ve durumu kabul edip, toz duman dağıldıktan sonra spekülasyonsuz tam bir olay sonrası analiz yayımlamadıklarını merak ediyorum
Yatırımcılar bu yazıyı ya da özetini görüp, bunu aylarca yeniden çalışma ve milyonlarca dolar maliyet gerektiren derin bir sorun yerine basit bir tedarikçi sorunu olarak geçiştirebilir
Belge pek iyi değil
3 veri merkezli yüksek erişilebilirlik yapılandırması vardı ve tamamen başarısız oldu
Neden belgenin başı veri merkezi işletmecisini suçlamakla dolu? Veri merkezi tesis yönetimi Cloudflare’ın kontrolü dışında
Cloudflare, kontrol edebileceği yüksek erişilebilirlik yapılandırması testini doğru düzgün yapmasa da sorun çıkmayacağına dair kumar oynamış
Veri merkezi işletim sorunu işletmeciyle tartışılmalı, ama bu iki taraf arasındaki bir mesele; bu olay sonrası analize girecek bir konu değil
Önemli kısmı gerçekten derinlere gömmüşler. Epey kaydırdıktan sonra şu cümle çıkıyor:
“Yüksek erişilebilirlik kümesinde olması gereken bazı servisler, yalnızca PDX-04’te çalışan servislere bağımlıydı”
İşte asıl mesele bu
Bir “felaket” sitesi kuruyorsanız test etmenin bir yolunu bir şekilde bulmanız gerekir gibi geliyor
Servis açılınca başarısız olan API çağrılarının yığılmasıyla gök gürültüsü sürüsü sorunu yaşanmış ve istek hacmini kontrol etmek için hız sınırlaması uyguladıklarını söylüyorlar
Ama bu konu yazının sonundaki maddelerde yok gibi
Şimdi merak ettiğim şey, sistem yarı kararlı arıza[1] yaratacak kadar karmaşık olduğunda ve gerçek trafikle test edecek pay olmadığında soğuk failover’ın nasıl tasarlanacağı
Uygulamada kullanılacak teknikleri tahmin edebiliyorum, ama sorun bu tekniklerin gerçek durumda çalıştığını doğrulayacak tasarım ve test
Ayrıca tamamen atlanmış gibi görünen bir başka nokta da, arızanın 2 Kasım 11:43 UTC’de başlamasına rağmen Avrupa felaket kurtarma sitesine geçme kararının 13:40 UTC’de alınmış olması
Karar vermek neden bu kadar uzun sürdü? Hafife alınabilecek bir karar olmadığını anlıyorum, ama zamanın çoğunda elektriğin yakında geri geleceği beklense bile 2 saat fazla tereddüt edilmiş gibi görünüyor
Hangi taahhütler olursa olsun, düğmeye basılması gereken önceden belirlenmiş bir eşik olmalı. Bu eşik gerçekten bu kadar uzağa mı konmuştu?
[1] http://charap.co/metastable-failures-in-distributed-systems/
Arızaya yol açan şey çoğu zaman yedekli sistemin kendisidir