Paghahanda ng DRP - huwag kalimutang isaalang-alang ang meteorite

Kahit na sa panahon ng sakuna ay laging may oras para sa isang tasa ng tsaa

DRP (disaster recovery plan) ay isang bagay na perpektong hindi na kakailanganin. Ngunit kung biglang gumapang ang mga beaver sa panahon ng pag-aasawa sa backbone optical fiber o ang isang junior admin ay bumaba sa produktibong base, tiyak na gusto mong makatiyak na magkakaroon ka ng paunang ginawang plano para sa kung ano ang gagawin sa lahat ng kahihiyang ito.

Habang ang mga customer sa gulat ay nagsimulang putulin ang mga technical support phone, ang junior ay naghahanap ng cyanide, matalino mong binuksan ang pulang sobre at sinimulang ayusin ang lahat.

Sa post na ito gusto kong magbahagi ng mga rekomendasyon kung paano magsulat ng DRP at kung ano ang dapat na nilalaman nito. Titingnan din natin ang mga sumusunod na bagay:

1. Matuto tayong mag-isip na parang kontrabida.
2. Tingnan natin ang mga benepisyo ng isang tasa ng tsaa sa panahon ng apocalypse.
3. Pag-isipan natin ang isang maginhawang istraktura ng DRP
4. Tingnan natin kung paano subukan ito

Aling mga kumpanya ang maaaring maging kapaki-pakinabang para sa?

Napakahirap gumuhit ng linya kapag nagsimulang kailanganin ng departamento ng IT ang mga ganoong bagay. Sasabihin ko na talagang kailangan mo ng DRP kung:

• Ang paghinto ng isang server, application o pagkawala ng ilang database ay hahantong sa malaking pagkalugi para sa negosyo sa kabuuan.
• Mayroon kang ganap na departamento ng IT. Sa kahulugan ng isang departamento sa anyo ng isang ganap na yunit ng kumpanya, na may sariling badyet, at hindi lamang ng ilang pagod na empleyado na naglalagay ng network, naglilinis ng mga virus at nagre-refill ng mga printer.
• Mayroon kang makatotohanang badyet para sa hindi bababa sa bahagyang redundancy sa kaso ng isang emergency.

Kapag ang IT department ay namamalimos nang ilang buwan nang hindi bababa sa ilang mga HDD sa isang lumang server para sa mga backup, malamang na hindi mo magagawang ayusin ang isang ganap na paglipat ng isang nabigong serbisyo upang magreserba ng kapasidad. Bagaman dito ang dokumentasyon ay hindi magiging kalabisan.

Mahalaga ang dokumentasyon

Magsimula sa dokumentasyon. Sabihin nating tumatakbo ang iyong serbisyo sa isang Perl script na isinulat ng mga admin tatlong henerasyon ang nakalipas, ngunit walang nakakaalam kung paano ito gumagana. Ang naipon na teknikal na utang at kakulangan ng dokumentasyon ay hindi maiiwasang mabaril ka hindi lamang sa tuhod, kundi pati na rin sa iba pang mga limbs, ito ay mas isang bagay ng oras.

Kapag mayroon kang magandang paglalarawan ng mga bahagi ng serbisyo, hanapin ang mga istatistika ng aksidente. Sila ay halos tiyak na magiging ganap na tipikal. Halimbawa, ang iyong disk ay nagiging puno paminsan-minsan, na nagiging sanhi ng pagkabigo ng node hanggang sa ito ay manu-manong linisin. O magiging hindi available ang serbisyo ng kliyente dahil sa katotohanang may nakalimutang muli na i-renew ang certificate, at ang Let's Encrypt ay hindi nagawa o ayaw mag-configure.

Mga isip na parang saboteur

Ang pinakamahirap na bahagi ay ang paghula sa mga aksidenteng iyon na hindi pa nangyari dati, ngunit maaaring ganap na masira ang iyong serbisyo. Dito kami ng mga kasamahan ko kadalasang kontrabida. Uminom ng maraming kape at isang masarap at ikulong ang iyong sarili sa isang meeting room. Siguraduhin lamang na sa parehong mga negosasyon ay ikinukulong mo ang mga inhinyero na sila mismo ang bumuo ng target na serbisyo o regular na nakikipagtulungan dito. Pagkatapos, sa pisara man o sa papel, sinimulan mong iguhit ang lahat ng posibleng kakila-kilabot na maaaring mangyari sa iyong serbisyo. Hindi kinakailangang magdetalye sa isang partikular na babaeng tagapaglinis at maglabas ng mga kable; sapat na upang isaalang-alang ang senaryo ng "Paglabag sa integridad ng lokal na network."

Karaniwan, ang karamihan sa mga karaniwang sitwasyong pang-emergency ay nahahati sa mga sumusunod na uri:

• Pagkabigo sa network
• Nabigo ang mga serbisyo ng OS
• Nabigo ang aplikasyon
• Kabiguan ng bakal
• Nabigo ang virtualization

Suriin lamang ang bawat uri at tingnan kung ano ang naaangkop sa iyong serbisyo. Halimbawa, ang Nginx daemon ay maaaring bumagsak at hindi tumaas - nangangahulugan ito ng mga pagkabigo sa bahagi ng OS. Ang isang bihirang sitwasyon na nagiging sanhi ng pagkabigo ng iyong web application ay isang pagkabigo ng software. Habang nagtatrabaho sa yugtong ito, mahalagang gawin ang diagnosis ng problema. Paano makilala ang isang nakapirming interface sa virtualization mula sa isang nahulog na cis drive at isang aksidente sa network, halimbawa. Mahalaga ito upang mabilis na mahanap ang mga responsable at simulan ang paghila ng kanilang buntot hanggang sa malutas ang aksidente.

Matapos maisulat ang mga tipikal na problema, nagbubuhos kami ng mas maraming kape at nagsimulang isaalang-alang ang mga kakaibang sitwasyon, kapag ang ilang mga parameter ay nagsimulang lumampas sa karaniwan. Halimbawa:

• Ano ang mangyayari kung ang oras sa aktibong node ay umuurong ng isang minuto na may kaugnayan sa iba sa cluster?
• Paano kung umusad ang panahon, paano kung sa 10 taon?
• Ano ang mangyayari kung ang isang cluster node ay biglang nawala ang network nito habang nag-synchronize?
• Ano ang mangyayari kung ang dalawang node ay hindi magbahagi ng pamumuno dahil sa pansamantalang paghihiwalay ng bawat isa sa network?

Sa yugtong ito, ang reverse approach ay lubhang nakakatulong. Kinukuha mo ang pinaka-matigas ang ulo na miyembro ng koponan na may sakit na imahinasyon at binibigyan mo siya ng gawain ng pag-aayos ng isang sabotahe sa pinakamaikling posibleng oras na magpapabagsak sa serbisyo. Kung mahirap i-diagnose, mas mabuti pa. Hindi ka maniniwala sa kung anong kakaiba at cool na ideya ang naiisip ng mga inhinyero kung bibigyan mo sila ng ideya na sirain ang isang bagay. At kung mangangako ka sa kanila ng test bench para dito, ayos lang iyon.

Ano itong DRP mo?!

Kaya natukoy mo ang iyong modelo ng pagbabanta. Isinasaalang-alang din nila ang mga lokal na residente na nagpuputol ng fiber optic cable sa paghahanap ng tanso, at isang radar ng militar na mahigpit na bumababa sa isang radio relay line tuwing Biyernes sa 16:46. Ngayon kailangan nating maunawaan kung ano ang gagawin sa lahat ng ito.

Ang iyong gawain ay isulat ang mga napakapulang sobre na mabubuksan sa isang emergency. Agad na asahan na kapag (hindi kung!) ang lahat ay natapos na, tanging ang pinaka walang karanasan na intern ay nasa malapit, na ang mga kamay ay nanginginig nang marahas sa kakila-kilabot sa nangyayari. Tingnan kung paano ipinapatupad ang mga emergency sign sa mga opisinang medikal. Halimbawa, kung ano ang gagawin sa kaso ng anaphylactic shock. Alam ng mga medikal na kawani ang lahat ng mga protocol sa pamamagitan ng puso, ngunit kapag ang isang tao sa malapit ay nagsimulang mamatay, kadalasan ang lahat ay walang magawa na nakakapit sa lahat ng bagay na nakikita. Upang gawin ito, may malinaw na mga tagubilin sa dingding na may mga item tulad ng "buksan ang pakete ng ganito at ganoon" at "pangasiwaan ang napakaraming yunit ng gamot sa intravenously."

Ang hirap mag-isip kapag emergency! Dapat mayroong mga simpleng tagubilin para sa pag-parse ng spinal cord.

Ang isang mahusay na DRP ay binubuo ng ilang simpleng mga bloke:

1. Sino ang aabisuhan tungkol sa simula ng isang aksidente. Ito ay mahalaga upang maiparallelize ang proseso ng pag-aalis hangga't maaari.
2. Paano mag-diagnose ng tama - magsagawa ng isang bakas, tingnan ang systemctl status servicename at iba pa.
3. Gaano karaming oras ang maaari mong gugulin sa bawat yugto? Kung wala kang oras upang manu-manong ayusin ito sa loob ng oras ng SLA, ang virtual machine ay papatayin at ibabalik mula sa backup kahapon.
4. Paano masisigurong tapos na ang aksidente.

Tandaan na ang DRP ay nagsisimula kapag ang serbisyo ay ganap na nabigo at nagtatapos kapag ang serbisyo ay naibalik, kahit na may pinababang kahusayan. Ang simpleng pagkawala ng reserbasyon ay hindi dapat mag-trigger ng DRP. Maaari ka ring magsulat ng isang tasa ng tsaa sa DRP. Seryoso. Ayon sa istatistika, maraming mga aksidente ang nagiging sakuna mula sa hindi kasiya-siya dahil sa ang katunayan na ang mga tauhan ay nagmamadaling ayusin ang isang bagay, sabay-sabay na pinapatay ang nag-iisang buhay na node na may data o sa wakas ay tinatapos ang kumpol. Bilang isang patakaran, 5 minuto na may isang tasa ng tsaa ay magbibigay sa iyo ng ilang oras upang huminahon at pag-aralan kung ano ang nangyayari.

Huwag malito ang DRP at system passport! Huwag i-overload ito ng hindi kinakailangang data. Gawing posible lamang na mabilis at maginhawang gumamit ng mga hyperlink upang pumunta sa nais na seksyon ng dokumentasyon at magbasa sa isang pinalawak na format tungkol sa mga kinakailangang seksyon ng arkitektura ng serbisyo. At sa DRP mismo mayroon lamang mga direktang tagubilin kung saan at kung paano kumonekta sa mga partikular na command para sa copy-paste.

Paano sumubok ng tama

Tiyaking kayang kumpletuhin ng sinumang responsableng empleyado ang lahat ng mga item. Sa pinakamahalagang sandali, maaaring lumabas na ang inhinyero ay walang mga karapatan na ma-access ang kinakailangang sistema, walang mga password para sa kinakailangang account, o wala siyang ideya kung ano ang "Kumonekta sa console ng pamamahala ng serbisyo sa pamamagitan ng isang proxy sa punong tanggapan” ay nangangahulugang. Ang bawat punto ay dapat na napakasimple.

Maling — “Pumunta sa virtualization at i-reboot ang patay na node”
Tama - "Kumonekta sa pamamagitan ng web interface sa virt.example.com, sa seksyon ng mga node, i-reboot ang node na nagdudulot ng error."

Iwasan ang kalabuan. Alalahanin ang natakot na intern.

Tiyaking subukan ang DRP. Ito ay hindi lamang isang plano para sa palabas - ito ay isang bagay na magbibigay-daan sa iyo at sa iyong mga kliyente na mabilis na makaalis sa isang kritikal na sitwasyon. Pinakamabuting gawin ito nang maraming beses:

• Ang isang eksperto at ilang trainees ay nagtatrabaho sa isang test bench na gayahin ang isang tunay na serbisyo hangga't maaari. Sinisira ng eksperto ang serbisyo sa iba't ibang paraan at binibigyang-daan ang mga trainees na ibalik ito ayon sa DRP. Ang lahat ng mga problema, mga ambiguity ng dokumentasyon at mga error ay naitala. Pagkatapos na sanayin ang mga trainees, ang DRP ay pinalawak at pinasimple sa hindi malinaw na mga lugar.
• Pagsubok sa isang tunay na serbisyo. Sa katunayan, hindi ka makakagawa ng perpektong kopya ng isang tunay na serbisyo. Samakatuwid, ilang beses sa isang taon kinakailangan na regular na patayin ang ilan sa mga server, putulin ang mga koneksyon at magdulot ng iba pang mga sakuna mula sa listahan ng mga banta upang masuri ang order ng pagbawi. Ang isang nakaplanong pagkabigo sa loob ng 10 minuto sa kalagitnaan ng gabi ay mas mahusay kaysa sa isang biglaang pagkabigo sa loob ng ilang oras sa panahon ng peak load na may pagkawala ng data.
• Tunay na pag-troubleshoot. Oo, bahagi rin ito ng pagsubok. Kung may nangyaring aksidente na wala sa listahan ng mga banta, kinakailangang dagdagan at isapinal ang DRP batay sa mga resulta ng imbestigasyon nito.

Pangunahing puntos

1. Kung ang tae ay maaaring mangyari, ito ay hindi lamang mangyayari, ngunit ito ay gagawin sa pinakakapahamak na senaryo na posible.
2. Tiyaking mayroon kang mga mapagkukunan para sa emergency na paglilipat ng pagkarga.
3. Tiyaking mayroon kang mga backup, awtomatiko silang nalilikha at regular na sinusuri para sa pagkakapare-pareho.
4. Pag-isipan ang mga karaniwang sitwasyon ng pagbabanta.
5. Bigyan ang mga inhinyero ng pagkakataon na makabuo ng mga hindi karaniwang opsyon para sa paghahatid ng serbisyo.
6. Ang DRP ay dapat na isang simple at mapurol na pagtuturo. Ang lahat ng mga kumplikadong diagnostic ay isinasagawa lamang pagkatapos na maibalik ang serbisyo ng mga kliyente. Kahit na nasa reserbang kapasidad.
7. Magbigay ng mga pangunahing numero ng telepono at mga contact sa DRP.
8. Regular na subukan ang pag-unawa ng mga empleyado sa DRP.
9. Ayusin ang mga nakaplanong aksidente sa mga lugar ng produksyon. Hindi mapapalitan ng stand ang lahat.

Pinagmulan: www.habr.com