Tiga Pola Berantai Klasik

Kegagalan Merambat Melalui Ketergantungan

Pola 1: Kawanan guntur (Thundering herd). Sumber daya bersama (cache, lock, database) gagal atau di-restart. Setiap klien yang bergantung padanya melakukan ulang (retry) secara bersamaan. Banjir permintaan ini melumpuhkan apa pun yang baru pulih; penumpukan retry lebih cepat daripada kemampuan pemulihan untuk menyerapnya; pemulihan tidak pernah selesai.

Pola 2: Badai retry (Retry storm). Layanan hilir melambat. Panggilan hulu, alih-alih gagal, melakukan retry. Retry tersebut melipatgandakan beban awal. Layanan yang lambat menjadi semakin lambat, memicu lebih banyak retry. Pada akhirnya, beban tersebut melebihi kapasitas bahkan versi layanan yang sehat.

Pola 3: Antrian kematian (Queue of death). Antrian pemrosesan tanpa backpressure menerima data lebih cepat daripada yang diproses. Antrian tumbuh tanpa batas. Memori habis; konsumen crash; restart; menemukan antrian yang masih lebih besar; crash lagi.

Benang merah: gangguan awal yang kecil memicu loop umpan balik positif. Respons sistem itu sendiri justru memperkuat kegagalan alih-alih meredamnya.

Mekanisme Peredaman

Exponential backoff dengan jitter. Klien yang melakukan retry menunggu lebih lama setiap kali, dengan offset acak. Mencegah gelombang retry yang tersinkronisasi.

Circuit breaker. Pemanggil (caller) melacak tingkat kegagalan downstream. Melewati ambang batas tertentu, pemanggil berhenti memanggil selama periode pendinginan & segera membatalkan permintaannya sendiri. Mencegah pekerjaan yang terbuang, memungkinkan downstream pulih.

Bulkhead. Isolasi sumber daya per dependensi. Pool koneksi A untuk database, pool koneksi B terpisah untuk cache. Database yang lambat tidak dapat melaparkan semua koneksi; panggilan cache tetap berlanjut.

Load shedding. Saat kelebihan beban, buang permintaan di tepi (edge) alih-alih menerimanya & gagal secara lambat. 429 dalam 1 ms lebih baik daripada 500 dalam 30 detik.

Backpressure. Perlahan-lahan produsen ketika konsumen tidak mampu mengimbangi. Antrean menjadi terbatas; pengirim diblokir; sumber asli pekerjaan merasakan gesekan tersebut.

Diagnosis Kegagalan Berantai

Tier API sebuah tim runtuh selama failover database rutin. Linimasa:

- 14:00:00 — operator mempromosikan database standby. Ketersediaan yang tidak diharapkan: ~10 detik.

- 14:00:08 — primary tidak tersedia. Permintaan pada lapisan API mulai gagal dengan error koneksi database.

- 14:00:08 — lapisan API melakukan retry (konfigurasi default: 5 retry, tanpa backoff, jarak 100ms).

- 14:00:11 — standby dipromosikan, menerima koneksi baru.

- 14:00:11 — lapisan API membuka ribuan koneksi database baru secara bersamaan (setiap replika × setiap permintaan konkuren × setiap retry).

- 14:00:13 — pool koneksi primary baru habis; koneksi baru ditolak.

- 14:00:13-14:05:00 — replika lapisan API menguras pool koneksi, melempar pengecualian, crash, restart, dan mengulang.

- 14:05:00 — operator secara manual menghentikan lalu lintas lapisan API; database stabil.

- 14:10:00 — pemulihan lalu lintas bertahap selesai. Total gangguan: ~10 menit (dibandingkan perkiraan ~10 detik).

DNS SERVFAIL: Dua Cacat yang Bertumpuk

Postmortem dengan Bentuk Nyata

Berikut adalah versi yang telah disanitasi dari insiden nyata. Nama vendor diubah, IP dianonimkan; bentuknya, garis waktunya, & pelajarannya adalah nyata.

Ringkasan

Situs example.com mengembalikan SERVFAIL dari semua resolver DNS publik selama sekitar 3-4 jam. Semua 46 zona lain pada master DNS yang sama tidak terpengaruh. Akar masalah: dua cacat yang bertumpuk.

1. Vendor A (penyedia DNS sekunder) menambahkan IP sinkronisasi internal baru yang tidak ada dalam daftar izin allow-axfr-ips dari primary.

2. Zona example.com memiliki konflik CNAME yang melanggar RFC dan sudah ada sejak beberapa tahun lalu (demo.example.com memiliki record CNAME & MX/TXT pada label yang sama) yang menyebabkan Vendor A menolak zona tersebut pada AXFR baru.

Garis Waktu (UTC)

- ~15:00 — Vendor A menambahkan IP sinkronisasi baru 198.51.100.42 ke infrastruktur mereka

- 15:02 — AXFR-out denied pertama untuk 198.51.100.42 muncul di log DNS primer (tidak ada peringatan untuk sinyal ini)

- ~18:00 — jendela kedaluwarsa SOA tercapai; Vendor A menghapus zona example.com dari cache

- ~18:30 — SERVFAIL terdeteksi secara eksternal

- ~19:45 — akar masalah diidentifikasi

- 20:00 — 198.51.100.42 ditambahkan ke allow-axfr-ips; primer diulang

- 20:05 — NOTIFY dikirim; AXFR dimulai; zona MASIH SERVFAIL (konflik CNAME)

- 20:07 — check-zone mengungkapkan 1 error: konflik CNAME pada demo.example.com

- 20:09 — CNAME diganti dengan record A; pemeriksaan zona bersih (0 error)

- 20:10 — NOTIFY dikirim; AXFR selesai; Vendor A mulai menyajikan zona

- 20:11 — dig @8.8.8.8 example.com A mengembalikan IP yang benar — TERSELESAIKAN

Mengapa Hanya example.com?

Semua 47 zona berbagi DNS primer yang sama. Blokir IP AXFR memengaruhi semua zona. Namun, hanya example.com yang memiliki konflik CNAME, & hanya example.com yang membutuhkan AXFR baru pada saat penolakan diberlakukan. Zona lain sudah diperbarui sebelum penolakan atau belum membutuhkannya.

Cacat laten

Konflik CNAME di demo.example.com telah ada selama bertahun-tahun. Hal ini berfungsi karena primer menyajikan zona dari basis datanya (toleran terhadap pelanggaran RFC) & Vendor A menyajikan dari data cache kedaluwarsa dari sebelum pelanggaran diperkenalkan. Ketika Vendor A membuang cache-nya & membutuhkan data baru, pelanggaran tersebut muncul.

Pemicu

Vendor A secara diam-diam menambahkan IP sinkronisasi baru. Allowlist pada server primer tidak menyertakannya. AXFR ditolak. Tiga jam kemudian (SOA expire), Vendor A menghapus zona tersebut. Cacat laten tersebut muncul ketika sistem mencoba melakukan pemulihan.

Menulis Poin Aksi Tanpa Menyalahkan

Tanpa Menyalahkan: Sasarkan pada Sistem, Bukan Orang

Poin aksi tanpa menyalahkan (blameless) menyebutkan sesuatu yang harus dilakukan secara berbeda oleh sistem, bukan sesuatu yang harus dilakukan secara berbeda oleh orang. 'Melatih operator' bersifat menyalahkan. 'Menambahkan pemeriksaan otomatis yang menangkap hal ini sebelum deploy' bersifat tanpa menyalahkan.

Poin aksi tanpa menyalahkan yang baik mengelompok ke dalam tiga dimensi:

- Pencegahan: membuat hal buruk menjadi lebih sulit atau mustahil

- Deteksi: menyadarinya lebih awal jika terjadi

- Pemulihan: membatasi kerusakan ketika terjadi

Setiap item harus menyebutkan (1) perubahan sistem yang spesifik, (2) tim pemilik, & (3) dimensi yang dilayani.

Kompartimen yang Tenggelam Tanpa Menenggelamkan Kapal

Diadopsi dari Teknik Perkapalan

Kapal memiliki sekat kedap air (watertight bulkheads): dinding vertikal yang membagi lambung menjadi kompartemen. Satu kompartemen dapat tergenang air tanpa menenggelamkan kapal; kompartemen lain dapat rusak tanpa memengaruhi bagian sisanya.

Sistem terdistribusi meminjam istilah yang sama & ide yang sama.

Pola sekat (bulkhead pattern): isolasi sumber daya per dependensi. Layanan yang memanggil tiga API hilir menggunakan tiga pool koneksi terpisah, tiga pool thread terpisah, dan tiga anggaran retry terpisah. Hilir yang lambat atau gagal tidak dapat mengonsumsi sumber daya yang dialokasikan untuk dua lainnya.

Tanpa sekat: satu dependensi yang lambat menguras pool thread bersama; panggilan ke dependensi lain terblokir menunggu thread; seluruh layanan menjadi tidak responsif.

Dengan sekat: satu dependensi yang lambat menguras pool-nya sendiri; panggilan ke dependensi tersebut gagal dengan cepat (fail fast); panggilan ke dependensi lain tetap berjalan normal; radius ledakan (blast radius) tetap terbatas pada dependensi yang gagal.

Pemutus Sirkuit (Circuit Breakers)

Pola circuit breaker: pembungkus berstatus (stateful) di sekitar dependensi hilir yang melacak tingkat kegagalan. Tiga status:

- Tertutup (normal): panggilan diteruskan. Kegagalan dihitung.

- Terbuka (terpicu): melewati ambang batas kegagalan (misalnya, 50% kegagalan dalam 30 detik terakhir), pemutus terbuka. Panggilan gagal segera tanpa mencoba dependensi. Menghemat pemanggil dari pekerjaan yang terbuang; menghemat dependensi dari menerima beban saat tidak sehat.

- Setengah terbuka (pengujian): setelah periode pendinginan, pemutus membiarkan sebagian kecil panggilan lolos. Jika berhasil, ia kembali tertutup ke normal. Jika gagal, ia terbuka lagi untuk pendinginan berikutnya.

Insight kunci: circuit breaker mencegah usaha yang terbuang selama periode yang diketahui tidak sehat, & memberi kesempatan pada dependensi hilir untuk pulih tanpa beban yang terus-menerus.

Bulkheads membatasi radius ledakan. Circuit breakers mencegah ledakan tersebut mempertahankan dirinya.

Batasi Radius Ledakan

Layanan API Anda memanggil empat layanan hilir: Layanan Pengguna, Layanan Rekomendasi, Layanan Notifikasi, & API Pembayaran pihak ketiga. Tim telah mendengar 'Layanan Rekomendasi sedikit tidak stabil' & ingin memastikan bahwa saat layanan tersebut gagal, sisa sistem tetap sehat.

Hari ini, layanan ini menggunakan satu thread pool bersama berisi 200 thread & satu HTTP connection pool bersama. Keempat downstream bersaing untuk sumber daya ini. Tidak ada circuit breaker.

Rancang Tinjauan Mode Kegagalan

Sintesis

Anda telah belajar mengidentifikasi SPOF melalui inspeksi, mengenali pola kegagalan berantai, memisahkan pemicu dari cacat laten saat membaca pascakegagalan, menulis item aksi tanpa menyalahkan yang mencakup pencegahan / deteksi / pemulihan, & membatasi radius ledakan dengan bulkhead + circuit breaker + degradasi anggun.

Terapkan kelima hal tersebut.

Tim Anda akan meluncurkan layanan baru search.example.com yang bergantung pada tiga layanan hilir: indeks pencarian utama (index.example.com), layanan analitik (analytics.example.com), & layanan rekomendasi (recs.example.com). Tim ingin Anda memimpin 'tinjauan mode kegagalan' sebelum peluncuran.

Ke Mana Kursus Ini Berlanjut

Ke Mana Kursus Ini Berlanjut

Anda sekarang dapat mengidentifikasi SPOF, mengenali kaskade, membaca pascabencana secara produktif, menulis item aksi tanpa menyalahkan, & membatasi radius ledakan melalui desain.

Pelajaran terakhir dalam kursus ini (cs_distsys_observability_and_capacity) mengajarkan apa yang harus diukur agar Anda mengetahui masalah sedang terjadi sebelum pengguna menyadarinya. Pengecekan kesehatan, endpoint versi, empat sinyal emas di lapisan proxy, & bagaimana keputusan kapasitas lonjakan terkait kembali ke data yang diamati.

Pelajaran pendamping: geometry_of_failure_modes_and_blast_radius menurunkan sentralitas antara (node graf mana yang menjadi titik kemacetan) & min-cut (batas dari radius ledakan).

Tugas selesai. Lanjutkan.