Dokumen ini menjelaskan pemulihan dari bencana (DR) dan perencanaan kelangsungan bisnis dalam konteks continuous integration dan continuous delivery (CI/CD). Panduan ini juga memberikan arahan tentang cara mengidentifikasi dan memitigasi dependensi saat Anda mengembangkan rencana keberlanjutan bisnis (BCP) yang komprehensif. Dokumen ini mencakup praktik terbaik yang dapat Anda terapkan pada BCP, terlepas dari alat dan proses yang Anda gunakan. Dokumen ini mengasumsikan bahwa Anda sudah memahami dasar-dasar siklus pengiriman dan operasi software, CI/CD, dan DR.
Pipeline CI/CD bertanggung jawab untuk membangun dan men-deploy aplikasi penting bisnis Anda. Oleh karena itu, seperti infrastruktur aplikasi Anda, proses CI/CD Anda memerlukan perencanaan untuk DR dan kelangsungan bisnis. Saat memikirkan DR dan kelangsungan bisnis untuk CI/CD, Anda harus memahami setiap fase siklus pengiriman dan operasi software, serta memahami cara kerjanya bersama sebagai proses holistik.
Diagram berikut adalah tampilan sederhana dari siklus pengembangan dan operasi software, yang mencakup tiga fase berikut:
- Loop dalam pengembangan: kode, coba, dan lakukan commit
- Continuous integration: build, pengujian, dan keamanan
- Continuous delivery: promosikan, luncurkan, rollback, dan metrik
Diagram ini juga menunjukkan bahwa Google Kubernetes Engine (GKE), Cloud Run, dan Google Distributed Cloud adalah target deployment yang memungkinkan untuk siklus pengembangan dan operasi software.
Selama siklus pengembangan dan operasi software, Anda perlu mempertimbangkan dampak bencana terhadap kemampuan tim untuk mengoperasikan dan memelihara aplikasi penting bisnis. Dengan melakukannya, Anda akan dapat menentukan Batas Waktu Pemulihan (RTO) dan Toleransi Durasi Kehilangan Data (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 perencanaan DR dan 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. Anda harus mengidentifikasi pipeline penting bisnis dalam BCP Anda, dan pipeline tersebut juga harus mendapatkan perhatian lebih saat Anda menerapkan praktik terbaik untuk menguji dan menjalankan prosedur pemulihan.
Karena setiap proses CI/CD dan toolchain-nya berbeda, tujuan panduan ini adalah membantu Anda mengidentifikasi titik kegagalan tunggal dalam proses CI/CD dan mengembangkan BCP yang komprehensif. Bagian berikut akan membantu Anda melakukan hal-hal berikut:
- Pahami apa 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 dengan cepat kembali ke kondisi operasi normal 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 khususnya relevan untuk merencanakan kelangsungan bisnis untuk CI/CD diuraikan di bagian berikut, dan juga menjadi dasar untuk panduan di bagian lain dalam 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 pimpinan: pastikan bahwa manajemen senior mendukung dan memperjuangkan pengembangan BCP. Tugaskan tim khusus atau individu yang bertanggung jawab untuk mengawasi rencana tersebut.
- Alokasi resource: alokasikan anggaran, personel, dan resource yang diperlukan untuk mengembangkan dan menerapkan BCP.
- Ruang lingkup dan tujuan: tentukan ruang lingkup BCP dan tujuannya. Tentukan proses bisnis mana yang penting dan perlu ditangani dalam rencana.
- Penilaian risiko: mengidentifikasi potensi risiko dan ancaman yang dapat mengganggu bisnis Anda, seperti bencana alam, pelanggaran keamanan siber, atau gangguan rantai pasokan.
- Analisis dampak: menilai potensi konsekuensi dari temuan penilaian risiko ini terhadap operasi bisnis, keuangan, reputasi, dan kepuasan pelanggan 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 berbagai alat 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, pemahaman tentang toolchain CI/CD Anda–termasuk dependensinya dan cara kerjanya dalam siklus proses DevOps Anda–adalah elemen penyusun mendasar 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 kelanjutan operasi proses CI/CD Anda melalui toolchain-nya.
- RTO dan RPO: tentukan batas yang dapat diterima untuk batas waktu nonaktif dan batas kehilangan data untuk setiap fungsi penting. Target RTO dan RPO ini terkait dengan pentingnya fungsi bisnis untuk kelangsungan operasi, dan melibatkan alat khusus 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 penting. 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 dengan vendor dan pemasok: buat rencana komunikasi dan koordinasi dengan vendor dan pemasok utama untuk menjaga kelancaran rantai pasokan selama gangguan.
- Pemulihan data dan IT: buat rencana untuk pencadangan data, pemulihan sistem IT, dan langkah-langkah keamanan siber.
- Rencana komunikasi: buat 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 dilakukan pada rencana, dan rencana harus diperlakukan sebagai dokumen yang terus diperbarui.
Penerapan
Pada tahap ini, Anda menerapkan rencana untuk organisasi Anda dengan menggunakan BCP yang dibuat oleh tim teknis. Implementasi mencakup pelatihan karyawan dan pengujian awal BCP. Implementasi juga mencakup penggunaan rencana jika terjadi gangguan untuk memulihkan operasi reguler. Langkah-langkah penerapan utama mencakup hal berikut:
- Pengujian dan pelatihan awal: setelah BPC didokumentasikan, uji BPC tersebut melalui simulasi dan latihan untuk mengidentifikasi kesenjangan dan meningkatkan efektivitas. Latih karyawan tentang peran dan tanggung jawab mereka selama terjadi gangguan.
- Aktivasi: saat gangguan terjadi, memulai BCP sesuai dengan pemicu dan prosedur yang telah ditentukan sebelumnya.
- Komunikasi: terus memberi tahu pemangku kepentingan tentang situasi dan upaya pemulihan.
Pemeliharaan dan peninjauan
Tahap ini bukan proses yang ditentukan yang hanya terjadi satu kali–melainkan, tahap ini mewakili upaya berkelanjutan yang harus menjadi bagian normal dari operasi CI/CD Anda. Penting untuk meninjau, menguji, dan memperbarui BCP secara rutin dalam organisasi Anda agar tetap relevan dan dapat ditindaklanjuti jika terjadi gangguan. Langkah-langkah utama pemeliharaan dan peninjauan meliputi hal berikut:
- Pembaruan rutin: tinjau dan perbarui BCP secara berkala agar tetap relevan dan efektif. Perbarui setiap kali ada perubahan pada personel, teknologi, atau proses bisnis.
- Pelajaran yang didapat: setelah setiap gangguan atau pengujian, lakukan diskusi singkat 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.
Membangun proses kelangsungan bisnis untuk CI/CD
Bagian ini memberikan panduan khusus untuk membangun BCP yang secara khusus berfokus pada pemulihan operasi CI/CD Anda. Proses perencanaan kelangsungan bisnis untuk CI/CD dimulai dengan pemahaman menyeluruh tentang toolchain CI/CD Anda, dan bagaimana toolchain tersebut terkait dengan siklus proses pengiriman dan operasi software. Dengan pemahaman ini sebagai fondasi, 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
- Tentukan target RTO dan RPO
- Memilih strategi tingkat tinggi untuk keberlangsungan bisnis
- Mendokumentasikan BCP Anda 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 rangkaian alat CI/CD dan dependensinya adalah kunci untuk perencanaan kelangsungan bisnis bagi CI/CD. Misi utama proses CI/CD Anda adalah mengirimkan kode ke sistem produksi untuk digunakan oleh 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 Anda.
Untuk membantu Anda memahami cara mengevaluasi toolchain 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 dalam diagram, alur utama untuk aplikasi contoh adalah sebagai berikut:
- Peristiwa pengembangan kode dalam loop dalam pengembangan memicu Cloud Build.
- Cloud Build menarik 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 menarik 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 mengambil image container dari repositori dan men-deploy-nya ke lingkungan GKE.
Untuk memahami alat yang digunakan dalam proses CI/CD Anda, sebaiknya buat diagram yang menunjukkan proses CI/CD dan alat yang digunakan di dalamnya, mirip dengan contoh dalam dokumen ini. Kemudian, Anda dapat menggunakan diagram untuk membuat tabel yang mencatat informasi penting tentang toolchain CI/CD, seperti fase proses, tujuan alat, alat itu sendiri, dan tim yang terpengaruh oleh kegagalan alat. Tabel ini menyediakan pemetaan alat dalam toolchain Anda dan mengidentifikasi alat dengan fase tertentu dari proses CI/CD. Dengan demikian, tabel ini dapat membantu Anda mendapatkan gambaran umum 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 mencakup alat lain yang tidak disebutkan dalam diagram, seperti alat keamanan atau alat pengujian.
Tabel pertama dipetakan ke alat yang digunakan dalam fase CI proses CI/CD:
| Continuous integration | Sumber | Alat yang digunakan | Pengguna utama | Penggunaan |
|---|---|---|---|---|
| Fase: Kontrol sumber |
|
|
|
|
| Fase: Membangun |
|
Developer |
|
|
| Fase: Pengujian |
|
Developer |
Jalankan pengujian unit dan integrasi dalam platform yang konsisten dan sesuai permintaan. |
|
| Fase: Keamanan |
|
|
Pindai kode untuk mengetahui masalah keamanan. |
Tabel kedua berfokus pada alat yang digunakan dalam fase CD 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 kemampuan pengamatan dan pemecahan masalah. |
|
| Fase: Pemantauan | Pemantauan file konfigurasi, termasuk berikut ini:
|
|
|
Seiring Anda terus mengerjakan BCP dan pemahaman Anda tentang toolchain CI/CD meningkat, Anda dapat memperbarui diagram dan tabel pemetaan.
Mengidentifikasi data dan dependensi
Setelah Anda menyelesaikan inventaris dasar dan peta toolchain CI/CD, langkah selanjutnya adalah merekam dependensi pada metadata atau konfigurasi. Saat menerapkan BCP, Anda harus memahami dengan jelas dependensi dalam toolchain CI/CD. Dependensi biasanya dibagi menjadi dua kategori: dependensi internal (urutan pertama) dan dependensi eksternal (urutan kedua atau ketiga).
Dependensi internal
Dependensi internal adalah sistem yang digunakan toolchain Anda dan yang dapat Anda kontrol secara langsung. Ketergantungan internal juga dipilih oleh tim Anda. Sistem ini mencakup alat CI, penyimpanan pengelolaan kunci, dan sistem kontrol sumber Anda. Anda dapat menganggap sistem ini berada di lapisan berikutnya dari toolchain itu sendiri.
Misalnya, diagram berikut memberikan contoh cara kecocokan dependensi
internal 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 di 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 menilai apakah suatu 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
deployment. 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 aplikasi Java contoh harus memperhitungkan dependensi ini pada file deploy.yaml dan cloudbuild.yaml karena file tersebut membuat ulang pipeline CI/CD setelah alat tersedia 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 diandalkan oleh toolchain Anda untuk beroperasi, dan sistem tersebut 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 Anda. 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 menjadi penting untuk proses CI/CD Anda: Cloud Build dan GKE mengandalkan dua layanan eksternal (Maven dan Docker) agar dapat berfungsi dengan baik. Saat menilai toolchain Anda sendiri, dokumentasikan dependensi eksternal yang perlu diakses alat Anda dan prosedur untuk menangani gangguan dependensi.
Dalam contoh aplikasi Java, library Java dan image Docker tidak dapat dikontrol secara langsung, tetapi Anda tetap 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 memperbarui library Java secara berkala ke repositori Maven lokal atau Artifact Registry. Dengan begitu, proses pemulihan Anda tidak perlu mengandalkan ketersediaan sumber pihak ketiga.
Selain itu, penting untuk dipahami bahwa dependensi eksternal dapat memiliki lebih dari satu lapisan. Misalnya, Anda dapat menganggap sistem yang digunakan oleh dependensi internal Anda sebagai dependensi tingkat kedua. Dependensi tingkat kedua ini mungkin memiliki dependensi sendiri, yang dapat Anda anggap sebagai dependensi tingkat ketiga. Perlu diketahui bahwa Anda mungkin perlu mendokumentasikan dan memperhitungkan dependensi eksternal tingkat kedua dan ketiga dalam BCP Anda untuk memulihkan operasi selama gangguan.
Menentukan target RTO dan RPO
Setelah memahami toolchain dan dependensi, Anda menentukan target RTO dan RPO untuk alat Anda. Setiap alat dalam proses CI/CD melakukan tindakan yang berbeda yang dapat memberikan dampak berbeda pada bisnis. Oleh karena itu, penting untuk mencocokkan prioritas target RTO dan RPO fungsi bisnis dengan dampaknya terhadap bisnis. Misalnya, membangun versi baru aplikasi melalui tahap CI mungkin tidak terlalu berpengaruh 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 Anda dapat menentukan target RTO dan RPO untuk setiap komponen toolchain CI/CD. Rantai alat 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 ini menampilkan 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 sedang pada developer, dampak tinggi pada operasi: pipeline deployment
- Dampak developer tinggi, dampak operasi rendah: loop dalam dev
- Dampak tinggi bagi developer, dampak sedang bagi operasi: pipeline CI, pipeline infrastructure as code (IaC)
- Dampak tinggi bagi developer, dampak tinggi bagi operasi: pengelolaan kontrol sumber (SCM), Artifact Registry
Komponen seperti pengelolaan kontrol sumber dan Artifact Registry yang memiliki dampak tinggi pada developer dan dampak operasional memiliki dampak terbesar pada bisnis. Komponen ini harus memiliki tujuan RTO dan RPO terendah. Komponen di kuadran lainnya 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 seberapa besar kehilangan data atau konfigurasi yang dapat ditoleransi dibandingkan dengan jumlah waktu yang diperlukan untuk memulihkan layanan untuk komponen tersebut.
Misalnya, pertimbangkan berbagai lokasi Artifact Registry dan pipeline IaC dalam grafik. Perbandingan kedua alat ini menunjukkan bahwa gangguan Artifact Registry memiliki dampak yang lebih besar terhadap operasi bisnis daripada gangguan di pipeline IaC. Karena gangguan Artifact Registry berdampak signifikan terhadap kemampuan Anda untuk men-deploy atau menskalakan otomatis aplikasi, maka alat ini akan memiliki target RTO dan RPO yang lebih rendah dibandingkan dengan alat lainnya. Sebaliknya, grafik menunjukkan bahwa gangguan pipeline IaC memiliki dampak yang lebih kecil pada operasi bisnis dibandingkan 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 terjadi gangguan.
Memilih strategi tingkat tinggi untuk kelangsungan bisnis
Proses kelangsungan bisnis untuk aplikasi produksi sering kali mengandalkan salah satu dari tiga strategi DR umum. Namun, untuk CI/CD, Anda dapat memilih antara dua strategi tingkat tinggi untuk kelangsungan bisnis: aktif/pasif atau pencadangan/pemulihan. Strategi yang Anda pilih akan bergantung pada persyaratan dan anggaran Anda. Setiap strategi memiliki pertimbangan 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 memengaruhi lebih dari penerapan CI/CD Anda. Anda juga harus mempertimbangkan semua infrastruktur yang Anda butuhkan, termasuk jaringan, komputasi, dan penyimpanan. Anda harus memiliki rencana DR untuk elemen penyusun tersebut dan mengujinya secara rutin untuk memastikan efektivitasnya.
Aktif/pasif
Dengan strategi aktif/pasif (atau standby hangat), aplikasi dan pipeline CI/CD pasif Anda adalah cerminan. 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 cocok untuk aplikasi penting bisnis yang dapat menoleransi sedikit periode nonaktif.
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 pipeline CI/CD 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 membangun, menguji, dan men-deploy ke lingkungan produksi multiregional.
Jika terjadi masalah kritis untuk pipeline region1, seperti pemadaman layanan regional suatu produk, hasilnya dapat berupa deployment yang gagal atau build yang tidak berhasil. Untuk memulihkan masalah dengan cepat, Anda dapat memperbarui pemicu untuk repositori Git dan beralih ke pipeline region2, yang kemudian menjadi pipeline aktif. Setelah masalah diselesaikan di region1, Anda dapat mempertahankan pipeline di region1 sebagai pasif.
Keuntungan strategi aktif/pasif meliputi:
- Waktu henti rendah: karena pipeline pasif telah di-deploy, tetapi diturunkan skalanya, jumlah waktu henti terbatas pada waktu yang diperlukan untuk menaikkan skala pipeline.
- Toleransi yang dapat dikonfigurasi untuk kehilangan data: dengan strategi ini, konfigurasi dan artefak harus disinkronkan secara berkala. Namun, jumlahnya dapat dikonfigurasi berdasarkan persyaratan Anda, yang dapat mengurangi kompleksitas.
Kekurangan strategi ini meliputi:
- Biaya: dengan infrastruktur yang diduplikasi, strategi ini meningkatkan biaya keseluruhan infrastruktur CI/CD Anda.
Mencadangkan/memulihkan
Dengan strategi pencadangan/pemulihan, Anda membuat pipeline failover hanya saat 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 sebagian pipeline CI/CD aplikasi di region yang berbeda.
Serupa dengan contoh sebelumnya, region1 menghosting pipeline CI/CD aktif. Alih-alih 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 masalah kritis terjadi di pipeline region1, seperti pemadaman 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 membangun ulang pipeline CI/CD di region2.
Jika gangguan adalah peristiwa berskala besar, Anda mungkin bersaing dengan pelanggan lain untuk mendapatkan 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 dari strategi pencadangan/pemulihan mencakup hal berikut:
- Biaya: strategi ini menimbulkan biaya terendah karena Anda hanya men-deploy pipeline cadangan selama skenario DR.
Kekurangan strategi ini meliputi:
- Waktu nonaktif: strategi ini memerlukan lebih banyak waktu untuk diterapkan karena Anda membuat pipeline failover saat Anda membutuhkannya. Daripada memiliki pipeline bawaan, layanan perlu dibuat dan dikonfigurasi selama pemulihan insiden. Waktu build artefak dan waktu untuk mengambil dependensi eksternal juga bisa jauh lebih lama.
Mendokumentasikan BCP Anda dan menerapkan praktik terbaik
Setelah Anda 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 yang harus diikuti oleh karyawan dalam peran tertentu selama gangguan.
Setelah menentukan BCP, Anda men-deploy atau mengupdate toolchain CI/CD menggunakan praktik terbaik untuk mencapai target RTO dan RPO. Meskipun toolchain CI/CD dapat sangat berbeda, dua pola utama untuk praktik terbaik umumnya sama terlepas dari toolchain: pemahaman yang komprehensif tentang dependensi dan penerapan otomatisasi.
Sehubungan dengan dependensi, sebagian besar BCP menangani sistem secara langsung dalam kontrol Anda. Namun, ingatlah bahwa dependensi eksternal tingkat kedua atau ketiga mungkin sama pentingnya, jadi penting untuk menerapkan praktik terbaik dan langkah-langkah redundansi untuk dependensi penting tersebut juga. Library Java eksternal dalam contoh aplikasi adalah contoh dependensi urutan ketiga. Jika Anda tidak memiliki repositori atau cadangan lokal untuk library tersebut, Anda mungkin tidak dapat membuat aplikasi jika sumber eksternal tempat Anda menarik library terputus.
Dalam hal otomatisasi, penerapan praktik terbaik harus digabungkan ke dalam strategi IaC cloud secara keseluruhan. Solusi IaC Anda harus menggunakan alat seperti Terraform untuk menyediakan resource yang diperlukan secara otomatis untuk penerapan CI/CD dan mengonfigurasi proses. Praktik IaC adalah prosedur pemulihan yang sangat efektif karena dimasukkan ke dalam fungsi sehari-hari pipeline CI/CD Anda. Selain itu, IaC mendorong penyimpanan file konfigurasi Anda dalam kontrol sumber, yang pada gilirannya 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 Anda secara rutin dan berkelanjutan. Pengujian BCP dan prosedur pemulihan memverifikasi bahwa rencana tersebut masih valid dan target RPO dan RTO yang didokumentasikan dapat diterima. Namun, yang paling penting, pengujian, pembaruan, dan pemeliharaan rutin menjadikan pelaksanaan BCP sebagai bagian dari operasi normal. Dengan menggunakan Google Cloud, Anda dapat menguji skenario pemulihan dengan biaya minimal. Sebaiknya Anda melakukan 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: Google Cloud Observability menyediakan alat logging dan pemantauan yang dapat Anda akses melalui panggilan API, yang berarti 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. Anda juga dapat melakukan pengujian di mana jalur akses biasa Anda ke Google Cloud tidak berfungsi.
Di Google, kami secara rutin menguji BCP kami melalui proses yang disebut DiRT (Pengujian Pemulihan Bencana). Pengujian ini membantu Google memverifikasi dampak, otomatisasi, dan memaparkan risiko yang tidak diperhitungkan. Perubahan pada otomatisasi dan BCP yang perlu diterapkan adalah hasil penting dari DiRT.
Praktik terbaik
Di bagian ini, Anda akan mempelajari beberapa praktik terbaik yang dapat diterapkan untuk mencapai tujuan RTO dan RPO Anda. 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 ketersediaan tinggi, RTO, dan RPO memenuhi persyaratan Anda. Jika terjadi insiden atau bencana, Anda juga harus melakukan retrospeksi dan menganalisis proses Anda agar dapat meningkatkannya.
Ketersediaan tinggi
Untuk setiap alat, Anda harus berupaya menerapkan praktik terbaik untuk ketersediaan tinggi. Mengikuti praktik terbaik untuk ketersediaan tinggi akan membuat proses CI/CD Anda 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 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 memiliki ketersediaan tinggi. Misalnya, Anda dapat menyimpan dalam cache semua library pihak ketiga di registry artefak Anda.
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 skenario bencana atau tindakan pihak yang tidak bertanggung jawab.
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
cloudbuild.yamldan file YAML Kubernetes. - Redundansi: pastikan tidak ada titik tunggal kegagalan terkait mengakses 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 pencadangan 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 bagian Mengidentifikasi data dan dependensi. Namun, dua sumber dependensi yang paling umum adalah sebagai berikut:
- Artefak aplikasi: misalnya, paket, library, dan gambar
- Sistem eksternal: misalnya, sistem tiket dan notifikasi
Salah satu cara untuk mengurangi risiko dependensi adalah dengan menerapkan praktik vendoring. Paket atau image aplikasi vendor adalah proses pembuatan dan penyimpanan salinannya di repositori pribadi. Vendoring menghilangkan dependensi pada sumber eksternal untuk paket atau image ini, dan juga dapat membantu mencegah malware dimasukkan ke dalam rantai pasokan software.
Beberapa manfaat paket atau image aplikasi vendor mencakup hal berikut:
- Keamanan: vendor menghilangkan dependensi pada sumber eksternal untuk paket atau gambar aplikasi, yang dapat membantu mencegah serangan penyisipan malware.
- Kontrol: dengan menyediakan paket atau image mereka sendiri, organisasi dapat memiliki kontrol yang lebih besar atas sumber paket dan image ini.
- Kepatuhan: penggunaan vendor dapat membantu organisasi mematuhi peraturan industri, seperti Sertifikasi Model Kematangan Pengamanan Cyber.
Jika tim Anda memutuskan untuk memaketkan atau membuat gambar aplikasi vendor, ikuti langkah-langkah utama berikut:
- Identifikasi paket atau gambar aplikasi yang perlu di-vendor.
- Buat repositori pribadi untuk menyimpan paket atau image yang di-vendor.
- Download paket atau image dari sumber asli dan simpan di repositori pribadi.
- Verifikasi integritas paket atau image.
- Perbarui paket atau gambar yang disediakan vendor sesuai kebutuhan.
Pipeline CI/CD sering memanggil sistem pihak eksternal untuk melakukan tindakan seperti menjalankan pemindaian, mencatat tiket, atau mengirim notifikasi. Biasanya, sistem pihak eksternal ini memiliki strategi DR sendiri yang harus diterapkan. Namun, dalam beberapa kasus, mereka mungkin tidak memiliki rencana DR yang sesuai, dan instance tersebut harus didokumentasikan dengan jelas dalam BCP. Kemudian, Anda harus memutuskan apakah tahap-tahap tersebut dalam pipeline dapat dilewati karena alasan ketersediaan, atau apakah dapat diterima jika menyebabkan periode nonaktif untuk pipeline CI/CD.
Pemantauan dan notifikasi
CI/CD Anda sama seperti sistem produksi aplikasi, jadi Anda juga perlu menerapkan teknik pemantauan dan notifikasi untuk alat CI/CD Anda. Sebagai praktik terbaik, sebaiknya Anda menerapkan dasbor dan notifikasi pemberitahuan. Repositori sampel 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 kesehatan dan performa keseluruhan pipeline CI/CD Anda. Misalnya, SLO dapat diterapkan untuk melacak latensi tahap build dan deployment. SLO ini membantu tim membangun dan merilis aplikasi dengan kecepatan dan frekuensi yang Anda inginkan.
Prosedur akses darurat
Selama terjadi 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 breakglass. Sebagai titik awal, Anda harus menerapkan tiga praktik terbaik berikut:
- 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.
- Mengembangkan metode audit otomatis, sehingga Anda dapat melacak kapan prosedur akses darurat digunakan dan siapa yang menggunakannya.
Langkah berikutnya
- 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