Malah nalika bencana, mesthi ana wektu kanggo ngombe teh.
DRP (rencana pemulihan bencana) minangka barang sing ora bakal dibutuhake. Nanging yen tiba-tiba berang-berang migrasi nalika musim kawin nyusup serat optik utama utawa admin junior ngeculake basis sing produktif, mesthine sampeyan pengin yakin manawa sampeyan duwe rencana sing wis digawe babagan apa sing kudu ditindakake kabeh iki.
Nalika pelanggan panik wiwit nelpon dhukungan teknologi, junior nggoleki sianida, sampeyan kanthi wicaksana mbukak amplop abang lan miwiti ngatur kabeh.
Ing kirim iki, aku pengin nuduhake rekomendasi babagan carane nulis DRP lan apa sing kudu ana. Kita uga bakal nliti ing ngisor iki:
- Sinau mikir kaya wong jahat.
- Ayo analisa manfaat secangkir teh sajrone kiamat.
- Coba struktur DRP sing trep
- Ayo ndeleng carane nyoba
Perusahaan endi sing bisa entuk manfaat saka iki?
Pancen angel banget kanggo nggambar garis nalika departemen IT wiwit mbutuhake barang kasebut. Aku bakal ujar manawa sampeyan dijamin butuh DRP yen:
- Mungkasi server, aplikasi, utawa ilang sawetara basis data bakal nyebabake kerugian sing signifikan kanggo bisnis kanthi sakabehe.
- Sampeyan duwe departemen IT lengkap. Maksudku, departemen minangka unit lengkap saka perusahaan, karo budget dhewe, lan ora mung sawetara karyawan kesel laying jaringan, reresik virus lan ngisi printer.
- Sampeyan duwe anggaran realistis kanggo paling ora redundansi parsial nalika ana darurat.
Nalika departemen IT wis ngemis kanggo paling saperangan saka HDD kanggo server lawas kanggo serep kanggo sasi, sampeyan ora kamungkinan kanggo ngatur relokasi lengkap layanan tiba kanggo kapasitas nyisakke. Senajan dokumentasi ora bakal superfluous kene uga.
Dokumentasi penting
Mulai karo dokumentasi. Contone, layanan sampeyan nganggo skrip Perl sing ditulis telung generasi admin kepungkur, lan ora ana sing ngerti cara kerjane. Utang teknis sing akumulasi lan kekurangan dokumentasi mesthi bakal nembak sampeyan ora mung ing dhengkul, nanging uga ing perangan awak liyane, iku mung masalah wektu.
Sawise sampeyan duwe katrangan sing apik babagan komponen layanan ing tangan, mundhakaken statistik kacilakan. Meh mesthi bakal rampung khas. Contone, sampeyan duwe disk kebak saka wektu kanggo wektu, sing nyebabake simpul gagal nganti diresiki kanthi manual. Utawa layanan klien dadi ora kasedhiya amarga kasunyatan sing ana maneh kelalen gawe sertifikat, lan Ayo Encrypt ora bisa diatur utawa ora pengin.
Pikiran kaya saboteur
Sisih paling angel yaiku prédhiksi kacilakan sing durung nate kedadeyan, nanging bisa ngrusak layanan sampeyan. Ing kene kita biasane main penjahat karo kolega. Njupuk akèh warung lan soko sedhep lan ngunci dhewe ing kamar rapat. Priksa manawa ing rapat sing padha sampeyan ngunci insinyur sing dhewe ngunggahake layanan target utawa kerjane kanthi rutin. Banjur, ing papan utawa ing kertas, sampeyan miwiti nggambar kabeh medeni sing bisa kedadeyan ing layanan sampeyan. Ora perlu rinci babagan wanita pembersih khusus lan narik kabel, cukup kanggo nimbang skenario "Pelanggaran integritas jaringan lokal".
Biasane, kahanan darurat sing paling umum cocog karo jinis ing ngisor iki:
- Gagal jaringan
- Gagal layanan OS
- Gagal aplikasi
- gagal wesi
- Gagal Virtualisasi
Cukup bukak saben tampilan lan deleng apa sing ditrapake kanggo layanan sampeyan. Contone, daemon Nginx bisa tiba lan ora munggah - iki minangka kegagalan ing bagean OS. Kahanan langka sing nyebabake aplikasi web sampeyan dadi ora bisa digunakake yaiku kegagalan piranti lunak. Sajrone pangembangan tahap iki, penting kanggo nemtokake diagnosis masalah kasebut. Carane mbedakake antarmuka Hung ing virtualisasi saka cisco tiba lan kacilakan jaringan, contone,. Iki penting kanggo cepet nemokake sing tanggung jawab lan miwiti narik buntut nganti kacilakan didandani.
Sawise masalah khas ditulis mudhun, kita pour kopi liyane lan wiwiti nimbang skenario strangest, nalika sawetara paramèter wiwit ngluwihi pakewuh. Tuladhane:
- Apa mengkono yen wektu ing simpul aktif gerakane bali menit relatif kanggo liyane ing kluster?
- Lan yen wektu maju, lan yen 10 taun?
- Apa sing kedadeyan yen simpul kluster tiba-tiba ilang jaringan sajrone sinkronisasi?
- Lan apa sing kedadeyan yen rong simpul ora nuduhake kepemimpinan amarga pamisahan sementara ing jaringan kasebut?
Ing tahap iki, pendekatan mbalikke mbantu akeh. Njupuk anggota paling wangkal saka tim karo bayangan lara lan menehi wong tugas kanggo ngatur pangalihan ing wektu paling cendhak, kang bakal sijine layanan mudhun. Yen angel didiagnosis, luwih apik. Sampeyan ora bakal pracaya gagasan aneh lan kelangan sing engineers teka karo nalika diwenehi idea kanggo break soko. Lan yen sampeyan janji karo wong-wong mau kanggo test stands iki, iku apik banget.
DRP-mu iki opo?!
Dadi sampeyan wis nemtokake model ancaman. Padha uga njupuk menyang akun residents lokal sing Cut kabel serat optik ing panelusuran tembaga, lan radar militèr sing irungnya baris relay radio strictly ana ing 16:46. Saiki kita kudu ngerti apa sing kudu ditindakake kabeh.
Tugas sampeyan yaiku nulis amplop abang sing padha sing bakal dibukak nalika darurat. Langsung nyana yen nalika (ora yen!) Kabeh wis ngaco munggah, mung trainee paling inexperienced bakal cedhak, kang tangan goyang-goyang violently saka medeni saka apa. Deleng carane tandha darurat ditindakake ing kantor medis. Contone, apa sing kudu ditindakake kanthi kejut anafilaksis. Staf medis ngerti kabeh protokol kanthi ati-ati, nanging nalika ana wong sing cedhak wiwit tiwas, asring kabeh wong ora duwe daya. Kanggo nindakake iki, instruksi sing jelas digantung ing tembok kanthi barang kaya "mbukak paket kasebut lan iki" lan "nyuntikake akeh unit obat kasebut kanthi intravena."
Iku angel kanggo mikir ing darurat! Mesthi ana instruksi prasaja kanggo parsing balung mburi.
DRP sing apik kalebu sawetara blok sing prasaja:
- Sapa sing kudu menehi kabar babagan wiwitan kacilakan. Iki penting supaya bisa parallelize proses eliminasi.
- Carane diagnosa bener - kita nglacak, katon ing systemctl status servicename lan ing.
- Pira wektu sing bisa ditindakake ing saben tahapan. Yen sampeyan ora duwe wektu kanggo ndandani karo tangan sak wektu SLA, mesin virtual matèni lan mbalek saka serep wingi.
- Carane nggawe manawa kacilakan wis rampung.
Elinga yen DRP diwiwiti nalika layanan wis rampung gagal lan rampung dening Recovery, malah karo efficiency suda. Mung ilang leladen ngirim ora ngaktifake DRP. Sampeyan uga bisa menehi resep secangkir teh ing DRP. Serius. Miturut statistik, akeh kacilakan dadi saka karu kanggo catastrophic amarga kasunyatan sing Staff ing gupuh cepet-cepet kanggo ndandani soko, bebarengan matèni mung simpul urip karo data utawa pungkasanipun rampung mati kluster. Minangka aturan, 5 menit kanggo secangkir teh bakal menehi wektu sethithik kanggo tenang lan nganalisa apa sing kedadeyan.
Aja bingung DRP lan paspor sistem! Aja kakehan data sing ora perlu. Mung menehi kesempatan kanggo cepet lan trep menyang bagean dibutuhake saka dokumentasi liwat hyperlinks lan maca ing format ditambahi bab bagean perlu saka arsitektur layanan. Lan ing DRP dhewe, mung ana instruksi langsung ing ngendi lan carane nyambungake karo perintah khusus kanggo nyalin-tempel.
Carane nguji kanthi bener
Priksa manawa karyawan sing tanggung jawab bisa ngrampungake kabeh item. Ing wayahe sing paling penting, bisa uga insinyur ora duwe hak akses menyang sistem sing dibutuhake, ora ana sandhi kanggo akun sing dibutuhake, utawa dheweke ora ngerti apa "Sambungake menyang konsol manajemen layanan liwat proxy ing kantor pusat” tegese. Saben item kudu dadi prasaja sabisa.
Salah - "Go menyang virtualisasi lan urip maneh simpul mati"
Bener - "Sambungake liwat antarmuka web menyang virt.example.com, ing bagean simpul, muat ulang simpul sing nyebabake kesalahan."
Nyingkiri ambiguitas. Elingi intern sing wedi.
Priksa manawa kanggo nyoba DRP. Iki ora mung rencana kanggo pertunjukan - iki sing bakal ngidini sampeyan lan klien cepet metu saka kahanan kritis. Paling apik kanggo nindakake iki kaping pirang-pirang:
- Siji pakar lan sawetara magang kerja ing bangku tes sing niru layanan nyata sabisa-bisa. Pakar kasebut ngilangi layanan kasebut kanthi macem-macem cara lan ngidini para pelatih bisa mulihake miturut DRP. Kabeh masalah, ambiguitas ing dokumentasi lan kasalahan direkam. Sawise nglatih para trainee, DRP dilengkapi lan disederhanakake ing panggonan sing ora jelas.
- Testing ing layanan nyata. Nyatane, sampeyan ora bisa nggawe salinan sampurna saka layanan nyata. Mulane, saperangan saka kaping taun iku perlu kanggo mateni bagean saka server ing basis ngrancang, break sambungan lan ngatur kacilakan liyane saka dhaftar ancaman kanggo ngevaluasi urutan Recovery. Iku luwih apik kanggo duwe 10-menit ngrancang outage ing tengah wengi saka Gagal dadakan kanggo sawetara jam ing mbukak puncak karo mundhut data.
- Ngilangi nyata saka kacilakan. Ya, iki uga bagean saka tes. Yen ana kacilakan sing ora ana ing dhaptar ancaman, perlu kanggo nambah lan ngrampungake DRP adhedhasar asil investigasi.
Titik Kunci
- Yen omong kosong bisa kelakon, ora mung kedadeyan, nanging bakal ditindakake ing skenario sing paling mbebayani.
- Priksa manawa sampeyan duwe sumber daya kanggo failover.
- Priksa manawa sampeyan duwe serep, digawe kanthi otomatis lan dipriksa konsistensi kanthi rutin.
- Coba skenario ancaman sing khas.
- Menehi engineers kesempatan kanggo teka munggah karo opsi non-standar kanggo sijine layanan.
- DRP kudu instruksi prasaja lan bisu. Kabeh diagnostik rumit mung sawise pelanggan mbalekake layanan. Sanajan wis siyaga.
- Dhaptar nomer telpon lan kontak utama ing DRP.
- Ajeg nyoba karyawan kanggo pemahaman DRP.
- Ngatur kacilakan sing direncanakake ing produk kasebut. Stand ora bisa ngganti kabeh.
Source: www.habr.com