Edhe nëse është një përmbytje, 1C duhet të funksionojë! Ne pajtohemi me biznesin në DR

Imagjinoni: po i shërbeni infrastrukturës IT të një qendre të madhe tregtare. Fillon të bjerë shi në qytet. Rrjedhat e shiut depërtojnë në çati, uji mbush ambientet e shitjes me pakicë deri në kyçin e këmbës. Shpresojmë që dhoma juaj e serverit të mos jetë në bodrum, përndryshe problemet nuk mund të shmangen.  

Historia e përshkruar nuk është një fantazi, por një përshkrim kolektiv i disa ngjarjeve të vitit 2020. Në kompanitë e mëdha, një plan i rimëkëmbjes nga fatkeqësitë, ose plani i rimëkëmbjes nga fatkeqësitë (DRP), është gjithmonë në dispozicion për këtë rast. Në korporata, kjo është përgjegjësi e specialistëve të vazhdimësisë së biznesit. Por në kompanitë e mesme dhe të vogla, zgjidhja e problemeve të tilla bie mbi shërbimet e IT. Ju duhet të kuptoni vetë logjikën e biznesit, të kuptoni se çfarë mund të dështojë dhe ku, të krijoni mbrojtje dhe ta zbatoni atë. 

Është mirë nëse një specialist i IT mund të negociojë me biznesin dhe të diskutojë nevojën për mbrojtje. Por unë kam parë më shumë se një herë se si një kompani e ka kursyer një zgjidhje për rikuperimin e fatkeqësive (DR) sepse e konsideroi atë të tepërt. Kur ndodhi një aksident, një rikuperim i gjatë kërcënoi humbje dhe biznesi nuk ishte gati. Mund të përsërisni sa të doni: "Të thashë", por shërbimi i IT do të duhet të rivendosë shërbimet.

Nga pozicioni i një arkitekti, unë do t'ju tregoj se si ta shmangni këtë situatë. Në pjesën e parë të artikullit, unë do të tregoj punën përgatitore: si të diskutoni tre pyetje me klientin për zgjedhjen e mjeteve të sigurisë: 

• Çfarë po mbrojmë?
• Nga çfarë po mbrohemi?
• Sa mbrohemi? 

Në pjesën e dytë, ne do të flasim për opsionet për t'iu përgjigjur pyetjes: si të mbroheni. Unë do të jap shembuj të rasteve se si klientët e ndryshëm ndërtojnë mbrojtjen e tyre.

Çfarë mbrojmë: identifikimi i funksioneve kritike të biznesit 

Është më mirë të filloni përgatitjen duke diskutuar planin e veprimit pas urgjencës me klientin e biznesit. Vështirësia kryesore këtu është gjetja e një gjuhe të përbashkët. Klientit zakonisht nuk i intereson se si funksionon zgjidhja e IT. Atij i intereson nëse shërbimi mund të kryejë funksione biznesi dhe të sjellë para. Për shembull: nëse faqja po funksionon, por sistemi i pagesave është i dëmtuar, nuk ka të ardhura nga klientët dhe "ekstremistët" janë ende specialistë të IT. 

Një profesionist i IT-së mund të ketë vështirësi në negociata të tilla për disa arsye:

• Shërbimi IT nuk e kupton plotësisht rolin e sistemit të informacionit në biznes. Për shembull, nëse nuk ka përshkrim të disponueshëm të proceseve të biznesit ose një model biznesi transparent. 
• Jo i gjithë procesi varet nga shërbimi IT. Për shembull, kur një pjesë e punës kryhet nga kontraktorët, dhe specialistët e IT nuk kanë ndikim të drejtpërdrejtë mbi ta.

Unë do ta strukturoja bisedën kështu: 

1. Ne u shpjegojmë bizneseve se aksidentet u ndodhin të gjithëve dhe rikuperimi kërkon kohë. Gjëja më e mirë është të demonstroni situata, si ndodh kjo dhe çfarë pasojash janë të mundshme.
2. Ne tregojmë se jo gjithçka varet nga shërbimi IT, por ju jeni gati të ndihmoni me një plan veprimi në fushën tuaj të përgjegjësisë.
3. I kërkojmë klientit të biznesit të përgjigjet: nëse ndodh apokalipsi, cili proces duhet të rikthehet më parë? Kush merr pjesë në të dhe si? 

   Kërkohet një përgjigje e thjeshtë nga biznesi, për shembull: qendra e thirrjeve duhet të vazhdojë regjistrimin e aplikacioneve 24/7.

4. Kërkojmë nga një ose dy përdorues të sistemit që ta përshkruajnë këtë proces në detaje. 
   Është më mirë të përfshini një analist për të ndihmuar nëse kompania juaj ka një të tillë.

   Për të filluar, përshkrimi mund të duket si ky: qendra e thirrjeve merr kërkesa me telefon, me postë dhe përmes mesazheve nga faqja e internetit. Pastaj ai i fut ato në 1C përmes ndërfaqes në internet, dhe prodhimi i merr ato nga atje në këtë mënyrë.

5. Më pas shikojmë se cilat zgjidhje harduerike dhe softuerike mbështesin procesin. Për mbrojtje të plotë, ne marrim parasysh tre nivele: 
   • aplikacionet dhe sistemet brenda faqes (niveli i softuerit),   
   • vetë siti ku funksionojnë sistemet (niveli i infrastrukturës), 
   • rrjet (ata shpesh e harrojnë atë).

6. Zbulojmë pikat e mundshme të dështimit: nyjet e sistemit nga të cilat varet performanca e shërbimit. Ne shënojmë veçmas nyjet që mbështeten nga kompani të tjera: operatorët e telekomit, ofruesit e pritjes, qendrat e të dhënave, etj. Me këtë, ju mund të ktheheni te klienti i biznesit për hapin tjetër.

Nga çfarë mbrohemi: rreziqet

Më pas, ne zbulojmë nga klienti i biznesit nga cilat rreziqe mbrohemi fillimisht. Të gjitha rreziqet mund të ndahen në dy grupe: 

• humbja e kohës për shkak të ndërprerjes së shërbimit;
• humbja e të dhënave për shkak të ndikimeve fizike, faktorëve njerëzorë etj.

Bizneset kanë frikë nga humbja e të dhënave dhe kohës - e gjithë kjo çon në humbje të parave. Pra, përsëri bëjmë pyetje për secilin grup rreziku: 

• Për këtë proces, a mund të vlerësojmë se sa kushton humbja e të dhënave dhe humbja e kohës në para? 
• Çfarë të dhënash nuk mund të humbasim? 
• Ku nuk mund të lejojmë joproduktive? 
• Cilat ngjarje janë më të mundshme dhe më kërcënuese për ne?

Pas diskutimit, ne do të kuptojmë se si t'i japim përparësi pikave të dështimit. 

Sa mbrojmë: RPO dhe RTO 

Kur pikat kritike të dështimit janë të qarta, ne llogarisim treguesit RTO dhe RPO. 

Unë kujtoj se RTO (objektivi i kohës së rikuperimit) — kjo është koha e lejuar nga momenti i aksidentit deri në rikthimin e plotë të shërbimit. Në gjuhën e biznesit, kjo është e pranueshme joproduktive. Nëse e dimë se sa para ka sjellë procesi, mund të llogarisim humbjet nga çdo minutë pushimi dhe të llogarisim humbjen e pranueshme. 

RPO (objektivi i pikës së rikuperimit) — pikë e vlefshme e rikuperimit të të dhënave. Ai përcakton kohën gjatë së cilës ne mund të humbasim të dhënat. Nga pikëpamja e biznesit, humbja e të dhënave mund të rezultojë në gjoba, për shembull. Humbje të tilla mund të konvertohen edhe në para. 

Koha e rikuperimit duhet të llogaritet për përdoruesin përfundimtar: për sa kohë ai do të jetë në gjendje të hyjë në sistem. Pra, së pari shtojmë kohën e rikuperimit të të gjitha hallkave në zinxhir. Këtu bëhet shpesh një gabim: ata marrin RTO-në e ofruesit nga SLA dhe harrojnë kushtet e mbetura.

Le të shohim një shembull specifik. Përdoruesi regjistrohet në 1C, sistemi hapet me një gabim të bazës së të dhënave. Ai kontakton administratorin e sistemit. Baza e të dhënave ndodhet në cloud, administratori i sistemit raporton problemin te ofruesi i shërbimit. Le të themi se të gjitha komunikimet zgjasin 15 minuta. Në cloud, një bazë të dhënash e kësaj madhësie do të rikthehet nga një kopje rezervë brenda një ore, prandaj, RTO në anën e ofruesit të shërbimit është një orë. Por ky nuk është afati përfundimtar; për përdoruesin, i janë shtuar 15 minuta për të zbuluar problemin. 
 
Tjetra, administratori i sistemit duhet të kontrollojë nëse baza e të dhënave është e saktë, ta lidhë atë me 1C dhe të nisë shërbimet. Kjo kërkon një orë tjetër, që do të thotë se RTO nga ana e administratorit është tashmë 2 orë e 15 minuta. Përdoruesit i duhen edhe 15 minuta të tjera: identifikohu, kontrollo që janë shfaqur transaksionet e nevojshme. 2 orë 30 minuta është koha totale e rikuperimit të shërbimit në këtë shembull.

Këto llogaritje do t'i tregojnë biznesit nga faktorët e jashtëm varet periudha e rikuperimit. Për shembull, nëse zyra është e përmbytur, së pari duhet të gjeni rrjedhjen dhe ta rregulloni atë. Do të duhet kohë, e cila nuk varet nga TI.  

Si mbrohemi: zgjedhja e mjeteve për rreziqe të ndryshme

Pas diskutimit të të gjitha pikave, klienti tashmë e kupton koston e një aksidenti për biznesin. Tani mund të zgjidhni mjetet dhe të diskutoni buxhetin. Duke përdorur shembuj të rasteve të klientëve, unë do t'ju tregoj se çfarë mjetesh ofrojmë për detyra të ndryshme. 

Le të fillojmë me grupin e parë të rreziqeve: humbjet për shkak të ndërprerjes së shërbimit. Zgjidhjet për këtë problem duhet të ofrojnë RTO të mirë.

1. Prisni aplikacionin në cloud 

   Për të filluar, thjesht mund të kaloni në cloud - ofruesi tashmë ka menduar për çështjet e disponueshmërisë së lartë. Pritësit e virtualizimit mblidhen në një grup, energjia dhe rrjeti rezervohen, të dhënat ruhen në sistemet e ruajtjes tolerante ndaj gabimeve dhe ofruesi i shërbimit është financiarisht përgjegjës për kohën e ndërprerjes.

   Për shembull, mund të presë një makinë virtuale me një bazë të dhënash në cloud. Aplikacioni do të lidhet me bazën e të dhënave nga jashtë nëpërmjet një kanali të krijuar ose nga e njëjta re. Nëse lindin probleme me një nga serverët në grup, VM do të riniset në serverin fqinj në më pak se 2 minuta. Pas kësaj, DBMS do të fillojë në të dhe brenda pak minutash baza e të dhënave do të bëhet e disponueshme.

   OTR: matur në minuta. Këto kushte mund të specifikohen në marrëveshjen me ofruesin.
   Kosto: Ne llogarisim koston e burimeve cloud për aplikacionin tuaj. 
   Nga çfarë nuk do t'ju mbrojë: nga dështimet masive në vendin e ofruesit, për shembull, për shkak të aksidenteve në nivel qyteti.

2. Grumbulloni aplikacionin  

   Nëse dëshironi të përmirësoni RTO, mund të forconi opsionin e mëparshëm dhe të vendosni menjëherë një aplikacion të grupuar në cloud.

   Ju mund të implementoni një grup në modalitetin aktiv-pasiv ose aktiv-aktiv. Ne krijojmë disa VM bazuar në kërkesat e shitësit. Për besueshmëri më të madhe, ne i shpërndajmë ato nëpër serverë dhe sisteme të ndryshme ruajtjeje. Nëse serveri me një nga bazat e të dhënave dështon, nyja rezervë merr përsipër ngarkesën në pak sekonda.

   OTR: Matur në sekonda.
   Kosto: pak më e shtrenjtë se një re e zakonshme, do të kërkohen burime shtesë për grupim.
   Nga çfarë nuk do t'ju mbrojë: Ende nuk do të mbrojë kundër dështimeve masive në vend. Por ndërprerjet lokale nuk do të zgjasin aq gjatë.

   Nga praktika: Kompania e shitjes me pakicë kishte disa sisteme informacioni dhe faqe interneti. Të gjitha bazat e të dhënave ishin të vendosura lokalisht në zyrën e kompanisë. Asnjë DR nuk u mendua derisa zyra mbeti pa energji disa herë radhazi. Klientët ishin të pakënaqur me prishjet e faqes në internet. 
    
   Problemi me disponueshmërinë e shërbimit u zgjidh pasi kaloi në renë kompjuterike. Plus, ne arritëm të optimizonim ngarkesën në bazat e të dhënave duke balancuar trafikun midis nyjeve.

3. Lëvizni në një re rezistente ndaj fatkeqësive

   Nëse duhet të siguroheni që edhe një fatkeqësi natyrore në faqen kryesore të mos ndërhyjë në punën tuaj, mund të zgjidhni një re rezistente ndaj fatkeqësive. Në këtë opsion, ofruesi shpërndan grupin e virtualizimit në 2 qendra të dhënash. Replikimi i vazhdueshëm sinkron ndodh ndërmjet qendrave të të dhënave, një-për-një. Kanalet midis qendrave të të dhënave janë të rezervuara dhe shkojnë përgjatë rrugëve të ndryshme, kështu që një grup i tillë nuk ka frikë nga problemet e rrjetit. 

   OTR: priret në 0.
   Kosto: Opsioni më i shtrenjtë i cloud. 
   Nga çfarë nuk do t'ju mbrojë: Nuk do të ndihmojë kundër korrupsionit të të dhënave, si dhe nga faktori njerëzor, prandaj rekomandohet të bëni kopje rezervë në të njëjtën kohë. 

   Nga praktika: Një nga klientët tanë zhvilloi një plan gjithëpërfshirës të rimëkëmbjes nga fatkeqësitë. Kjo është strategjia që ai zgjodhi: 

   • Një re tolerante ndaj fatkeqësive mbron aplikacionin nga dështimet në nivelin e infrastrukturës. 
   • Rezervimi me dy nivele siguron mbrojtje në rast të gabimit njerëzor. Ekzistojnë dy lloje të kopjeve rezervë: "të ftohtë" dhe "të nxehtë". Një kopje rezervë "e ftohtë" është në gjendje të çaktivizuar dhe kërkon kohë për t'u vendosur. Një kopje rezervë "e nxehtë" është tashmë gati për përdorim dhe rikthehet më shpejt. Ai ruhet në një sistem ruajtjeje të dedikuar posaçërisht. Kopja e tretë regjistrohet në kasetë dhe ruhet në një dhomë tjetër. 

   Një herë në javë, klienti teston mbrojtjen dhe kontrollon funksionalitetin e të gjitha kopjeve rezervë, përfshirë ato nga shiriti. Çdo vit kompania teston të gjithë renë rezistente ndaj fatkeqësive. 

4. Organizoni përsëritjen në një faqe tjetër 

   Një tjetër mundësi se si të shmangni problemet globale në faqen kryesore: siguroni gjeo-rezervimin. Me fjalë të tjera, krijoni makina virtuale rezervë në një sit në një qytet tjetër. Zgjidhjet speciale për DR janë të përshtatshme për këtë: në kompaninë tonë ne përdorim VMware vCloud Availability (vCAV). Me ndihmën e tij, ju mund të konfiguroni mbrojtjen midis disa sajteve të ofruesve të resë kompjuterike ose të rivendosni në re nga një sajt në premisë. Unë kam folur tashmë në më shumë detaje për skemën e punës me vCAV këtu. 

   RPO dhe RTO: nga 5 minuta. 

   Kosto: më i shtrenjtë se opsioni i parë, por më i lirë se riprodhimi i harduerit në një re të mbrojtur nga fatkeqësitë. Çmimi përbëhet nga kostoja e licencës vCAV, tarifa e administrimit, kostoja e burimeve cloud dhe burimet rezervë sipas modelit PAYG (10% e kostos së burimeve të punës për VM-të e fikur).

   Nga praktika: Klienti mbante 6 makina virtuale me baza të dhënash të ndryshme në renë tonë në Moskë. Në fillim, mbrojtja u sigurua me kopje rezervë: disa nga kopjet rezervë u ruajtën në renë kompjuterike në Moskë dhe disa u ruajtën në faqen tonë të Shën Petersburgut. Me kalimin e kohës, bazat e të dhënave u rritën në madhësi dhe rivendosja nga një kopje rezervë filloi të marrë më shumë kohë. 
    
   Replikimi i bazuar në VMware vCloud Availability u shtua në kopje rezervë. Kopjet e makinave virtuale ruhen në një faqe rezervë në Shën Petersburg dhe përditësohen çdo 5 minuta. Nëse ndodh një dështim në sitin kryesor, punonjësit kalojnë në mënyrë të pavarur në një kopje të makinës virtuale në Shën Petersburg dhe vazhdojnë të punojnë me të. 

Të gjitha zgjidhjet e konsideruara ofrojnë disponueshmëri të lartë, por nuk mbrojnë nga humbja e të dhënave për shkak të një virusi ransomware ose një gabimi aksidental të punonjësve. Në këtë rast, do të na duhen kopje rezervë që do të ofrojnë RPO-në e kërkuar.

5. Mos harroni për kopjen rezervë

Të gjithë e dinë që ju duhet të bëni kopje rezervë, edhe nëse keni zgjidhjen më të mirë të mbrojtur nga fatkeqësitë. Kështu që unë do t'ju kujtoj shkurtimisht disa pika.

Në mënyrë të rreptë, rezervimi nuk është DR. Dhe kjo është arsyeja pse: 

• Është një kohë e gjatë. Nëse të dhënat maten në terabajt, rikuperimi do të zgjasë më shumë se një orë. Ju duhet të rivendosni, të caktoni një rrjet, të kontrolloni nëse ai ndizet, të shihni që të dhënat janë në rregull. Kështu që ju mund të siguroni një RTO të mirë vetëm nëse ka pak të dhëna. 
• Të dhënat mund të mos restaurohen herën e parë dhe duhet të lini kohë për një veprim të përsëritur. Për shembull, ka raste kur ne nuk e dimë saktësisht se kur kanë humbur të dhënat. Le të themi se humbja është vënë re në orën 15.00, dhe kopjet bëhen çdo orë. Nga ora 15.00 shikojmë të gjitha pikat e rikuperimit: 14:00, 13:00 e kështu me radhë. Nëse sistemi është i rëndësishëm, ne përpiqemi të minimizojmë moshën e pikës së rikuperimit. Por nëse rezervimi i freskët nuk përmban të dhënat e nevojshme, marrim pikën tjetër - kjo është kohë shtesë. 

Në këtë rast, plani rezervë mund të sigurojë atë që kërkohet RPO. Për kopje rezervë, është e rëndësishme të sigurohet gjeo-rezervimi në rast të problemeve me faqen kryesore. Rekomandohet që disa kopje rezervë të ruhen veçmas.

Plani përfundimtar i rimëkëmbjes nga fatkeqësitë duhet të përmbajë të paktën 2 mjete:  

• Një nga opsionet 1-4, i cili do të mbrojë sistemet nga dështimet dhe rëniet.
• Rezervimi për të mbrojtur të dhënat nga humbja. 

Vlen gjithashtu të kujdeseni për një kanal komunikimi rezervë në rast se ofruesi kryesor i Internetit prishet. Dhe - voila! — DR me paga minimale është tashmë gati. 

Burimi: www.habr.com