Imajinatu: merkataritza-zentro handi baten IT azpiegitura zerbitzatzen ari zara. Euria hasten da hirian. Euri-korronteek teilatua zeharkatzen dute, urak orkatilaraino betetzen ditu txikizkako lokalak. Zure zerbitzari gela sotoan ez egotea espero dugu, bestela arazoak ezin dira saihestu.
Deskribatutako istorioa ez da fantasia bat, 2020ko gertaera pare baten deskribapen kolektiboa baizik. Enpresa handietan, hondamendiak berreskuratzeko plan bat edo hondamendia berreskuratzeko plan bat (DRP) beti dago eskuragarri kasu honetarako. Korporazioetan, negozioaren jarraipeneko espezialisten ardura da. Baina enpresa ertain eta txikietan, horrelako arazoak konpontzea IT zerbitzuen esku dago. Zeuk ulertu behar duzu negozio-logika, ulertu zerk huts egin dezakeen eta non, babestu eta inplementatu.
Oso ona da IT espezialista batek negozioarekin negoziatu eta babesaren beharraz eztabaidatzea. Baina behin baino gehiagotan ikusi dut enpresa batek hondamendiak berreskuratzeko (DR) irtenbide bat nola gutxitu zuen erredundantetzat jotzen zuelako. Istripu bat gertatu zenean, errekuperazio luze batek galerak mehatxatu zituen, eta negozioa ez zegoen prest. Nahi adina errepika dezakezu: Β«Esan dizutΒ», baina IT zerbitzuak oraindik zerbitzuak berreskuratu beharko ditu.
Arkitektoaren jarreratik, egoera hori nola saihestu esango dizut. Artikuluaren lehen zatian, prestaketa lana erakutsiko dut: nola eztabaidatu bezeroarekin segurtasun tresnak aukeratzeko hiru galdera:
- Zer babesten dugu?
- Zertatik babesten dugu?
- Zenbat babesten dugu?
Bigarren zatian, galderari erantzuteko aukerei buruz hitz egingo dugu: nola defendatu. Bezero ezberdinek beren babesa eraikitzen duten kasuen adibideak emango ditut.
Babesten duguna: negozio-funtzio kritikoak identifikatzea
Hobe da prestatzen hastea larrialdiaren ondorengo ekintza-plana negozio-bezeroarekin eztabaidatuz. Hemen zailtasun nagusia hizkuntza komun bat aurkitzea da. Bezeroari normalean ez zaio axola IT irtenbideak nola funtzionatzen duen. Zerbitzuak negozio-funtzioak bete ditzakeen eta dirua ekar dezakeen axola dio. Esate baterako: gunea funtzionatzen ari bada, baina ordainketa-sistema behera badago, ez dago bezeroen diru-sarrerarik, eta "muturrekoak" informatika espezialistak dira oraindik.
IT profesional batek zailtasunak izan ditzake negoziazio horietan hainbat arrazoirengatik:
- Informatika zerbitzuak ez du guztiz ulertzen informazio sistemak negozioetan duen eginkizuna. Adibidez, negozio-prozesuen deskribapenik edo negozio-eredu gardenik ez badago.
- Prozesu osoa ez dago IT zerbitzuaren araberakoa. Esaterako, lanaren zati bat kontratistak egiten dutenean, eta informatikako espezialistek ez dutenean eragin zuzenik.
Honela egituratuko nuke elkarrizketa:
- Enpresei azaltzen diegu istripuak denei gertatzen zaizkiela, eta berreskuratzeak denbora behar duela. Onena egoerak erakustea da, nola gertatzen den eta zer ondorio izan daitezkeen.
- Erakusten dugu dena ez dela IT zerbitzuaren araberakoa, baina prest zaude zure ardura-eremuko ekintza-plan batekin laguntzeko.
- Enpresa bezeroari erantzuteko eskatzen diogu: apokalipsia gertatzen bada, zein prozesu berreskuratu behar da lehenik? Nork parte hartzen du eta nola?
Erantzun sinple bat eskatzen zaio negozioaren aldetik, adibidez: dei zentroak 24/7 aplikazioak erregistratzen jarraitu behar du.
- Sistemaren erabiltzaile bati edo biri prozesu hau zehatz-mehatz deskribatzeko eskatzen diogu.
Hobe da analista bat inplikatzea zure enpresak badauka laguntzeko.Hasteko, deskribapena honelakoa izan daiteke: dei zentroak telefonoz, postaz eta webguneko mezuen bidez jasotzen ditu eskaerak. Ondoren, 1C-n sartzen ditu web interfazearen bidez, eta ekoizpenak hortik eramaten ditu modu honetan.
- Ondoren, zer hardware- eta software-soluziok onartzen duten prozesua aztertuko dugu. Babes integrala lortzeko, hiru maila hartzen ditugu kontuan:
- guneko aplikazioak eta sistemak (software maila),
- sistemak exekutatzen diren gunea bera (azpiegitura maila),
- sarea (askotan ahazten dira).
- Huts-puntu posibleak aurkitzen ditugu: zerbitzuaren errendimendua menpe dagoen sistema-nodoak. Beste enpresek onartzen dituzten nodoak bereizten ditugu: telekomunikazio-operadoreak, ostalaritza-hornitzaileak, datu-zentroak, etab. Honen bidez, negozioaren bezeroarengana itzuli zaitezke hurrengo urratsera.
Zertaz babesten dugun: arriskuak
Ondoren, negozio-bezeroarengandik jakingo dugu zein arriskutatik babesten dugun lehenik. Arrisku guztiak bi taldetan bana daitezke:
- denbora galtzea zerbitzuaren geldialdiagatik;
- inpaktu fisikoak, giza faktoreak eta abarrengatik datuak galtzea.
Enpresek datuak eta denbora galtzearen beldur dira; horrek guztiak dirua galtzea dakar. Beraz, berriro galderak egiten ditugu arrisku talde bakoitzari:
- Prozesu honetarako, kalkulatu al dezakegu zenbat balio duten datu-galerak eta denbora-galerak dirutan?
- Zein datu ezin ditugu galdu?
- Non ezin dugu utzi geldialdia?
- Zein gertakari dira guretzat litekeena eta mehatxagarriena?
Eztabaidatu ondoren, hutsegite puntuak nola lehenetsi ulertuko dugu.
Zenbat babesten dugun: RPO eta RTO
Porrotaren puntu kritikoak argi daudenean, RTO eta RPO adierazleak kalkulatzen ditugu.
Gogora dezadala hori RTO (berreskuratze denboraren helburua) β istripuaren unetik zerbitzua guztiz leheneratzen den arte baimendutako denbora da. Negozio-hizkuntzan, geldialdi onargarria da. Prozesuak zenbat diru ekarri duen badakigu, geldialdi minutu bakoitzeko galerak kalkula ditzakegu eta galera onargarria kalkula dezakegu.
RPO (berreskuratze puntuaren helburua) β Baliozko datuak berreskuratzeko puntua. Datuak gal ditzakegun denbora zehazten du. Negozioaren ikuspuntutik, datuak galtzeak isunak eragin ditzake, adibidez. Horrelako galerak ere diru bihur daitezke.
Berreskuratzeko denbora kalkulatu behar da azken erabiltzailearentzat: zenbat denbora izango du sisteman saioa hasi. Beraz, lehenik eta behin kateko esteka guztien berreskuratze-denbora batzen dugu. Akats bat egin ohi da hemen: hornitzailearen RTO hartzen dute SLAtik, eta gainerako baldintzak ahaztu egiten dituzte.
Ikus dezagun adibide zehatz bat. Erabiltzailea 1C-n sartzen da, sistema datu-basearen errore batekin irekitzen da. Sistemaren administratzailearekin harremanetan jartzen da. Datu-basea hodeian dago, sistema-administratzaileak arazoaren berri ematen dio zerbitzu-hornitzaileari. Demagun komunikazio guztiek 15 minutu behar dituztela. Hodeian, tamaina horretako datu-base bat babeskopia batetik berrezarriko da ordubetean, beraz, zerbitzu hornitzailearen aldean RTO ordubetekoa da. Baina hau ez da azkeneko epea; erabiltzaileari 15 minutu gehitu zaizkio arazoa detektatzeko.
Ondoren, sistema-administratzaileak datu-basea zuzena dela egiaztatu behar du, 1C-ra konektatu eta zerbitzuak martxan jarri. Honek beste ordu bat behar du, hau da, administratzailearen aldetik RTO dagoeneko 2 ordu eta 15 minutukoa da. Erabiltzaileak beste 15 minutu behar ditu: hasi saioa, egiaztatu beharrezko transakzioak agertu direla. 2 ordu 30 minutu da zerbitzuaren berreskurapen-denbora osoa adibide honetan.
Kalkulu hauek negozioa suspertzeko epea zein kanpoko faktoreren araberakoa den erakutsiko dute. Adibidez, bulegoa gainezka badago, lehenik ihesa aurkitu eta konpondu behar duzu. Denbora beharko da, eta horrek ez du ITaren araberakoa.
Nola babesten dugun: arrisku desberdinetarako tresnak hautatzea
Puntu guztiak eztabaidatu ondoren, bezeroak dagoeneko ulertzen du negozioarentzat istripu baten kostua. Orain tresnak aukeratu eta aurrekontua eztabaidatu dezakezu. Bezeroen kasuen adibideak erabiliz, zeregin ezberdinetarako zer tresna eskaintzen ditugun erakutsiko dizut.
Has gaitezen lehen arrisku multzotik: zerbitzua gelditzeagatiko galerak. Arazo honen irtenbideek RTO ona eman beharko lukete.
- Ostatu aplikazioa hodeian
Hasteko, hodeira mugi zaitezke; hornitzaileak dagoeneko pentsatu ditu erabilgarritasun handiko arazoak. Birtualizazio-ostalariak kluster batean biltzen dira, energia eta sarea erreserbatuta daude, datuak akatsak jasan ditzaketen biltegiratze-sistemetan gordetzen dira eta zerbitzu-hornitzaileak finantza-erantzule dira geldialdi-denboraz.
Adibidez, hodeian datu-base bat duen makina birtual bat ostatu dezakezu. Aplikazioa kanpotik konektatuko da datu-basera ezarritako kanal baten bidez edo hodei beretik. Arazoak sortzen badira klusterreko zerbitzarietako batekin, VM-a aldameneko zerbitzarian berrabiaraziko da 2 minutu baino gutxiagoan. Horren ostean, DBMS-a abiaraziko da bertan, eta minutu gutxiren buruan datu-basea eskuragarri egongo da.
OTR: minututan neurtuta. Baldintza hauek hornitzailearekin egindako hitzarmenean zehaztu daitezke.
Kostua: zure aplikaziorako hodeiko baliabideen kostua kalkulatzen dugu.
Zertaz babestuko ez zaituena: hornitzailearen gunean izandako hutsegite handietatik, adibidez, hiri mailan izandako istripuengatik. - Aplikazioa multzokatu
RTO hobetu nahi baduzu, aurreko aukera indartu dezakezu eta berehala hodeian klusteratutako aplikazio bat jar dezakezu.
Kluster bat modu aktibo-pasibo edo aktibo-aktibo inplementatu dezakezu. Hainbat VM sortzen ditugu saltzailearen eskakizunetan oinarrituta. Fidagarritasun handiagoa lortzeko, zerbitzari eta biltegiratze sistema ezberdinetan banatzen ditugu. Datu-baseetako bat duen zerbitzariak huts egiten badu, babeskopia-nodoak hartzen du karga segundo gutxitan.
OTR: segundotan neurtuta.
Kostua: hodei arrunt bat baino apur bat garestiagoa, baliabide gehigarriak beharko dira clustering egiteko.
Zertaz babestuko ez zaituena: Oraindik ez du babestuko guneko akats handietatik. Baina tokiko etenek ez dute hainbeste iraungo.Praktiketatik: Txikizkako enpresak hainbat informazio sistema eta webgune zituen. Datu-base guztiak lokalean kokatuta zeuden enpresaren bulegoan. DR ez zen pentsatu bulegoa hainbat aldiz jarraian botererik gabe geratu zen arte. Bezeroak ez zeuden gustura webguneen hutsegiteekin.
Zerbitzuaren erabilgarritasunaren arazoa hodeira eraman ondoren konpondu zen. Gainera, datu-baseen karga optimizatzea lortu dugu nodoen arteko trafikoa orekatuz. - Mugitu hondamendien aurkako hodei batera
Webgune nagusiko hondamendi natural batek ere zure lana oztopatzen ez duela ziurtatu behar baduzu, hondamendiei aurre egiteko hodei bat hauta dezakezu.Aukera honetan, hornitzaileak birtualizazio-klusterra 2 datu-zentrotan zabaltzen du. Etengabeko erreplikazio sinkronoa gertatzen da datu-zentroen artean, banan-banan. Datu-zentroen arteko kanalak erreserbatuta daude eta ibilbide ezberdinetatik doaz, beraz, kluster batek ez du sareko arazoen beldurrik.
OTR: 0rako joera du.
Kostua: Hodeiko aukerarik garestiena.
Zertaz babestuko ez zaituena: Ez du lagunduko datuen ustelkeriaren aurka, baita giza faktoretik ere, beraz, aldi berean babeskopiak egitea gomendatzen da.Praktiketatik: Gure bezeroetako batek hondamendiak berreskuratzeko plan integral bat garatu zuen. Hau da aukeratu zuen estrategia:
- Hondamendiei aurre egiteko hodei batek azpiegitura mailan dauden hutsegiteetatik babesten du aplikazioa.
- Bi mailatako babeskopiak giza akatsen kasuan babesa eskaintzen du. Bi babeskopia mota daude: "hotzak" eta "beroak". Babeskopia "hotza" bat desgaituta dago eta denbora behar du zabaltzeko. Babeskopia "beroa" dagoeneko erabiltzeko prest dago eta azkarrago leheneratzen da. Bereziki dedikaturiko biltegiratze sistema batean gordetzen da. Hirugarren kopia zinta batean grabatu eta beste gela batean gordetzen da.
Astean behin, bezeroak babeskopia probatzen du eta babeskopia guztien funtzionaltasuna egiaztatzen du, zintakoak barne. Urtero konpainiak hondamendien aurkako hodei osoa probatzen du.
- Antolatu erreplikazioa beste gune batera
Gune nagusian arazo globalak saihesteko beste aukera bat: geo-erreserba ematea. Beste era batera esanda, sortu babeskopiko makina birtualak beste hiri bateko gune batean. DRrako irtenbide bereziak egokiak dira horretarako: gure enpresan VMware vCloud Availability (vCAV) erabiltzen dugu. Haren laguntzarekin, babesa konfigura dezakezu hodeiko hornitzaile gune batzuen artean edo hodeira leheneratu gune lokal batetik. Dagoeneko zehatzago hitz egin dut vCAVrekin lan egiteko eskemari buruz .
RPO eta RTO: 5 minututik aurrera.
Kostua: lehen aukera baino garestiagoa, baina hondamendien aurkako hodei batean hardwarearen erreplikazioa baino merkeagoa. Prezioa vCAV lizentzia baten kostua, administrazio-tasak, hodeiko baliabideen kostua eta PAYG ereduaren araberako erreserba-baliabideen kostua da (matrikula virtual itzalita duten lan-baliabideen kostuaren % 10).
Praktiketatik: Bezeroak 6 makina birtual gorde zituen datu-base ezberdinekin gure hodeian Moskun. Hasieran, babeskopia bidez ematen zen babesa: segurtasun kopia batzuk Moskun hodeian gordetzen ziren, eta beste batzuk gure San Petersburgoko gunean. Denborarekin, datu-baseak handitu egin ziren, eta babeskopia batetik leheneratzea denbora gehiago behar izaten hasi zen.
VMware vCloud Availability-n oinarritutako erreplikazioa gehitu da babeskopietan. Makina birtualen erreplikak San Petersburgoko babeskopia gune batean gordetzen dira eta 5 minuturo eguneratzen dira. Gune nagusian hutsegite bat gertatzen bada, langileak modu independentean San Petersburgoko makina birtualaren erreplika batera aldatzen dira eta lanean jarraitzen dute.
Kontuan hartutako irtenbide guztiek erabilgarritasun handia eskaintzen dute, baina ez dute babesten ransomware birusaren edo ustekabeko langileen akatsen batengatik datu-galeren aurka. Kasu honetan, beharrezko RPO emango duten babeskopiak beharko ditugu.
5. Ez ahaztu babeskopiaz
Denek daki babeskopiak egin behar dituzula, hondamendiei aurre egiteko irtenbiderik onena izan arren. Beraz, puntu batzuk laburki gogoraraziko dizkizut.
Zorrotz esanda, babeskopia ez da DR. Eta horregatik:
- Denbora luzea da. Datuak terabytetan neurtzen badira, berreskuratzeak ordubete baino gehiago beharko du. Berrezarri behar duzu, sare bat esleitu, pizten dela egiaztatu, datuak ondo daudela ikusi. Beraz, RTO on bat eman dezakezu datu gutxi baldin badago.
- Baliteke datuak lehen aldian ez berreskuratzea, eta ekintza errepikatzeko denbora eman behar duzu. Esaterako, badira datuak zehatz-mehatz noiz galdu diren ez dakigula. Demagun 15.00:15.00etan nabaritu dela galera, eta orduro kopiak egiten direla. 14:00etatik aurrera errekuperazio puntu guztiak aztertzen ditugu: 13:00, XNUMX:XNUMX eta abar. Sistema garrantzitsua bada, berreskuratzeko puntuaren adina gutxitzen saiatzen gara. Baina babeskopia berriak beharrezko datuak ez baditu, hurrengo puntua hartuko dugu - denbora gehigarria da.
Kasu honetan, babeskopia-egutegiak behar dena eman dezake RPO. Babeskopia egiteko, garrantzitsua da gune nagusiarekin arazoak izanez gero geo-erreserba ematea. Gomendagarria da segurtasun kopia batzuk bereizita gordetzea.
Hondamendia berreskuratzeko azken planak gutxienez 2 tresna izan behar ditu:
- 1-4 aukeretako bat, sistemak akatsetatik eta erorketetatik babestuko dituena.
- Babeskopia egin datuak galtzetik babesteko.
Merezi du, halaber, babeskopiko komunikazio kanal bat zaintzea, Interneteko hornitzaile nagusiak behera egiten badu. Eta - voila! β Gutxieneko soldatako DR jada prest dago.
Iturria: www.habr.com