Kamu 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 menjaga pengguna.
Jarak itu adalah apa Redundansi dan Failover Benar-benar tentang apa. Redundansi memberikan Anda jalur, komponen, atau salinan status alternatif. 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 pembaruan 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 Bergradasi
- Menerapkan Failover ke CI/CD dan Pengiriman Update Langsung
- Platform Update Pintu Gerbang sebagai Rantai Failover
- Menguji Failover Sebelum Anda Membutuhkannya
- Daftar Periksa Praktis untuk Tim yang Mengirimkan Update Langsung
Ketika Cadangan 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 mengalami degradasi, satu jalur mulai mengembalikan sinyal 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 cadangan dan memiliki desain redundansi yang nyata. redundancy failover Desain yang sebenarnya
Desain yang sebenarnya
Desain yang sebenarnya Desain yang sebenarnya Desain yang sebenarnya Desain yang sebenarnya Desain yang sebenarnya Desain yang sebenarnya menjelaskan bagaimana sisa rantai kembali ke keadaan yang wajar. Validasi menjawab apakah seluruhnya berfungsi di kondisi nyata, bukan hanya di papan tulis putih.
Sebuah tim mobile melihat hal ini dengan jelas dalam pengiriman pembaruan langsung. Jika sebuah layanan tidak dapat menandatangani, menyimpan, mengalihkan, 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 menyadari dan menggantinya. Logika yang sama berlaku pada tanggapan insiden, di mana menit pertama lebih penting daripada diagram arsitektur, seperti yang dijelaskan dalam Capgo's guide tanggapan insiden.
Ringkasan yang berguna dari nasihat redundansi dari Networking2000 menegaskan pelajaran yang sama, duplikasi hanya membantu ketika sisa sistem dapat berpindah kepadanya.
Redundansi dan Failover Didefinisikan sebagai Pasangannya
Redundansi dan failover seringkali dibicarakan seperti mereka adalah hal yang sama. Mereka tidak. Redundansi adalah kehadiran lebih dari satu komponen yang dapat melakukan pekerjaan yang sama. Failover Adalah tindakan mengalih 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 kehabisan energi dan langsung menugaskan tiket berikutnya kepada orang lain, itu adalah failover.
Dapur masih membutuhkan lebih dari orang-orang. Dapur membutuhkan cara untuk mendeteksi kegagalan, aturan untuk siapa yang mengambil alih, dan cara untuk menjaga pesanan berjalan tanpa mengacaukan bagian depan. Itulah mengapa redundansi tanpa failover hanya kapasitas yang tidak digunakan, dan failover tanpa redundansi hanya 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 asumsikan mereka sudah terlindungi. Di produksi, pertanyaan yang berguna adalah apakah sistem dapat mendeteksi masalah dengan cepat, melakukan pergantian tanpa menyebabkan kegagalan kedua, dan kemudian melakukan pergantian kembali dengan bersih ketika jalur asli pulih.
Empat pertanyaan yang setiap tim harus tanyakan
Rancangan failover yang praktis hidup atau mati berdasarkan empat kriteria evaluasi.
- Waktu deteksi, berapa cepat sistem tahu bahwa ada masalah.
- Waktu pergantianBagaimana lama waktu untuk memindahkan pekerjaan ke jalur cadangan.
- Konsistensi data.Apakah cadangan memiliki keadaan yang diperlukan untuk mengambil alih dengan aman.
- Reversibilitas.Apakah sistem dapat kembali ke jalur yang disukai tanpa membuat hal-hal menjadi lebih buruk.
Keragaman ini berlaku untuk basis data, pengaturan load balancer, dan pipa update hidup secara sama. Perbedaan hanya terletak di mana tukar gantian terjadi. Dalam sistem rilis aplikasi mobile, tukar gantian mungkin terjadi antara saluran, edge, atau versi bundle daripada antara server aplikasi. Logika yang sama berlaku, yaitu 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, pengatur load balancer, atau lapisan routing global. Pilihan masing-masing menangani jenis kegagalan yang berbeda, dan masing-masing menciptakan set blind spot yang berbeda.
Di mana setiap pola cenderung membantu.
Keragaman perangkat keras. berfungsi baik ketika kegagalan lokal dan jelas, seperti perangkat, kartu, atau node yang mengalami gangguan. Ini sederhana untuk dipahami, yang adalah mengapa pola ini muncul awal dalam kemampuan platform. Kerugian adalah bahwa perangkat keras sendiri tidak dapat menyelesaikan orkestrasi. Jika lapisan yang lebih tinggi tidak tahu apa yang terjadi, lalu arus trafik mungkin masih mengarah ke tempat yang salah.
Keragaman perangkat lunak. menggeser fokus ke atas. Sebaliknya dari hanya menggandakan kotak-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 sesuatu gagal.
failover regional membantu ketika radius ledakan lebih besar dari sebuah cluster tunggal. Jika sebuah situs atau zona seluruhnya menjadi tidak sehat, lalu arus trafik 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 bocor
Setiap pola akan patah 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 konkurensi. 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 DNS dapat lambat untuk menyesuaikan perubahan, sementara kontrol yang dikendalikan load balancer hanya membantu jika balancer itu sendiri sehat.
Untuk platform pembaruan mobile, itu berarti layer failover mungkin berada di beberapa tingkat sekaligus. Server build mungkin berredundansi, penyimpanan artefak mungkin berrepresi, dan pengiriman edge mungkin berload-balanced, tetapi pertanyaan utama adalah lapisan mana yang memutuskan pembaruan harus bergerak. Jika Anda ingin menggunakan lensa deploymen yang lebih luas, petunjuk deploymen multi-regional dari Capgo Mulai dari lapisan yang memiliki dampak pengguna, kemudian kerja 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 selamatkan. Tim kecil biasanya memulai dengan aktif-pasif plus jalur validasi yang jelas, kemudian menambahkan konkurensi lebih lanjut hanya ketika mereka telah membuktikan lapisan-lapisan yang lebih rendah dapat dipercaya.
Pengaturan Failover Berat dan Ambang Batas Bergradasi
Pengaturan Failover Berat dan Ambang Batas Bergradasi
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 kondisi 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 dianggap penting (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 memungkinkan switchover. Hal ini penting karena degradasi parsial sangat umum, dan switchover segera dapat mengganggu lebih banyak lalu lintas daripada kerugian asli.
Bagaimana periksa kesehatan berat mengubah keputusan
Failover Berat menampilkan di luar peralatan jaringan juga. Pembatas 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 kebijakan tetap dapat disesuaikan karena pergantian memiliki biaya. Failover yang terlalu cepat dapat memecahkan sesi, memperumit pemulihan keadaan, dan mengubah satu insiden menjadi dua.
Untuk tim mobile, logika yang sama berlaku pada kontrol pengiriman. Jalur pembaruan hidup mungkin masih sehat cukup untuk sebagian audiens sementara potongan yang lebih kecil sudah rusak. Jika observabilitas halus, sistem dapat terus menyajikan dari tepi hingga risiko melewati garis yang Anda definisikan. Tepi adalah bagian dari keputusan itu, dan model jaringan tepi dari __CAPGO_KEEP_0__ edge network model from Capgo Video singkat dapat membuat model mental lebih mudah dipegang.
Failover Berat mengubah cara Anda menyusun 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 pengiriman semua menjadi tempat di mana
failover redundansi Penerapan Failover ke CI/CD dan Pengiriman Pembaruan Hidup harus jelas.
Tangani pipa seperti jalur layanan
Jika salah satu pengguna build mati, keamanan redundansi hanya berguna jika pengguna lain dapat mengambil tugas. Jika penyimpanan artefak tidak tersedia, pipa perlu memiliki salinan lain atau jalur lain ke bundle. Jika peluncuran 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-tengah pemikiran itu, di mana proses build berubah menjadi acara distribusi yang menghadap pengguna.
Rantai rilis yang praktis biasanya memerlukan tiga perlindungan.
- Keamanan buildagar keluarnya tidak terblokir oleh kegagalan pengguna atau antrian.
- Keamanan artefakagar bundle yang ditandatangani tidak menjadi titik kegagalan tunggal.
- Kawal saluranJadi, perilaku rilis yang buruk dapat dicegah sebelum terpapar secara penuh.
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 yang buruk, kemudian kembali ke jalur yang 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 berada di keadaan buta dan setiap keputusan failover hanya spekulasi.
Jalur rollback harus seunik jalur rilis. Jika terasa unik selama insiden, maka tidak dirancang dengan baik.
Capgo masuk dalam model itu sebagai salah satu pilihan untuk tim yang mengirimkan rilis CapacitorJS atau Electron secara langsung, karena mendukung bundle web yang ditandatangani, distribusi berdasarkan saluran, log per-device, dan perlindungan rollback otomatis. Fitur-fitur itu penting untuk failover karena memberikan platform cara untuk mendeteksi, isolasi, dan membalikkan rilis yang buruk tanpa menunggu siklus tinjauan toko.
Poinnya bukan bahwa satu alat dapat menyelesaikan segalanya. Poinnya adalah bahwa pipa pengiriman Anda harus berperilaku seperti sistem yang tahan lama, bukan siaran satu arah.
Platform Pembaruan Pintu Gerbang sebagai Rantai Pemulihan
Sebuah jalur pembaruan gagal di dunia jauh sebelum dashboard mengatakan begitu. Sebuah paket bergerak dari build ke signing, kemudian ke penyimpanan, kemudian melalui jaringan pinggiran 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 belum gagal berpindah. Ia telah berhenti.
Mengapa pinggiran termasuk dalam jalur pemulihan
Latensi, konsistensi, paket yang ditandatangani, dan log perangkat per device adalah bagian yang berat dari pengiriman. Paket yang ditandatangani yang tidak dapat diverifikasi adalah jalur mati, karena perangkat harus menolak untuk percaya padanya. Node pinggiran 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.
Pinggiran mengikuti logika yang sama seperti infrastruktur klasik. Jaringan pinggiran 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 pinggiran 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 pinggiran jaringan, di mana pengolahan lokal mengubah keduanya kinerja dan perilaku kegagalan.
Apakah saluran berdasarkan audiens yang Anda beli
Saluran berdasarkan audiens, seperti beta, staging, produksi, atau aliran khusus pelanggan, memungkinkan tim untuk menguji jalur pemulihan sebelum seluruh armada bergantung pada itu. Hal itu 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 apakah 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 harus hanya menerima rilis setelah jalur-jalur sebelumnya telah menunjukkan bahwa rantai utuh.
- Saluran khusus pelanggan memungkinkan Anda mengisolasi risiko ketika satu audiens membutuhkan siklus patch yang berbeda.
Pelajaran penting adalah bahwa pengiriman edge 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 berikutnya di edge terpercaya berikutnya.
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 sejalan.
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 hingga layanan tanda tangan, penyimpanan artefak, atau jalur autentikasi menunjukkan domain kegagalan yang sama. testing Capacitor OTA updatesmenguji __CAPGO_KEEP_0__ pembaruan OTA
dimana jalur pembaruan harus berfungsi di perangkat, melalui layer edge, dan kembali ke sumber rilis yang dipercaya Anda.
A tes failover yang berguna memaksa jalur pemulihan yang sebenarnya, bukan yang palsu. Tim harus merehearsikan urutan lengkap di bawah kondisi yang realistis, lalu lihat di mana rantai melengkung, berhenti, atau patah. Perspektif tepi yang lebih luas membantu di sini, karena proses data di tepi jaringan mengubah apa yang berarti “pemulihan” ketika kondisi lokal menjadi bagian dari cerita kegagalan.
A checklist yang berguna seperti ini:
- Drill 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 wilayah yang direncanakan, pastikan routing, autentikasi, penyimpanan, dan pengiriman update semua bergerak bersama.
- Reversal roll-out yang dipersiapkan, pastikan pembaruan hidup yang buruk dapat dihentikan dan diganti di bawah kondisi jaringan yang nyata.
- Validasi rollback mobilePastikan 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 kekacauan 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.
- Peta titik lemahIdentifikasi titik lemah tunggal pada layer DNS, edge, dan origin, kemudian tuliskan siapa yang bertanggung jawab atas dampak pengguna.
- Konfirmasi jalur alternatifPastikan setiap komponen kritis memiliki jalur cadangan yang sehat, bukan hanya aset duplikat pada kertas.
- Pakai penghalang saluranJaga beta, pengembangan, dan produksi terpisah agar satu rilis buruk tidak menjadi peristiwa bagi seluruh armada.
- Minta bundel yang ditandatangani.Karena bundel yang tidak dapat diverifikasi bukanlah jalur pengganti yang valid.
- Perhatikan signal per perangkat.Gunakan log dan data peningkatan sebagai mekanisme deteksi yang memberitahu Anda kapan failover harus diaktifkan.
- Rehearse rollback.Tunggu sampai terjadi insiden nyata untuk menemukan bahwa versi terakhir yang diketahui baik 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 yang dapat pulih dengan baik adalah tim yang dapat menjejak 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 yang harus berfungsi di bawah tekanan, termasuk lapisan pembaruan tepi yang berada di antara pipa rilis dan perangkat pengguna.
Jika rilis gagal, respons harus sudah dipraktikkan. Daftar tugas harus berada di samping buku catatan kejadian, dan harus terhubung ke guide tanggapan kejadian panduan tanggapan kejadian yang tim Anda gunakan ketika produksi mulai rusak.
