Kahit baha, dapat gumana ang 1C! Sumasang-ayon kami sa negosyo sa DR

Isipin: sineserbisyuhan mo ang imprastraktura ng IT ng isang malaking shopping center. Nagsisimula nang umulan sa lungsod. Bumubuhos ang mga agos ng ulan sa bubong, pinupuno ng tubig ang mga retail na lugar hanggang bukung-bukong. Umaasa kami na ang iyong silid ng server ay wala sa basement, kung hindi man ay hindi maiiwasan ang mga problema.  

Ang kuwentong inilarawan ay hindi isang pantasya, ngunit isang kolektibong paglalarawan ng ilang mga kaganapan ng 2020. Sa malalaking kumpanya, ang isang disaster recovery plan, o disaster recovery plan (DRP), ay palaging nasa kamay para sa kasong ito. Sa mga korporasyon, responsibilidad ito ng mga espesyalista sa pagpapatuloy ng negosyo. Ngunit sa katamtaman at maliliit na kumpanya, ang paglutas ng mga naturang problema ay nahuhulog sa mga serbisyo ng IT. Kailangan mong maunawaan ang lohika ng negosyo sa iyong sarili, maunawaan kung ano ang maaaring mabigo at kung saan, magkaroon ng proteksyon at ipatupad ito. 

Mahusay kung ang isang espesyalista sa IT ay maaaring makipag-ayos sa negosyo at talakayin ang pangangailangan para sa proteksyon. Ngunit nakita ko nang higit sa isang beses kung paano nagtipid ang isang kumpanya sa isang solusyon sa pagbawi ng kalamidad (DR) dahil itinuturing itong kalabisan. Kapag naganap ang isang aksidente, ang isang mahabang pagbawi ay nagbanta ng mga pagkalugi, at ang negosyo ay hindi handa. Maaari mong ulitin hangga't gusto mo: "Sinabi ko na sa iyo," ngunit kailangan pa ring ibalik ng serbisyo ng IT ang mga serbisyo.

Mula sa posisyon ng isang arkitekto, sasabihin ko sa iyo kung paano maiwasan ang sitwasyong ito. Sa unang bahagi ng artikulo, ipapakita ko ang gawaing paghahanda: kung paano talakayin ang tatlong tanong sa customer para sa pagpili ng mga tool sa seguridad: 

• Ano ang pinoprotektahan natin?
• Ano ang pinoprotektahan natin?
• Gaano natin pinoprotektahan? 

Sa ikalawang bahagi, pag-uusapan natin ang tungkol sa mga opsyon para sa pagsagot sa tanong: kung paano ipagtanggol ang iyong sarili. Magbibigay ako ng mga halimbawa ng mga kaso kung paano binuo ng iba't ibang mga customer ang kanilang proteksyon.

Ang aming pinoprotektahan: pagtukoy sa mga kritikal na function ng negosyo 

Mas mainam na simulan ang paghahanda sa pamamagitan ng pagtalakay sa post-emergency action plan sa customer ng negosyo. Ang pangunahing kahirapan dito ay ang paghahanap ng isang karaniwang wika. Karaniwang walang pakialam ang customer kung paano gumagana ang solusyon sa IT. Siya ay nagmamalasakit kung ang serbisyo ay maaaring gumanap ng mga function ng negosyo at magdala ng pera. Halimbawa: kung ang site ay gumagana, ngunit ang sistema ng pagbabayad ay down, walang kita mula sa mga kliyente, at ang mga "ekstremista" ay mga espesyalista pa rin sa IT. 

Ang isang propesyonal sa IT ay maaaring nahihirapan sa gayong mga negosasyon sa ilang kadahilanan:

• Hindi lubos na nauunawaan ng serbisyong IT ang papel ng sistema ng impormasyon sa negosyo. Halimbawa, kung walang available na paglalarawan ng mga proseso ng negosyo o isang transparent na modelo ng negosyo. 
• Hindi nakasalalay ang buong proseso sa serbisyo ng IT. Halimbawa, kapag ang bahagi ng trabaho ay ginagawa ng mga kontratista, at ang mga espesyalista sa IT ay walang direktang impluwensya sa kanila.

Buuin ko ang pag-uusap tulad nito: 

1. Ipinapaliwanag namin sa mga negosyo na nangyayari ang mga aksidente sa lahat, at nangangailangan ng oras ang pagbawi. Ang pinakamagandang bagay ay upang ipakita ang mga sitwasyon, kung paano ito nangyayari at kung anong mga kahihinatnan ang posible.
2. Ipinakita namin na hindi lahat ay nakasalalay sa serbisyo ng IT, ngunit handa kang tumulong sa isang plano ng aksyon sa iyong lugar ng responsibilidad.
3. Hinihiling namin sa customer ng negosyo na sagutin: kung mangyari ang apocalypse, aling proseso ang dapat na unang ibalik? Sino ang nakikilahok dito at paano? 

   Isang simpleng sagot ang kailangan mula sa negosyo, halimbawa: kailangang ipagpatuloy ng call center ang pagrerehistro ng mga aplikasyon 24/7.

4. Hinihiling namin sa isa o dalawang user ng system na ilarawan ang prosesong ito nang detalyado. 
   Mas mainam na isama ang isang analyst upang tumulong kung mayroon ang iyong kumpanya.

   Upang magsimula, ang paglalarawan ay maaaring magmukhang ganito: ang call center ay tumatanggap ng mga kahilingan sa pamamagitan ng telepono, sa pamamagitan ng koreo at sa pamamagitan ng mga mensahe mula sa website. Pagkatapos ay ipinasok niya ang mga ito sa 1C sa pamamagitan ng web interface, at dinadala sila ng produksyon mula doon sa ganitong paraan.

5. Pagkatapos ay titingnan namin kung anong mga solusyon sa hardware at software ang sumusuporta sa proseso. Para sa komprehensibong proteksyon, isinasaalang-alang namin ang tatlong antas: 
   • mga application at system sa loob ng site (antas ng software),   
   • ang mismong site kung saan tumatakbo ang mga system (antas ng imprastraktura), 
   • network (madalas nilang nakakalimutan ito).

6. Nalaman namin ang mga posibleng punto ng pagkabigo: mga node ng system kung saan nakasalalay ang pagganap ng serbisyo. Hiwalay kaming nagpapansinan ng mga node na sinusuportahan ng ibang mga kumpanya: mga operator ng telecom, hosting provider, data center, at iba pa. Sa pamamagitan nito, maaari kang bumalik sa customer ng negosyo para sa susunod na hakbang.

Kung ano ang aming pinoprotektahan mula sa: mga panganib

Susunod, malalaman natin mula sa customer ng negosyo kung anong mga panganib ang una nating pinoprotektahan ang ating sarili. Ang lahat ng mga panganib ay maaaring nahahati sa dalawang grupo: 

• pagkawala ng oras dahil sa downtime ng serbisyo;
• pagkawala ng data dahil sa mga pisikal na epekto, mga kadahilanan ng tao, atbp.

Ang mga negosyo ay natatakot na mawalan ng parehong data at oras - lahat ng ito ay humahantong sa pagkawala ng pera. Kaya muli kaming nagtatanong para sa bawat pangkat ng panganib: 

• Para sa prosesong ito, maaari ba nating tantyahin kung magkano ang halaga ng pagkawala ng data at pagkawala ng oras sa pera? 
• Anong data ang hindi natin mawawala? 
• Saan tayo hindi maaaring magbigay ng downtime? 
• Anong mga kaganapan ang pinaka-malamang at pinaka-nagbabanta sa atin?

Pagkatapos ng talakayan, mauunawaan natin kung paano uunahin ang mga punto ng kabiguan. 

Gaano natin pinoprotektahan: RPO at RTO 

Kapag malinaw ang mga kritikal na punto ng pagkabigo, kinakalkula namin ang mga tagapagpahiwatig ng RTO at RPO. 

Ipaalala ko sa iyo iyon RTO (layunin sa oras ng pagbawi) — ito ang pinahihintulutang oras mula sa sandali ng aksidente hanggang sa ganap na maibalik ang serbisyo. Sa wika ng negosyo, ito ay katanggap-tanggap na downtime. Kung alam namin kung gaano karaming pera ang dinala ng proseso, maaari naming kalkulahin ang mga pagkalugi mula sa bawat minuto ng downtime at kalkulahin ang katanggap-tanggap na pagkawala. 

RPO (layunin sa recovery point) — wastong data recovery point. Tinutukoy nito ang oras kung kailan tayo maaaring mawalan ng data. Mula sa pananaw ng negosyo, ang pagkawala ng data ay maaaring magresulta sa mga multa, halimbawa. Ang ganitong mga pagkalugi ay maaari ding i-convert sa pera. 

Kailangang kalkulahin ang oras ng pagbawi para sa end user: gaano katagal siya makakapag-log in sa system. Kaya una naming idagdag ang oras ng pagbawi ng lahat ng mga link sa chain. Madalas na nagkakamali dito: kinukuha nila ang RTO ng provider mula sa SLA, at nakalimutan ang mga natitirang termino.

Tingnan natin ang isang partikular na halimbawa. Nag-log in ang user sa 1C, bubukas ang system na may error sa database. Nakipag-ugnayan siya sa system administrator. Ang database ay matatagpuan sa cloud, iniulat ng system administrator ang problema sa service provider. Sabihin nating tumatagal ng 15 minuto ang lahat ng komunikasyon. Sa cloud, ang isang database ng ganitong laki ay maibabalik mula sa isang backup sa loob ng isang oras, samakatuwid, ang RTO sa panig ng service provider ay isang oras. Ngunit hindi ito ang huling deadline; para sa gumagamit, 15 minuto ang idinagdag dito upang makita ang problema. 
 
Susunod, kailangang suriin ng administrator ng system kung tama ang database, ikonekta ito sa 1C at simulan ang mga serbisyo. Nangangailangan ito ng isa pang oras, na nangangahulugan na ang RTO sa panig ng administrator ay 2 oras at 15 minuto na. Ang gumagamit ay nangangailangan ng isa pang 15 minuto: mag-log in, tingnan kung ang mga kinakailangang transaksyon ay lumitaw. 2 oras 30 minuto ang kabuuang oras ng pagbawi ng serbisyo sa halimbawang ito.

Ipapakita ng mga kalkulasyong ito sa negosyo kung anong mga panlabas na salik ang nakasalalay sa panahon ng pagbawi. Halimbawa, kung baha ang opisina, kailangan mo munang hanapin ang leak at ayusin ito. Kakailanganin ito ng oras, na hindi nakasalalay sa IT.  

Paano namin pinoprotektahan: pagpili ng mga tool para sa iba't ibang panganib

Matapos talakayin ang lahat ng mga punto, naiintindihan na ng customer ang halaga ng isang aksidente para sa negosyo. Ngayon ay maaari kang pumili ng mga tool at talakayin ang badyet. Gamit ang mga halimbawa ng mga kaso ng kliyente, ipapakita ko sa iyo kung anong mga tool ang inaalok namin para sa iba't ibang gawain. 

Magsimula tayo sa unang pangkat ng mga panganib: pagkalugi dahil sa downtime ng serbisyo. Ang mga solusyon para sa problemang ito ay dapat magbigay ng magandang RTO.

1. I-host ang application sa cloud 

   Upang magsimula, maaari kang lumipat sa cloud - naisip na ng provider ang mga isyu ng mataas na kakayahang magamit. Ang mga host ng virtualization ay pinagsama-sama sa isang cluster, ang kapangyarihan at network ay nakalaan, ang data ay naka-imbak sa mga fault-tolerant na storage system, at ang service provider ay may pananagutan sa pananalapi para sa downtime.

   Halimbawa, maaari kang mag-host ng virtual machine na may database sa cloud. Ang application ay kumonekta sa database sa labas sa pamamagitan ng isang itinatag na channel o mula sa parehong ulap. Kung may mga problema sa isa sa mga server sa cluster, magre-restart ang VM sa kalapit na server sa loob ng wala pang 2 minuto. Pagkatapos nito, magsisimula ang DBMS dito, at sa ilang minuto ay magiging available na ang database.

   RTO: sinusukat sa ilang minuto. Maaaring tukuyin ang mga tuntuning ito sa kasunduan sa provider.
   Gastos: Kinakalkula namin ang halaga ng mga mapagkukunan ng ulap para sa iyong aplikasyon. 
   Kung ano ang hindi nito mapoprotektahan ka: mula sa napakalaking pagkabigo sa site ng provider, halimbawa, dahil sa mga aksidente sa antas ng lungsod.

2. I-cluster ang application  

   Kung gusto mong pagbutihin ang RTO, maaari mong palakasin ang nakaraang opsyon at agad na maglagay ng clustered application sa cloud.

   Maaari kang magpatupad ng cluster sa active-passive o active-active mode. Gumagawa kami ng ilang VM batay sa mga kinakailangan ng vendor. Para sa higit na pagiging maaasahan, ipinamahagi namin ang mga ito sa iba't ibang server at storage system. Kung nabigo ang server na may isa sa mga database, ang backup na node ang kukuha sa pag-load sa loob ng ilang segundo.

   RTO: Sinusukat sa mga segundo.
   Gastos: bahagyang mas mahal kaysa sa isang regular na ulap, kakailanganin ang mga karagdagang mapagkukunan para sa clustering.
   Kung ano ang hindi nito mapoprotektahan ka: Hindi pa rin mapoprotektahan laban sa malalaking pagkabigo sa site. Ngunit ang mga lokal na pagkagambala ay hindi magtatagal.

   Mula sa pagsasanay: Ang kumpanya ng retail ay may ilang mga sistema ng impormasyon at mga website. Ang lahat ng mga database ay lokal na matatagpuan sa opisina ng kumpanya. Walang DR na inisip hanggang sa naiwan ang opisina na walang kuryente ng ilang beses na magkasunod. Hindi nasisiyahan ang mga customer sa mga pag-crash ng website. 
    
   Nalutas ang problema sa availability ng serbisyo pagkatapos lumipat sa cloud. Dagdag pa, nagawa naming i-optimize ang load sa mga database sa pamamagitan ng pagbabalanse ng trapiko sa pagitan ng mga node.

3. Lumipat sa isang ulap na hindi tinatablan ng sakuna

   Kung kailangan mong tiyakin na kahit na ang isang natural na sakuna sa pangunahing site ay hindi nakakasagabal sa iyong trabaho, maaari kang pumili ng isang cloud na lumalaban sa sakuna. Sa opsyong ito, ikakalat ng provider ang virtualization cluster sa 2 data center. Ang patuloy na kasabay na pagtitiklop ay nangyayari sa pagitan ng mga sentro ng data, isa-sa-isa. Ang mga channel sa pagitan ng mga sentro ng data ay nakalaan at sumasama sa iba't ibang mga ruta, kaya ang ganitong kumpol ay hindi natatakot sa mga problema sa network. 

   RTO: may posibilidad na 0.
   Gastos: Ang pinakamahal na opsyon sa cloud. 
   Kung ano ang hindi nito mapoprotektahan ka: Hindi ito makakatulong laban sa katiwalian ng data, gayundin mula sa kadahilanan ng tao, kaya inirerekomenda na gumawa ng mga backup nang sabay. 

   Mula sa pagsasanay: Ang isa sa aming mga kliyente ay bumuo ng isang komprehensibong plano sa pagbawi ng kalamidad. Ito ang napili niyang diskarte: 

   • Pinoprotektahan ng disaster-tolerant cloud ang application mula sa mga pagkabigo sa antas ng imprastraktura. 
   • Ang dalawang antas na backup ay nagbibigay ng proteksyon sa kaso ng pagkakamali ng tao. Mayroong dalawang uri ng pag-backup: "malamig" at "mainit". Ang isang "malamig" na backup ay nasa isang naka-disable na estado at nangangailangan ng oras upang i-deploy. Ang isang "mainit" na backup ay handa nang gamitin at naibalik nang mas mabilis. Ito ay naka-imbak sa isang espesyal na nakatuong sistema ng imbakan. Ang ikatlong kopya ay naitala sa tape at nakaimbak sa ibang silid. 

   Minsan sa isang linggo, sinusuri ng kliyente ang proteksyon at sinusuri ang paggana ng lahat ng backup, kabilang ang mga mula sa tape. Bawat taon sinusubok ng kumpanya ang buong ulap na lumalaban sa kalamidad. 

4. Ayusin ang pagtitiklop sa ibang site 

   Isa pang opsyon kung paano maiiwasan ang mga pandaigdigang problema sa pangunahing site: magbigay ng geo-reservation. Sa madaling salita, lumikha ng mga backup na virtual machine sa isang site sa ibang lungsod. Ang mga espesyal na solusyon para sa DR ay angkop para dito: sa aming kumpanya ginagamit namin ang VMware vCloud Availability (vCAV). Sa tulong nito, maaari mong i-configure ang proteksyon sa pagitan ng ilang mga site ng cloud provider o i-restore sa cloud mula sa isang on-premise na site. Napag-usapan ko na nang mas detalyado ang tungkol sa pamamaraan para sa pagtatrabaho sa vCAV dito. 

   RPO at RTO: mula 5 minuto. 

   Gastos: mas mahal kaysa sa unang opsyon, ngunit mas mura kaysa sa pagtitiklop ng hardware sa isang ulap na hindi patunay ng kalamidad. Binubuo ang presyo ng halaga ng isang lisensya ng vCAV, mga bayarin sa pangangasiwa, ang halaga ng mga mapagkukunan ng ulap at mga mapagkukunan ng reserba ayon sa modelo ng PAYG (10% ng halaga ng mga mapagkukunan sa pagtatrabaho para sa mga naka-off na VM).

   Mula sa pagsasanay: Ang kliyente ay nagpapanatili ng 6 na virtual machine na may iba't ibang mga database sa aming cloud sa Moscow. Sa una, ang proteksyon ay ibinigay sa pamamagitan ng backup: ang ilan sa mga backup na kopya ay naka-imbak sa cloud sa Moscow, at ang ilan ay naka-imbak sa aming St. Petersburg site. Sa paglipas ng panahon, ang mga database ay lumaki sa laki, at ang pagpapanumbalik mula sa isang backup ay nagsimulang tumagal ng mas maraming oras. 
    
   Ang pagtitiklop batay sa VMware vCloud Availability ay idinagdag sa mga backup. Ang mga kopya ng mga virtual machine ay iniimbak sa isang backup na site sa St. Petersburg at ina-update bawat 5 minuto. Kung ang isang pagkabigo ay nangyari sa pangunahing site, ang mga empleyado ay malayang lumipat sa isang kopya ng virtual machine sa St. Petersburg at patuloy na nagtatrabaho dito. 

Ang lahat ng mga solusyon na isinasaalang-alang ay nagbibigay ng mataas na kakayahang magamit, ngunit hindi nagpoprotekta laban sa pagkawala ng data dahil sa isang ransomware virus o isang aksidenteng error ng empleyado. Sa kasong ito, kakailanganin namin ng mga backup na magbibigay ng kinakailangang RPO.

5. Huwag kalimutan ang tungkol sa backup

Alam ng lahat na kailangan mong gumawa ng mga backup, kahit na mayroon kang pinakaastig na solusyon sa disaster-proof. Kaya't ipapaalala ko lang sa iyo ang ilang mga punto.

Sa mahigpit na pagsasalita, ang backup ay hindi DR. At dahil jan: 

• Ito ay isang mahabang panahon. Kung ang data ay sinusukat sa terabytes, ang pagbawi ay tatagal ng higit sa isang oras. Kailangan mong ibalik, magtalaga ng network, tingnan kung naka-on ito, tingnan kung maayos ang data. Kaya maaari kang magbigay ng isang mahusay na RTO lamang kung mayroong maliit na data. 
• Maaaring hindi maibalik ang data sa unang pagkakataon, at kailangan mong maglaan ng oras para ulitin ang pagkilos. Halimbawa, may mga pagkakataon na hindi natin alam nang eksakto kung kailan nawala ang data. Sabihin nating ang pagkawala ay napansin sa 15.00, at ang mga kopya ay ginagawa bawat oras. Mula 15.00 tinitingnan namin ang lahat ng recovery point: 14:00, 13:00 at iba pa. Kung mahalaga ang system, sinusubukan naming bawasan ang edad ng recovery point. Ngunit kung ang sariwang backup ay hindi naglalaman ng kinakailangang data, gagawin namin ang susunod na punto - ito ay karagdagang oras. 

Sa kasong ito, maaaring ibigay ng backup na iskedyul ang kinakailangan RPO. Para sa mga backup, mahalagang magbigay ng geo-reservation sa kaso ng mga problema sa pangunahing site. Inirerekomenda na mag-imbak ng ilang backup na kopya nang hiwalay.

Ang panghuling disaster recovery plan ay dapat maglaman ng hindi bababa sa 2 tool:  

• Isa sa mga opsyon 1-4, na magpoprotekta sa mga system mula sa mga pagkabigo at pagkahulog.
• I-backup upang maprotektahan ang data mula sa pagkawala. 

Ito rin ay nagkakahalaga ng pag-aalaga ng isang backup na channel ng komunikasyon kung sakaling bumaba ang pangunahing tagapagbigay ng Internet. At - voila! — Nakahanda na ang DR sa minimum na sahod. 

Pinagmulan: www.habr.com