Një test i rimëkembjes ndaj fatkeqësive (provë për DR) është shqyrtimi i çdo
hapi në planin e rimëkëmbjes ndaj fatkeqësive ashtu siç përshkruhet në procesin
e planifikimit të vazhdimësisë së biznesit / rikthimit ndaj fatkeqësive (BCDR)
të një organizate.
Testimi i rikthimit ndaj fatkeqësive ndihmon që një organizatë të mund të
rikuperojë të dhënat, ti rivendosë aplikacionet kritike të biznesit si dhe të
vazhdojë operacionet pas ndërprerjes së shërbimeve. Në shumë organizata,
megjithatë, testimi i DR është lënë pas dore, sepse krijimi i një plani për
rikuperimin ndaj fatkeqesive mund të lidhë burimet dhe të jetë i kushtueshëm.
Kompanitë mund ta konsiderojnë planin e tyre të DR si të mjaftueshme, edhe nëse
nuk ka dëshmi se ajo mund ta kryejë atë plan nëse goditet nga fatkeqësia.
Nëse një organizatë nuk investon kohë dhe burime në testimin e planit të
rimëkëmbjes së fatkeqësive, ekziston një shans i vërtetë që plani do të
dështojë të ekzekutohet siç pritet atëhere kur është e nevojshme. Komunikimet,
rikuperimi i të dhënave dhe shërimi i aplikacioneve zakonisht janë fokusi i
testimit të rikuperimit të fatkeqësive. Fusha të tjera për testim variojnë, në
varësi të objektivit të objektit të rikuperimit (RPO-Recovery Point Objective)
dhe kohës së rikuperimit (RTO-Recovery Time Objektive).
Qëllimet e testimit të
rikuperimit të fatkeqësive
Një nga qëllimet kryesore të një prove të rikuperimit ndaj katastrofave
është të përcaktojë nëse një plan DR mund të funksionojë dhe të përmbushë
kërkesat e paracaktuara të RPO / RTO të një organizate. Ai gjithashtu jep
reagime për ndërmarrjet në mënyrë që ata të mund të ndryshojnë planin e tyre DR
nëse ndonjë çështje e papritur lind.
Sistemet e TI-së rrallë mbeten të stagnuara, kështu që produktet e reja dhe
të përmirësuara duhet të testohen përsëri. Te sistemet e ruajtjes dhe serverët
mund të jenë shtuar ose përditësuar aplikacionet e reja të aplikuara dhe
aplikacionet e vjetra të përditësuara pasi që një organizatë e zhvilloi planin
e saj të rimëkëmbjes ndaj fatkeqësive. Ose, edhe cloud (si privat, publik ose hibrid)
mund të fillojë të luajë një rol më të madh në infrastrukturën IT të një
organizate. Një test për rimëkëmbjen e fatkeqësive ndihmon për t'u siguruar që
një plan DR të mbetet i tanishëm në një botë të TI-ve që vazhdimisht ndryshon.
Llojet e testeve të rikuperimit
ndaj fatkeqësive
Ekzistojnë tri lloje themelore të testimit të rikuperimit të fatkeqësive.
Këto përfshijnë një rishikim të planit, testin tabletop dhe testin e simulimit.
Plani i rishikimit: këtu, pronari i planit DR dhe anëtarët e tjerë të
ekipit pas zhvillimit dhe zbatimit të tij e kalojnë duke e shqyrtuar atë në
detaje për të gjetur ndonjë mospërputhje dhe elementë të humbur.
Testi Tabletop: këto janë ushtrime ku palët e interesit mblidhen për të ecur hap pas hapi
përmes të gjithë komponentëve të një plani të rimëkëmbjes të fatkeqësive. Kjo
ndihmon në përcaktimin nëse të gjithë e dinë se çfarë duhet të bëjnë në rast
emergjence dhe zbulojnë ndonjë mospërputhje, mungesë informacioni ose gabime.
Simulimi: simulimi
i skenarëve të fatkeqësive është një mënyrë e mirë për të parë nëse procedurat
dhe burimet - duke përfshirë sistemet rezervë dhe vendet e rikuperimit - të
ndara për rikuperimin ndaj fatkeqësive dhe vazhdimësinë e biznesit punojnë në
një situatë sa më afër botës reale. Një simulim kryen një sërë skenaresh
fatkeqësish për të parë nëse ekipet e përfshira në procesin e DR mund të
rifillojnë teknologjitë dhe operacionet e biznesit në kohën e duhur. Një
simulim mund të përcaktojë nëse ka njerëz të mjaftueshëm në staf për të bërë
punën e DR siç duhet.
Aspektet e rëndësishme të testit
DR
Testimi efektiv i rikuperimit të katastrofave duhet të marrë parasysh:
Kohën:
Kur ishte hera e fundit që u provua një aplikacion apo sistem? Sa më e gjatë të
jetë hapsira kohore mes testeve, aq më i lartë është rreziku që ndryshimi ose
rritja (në të dhëna, hardware ose softuer) do të rezultojë në dështimin e
planit DR. Është gjithashtu e rëndësishme të matni dhe të dini sa kohë një
rimëkëmbje e plotë merr nga një perspektivë RTO si pjesë e testit tuaj DR.
Ndryshimet:
Testoni për të siguruar që proceset e backup / restore mbeten të paprekura nga
ndonjë ndryshim. Gjithmonë kryej një test DR pas çdo ndryshimi të madh të
infrastrukturës - në harduerin e depos së ruajtjes së dhënave , për shembull -
pasi këto mund të çojnë në nevojën për të rishkruar proceset e rikuperimit ndaj
katastrofave.
Ndikimi:
Duhet të dini nëse rikuperimi i fatkeqësive do të ndikojë në mjedisin tuaj të
prodhimit. Ndonjëherë, për shembull, testet mund të jenë joproduktive, sepse
një aplikacion ose pajisje hardware duhet të hiqet gjatë një testi ose ato mund
të kenë ndikim në të dhënat e drejtpërdrejta. Të gjitha të dhënat dhe
azhurnimet e softuerëve duhet të inkorporohen në një simulim për të siguruar se
është një veprim i vlefshëm dhe ndikimi i testeve janë të njëjta sikur plani DR
të zbatohej në një fatkeqësi reale.
Njerëzit:
Përdorni një test DR për të minimizuar ose hequr plotësisht potencialin për
gabime njerëzore nga procesi i rimëkëmbjes së fatkeqësive. Dhe, për të
përcaktuar më mirë vlefshmërinë e të gjitha hapave në një plan DR, sigurohuni
që të përdorni një shumëllojshmëri njerëzish - jo vetëm punonjës të përfshirë
në mbështetjen e drejtpërdrejtë të një aplikacioni të veçantë - gjatë
ekzekutimit të testimeve, qoftë në një sistem real ose gjatë një ushtrimi në
letër.
Lista e kontrollit të testimit të
rikkthimit ndaj fatkeqësive
Paraqitni një plan të detajuar të testimit të DR kur përpiqeni të merrni
miratimin dhe financimin për të kryer testet.
Qartë identifikoni qëllimet, objektivat, procedurat dhe atë që kërkoni në
analizat tuaja pas testimit.
Vendosni ekipin e testimit - duke përfshirë ekspertët e lëndës - dhe
sigurohuni që të gjithë të jenë në dispozicion për datën e testimit të
planifikuar.
Përcaktoni saktësisht se çfarë të testoni (backup dhe rikthim, rifillimin e
sistemit dhe rrjeteve, sistemin e njoftimit të punonjësve, etj.).
Dokumentoni me kujdes dhe jeni të përgatitur për të redaktuar planin tuaj
DR dhe skriptat e testimit të rikthimit ndaj fatkeqësive.
Shqyrtoni dhe konfirmoni që të gjitha kodet në skriptet e testimit janë të
sakta.
Përfshini të gjitha elementet dhe proceset përkatëse të teknologjisë që
testohen, pa marrë parasysh se a duken të parëndësishme, në plan.
Sigurohuni që mjedisi i testimit të jetë i gatshëm, i disponueshëm dhe nuk
do të ndikojë në sistemet e prodhimit para fillimit. Sigurohuni që testimi të
mos bjerë në konflikt me ndonjë aktivitet ose test tjetër.
Programoni një test DR shumë më herët, i cili mund të zgjasë me orë,
njoftoj dhe kujtoj menaxherët e tjerë të IT për testin e ardhshëm.
Ndaloni dhe rishikoni testin nëse lindin probleme. Vazhdoni nëse problemi
mund të anashkalohet. Ripërpunoni nëse është e nevojshme.
Caktoni një kohëmatës për të regjistruar kohën e nisjes dhe përfundimit dhe
një shkrues për të marrë shënime për të ndihmuar në përgatitjen e raportit
pas-veprimit të testit, i cili përshkruan atë që ndodhi gjatë testit, çfarë
bëri dhe nuk funksionoi dhe çfarë është mësuar nga testi.
Përditëso planet e rikuperimit të fatkeqësive dhe planet e vazhdimësisë së
biznesit dhe dokumentet e tjera bazuar në atë që është mësuar nga testi DR.
Comments
Post a Comment