Pertanyaan dan kapan ini berlaku
Desain koordinator yang mengevaluasi kesehatan regional, mengalihkan lalu lintas saat aturan terpenuhi, dan memulihkan lalu lintas dengan aman setelah pemulihan. Jelaskan control plane dan data plane, sinyal, status data, persetujuan, audit, dan drill.
AWS ARC mendeskripsikan routing control sebagai switch data-plane yang andal dan menekankan bahwa mekanisme failover harus berfungsi selama bencana. Kubernetes menyoroti replika, persebaran topologi, dan anggaran disrupsi. Topik wawancara perangkat lunak Amazon menekankan penerapan pengetahuan untuk memecahkan masalah sistem.
Ini berbeda dari mendesain gateway API multi-wilayah: fokusnya adalah alur kerja keputusan dan pemulihan, termasuk positif palsu, split brain, pengejaran data (data catch-up), dan failback.
Hal yang dinilai oleh pewawancara
Mereka mencari kesehatan berbasis banyak sinyal, kontrol perutean yang tangguh, RTO/RPO dan replikasi yang eksplisit, fencing terhadap keputusan konkuren, kemampuan audit, drill, serta rencana failback yang terukur.
Pertanyaan klarifikasi sebelum menjawab
- Apa target RTO, RPO, ketersediaan, dan intervensi manusia?
- Apakah kegagalan berupa keterjangkauan regional, dependensi, latensi, deployment, atau kerusakan data?
- Apakah standby berstatus hot, warm, atau cold?
- Data apa yang direplikasi dan penulisan mana yang boleh ditolak?
- Bagaimana DNS, gateway, Anycast, atau klien menerima perutean baru?
- Siapa yang dapat mengambil alih jika otomatisasi gagal?
- Bagaimana penulisan ganda (dual writing) dicegah?
- Kondisi kesehatan dan pengejaran data apa yang menjadi syarat failback?
- Apakah cakupannya satu cloud tertentu atau desain abstrak?
Kerangka jawaban 30 detik
"Saya mendefinisikan RTO, RPO, dan kesiapan standby terlebih dahulu. Setiap wilayah menjalankan data plane-nya sendiri; koordinator hanya memublikasikan status perutean yang tervalidasi. Kesehatan menggabungkan probe bisnis, dependensi, kapasitas, dan lag replikasi dengan sinyal mirip kuorum serta peredaman (dampening). Sebelum beralih, saya membatasi (fence) atau menurunkan performa penulisan, memverifikasi ambang data standby, dan menggunakan kontrol perutean berkeandalan tinggi. Setiap perubahan status diaudit dan dapat dibatalkan (reversible). Failback menunggu kesehatan dan pengejaran data, lalu dimulai dengan sebagian kecil lalu lintas."
Jawaban mendalam, langkah demi langkah
Langkah 1: Definisikan model kegagalan dan target
Pisahkan gangguan zona, partisi regional, kegagalan dependensi, deployment yang buruk, dan kerusakan data. Petakan RTO/RPO ke biaya standby, replikasi, dan otomatisasi.
Langkah 2: Pisahkan control plane dan data plane
Data plane melayani permintaan dan mengeksekusi perutean. Control plane menghitung rekomendasi, persetujuan, dan pencatatan. Eksekusi failover tidak boleh bergantung pada control plane yang sedang tidak tersedia.
Langkah 3: Bangun keputusan kesehatan
Gabungkan keberhasilan bisnis, dependensi, latensi, lag replikasi, kapasitas, dan sinyal operator. Satu probe yang gagal menciptakan status kandidat; ambang batas yang bertahan lama melanjutkan alur kerja.
Langkah 4: Eksekusi peralihan yang aman
Gunakan status seperti ready, candidate, approved, switching, stable, dan failback. Lease atau versi fencing mencegah operasi yang konkuren. Tentukan pembatasan penulisan (write fencing), waktu peralihan maksimum, dan tindakan penghentian.
| Tahap | Pemeriksaan utama | Tindakan kegagalan |
|---|---|---|
| Ready | Ambang batas standby dan replikasi | Blokir peralihan |
| Candidate | Kegagalan multi-sinyal yang berkelanjutan | Amati atau setujui |
| Switching | Perutean, kesalahan, dan kapasitas | Jeda atau kembalikan (revert) |
| Stable | Pemulihan bisnis dan penulis tunggal | Selesai |
| Failback | Kesehatan utama dan pengejaran data | Pertahankan standby tetap aktif |
Langkah 5: Tangani konsistensi dan split brain
Pilih penulis tunggal (single writer), pengurutan global, atau resolusi konflik. Selama partisi, tolak penulisan yang tidak aman daripada menerima penulisan yang tidak dapat digabungkan di kedua wilayah. Catat titik pengalihan (cutover point) dan celah data.
Langkah 6: Sebarkan rute dan lindungi kapasitas
Jelaskan penyebaran DNS, gateway, atau edge, termasuk TTL, cache, dan percobaan ulang klien. Hangatkan (warm up) kapasitas standby dan tentukan pembatasan (throttling) serta mode degradasi.
Langkah 7: Observasi, audit, dan serah terima
Catat bukti kesehatan, versi aturan, operator, transisi status, dan hasil rute. Berikan peringatan tentang waktu peralihan, kesalahan, lag, kapasitas, dan tanda-tanda penulisan ganda. Tindakan manual harus diotorisasi dan bersifat idempoten.
Langkah 8: Drill dan failback dengan aman
Injeksi kegagalan dan uji lalu lintas secara bertahap. Sebelum failback, verifikasi kesehatan wilayah primer, pengejaran data, stabilitas dependensi, dan kapasitas. Alihkan sebagian kecil persentase terlebih dahulu dan pertahankan opsi pembalikan cepat.
Contoh jawaban berkualitas tinggi
"Saya akan mendesain dua wilayah dengan satu penulis serta RTO lima menit dan RPO tiga puluh detik. Kedua wilayah memiliki data plane lengkap; wilayah standby menjaga cache dan kapasitas tetap hangat.
Kesehatan menggabungkan keberhasilan bisnis, dependensi, lag replikasi, dan kapasitas. Tiga jendela buruk berturut-turut menciptakan kandidat; sebuah lease dan versi fencing monotonik memungkinkan hanya satu koordinator yang dapat memajukan status. Sebelum beralih, penulisan di-fence, lag standby diperiksa, dan kontrol perutean berkeandalan tinggi memindahkan lalu lintas. Kesalahan dan latensi dipantau, dengan ambang batas pembalikan langsung.
Audit menyimpan bukti, aturan, persetujuan, dan hasil rute. Drill bulanan menguji caching DNS, percobaan ulang klien, dan kapasitas standby. Failback menunggu pengejaran data, mengalihkan lima persen terlebih dahulu, dan berhenti jika penulisan ganda atau latensi muncul."
Kesalahan umum
- Menampilkan dua wilayah tanpa pemilik keputusan.
- Menggunakan satu ping atau metrik infrastruktur sebagai kesehatan bisnis.
- Mengotomatiskan tanpa fencing, dampening, persetujuan, atau pengembalian (revert).
- Mengabaikan TTL, cache, dan percobaan ulang klien.
- Mengizinkan penulisan ganda tanpa penanganan konflik.
- Melupakan pemanasan (warm-up) dan kapasitas standby.
- Membahas failover tetapi tidak membahas failback atau drill.
- Menyatakan RTO/RPO tanpa memetakan keduanya ke replikasi dan biaya.
Pertanyaan lanjutan dan cara menjawabnya
Pertanyaan lanjutan 1: Bagaimana Anda menangani positif palsu?
Gunakan banyak sinyal, jendela yang berkelanjutan, dan peredaman (dampening). Kegagalan dengan tingkat keyakinan rendah harus diamati atau didegradasi terlebih dahulu sebelum beralih.
Pertanyaan lanjutan 2: Bagaimana jika control plane mati?
Pertahankan sakelar eksekusi dan pembacaan yang diperlukan pada data plane berkeandalan tinggi, distribusikan status aman sebelumnya, dan batasi operasi manual yang diaudit.
Pertanyaan lanjutan 3: Bagaimana jika kedua wilayah menjadi primer?
Gunakan lease, fencing token, atau penengah (arbiter) eksternal. Jika kepemilikan penulis tunggal tidak pasti, tolak penulisan.
Pertanyaan lanjutan 4: Bagaimana jika kapasitas standby tidak mencukupi?
Pesan kapasitas cadangan, gunakan degradasi dan pembatasan (throttling), dan hanya terima lalu lintas penting ketika beban penuh tidak dapat dilayani.
Pertanyaan lanjutan 5: Mengapa tidak mengotomatiskan semuanya?
Otomatiskan kegagalan yang dapat dibatalkan dan memiliki keyakinan tinggi. Wajibkan konfirmasi manusia untuk kerusakan data, split brain, dan peristiwa berkeyakinan rendah.
Pertanyaan lanjutan 6: Bagaimana Anda membuktikan bahwa drill berhasil?
Lacak waktu deteksi hingga pemulihan, RPO, kesalahan, kapasitas, langkah manual, dan hasil revert; ubah setiap kekurangan menjadi perbaikan yang memiliki penanggung jawab jelas.