Bahkan ketika terjadi bencana, selalu ada waktu untuk minum teh
DRP (rencana pemulihan bencana) adalah suatu hal yang idealnya tidak akan pernah dibutuhkan. Namun jika tiba-tiba berang-berang yang bermigrasi selama musim kawin menggerogoti serat optik tulang punggung atau admin junior menjatuhkan basis produktifnya, Anda pasti ingin memastikan bahwa Anda memiliki rencana yang telah dibuat sebelumnya tentang apa yang harus dilakukan dengan semua aib ini.
Sementara pelanggan yang panik mulai memutus telepon dukungan teknis, yang junior mencari sianida, Anda dengan bijak membuka amplop merah dan mulai membereskan semuanya.
Pada postingan kali ini saya ingin berbagi rekomendasi bagaimana cara menulis DRP dan apa saja isinya. Kami juga akan melihat hal-hal berikut:
- Mari belajar berpikir seperti penjahat.
- Yuk simak manfaat secangkir teh saat kiamat.
- Mari kita pikirkan struktur DRP yang nyaman
- Mari kita lihat cara mengujinya
Bagi perusahaan mana hal ini berguna?
Sangat sulit untuk menarik batasan ketika departemen TI mulai membutuhkan hal-hal seperti itu. Menurut saya, Anda pasti membutuhkan DRP jika:
- Menghentikan server, aplikasi, atau kehilangan database akan menyebabkan kerugian besar bagi bisnis secara keseluruhan.
- Anda memiliki departemen TI yang lengkap. Dalam arti departemen berupa unit perusahaan yang utuh, dengan anggarannya sendiri, dan bukan hanya segelintir karyawan yang lelah memasang jaringan, membersihkan virus, dan mengisi ulang printer.
- Anda memiliki anggaran yang realistis untuk setidaknya redundansi sebagian jika terjadi keadaan darurat.
Ketika departemen TI telah meminta selama berbulan-bulan untuk setidaknya beberapa HDD ke server lama untuk dicadangkan, Anda tidak mungkin dapat mengatur perpindahan penuh dari layanan yang gagal untuk mencadangkan kapasitas. Meskipun di sini dokumentasinya tidak akan berlebihan.
Dokumentasi itu penting
Mulailah dengan dokumentasi. Katakanlah layanan Anda berjalan pada skrip Perl yang ditulis tiga generasi lalu oleh admin, namun tidak ada yang tahu cara kerjanya. Akumulasi hutang teknis dan kurangnya dokumentasi pasti akan membuat Anda tidak hanya menderita, tetapi juga anggota tubuh lainnya, ini lebih merupakan masalah waktu.
Setelah Anda memiliki gambaran yang baik tentang komponen servis, carilah statistik kecelakaan. Mereka hampir pasti sangat khas. Misalnya, disk Anda menjadi penuh dari waktu ke waktu, yang menyebabkan node gagal hingga dibersihkan secara manual. Atau layanan klien menjadi tidak tersedia karena seseorang lagi lupa memperbarui sertifikat, dan Let's Encrypt tidak dapat atau tidak mau melakukan konfigurasi.
Pikiran seperti penyabot
Bagian tersulitnya adalah memprediksi kecelakaan yang belum pernah terjadi sebelumnya, namun berpotensi menyebabkan gangguan total pada layanan Anda. Di sini saya dan rekan-rekan biasanya berperan sebagai penjahat. Minumlah banyak kopi dan sesuatu yang enak dan kunci diri Anda di ruang pertemuan. Pastikan saja bahwa dalam negosiasi yang sama Anda mengunci para insinyur yang mengembangkan sendiri layanan target atau secara teratur bekerja dengannya. Kemudian, baik di papan tulis atau di atas kertas, Anda mulai menggambar semua kemungkinan kengerian yang bisa terjadi pada layanan Anda. Tidak perlu menjelaskan secara rinci kepada petugas kebersihan tertentu dan mencabut kabel; cukup dengan mempertimbangkan skenario “Pelanggaran integritas jaringan lokal.”
Biasanya, situasi darurat yang paling umum terbagi dalam jenis berikut:
- Kesalahan jaringan
- Kegagalan layanan OS
- Kegagalan aplikasi
- Kegagalan besi
- Kegagalan virtualisasi
Telusuri saja setiap jenisnya dan lihat apa yang berlaku untuk layanan Anda. Misalnya, daemon Nginx mungkin jatuh dan tidak naik - ini berarti kegagalan di pihak OS. Situasi langka yang menyebabkan aplikasi web Anda gagal adalah kegagalan perangkat lunak. Saat menjalani tahap ini, penting untuk menentukan diagnosis masalahnya. Bagaimana membedakan antarmuka yang dibekukan pada virtualisasi dari drive cis yang jatuh dan kegagalan jaringan, misalnya. Hal ini penting untuk segera menemukan mereka yang bertanggung jawab dan mulai menarik perhatian mereka hingga kecelakaan tersebut terselesaikan.
Setelah masalah umum ditulis, kami menuangkan lebih banyak kopi dan mulai mempertimbangkan skenario paling aneh, ketika beberapa parameter mulai melampaui norma. Misalnya:
- Apa yang terjadi jika waktu pada node aktif mundur satu menit dibandingkan waktu lain dalam cluster?
- Bagaimana jika waktu bergerak maju, bagaimana jika 10 tahun?
- Apa yang terjadi jika node cluster tiba-tiba kehilangan jaringannya selama sinkronisasi?
- Apa yang akan terjadi jika dua node tidak berbagi kepemimpinan karena isolasi sementara satu sama lain di jaringan?
Pada tahap ini, pendekatan sebaliknya sangat membantu. Anda mengambil anggota tim yang paling keras kepala dengan imajinasi yang sakit dan memberinya tugas untuk mengatur sabotase dalam waktu sesingkat mungkin yang akan menurunkan layanan. Jika sulit didiagnosis, lebih baik lagi. Anda tidak akan percaya ide aneh dan keren apa yang muncul dari para insinyur jika Anda memberi mereka ide untuk memecahkan sesuatu. Dan jika Anda menjanjikan mereka tempat ujian untuk ini, itu tidak masalah.
Apa DRP milikmu ini?!
Jadi, Anda telah menentukan model ancaman Anda. Mereka juga memperhitungkan penduduk setempat yang memotong kabel serat optik untuk mencari tembaga, dan radar militer yang memutus jalur relai radio secara ketat pada hari Jumat pukul 16:46. 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 berakhir, hanya pekerja magang yang paling tidak berpengalaman yang akan berada di dekatnya, yang tangannya akan gemetar hebat karena kengerian atas apa yang terjadi. Lihat bagaimana tanda-tanda darurat diterapkan di kantor medis. Misalnya saja apa yang harus dilakukan jika terjadi syok anafilaksis. Staf medis hafal semua protokolnya, namun ketika seseorang di dekatnya mulai meninggal, sering kali semua orang tidak berdaya memegangi segala sesuatu yang terlihat. Untuk melakukan hal ini, ada instruksi yang jelas di dinding dengan item seperti “buka kemasan ini dan itu” dan “berikan begitu banyak unit obat secara intravena.”
Sulit untuk berpikir dalam keadaan darurat! Harus ada instruksi sederhana untuk penguraian sumsum tulang belakang.
DRP yang baik terdiri dari beberapa blok sederhana:
- Siapa yang harus diberitahu tentang permulaan kecelakaan. Hal ini penting untuk memparalelkan proses eliminasi sebanyak mungkin.
- Cara mendiagnosis dengan benar - melakukan penelusuran, melihat status systemctl, nama layanan, dan sebagainya.
- Berapa banyak waktu yang dapat Anda habiskan pada setiap tahap? Jika Anda tidak punya waktu untuk memperbaikinya secara manual dalam waktu SLA, mesin virtual akan dimatikan dan dibatalkan dari cadangan kemarin.
- Bagaimana memastikan kecelakaan itu selesai.
Ingatlah bahwa DRP dimulai ketika layanan benar-benar gagal dan berakhir ketika layanan dipulihkan, bahkan dengan penurunan efisiensi. Kehilangan reservasi saja tidak akan memicu DRP. Anda juga dapat menulis secangkir teh ke dalam DRP. Dengan serius. Menurut statistik, banyak kecelakaan yang berubah dari tidak menyenangkan menjadi bencana besar karena staf yang panik terburu-buru memperbaiki sesuatu, sekaligus mematikan satu-satunya simpul hidup yang memiliki data atau akhirnya menghabisi cluster tersebut. Biasanya, 5 menit dengan secangkir teh akan memberi Anda waktu untuk menenangkan diri dan menganalisis apa yang terjadi.
Jangan bingung DRP dan paspor sistem! Jangan membebaninya dengan data yang tidak perlu. Memungkinkan dengan cepat dan mudah menggunakan hyperlink untuk membuka bagian dokumentasi yang diinginkan dan membaca dalam format yang diperluas tentang bagian yang diperlukan dari arsitektur layanan. Dan di DRP sendiri hanya ada petunjuk langsung dimana dan bagaimana menghubungkannya dengan perintah khusus untuk copy-paste.
Cara tes yang benar
Pastikan bahwa setiap karyawan yang bertanggung jawab mampu menyelesaikan semua item. Pada saat yang paling genting, teknisi mungkin tidak memiliki hak untuk mengakses sistem yang diperlukan, tidak ada kata sandi untuk akun yang diperlukan, atau dia tidak tahu apa yang dimaksud dengan “Sambungkan ke konsol manajemen layanan melalui proxy di kantor pusat” maksudnya. Setiap poin harus sangat sederhana.
Salah - “Buka virtualisasi dan reboot node mati”
Dengan benar - “Hubungkan melalui antarmuka web ke virt.example.com, di bagian node, reboot node yang menyebabkan kesalahan.”
Hindari ambiguitas. Ingat magang yang ketakutan.
Pastikan untuk menguji DRP. Ini bukan sekadar rencana pertunjukan - ini adalah sesuatu yang memungkinkan Anda dan klien Anda keluar dari situasi kritis dengan cepat. Sebaiknya lakukan ini beberapa kali:
- Seorang ahli dan beberapa peserta pelatihan bekerja di bangku tes yang sebisa mungkin mensimulasikan layanan nyata. Pakar memutus layanan dengan berbagai cara dan memungkinkan peserta pelatihan memulihkannya sesuai dengan DRP. Semua masalah, ambiguitas dan kesalahan dokumentasi dicatat. Setelah peserta dilatih, DRP diperluas dan disederhanakan di bidang yang tidak jelas.
- Menguji layanan nyata. Faktanya, Anda tidak akan pernah bisa membuat salinan sempurna dari layanan nyata. Oleh karena itu, beberapa kali dalam setahun perlu mematikan beberapa server secara rutin, memutus koneksi, dan menyebabkan bencana lain dari daftar ancaman untuk menilai urutan pemulihan. Kegagalan terencana selama 10 menit di tengah malam lebih baik daripada kegagalan mendadak selama beberapa jam saat beban puncak disertai kehilangan data.
- Pemecahan masalah nyata. Ya, ini juga bagian dari pengujian. Apabila terjadi kecelakaan yang tidak termasuk dalam daftar ancaman, maka perlu dilakukan penambahan dan penyempurnaan DRP berdasarkan hasil penyelidikannya.
Poin-poin penting
- Jika hal buruk bisa terjadi, hal itu tidak hanya akan terjadi, tetapi akan terjadi dalam skenario yang paling buruk.
- Pastikan Anda memiliki sumber daya untuk transfer beban darurat.
- Pastikan Anda memiliki cadangan, cadangan tersebut dibuat secara otomatis dan diperiksa konsistensinya secara berkala.
- Pikirkan skenario ancaman yang umum.
- Berikan kesempatan kepada teknisi untuk memberikan opsi non-standar dalam memberikan layanan.
- DRP harus menjadi instruksi yang sederhana dan blak-blakan. Semua diagnostik kompleks dilakukan hanya setelah layanan klien dipulihkan. Sekalipun dalam kapasitas cadangan.
- Berikan nomor telepon utama dan kontak di DRP.
- Uji pemahaman karyawan tentang DRP secara berkala.
- Mengatur kecelakaan yang direncanakan di lokasi produksi. Stand tidak bisa menggantikan segalanya.
Sumber: www.habr.com