Kahit na sa panahon ng kalamidad, laging may oras para sa isang tasa ng tsaa.
DRP Ang disaster recovery plan ay isang bagay na hindi mo na kailangan. Ngunit kung ang mga beaver na lumilipat sa panahon ng pag-aasawa ay ngumunguya sa fiber optic cable o na-crash ng isang junior admin ang iyong database ng produksyon, talagang gusto mong makatiyak na mayroon kang paunang naplanong tugon sa kaguluhang ito.
Habang nagsimulang tumawag sa tech support ang mga natarantang customer, naghahanap ang junior ng cyanide, at ikaw, na may matalinong hitsura, buksan ang pulang sobre at simulan ang pag-aayos ng lahat.
Sa post na ito, gusto kong magbahagi ng ilang rekomendasyon kung paano magsulat ng DRP at kung ano ang dapat na nilalaman nito. Sasaklawin din natin ang mga sumusunod:
- Matuto tayong mag-isip na parang kontrabida.
- Tingnan natin ang mga benepisyo ng isang tasa ng tsaa sa panahon ng apocalypse.
- Pag-isipan natin ang isang maginhawang istraktura ng DRP
- Tingnan natin kung paano subukan ito.
Anong mga kumpanya ang maaaring maging kapaki-pakinabang para sa?
Napakahirap na gumuhit ng linya kapag nagsimulang kailanganin ng isang departamento ng IT ang mga ganoong bagay. Sasabihin ko talagang kailangan mo ng DRP kung:
- Ang paghinto ng isang server, application, o pagkawala ng isang database ay magreresulta sa malaking pagkalugi para sa negosyo sa kabuuan.
- Mayroon kang ganap na IT department. Ang ibig kong sabihin ay isang departamento na isang ganap na yunit ng kumpanya, na may sariling badyet, at hindi lamang ng ilang pagod na empleyado na nagse-set up ng network, naglilinis ng mga virus, at nagre-refill ng mga printer.
- Mayroon kang makatotohanang badyet para sa hindi bababa sa isang bahagyang backup sa kaso ng isang emergency.
Kapag ang iyong departamento ng IT ay gumugol ng mga buwan na humihiling ng kahit na ilang HDD na idagdag sa iyong tumatandang server para sa mga backup, malamang na hindi ka makakapag-ayos ng isang buong-scale na paglipat ng down na serbisyo sa backup na kapasidad. Gayunpaman, ang dokumentasyon ay palaging nakakatulong dito.
Mahalaga ang dokumentasyon
Magsimula sa dokumentasyon. Sabihin nating ang iyong serbisyo ay pinapagana ng isang Perl script na isinulat tatlong henerasyon ang nakalipas ng mga admin, at walang nakakaalam kung paano ito gumagana. Ang naipon na teknikal na utang at kakulangan ng dokumentasyon ay hindi maiiwasang saktan ka, hindi lamang sa tuhod kundi sa iba pang mga paa't kamay; konting oras na lang.
Kapag mayroon kang magandang paglalarawan ng mga bahagi ng serbisyo, hanapin ang mga istatistika ng pag-crash. Sila ay halos tiyak na magiging pangkaraniwan. Halimbawa, ang iyong disk ay maaaring paminsan-minsan ay mapupuno, na nagiging sanhi ng isang node na mabigo hanggang sa ito ay manu-manong linisin. O maaaring maging hindi available ang serbisyo ng kliyente dahil may nakalimutang i-renew muli ang certificate, at ang Let's Encrypt ay hindi ma-configure o hindi ito ma-configure.
Mga isip na parang saboteur
Ang pinakamahirap na bahagi ay ang paghula ng mga pagkabigo na hindi pa nangyayari ngunit posibleng ganap na alisin ang iyong serbisyo. Dito kami ng mga kasamahan ko kadalasang kontrabida. Kumuha ng maraming kape at isang masarap at ikulong ang iyong sarili sa isang conference room. Siguraduhing i-lock mo ang mga inhinyero na nag-set up ng target na serbisyo o regular na nakikipagtulungan dito sa parehong silid. Pagkatapos, alinman sa isang whiteboard o sa papel, simulan ang pagguhit ng lahat ng posibleng kakila-kilabot na maaaring mangyari sa iyong serbisyo. Hindi mo na kailangang magdetalye, hanggang sa partikular na babaeng naglilinis at mga kable na hinihila; sapat na ang sitwasyong "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 serbisyo ng OS
- Nabigo ang aplikasyon
- Kabiguan ng bakal
- Nabigo ang virtualization
Suriin lang ang bawat uri at tingnan kung ano ang naaangkop sa iyong serbisyo. Halimbawa, ang isang Nginx daemon ay maaaring mag-crash at mabigong magsimula—ito ay nagpapahiwatig ng isang pagkabigo sa OS. Ang isang pambihirang sitwasyon na nagpapagana sa iyong web application ay isang pagkabigo ng software. Sa yugtong ito, mahalagang bumuo ng diagnostic para sa problema. Paano mo makikilala ang isang nakapirming interface sa virtualization mula sa isang down na Cisco box o isang network crash, halimbawa? Ito ay mahalaga upang mabilis mong matukoy ang mga responsable at simulan ang paghabol sa kanila hanggang sa malutas ang problema.
Kapag naitala ang mga tipikal na problema, nagbubuhos kami ng mas maraming kape at nagsisimulang isaalang-alang ang pinaka-hindi pangkaraniwang mga sitwasyon, kapag ang ilang mga parameter ay nagsimulang lumihis nang malaki mula sa pamantayan. Halimbawa:
- Ano ang mangyayari kung ang oras sa aktibong node ay magbabalik 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 nawalan ng koneksyon sa network habang nag-synchronize?
- Ano ang mangyayari kung mabibigo ang dalawang node na magbahagi ng pamumuno dahil sa pansamantalang paghihiwalay sa isa't isa sa network?
Sa yugtong ito, ang reverse approach ay lubhang nakakatulong. Kunin ang pinakaambisyoso na miyembro ng team na may pinaka-mapanlikhang isip at bigyan sila ng sabotahe sa serbisyo sa lalong madaling panahon. Kung mahirap i-diagnose, mas mabuti pa. Hindi ka maniniwala sa kakaiba at mahuhusay na ideya na naiisip ng mga inhinyero kapag binigyan mo sila ng ideya ng pagsira ng isang bagay. At kung nangako ka sa kanila ng isang test rig para dito, mas mabuti iyon.
Ano itong DRP mo?!
Kaya, tinukoy mo ang modelo ng pagbabanta. Isinaalang-alang mo ang mga lokal na residente na nagpuputol ng mga fiber optic na cable para maghanap ng tanso, at ang radar ng militar na mahigpit na bumababa sa linya ng relay ng radyo tuwing Biyernes nang 16:46 PM. Ngayon ay kailangan mong malaman kung ano ang gagawin sa lahat ng ito.
Ang iyong gawain ay isulat ang mga pulang sobre na mabubuksan sa isang emergency. Asahan na kapag (hindi kung!) ang lahat ay nagkamali, tanging ang pinaka-kamang nagsasanay ang naroroon, ang kanilang mga kamay ay marahas na nanginginig sa 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 namamatay, sila ay madalas na walang magawang hawakan ang lahat. Iyon ang dahilan kung bakit may malinaw na mga tagubilin na naka-post sa dingding na may mga hakbang tulad ng "buksan ang pakete nito" at "pangasiwaan ang mga intravenous x unit ng gamot."
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:
- Sino ang dapat ipaalam sa isang emergency? Mahalaga ito upang matiyak na ang proseso ng pagtugon ay kahanay hangga't maaari.
- Upang mag-diagnose nang tama, nagsasagawa kami ng pagsubaybay, tingnan ang servicename ng status ng systemctl, at iba pa.
- Gaano karaming oras ang maaari mong gugulin sa bawat yugto? Kung hindi mo ito maaayos nang manu-mano sa loob ng SLA, ang virtual machine ay papatayin at muling i-install mula sa backup kahapon.
- Paano masisigurong tapos na ang aksidente.
Tandaan na ang DRP ay nagsisimula kapag ang isang serbisyo ay ganap na nabigo at nagtatapos sa pagpapanumbalik ng kakayahang magamit, kahit na may pinababang kahusayan. Ang simpleng pagkawala ng redundancy ay hindi dapat mag-trigger ng DRP. Maaari ka ring magdagdag ng isang tasa ng tsaa sa iyong DRP. Seryoso. Ayon sa istatistika, maraming mga insidente ang napupunta mula sa hindi kasiya-siya hanggang sa sakuna dahil ang mga kawani ay nataranta at nagmamadaling ayusin ang isang bagay, nang sabay-sabay na pinapatay ang tanging nabubuhay na node na may data o ganap na sinisira ang cluster. Bilang isang patakaran, 5 minuto sa isang tasa ng tsaa ay magbibigay sa iyo ng ilang oras upang huminahon at pag-aralan kung ano ang nangyayari.
Huwag malito ang DRP sa system passport! Huwag i-overload ito ng hindi kinakailangang impormasyon. Magbigay lamang ng mabilis at madaling mga hyperlink sa kinakailangang seksyon ng dokumentasyon at basahin ang tungkol sa mga nauugnay na bahagi ng arkitektura ng serbisyo sa pinalawak na format. Ang DRP mismo ay dapat lamang maglaman ng mga direktang tagubilin kung saan at kung paano kumonekta, gamit ang mga partikular na command na copy-paste.
Paano sumubok ng tama
Tiyakin na ang bawat responsableng empleyado ay kayang kumpletuhin ang lahat ng mga hakbang. Sa pinakamahalagang sandali, maaaring lumabas na ang isang engineer ay walang mga karapatan sa pag-access sa kinakailangang system, walang mga password para sa kinakailangang account, o walang ideya kung ano ang ibig sabihin ng "Kumonekta sa console ng pamamahala ng serbisyo sa pamamagitan ng isang proxy sa punong tanggapan". Ang bawat hakbang ay dapat na kasing simple hangga't maaari.
Maling — "Pumunta sa virtualization at i-reboot ang patay na node."
Tama — "Kumonekta sa virt.example.com sa pamamagitan ng web interface, sa seksyon ng mga node, i-restart ang node na nagdudulot ng error."
Iwasan ang kalabuan. Alalahanin ang takot na intern.
Tiyaking subukan ang iyong DRP. Ito ay hindi lamang isang checkbox plan—ito ang magbibigay-daan sa iyo at sa iyong mga kliyente na mabilis na mag-navigate sa mga kritikal na sitwasyon. Sa isip, dapat mong gawin ito nang maraming beses:
- Isang eksperto at ilang intern ang nagtatrabaho sa isang test rig na malapit na ginagaya ang isang tunay na serbisyo. Ginagambala ng eksperto ang serbisyo sa iba't ibang paraan at pagkatapos ay pinapayagan ang mga intern na ibalik ito ayon sa DRP. Ang lahat ng mga problema, ambiguity sa dokumentasyon, at mga error ay naitala. Pagkatapos ng pagsasanay sa mga intern, ang DRP ay pinalawak at pinasimple sa hindi malinaw na mga lugar.
- Pagsubok sa isang tunay na serbisyo. Sa katotohanan, hindi kailanman posible na lumikha ng perpektong kopya ng isang tunay na serbisyo. Samakatuwid, ilang beses sa isang taon kinakailangan na magsagawa ng mga nakaiskedyul na pagsasara ng ilang mga server, guluhin ang mga koneksyon, at mag-trigger ng iba pang mga sakuna mula sa listahan ng banta upang masuri ang mga pamamaraan sa pagbawi. Ang nakaplanong 10 minutong sakuna sa kalagitnaan ng gabi ay mas mahusay kaysa sa biglaang pagkawala ng trabaho na tumatagal ng ilang oras sa peak load, na nagreresulta sa pagkawala ng data.
- Aktwal na paglutas ng aksidente. Oo, bahagi rin ito ng pagsubok. Kung may nangyaring aksidente na wala sa listahan ng pagbabanta, ang DRP ay dapat dagdagan at pinuhin batay sa mga resulta ng pagsisiyasat.
Mga pangunahing punto
- Kung may masamang mangyari, hindi lamang ito mangyayari, ngunit ito ay gagawin sa pinakamasamang paraan na posible.
- Tiyaking mayroon kang mga mapagkukunan para sa emergency na paglilipat ng pagkarga.
- Tiyaking mayroon kang mga backup, awtomatiko silang nilikha at regular na sinusuri para sa pagkakapare-pareho.
- Pag-isipan ang mga karaniwang sitwasyon ng pagbabanta.
- Bigyan ang mga inhinyero ng pagkakataon na makabuo ng mga hindi karaniwang opsyon para sa pagpapatupad ng serbisyo.
- Ang DRP ay dapat na isang simple, tuwirang pagtuturo. Ang lahat ng kumplikadong diagnostic ay dapat lamang gawin pagkatapos maibalik ang serbisyo ng mga customer, kahit na may backup na kapasidad lamang.
- Mangyaring isama ang mga pangunahing numero ng telepono at mga contact sa iyong DRP.
- Regular na subukan ang pag-unawa ng mga empleyado sa DRP.
- Ayusin ang nakaplanong pagkawala ng produksyon. Hindi mapapalitan ng stand ang lahat.
Pinagmulan: www.habr.com
