Bahkan saat terjadi bencana, selalu ada waktu untuk secangkir teh
DRP (disaster recovery plan) - yang idealnya tidak pernah dibutuhkan. Tetapi jika tiba-tiba berang-berang bermigrasi selama musim kawin menggerogoti serat optik tulang punggung atau admin junior menjatuhkan basis produktif, Anda pasti ingin memastikan bahwa Anda akan memiliki rencana yang telah dibuat sebelumnya tentang apa yang harus dilakukan dengan semua kekacauan ini.
Sementara pelanggan panik mulai memutuskan telepon dukungan teknis mereka, junior mencari sianida, Anda dengan bijak membuka amplop merah dan mulai mengatur semuanya.
Dalam posting ini, saya ingin membagikan rekomendasi tentang cara menulis DRP dan apa yang harus dikandungnya. Kami juga akan melihat hal-hal berikut:
- Mari belajar berpikir seperti penjahat.
- Mari kita lihat manfaat secangkir teh saat kiamat.
- Kami akan memikirkan struktur DRP yang nyaman
- Mari kita lihat cara mengujinya.
Untuk perusahaan mana ini bisa bermanfaat
Sangat sulit untuk menarik garis ketika departemen TI mulai membutuhkan hal-hal ini. Saya akan mengatakan bahwa Anda dijamin membutuhkan DRP jika:
- Menghentikan server, aplikasi, atau hilangnya basis akan menyebabkan kerugian bisnis yang signifikan secara keseluruhan.
- Anda memiliki departemen TI yang lengkap. Dalam arti departemen dalam bentuk unit perusahaan yang lengkap, dengan anggaran sendiri, dan tidak hanya beberapa karyawan yang lelah membangun jaringan, membersihkan virus, dan mengisi ulang printer.
- Anda memiliki anggaran yang realistis untuk setidaknya redundansi parsial dalam keadaan darurat.
Ketika departemen TI selama berbulan-bulan meminta setidaknya beberapa HDD untuk server lama untuk cadangan, Anda tidak mungkin dapat mengatur transfer penuh dari layanan yang jatuh untuk mencadangkan kapasitas. Walaupun dokumentasi disini tidak akan berlebihan.
Dokumentasi itu penting
Mulailah dengan dokumentasi. Misalkan layanan Anda didasarkan pada skrip Perl yang ditulis tiga generasi admin yang lalu, dan tidak ada yang tahu cara kerjanya. Akumulasi hutang teknis dan kurangnya dokumentasi pasti akan menembak Anda tidak hanya di lutut, tetapi juga di anggota tubuh lainnya, ini lebih merupakan masalah waktu.
Setelah Anda memiliki deskripsi yang baik tentang komponen layanan, tampilkan statistik kerusakan. Mereka hampir pasti benar-benar tipikal. Misalnya, Anda memiliki disk penuh dari waktu ke waktu, yang menyebabkan kegagalan node sebelum dibersihkan secara manual. Atau layanan klien menjadi tidak tersedia karena fakta bahwa seseorang lagi lupa memperbarui sertifikat, dan Let's Encrypt tidak dapat atau tidak ingin mengkonfigurasinya.
Pikiran seperti penyabot
Bagian tersulit adalah memprediksi kecelakaan yang belum pernah terjadi sebelumnya, tetapi berpotensi mematikan layanan Anda sepenuhnya. Di sini kami biasanya bermain penjahat dengan rekan kerja kami. Ambil banyak kopi dan sesuatu yang enak dan kunci diri Anda di ruang rapat. Pastikan saja di ruang rapat yang sama Anda mengunci teknisi yang meningkatkan layanan target atau secara teratur bekerja dengannya. Kemudian, baik di papan tulis atau di atas kertas, Anda mulai menggambar semua kemungkinan kengerian yang dapat terjadi pada layanan Anda. Tidak perlu merinci ke pembersih khusus dan menarik kabel, itu cukup untuk mempertimbangkan skenario "Pelanggaran integritas jaringan lokal."
Biasanya, situasi darurat yang paling umum termasuk dalam jenis berikut:
- Kesalahan jaringan
- Kegagalan layanan OS
- Kegagalan aplikasi
- Kegagalan besi
- Kegagalan virtualisasi
Cukup lihat setiap tampilan dan lihat apa yang berlaku untuk layanan Anda. Misalnya, daemon Nginx mungkin macet dan tidak naik - ini adalah kegagalan pada bagian OS. Situasi langka yang membuat aplikasi web Anda tidak dapat digunakan adalah kegagalan perangkat lunak. Selama tahap ini, penting untuk menentukan diagnosis masalah. Bagaimana membedakan antarmuka yang digantung pada virtualisasi dari tsiska yang jatuh dan kerusakan jaringan, misalnya. Sangat penting untuk segera menemukan mereka yang bertanggung jawab dan mulai menarik-narik ekor mereka sampai kecelakaan teratasi.
Setelah masalah tipikal ditulis, kami menuangkan lebih banyak kopi dan mulai mempertimbangkan skenario paling aneh ketika beberapa parameter mulai melampaui kisaran normal. Misalnya:
- Apa yang terjadi jika waktu pada node aktif bergerak mundur satu menit relatif terhadap yang lain di cluster?
- Dan jika waktu bergerak maju, dan jika 10 tahun?
- Apa yang terjadi jika node cluster tiba-tiba kehilangan jaringannya selama sinkronisasi?
- Apa yang terjadi jika dua node tidak berbagi kepemimpinan karena isolasi sementara satu sama lain melalui jaringan?
Pendekatan sebaliknya sangat membantu pada tahap ini. Anda mengambil anggota tim yang paling keras kepala dengan imajinasi yang sakit dan memberinya tugas untuk mengatur sabotase sesegera mungkin, yang akan menurunkan layanan. Jika sulit mendiagnosisnya, lebih baik lagi. Anda tidak akan percaya ide-ide aneh dan keren yang muncul dari para insinyur jika Anda memberi mereka ide untuk memecahkan sesuatu. Dan jika Anda menjanjikan mereka bangku tes untuk ini, itu sangat bagus.
Apa DRP-mu ini ?!
Jadi, Anda telah menentukan model ancaman. Penduduk setempat, yang memotong kabel serat optik untuk mencari tembaga, dan radar militer, yang menjatuhkan jalur relai radio secara ketat pada hari Jumat pukul 16:46, juga diperhitungkan. Sekarang kita perlu memahami apa yang harus dilakukan dengan semua ini.
Tugas Anda adalah menulis amplop merah yang akan dibuka dalam keadaan darurat. Segera berharap bahwa ketika (bukan jika!) Semuanya akan dimulai, hanya peserta pelatihan yang paling tidak berpengalaman yang akan berada di dekatnya, yang tangannya akan gemetar dengan keras karena kengerian dari apa yang terjadi. Lihat bagaimana label darurat diterapkan di kantor medis. Misalnya, apa yang harus dilakukan jika terjadi syok anafilaksis. Staf medis hafal semua protokol, tetapi ketika orang di sebelahnya mulai meninggal, sering kali semua orang tanpa daya meraih semuanya. Untuk melakukan ini, ada instruksi yang jelas di dinding dengan item seperti "buka bungkusnya" dan "suntikkan begitu banyak unit obat secara intravena".
Sulit untuk berpikir dalam keadaan darurat! Harus ada instruksi sederhana untuk mengurai oleh sumsum tulang belakang.
DRP yang baik terdiri dari beberapa blok sederhana:
- . , .
- — , systemctl status servicename .
- . SLA — .
- , .
Ingatlah bahwa DRP dimulai ketika layanan benar-benar gagal dan akhirnya dibangun kembali, bahkan dengan efisiensi yang berkurang. Kehilangan reservasi seharusnya tidak mengaktifkan DRP. Anda juga bisa menambahkan secangkir teh ke DRP. Sungguh. Menurut statistik, banyak kecelakaan dari yang tidak menyenangkan menjadi bencana karena staf yang panik bergegas untuk memperbaiki sesuatu, secara bersamaan membunuh satu-satunya node yang hidup dengan data atau akhirnya menghabisi cluster. Biasanya, 5 menit untuk secangkir teh akan memberi Anda waktu untuk menenangkan diri dan menganalisis apa yang terjadi.
Jangan bingung dengan DRP dan paspor sistem! Jangan membebani dengan data yang tidak perlu. Buatlah mungkin untuk menggunakan hyperlink dengan cepat dan mudah untuk membuka bagian dokumentasi yang diperlukan dan membaca dalam format yang diperpanjang tentang bagian yang diperlukan dari arsitektur layanan. Dan di DRP sendiri hanya ada petunjuk langsung dimana dan bagaimana menghubungkan dengan perintah khusus untuk copy-paste.
Bagaimana cara menguji dengan benar
Pastikan bahwa setiap orang yang bertanggung jawab dapat menyelesaikan semua poin. Pada saat yang paling genting, mungkin teknisi tersebut ternyata tidak memiliki hak akses ke sistem yang diperlukan, tidak ada sandi untuk akun yang diperlukan, atau dia tidak tahu apa artinya "Sambungkan ke konsol manajemen layanan melalui proxy di kantor pusat." Setiap poin harus sangat sederhana.
Salah - "Buka virtualisasi dan reboot node mati"
Benar - "Hubungkan melalui antarmuka web ke virt.example.com, di bagian node, reboot node yang menyebabkan kesalahan."
Hindari ambiguitas. Ingatlah peserta pelatihan yang ketakutan.
Pastikan untuk menguji DRP. Ini bukan hanya rencana untuk dihapus - ini adalah rencana yang akan memungkinkan Anda dan pelanggan Anda dengan cepat keluar dari situasi kritis. Optimal untuk melakukan ini beberapa kali:
- Seorang ahli dan beberapa peserta pelatihan bekerja di bangku tes yang mensimulasikan layanan nyata sebanyak mungkin. Pakar menghentikan layanan dengan berbagai cara dan memungkinkan peserta untuk memulihkannya sesuai dengan DRP. Semua masalah, ambiguitas dalam dokumentasi dan kesalahan dicatat. Setelah melatih para peserta, DRP ditambahkan dan disederhanakan di tempat-tempat yang tidak jelas.
- . . , , , . 10 , .
- . , . , , DRP .
- , , .
- , .
- , , .
- .
- .
- DRP . , . .
- DRP.
- DRP.
- . .
