Üç Klasik Kaskade Deseni

Başarısızlıklar Bağımlılıklar Aracılığıyla Geçer

Desen 1: Gökten Düşen Kuş Yüklü. Bir ortak kaynak (cache, kilit, veri tabanı) başarısız olur veya yeniden başlatılır. Ona bağlı her müşteri aynı anda yeniden dener. Tekrarlar kaldırmayı aşıp, geri yüklenme onları absorbe edemez; geri yüklenme asla tamamlanmaz.

Desen 2: Tekrar Fırtınası. Bir alt hizmet yavaşlar. Üstteki çağrıcılar başarısız olmayacak şekilde tekrar dener. Tekrarlar yükü katlar. Hızlı hizmet daha yavaş, daha fazla tekrar tetikler. Sonunda, hizmetin sağlıklı bir sürümü bile kaldıramayacak kadar yük artar.

Desen 3: Ölüm Kuyruğu. Bir işleme kuyruğu için geri basınç yoktur ve daha hızlı işler than kuyruğun büyümesine neden olur. Bellek tükenir; tüketici çöker; yeniden başlatılır; daha büyük bir kuyruğa rastlar; tekrar çöker.

Genel bağ: küçük bir başlangıç istilası, pozitif geri besleme döngüsü tetikler. Sistem kendi cevabı ile başarısızlığı büyüterek, dindirmez.

Dindirme Mekanizmaları

Eksponansiyel geri çekilme ile dalgalı. Tekrar eden istemcilerin her seferinde daha uzun bekleme süresi vardır, rastgele bir ekleme vardır. Sentezli geri çağrı dalgalarını önler.

Devre açıcı. Bir çağrıcı, alt hizmet başarısızlık oranını izler. Bir eşiği aştığında, bir soğutma süresi boyunca çağrıya son verir ve hemen kendi taleplerini başarısız eder. Boş işleme önler, alt hizmetin iyileşmesine izin verir.

Kumanya. Bağımlılıklar için ayrı kaynaklar izole et. Veritabanı A için bağlantı havuzu B için cache bağlantı havuzu. Yavaş bir veri tabanı diğer tüm bağlantıları starve edemez; cache çağrıları devam eder.

Yükten Azaltma. Yüklü olduğunda, kenarda istekleri reddetmek yerine yavaş bir şekilde başarısız olur. 1 milisaniyede 429 daha iyidır, 30 saniyede 500.

Geri basınç. Tüketiciler kaldıramadığında yavaş üreticiler. Kuyruklar sınırlı hale gelir; gönderenler bloke edilir; orijinal çalışma kaynağı gerilimi hisseder.

Bir Kaskade Tanımla

Bir ekip olan API katmanının, rutin bir veri tabanı failover sırasında çöktüğü görülüyor. Süreç:

- 14:00:00 — operatör, yedek veri tabanını öne çıkarıyor. Beklenen süreklilik: ~10 saniye.

- 14:00:08 — ana veri tabanı kullanılamıyor. API katmanı, veri tabanı bağlantısı hatası ile başarısız olan istekleri başlıyor.

- 14:00:08 — API katmanı, yeniden deneme (varsayılan yapılandırma: 5 deneme, geri çekilme yok, 100ms aralıklarla).

- 14:00:11 — yedek, yeni bağlantıları kabul etmeye başlıyor.

- 14:00:11 — API katmanı, her kopya × her eşzamanlı istek × her yeniden deneme için, binlerce yeni veri tabanı bağlantısı aynı anda açıyor.

- 14:00:13 — yeni ana veri tabanı'nın bağlantı havuzu tükeniyor; yeni bağlantılar reddediliyor.

- 14:00:13-14:05:00 — API katmanı kopyaları, bağlantı havuzlarını tüketiyor, hatalar fırlatıyor, yeniden başlatıyor, tekrarlıyor.

- 14:05:00 — operatör, API katmanı trafiğini manuel olarak durduruyor; veri tabanı stabilize oluyor.

- 14:10:00 — yavaşça trafiğin geri kazanımı tamamlanıyor. Toplam kesinti: ~10 dakika (beklenen ~10 saniye yerine).

DNS SERVFAIL: İki Katlanmış Güçlüğü Anlayın

Gerçek Şekil Postmortem

Aşağıda, gerçek bir olayın temizlenmiş bir sürümü bulunmaktadır. Satıcı adları değiştirildi, IP'ler anonimleştirildi; şekil, zamanlama ve dersler gerçekdir.

Özeti

Örnek.com sitesi, yaklaşık 3-4 saat boyunca tüm genel DNS çözücülerden SERVFAIL geri döndü. Aynı DNS ana bilgisayarındaki diğer 46 bölgede etkilenmedi. Neden: iki katlanmış güçlük.

1. Satıcı A (bir ikincil DNS sağlayıcısı), ana bilgisayarın allow-axfr-ips izni dışında olan yeni bir iç eşitleme IP'si ekledi.

2. Örnek.com bölgesinde, yıllar öncesine dayanan RFC'ye aykırı bir CNAME çakışması vardı (demo.example.com, aynı etikette hem CNAME hem de MX/TXT kayıtları vardı) ve bu, Satıcı A'nın yeni AXFR'yi reddetmesine neden oldu.

Zamanlamalar (UTC)

- ~15:00 — Satıcı A, altyapılarına yeni eşitleme IP'si 198.51.100.42 ekledi

- 15:02 — first AXFR-out denied for 198.51.100.42 appears in primary DNS logs (no alerting on this signal)

- ~18:00 — SOA expire window reached; Vendor A drops example.com zone from cache

- ~18:30 — SERVFAIL detected externally

- ~19:45 — root cause identified

- 20:00 — 198.51.100.42 added to allow-axfr-ips; primary restarted

- 20:05 — NOTIFY sent; AXFR initiated; zone STILL SERVFAIL (CNAME conflict)

- 20:07 — check-zone reveals 1 error: CNAME conflict on demo.example.com

- 20:09 — CNAME replaced with A record; zone check clean (0 errors)

- 20:10 — NOTIFY sent; AXFR completes; Vendor A begins serving zone

- 20:11 — dig @8.8.8.8 example.com A returns correct IP — RESOLVED

Why Only example.com?

All 47 zones share the same DNS primary. The AXFR IP block affected all zones. But only example.com had the CNAME conflict, & only example.com needed a fresh AXFR at the moment the deny was enforced. Other zones had already refreshed before the deny or did not yet need to.

Latent defect

The CNAME conflict at demo.example.com had existed for years. It worked because the primary served the zone from its database (lenient about RFC violations) & Vendor A was serving from stale cached data from before the violation was introduced. When Vendor A dropped its cache & needed fresh data, the violation surfaced.

Trigger

Vendor A silently added a new sync IP. The primary's allowlist did not include it. AXFR denied. Three hours later (SOA expire), Vendor A dropped the zone. The latent defect surfaced when the system tried to recover.

Blameless Eylem Maddeleri Yazın

Blameless: Sistemleri, Kişiler Değil

Blameless eylem maddesi, bir kişinin farklı bir şey yapması gerektiğini belirtmez, sistem farklı bir şekilde neler yapması gerektiğini belirtir. 'Operatörü eğit' suçlayıcıdır. 'Bu hatayı önceden dağıtmadan önce otomatik bir denetleyici ekleyin' suçsuzdur.

İyi blameless eylem maddeleri, üç boyut'a ayrılır:

- Önleme: Kötü şeyin zor veya imkansız olmasına yardımcı olmak

- Tespit: Olay gerçekleşirse daha erken fark etmesine yardımcı olmak

- Kurtarma: Olay gerçekleştiğinde hasarı sınırlamak

Her madde, (1) özel sistem değişikliği, (2) sahibi olan bir ekip ve (3) karşıladığı boyutu belirtmelidir.

Gemi Nasıl Sönmez

Deniz Mühendisliğinden Ödünç Alınan

Geminin içinde su geçirmez bölme duvarları bulunur: dikey duvarlar, gövdeyi bölümlere ayırır. Bir bölüm sızdırsa gemiyi batırmaz; başka biri de başarısız olursa geri kalanı etkilemez.

Dağıtılmış sistemler aynı kelimeyi ve aynı fikri kullanır.

Bölme Duvarı Şablonu: bağımlıya göre kaynakları izole et. Üç downstream API'ye çağrı yapan bir hizmet, üç ayrı bağlantı havuzu, üç ayrı işlev havuzu, üç ayrı tekrar bütçe kullanır. Aşırıya götürülen bir downstream, diğer ikisini de etkileyemez.

Bölme Duvarı Yok: bir yavaş bağımlı, paylaşımlı işlev havuzunu tüketir; diğer bağımlılıklara yönelik çağrılar bekleyen işlevler için havuzları tüketir; tüm hizmet yanıt vermez hale gelir.

Bölme Duvarı Var: bir yavaş bağımlı, kendi havuzunu tüketir; buna yönelik çağrılar hızlı bir şekilde başarısız olur; diğer bağımlılıklara yönelik çağrılar normal olarak devam eder; başarısız bağımlıya sınırlı kalır.

Devre Kesici

Devre Kesici Şablonu: bir downstream bağımlılığı sarmalayan, başarısızlık oranını takip eden bir durumlu kaporta. Üç durum vardır:

- Kapalı (normal): çağrılar geçer. Başarısızlıklar sayılır.

- Açık (çalışma): 30 saniyede başarısızlık oranı %50'yi geçirse, devre kesici açılır. Çağrılar, bağımlı sağlıksız olduğu sürece işe yaramaz; bağımlıdan gelen yükü almadan, bağımlı iyileşene kadar bekler.

- Yarı Açık (test): bir soğutma süresi sonra, devre kesici küçük bir kısmını geçirmeye izin verir. Eğer başarılı olursa, normal olarak kapanır. Eğer başarısız olursa, başka bir soğutma süresi için yeniden açılır.

Ana Fikir: devre kesici, bilinmeyen sağlıksız dönemlerde çaba harcamayı engeller ve downstream'a iyileşme şansı verir.

Bölme Duvarları patlama sınırlarını sınırlar. Devre kesiciler patlamayı sürdürülmesini engeller.

Patlama Sınırlarını Sınırla

API hizmetiniz, kullanıcı hizmeti, öneri hizmeti, bildirim hizmeti ve üçüncü taraf ödeme API'sine bağımlı dört downstream hizmeti çağırır. Takım, 'Öneri Hizmeti biraz dalgalı olduğunu duydu' ve hizmetin başarısız olduğunda sistemin geri kalanının sağlıklı kalmasını sağlamak istiyor.

Bugün hizmet, 200 thread ve tek bir paylaşımlı HTTP bağlantı havuzu kullanarak çalışır. Dört downstream da bu kaynakları paylaşır. Devre kesiciler yoktur.

Bir Hata Modu İncelemesi Tasarımı

Sendeleme

Hata modlarını inceleyerek SPOF'ları belirleyebilir, kaskadya başarısızlık desenlerini tanımlayabilirsiniz, bir postmortem okurken tetikleyiciyi sönmemiş hasardan ayırabilirsiniz, suçlamasız eylem maddeleri oluşturabilirsiniz ve önleme / algılama / geri dönüşümsüzlük arasında ayrım yapabilirsiniz ve kemerler + devre kesiciler + zarif gerileme ile patlayıcının etki alanını sınırlayabilirsiniz.

Beşini uygula.

Takım, yeni bir hizmet search.example.com başlatıyor ve bu hizmetin üç downstream hizmeti üzerine bağlıdır: birincil arama dizini (index.example.com), analiz hizmeti (analytics.example.com) ve öneri hizmeti (recs.example.com). Takım, hizmetin başlatılmasından önce bir 'hata modu incelemesi' düzenlemesini istiyor.

Bu Kursun Sonraki Adımı

Bu Kursun Sonraki Adımı

Şimdi SPOF'ları belirleyebilir, kaskadları tanımlayabilirsiniz, bir postmortem okurken verimli bir şekilde tetikleyiciyi sönmemiş hasardan ayırabilirsiniz, suçlamasız eylem maddeleri oluşturabilirsiniz ve tasarımı ile patlayıcının etki alanını sınırlayabilirsiniz.

Bu kursun (cs_distsys_observability_and_capacity) son dersinde, kullanıcıların sorunu öğrenmeden önce neyin ölçülmesi gerektiğini öğretir. Sağlık kontrolleri, sürüm uçları, proxy katmanında dört altın sinyal ve gözlemlenen verilere dayalı olarak patlama kapasitesi kararlarının nasıl bağlantılı olduğu.

Etkin ders: geometry_of_failure_modes_and_blast_radius başarısızlık modlarındaki arasında ve patlama yarıçapının sınırını belirleyen merkezi olmayanlik (graf düğümünün boğucu olduğu) ve min-cut (patlama yarıçapının sınırı) arasındaki ilişkiyi çıkarır.

Mükemmel iş çıkarmışsın. İlerle.