Dokumen ini menjelaskan pemulihan dari bencana (DR) dan perencanaan kelangsungan bisnis dalam konteks continuous integration dan continuous delivery (CI/CD). Panduan ini juga memberikan panduan tentang cara mengidentifikasi dan memitigasi dependensi saat Anda mengembangkan rencana kelangsungan bisnis (BCP) yang komprehensif. Dokumen ini mencakup praktik terbaik yang dapat Anda terapkan ke BCP, terlepas dari alat dan proses yang Anda gunakan. Dokumen ini mengasumsikan bahwa Anda telah memahami dasar-dasar siklus operasi dan pengiriman software, CI/CD, dan DR.
Pipeline CI/CD bertanggung jawab untuk mem-build dan men-deploy aplikasi penting bagi bisnis Anda. Jadi, seperti infrastruktur aplikasi, proses CI/CD Anda memerlukan perencanaan untuk DR dan kelangsungan bisnis. Saat Anda memikirkan DR dan kelangsungan bisnis untuk CI/CD, penting untuk memahami setiap fase siklus operasi dan pengiriman software, serta memahami cara kerjanya bersama sebagai proses menyeluruh.
Diagram berikut adalah tampilan sederhana dari siklus operasi dan pengembangan software, yang mencakup tiga fase berikut:
- Loop dalam pengembangan: kode, coba, dan komit
- Continuous integration: build, pengujian, dan keamanan
- Continuous delivery: promosi, peluncuran, rollback, dan metrik
Diagram ini juga menunjukkan bahwa Google Kubernetes Engine (GKE), Cloud Run, dan Google Distributed Cloud adalah kemungkinan target deployment siklus operasi dan pengembangan software.
Sepanjang siklus pengembangan dan operasi software, Anda perlu mempertimbangkan dampak bencana terhadap kemampuan tim untuk mengoperasikan dan memelihara aplikasi yang penting bagi bisnis. Tindakan ini akan membantu Anda menentukan Recovery Time Objective (RTO) dan Recovery Point Objective (RPO) untuk alat di toolchain CI/CD Anda.
Selain itu, sebagian besar organisasi memiliki banyak pipeline CI/CD yang berbeda untuk berbagai aplikasi dan kumpulan infrastruktur, dan setiap pipeline memiliki persyaratan unik untuk DR dan perencanaan kelangsungan bisnis. Strategi pemulihan yang Anda pilih untuk pipeline akan bervariasi berdasarkan RTO dan RPO alat Anda. Misalnya, beberapa pipeline lebih penting daripada yang lain, dan akan memiliki persyaratan RTO dan RPO yang lebih rendah. Penting untuk mengidentifikasi pipeline yang penting bagi bisnis dalam BCP Anda, dan pipeline tersebut juga harus menerima lebih banyak perhatian saat Anda menerapkan praktik terbaik untuk menguji dan menjalankan prosedur pemulihan.
Karena setiap proses CI/CD dan toolchain-nya berbeda, tujuan panduan ini adalah untuk membantu Anda mengidentifikasi titik kegagalan tunggal dalam proses CI/CD dan mengembangkan BCP yang komprehensif. Bagian berikut membantu Anda melakukan hal berikut:
- Pahami hal-hal yang diperlukan untuk memulihkan dari peristiwa DR yang memengaruhi proses CI/CD Anda.
- Tentukan RTO dan RPO untuk alat dalam proses CI/CD Anda.
- Pahami mode kegagalan dan dependensi proses CI/CD Anda.
- Pilih strategi pemulihan yang sesuai untuk alat di toolchain Anda.
- Pahami praktik terbaik umum untuk menerapkan rencana pemulihan DR untuk proses CI/CD Anda.
Memahami proses kelangsungan bisnis
Membuat BCP sangat penting untuk membantu memastikan bahwa organisasi Anda dapat melanjutkan operasinya jika terjadi gangguan dan keadaan darurat. Hal ini membantu organisasi Anda kembali ke status operasi normal dengan cepat untuk proses CI/CD-nya.
Bagian berikut menguraikan tahapan tingkat tinggi yang mencakup langkah-langkah yang terlibat dalam membuat BCP yang efektif. Meskipun banyak langkah ini berlaku secara luas untuk pengelolaan program dan DR, langkah-langkah tertentu lebih relevan untuk merencanakan kelangsungan bisnis untuk proses CI/CD Anda. Langkah-langkah yang khusus relevan dengan perencanaan kelangsungan bisnis untuk CI/CD ditandai di bagian berikut, dan juga membentuk dasar untuk panduan di bagian lain dokumen ini.
Inisiasi dan perencanaan
Pada tahap awal ini, tim teknis dan bisnis bekerja sama untuk membangun fondasi bagi proses perencanaan kelangsungan bisnis dan pemeliharaannya yang berkelanjutan. Langkah-langkah utama untuk tahap ini meliputi:
- Dukungan kepemimpinan: pastikan manajemen senior mendukung dan mendorong pengembangan BCP. Tetapkan tim khusus atau individu yang bertanggung jawab untuk mengawasi rencana.
- Alokasi resource: mengalokasikan anggaran, personel, dan resource yang diperlukan untuk mengembangkan dan menerapkan BCP.
- Cakupan dan tujuan: tentukan cakupan BCP dan tujuannya. Tentukan proses bisnis mana yang penting dan perlu ditangani dalam perencanaan.
- Penilaian risiko: mengidentifikasi potensi risiko dan ancaman yang dapat mengganggu bisnis Anda, seperti bencana alam, pelanggaran keamanan cyber, atau gangguan rantai pasokan.
- Analisis dampak: menilai potensi konsekuensi dari temuan penilaian risiko ini terhadap operasi, keuangan, reputasi, dan kepuasan pelanggan bisnis Anda.
Analisis dampak bisnis
Pada tahap ini, tim bisnis dan teknis menganalisis dampak bisnis dari gangguan terhadap pelanggan dan organisasi Anda, serta memprioritaskan pemulihan fungsi bisnis yang penting. Fungsi bisnis ini dilakukan oleh alat yang berbeda selama berbagai fase proses build dan deployment.
Analisis dampak bisnis adalah tahap penting dalam proses perencanaan kelangsungan bisnis untuk CI/CD, terutama langkah-langkah untuk mengidentifikasi fungsi bisnis penting dan dependensi alat. Selain itu, memahami toolchain CI/CD Anda, termasuk dependensinya dan cara kerjanya dalam siklus proses DevOps, adalah elemen penyusun dasar untuk mengembangkan BCP bagi proses CI/CD Anda.
Langkah-langkah utama dalam tahap analisis dampak bisnis meliputi hal-hal berikut:
- Fungsi penting: menentukan fungsi dan proses bisnis utama yang harus diprioritaskan untuk pemulihan. Misalnya, jika Anda menentukan bahwa men-deploy aplikasi lebih penting daripada menjalankan pengujian unit, Anda akan memprioritaskan pemulihan untuk proses dan alat deployment aplikasi.
- Dependensi: identifikasi dependensi internal dan eksternal yang dapat memengaruhi pemulihan fungsi penting Anda. Dependensi sangat relevan untuk memastikan operasi berkelanjutan proses CI/CD Anda melalui toolchain-nya.
- RTO dan RPO: menentukan batas yang dapat diterima untuk downtime dan batas kehilangan data untuk setiap fungsi penting. Target RTO dan RPO ini terkait dengan pentingnya fungsi bisnis untuk operasi berkelanjutan, dan melibatkan alat tertentu yang diperlukan agar fungsi bisnis dapat beroperasi dengan lancar.
Pengembangan strategi
Pada tahap ini, tim teknis mengembangkan strategi pemulihan untuk fungsi bisnis penting, seperti memulihkan operasi dan data, serta berkomunikasi dengan vendor dan pemangku kepentingan. Pengembangan strategi juga merupakan bagian penting dari perencanaan kelangsungan bisnis untuk proses CI/CD Anda, terutama langkah memilih strategi pemulihan tingkat tinggi untuk fungsi penting.
Langkah-langkah utama dalam tahap pengembangan strategi meliputi hal-hal berikut:
- Strategi pemulihan: mengembangkan strategi untuk memulihkan fungsi kritis. Strategi ini mungkin melibatkan lokasi alternatif, kerja jarak jauh, atau sistem cadangan. Strategi ini terkait dengan target RTO dan RPO untuk setiap fungsi penting.
- Hubungan vendor dan pemasok: buat rencana komunikasi dan koordinasi dengan vendor dan pemasok utama untuk menjaga agar rantai pasokan tetap berjalan selama gangguan.
- Pemulihan data dan IT: membuat rencana untuk pencadangan data, pemulihan sistem IT, dan langkah-langkah keamanan cyber.
- Rencana komunikasi: mengembangkan rencana komunikasi yang jelas untuk pemangku kepentingan internal dan eksternal selama dan setelah gangguan.
Pengembangan rencana
Pada tahap ini, langkah utamanya adalah mendokumentasikan BCP. Tim teknis mendokumentasikan alat, proses, strategi pemulihan, alasan, dan prosedur untuk setiap fungsi penting. Pengembangan rencana juga mencakup penulisan petunjuk langkah demi langkah yang harus diikuti karyawan selama gangguan. Selama penerapan dan pemeliharaan berkelanjutan, perubahan mungkin perlu diterapkan ke rencana, dan rencana harus diperlakukan sebagai dokumen yang terus diperbarui.
Penerapan
Pada tahap ini, Anda menerapkan rencana untuk organisasi menggunakan BCP yang dibuat oleh tim teknis. Penerapan mencakup pelatihan karyawan dan pengujian awal BCP. Penerapan juga mencakup penggunaan rencana jika terjadi gangguan untuk memulihkan operasi reguler. Langkah-langkah penerapan utama meliputi hal berikut:
- Pengujian dan pelatihan awal: setelah BPC didokumentasikan, uji melalui simulasi dan latihan untuk mengidentifikasi kesenjangan dan meningkatkan efektivitas. Latih karyawan tentang peran dan tanggung jawab mereka selama gangguan.
- Aktivasi: saat gangguan terjadi, mulai BCP sesuai dengan pemicu dan prosedur yang telah ditentukan sebelumnya.
- Komunikasi: terus beri tahu pemangku kepentingan tentang situasi dan upaya pemulihan.
Pemeliharaan dan peninjauan
Tahap ini bukan proses yang ditentukan yang hanya terjadi satu kali. Sebaliknya, tahap ini mewakili upaya berkelanjutan yang harus menjadi bagian normal dari operasi CI/CD Anda. Penting untuk meninjau, menguji, dan memperbarui BCP secara berkala dalam organisasi Anda agar tetap relevan dan dapat ditindaklanjuti jika terjadi gangguan. Langkah-langkah utama pemeliharaan dan peninjauan mencakup hal-hal berikut:
- Pembaruan rutin: tinjau dan perbarui BCP secara berkala agar tetap terbaru dan efektif. Perbarui setiap kali ada perubahan pada personel, teknologi, atau proses bisnis.
- Pelajaran yang didapat: setelah setiap gangguan atau pengujian, lakukan debriefing untuk mengidentifikasi pelajaran yang didapat dan area yang perlu ditingkatkan.
- Kepatuhan terhadap peraturan: selaraskan BCP Anda dengan peraturan dan standar industri.
- Kesadaran karyawan: terus mengedukasi karyawan tentang BCP dan peran mereka dalam pelaksanaannya.
Membuat proses kelangsungan bisnis untuk CI/CD
Bagian ini memberikan panduan khusus untuk membuat BCP yang secara khusus berfokus pada pemulihan operasi CI/CD Anda. Proses perencanaan kontinuitas bisnis untuk CI/CD dimulai dengan pemahaman menyeluruh tentang toolchain CI/CD Anda, dan kaitannya dengan siklus proses operasi dan pengiriman software. Dengan pemahaman ini sebagai dasar, Anda kemudian dapat merencanakan cara organisasi Anda memulihkan operasi CI/CD dari gangguan.
Untuk membangun proses kelangsungan bisnis yang andal untuk proses CI/CD, Anda perlu melakukan langkah-langkah utama berikut:
- Memahami toolchain
- Mengidentifikasi data dan dependensi
- Menentukan target RTO dan RPO
- Memilih strategi tingkat tinggi untuk keberlangsungan bisnis
- Mendokumentasikan BCP dan menerapkan praktik terbaik
- Menguji skenario kegagalan dan mempertahankan rencana
Bagian berikut memberikan detail selengkapnya tentang setiap langkah ini.
Memahami toolchain
toolchain CI/CD terdiri dari banyak alat individual yang berbeda dan kemungkinan kombinasi alat dapat tampak tidak terbatas. Namun, memahami toolchain CI/CD dan dependensinya adalah kunci untuk perencanaan kelangsungan bisnis untuk CI/CD. Misi inti proses CI/CD Anda adalah mengirimkan kode ke sistem produksi untuk konsumsi pengguna akhir. Selama proses tersebut, banyak sistem dan sumber data yang berbeda digunakan; mengetahui sumber data dan dependensi tersebut sangat penting untuk mengembangkan BCP. Untuk mulai membuat strategi DR, Anda harus memahami berbagai alat yang terlibat dalam proses CI/CD terlebih dahulu.
Untuk membantu Anda memahami cara mengevaluasi toolchain Anda sendiri dan mengembangkan BCP, dokumen ini menggunakan contoh aplikasi Java perusahaan yang berjalan di GKE. Diagram berikut menunjukkan lapisan pertama data dan sistem dalam toolchain. Lapisan pertama ini akan berada di bawah kontrol langsung Anda dan mencakup hal berikut:
- Sumber untuk aplikasi Anda
- Alat di platform CI/CD Anda, seperti Cloud Build atau Cloud Deploy
- Interkoneksi dasar dari berbagai alat
Seperti yang ditunjukkan pada diagram, alur utama untuk contoh aplikasi adalah berikut:
- Peristiwa pengembangan kode di loop dalam developer memicu Cloud Build.
- Cloud Build mengambil kode sumber aplikasi dari repositori kontrol sumber.
- Cloud Build mengidentifikasi dependensi yang diperlukan yang ditentukan dalam file konfigurasi build, seperti file JAR pihak ketiga dari repositori Java di Artifact Registry. Cloud Build kemudian mengambil dependensi ini dari lokasi sumbernya.
- Cloud Build menjalankan build dan melakukan validasi yang diperlukan, seperti analisis statis dan pengujian unit.
- Jika build berhasil, Cloud Build akan membuat image container dan mengirimkannya ke repositori container di Artifact Registry.
- Pipeline Cloud Deploy dipicu, dan pipeline tersebut mengambil image container dari repositori dan men-deploy-nya ke lingkungan GKE.
Untuk memahami alat yang digunakan dalam proses CI/CD, sebaiknya buat diagram yang menunjukkan proses CI/CD dan alat yang digunakan di dalamnya, seperti contoh dalam dokumen ini. Kemudian, Anda dapat menggunakan diagram untuk membuat tabel yang berisi informasi penting tentang toolchain CI/CD, seperti fase proses, tujuan alat, alat itu sendiri, dan tim yang terpengaruh oleh kegagalan alat. Tabel ini memberikan pemetaan alat dalam toolchain Anda dan mengidentifikasi alat dengan fase tertentu dari proses CI/CD. Dengan demikian, tabel ini dapat membantu Anda mendapatkan gambaran keseluruhan tentang toolchain dan cara kerjanya.
Tabel berikut memetakan contoh aplikasi perusahaan yang disebutkan sebelumnya ke setiap alat dalam diagram. Untuk memberikan contoh yang lebih lengkap tentang tampilan pemetaan toolchain, tabel ini juga menyertakan alat lain yang tidak disebutkan dalam diagram, seperti alat keamanan atau alat pengujian.
Tabel pertama dipetakan ke alat yang digunakan dalam fase CI dari proses CI/CD:
| Continuous integration | Sumber | Alat yang digunakan | Pengguna utama | Penggunaan |
|---|---|---|---|---|
| Fase: Kontrol sumber |
|
|
|
|
| Fase: Build |
|
Developer |
|
|
| Fase: Pengujian |
|
Developer |
Jalankan pengujian unit dan integrasi di platform on demand yang konsisten. |
|
| Fase: Keamanan |
|
|
Memindai kode untuk mengetahui masalah keamanan. |
Tabel kedua berfokus pada alat yang digunakan dalam fase CD dari proses CI/CD:
| Deployment berkelanjutan | Sumber | Alat yang digunakan | Pengguna utama | Penggunaan |
|---|---|---|---|---|
| Fase: Deployment | File konfigurasi deployment |
|
Otomatiskan deployment untuk mempromosikan, menyetujui, dan mengelola traffic di platform yang aman dan konsisten. |
|
| Fase: Pengujian |
|
|
Developer |
Uji integrasi dan performa untuk kualitas dan kegunaan. |
| Fase: Logging |
|
|
Simpan log untuk visibilitas dan pemecahan masalah. |
|
| Fase: Pemantauan | Pemantauan file konfigurasi, termasuk hal berikut:
|
|
|
Seiring Anda terus mengerjakan BCP dan pemahaman Anda tentang toolchain CI/CD bertambah, Anda dapat memperbarui diagram dan tabel pemetaan.
Mengidentifikasi data dan dependensi
Setelah Anda menyelesaikan inventaris dasar dan peta toolchain CI/CD, langkah berikutnya adalah mengambil dependensi pada metadata atau konfigurasi. Saat menerapkan BCP, Anda harus memiliki pemahaman yang jelas tentang dependensi dalam toolchain CI/CD. Dependensi biasanya termasuk dalam salah satu dari dua kategori: dependensi internal (tingkat pertama) dan dependensi eksternal (tingkat kedua atau tingkat ketiga).
Dependensi internal
Dependensi internal adalah sistem yang digunakan toolchain dan Anda dapat mengontrolnya secara langsung. Ketergantungan internal juga dipilih oleh tim Anda. Sistem ini mencakup alat CI, penyimpanan pengelolaan kunci, dan sistem kontrol sumber. Anda dapat menganggap sistem ini berada di lapisan berikutnya dari toolchain itu sendiri.
Misalnya, diagram berikut memberikan contoh bagaimana dependensi internal
cocok dalam toolchain. Diagram ini memperluas diagram toolchain lapisan pertama sebelumnya untuk contoh aplikasi Java agar juga menyertakan dependensi internal toolchain: kredensial aplikasi, file deploy.yaml, dan file cloudbuild.yaml.
Diagram menunjukkan bahwa agar dapat berfungsi dengan baik dalam contoh aplikasi Java, alat seperti
Cloud Build, Cloud Deploy, dan GKE memerlukan akses ke dependensi non-toolchain seperti cloudbuild.yaml,deploy.yaml, dan kredensial aplikasi. Saat menganalisis toolchain CI/CD Anda sendiri, Anda akan menilai apakah alat dapat berjalan sendiri, atau apakah alat tersebut perlu memanggil resource lain.
Pertimbangkan dependensi internal yang didokumentasikan untuk contoh aplikasi Java.
Kredensial disimpan di Secret Manager, yang bukan bagian dari
toolchain, tetapi kredensial diperlukan agar aplikasi dapat dimulai saat
di-deploy. Dengan demikian, kredensial aplikasi disertakan sebagai dependensi untuk
GKE. Anda juga harus menyertakan file deploy.yaml dan
cloudbuild.yaml sebagai dependensi, meskipun file tersebut disimpan dalam kontrol
sumber dengan kode aplikasi, karena file tersebut menentukan pipeline CI/CD untuk
aplikasi tersebut.
BCP untuk contoh aplikasi Java harus memperhitungkan dependensi ini
pada file deploy.yaml dan cloudbuild.yaml karena file tersebut membuat ulang
pipeline CI/CD setelah alat diterapkan selama proses pemulihan.
Selain itu, jika dependensi ini disusupi, fungsi keseluruhan
pipeline akan terpengaruh meskipun alat itu sendiri masih beroperasi.
Dependensi eksternal
Dependensi eksternal adalah sistem eksternal yang digunakan toolchain Anda untuk beroperasi, dan tidak berada di bawah kendali langsung Anda. Dependensi eksternal dihasilkan dari alat dan framework pemrograman yang Anda pilih. Anda dapat menganggap dependensi eksternal sebagai lapisan lain di bawah dependensi internal. Contoh dependensi eksternal mencakup repositori npm atau Maven, dan layanan pemantauan.
Meskipun dependensi eksternal berada di luar kendali Anda, Anda dapat memasukkannya ke dalam BCP. Diagram berikut memperbarui contoh aplikasi Java dengan menyertakan dependensi eksternal selain dependensi internal: library Java di Maven Central dan image Docker di Docker Hub. Library Java digunakan oleh Artifact Registry, dan image Docker digunakan oleh Cloud Build.
Diagram menunjukkan bahwa dependensi eksternal dapat penting untuk proses CI/CD Anda: Cloud Build dan GKE mengandalkan dua layanan eksternal (Maven dan Docker) agar berhasil berfungsi. Saat Anda menilai toolchain Anda sendiri, dokumentasikan dependensi eksternal yang perlu diakses alat Anda dan prosedur untuk menangani pemadaman dependensi.
Dalam contoh aplikasi Java, library Java dan image Docker tidak dapat dikontrol secara langsung, tetapi Anda masih dapat menyertakannya dan prosedur pemulihannya dalam BCP. Misalnya, pertimbangkan library Java di Maven. Meskipun library disimpan di sumber eksternal, Anda dapat membuat proses untuk mendownload dan memuat ulang library Java secara berkala ke repositori Maven lokal atau Artifact Registry. Dengan demikian, proses pemulihan Anda tidak perlu mengandalkan ketersediaan sumber pihak ketiga.
Selain itu, penting untuk memahami bahwa dependensi eksternal dapat memiliki lebih dari satu lapisan. Misalnya, Anda dapat menganggap sistem yang digunakan oleh dependensi internal sebagai dependensi tingkat kedua. Dependensi tingkat kedua ini mungkin memiliki dependensi sendiri, yang dapat Anda anggap sebagai dependensi tingkat ketiga. Perhatikan bahwa Anda mungkin perlu mendokumentasikan dan memperhitungkan dependensi eksternal tingkat kedua dan ketiga dalam BCP untuk memulihkan operasi selama gangguan.
Menentukan target RTO dan RPO
Setelah mengembangkan pemahaman tentang toolchain dan dependensi, Anda akan menentukan target RTO dan RPO untuk alat Anda. Setiap alat dalam proses CI/CD melakukan tindakan yang berbeda yang dapat memiliki dampak yang berbeda pada bisnis. Oleh karena itu, penting untuk mencocokkan prioritas target RTO dan RPO fungsi bisnis dengan dampaknya terhadap bisnis. Misalnya, mem-build aplikasi versi baru melalui tahap CI mungkin kurang berdampak dibandingkan men-deploy aplikasi melalui tahap CD. Dengan demikian, alat deployment dapat memiliki target RTO dan RPO yang lebih lama daripada fungsi lainnya.
Diagram empat kuadran berikut adalah contoh umum tentang cara menentukan target RTO dan RPO untuk setiap komponen toolchain CI/CD. toolchain yang dipetakan dalam diagram ini mencakup alat seperti pipeline IaC dan sumber data pengujian. Alat ini tidak disebutkan dalam diagram sebelumnya untuk aplikasi Java, tetapi disertakan di sini untuk memberikan contoh yang lebih lengkap.
Diagram menunjukkan kuadran yang didasarkan pada tingkat dampak terhadap developer dan operasi. Dalam diagram, komponen diposisikan sebagai berikut:
- Dampak developer sedang, dampak operasi rendah: sumber data pengujian
- Dampak developer sedang, dampak operasi sedang: Cloud Key Management Service, Cloud KMS
- Dampak developer sedang, dampak operasi tinggi: pipeline deployment
- Dampak developer tinggi, dampak operasi rendah: loop dalam developer
- Dampak developer tinggi, dampak operasi sedang: pipeline CI, pipeline infrastruktur sebagai kode (IaC)
- Dampak developer tinggi, dampak operasi tinggi: pengelolaan kontrol sumber (SCM), Artifact Registry
Komponen seperti pengelolaan kontrol sumber dan Artifact Registry yang memiliki dampak developer dan dampak operasi yang tinggi akan berdampak paling besar pada bisnis. Komponen ini harus memiliki tujuan RTO dan RPO terendah. Komponen di kuadran lain memiliki prioritas yang lebih rendah, yang berarti bahwa tujuan RTO dan RPO akan lebih tinggi. Secara umum, tujuan RTO dan RPO untuk komponen toolchain Anda harus ditetapkan sesuai dengan jumlah data atau konfigurasi yang dapat ditoleransi dibandingkan dengan jumlah waktu yang diperlukan untuk memulihkan layanan untuk komponen tersebut.
Misalnya, pertimbangkan lokasi Artifact Registry dan pipeline IaC yang berbeda dalam grafik. Perbandingan antara kedua alat ini menunjukkan bahwa hilangnya layanan Artifact Registry memiliki dampak yang lebih besar terhadap operasi bisnis daripada hilangnya layanan di pipeline IaC. Karena pemadaman layanan Artifact Registry secara signifikan memengaruhi kemampuan Anda untuk men-deploy atau menskalakan otomatis aplikasi, Artifact Registry akan memiliki target RTO dan RPO yang lebih rendah dibandingkan dengan alat lainnya. Sebaliknya, grafik menunjukkan bahwa pemadaman pipeline IaC memiliki dampak yang lebih kecil terhadap operasi bisnis daripada alat lainnya. Pipeline IaC kemudian akan memiliki tujuan RTO dan RPO yang lebih tinggi karena Anda dapat menggunakan metode lain untuk men-deploy atau mengupdate infrastruktur selama pemadaman layanan.
Memilih strategi tingkat tinggi untuk kelangsungan bisnis
Proses kelangsungan bisnis untuk aplikasi produksi sering kali mengandalkan salah satu tiga strategi DR umum. Namun, untuk CI/CD, Anda dapat memilih antara dua strategi tingkat tinggi untuk kontinuitas bisnis: aktif/pasif atau pencadangan/pemulihan. Strategi yang Anda pilih akan bergantung pada persyaratan dan anggaran Anda. Setiap strategi memiliki kompromi dengan kompleksitas dan biaya, dan Anda memiliki pertimbangan yang berbeda untuk proses CI/CD. Bagian berikut memberikan detail selengkapnya tentang setiap strategi dan komprominya.
Selain itu, saat peristiwa yang mengganggu layanan terjadi, peristiwa tersebut mungkin berdampak lebih besar daripada penerapan CI/CD Anda. Anda juga harus mempertimbangkan semua infrastruktur yang diperlukan, termasuk jaringan, komputasi, dan penyimpanan. Anda harus memiliki rencana DR untuk elemen penyusun tersebut dan mengujinya secara rutin untuk memastikan bahwa rencana tersebut efektif.
Aktif/pasif
Dengan strategi aktif/pasif (atau warm standby), aplikasi Anda dan pipeline CI/CD pasif adalah mirror. Namun, pipeline pasif tidak benar-benar menangani beban kerja pelanggan dan build atau deployment apa pun, sehingga berada dalam status yang diperkecil. Strategi ini paling sesuai untuk aplikasi penting bagi bisnis yang dapat menoleransi periode nonaktif dalam jumlah kecil.
Diagram berikut menunjukkan konfigurasi aktif/pasif untuk contoh aplikasi Java yang digunakan dalam dokumen ini. Pipeline pasif sepenuhnya menduplikasi toolchain aplikasi di region yang berbeda.
Dalam contoh ini, region1 menghosting pipeline CI/CD aktif dan region2 memiliki counterpart pasif. Kode dihosting di penyedia layanan Git eksternal, seperti GitHub atau GitLab. Peristiwa repositori (seperti penggabungan dari permintaan pull) dapat memicu pipeline CI/CD di region1 untuk mem-build, menguji, dan men-deploy ke lingkungan produksi multi-regional.
Jika terjadi masalah kritis untuk pipeline region1, seperti pemadaman layanan regional pada produk, hasilnya dapat berupa deployment yang gagal atau build yang gagal. Untuk cepat pulih dari masalah ini, Anda dapat memperbarui pemicu untuk repositori Git dan beralih ke pipeline region2, yang kemudian menjadi pipeline aktif. Setelah masalah teratasi di region1, Anda dapat mempertahankan pipeline di region1 sebagai pasif.
Keuntungan strategi aktif/pasif mencakup hal berikut:
- Downtime rendah: karena pipeline pasif telah di-deploy, tetapi diperkecil skalanya, jumlah downtime dibatasi pada waktu yang diperlukan untuk menskalakan pipeline.
- Toleransi yang dapat dikonfigurasi untuk kehilangan data: dengan strategi ini, konfigurasi dan artefak harus disinkronkan secara berkala. Namun, jumlah tersebut dapat dikonfigurasi berdasarkan persyaratan Anda, yang dapat mengurangi kompleksitas.
Kekurangan strategi ini mencakup hal berikut:
- Biaya: dengan infrastruktur duplikat, strategi ini akan meningkatkan biaya keseluruhan infrastruktur CI/CD Anda.
Pencadangan/pemulihan
Dengan strategi pencadangan/pemulihan, Anda membuat pipeline failover hanya jika diperlukan selama pemulihan insiden. Strategi ini paling sesuai untuk kasus penggunaan dengan prioritas lebih rendah. Diagram berikut menunjukkan konfigurasi pencadangan/pemulihan untuk contoh aplikasi Java. Konfigurasi cadangan hanya menduplikasi bagian dari pipeline CI/CD aplikasi di region yang berbeda.
Serupa dengan contoh sebelumnya, region1 menghosting pipeline CI/CD yang aktif. Daripada memiliki pipeline pasif di region2, region2 hanya memiliki cadangan data regional yang diperlukan, seperti paket Maven dan image container. Jika Anda menghosting repositori sumber di region1, Anda juga harus menyinkronkan data ke lokasi DR.
Demikian pula, jika terjadi masalah kritis di pipeline region1, seperti pemadaman layanan produk regional, Anda dapat memulihkan penerapan CI/CD di region2. Jika kode infrastruktur disimpan di repositori kode infrastruktur, Anda dapat menjalankan skrip otomatisasi dari repositori dan mem-build ulang pipeline CI/CD di region2.
Jika pemadaman terjadi dalam skala besar, Anda mungkin bersaing dengan pelanggan lain untuk
resource cloud. Salah satu cara untuk memitigasi situasi ini adalah dengan memiliki beberapa opsi untuk lokasi DR. Misalnya, jika pipeline region1 Anda berada di us-east1,
region failover Anda dapat berupa us-east4, us-central1, atau us-west1.
Keuntungan strategi pencadangan/pemulihan mencakup hal berikut:
- Biaya: strategi ini menimbulkan biaya terendah karena Anda men-deploy pipeline pencadangan hanya selama skenario DR.
Kekurangan strategi ini mencakup hal berikut:
- Periode nonaktif: strategi ini memerlukan lebih banyak waktu untuk diterapkan karena Anda membuat pipeline failover saat Anda membutuhkannya. Layanan harus dibuat dan dikonfigurasi selama pemulihan insiden, bukan memiliki pipeline bawaan. Waktu build artefak dan waktu untuk mengambil dependensi eksternal juga dapat menjadi lebih lama secara signifikan.
Mendokumentasikan BCP dan menerapkan praktik terbaik
Setelah memetakan toolchain CI/CD, mengidentifikasi dependensinya, dan menentukan target RTO dan RPO untuk fungsi penting, langkah berikutnya adalah mendokumentasikan semua informasi yang relevan dalam BCP tertulis. Saat membuat BCP, dokumentasikan strategi, proses, dan prosedur untuk memulihkan setiap fungsi penting. Proses dokumentasi ini mencakup penulisan prosedur langkah demi langkah untuk karyawan dalam peran tertentu yang harus diikuti selama gangguan.
Setelah menentukan BCP, Anda men-deploy atau mengupdate toolchain CI/CD menggunakan praktek terbaik untuk mencapai target RTO dan RPO. Meskipun toolchain CI/CD dapat sangat berbeda, dua pola utama untuk praktik terbaik bersifat umum, terlepas dari toolchain: pemahaman komprehensif tentang dependensi dan penerapan otomatisasi.
Sehubungan dengan dependensi, sebagian besar BCP menangani sistem secara langsung dalam kendali Anda. Namun, ingatlah bahwa dependensi eksternal tingkat kedua atau ketiga mungkin sama berdampaknya, jadi penting untuk menerapkan praktik terbaik dan tindakan redundansi untuk dependensi penting tersebut. Library Java eksternal dalam contoh aplikasi adalah contoh dependensi tingkat ketiga. Jika tidak memiliki repositori atau cadangan lokal untuk library tersebut, Anda mungkin tidak dapat mem-build aplikasi jika sumber eksternal tempat Anda mengambil library terputus.
Dalam hal otomatisasi, penerapan praktik terbaik harus disertakan dalam keseluruhan strategi IaC cloud Anda. Solusi IaC Anda harus menggunakan alat seperti Terraform untuk menyediakan resource yang diperlukan dari penerapan CI/CD secara otomatis dan mengonfigurasi proses. Praktik IaC adalah prosedur pemulihan yang sangat efektif karena disertakan dalam fungsi sehari-hari pipeline CI/CD Anda. Selain itu, IaC mendorong penyimpanan file konfigurasi Anda dalam kontrol sumber, yang pada akhirnya mendorong penerapan praktik terbaik untuk pencadangan.
Setelah Anda menerapkan toolchain sesuai dengan BCP dan praktik terbaik untuk dependensi dan otomatisasi, proses CI/CD dan strategi pemulihan Anda mungkin berubah. Pastikan untuk mendokumentasikan setiap perubahan pada strategi, proses, dan prosedur pemulihan yang dihasilkan dari peninjauan BCP dan penerapan praktik terbaik.
Menguji skenario kegagalan dan mempertahankan rencana
Sangat penting untuk meninjau, menguji, dan memperbarui BCP secara rutin secara berkelanjutan. Menguji BCP dan prosedur pemulihan akan memverifikasi bahwa rencana tersebut masih valid dan target RPO dan RTO yang didokumentasikan dapat diterima. Namun, yang paling penting, pengujian, pembaruan, dan pemeliharaan rutin membuat eksekusi BCP menjadi bagian dari operasi normal. Dengan Google Cloud, Anda dapat menguji skenario pemulihan dengan biaya minimal. Sebaiknya lakukan hal berikut untuk membantu pengujian Anda:
- Mengotomatiskan penyediaan infrastruktur dengan alat IaC: Anda dapat menggunakan alat seperti Terraform untuk mengotomatiskan penyediaan infrastruktur CI/CD.
- Pantau dan debug pengujian Anda dengan Cloud Logging dan Cloud Monitoring: Kemampuan Observasi Google Cloud menyediakan alat logging dan pemantauan yang dapat Anda akses melalui panggilan API. Artinya, 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 di BCP Anda: misalnya, Anda dapat menguji apakah izin dan akses pengguna berfungsi di lingkungan DR seperti yang dilakukan di lingkungan produksi. Anda dapat melakukan pengujian integrasi dan fungsional di lingkungan DR. Anda juga dapat melakukan pengujian saat jalur akses yang biasa Anda gunakan ke Google Cloud tidak berfungsi.
Di Google, kami secara rutin menguji BCP melalui proses yang disebut DiRT (Disaster Recovery Testing). Pengujian ini membantu Google memverifikasi dampak, otomatisasi, dan mengekspos risiko yang tidak diperhitungkan. Perubahan pada otomatisasi dan BCP yang perlu diterapkan adalah output penting dari DiRT.
Praktik terbaik
Di bagian ini, Anda akan mempelajari beberapa praktik terbaik yang dapat diterapkan untuk mencapai tujuan RTO dan RPO. Praktik terbaik ini berlaku secara luas untuk DR untuk CI/CD, dan bukan untuk alat tertentu. Terlepas dari penerapan Anda, Anda harus menguji BCP secara rutin untuk memastikan bahwa ketersediaan tinggi, RTO, dan RPO memenuhi persyaratan Anda. Jika terjadi insiden atau bencana, Anda juga harus melakukan retrospective dan menganalisis proses Anda agar dapat meningkatkannya.
Ketersediaan tinggi
Untuk setiap alat, Anda harus berupaya menerapkan praktik terbaik untuk ketersediaan tinggi. Dengan mengikuti praktik terbaik untuk ketersediaan tinggi, proses CI/CD Anda akan berada dalam sikap yang lebih proaktif karena praktik ini membuat proses CI/CD lebih tangguh terhadap kegagalan. Strategi proaktif ini harus digunakan dengan kontrol dan prosedur yang lebih reaktif untuk pemulihan dan pencadangan.
Berikut adalah beberapa praktik terbaik untuk mencapai ketersediaan tinggi. Namun, baca dokumentasi mendetail untuk setiap alat di CI/CD Anda untuk mengetahui praktik terbaik yang lebih mendetail:
- Layanan terkelola: menggunakan layanan terkelola akan mengalihkan tanggung jawab operasional ke Google Cloud.
- Penskalaan otomatis: jika memungkinkan, gunakan penskalaan otomatis. Aspek utama penskalaan otomatis adalah instance pekerja dibuat secara dinamis, sehingga pemulihan node yang gagal bersifat otomatis.
- Deployment global dan multi-region: jika memungkinkan, gunakan deployment global dan multi-region, bukan deployment regional. Misalnya, Anda dapat mengonfigurasi Artifact Registry untuk penyimpanan multi-region.
- Dependensi: pahami semua dependensi alat Anda dan pastikan dependensi tersebut sangat tersedia. Misalnya, Anda dapat meng-cache semua library pihak ketiga di registry artefak.
Prosedur pencadangan
Saat Anda menerapkan DR untuk CI/CD, beberapa alat dan proses lebih cocok untuk strategi pencadangan/pemulihan. Strategi pencadangan yang komprehensif adalah langkah pertama untuk kontrol reaktif yang efektif. Pencadangan memungkinkan Anda memulihkan pipeline CI/CD dengan gangguan minimal jika terjadi serangan pihak tidak bertanggung jawab atau skenario bencana.
Sebagai titik awal, Anda harus menerapkan tiga praktik terbaik berikut. Namun, untuk praktik terbaik pencadangan yang lebih mendetail, lihat dokumentasi untuk setiap alat dalam proses CI/CD Anda.
- Kontrol sumber: simpan file konfigurasi dan apa pun yang Anda kodifikasi, seperti
skrip dan kebijakan otomatisasi, dalam kontrol sumber. Contohnya mencakup
file YAML
cloudbuild.yamldan Kubernetes. - Redundansi: memastikan tidak ada titik tunggal kegagalan terkait akses ke secret seperti sandi, sertifikat, dan kunci API. Contoh praktik yang harus dihindari mencakup hanya satu orang yang mengetahui sandi atau menyimpan kunci API hanya di satu server di wilayah tertentu.
- Pencadangan: sering kali verifikasi kelengkapan dan akurasi cadangan Anda. Layanan terkelola seperti Pencadangan untuk GKE akan membantu menyederhanakan proses verifikasi Anda.
Prosedur pemulihan
DR juga memerlukan prosedur pemulihan untuk melengkapi proses pencadangan. Prosedur pemulihan Anda, yang dikombinasikan dengan pencadangan lengkap, akan menentukan seberapa cepat Anda dapat merespons skenario bencana.
Pengelolaan dependensi
Pipeline CI/CD Anda dapat memiliki banyak dependensi, yang juga dapat menjadi sumber kegagalan. Daftar lengkap dependensi harus diidentifikasi seperti yang dijelaskan sebelumnya dalam dokumen ini di Mengidentifikasi data dan dependensi. Namun, dua sumber dependensi yang paling umum adalah sebagai berikut:
- Artefak aplikasi: misalnya, paket, library, dan image
- Sistem eksternal: misalnya, sistem tiket dan notifikasi
Salah satu cara untuk memitigasi risiko dependensi adalah dengan mengadopsi praktik vendoring. Menjual paket atau image aplikasi adalah proses pembuatan dan penyimpanan salinannya di repositori pribadi. Vendoring menghapus dependensi pada sumber eksternal untuk paket atau image ini, dan juga dapat membantu mencegah malware disisipkan ke dalam supply chain software.
Beberapa manfaat vendoring paket atau image aplikasi mencakup hal berikut:
- Keamanan: vendoring menghapus dependensi pada sumber eksternal untuk paket atau image aplikasi, yang dapat membantu mencegah serangan insersi malware.
- Kontrol: dengan menyediakan paket atau image mereka sendiri, organisasi dapat memiliki kontrol lebih besar atas sumber paket dan image ini.
- Kepatuhan: vendoring dapat membantu organisasi mematuhi peraturan industri, seperti Sertifikasi Model Kematangan Keamanan Cyber.
Jika tim Anda memutuskan untuk menggunakan paket atau image aplikasi vendor, ikuti langkah-langkah utama berikut:
- Identifikasi paket atau image aplikasi yang perlu di-vendor.
- Buat repositori pribadi untuk menyimpan paket atau image vendor.
- Download paket atau image dari sumber asli dan simpan di repositori pribadi.
- Verifikasi integritas paket atau image.
- Perbarui paket atau image vendor sesuai kebutuhan.
Pipeline CI/CD sering memanggil sistem pihak eksternal untuk melakukan tindakan seperti menjalankan pemindaian, mencatat tiket, atau mengirim notifikasi. Pada umumnya, sistem pihak eksternal ini memiliki strategi DR sendiri yang harus diterapkan. Namun, dalam beberapa kasus, mereka mungkin tidak memiliki rencana DR yang sesuai, dan kasus tersebut harus didokumentasikan dengan jelas dalam BCP. Kemudian, Anda harus memutuskan apakah tahap tersebut dalam pipeline dapat dilewati karena alasan ketersediaan, atau apakah dapat diterima untuk menyebabkan downtime pada pipeline CI/CD.
Pemantauan dan notifikasi
CI/CD Anda sama seperti sistem produksi aplikasi, sehingga Anda juga perlu menerapkan teknik pemantauan dan notifikasi untuk alat CI/CD. Sebagai praktik terbaik, sebaiknya Anda menerapkan dasbor dan notifikasi pemberitahuan. Repositori contoh GitHub untuk Cloud Monitoring memiliki banyak contoh dasbor dan kebijakan pemberitahuan.
Anda juga dapat menerapkan tingkat pemantauan tambahan, seperti Indikator Tingkat Layanan (SLI) dan Tujuan Tingkat Layanan (SLO). Tingkat pemantauan ini membantu melacak kondisi dan performa keseluruhan pipeline CI/CD Anda. Misalnya, SLO dapat diterapkan untuk melacak latensi tahap build dan deployment. SLO ini membantu tim mem-build dan merilis aplikasi dengan kecepatan dan frekuensi yang Anda inginkan.
Prosedur akses darurat
Selama bencana, tim operasi mungkin perlu mengambil tindakan di luar prosedur standar dan mendapatkan akses darurat ke sistem dan alat. Tindakan darurat semacam itu terkadang disebut sebagai prosedur pecah kaca. Sebagai titik awal, Anda harus menerapkan tiga praktik terbaik ini:
- Memiliki rencana dan prosedur eskalasi yang jelas. Rencana yang jelas membantu tim operasi mengetahui kapan mereka perlu menggunakan prosedur akses darurat.
- Pastikan beberapa orang memiliki akses ke informasi penting, seperti konfigurasi dan secret.
- Kembangkan metode audit otomatis, sehingga Anda dapat melacak kapan prosedur akses darurat digunakan dan siapa yang menggunakannya.
Langkah selanjutnya
- Pelajari lebih lanjut produk Google Cloud yang digunakan dalam dokumen ini:
- Lihat Panduan perencanaan pemulihan dari bencana.
- Coba fitur Google Cloud lainnya dengan menyelesaikan tutorial kami.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis:
- Ben Good | Solutions Architect
- Xiang Shen | Solutions Architect
Kontributor lainnya:
- Marco Ferrari | Cloud Solutions Architect
- Anuradha Bajpai | Solutions Architect
- Rodd Zurcher | Solutions Architect