Panduan perencanaan pemulihan dari bencana

Last reviewed 2023-11-22 UTC

Dokumen ini adalah bagian pertama dari rangkaian yang membahas pemulihan bencana (DR) di Google Cloud. Bagian ini memberikan ringkasan proses perencanaan DR: hal yang perlu Anda ketahui untuk merancang dan mengimplementasikan rencana DR. Bagian berikutnya membahas kasus penggunaan DR tertentu dengan contoh implementasi di Google Cloud.

Rangkaian ini terdiri dari bagian berikut:

Pengantar

Peristiwa yang mengganggu layanan dapat terjadi kapan saja. Jaringan Anda mungkin mengalami pemadaman, push aplikasi terbaru mungkin menyebabkan bug kritis, atau Anda mungkin harus menghadapi bencana alam. Jika segala sesuatu menjadi kacau, penting untuk memiliki rencana DR yang kuat, bertarget, dan teruji dengan baik.

Dengan menerapkan rencana DR yang dirancang dengan baik dan teruji dengan baik, Anda dapat memastikan bahwa jika terjadi bencana, dampak pada penghasilan bisnis Anda akan minimal. Apa pun kebutuhan DR Anda, Google Cloud memiliki pilihan produk dan fitur yang andal, fleksibel, dan hemat biaya yang dapat Anda gunakan untuk membuat atau meningkatkan solusi yang tepat untuk Anda.

Dasar-dasar perencanaan DR

DR adalah bagian dari business continuity planning. Perencanaan DR dimulai dengan analisis dampak bisnis yang mendefinisikan dua metrik utama:

  • Batas waktu pemulihan (RTO), yang merupakan durasi maksimum aplikasi yang dapat diterima untuk offline. Nilai ini biasanya didefinisikan sebagai bagian dari perjanjian tingkat layanan (SLA) yang lebih besar.
  • Toleransi jumlah data yang hilang (RPO), yaitu jangka waktu maksimum yang dapat diterima saat data yang mungkin hilang dari aplikasi Anda karena suatu insiden besar. Metrik ini bervariasi berdasarkan cara penggunaan datanya. Misalnya, data pengguna yang sering dimodifikasi dapat memiliki RPO yang hanya beberapa menit. Sebaliknya, data yang kurang penting dan jarang dimodifikasi dapat memiliki RPO selama beberapa jam. (Metrik ini hanya menjelaskan durasi waktu; tidak membahas jumlah atau kualitas data yang hilang.)

Biasanya, semakin kecil nilai RTO dan RPO Anda (yaitu, semakin cepat aplikasi Anda harus pulih dari gangguan), semakin besar biaya untuk menjalankan aplikasi Anda. Grafik berikut menunjukkan rasio biaya terhadap RTO/RPO.

Grafik yang menunjukkan bahwa RTO/RPO yang kecil memetakan ke biaya tinggi.

Karena nilai RTO dan RPO yang lebih kecil sering kali mengindikasikan kompleksitas yang lebih besar, overhead administratif terkait akan mengikuti kurva yang serupa. Aplikasi dengan ketersediaan tinggi mungkin mengharuskan Anda untuk mengelola distribusi antara dua pusat data yang terpisah secara fisik, mengelola replikasi, dan banyak lagi.

Nilai RTO dan RPO biasanya digabungkan ke metrik lain: tujuan tingkat layanan (SLO), yang merupakan elemen terukur utama dari SLA. SLA dan SLO sering kali digabungkan. SLA adalah keseluruhan perjanjian yang menentukan layanan yang akan diberikan, cara layanan didukung, waktu, lokasi, biaya, performa, penalti, dan tanggung jawab para pihak yang terlibat. SLO adalah karakteristik SLA yang spesifik dan terukur, seperti ketersediaan, throughput, frekuensi, waktu respons, atau kualitas. SLA dapat berisi banyak SLO. RTO dan RPO dapat diukur dan dianggap sebagai SLO.

Anda dapat membaca SLO and SLA lebih lanjut di buku Site Reliability Engineering Google.

Anda mungkin juga merencanakan arsitektur untuk ketersediaan tinggi (HA). HA tidak sepenuhnya tumpang tindih dengan DR, tetapi sering kali perlu mempertimbangkan HA saat Anda memikirkan nilai RTO dan RPO. HA membantu memastikan tingkat performa operasional, biasanya waktu beroperasi, untuk periode yang lebih tinggi dari biasanya. Saat menjalankan workload produksi di Google Cloud, Anda dapat menggunakan sistem yang didistribusikan secara global. Jadi, jika terjadi masalah di satu region, aplikasi akan terus menyediakan layanan meskipun layanannya kurang luas. Intinya, aplikasi tersebut memanggil rencana DR-nya.

Mengapa Google Cloud?

Google Cloud dapat mengurangi biaya yang terkait dengan RTO and RPO secara signifikan jika dibandingkan dengan memenuhi persyaratan RTO dan RPO secara lokal. Misalnya, perencanaan DR tradisional mengharuskan Anda untuk memperhitungkan sejumlah persyaratan, termasuk hal berikut:

  • Kapasitas: mengamankan resource yang cukup untuk diskalakan sesuai kebutuhan.
  • Keamanan: memberikan keamanan fisik untuk melindungi aset.
  • Network infrastructure: mencakup komponen software seperti firewall dan load balancer.
  • Dukungan: menyediakan teknisi terampil untuk melakukan pemeliharaan dan mengatasi masalah.
  • Bandwidth: merencanakan bandwidth yang sesuai untuk beban puncak.
  • Fasilitas: memastikan infrastruktur fisik, termasuk peralatan dan daya.

Dengan menyediakan solusi yang sangat terkelola pada platform produksi kelas dunia, Google Cloud membantu Anda mengabaikan sebagian besar atau semua faktor rumit ini, sehingga menghilangkan banyak biaya bisnis dalam prosesnya. Selain itu, fokus Google Cloud pada kesederhanaan administratif juga mengurangi biaya pengelolaan aplikasi yang kompleks.

Google Cloud menawarkan beberapa fitur yang relevan dengan perencanaan DR, termasuk:

  • Jaringan global. Google memiliki salah satu jaringan komputer terbesar dan tercanggih di dunia. Jaringan backbone Google menggunakan jaringan canggih yang ditetapkan untuk software dan layanan edge caching untuk menghadirkan performa yang cepat, konsisten, dan skalabel.
  • Redundansi Banyak titik kehadiran (PoP) di seluruh dunia berarti redundansi yang kuat. Data Anda dicerminkan secara otomatis di seluruh perangka penyimpanan di beberapa lokasi.
  • Skalabilitas. Google Cloud dirancang agar dapat diskalakan seperti produk Google lainnya (misalnya, penelusuran dan Gmail), bahkan saat Anda mengalami lonjakan traffic yang besar. Layanan terkelola seperti App Engine Autocaler Compute Engine, dan Datastore memberi Anda penskalaan otomatis yang memungkinkan aplikasi Anda tumbuh dan menyusut sesuai kebutuhan.
  • Keamanan. Model keamanan Google dibangun berdasarkan pengalaman lebih dari 15 tahun dalam membantu menjaga keamanan pelanggan di aplikasi Google seperti Gmail dan Google Workspace. Selain itu, tim site reliability engineering di Google membantu memastikan ketersediaan tinggi dan mencegah penyalahgunaan resource platform.
  • Kepatuhan. Google melakukan audit pihak ketiga independen secara rutin untuk memverifikasi bahwa Google Cloud selaras dengan peraturan keamanan, privasi, dan kepatuhan, serta praktik terbaik. Google Cloud mematuhi sertifikasi seperti ISO 27001, SOC 2/3, dan PCI DSS 3.0.

Pola DR

Pola DR dianggap dingin, hangat, atau panas. Pola-pola ini menunjukkan seberapa mudah sistem dapat pulih ketika terjadi kesalahan. Sebuah analogi yang mungkin adalah apa yang akan Anda lakukan jika Anda mengemudi dan ban mobil Anda bocor.

3 foto skenario ban kempes pada mobil: tidak ada cadangan; alat tambahan; ban kempes.

Cara Anda menangani ban kempes bergantung pada kesiapan Anda:

  • Dingin: Anda tidak memiliki ban cadangan, jadi Anda harus menelepon seseorang untuk datang dengan membawa ban baru dan menggantinya. Perjalanan Anda berhenti hingga bantuan tiba untuk melakukan perbaikan.
  • Hangat: Anda memiliki ban cadangan dan kit pengganti, sehingga Anda dapat kembali menggunakan mobil yang Anda miliki. Namun, Anda harus menghentikan perjalanan untuk memperbaiki masalah tersebut.
  • Panas: Anda memiliki ban kempes. Anda mungkin perlu sedikit memperlambat tetapi tidak ada dampak langsung pada perjalanan Anda. Ban Anda berjalan cukup baik sehingga Anda dapat melanjutkan perjalanan (meskipun Anda pada akhirnya harus mengatasi masalah tersebut).

Membuat rencana DR terperinci

Bagian ini memberikan Anda rekomendasi tentang cara membuat rencana DR.

Mendesain sesuai dengan tujuan pemulihan Anda

Saat mendesain rencana DR, Anda perlu menggabungkan aplikasi dan data teknik pemulihan serta melihat gambaran yang lebih besar. Cara umum untuk melakukannya adalah dengan melihat nilai RTO dan RPO Anda, serta pola DR mana yang dapat Anda gunakan untuk memenuhi nilai tersebut. Misalnya, dalam kasus data yang berorientasi pada kepatuhan historis, Anda mungkin tidak memerlukan akses cepat ke data tersebut, jadi nilai RTO yang besar dan dingin pola DR adalah pilihan yang tepat. Namun, jika layanan online Anda mengalami gangguan, Anda pasti ingin dapat memulihkan data dan aplikasi yang berhubungan langsung dengan pelanggan secepat mungkin. Dalam hal ini, pola panas akan lebih tepat. Sistem notifikasi email Anda, yang biasanya tidak penting bagi bisnis, mungkin merupakan kandidat untuk pola yang hangat.

Untuk mendapatkan panduan cara menggunakan Google Cloud untuk mengatasi skenario DR umum, tinjau skenario pemulihan aplikasi. Skenario ini memberikan strategi DR untuk berbagai kasus penggunaan dan penawaran contoh Google Cloud untuk masing-masing kasus.

Desain untuk pemulihan end-to-end

Tidaklah cukup hanya memiliki rencana untuk mencadangkan atau mengarsipkan data Anda . Pastikan rencana DR Anda menangani seluruh proses pemulihan, mulai dari pencadangan, pemulihan, hingga pembersihan. Kami membahas hal ini dalam dokumen tentang data dan pemulihan DR.

Buat tugas Anda spesifik

Saat tiba waktunya untuk menjalankan rencana DR, Anda tidak ingin terjebak dalam menebak arti dari setiap langkah. Buat setiap tugas dalam rencana DR Anda terdiri dari satu atau beberapa perintah atau tindakan yang jelas dan tidak ambigu. Misalnya, "Jalankan skrip pemulihan" ini terlalu umum. Sebaliknya, "Buka Bash dan jalankan /home/example/restore.sh" adalah hal yang tepat dan konkret.

Melakukan langkah-langkah pengendalian

Menambahkan kontrol untuk mencegah terjadinya bencana dan mendeteksi masalah sebelum terjadi. Misalnya, menambahkan monitor yang mengirim pemberitahuan saat aliran penghancuran data, seperti pipa penghapusan, menunjukkan lonjakan tidak terduga atau aktivitas tidak biasa lainnya. Monitor ini juga dapat menghentikan pipa proses jika ambang batas penghapusan tertentu tercapai, sehingga mencegah situasi bencana.

Mempersiapkan software Anda

Bagian dari perencanaan DR Anda adalah memastikan bahwa software yang Anda andalkan siap untuk peristiwa pemulihan.

Memastikan bahwa Anda dapat menginstal software Anda

Pastikan aplikasi software Anda dapat diinstal dari sumber atau dari gambar yang telah dikonfigurasi sebelumnya. Pastikan Anda memiliki lisensi yang sesuai untuk setiap software yang akan di-deploy di Google Cloud. hubungi penyedia software untuk mendapatkan panduan.

Pastikan resource Compute Engine yang diperlukan tersedia di lingkungan pemulihan. Hal ini mungkin memerlukan pengalokasian instance atau reservasi mereka.

Mendesain deployment berkelanjutan untuk pemulihan

Kumpulan alat berkelanjutan deployment (CD) merupakan komponen tak terpisahkan saat Anda men-deploy aplikasi. Sebagai bagian dari rencana pemulihan, Anda harus mempertimbangkan tempat untuk men-deploy artefak di lingkungan yang dipulihkan. Rencanakan dimana Anda ingin menghosting lingkungan dan artefak CD, semua harus tersedia dan beroperasi jika terjadi bencana.

Menerapkan kontrol keamanan dan kepatuhan

Saat Anda merancang rencana DR, keamanan adalah hal penting. Kontrol yang sama dengan yang Anda miliki di lingkungan produksi harus diterapkan ke lingkungan yang dipulihkan. Peraturan kepatuhan juga akan berlaku untuk lingkungan yang Anda pulihkan.

Mengonfigurasi keamanan yang sama untuk DR dan lingkungan produksi

Pastikan kontrol jaringan Anda menyediakan pemisahan dan pemblokiran yang sama dengan yang digunakan lingkungan produksi sumber. Pelajari cara mengonfigurasi VPC Bersama dan firewall agar Anda dapat membuat jaringan terpusat dan kontrol keamanan deployment Anda, mengonfigurasi subnet, mengontrol traffic masuk dan keluar, dan sebagainya. Pahami cara menggunakan akun layanan untuk menerapkan hak istimewa terendah pada aplikasi yang mengakses Google Cloud API. Pastikan menggunakan akun layanan sebagai bagian dari aturan firewall.

Pastikan Anda memberi pengguna akses yang sama ke lingkungan DR seperti yang mereka miliki di lingkungan produksi sumber. Daftar berikut menguraikan cara-cara menyinkronkan izin antarlingkungan:

  • Jika lingkungan produksi Anda adalah Google Cloud, mereplikasi kebijakan IAM di lingkungan DR menjadi mudah. Anda dapat menggunakan alat infrastruktur sebagai kode (IaC) seperti Terraform untuk men-deploy kebijakan IAM ke produksi. Anda kemudian menggunakan alat yang sama untuk mengikat kebijakan ke resource yang sesuai di lingkungan DR sebagai bagian dari proses mempersiapkan lingkungan DR Anda.

  • Jika lingkungan produksi Anda berada di infrastruktur lokal, Anda dapat memetakan peran fungsional, seperti peran auditor dan administrator jaringan, hingga kebijakan IAM yang memiliki peran IAM yang sesuai. Dokumentasi IAM memiliki beberapa contoh konfigurasi peran fungsional Misalnya, lihat dokumentasi untuk membuat jejaring dan logging audit peran fungsional.

  • Anda harus mengonfigurasi kebijakan IAM untuk memberikan izin yang sesuai ke produk. Misalnya, Anda dapat membatasi akses ke bucket Cloud Storage tertentu.

  • Jika lingkungan produksi Anda adalah penyedia cloud lain, petakan izin di kebijakan IAM penyedia lain ke kebijakan Google Cloud IAM.

Verifikasi keamanan DR Anda

Setelah Anda mengonfigurasi izin untuk lingkungan DR, pastikan bahwa Anda menguji semuanya. Buat lingkungan pengujian. Gunakan alat IaC seperti Terraform untuk men-deploy kebijakan Google Cloud Anda ke lingkungan pengujian. Pastikan izin yang Anda berikan kepada pengguna cocok dengan izin yang diberikan kepada pengguna secara lokal.

Pastikan pengguna dapat mengakses lingkungan DR

Jangan menunggu bencana terjadi sebelum memeriksa apakah pengguna dapat mengakses lingkungan DR. Pastikan Anda telah memberikan hak akses yang sesuai untuk pengguna, developer, operator, data scientist, administrator keamanan administrator jaringan, dan peran lainnya dalam organisasi Anda. Jika Anda menggunakan sistem identitas alternatif, pastikan akun telah disinkronkan dengan akun Cloud Identity Anda. Karena lingkungan DR akan menjadi lingkungan produksi Anda untuk sementara waktu, minta pengguna yang memerlukan akses ke lingkungan DR untuk login, dan selesaikan masalah autentikasi apapun. Gabungkan pengguna yang login ke lingkungan DR sebagai bagian dari tes DR reguler yang Anda terapkan.

Untuk mengelola secara terpusat siapa yang memiliki akses SSH ke mesin virtual (VM) yang diluncurkan, aktifkan fitur login OS pada project Google Cloud yang membentuk lingkungan DR Anda.

Melatih pengguna

Pengguna perlu memahami cara melakukan tindakan di Google Cloud yang mereka gunakan untuk menyelesaikan di lingkungan produksi, seperti login, mengakses VMs, dan sebagainya. Dengan menggunakan lingkungan pengujian, latih pengguna cara melakukan tugas-tugas ini dengan cara yang melindungi keamanan sistem Anda.

Pastikan lingkungan DR memenuhi persyaratan kepatuhan

Pastikan akses ke lingkungan DR Anda dibatasi hanya untuk pengguna yang membutuhkan akses. Pastikan data PII tersamarkan dan terenkripsi. Jika melakukan uji penetrasi secara teratur di lingkungan produksi, Anda harus menyertakan lingkungan DR sebagai bagian dari cakupan tersebut dan melakukan pengujian reguler dengan membuat lingkungan DR.

Pastikan saat lingkungan DR Anda berfungsi, setiap log yang Anda kumpulkan diisi ulang ke arsip log lingkungan produksi Anda. Demikian pula, pastikan bahwa sebagai bagian dari lingkungan DR, Anda dapat mengekspor log audit yang dikumpulkan melalui Cloud Logging ke arsip sink log utama Anda. Gunakan fasilitas sink ekspor. Untuk log aplikasi, buat pencerminan lingkungan logging dan pemantauan lokal. Jika lingkungan produksi Anda adalah penyedia cloud lain, petakan logging dan pemantauan penyedia tersebut ke layanan Google Cloud yang setara. Siapkan proses untuk memformat input ke lingkungan produksi Anda.

Gunakan Cloud Storage sebagai bagian dari rutinitas pencadangan harian Anda

Gunakan Cloud Storage untuk menyimpan cadangan. Pastikan bucket yang berisi cadangan Anda memiliki izin yang sesuai yang diterapkan pada bucket tersebut.

Mengelola secret dengan benar

Kelola rahasia dan kunci level aplikasi dengan menggunakan Google Cloud untuk menghosting key/secret management service (KMS). Anda dapat menggunakan Cloud KMS atau solusi pihak ketiga seperti HashiCorp Vault dengan backend Google Cloud seperti Spanner atau Cloud Storage.

Perlakukan data yang dipulihkan seperti data produksi

Pastikan kontrol keamanan yang Anda terapkan ke data produksi juga berlaku untuk data yang dipulihkan: semua persyaratan izin, enkripsi, dan audit yang sama harus diterapkan.

Ketahui lokasi cadangan Anda dan siapa yang berwenang untuk memulihkan data. Pastikan proses pemulihan Anda dapat diaudit. Setelah pemulihan dari bencana, pastikan Anda dapat menunjukkan siapa yang memiliki akses ke data cadangan dan siapa yang melakukan pemulihan.

Memastikan rencana DR Anda berjalan

Pastikan bahwa jika terjadi bencana, rencana DR Anda berfungsi sebagaimana mestinya.

Mempertahankan lebih dari satu jalur pemulihan data

Jika terjadi bencana, metode koneksi Anda ke Google Cloud mungkin tidak akan tersedia. Menerapkan cara akses alternatif ke Google Cloud untuk memastikan bahwa anda dapat mentransfer data ke Google Cloud. Uji secara teratur apakah jalur cadangan dapat beroperasi.

Uji rencana Anda secara teratur.

Setelah membuat rencana DR, uji secara rutin, dengan memperhatikan setiap masalah yang muncul dan menyesuaikan rencana Anda sebagaimana mestinya. Dengan Google Cloud, Anda dapat menguji skenario pemulihan dengan biaya minimal. Sebaiknya Anda menerapkan hal berikut untuk membantu pengujian:

  • Mengotomatiskan penyediaan infrastruktur. Anda dapat menggunakan alat IaC seperti Terraform untuk mengotomatiskan penyediaan instance VM dan infrastruktur Google Cloud lainnya. Jika Anda menjalankan lingkungan produksi secara lokal, pastikan Anda memiliki proses pemantauan yang dapat memulai proses DR saat mendeteksi kegagalan dan dapat memicu tindakan pemulihan yang sesuai.
  • Pantau dan debug pengujian Anda dengan Cloud Logging dan Cloud Monitoring. Google Cloud memiliki alat logging dan pemantauan luar biasa yang dapat Anda akses melalui panggilan API. Dengan alat ini, Anda dapat mengotomatiskan deployment skenario pemulihan dengan merespons metrik. Saat mendesain pengujian, pastikan Anda memiliki pemantauan dan pemberitahuan yang sesuai yang dapat memicu tindakan pemulihan yang sesuai.

  • Lakukan pengujian yang disebutkan sebelumnya:

    • Uji apakah izin dan akses pengguna berfungsi di lingkungan DR seperti yang dilakukan di lingkungan produksi.
    • Lakukan uji penetrasi di lingkungan DR Anda.
    • Lakukan pengujian dimana jalur akses yang biasa Anda gunakan ke Google Cloud tidak berfungsi.

Apa langkah selanjutnya?