Walaupun semasa bencana sentiasa ada masa untuk secawan teh
DRP (pelan pemulihan bencana) adalah perkara yang idealnya tidak akan diperlukan. Tetapi jika memerang tiba-tiba berhijrah semasa musim mengawan menggerogoti gentian optik tulang belakang atau pentadbir junior menjatuhkan asas yang produktif, anda pasti ingin memastikan bahawa anda akan mempunyai rancangan yang telah dibuat terlebih dahulu untuk apa yang perlu dilakukan dengan semua aib ini.
Semasa pelanggan yang panik mula memotong telefon sokongan teknikal, junior sedang mencari sianida, anda dengan bijak membuka sampul merah dan mula menyusun segala-galanya.
Dalam siaran ini saya ingin berkongsi cadangan tentang cara menulis DRP dan kandungan yang sepatutnya. Kami juga akan melihat perkara berikut:
- Mari belajar berfikir seperti penjahat.
- Mari kita lihat manfaat secawan teh semasa kiamat.
- Mari kita fikirkan struktur DRP yang mudah
- Mari lihat bagaimana untuk mengujinya
Syarikat manakah yang mungkin berguna untuk ini?
Sangat sukar untuk membuat garis apabila jabatan IT mula memerlukan perkara sedemikian. Saya akan mengatakan bahawa anda pasti memerlukan DRP jika:
- Menghentikan pelayan, aplikasi atau kehilangan beberapa pangkalan data akan membawa kepada kerugian besar untuk perniagaan secara keseluruhan.
- Anda mempunyai jabatan IT yang lengkap. Dalam erti kata jabatan dalam bentuk unit penuh syarikat, dengan bajet sendiri, dan bukan hanya beberapa pekerja yang letih meletakkan rangkaian, membersihkan virus dan mengisi semula pencetak.
- Anda mempunyai belanjawan yang realistik untuk sekurang-kurangnya separa lebihan sekiranya berlaku kecemasan.
Apabila jabatan IT telah meminta selama berbulan-bulan sekurang-kurangnya beberapa HDD ke pelayan lama untuk sandaran, anda tidak mungkin dapat mengatur langkah penuh perkhidmatan yang gagal untuk menempah kapasiti. Walaupun di sini dokumentasi tidak akan berlebihan.
Dokumentasi adalah penting
Mulakan dengan dokumentasi. Katakan perkhidmatan anda berjalan pada skrip Perl yang ditulis tiga generasi lalu oleh pentadbir, tetapi tiada siapa yang tahu cara ia berfungsi. Hutang teknikal yang terkumpul dan kekurangan dokumentasi pasti akan menembak anda bukan sahaja di lutut, tetapi juga pada anggota badan yang lain, ia lebih memerlukan masa.
Sebaik sahaja anda mempunyai penerangan yang baik tentang komponen perkhidmatan, cari statistik kemalangan. Mereka hampir pasti akan menjadi tipikal sepenuhnya. Sebagai contoh, cakera anda menjadi penuh dari semasa ke semasa, yang menyebabkan nod gagal sehingga ia dibersihkan secara manual. Atau perkhidmatan pelanggan menjadi tidak tersedia kerana fakta bahawa seseorang sekali lagi terlupa untuk memperbaharui sijil, dan Let's Encrypt tidak dapat atau tidak mahu mengkonfigurasi.
Fikiran seperti pensabotaj
Bahagian yang paling sukar adalah dalam meramalkan kemalangan yang tidak pernah berlaku sebelum ini, tetapi yang boleh menyebabkan perkhidmatan anda ranap sepenuhnya. Di sini saya dan rakan sekerja biasanya bermain penjahat. Ambil banyak kopi dan sesuatu yang lazat dan berkurung dalam bilik mesyuarat. Hanya pastikan bahawa dalam rundingan yang sama anda mengunci jurutera yang membangunkan perkhidmatan sasaran atau kerap bekerja dengannya. Kemudian, sama ada di papan atau di atas kertas, anda mula melukis semua kemungkinan ngeri yang boleh berlaku pada perkhidmatan anda. Ia tidak perlu menjelaskan secara terperinci kepada wanita pembersih tertentu dan mengeluarkan kabel; cukup untuk mempertimbangkan senario "Pelanggaran integriti rangkaian tempatan."
Biasanya, kebanyakan situasi kecemasan tipikal termasuk dalam jenis berikut:
- Kegagalan rangkaian
- Kegagalan perkhidmatan OS
- Kegagalan aplikasi
- Kegagalan besi
- Kegagalan virtualisasi
Hanya semak setiap jenis dan lihat perkara yang berkaitan dengan perkhidmatan anda. Sebagai contoh, daemon Nginx mungkin jatuh dan tidak naik - ini bermakna kegagalan di pihak OS. Situasi yang jarang berlaku yang menyebabkan aplikasi web anda gagal ialah kegagalan perisian. Semasa bekerja melalui peringkat ini, adalah penting untuk menyelesaikan diagnosis masalah. Bagaimana untuk membezakan antara muka beku pada virtualisasi daripada pemacu cis yang jatuh dan kegagalan rangkaian, sebagai contoh. Ini penting untuk mencari mereka yang bertanggungjawab dengan cepat dan mula menarik ekor mereka sehingga kemalangan itu diselesaikan.
Selepas masalah biasa ditulis, kami menuangkan lebih banyak kopi dan mula mempertimbangkan senario paling pelik, apabila beberapa parameter mula melampaui norma. Sebagai contoh:
- Apakah yang berlaku jika masa pada nod aktif bergerak ke belakang seminit berbanding orang lain dalam kelompok?
- Bagaimana jika masa bergerak ke hadapan, bagaimana jika menjelang 10 tahun?
- Apakah yang berlaku jika nod kluster tiba-tiba kehilangan rangkaiannya semasa penyegerakan?
- Apakah yang akan berlaku jika dua nod tidak berkongsi kepimpinan kerana pengasingan sementara antara satu sama lain pada rangkaian?
Pada peringkat ini, pendekatan terbalik sangat membantu. Anda mengambil ahli pasukan yang paling degil dengan imaginasi yang sakit dan memberinya tugas untuk mengatur sabotaj dalam masa yang sesingkat mungkin yang akan menjatuhkan perkhidmatan. Jika sukar untuk didiagnosis, lebih baik. Anda tidak akan percaya idea pelik dan hebat yang dibuat oleh jurutera jika anda memberi mereka idea untuk memecahkan sesuatu. Dan jika anda menjanjikan mereka bangku ujian untuk ini, itu tidak mengapa.
Apakah DRP awak ini?!
Jadi anda telah menentukan model ancaman anda. Mereka juga mengambil kira penduduk tempatan yang memotong kabel gentian optik untuk mencari tembaga, dan radar tentera yang menjatuhkan talian penyampaian radio secara ketat pada hari Jumaat pada jam 16:46. Sekarang kita perlu memahami apa yang perlu dilakukan dengan semua ini.
Tugas anda ialah menulis sampul surat berwarna merah yang akan dibuka semasa kecemasan. Segera jangkakan bahawa apabila (bukan jika!) segala-galanya berakhir, hanya pelatih yang paling tidak berpengalaman akan berada berdekatan, yang tangannya akan menggigil kuat akibat ngeri apa yang sedang berlaku. Lihat bagaimana tanda kecemasan dilaksanakan di pejabat perubatan. Sebagai contoh, apa yang perlu dilakukan sekiranya berlaku kejutan anaphylactic. Kakitangan perubatan mengetahui semua protokol dengan teliti, tetapi apabila seseorang yang berdekatan mula mati, selalunya semua orang tidak berdaya berpegang pada segala yang dilihat. Untuk melakukan ini, terdapat arahan yang jelas di dinding dengan item seperti "buka bungkusan itu dan itu" dan "mentadbir begitu banyak unit ubat secara intravena."
Sukar untuk berfikir dalam kecemasan! Perlu ada arahan mudah untuk penghuraian saraf tunjang.
DRP yang baik terdiri daripada beberapa blok mudah:
- Siapa yang perlu diberitahu tentang permulaan kemalangan. Ini penting untuk menyelaraskan proses penyingkiran sebanyak mungkin.
- Cara mendiagnosis dengan betul - lakukan jejak, lihat dalam nama perkhidmatan status systemctl dan sebagainya.
- Berapa banyak masa yang boleh anda luangkan pada setiap peringkat? Jika anda tidak mempunyai masa untuk membetulkannya secara manual dalam masa SLA, mesin maya dimatikan dan ditarik balik daripada sandaran semalam.
- Bagaimana untuk memastikan kemalangan itu berakhir.
Ingat bahawa DRP bermula apabila perkhidmatan gagal sepenuhnya dan berakhir apabila perkhidmatan dipulihkan, walaupun dengan kecekapan yang berkurangan. Hanya kehilangan tempahan tidak seharusnya mencetuskan DRP. Anda juga boleh menulis secawan teh ke dalam DRP. Serius. Menurut statistik, banyak kemalangan bertukar daripada tidak menyenangkan kepada malapetaka disebabkan kakitangan dalam keadaan panik tergesa-gesa untuk membetulkan sesuatu, pada masa yang sama membunuh satu-satunya nod yang hidup dengan data atau akhirnya menamatkan kluster. Sebagai peraturan, 5 minit dengan secawan teh akan memberi anda sedikit masa untuk bertenang dan menganalisis apa yang berlaku.
Jangan mengelirukan DRP dan pasport sistem! Jangan membebankannya dengan data yang tidak diperlukan. Hanya pastikan untuk menggunakan hiperpautan dengan cepat dan mudah untuk pergi ke bahagian dokumentasi yang dikehendaki dan membaca dalam format yang diperluaskan tentang bahagian yang diperlukan dalam seni bina perkhidmatan. Dan dalam DRP itu sendiri hanya terdapat arahan langsung di mana dan bagaimana untuk menyambung dengan arahan khusus untuk salin-tampal.
Bagaimana untuk menguji dengan betul
Pastikan mana-mana pekerja yang bertanggungjawab dapat menyelesaikan semua item. Pada saat yang paling penting, mungkin ternyata jurutera tidak mempunyai hak untuk mengakses sistem yang diperlukan, tiada kata laluan untuk akaun yang diperlukan, atau dia tidak tahu apa yang "Sambungkan ke konsol pengurusan perkhidmatan melalui proksi di ibu pejabatβ bermaksud. Setiap titik hendaklah sangat mudah.
salah β βPergi ke virtualisasi dan but semula nod matiβ
betul - "Sambung melalui antara muka web ke virt.example.com, dalam bahagian nod, but semula nod yang menyebabkan ralat."
Elakkan kekaburan. Ingat pelatih takut.
Pastikan untuk menguji DRP. Ini bukan sekadar rancangan untuk pertunjukan - ia adalah sesuatu yang akan membolehkan anda dan pelanggan anda keluar dengan cepat daripada situasi kritikal. Adalah lebih baik untuk melakukan ini beberapa kali:
- Seorang pakar dan beberapa pelatih bekerja di bangku ujian yang mensimulasikan perkhidmatan sebenar sebanyak mungkin. Pakar memecahkan perkhidmatan dalam pelbagai cara dan membolehkan pelatih memulihkannya mengikut DRP. Semua masalah, kekaburan dokumentasi dan ralat direkodkan. Selepas pelatih dilatih, DRP diperluaskan dan dipermudahkan di kawasan yang tidak jelas.
- Menguji perkhidmatan sebenar. Malah, anda tidak boleh membuat salinan sempurna perkhidmatan sebenar. Oleh itu, beberapa kali setahun adalah perlu untuk mematikan beberapa pelayan secara rutin, memutuskan sambungan dan menyebabkan bencana lain daripada senarai ancaman untuk menilai prosedur pemulihan. Kegagalan yang dirancang selama 10 minit di tengah malam adalah lebih baik daripada kegagalan mengejut selama beberapa jam semasa beban puncak dengan kehilangan data.
- Penyelesaian masalah sebenar. Ya, ini juga sebahagian daripada ujian. Jika berlaku kemalangan yang tiada dalam senarai ancaman, adalah perlu untuk menambah dan memuktamadkan DRP berdasarkan hasil siasatannya.
Perkara utama
- Jika najis boleh berlaku, ia bukan sahaja akan berlaku, tetapi ia akan berlaku dalam senario yang paling dahsyat yang mungkin.
- Pastikan anda mempunyai sumber untuk pemindahan beban kecemasan.
- Pastikan anda mempunyai sandaran, ia dibuat secara automatik dan kerap diperiksa untuk konsistensi.
- Fikirkan melalui senario ancaman biasa.
- Beri jurutera peluang untuk menghasilkan pilihan bukan standard untuk menyampaikan perkhidmatan.
- DRP harus menjadi arahan yang mudah dan tumpul. Semua diagnostik kompleks dijalankan hanya selepas perkhidmatan pelanggan telah dipulihkan. Walaupun pada kapasiti simpanan.
- Sediakan nombor telefon dan kenalan utama dalam DRP.
- Uji pemahaman pekerja tentang DRP dengan kerap.
- Susun kemalangan yang dirancang di tapak pengeluaran. Pendirian tidak boleh menggantikan segala-galanya.
Sumber: www.habr.com