Anda mungkin sedang di tengah-tengah rilis ketika masalah ini muncul. Bangunan hijau, tim seluler siap untuk memasukkan, dan satu node pinggir mulai menurunkan lalu lintas atau jalur backend menjadi aneh sehingga membuat peluncuran tidak aman. Pada titik itu, memiliki "cadangan" bukanlah sama dengan memiliki sistem yang dapat terus melayani pengguna.
Jarak itu adalah apa Redundansi dan Failover Benar-benar tentang apa itu redundansi failover. Redundansi memberikan Anda jalur alternatif, komponen, atau salinan status. Failover adalah keputusan dan koordinasi yang memindahkan pekerjaan ke salah satu alternatif ketika sesuatu rusak.
Bagi tim mobile dan CI/CD, hal ini lebih penting daripada sebagian besar daftar checklist infrastruktur mengakui. Platform update hidup bukan hanya alat publikasi, tetapi juga rantai routing, tanda tangan, penyimpanan, pengiriman edge, pengecekan perangkat, dan perilaku rollback. Jika salah satu link dalam rantai tersebut tidak dapat fail over dengan bersih, jalur rilis seluruhnya masih bisa runtuh.
Daftar Isi
- Ketika Cadangan Tidak Cukup
- Redundansi dan Failover Didefinisikan sebagai Pasangannya
- Polanya Arsitektur yang Umum dan Kapan Menggunakannya
- Failover Berat dan Ambang Batas yang Berlapis
- Menerapkan Failover ke CI/CD dan Pengiriman Update Langsung
- Platform Update Edge sebagai Rantai Failover
- Menguji Failover Sebelum Anda Membutuhkannya
- Daftar Periksa Praktis untuk Tim yang Mengirimkan Update Langsung
When a Backup Tidak Cukup
Kasus yang sangat umum dimulai dengan rilis yang tampaknya tidak berbahaya. Paket aplikasi melewati tahap staging, sistem deploy berperilaku normal, dan tim mengharapkan peluncuran rutin. Kemudian node edge regional menurun, satu jalur mulai mengembalikan signal kesehatan yang buruk, dan rilis harus dihentikan sementara semua orang bertanya pertanyaan yang sama, “Apakah kita dapat bertahan dari kegagalan ini, atau hanya mendeteksinya?”
Yaitu celah antara memiliki infrastruktur backup dan memiliki desain redundansi yang nyata. redundancy failover Desain yang sebenarnya tidak hanya memiliki server cadangan yang duduk di rak, tetapi juga routing layer yang tidak pernah menunjuk pengguna ke server cadangan itu, layanan autentikasi tidak dapat mencapai server cadangan, atau proses pengembangan tidak mengetahui kapan harus beralih.
Microsoft's arsitektur guidance membuat celah ini jelas, ia merekomendasikan pengujian dan validasi komponen redundan, sinkronisasi failover depan dan belakang, dan menggunakan failover otomatis dengan manual failback, karena duplikasi sederhana tidak menjamin recovery bekerja secara end-to-end.
Backup yang tidak pernah dilatihkan hanya harapan dengan garis anggaran. Model yang berguna memiliki empat bagian. Redundansi menjawab apa saja jalur ganda atau alternatif yang ada. Failover menjawab bagaimana sistem berpindah ke sana. menjelaskan bagaimana rantai lainnya kembali ke keadaan yang seimbang. Validasi menjawab apakah semuanya berfungsi dengan kondisi nyata, bukan hanya di papan tulis putih.
Sebuah tim mobile melihat hal ini dengan jelas dalam pengiriman update langsung. Jika sebuah layanan tidak dapat menandatangani, menyimpan, mengirim, dan memverifikasi bundle setelah kegagalan sebagian, maka platform mungkin terlihat redundant di satu lapisan yang sempit dan masih gagal melayani pengguna di produksi. Gagalnya biasanya bukan satu box yang rusak, melainkan tukar menukar antara box, atau asumsi bahwa orang lain akan mengamati dan mengganti. Logika yang sama berlaku pada tanggapan insiden, di mana menit pertama lebih penting daripada diagram arsitektur, seperti yang dijelaskan dalam Capgo’s panduan tanggapan insiden.
Ringkasan yang berguna dari menyokong pelajaran yang sama, duplikasi hanya membantu ketika sistem lain dapat berpindah kepadanya. Redundansi dan Failover Didefinisikan sebagai Pasangannya
Redundansi dan failover seringkali dibicarakan seperti mereka adalah hal yang sama. Mereka bukan.
Redundansi adalah kehadiran lebih dari satu komponen yang dapat melakukan pekerjaan yang sama. Redundansi dan Failover Failover Adalah tindakan mengalihkan tanggung jawab dari komponen yang gagal ke komponen yang sehat.
Analogi dapur yang menempel
Pikirkan tentang dapur restoran yang sibuk. Jika ada beberapa koki yang dapat memasak menu yang sama, itu adalah redundansi. Jika kepala koki melihat seseorang terbakar dan langsung menugaskan tiket berikutnya kepada orang lain, itu adalah failover.
Dapur masih membutuhkan lebih dari orang-orang. Dapur membutuhkan cara untuk mengenali kegagalan, aturan untuk siapa yang mengambil alih, dan cara untuk menjaga pesanan berjalan tanpa mengacaukan bagian depan. Itu mengapa redundansi tanpa failover adalah kapasitas yang tidak digunakan, dan failover tanpa redundansi adalah panik.
Perbedaan ini penting karena tim sering berhenti setelah membeli atau membangun komponen alternatif. Mereka bertanya apakah mereka memiliki dua server, dua wilayah, atau dua salinan data, lalu menganggap mereka terlindungi. Di produksi, pertanyaan yang berguna adalah apakah sistem dapat mendeteksi masalah dengan cepat, mengganti tanpa menyebabkan kegagalan kedua, dan kemudian kembali dengan bersih ketika jalur asli pulih.
Empat pertanyaan yang setiap tim harus tanyakan
Desain failover yang praktis hidup atau mati berdasarkan empat kriteria evaluasi.
- Waktu deteksi, berapa cepat sistem tahu bahwa ada yang salah.
- Waktu switchoverBagaimana lama waktu untuk memindahkan pekerjaan ke jalur cadangan.
- Konsistensi DataApakah cadangan memiliki keadaan yang diperlukan untuk mengambil alih dengan aman.
- ReversibilitasApakah sistem dapat kembali ke jalur yang disukai tanpa membuat hal-hal menjadi lebih buruk.
Ketiga pertanyaan tersebut berlaku untuk basis data, load balancer, dan pipeline update hidup secara sama. Perbedaan hanya terletak di mana handoff terjadi. Dalam sistem rilis aplikasi mobile, handoff mungkin terjadi antara saluran, edge, atau versi bundle daripada antara server aplikasi. Logika yang sama, alternatif yang sehat harus ada, dan sistem harus dapat memilihnya untuk alasan yang tepat.
Gaya Arsitektur Umum dan Kapan Menggunakannya
Cara Termudah untuk Berpikir tentang Failover adalah dengan bertanya di mana keputusan dibuat. Beberapa tim membiarkan perangkat keras menyerap masalah. Lainnya mendorong keputusan ke dalam perangkat lunak, load balancer, atau layer routing global. Pilihan masing-masing menangani jenis kegagalan yang berbeda, dan setiap satu menciptakan set blind spot yang berbeda.
Di mana setiap pola cenderung membantu
Redundansi Perangkat Keras berfungsi baik ketika kegagalan lokal dan jelas, seperti perangkat, kartu, atau node yang down. Ini sederhana untuk dipahami, yang adalah mengapa pola ini muncul awal dalam kemampuan platform. Kerugian adalah bahwa perangkat keras sendiri tidak dapat menyelesaikan koordinasi. Jika lapisan yang lebih tinggi tidak tahu apa yang terjadi, lalu arus trafik mungkin masih mengarah ke tempat yang salah.
Redundansi Perangkat Lunak menggeser fokus ke atas. Sebaliknya dari hanya menggandakan kotak, Anda menggandakan layanan, proses, atau kapasitas di lapisan aplikasi. Itu biasanya lebih sesuai untuk sistem cloud-native karena perangkat lunak dapat membuat keputusan yang lebih cerdas tentang kesehatan, versi, dan keadaan.
aktif-aktif berarti ada beberapa jalur yang melayani secara bersamaan, sehingga kegagalan tunggal tidak menciptakan awal dingin. Ini adalah pilihan yang kuat ketika sistem dapat menolerir pengolahan bersamaan dan model data dapat tetap konsisten di antara partisipan aktif. aktif-pasif lebih konservatif, satu jalur melayani, yang lain menunggu. Ini lebih mudah untuk dipahami dan seringkali lebih sederhana untuk keadaan otoritatif, tetapi Anda membayar untuk kapasitas yang tidak terlihat sampai ada kegagalan.
failover regional membantu ketika radius ledakan lebih besar dari sebuah cluster tunggal. Jika sebuah situs atau zona seluruhnya menjadi tidak sehat, lalu lintas dapat dipindahkan ke tempat lain. strategi yang dikendalikan DNS sering digunakan untuk membuat perpindahan tersebut terlihat kepada klien, sementara strategi yang dikendalikan load balancer memungkinkan keputusan lebih dekat ke jalur permintaan.
di mana setiap pola cenderung hancur
Setiap pola akan gagal di suatu tempat. Redundansi perangkat keras dapat menyembunyikan fakta bahwa dependensi upstream masih bersama. Konfigurasi aktif-aktif dapat menjadi rumit jika model keadaan tidak dibangun untuk kemampuan paralel. Konfigurasi aktif-pasif dapat diam selama waktu yang lama sehingga tidak ada kepercayaan bahwa sisi pasif masih berfungsi. Failover regional dapat dihancurkan oleh layanan bersama yang menjangkau domain kegagalan yang sama. Kontrol yang dikendalikan oleh DNS dapat lambat untuk menyesuaikan perubahan, sementara kontrol yang dikendalikan oleh load balancer hanya membantu jika balancer itu sendiri sehat.
Untuk platform pembaruan mobile, itu berarti lapisan failover mungkin berada di beberapa tingkat sekaligus. Server build mungkin berredundansi, penyimpanan artefak mungkin diulang, dan pengiriman edge mungkin diimbangi beban, tetapi pertanyaan utama adalah lapisan mana yang memutuskan pembaruan harus bergerak. Jika Anda ingin lensa deploymen yang lebih luas, multi-region deployment guide from Capgo adalah teman yang sangat berguna karena menunjukkan bagaimana berpikir regional mengubah bentuk keandalan pembaruan.
Mulai dengan lapisan yang memiliki dampak pengguna, kemudian kerjakan ke luar. Jika pengguna hanya merasakan pembaruan setelah meninggalkan edge, edge adalah bagian dari cerita failover.
Polanya yang tepat bukanlah yang paling canggih, melainkan yang sesuai dengan kegagalan yang ingin Anda lalui. Tim kecil biasanya memulai dengan aktif-pasif plus jalur validasi yang jelas, kemudian menambahkan kemampuan paralel lebih lanjut hanya ketika mereka telah membuktikan lapisan-lapisan yang lebih rendah dapat dipercaya.
Pengaturan Failover Berat dan Ambang Batas yang Berlapis
A keputusan failover tidak perlu menjadi switch yang murni ya atau tidak. Logika biner adalah salah satu alasan sistem mengalami flapping, karena layanan terus bergoyang antara status sehat dan tidak sehat segera setelah satu signal melewati garis. Failover berat menangani situasi yang sama dengan lebih banyak konteks, dengan menganggap gagal sebagai signal dengan tingkat dampak yang berbeda.
Mengapa pemikiran biner menyebabkan flapping
Model chassis-cluster Juniper memberikan contoh yang konkrit. Setiap kelompok redundansi dimulai dengan ambang batas 255lalu mengurangi berat yang ditetapkan untuk setiap objek yang diawasi ketika objek tersebut gagal. Failover hanya terjadi ketika ambang batas mencapai nol, yang memungkinkan operator menentukan seberapa besar kerugian individu antarmuka atau komponen yang harus berarti (Kelompok redundansi chassis-cluster Juniper failover).
Konfigurasi tersebut lebih sesuai dengan realitas produksi daripada cutover keras. Satu link yang rusak mungkin mengganggu tetapi masih dapat digunakan. Beberapa bagian yang diawasi gagal secara bersamaan dapat memberitahu cerita yang berbeda, karena efek kombinasi mungkin cukup besar untuk membenarkan pergantian. Hal ini penting karena degradasi parsial sangat umum, dan switchover segera dapat mengganggu lebih banyak lalu lintas daripada kerusakan asli.
Mengapa pengecekan kesehatan berat mengubah keputusan
Weighted failover muncul di luar perangkat jaringan juga. Breaker sirkuit, kolam lalu lintas berat, dan kontrol keluar yang dipersiapkan semua mengikuti ide yang sama, jangan panik pada peringatan pertama, tetapi jangan abaikan tanda-tanda yang diulang juga. Karena switching memiliki biaya, kebijakan tetap dapat disesuaikan. Failover dini dapat memecahkan sesi, memperumit pemulihan keadaan, dan mengubah satu insiden menjadi dua.
Untuk tim mobile, logika yang sama berlaku pada kontrol peluncuran. Jalur pembaruan hidup mungkin masih sehat cukup untuk sebagian audiens sementara potongan yang lebih kecil sudah rusak. Jika observabilitas halus, sistem dapat terus melayani dari tepi hingga risiko melintasi garis yang Anda definisikan. Tepi adalah bagian dari keputusan tersebut, dan model jaringan tepi dari __CAPGO_KEEP_0__ edge network model from Capgo Video singkat dapat membuat model mental lebih mudah diingat.
Weighted failover mengubah cara Anda menggambarkan masalah. Anda berhenti bertanya apakah komponen masih hidup atau mati, dan mulai bertanya berapa banyak kepercayaan yang masih ada di jalur. Pertanyaan itu lebih jujur dalam sistem di mana kerusakan parsial normal, dan di mana menahan diri sering lebih baik daripada memaksa pergantian yang terburu-buru.
Penerapan Failover ke CI/CD dan Pengiriman Pembaruan Hidup
Jalur pipa rilis adalah sistem pengiriman, tetapi juga sistem pemulihan. Setelah Anda melihatnya dengan cara itu, pilihan desain menjadi lebih jelas. Server bangun, penyimpanan artefak, layanan tanda tangan, dan saluran peluncuran semua menjadi tempat di mana
redundansi failover redundansi failover harus eksplisit.
Tangani pipa seperti jalur layanan
Jika runner pembangunan mati, keamanan redundansi hanya berguna jika runner lain dapat mengambil pekerjaan. Jika penyimpanan artefak tidak tersedia, pipa perlu salinan lain atau jalur lain ke bundle. Jika rollout mencapai keadaan buruk, sistem harus berhenti mengirimkan pembaruan sebelum masalah menyebar.
Di mana CI/CD dan pengiriman pembaruan hidup berbeda dari skrip publikasi biasa. Pipa yang matang perlu tahu apakah rilis aman untuk melanjutkan, aman untuk menunda, atau aman untuk membalikkan. Capacitor Panduan trigger pembaruan OTA bermanfaat karena berada di tengah berpikir itu, di mana proses pembangunan berubah menjadi acara distribusi wajah pengguna.
Rantai rilis praktis biasanya membutuhkan tiga perlindungan.
- Keamanan pembangunanagar satu runner atau satu antrian kegagalan tidak menghalangi rilis.
- Keamanan artefakagar bundle yang ditandatangani bukan titik kegagalan tunggal.
- Kawal saluranJadi, perilisan buruk dapat diisolasi sebelum penuhnya paparan.
Keduanya bukanlah kekhawatiran yang terpisah. Mereka adalah cerita pemulihan yang sama pada titik-titik yang berbeda dalam jalur.
Jadikan rollback bagian dari pengiriman, bukan kecenderungan.
Rollback adalah versi layer aplikasi dari failback. Sistem mengalihkan pengguna dari jalur buruk, kemudian kembali ke jalur stabil ketika masalah dipahami atau diperbaiki. Jika rollback hanya ada sebagai latihan manual, biasanya datang terlambat.
Otomatisasi adalah yang membuat hal ini mungkin. Log per-device, sinyal adopsi, dan kejadian gagal memberitahu Anda apakah jalur update sehat untuk melanjutkan. Tanpa feedback itu, tim terbang blind dan setiap keputusan failover hanya spekulasi.
Jalur rollback harus sealam-alam jalur pengiriman. Jika terasa unik selama insiden, itu tidak dirancang dengan baik.
Capgo masuk dalam model itu sebagai salah satu pilihan untuk tim yang mengirimkan update CapacitorJS atau Electron secara langsung, karena mendukung bundle web yang ditandatangani, distribusi berdasarkan channel, log per-device, dan perlindungan rollback otomatis. Fitur-fitur itu penting untuk failover karena memberikan platform cara mendeteksi, mengisolasi, dan membalikkan perilisan buruk tanpa menunggu siklus tinjauan toko.
Poinnya bukan bahwa satu alat menyelesaikan segalanya. Poinnya adalah bahwa pipa pengiriman Anda harus berperilaku seperti sistem yang tangguh, bukan siaran satu arah.
Platform Pembaruan Pintu Gerbang sebagai Rantai Failover
Sebuah jalur pembaruan gagal di dunia sebelum dashboard mengatakan begitu. Sebuah paket bergerak dari build ke signing, kemudian ke penyimpanan, kemudian melalui jaringan edge yang mungkin terbagi di berbagai wilayah, dan akhirnya ke perangkat yang mungkin offline, lambat, atau hanya terhubung sebagian. Jika salah satu langkah dalam rantai itu gagal, pembaruan itu tidak gagal berpindah. Ia telah berhenti.
Mengapa edge termasuk dalam jalur pemulihan
Latensi, konsistensi, paket yang ditandatangani, dan log perangkat per device adalah bagian-bagian yang menopang pengiriman. Paket yang ditandatangani yang tidak dapat diverifikasi adalah jalur mati, karena perangkat harus menolak untuk percaya padanya. Node edge yang menyajikan konten yang berbeda tergantung di mana permintaan mendarat dapat memicu event pemulihan bahkan ketika aplikasi itu sendiri sehat, yang mengubah masalah pengiriman menjadi masalah keandalan.
Edge mengikuti logika yang sama seperti infrastruktur klasik. Jaringan edge yang terdistribusi menjadi lapisan redundansi untuk pengiriman, dan target pemulihan adalah node yang sehat berikutnya yang dapat menjawab permintaan. Jika Anda telah bekerja dengan tabel routing atau replika database, pola itu akan terasa familiar. Distribusi mobile menyembunyikan kegagalan di balik logika pembaruan, sehingga langkah yang rusak lebih mudah dilupakan.
Untuk primer yang lebih luas tentang lapisan pengiriman itu Mengapa jaringan edge melakukan hal-hal di prakteknya Membantu menjelaskan mengapa lokasi kegagalan sangat penting dalam sistem pembaruan mobile. Ide yang sama juga terkait dengan Mengolah data di ujung jaringan, di mana pengolahan lokal mengubah baik performa maupun perilaku kegagalan.
Apa yang dibeli oleh saluran berdasarkan audiens
Saluran berdasarkan audiens, seperti beta, staging, produksi, atau aliran khusus pelanggan, memungkinkan tim untuk menguji jalur pemulihan sebelum seluruh armada bergantung padanya. Hal ini penting karena bundle yang sama dapat berperilaku berbeda tergantung pada campuran perangkat, kualitas jaringan, atau waktu peluncuran.
Beberapa implikasi praktis mengikuti dari itu.
- Saluran beta membantu Anda memastikan bahwa jalur pembaruan stabil sebelum terpapar lebih luas.
- Saluran staging memungkinkan Anda memastikan bahwa perilaku rollback dan re-fetch berfungsi dalam pengaturan yang dikendalikan.
- Saluran produksi hanya harus menerima rilis setelah jalur-jalur sebelumnya telah menunjukkan bahwa rantai utuh.
- Saluran khusus pelanggan dapat mengisolasi risiko ketika satu audiens membutuhkan siklus patch yang berbeda.
Pesan penting adalah bahwa pengiriman tepi bukanlah cermin pasif dari sistem pembangunan. Ini adalah lapisan pemulihan aktif. Jika node yang paling dekat tidak dapat menyediakan, sistem harus memilih node berikutnya. Jika bundle tidak dapat diverifikasi, platform harus kembali ke keadaan rilis yang lebih aman.
Jembatan antara infrastruktur dan pengiriman mobile. Tujuan failover bukan selalu server lain, tetapi bisa juga bundle terpercaya selanjutnya di edge terpercaya selanjutnya.
Tes Failover Sebelum Anda Membutuhkannya
Mitos redundansi bertahan hidup karena jalur bahagia terlihat menarik. Tim melihat infrastruktur duplikat, menganggap kekuatan, dan melewatkan ketergantungan tersembunyi yang menghancurkan segalanya di bawah kegagalan nyata. Poinnya sederhana, bagian redundan perlu diuji dan diverifikasi, dan failover front-end dan back-end harus tetap seimbang.
Mengapa mitos redundansi bertahan hidup
Mitos biasanya dimulai dengan ketergantungan yang sama dan pemisahan fisik yang lemah. Dua sistem tidak benar-benar terpisah jika masih bergantung pada jalur tersembunyi yang sama, layanan tanda tangan yang sama, atau penyimpanan artefak yang sama.
Oleh karena itu, tes yang hanya memeriksa apakah cadangan ada bisa melewati sementara jalur failover sebenarnya masih gagal.
Hal ini lebih penting lagi untuk pengiriman mobile dan sistem edge, karena rantai panjang melintasi lebih dari satu lapisan. Rollback bisa terlihat sehat di dashboard sementara perangkat tidak bisa memulihkan bundle dari lokasi edge cadangan. Failover regional bisa terlihat sukses sampai layanan tanda tangan, penyimpanan artefak, atau jalur autentikasi menunjukkan domain kegagalan yang sama. Pola yang sama muncul dalam mengujikan Capacitor pembaruan OTAdi mana jalur pembaruan harus berfungsi di perangkat, melalui layer edge, dan kembali ke sumber rilis yang dipercaya.
Apa yang harus direhearsal dalam praktek
A tes failover yang berguna memaksa jalur pemulihan yang sebenarnya, bukan yang palsu. Tim harus merehearsikan urutan yang lengkap di bawah kondisi yang realistis, lalu lihat di mana rantai melengkung, berhenti, atau patah. Perspektif tepi yang lebih luas membantu di sini, karena pengolahan data di tepi jaringan mengubah apa yang berarti “pemulihan” ketika kondisi lokal menjadi bagian dari cerita kegagalan.
A checklist yang praktis terlihat seperti ini:
- Dril kekacauan, secara sengaja hapus atau menurunkan komponen untuk melihat apakah sistem bergeser dengan bersih.
- Transaksi sintetis di antara wilayah, pastikan permintaan dapat diselesaikan ketika satu situs tidak tersedia.
- Failover regional yang direncanakan, verifikasi bahwa routing, autentikasi, penyimpanan, dan pengiriman update semua bergerak bersama.
- Reversal roll-out yang dipersiapkan, pastikan update hidup yang buruk dapat dihentikan dan diganti di bawah kondisi jaringan yang nyata.
- Validasi Rollback Mobile, pastikan paket yang ditandatangani dapat dire- fetch dari lokasi edge cadangan.
Jika tes tidak menyentuh jalur fallback yang sebenarnya, maka hanya membuktikan bahwa dashboard monitoring berfungsi.
Tim-tim yang kuat menganggap pengujian failover sebagai kebiasaan operasional yang berulang. Mereka tidak menunggu audit untuk mengetahui apakah rantai cadangan dapat bertahan. Mereka merehearsal mode gagal yang paling penting, kemudian memperketat handoff hingga sistem dapat pulih tanpa harus berlari manual.
Daftar Periksa Praktis untuk Tim yang Mengirimkan Update Hidup
Update hidup dapat gagal di tempat yang sama seperti database atau load balancer gagal, hanya radius ledakan yang berbeda pada mobile. Paket yang buruk, node edge yang rusak, atau saluran fallback yang ketinggalan zaman dapat meninggalkan pengguna terjebak pada build lama sementara aplikasi tampak sehat.
Jika Anda mengirimkan update hidup minggu ini, mulai dengan jalur yang diambil oleh rilis.
- Petakan titik lemahIdentifikasi titik lemah tunggal pada layer DNS, edge, dan origin, kemudian tuliskan siapa yang bertanggung jawab atas dampak pengguna.
- Pastikan jalur alternatif, pastikan setiap komponen kritis memiliki jalur cadangan yang sehat, bukan hanya aset duplikat pada kertas.
- Gunakan pengaman saluranJaga beta, pengembangan, dan produksi terpisah agar satu rilis buruk tidak menjadi peristiwa bagi seluruh armada.
- Minta bundel yang ditandatangani.Perhatikan signal per perangkat.
- Gunakan log dan data penyebaran sebagai mekanisme deteksi yang memberitahu Anda kapan failover harus diaktifkan.Rehearse rollback.
- Tunggu sampai terjadi insiden nyata untuk menemukan bahwa versi terakhir yang diketahui tidak dapat dipulihkan dengan bersih.Lakukan latihan chaos yang terjadwal.
- Matikan sengaja salah satu bagian jalur dan perhatikan apakah rantai benar-benar bergeser.Validasi failback juga.
- Karena kembali ke jalur yang disukai adalah bagian dari sistem, bukan fitur bonus.Tim-tim yang dapat pulih dengan baik adalah tim-tim yang dapat menelusuri rilis dari sumber ke perangkat dan menunjuk ke tempat pasti di mana rilis dapat gagal. Mereka tidak menganggap redundansi sebagai tumpukan salinan tambahan. Mereka menganggapnya sebagai rantai keputusan, pengecekan, dan pengiriman tangan yang harus berfungsi di bawah tekanan, termasuk lapisan pembaruan tepi yang berada di antara pipa rilis dan perangkat pengguna.
Minta bundel yang ditandatangani.
If suatu rilis berjalan tidak lancar, respons harus sudah dipraktikkan. Daftar cek harus berada di samping buku catatan insiden Anda, dan harus terhubung ke panduan tanggap darurat. panduan tanggap darurat panduan tanggap darurat yang tim Anda gunakan ketika produksi mulai rusak.
