Hata kama ni mafuriko, 1C inapaswa kufanya kazi! Tunakubaliana na biashara kuhusu DR

Fikiria: unahudumia miundombinu ya IT ya kituo kikubwa cha ununuzi. Mvua huanza kunyesha mjini. Mito ya mvua huvunja paa, maji hujaza majengo ya rejareja hadi kwenye kifundo cha mguu. Tunatumai kuwa chumba chako cha seva hakiko kwenye ghorofa ya chini, vinginevyo matatizo hayawezi kuepukika.  

Hadithi iliyoelezewa sio ndoto, lakini maelezo ya pamoja ya matukio kadhaa ya 2020. Katika makampuni makubwa, mpango wa kurejesha maafa, au mpango wa kurejesha maafa (DRP), huwa karibu kwa kesi hii. Katika mashirika, hili ni jukumu la wataalam wa mwendelezo wa biashara. Lakini katika makampuni ya kati na ndogo, kutatua matatizo hayo huanguka kwenye huduma za IT. Unahitaji kuelewa mantiki ya biashara mwenyewe, kuelewa nini kinaweza kushindwa na wapi, kuja na ulinzi na kutekeleza. 

Ni vyema ikiwa mtaalamu wa TEHAMA anaweza kujadiliana na biashara na kujadili hitaji la ulinzi. Lakini nimeona zaidi ya mara moja jinsi kampuni ilivyoruka suluhisho la uokoaji wa maafa (DR) kwa sababu iliona kuwa haina maana. Wakati ajali ilitokea, ahueni ya muda mrefu ilitishia hasara, na biashara haikuwa tayari. Unaweza kurudia vile unavyopenda: "Nilikuambia hivyo," lakini huduma ya IT bado itabidi kurejesha huduma.

Kutoka kwa nafasi ya mbunifu, nitakuambia jinsi ya kuepuka hali hii. Katika sehemu ya kwanza ya kifungu hicho, nitaonyesha kazi ya maandalizi: jinsi ya kujadili maswali matatu na mteja kwa kuchagua zana za usalama: 

• Tunalinda nini?
• Tunalinda kutokana na nini?
• Je, tunalinda kiasi gani? 

Katika sehemu ya pili, tutazungumza juu ya chaguzi za kujibu swali: jinsi ya kujitetea. Nitatoa mifano ya kesi za jinsi wateja tofauti hujenga ulinzi wao.

Tunacholinda: kutambua kazi muhimu za biashara 

Ni vyema kuanza kujiandaa kwa kujadili mpango wa utekelezaji wa baada ya dharura na mteja wa biashara. Ugumu kuu hapa ni kupata lugha ya kawaida. Kwa kawaida mteja hajali jinsi ufumbuzi wa IT unavyofanya kazi. Anajali ikiwa huduma inaweza kufanya kazi za biashara na kuleta pesa. Kwa mfano: ikiwa tovuti inafanya kazi, lakini mfumo wa malipo umepungua, hakuna mapato kutoka kwa wateja, na "wenye msimamo mkali" bado ni wataalamu wa IT. 

Mtaalamu wa IT anaweza kuwa na ugumu katika mazungumzo kama haya kwa sababu kadhaa:

• Huduma ya IT haielewi kikamilifu jukumu la mfumo wa habari katika biashara. Kwa mfano, ikiwa hakuna maelezo yanayopatikana ya michakato ya biashara au mtindo wa biashara ulio wazi. 
• Sio mchakato mzima unategemea huduma ya IT. Kwa mfano, wakati sehemu ya kazi inafanywa na makandarasi, na wataalamu wa IT hawana ushawishi wa moja kwa moja juu yao.

Ningeunda mazungumzo kama hii: 

1. Tunawafafanulia wafanyabiashara kwamba ajali hutokea kwa kila mtu, na kupona huchukua muda. Jambo bora ni kuonyesha hali, jinsi hii inatokea na ni matokeo gani yanawezekana.
2. Tunaonyesha kuwa sio kila kitu kinategemea huduma ya IT, lakini uko tayari kusaidia na mpango wa utekelezaji katika eneo lako la uwajibikaji.
3. Tunauliza mteja wa biashara kujibu: ikiwa apocalypse itatokea, ni mchakato gani unapaswa kurejeshwa kwanza? Nani anashiriki katika hilo na jinsi gani? 

   Jibu rahisi linahitajika kutoka kwa biashara, kwa mfano: kituo cha simu kinahitaji kuendelea kusajili programu 24/7.

4. Tunaomba mtumiaji mmoja au wawili wa mfumo kuelezea mchakato huu kwa undani. 
   Ni bora kuhusisha mchambuzi kukusaidia ikiwa kampuni yako ina moja.

   Kuanza, maelezo yanaweza kuonekana kama hii: kituo cha simu hupokea maombi kwa simu, kwa barua na kupitia ujumbe kutoka kwa tovuti. Kisha huwaingiza kwenye 1C kupitia kiolesura cha wavuti, na uzalishaji huwachukua kutoka hapo kwa njia hii.

5. Kisha tunaangalia ni suluhisho gani za vifaa na programu zinazounga mkono mchakato. Kwa ulinzi wa kina, tunazingatia viwango vitatu: 
   • maombi na mifumo ndani ya tovuti (kiwango cha programu),   
   • tovuti yenyewe ambapo mifumo inaendesha (kiwango cha miundombinu), 
   • mtandao (mara nyingi husahau kuhusu hilo).

6. Tunapata pointi zinazowezekana za kushindwa: nodes za mfumo ambazo utendaji wa huduma hutegemea. Tunatambua nodi tofauti ambazo zinaungwa mkono na makampuni mengine: waendeshaji wa mawasiliano ya simu, watoa huduma wa kukaribisha, vituo vya data, na kadhalika. Kwa hili, unaweza kurudi kwa mteja wa biashara kwa hatua inayofuata.

Tunachokinga: hatari

Kisha, tutajua kutoka kwa mteja wa biashara ni hatari gani tunazojilinda dhidi ya kwanza. Hatari zote zinaweza kugawanywa katika vikundi viwili: 

• kupoteza muda kwa sababu ya kupungua kwa huduma;
• kupoteza data kutokana na athari za kimwili, sababu za kibinadamu, nk.

Biashara zinaogopa kupoteza data na wakati - yote haya husababisha upotezaji wa pesa. Kwa hivyo tena tunauliza maswali kwa kila kikundi cha hatari: 

• Kwa mchakato huu, je, tunaweza kukadiria ni kiasi gani cha hasara ya data na gharama ya kupoteza wakati katika pesa? 
• Ni data gani hatuwezi kupoteza? 
• Ni wapi hatuwezi kuruhusu wakati wa kupumzika? 
• Ni matukio gani yana uwezekano mkubwa na yanatisha zaidi kwetu?

Baada ya majadiliano, tutaelewa jinsi ya kuweka kipaumbele pointi za kushindwa. 

Kiasi gani tunacholinda: RPO na RTO 

Wakati pointi muhimu za kushindwa ziko wazi, tunahesabu viashiria vya RTO na RPO. 

Acha nikukumbushe kuwa RTO (lengo la wakati wa kurejesha) - huu ni wakati unaoruhusiwa kutoka wakati wa ajali hadi huduma itakaporejeshwa kikamilifu. Katika lugha ya biashara, muda huu unakubalika. Ikiwa tunajua ni kiasi gani cha pesa ambacho mchakato ulileta, tunaweza kuhesabu hasara kutoka kwa kila dakika ya muda wa kupumzika na kuhesabu hasara inayokubalika. 

RPO (lengo la hatua ya uokoaji) - hatua halali ya kurejesha data. Huamua muda ambao tunaweza kupoteza data. Kwa mtazamo wa biashara, kupoteza data kunaweza kusababisha faini, kwa mfano. Hasara kama hizo pia zinaweza kubadilishwa kuwa pesa. 

Wakati wa kurejesha unahitaji kuhesabiwa kwa mtumiaji wa mwisho: muda gani ataweza kuingia kwenye mfumo. Kwa hivyo kwanza tunaongeza muda wa urejeshaji wa viungo vyote kwenye mnyororo. Hitilafu mara nyingi hufanywa hapa: wanachukua RTO ya mtoa huduma kutoka kwa SLA, na kusahau kuhusu masharti yaliyobaki.

Hebu tuangalie mfano maalum. Mtumiaji huingia kwenye 1C, mfumo unafungua na hitilafu ya hifadhidata. Anawasiliana na msimamizi wa mfumo. Hifadhidata iko kwenye wingu, msimamizi wa mfumo anaripoti shida kwa mtoa huduma. Wacha tuseme mawasiliano yote huchukua dakika 15. Katika wingu, hifadhidata ya ukubwa huu itarejeshwa kutoka kwa nakala rudufu kwa saa, kwa hivyo, RTO kwenye upande wa mtoa huduma ni saa moja. Lakini hii sio tarehe ya mwisho ya mwisho; kwa mtumiaji, dakika 15 zimeongezwa kwake ili kugundua shida. 
 
Ifuatayo, msimamizi wa mfumo anahitaji kuangalia kuwa hifadhidata ni sahihi, iunganishe na 1C na uanze huduma. Hii inahitaji saa nyingine, ambayo ina maana kwamba RTO kwa upande wa msimamizi tayari ni saa 2 na dakika 15. Mtumiaji anahitaji dakika nyingine 15: ingia, angalia kwamba shughuli muhimu zimeonekana. Saa 2 dakika 30 ni jumla ya muda wa kurejesha huduma katika mfano huu.

Mahesabu haya yataonyesha biashara juu ya mambo gani ya nje kipindi cha kurejesha kinategemea. Kwa mfano, ikiwa ofisi imejaa mafuriko, kwanza unahitaji kupata uvujaji na kurekebisha. Itachukua muda, ambayo haitegemei IT.  

Jinsi tunavyolinda: kuchagua zana za hatari tofauti

Baada ya kujadili pointi zote, mteja tayari anaelewa gharama ya ajali kwa biashara. Sasa unaweza kuchagua zana na kujadili bajeti. Kwa kutumia mifano ya kesi za mteja, nitakuonyesha ni zana gani tunazotoa kwa kazi tofauti. 

Wacha tuanze na kundi la kwanza la hatari: hasara kwa sababu ya wakati wa huduma. Suluhisho za shida hii zinapaswa kutoa RTO nzuri.

1. Pangisha programu katika wingu 

   Kuanza, unaweza tu kuhamia wingu - mtoa huduma tayari amefikiria kupitia masuala ya upatikanaji wa juu. Wapangishi wa uwekaji mtandaoni hukusanywa katika kundi, nguvu na mtandao zimehifadhiwa, data huhifadhiwa kwenye mifumo ya hifadhi inayostahimili hitilafu, na mtoa huduma anawajibika kifedha kwa muda usiofaa.

   Kwa mfano, unaweza kukaribisha mashine ya kawaida iliyo na hifadhidata kwenye wingu. Programu itaunganishwa kwa hifadhidata nje kupitia chaneli iliyoanzishwa au kutoka kwa wingu sawa. Matatizo yakitokea na mojawapo ya seva kwenye nguzo, VM itaanza upya kwenye seva ya jirani kwa chini ya dakika 2. Baada ya hayo, DBMS itaanza ndani yake, na katika dakika chache hifadhidata itapatikana.

   RTO: kipimo kwa dakika. Masharti haya yanaweza kubainishwa katika makubaliano na mtoa huduma.
   Gharama: Tunakokotoa gharama ya rasilimali za wingu kwa programu yako. 
   Kile ambacho hakitakulinda nacho: kutokana na kushindwa kwa kiasi kikubwa kwenye tovuti ya mtoa huduma, kwa mfano, kutokana na ajali katika ngazi ya jiji.

2. Unganisha programu  

   Ikiwa unataka kuboresha RTO, unaweza kuimarisha chaguo la awali na mara moja uweke programu iliyounganishwa kwenye wingu.

   Unaweza kutekeleza kundi katika modi amilifu-ya-tusi au amilifu-amilifu. Tunaunda VM kadhaa kulingana na mahitaji ya muuzaji. Kwa kutegemewa zaidi, tunazisambaza kwenye seva tofauti na mifumo ya hifadhi. Ikiwa seva iliyo na moja ya hifadhidata itashindwa, nodi ya chelezo inachukua mzigo katika sekunde chache.

   RTO: Hupimwa kwa sekunde.
   Gharama: ghali kidogo kuliko wingu la kawaida, rasilimali za ziada zitahitajika kwa kuunganisha.
   Kile ambacho hakitakulinda nacho: Bado haitalinda dhidi ya hitilafu kubwa kwenye tovuti. Lakini usumbufu wa ndani hautadumu kwa muda mrefu.

   Kutoka kwa mazoezi: Kampuni ya rejareja ilikuwa na mifumo na tovuti kadhaa za habari. Hifadhidata zote zilipatikana ndani ya ofisi ya kampuni. Hakuna DR aliyefikiriwa hadi ofisi ilipoachwa bila nguvu mara kadhaa mfululizo. Wateja hawakufurahishwa na hitilafu za tovuti. 
    
   Tatizo la upatikanaji wa huduma lilitatuliwa baada ya kuhamia kwenye wingu. Zaidi, tuliweza kuongeza mzigo kwenye hifadhidata kwa kusawazisha trafiki kati ya nodi.

3. Sogeza hadi kwenye wingu la kuzuia maafa

   Iwapo unahitaji kuhakikisha kuwa hata janga la asili kwenye tovuti kuu haliingiliani na kazi yako, unaweza kuchagua wingu linalostahimili majanga. Katika chaguo hili, mtoa huduma anaeneza kundi la utangazaji kwenye vituo 2 vya data. Urudiaji wa mara kwa mara wa kisawazishaji hutokea kati ya vituo vya data, moja hadi moja. Njia kati ya vituo vya data zimehifadhiwa na huenda kwenye njia tofauti, kwa hivyo nguzo hiyo haogopi matatizo ya mtandao. 

   RTO: inaelekea 0.
   Gharama: Chaguo la gharama kubwa zaidi la wingu. 
   Kile ambacho hakitakulinda nacho: Haitasaidia dhidi ya uharibifu wa data, na pia kutoka kwa sababu ya kibinadamu, kwa hiyo inashauriwa kufanya salama kwa wakati mmoja. 

   Kutoka kwa mazoezi: Mmoja wa wateja wetu alitengeneza mpango mpana wa kurejesha maafa. Huu ndio mkakati aliouchagua: 

   • Wingu linalostahimili majanga hulinda programu kutokana na kushindwa katika kiwango cha miundombinu. 
   • Chelezo ya ngazi mbili hutoa ulinzi katika kesi ya makosa ya kibinadamu. Kuna aina mbili za chelezo: "baridi" na "moto". Hifadhi rudufu "baridi" iko katika hali ya kuzimwa na inachukua muda kusambaza. Nakala ya "moto" tayari iko tayari kutumika na inarejeshwa haraka. Imehifadhiwa kwenye mfumo maalum wa uhifadhi. Nakala ya tatu imeandikwa kwenye mkanda na kuhifadhiwa kwenye chumba kingine. 

   Mara moja kwa wiki, mteja hujaribu ulinzi na huangalia utendakazi wa chelezo zote, pamoja na zile za mkanda. Kila mwaka kampuni hujaribu wingu lote linalostahimili majanga. 

4. Panga urudufishaji kwa tovuti nyingine 

   Chaguo jingine la jinsi ya kuepuka matatizo ya kimataifa kwenye tovuti kuu: kutoa geo-reservation. Kwa maneno mengine, unda chelezo mashine pepe katika tovuti katika mji mwingine. Suluhisho maalum kwa DR zinafaa kwa hili: katika kampuni yetu tunatumia VMware vCloud Availability (vCAV). Kwa usaidizi wake, unaweza kusanidi ulinzi kati ya tovuti kadhaa za watoa huduma za wingu au kurejesha kwenye wingu kutoka kwa tovuti ya juu. Tayari nimezungumza kwa undani zaidi juu ya mpango wa kufanya kazi na vCAV hapa. 

   RPO na RTO: kutoka dakika 5. 

   Gharama: ghali zaidi kuliko chaguo la kwanza, lakini ni nafuu zaidi kuliko urudufishaji wa maunzi katika wingu la kuzuia maafa. Bei hiyo inajumuisha gharama ya leseni ya vCAV, ada za usimamizi, gharama ya rasilimali za wingu na rasilimali za akiba kulingana na muundo wa PAYG (10% ya gharama ya rasilimali za kufanya kazi kwa VM zilizozimwa).

   Kutoka kwa mazoezi: Mteja aliweka mashine 6 pepe zilizo na hifadhidata tofauti kwenye wingu letu huko Moscow. Mara ya kwanza, ulinzi ulitolewa na chelezo: baadhi ya nakala za chelezo zilihifadhiwa kwenye wingu huko Moscow, na zingine zilihifadhiwa kwenye tovuti yetu ya St. Baada ya muda, hifadhidata zilikua kwa ukubwa, na kurejesha kutoka kwa nakala rudufu ilianza kuchukua muda zaidi. 
    
   Urudiaji kulingana na Upatikanaji wa VMware vCloud uliongezwa kwenye chelezo. Nakala za mashine pepe huhifadhiwa kwenye tovuti ya chelezo huko St. Petersburg na husasishwa kila baada ya dakika 5. Ikiwa kushindwa hutokea kwenye tovuti kuu, wafanyakazi hubadilika kwa kujitegemea kwenye replica ya mashine ya virtual huko St. Petersburg na kuendelea kufanya kazi nayo. 

Suluhu zote zinazozingatiwa hutoa upatikanaji wa juu, lakini hazilinde dhidi ya upotezaji wa data kutokana na virusi vya ukombozi au hitilafu ya mfanyakazi. Katika kesi hii, tutahitaji chelezo ambazo zitatoa RPO inayohitajika.

5. Usisahau kuhusu chelezo

Kila mtu anajua kwamba unahitaji kufanya nakala rudufu, hata kama una suluhisho bora zaidi la kuzuia maafa. Kwa hiyo nitakukumbusha kwa ufupi tu mambo machache.

Kwa kusema kweli, chelezo sio DR. Na ndio maana: 

• Ni muda mrefu. Ikiwa data itapimwa kwa terabaiti, urejeshaji utachukua zaidi ya saa moja. Unahitaji kurejesha, toa mtandao, angalia kuwa inawasha, angalia kuwa data iko katika mpangilio. Kwa hivyo unaweza kutoa RTO nzuri tu ikiwa kuna data kidogo. 
• Data inaweza isirejeshwe mara ya kwanza, na unahitaji kuruhusu muda wa kurudia kitendo. Kwa mfano, kuna nyakati ambapo hatujui ni lini hasa data ilipotea. Wacha tuseme hasara iligunduliwa saa 15.00, na nakala zinafanywa kila saa. Kutoka 15.00 tunaangalia pointi zote za kurejesha: 14:00, 13:00 na kadhalika. Ikiwa mfumo ni muhimu, tunajaribu kupunguza umri wa hatua ya kurejesha. Lakini ikiwa nakala mpya haikuwa na data muhimu, tunachukua hatua inayofuata - hii ni wakati wa ziada. 

Katika kesi hii, ratiba ya chelezo inaweza kutoa kinachohitajika RPO. Kwa nakala rudufu, ni muhimu kutoa uhifadhi wa kijiografia ikiwa kuna shida na tovuti kuu. Inapendekezwa kuhifadhi nakala za chelezo kando.

Mpango wa mwisho wa uokoaji wa maafa unapaswa kuwa na angalau zana 2:  

• Moja ya chaguzi 1-4, ambayo italinda mifumo kutokana na kushindwa na kuanguka.
• Hifadhi nakala ili kulinda data dhidi ya upotevu. 

Inafaa pia kutunza kituo chelezo cha mawasiliano iwapo mtoa huduma mkuu wa Intaneti atashuka. Na - voila! - DR kwa kima cha chini cha mshahara tayari iko tayari. 

Chanzo: mapenzi.com