Perintah dan konteks
Pewawancara bertanya: “SaaS B2B kami mereplikasi data ke dua region. Haruskah pelanggan dapat memicu peralihan ketika region primer mengalami kegagalan?” Asumsikan pelanggan tidak dapat mengoperasikan database dasar secara langsung, dan produk harus mempertahankan isolasi penyewa (tenant isolation), residensi data, serta kemampuan audit (auditability). Ini cocok untuk wawancara platform product manager, infrastructure product manager, dan technical program manager.
Ujian ini adalah tentang penetapan batasan produk, bukan respons refleks “otomatisasi selalu lebih cepat.” AWS memposisikan desain multi-Region untuk ketahanan ekstrem tetapi memperingatkan bahwa dependensi lintas-Region melemahkan postur tersebut; Google Cloud menyatakan bahwa pemulihan harus dirancang, dibangun, dan diuji; Azure membingkai pilihan ini di sekitar kebutuhan bisnis, RTO, RPO, biaya, dan kompleksitas.
Hal yang dievaluasi oleh pewawancara
- Dapatkah Anda mengubah “pelanggan menginginkan kendali” menjadi persyaratan RTO, RPO, residensi, dan kepatuhan yang terukur?
- Dapatkah Anda membedakan antara peralihan otomatis oleh platform, disetujui oleh operator, dan diminta oleh pelanggan?
- Dapatkah Anda menyebutkan mode kegagalan yang melibatkan keterlambatan replikasi (replication lag), split brain, caching DNS, kuota, dan sinyal palsu?
- Jawaban yang kuat membatasi operasi ke control plane penyewa dengan pra-pemeriksaan, persetujuan, gladi bersih, audit, dan failback. Jawaban yang lemah hanya mengekspos tombol failover mentah.
Pertanyaan klarifikasi sebelum menjawab
Kegagalan apa yang sedang kita selesaikan?
Kegagalan aplikasi pada penyewa tunggal dapat ditangani dengan isolasi atau restart; pemadaman total di tingkat regional adalah kasus untuk peralihan lintas-Region. Jika kebutuhannya hanya latensi, multi-Region mungkin tidak lebih baik daripada desain multi-AZ yang lebih sederhana.
Berapa RTO dan RPO-nya?
Replikasi asinkron dapat kehilangan penulisan terbaru. Persyaratan RPO nol tidak dapat dipenuhi dengan tombol replika asinkron biasa. RTO menentukan kapasitas siaga (warm capacity); RPO menentukan apakah replication lag dapat diterima.
Data mana yang boleh keluar dari region asal?
Residensi, kunci enkripsi, cadangan (backup), dan log mengubah region target yang memenuhi syarat. “Region sekunder” tidak otomatis menjadi region yang patuh regulasi.
Jawaban 30 detik
“Saya akan membuat tingkatan pengalaman berdasarkan target ketersediaan masing-masing penyewa, toleransi kehilangan data, dan batasan residensi. Platform biasanya harus beralih secara otomatis atau dengan persetujuan operator berdasarkan sinyal kesehatan yang kuat; hanya penyewa yang lolos pra-pemeriksaan yang boleh mengirimkan permintaan peralihan yang diaudit, bukan mempromosikan replika secara langsung. Permintaan tersebut memeriksa replication lag, kapasitas target, kunci, versi, dan dependensi, lalu membekukan atau menguras (drain) penulisan. Setelah peralihan, kami memantau kesalahan, status penulisan, dan RPO, serta memulihkan operasi normal hanya setelah kriteria failback terpenuhi. Saya akan melakukan gladi bersih dengan sekelompok kecil penyewa, membandingkan waktu pemulihan, peralihan palsu, dan dampak pelanggan, lalu memutuskan apakah akan memperluas akses.”
Solusi langkah demi langkah
- Tentukan kontrak produk. Perlakukan failover regional sebagai operasi pemulihan bencana (disaster-recovery) berlingkup penyewa. Nyatakan target RTO, RPO maksimum, fitur yang tidak tersedia, harga, dan tanggung jawab pelanggan. Replika yang tidak dapat memenuhi kontrak tidak boleh ditampilkan sebagai siap.
- Buat tiga tingkatan kendali. Otomatisasi platform cocok untuk sinyal kesehatan regional yang jelas; persetujuan operator cocok untuk dependensi bersama yang berdampak pada bisnis; permintaan pelanggan harus menghasilkan perintah terbatas yang dievaluasi berdasarkan kebijakan. Pelanggan tidak boleh mengedit DNS, mempromosikan database, atau memutar ulang antrean secara langsung.
- Jalankan pra-pemeriksaan. Verifikasi waktu pengejaran replika (catch-up time), kuota target, versi aplikasi, ketersediaan kunci, backlog antrean, dependensi eksternal, dan residensi. Pemeriksaan yang gagal harus mengembalikan alasan yang dapat ditindaklanjuti sebelum menerima operasi.
- Lindungi otoritas penulisan. Hentikan atau kuras penulisan di primer, catat posisi terakhir yang dikonfirmasi, dan promosikan tepat satu otoritas penulisan. Tampilkan jendela ketidakpastian yang diciptakan oleh replikasi asinkron; “terplikasi” tidak berarti nol kehilangan data.
- Verifikasi dan lakukan failback. Gunakan transaksi sintetis untuk login, pembacaan, penulisan, pekerjaan (jobs), dan audit. Pantau tingkat kesalahan, posisi replikasi, usia antrean, dan keberhasilan penyewa. Sebelum failback, lakukan pengejaran data ke arah sebaliknya dan lakukan gladi bersih penanganan konflik sehingga pemulihan tidak menciptakan dua penulis.
- Pilih peluncuran bertahap. Mulai dengan simulasi read-only untuk penyewa internal atau yang bersedia, kemudian peralihan yang disetujui operator, dan baru kemudian pertimbangkan otomatisasi. Jeda pada kondisi penghentian yang ditentukan: peralihan palsu, pelanggaran RPO, kapasitas target tidak mencukupi, atau bukti audit yang hilang.
Jawaban model
Saya tidak akan memberikan tombol mentah kepada pelanggan. Pertama, saya akan mengonfirmasi apakah mereka memerlukan RTO lintas-Region, RPO apa yang dapat mereka terima, dan batasan residensi apa yang berlaku. Produk dapat mengekspos “minta failover”, tetapi permintaan tersebut harus lolos pemeriksaan kebijakan penyewa, posisi replikasi, kapasitas target, versi, kunci, dan dependensi.
Selama peralihan, platform membekukan atau menguras penulisan di primer, mencatat posisi terakhir yang dikonfirmasi, mempromosikan satu replika penulisan, dan menyatakan estimasi jendela kehilangan serta fitur yang tidak tersedia. Setelah itu, transaksi sintetis memverifikasi pembacaan, penulisan, pekerjaan, dan audit. Kami mengukur kesalahan, status replikasi, dan waktu pemulihan per penyewa. Failback baru dimulai setelah pengejaran arah balik membuktikan tidak ada split brain.
Saya akan melakukan gladi bersih dengan penyewa internal, menambahkan persetujuan operator, dan mempertimbangkan otomatisasi hanya setelah buktinya kuat. Jika peralihan palsu, RPO, atau pra-pemeriksaan kapasitas melampaui ambang batas, nonaktifkan akses yang dipicu pelanggan dan pertahankan jejak audit. Hal ini memberi pelanggan visibilitas dan kendali terbatas tanpa membebankan risiko pemulihan bencana kepada mereka.
Kesalahan umum
- Menganggap multi-Region sebagai ketersediaan otomatis → mengabaikan promosi, dependensi, dan failback → dokumentasikan RTO/RPO, gladi bersih, dan failback per komponen.
- Membiarkan pelanggan mempromosikan database secara langsung → berisiko split brain atau berdampak lintas penyewa → ekspos perintah penyewa yang diaudit dan dieksekusi oleh kebijakan.
- Hanya memeriksa kesehatan regional → kesehatan DNS tidak membuktikan bahwa data, kunci, atau kuota sudah siap → sertakan posisi replikasi, kapasitas, versi, kunci, dan dependensi.
- Menjanjikan nol kehilangan data → replikasi asinkron memiliki jendela yang belum dikonfirmasi → nyatakan RPO, catat posisi terakhir yang dikonfirmasi, dan tunjukkan potensi rentang kehilangan data.
- Melewatkan failback → primer yang pulih dapat menciptakan penulisan ganda dan pergeseran data (drift) → rancang pengejaran arah balik, deteksi konflik, dan failback bertahap.
Tindak lanjut dan tanggapan
Bagaimana jika pelanggan membutuhkan RPO nol?
Jelaskan bahwa replikasi asinkron tidak dapat menyediakan RPO nol. Evaluasi replikasi sinkron atau penulisan ganda tingkat bisnis, lalu hitung ulang latensi, ketersediaan, biaya, dan konsistensi. Jika target masih tidak dapat dipenuhi, ganti dengan jendela kehilangan maksimum yang terukur.
Bagaimana jika sinyal kesehatan palsu memicu otomatisasi?
Wajibkan banyak sinyal, durasi minimum, dan jendela pembatalan manual oleh manusia. Untuk penyewa bernilai tinggi, masuk ke status beku dan terverifikasi sebelum promosi. Catat setiap keputusan dan sesuaikan ambang batas menggunakan tingkat peralihan palsu dan waktu pemulihan.
Bagaimana jika region target tidak memiliki kapasitas setelah permintaan?
Lakukan pra-pemeriksaan kuota dan kapasitas, serta cadangkan anggaran atau rencana autoscaling untuk penyewa kritis. Jika gagal, kembalikan alasannya dan pertahankan status primer; jangan beralih ke region yang belum siap hanya untuk meningkatkan tingkat keberhasilan penekanan tombol.
Bisakah aturan residensi dikesampingkan selama pemadaman?
Jangan mengasumsikan adanya pengecualian. Cantumkan region yang diizinkan, kunci enkripsi, dan batasan log dalam kontrak serta kebijakan penyewa. Jika pergerakan lintas batas dilarang, tawarkan ketahanan multi-AZ di region yang sama atau mode terdegradasi yang eksplisit.