Soalan dan skop
Reka bentuk pemulihan untuk SaaS satu wilayah selepas gangguan di seluruh wilayah. Perniagaan memerlukan kehilangan data maksimum satu jam (RPO) dan pemulihan perkhidmatan dalam tempoh empat jam (RTO). Andaikan 1,000 permintaan sesaat pada waktu puncak adalah andaian temu ramah, bukan fakta pengeluaran yang diukur; aplikasi adalah tanpa status (stateless), pangkalan data utama adalah hubungan (relational), dan storan objek mengandungi muat naik pengguna.
Reka bentuk mesti memulihkan data, kod aplikasi, konfigurasi, rahsia (secrets), penghalaan, dan akses pengendali. Ia juga mesti menghalang pangkalan data utama yang rosak daripada disalin secara membabi buta ke dalam wilayah pemulihan. "Kami mempunyai sandaran" bukanlah jawapan yang lengkap: kekerapan sandaran, masa pemulihan, autoriti failover, dan bukti daripada latih tubi mesti sepadan dengan objektif.
Perkara yang diuji oleh penemu ramah
Buku panduan temu ramah reka bentuk sistem membingkaikan pemulihan bencana sebagai masalah RPO/RTO gaya temu ramah dan mengharapkan domain kegagalan yang jelas, pilihan pemulihan, dan bukti operasi. AWS mentakrifkan RPO dan RTO sebagai objektif pemulihan yang ditetapkan oleh keperluan perniagaan, kemudian mengesyorkan strategi yang ditetapkan, ujian, pengurusan hanyutan konfigurasi (drift), dan automasi.
Jawapan yang kukuh:
- menterjemahkan RPO kepada kekerapan replikasi atau sandaran dan mengukur lat (lag);
- menterjemahkan RTO kepada belanjawan pemulihan, kenaikan pangkat (promotion), penggunaan (deployment), penghalaan, dan pengesahan;
- memisahkan pemulihan satah data daripada tindakan satah kawalan yang mungkin tidak tersedia;
- memilih pilot light, warm standby, atau aktif/aktif berdasarkan kos dan sasaran, dan bukannya menamakan multi-region secara lalai;
- melatih pemulihan dan failover, termasuk data yang rosak dan konfigurasi lapuk.
Soalan penjelasan sebelum menjawab
- Adakah RPO terpakai sama rata untuk pembayaran, profil, dan muat naik? Penggredan (tiering) boleh memberikan rekod kritikal objektif yang lebih ketat berbanding analitik.
- Adakah bencana itu kehilangan wilayah, penggunaan kod yang tidak elok, atau kerosakan logikal? Replikasi membantu kes pertama tetapi boleh menyalin kes kedua; sandaran titik-dalam-masa (point-in-time) diperlukan untuk pengunduran (rollback).
- Adakah penulisan mesti diteruskan semasa failover? Jika ya, pilih autoriti penulisan dan dasar konflik; jika tidak, tetingkap pemulihan baca sahaja memudahkan ketepatan.
- Adakah RTO empat jam diukur berdasarkan kejayaan pemeriksaan kesihatan, trafik pelanggan, atau pariti ciri penuh? Runbook mesti menamakan pencapaian tersebut.
- Bolehkah akaun pemulihan dan satah kawalan dikendalikan secara bebas? Kuota yang diperuntukkan lebih awal, kelayakan, imej, dan akses DNS boleh menentukan sama ada sasaran boleh dicapai.
Rangka kerja jawapan 30 saat
"Saya akan membahagikan beban kerja mengikut tahap (tier), menjadikan RPO/RTO perniagaan boleh diukur, dan menggunakan pangkalan data rentas wilayah dan replikasi objek tak segerak berserta sandaran titik-dalam-masa. Wilayah pilot-light dengan infrastruktur-sebagai-kod sesuai dengan RTO empat jam jika pemulihan dan promosi kekal dalam belanjawan. Runbook menaikkan titik data yang diketahui baik, menggunakan aplikasi, menukar penghalaan, menjalankan pemeriksaan integriti dan ujian asap (smoke checks), serta menyampaikan status. Latih tubi suku tahunan mengukur setiap langkah, mengesahkan pemulihan sandaran, mengesan hanyutan konfigurasi, dan mengemas kini objektif jika pemulihan yang diukur tidak lagi sesuai."
Jawapan mendalam langkah demi langkah
1. Tukar objektif kepada belanjawan pemulihan
Untuk RPO ≤ 1 jam, lat replikasi atau selang sandaran maksimum yang diterima ialah satu jam. Tetapkan amaran di bawah had tersebut, contohnya apabila lat menghampiri 45 minit, dan simpan snapshot titik-dalam-masa untuk pulih daripada kerosakan data. Jangan mendakwa kekerapan replikasi sejagat; ukur beban kerja sumber dan pilih margin.
Untuk RTO ≤ 4 jam, peruntukkan belanjawan yang konkrit: pengesanan dan pengisytiharan, promosi data, penggunaan aplikasi, penghalaan, ujian asap, dan simpanan kecemasan. Jika runbook memerlukan 20 minit untuk memulihkan pangkalan data, 30 minit untuk menggunakan imej, dan 10 minit untuk menukar trafik, itu adalah andaian yang perlu disahkan dalam latih tubi, bukan jaminan.
2. Pilih topologi pemulihan
Sandaran dan pemulihan adalah paling murah tetapi memerlukan pembinaan semula infrastruktur dan biasanya mempunyai RTO terbesar. Pilot light memastikan data yang direplikasi dan sumber pemulihan teras sentiasa sedia sementara kapasiti aplikasi dimatikan; ia adalah titik permulaan yang munasabah untuk sasaran empat jam. Warm standby memastikan tindanan berfungsi berskala kecil terus berjalan dan memendekkan pemulihan pada kos yang lebih tinggi. Aktif/aktif meminimumkan masa failover tetapi menambah konflik penulisan rentas wilayah, kerumitan stereng trafik, dan permukaan operasi terbesar.
Pilihan mengikut objektif: jangan bayar kos aktif/aktif untuk sasaran empat jam melainkan impak perniagaan mewajarkannya. Simpan infrastruktur-sebagai-kod, imej kontena, skema, dan konfigurasi yang diverikan dalam akaun pemulihan supaya penggunaan boleh dihasilkan semula.
3. Lindungi dan pulihkan data
Replikasi perubahan hubungan secara tak segerak ke wilayah yang berasingan dan pantau lat. Naikkan hanya replika yang kedudukan log dan pemeriksaan integritinya memenuhi RPO. Simpan sandaran titik-dalam-masa yang tidak boleh diubah (immutable) dalam akaun atau wilayah yang berasingan untuk mengendalikan pemadaman yang tidak disengajakan, perisian tebusan (ransomware), dan penulisan yang rosak. Replikasi data objek dengan pemverian dan sahkan kiraan objek serta checksum.
Runbook merekodkan cap masa pemulihan yang dipilih, membekukan atau mengalirkan keluar (drain) penulisan apabila perlu, mempromosikan stor data, dan menyelaraskan sebarang kehilangan penulisan yang diterima. Jika rekod pembayaran memerlukan sifar kehilangan data, ia memerlukan tahap yang berbeza dan mungkin replikasi segerak; jangan mendakwa objektif satu jam merangkumi setiap domain.
4. Pulihkan laluan penyampaian (serving path)
Gunakan aplikasi daripada imej tidak boleh diubah dan kod infrastruktur. Pra-cipta pemeriksaan kesihatan DNS atau penghalaan global, akses rahsia, kuota perkhidmatan, dan kebolehcerapan di wilayah pemulihan. Salurkan trafik hanya selepas ketersambungan pangkalan data, migrasi, pengesahan, dan ujian asap baca/tulis yang representatif lulus.
Pastikan laluan kawalan failover adalah minimum. AWS menyatakan bahawa operasi satah data biasanya lebih tersedia daripada operasi satah kawalan semasa bencana; reka bentuk yang bergantung pada penciptaan setiap sumber melalui satah kawalan selepas gangguan mungkin terlepas RTO sasaran.
5. Jadikan runbook selamat untuk dilaksanakan
Tentukan siapa yang boleh mengisytiharkan bencana, siapa yang mempromosikan data, dan siapa yang meluluskan trafik. Gunakan log langkah monotonik dengan arahan idempoten untuk setiap tindakan, syarat henti, dan pelan rollback atau failback. Terbitkan kemas kini status pelanggan sebelum dan selepas perubahan penghalaan. Semasa pemulihan, lumpuhkan ciri bukan kritikal jika kapasiti berkurangan dan kekalkan jejak audit titik pemulihan yang dipilih.
6. Sahkan dengan latih tubi dan metrik
Jalankan ujian pemulihan berjadual, regional game days, dan pemeriksaan hanyutan konfigurasi. Ukur tempoh pengesanan, keputusan, pemulihan, promosi, penggunaan, penghalaan, ujian asap, dan penstabilan secara berasingan. Sahkan kiraan baris yang dipulihkan, checksum, kebenaran, baris gilir (queues), dan kerja latar belakang. Suntik sandaran yang gagal, rahsia lapuk, kuota yang tidak mencukupi, dan lat replika separa; setiap satu harus menghasilkan amaran yang boleh diambil tindakan atau penghentian yang didokumenkan.
Ujian penerimaan adalah bukti: RPO dan RTO yang diukur dalam latih tubi terkini, jurang yang belum diselesaikan, dan pemilik tindakan. Dokumen tanpa pemulihan hanyalah hipotesis.
Contoh jawapan berkualiti tinggi
"Untuk RPO satu jam dan RTO empat jam, saya akan menggunakan pangkalan data rentas wilayah dan replikasi objek tak segerak, sandaran titik-dalam-masa yang tidak boleh diubah, dan wilayah pilot-light yang diuruskan oleh infrastruktur-sebagai-kod. Saya akan memperuntukkan masa untuk pengesanan, promosi data, penggunaan aplikasi, DNS atau penghalaan global, dan ujian asap, kemudian membuktikan masa tersebut dalam latih tubi suku tahunan. Runbook failover memilih titik pemulihan yang diketahui baik, mempromosikan hanya selepas pemeriksaan integriti, menggunakan imej yang tidak boleh diubah, mengesahkan pengesahan dan penulisan representatif, dan kemudian mengalihkan trafik. Jika utama mempunyai kerosakan logikal, replikasi sahaja tidak selamat, jadi runbook memulihkan titik masa yang lebih awal. Data pembayaran kritikal akan menjadi tahap berasingan dengan objektif yang lebih ketat. Saya akan melaporkan lat yang diukur, tempoh pemulihan, penemuan hanyutan, dan pemilik pembetulan seterusnya."
Kesilapan biasa
- Menyebut "multi-region" tanpa objektif → kos dan kerumitan tidak terhad → terbitkan topologi daripada RPO/RTO dan tahap perkhidmatan.
- Menganggap replikasi sebagai sandaran → kerosakan atau pemadaman boleh mereplikasi serta-merta → simpan salinan titik-dalam-masa yang tidak boleh diubah dan uji pemulihan.
- Mengabaikan kod dan konfigurasi → data yang dipulihkan tidak mempunyai tindanan penyampaian → versi imej, skema, akses rahsia, kuota, dan IaC dalam akaun pemulihan.
- Mengira perubahan DNS sebagai pemulihan → trafik sampai ke sistem yang tidak sihat atau tidak disahkan → sertakan promosi, ujian asap, dan penstabilan dalam RTO.
- Bergantung pada satah kawalan yang tidak tersedia → automasi tidak dapat mencipta sasaran semasa gangguan → pra-peruntukkan sumber pemulihan kritikal dan latih laluannya.
- Tidak pernah menjalankan latih tubi → sandaran, kuota, dan runbook boleh menjadi lapuk → ukur pemulihan dan failover secara kerap dengan suntikan kegagalan.
Soalan susulan dan jawapan
Apakah yang berubah untuk RPO sifar?
Replikasi tak segerak tidak lagi memenuhi sasaran. Tentukan autoriti penulisan segerak atau terima penghentian penulisan di peringkat produk; kemudian nilai semula kependaman (latency), kuorum, dan tingkah laku pemisahan wilayah.
Bagaimanakah anda pulih daripada kerosakan logikal?
Hentikan promosi replika yang rosak, kenal pasti sandaran titik-dalam-masa yang bersih, pulihkan ke dalam persekitaran yang terpencil, sahkan invariat, dan mainkan semula (replay) hanya perubahan yang diluluskan. Wilayah yang sihat tidak membuktikan data yang sihat.
Mengapa memilih pilot light berbanding warm standby?
Pilot light mengurangkan kos keadaan mantap dan sesuai dengan sasaran empat jam apabila penggunaan dan peningkatan skala diukur. Warm standby wajar apabila belanjawan RTO tidak dapat menyerap masa peruntukan atau apabila trafik kapasiti terhad mesti bermula serta-merta.
Bagaimanakah anda menghalang hanyutan konfigurasi?
Hasilkan wilayah pemulihan daripada IaC yang diverikan, bandingkan sumber yang diingini dan yang diperhatikan, beri amaran tentang perbezaan imej, skema, rahsia, kuota, dan penghalaan, serta sertakan pemeriksaan hanyutan dalam setiap latih tubi.