Panduan perencanaan pemulihan dari bencana

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

Rangkaian ini terdiri dari bagian berikut:

Peristiwa yang mengganggu layanan dapat terjadi kapan saja. Jaringan Anda mungkin mengalami pemadaman, push aplikasi terbaru Anda 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. Tidak peduli seperti apa 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 yang dapat diterima saat aplikasi Anda dapat berada secara offline. Nilai ini biasanya didefinisikan sebagai bagian dari perjanjian tingkat layanan (SLA) yang lebih besar.
  • Tujuan poin pemulihan (RPO), yang merupakan jangka waktu maksimum yang dapat diterima saat data mungkin hilang dari aplikasi Anda karena 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 dalam metrik lain: tujuan tingkat layanan (SLO), yang merupakan elemen penting yang dapat diukur 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 lebih lanjut SLO dan SLA di buku Google Site Reliability Engineering.

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 Anda menjalankan beban kerja produksi diGoogle Cloud, Anda dapat menggunakan sistem yang terdistribusi secara global sehingga jika terjadi masalah di satu region, aplikasi akan terus menyediakan layanan meskipun ketersediaannya kurang luas. Intinya, aplikasi tersebut memanggil rencana DR-nya.

Mengapa Google Cloud?

Google Cloud dapat mengurangi biaya yang terkait dengan RTO dan RPO secara signifikan jika dibandingkan dengan memenuhi persyaratan RTO dan RPO secara lokal. Misalnya, perencanaan DR mengharuskan Anda untuk memperhitungkan sejumlah persyaratan, termasuk yang 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 memberikan solusi yang sangat terkelola pada platform produksi kelas dunia,Google Cloud membantu Anda melewati sebagian besar atau semua faktor rumit ini, sehingga menghilangkan banyak biaya bisnis dalam prosesnya. Selain itu,fokus Google Cloud pada kesederhanaan administratif berarti biaya pengelolaan aplikasi yang kompleks juga berkurang.

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

  • 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 untuk diskalakan seperti produk Google lainnya (misalnya penelusuran dan Gmail), bahkan saat Anda mengalami lonjakan traffic yang besar. Layanan terkelola seperti Cloud Run, Compute Engine, dan Firestore memberi Anda penskalaan otomatis yang memungkinkan aplikasi Anda tumbuh dan menyusut sesuai kebutuhan.
  • Keamanan. Model keamanan Google dibuat berdasarkan pengalaman puluhan 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 membantu mencegah penyalahgunaan resource platform.
  • Kepatuhan. Google melakukan audit pihak ketiga independen secara rutin untuk memverifikasi bahwa Google Cloud selaras dengan peraturan serta praktik terbaik keamanan, privasi, dan kepatuhan. 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.

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 ingin dapat memulihkan data dan bagian aplikasi yang ditampilkan kepada pengguna 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.

Sebagai panduan tentang penggunaan Google Cloud untuk mengatasi skenario DR umum, tinjau skenario pemulihan aplikasi. Skenario ini menyediakan strategi DR tertarget untuk berbagai kasus penggunaan dan menawarkan contoh implementasi Google Cloud untuk setiap 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 shell dan jalankan /home/example/restore.sh" bersifat 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 software apa pun yang akan di-deploy di Google Cloud. Hubungi penyedia software untuk mendapatkan panduan.

Pastikan resource Compute Engine yang diperlukan tersedia di lingkungan pemulihan. Anda mungkin perlu mengalokasikan instance terlebih dahulu atau melakukannya.

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 menetapkan kontrol keamanan dan jaringan terpusat atas deployment Anda, mengonfigurasi subnet, dan mengontrol traffic masuk dan keluar. Pahami cara menggunakan akun layanan untuk menerapkan hak istimewa terendah untuk 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, Anda dapat mereplikasi kebijakan IAM di lingkungan DR dengan mudah. Anda dapat menggunakan alat infrastructure as code (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 peran fungsional jaringan dan logging audit.

  • 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 dalam kebijakan IAM penyedia lain ke Google Cloud kebijakan IAM.

Verifikasi keamanan DR Anda

Setelah Anda mengonfigurasi izin untuk lingkungan DR, pastikan bahwa Anda menguji semuanya. Buat lingkungan pengujian. Pastikan izin yang Anda berikan kepada pengguna cocok dengan yang dimiliki pengguna di infrastruktur lokal.

Memastikan pengguna dapat mengakses lingkungan DR

Jangan menunggu terjadinya bencana 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 akan memerlukan akses ke lingkungan DR untuk login, dan selesaikan masalah autentikasi apa pun. Memasukkan pengguna yang login ke lingkungan DR sebagai bagian dari pengujian DR reguler yang Anda terapkan.

Untuk mengelola secara terpusat siapa saja yang memiliki akses administratif ke virtual machine (VM) yang diluncurkan, aktifkan fitur login OS di Google Cloud project yang membentuk lingkungan DR Anda.

Melatih pengguna

Pengguna perlu memahami cara melakukan tindakan dalam Google Cloud yang biasa mereka selesaikan di lingkungan produksi, seperti login dan mengakses VM. Dengan menggunakan lingkungan pengujian, latih pengguna cara melakukan tugas-tugas ini dengan cara yang menjaga 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. 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.

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

Memastikan bahwa jika bencana benar-benar terjadi, rencana DR Anda berfungsi sebagaimana mestinya.

Mempertahankan lebih dari satu jalur pemulihan data

Jika terjadi bencana, metode koneksi Anda ke Google Cloud mungkin tidak tersedia. Terapkan cara alternatif akses ke Google Cloud untuk membantu 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 rencana tersebut secara rutin, dengan mencatat setiap masalah yang muncul dan menyesuaikan rencana Anda sebagaimana mestinya. Dengan menggunakan Google Cloud, Anda dapat menguji skenario pemulihan dengan biaya minimal. Sebaiknya terapkan hal berikut untuk membantu pengujian:

  • Mengotomatiskan penyediaan infrastruktur. Anda dapat menggunakan alat IaC seperti Terraform untuk mengotomatiskan penyediaan Google Cloud infrastruktur. 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 lingkungan Anda dengan Kemampuan Observasi Google Cloud. Google Cloud memiliki alat logging dan pemantauan yang sangat baik dan dapat Anda akses melalui panggilan API, sehingga Anda dapat mengotomatiskan deployment skenario pemulihan dengan bereaksi terhadap 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 yang tidak memungkinkan jalur akses yang biasa Anda lakukan ke Google Cloud.

Apa langkah selanjutnya?

Kontributor

Penulis: