X
GO

Kurset

Kërko Kurse

TESTI PËR RIKTHIM PAS FATKEQËSIVE

TESTI PËR RIKTHIM PAS FATKEQËSIVE

Një test i rimëkëmbjes pas fatkeqësive (provë për DR) është shqyrtimi i çdo hapi në planin e rimëkëmbjes pas fatkeqësive ashtu siç përshkruhet në procesin e planifikimit të vazhdimësisë së biznesit/rikthimit pas fatkeqësive (BCDR) të një organizate.

 

Testimi i rikthimit te të dhënave pas fatkeqësive (DR) ndihmon që një organizatë të mund të rikuperojë të dhënat, të 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 pas fatkeqësive mund të lidhë burimet dhe të jetë i kushtueshëm. Kompanitë mund të konsiderojnë planin e tyre të DR si të mjaftueshëm, edhe nëse nuk ka dëshmi se ajo mund ta kryejë atë plan nëse goditet nga ndonjë fatkeqësi.  

 

Nëse një organizatë nuk investon kohë dhe burime në testimin e planit të rimëkëmbjes pas një fatkeqësie, ekziston një shans i vërtetë që plani do të dështojë të ekzekutohet siç pritet atëherë kur të jetë e nevojshme. Komunikimet, rikuperimi i të dhënave dhe shërimi i aplikacioneve zakonisht janë fokusi i testimit të rikuperimit pas fatkeqësive. Fusha të tjera për testim ndryshojnë, varësisht nga objektivi i objektit të rikuperimit (RPO – Recovery Point Objective) dhe kohës së rikuperimit (RTO – Recovery Time Objective).

 

 

QËLLIMET E TESTIMIT TË RIKUPERIMIT PAS FATKEQËSIVE

Një nga qëllimet kryesore të një prove të rikuperimit pas një katastrofe, ë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 pas 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 pas 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ë skenarësh 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 pas 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 pas fatkeqësive. Dhe, për të përcaktuar më mirë vlefshmërinë e të gjithë 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Ë RIKTHIMIT PAS 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 pas fatkeqësive.
  • Shqyrtoni dhe konfirmoni që të gjitha kodet në skriptet e testimit janë të sakta.
  • Përfshini në plan të gjitha elementet dhe proceset përkatëse të teknologjisë që testohen, pa marrë parasysh se a duken të parëndësishme apo jo.
  • 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ë, njoftoni menaxherët e tjerë të IT-s 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 pas fatkeqësive dhe planet e vazhdimësisë së biznesit dhe dokumentet e tjera bazuar në atë që është mësuar nga testi DR.

 

 

DR – Data Recovery (kthimi i shënimeve)

BCDR – Business Continuity and Data Recovery (Vazhdimësia e Biznesit dhe Kthimi i të dhënave)

Print
320 Vlerëso artikullin:
4.9
Ragip Avdijaj
Kategoria: Blog, Teknologji

x