Gesaan dan konteks
Penemu bual bertanya: “SaaS B2B kami mereplikasi data ke dua rantau. Patutkah pelanggan dapat memicu pertukaran apabila rantau utama gagal?” Andaikan pelanggan tidak boleh mengendalikan pangkalan data asas secara langsung, dan produk mesti mengekalkan pengasingan penyewa (tenant isolation), residensi data, dan kebolehauditan. Ini sesuai untuk temu bual pengurus produk platform, pengurus produk infrastruktur, dan pengurus program teknikal.
Ujian ini adalah penetapan sempadan produk, bukan respons refleks “automasi adalah lebih pantas.” AWS meletakkan reka bentuk berbilang Rantau untuk ketahanan ekstrem tetapi memberi amaran bahawa kebergantungan rentas Rantau melemahkan postur tersebut; Google Cloud menyatakan pemulihan mesti direka bentuk, dibina, dan diuji; Azure merangka pilihan berdasarkan keperluan perniagaan, RTO, RPO, kos, dan kerumitan.
Perkara yang dinilai oleh penemu bual
- Bolehkah anda menukar “pelanggan mahukan kawalan” kepada keperluan RTO, RPO, residensi, dan pematuhan yang boleh diukur?
- Bolehkah anda membezakan pertukaran automatik platform, diluluskan oleh pengendali, dan diminta oleh pelanggan?
- Bolehkah anda menamakan mod kegagalan yang melibatkan kelengahan replikasi (replication lag), split brain, caching DNS, kuota, dan isyarat palsu?
- Jawapan yang kukuh mengehadkan operasi kepada satah kawalan (control plane) penyewa dengan semakan awal, kelulusan, latihan simulasi, audit, dan failback. Jawapan yang lemah mendedahkan butang failover mentah secara terus.
Soalan penjelasan sebelum menjawab
Apakah kegagalan yang sedang kita selesaikan?
Kegagalan aplikasi penyewa tunggal mungkin boleh dikendalikan melalui pengasingan atau mula semula; gangguan seluruh rantau adalah kes untuk pertukaran rentas Rantau. Jika keperluannya hanyalah kependaman (latency), berbilang Rantau mungkin tidak dapat mengatasi reka bentuk berbilang AZ yang lebih mudah.
Apakah RTO dan RPO?
Replikasi tak segerak (asynchronous) boleh kehilangan penulisan terbaharu. Keperluan sifar RPO tidak dapat dipenuhi dengan butang replika tak segerak biasa. RTO menentukan kapasiti sedia (warm capacity); RPO menentukan sama ada kelengahan replikasi boleh diterima.
Data manakah yang boleh meninggalkan rantau asal?
Residensi, kunci penyulitan, sandaran (backup), dan log mengubah rantau sasaran yang layak. “Rantau sekunder” tidak semestinya merupakan rantau yang mematuhi peraturan secara automatik.
Jawapan 30 saat
“Saya akan menstrukturkan pengalaman mengikut sasaran ketersediaan, kehilangan data yang boleh diterima, dan kekangan residensi bagi setiap penyewa. Platform sepatutnya bertukar secara automatik atau dengan kelulusan pengendali berdasarkan isyarat kesihatan yang kukuh; hanya penyewa yang lulus semakan awal boleh menghantar permintaan pertukaran yang diaudit, dan bukannya menaikkan taraf (promote) replika secara langsung. Permintaan itu menyemak kelengahan replikasi, kapasiti sasaran, kunci, versi, dan kebergantungan, kemudian membekukan atau mengalirkan (drain) penulisan. Selepas pertukaran, kami memantau ralat, keadaan penulisan, dan RPO, serta memulihkan operasi normal hanya selepas kriteria failback dipenuhi. Saya akan mengadakan latihan simulasi dengan set penyewa yang kecil, membandingkan masa pemulihan, pertukaran palsu, dan impak pelanggan, kemudian memutuskan sama ada mahu meluaskan akses.”
Penyelesaian langkah demi langkah
- Tentukan kontrak produk. Anggap failover serantau sebagai operasi pemulihan bencana (disaster-recovery) berskop penyewa. Nyatakan sasaran RTO, RPO maksimum, ciri yang tidak tersedia, harga, dan tanggungjawab pelanggan. Replika yang tidak dapat memenuhi kontrak tidak boleh ditunjukkan sebagai sedia.
- Cipta tiga peringkat kawalan. Automasi platform sesuai untuk isyarat kesihatan serantau yang jelas; kelulusan pengendali sesuai untuk kebergantungan dikongsi yang memberi kesan kepada perniagaan; permintaan pelanggan harus menghasilkan arahan terhad yang dinilai oleh dasar. Pelanggan tidak boleh mengedit DNS, menaikkan taraf pangkalan data, atau memainkan semula baris gilir secara langsung.
- Jalankan semakan awal. Sahkan masa mengejar replika (catch-up time), kuota sasaran, versi aplikasi, ketersediaan kunci, tunggakan baris gilir (backlog), kebergantungan luaran, dan residensi. Semakan yang gagal harus mengembalikan sebab yang boleh diambil tindakan sebelum menerima operasi.
- Lindungi autoriti penulisan. Hentikan atau alirkan penulisan dalam rantau utama, rekod kedudukan terakhir yang disahkan, dan naikkan taraf tepat satu autoriti penulisan. Dedahkan tetingkap ketidakpastian yang terhasil akibat replikasi tak segerak; “direplikasi” tidak bermakna kehilangan sifar.
- Sahkan dan lakukan failback. Gunakan transaksi sintetik untuk log masuk, bacaan, penulisan, tugas (jobs), dan audit. Pantau kadar ralat, kedudukan replikasi, usia baris gilir, dan kejayaan penyewa. Sebelum failback, kejar data dalam arah bertentangan dan latih simulasi konflik supaya pemulihan tidak menghasilkan dua penulis.
- Pilih pelancaran berperingkat. Mulakan dengan simulasi baca sahaja untuk penyewa dalaman atau yang bersedia, kemudian pertukaran yang diluluskan pengendali, dan hanya pertimbangkan automasi kemudian. Jeda pada syarat henti yang ditetapkan: pertukaran palsu, pelanggaran RPO, kapasiti sasaran tidak mencukupi, atau bukti audit yang hilang.
Jawapan model
Saya tidak akan memberikan butang mentah kepada pelanggan. Mula-mula saya akan mengesahkan sama ada mereka memerlukan RTO rentas Rantau, RPO yang boleh mereka terima, dan kekangan residensi yang dikenakan. Produk boleh mendedahkan “minta failover,” tetapi permintaan tersebut mesti melepasi semakan dasar penyewa, kedudukan replikasi, kapasiti sasaran, versi, kunci, dan kebergantungan.
Semasa pertukaran, platform membekukan atau mengalirkan penulisan dalam rantau utama, merekodkan kedudukan terakhir yang disahkan, menaikkan taraf satu replika penulisan, serta menyatakan tetingkap kehilangan yang dijangkakan dan ciri yang tidak tersedia. Selepas itu, transaksi sintetik mengesahkan bacaan, penulisan, tugas, dan audit. Kami mengukur ralat, keadaan replikasi, dan masa pemulihan bagi setiap penyewa. Failback hanya bermula selepas pengejaran arah bertentangan membuktikan tiada split brain berlaku.
Saya akan mengadakan latihan simulasi dengan penyewa dalaman, menambah kelulusan pengendali, dan mempertimbangkan automasi hanya selepas bukti kukuh diperoleh. Jika pertukaran palsu, RPO, atau semakan awal kapasiti melepasi ambang batas, nyahdayakan akses pencetus pelanggan dan kekalkan jejak audit. Ini memberikan pelanggan keterlihatan dan kawalan terhad tanpa memindahkan risiko pemulihan bencana kepada mereka.
Kesilapan biasa
- Menganggap berbilang Rantau sebagai ketersediaan automatik → mengabaikan kenaikan taraf, kebergantungan, dan failback → dokumentasikan RTO/RPO, latihan simulasi, dan failback bagi setiap komponen.
- Membiarkan pelanggan menaikkan taraf pangkalan data secara langsung → berisiko split brain atau memberi kesan rentas penyewa → dedahkan arahan penyewa yang diaudit dan dilaksanakan oleh dasar.
- Hanya menyemak kesihatan serantau → kesihatan DNS tidak membuktikan bahawa data, kunci, atau kuota sudah sedia → sertakan kedudukan replikasi, kapasiti, versi, kunci, dan kebergantungan.
- Menjanjikan sifar kehilangan data → replikasi tak segerak mempunyai tetingkap yang belum disahkan → nyatakan RPO, rekod kedudukan terakhir yang disahkan, dan tunjukkan julat potensi kehilangan.
- Melangkau failback → rantau utama yang pulih boleh menghasilkan penulisan dwi-arah dan hanyutan data (drift) → reka bentuk pengejaran arah bertentangan, pengesanan konflik, dan failback berperingkat.
Soalan susulan dan jawapan
Bagaimana jika pelanggan memerlukan sifar RPO?
Terangkan bahawa replikasi tak segerak tidak boleh menyediakan sifar RPO. Nilaikan replikasi segerak atau penulisan dwi peringkat perniagaan, kemudian kira semula kependaman, ketersediaan, kos, dan ketekalan. Jika sasaran masih tidak dapat dipenuhi, gantikannya dengan tetingkap kehilangan maksimum yang boleh diukur.
Bagaimana jika isyarat kesihatan palsu mencetuskan automasi?
Wajibkan pelbagai isyarat, tempoh minimum, dan tetingkap pembatalan oleh manusia. Bagi penyewa bernilai tinggi, masuki keadaan beku dan disemak terlebih dahulu sebelum kenaikan taraf. Rekod setiap keputusan dan selaraskan ambang batas menggunakan kadar pertukaran palsu dan masa pemulihan.
Bagaimana jika rantau sasaran tiada kapasiti selepas permintaan?
Semak awal kuota dan kapasiti, serta peruntukkan belanjawan atau pelan penskalaan automatik (autoscaling) untuk penyewa kritikal. Sekiranya gagal, kembalikan sebabnya dan kekalkan keadaan utama; jangan bertukar ke rantau yang tidak bersedia semata-mata untuk meningkatkan kadar kejayaan butang.
Bolehkah peraturan residensi diketepikan semasa gangguan?
Jangan menganggap ada pengecualian. Masukkan rantau yang dibenarkan, kunci penyulitan, dan sempadan log ke dalam kontrak serta dasar penyewa. Jika pergerakan rentas sempadan dilarang, tawarkan ketahanan berbilang AZ dalam rantau yang sama atau mod terdegradasi yang jelas.