Ontdek waarom het belangrijk is om een robuust noodherstelplan voor uw bedrijf te hebben.
Niets wordt tegelijkertijd uitgevonden en geperfectioneerd. ~John Ray
Onsterfelijk of sterfelijk, de kans dat we honderd procent efficiëntie bereiken in alles wat we doen, is bijna nul. Ons Disaster Recovery (DR) plannen lopen op geen enkele manier uiteen. Inefficiëntie of falen zijn echter geen indicaties van ondergang, maar eerder de opstapjes naar het bereiken van superieure resultaten.
Ons artikel over Herstel na een Ramp is essentieel voor het begrijpen van de rol van disaster recovery bij gegevensback-up en het verminderen van verliezen als gevolg van natuurlijke of technische rampen. Kort gezegd is rampenherstel een handeling waarbij iemands vooruitziende blik wordt gebruikt om risico's te beperken die zich in de nabije toekomst kunnen voordoen. EEN Ramp herstel plan is een vruchtbaar resultaat van het verantwoorden van rampenherstel door middel van woorden en concrete stappen. In wezen is het een document dat verschillende voorschriften en richtlijnen omvat die een organisatie bij allerlei rampen volgt. Het begrijpen van de kleinste details en het identificeren van dubbelzinnige scenario's is dus de sleutel tot het ontwikkelen van een betere Disaster Recovery-strategie en een effectief DR-plan.
Waarom is het testen van het DR-plan belangrijk?
Zoals John Ray terecht had gezegd, is de kans op het bereiken van een onfeilbaar DR-plan bij de allereerste poging menselijk onmogelijk. Het kan een direct gevolg zijn van het niet in overweging nemen van alle aspecten van de software of netwerkconfiguratie, de implicaties van de onderliggende hardware, het upgraden van de servers, software of hardware en andere soortgelijke redenen. Om het DR-plan te laten concurreren met zijn omgeving en ervoor te zorgen dat het voldoet aan de RPO en RTO's, is het daarom essentieel om het DR-plan met regelmatige tussenpozen iteratief te testen.
Uw DR-plan begrijpen
Een DR-plan bestaat uit de mogelijke rampscenario's en de strategieën die zijn ontwikkeld om hun apparatuur en gegevens daaruit te versterken. Een organisatie kan echter alleen uitblinken in haar plan van aanpak als ze het feit hebben verteerd dat haar omgeving dynamisch is en consistentie een luchtspiegeling is. Het DR-plan moet iteratief worden bestudeerd en geïmproviseerd om de onvermijdelijke inconsistentie aan te pakken.
Om dit te bereiken, moet het DR-team het volgende kunnen doen:
- Bestaande tekortkomingen: De tekortkomingen van hun plan identificeren, vergelijkbaar met het debuggen van een programmacode en het vinden van geschikte oplossingen.
- Ontwikkelende omgeving: Inzicht in de veranderingen die worden opgelegd aan de huidige strategieën als gevolg van de zich ontwikkelende omgeving. Het DR-team moet zich bewust zijn van de evolutie van technologie en de uitdagingen die daarmee gepaard gaan.
- Nieuwe risico's: Het DR-team moet deze risico's in overweging nemen om een waterdicht plan op te stellen. In een dynamische omgeving is het toevoegen van uitdagingen onvermijdelijk. Het DR-team moet dus goed uitkijken om ervoor te zorgen dat de spleten gesloten blijven en goed worden afgedicht tegen kwaadwillende interventie.
DR-testen met minder personeel
Zoals het idioom terecht aangeeft, bederven te veel koks de bouillon, en de automatisering van rampenherstel en -beheer heeft geleid tot een afname van de behoefte aan menselijk ingrijpen. De hoge mate van controle en zorg die is besteed aan het aanwerven van een kleine, maar goed uitgeruste groep deskundigen om deel uit te maken van het DR-testteam, compenseert de vermindering van het personeel. Afgezien van de voor de hand liggende reden om kosteneffectief te zijn, neemt de kans op complicaties en miscommunicaties af naarmate een hechte groep met gelijkgestemde belangen leidt tot effectieve DR-testen.
Testen van DR-plannen – Maken, simuleren en emuleren, consolideren
Elk product vereist iteratieve tests, prototypetests, bètatests, enz. om het succes en falen van updates en functies te identificeren die tijdens elke iteratie of in de onderhoudsfase zijn geïntroduceerd.
Evenzo is het extraheren van de tekortkomingen van een DR-plan grotendeels afhankelijk van het vermogen van het DR-team om de testomgeving af te stemmen op de daadwerkelijke omgeving om de werking van het DR-plan te bewaken en te simuleren.
Het testen van het DR-plan omvat de volgende fasen:
Fase 1: creëren
Het testen van het DR-plan is net zo succesvol als de tests die zijn ingezet om het gedrag ervan onder de loep te nemen. De tests moeten betrekking hebben op elke testcase en aandacht besteden aan hoekgevallen die een scherp oog vereisen. Om de resultaten van deze tests te analyseren en uitgebreide conclusies te trekken, mogen de tests verder niet dubbelzinnig zijn.
Hoe doen we dat?
- Identificeer de doel van de test. De tests moeten samenhangend zijn met minder koppeling om ervoor te zorgen dat elk kenmerk van het DR-plan wordt getest.
- Identificeer en benadruk de parameters of doelstellingen gebruikt om het succes of falen van een test te meten.
- Identificeer de rollen van leden en schrijf een uitgebreide beschrijving van de werkomgeving om de juiste inzet van de test te garanderen.
Onthoud dat nauwgezette documentatie de sleutel is om deuren naar het hiernamaals te openen! Het hiernamaals, een verzachte wereld met een versterkt pantser klaar voor alles wat op zijn pad komt!
Hieronder vindt u voorbeelden van inzetbare tests:
- Papiertest: De papieren test omvat de gezamenlijke inspanningen van alle leden van het DR-team. Het plan wordt woord voor woord gelezen, waarbij gemiste aanwijzingen worden blootgelegd en dubbelzinnige taal wordt geïdentificeerd (ook wel tafeloefeningen genoemd).
- Paralleltest: Parallel testen omvat de gelijktijdige werking van twee soorten systemen. De herstelsystemen worden getest aan de hand van de verschillende geïdentificeerde scenario's om hun vermogen om transacties af te handelen te controleren en de werking van het primaire systeem na te bootsen. Ondertussen werken de primaire systemen continu op optimale capaciteit zonder enige hinder.
- Cutover-test: In tegenstelling tot parallelle tests richt de cutover-test zich primair op het herstelsysteem dat bij een ongunstig scenario de volledige werklast overneemt. Daarom moet het primaire systeem inactief blijven om een goede analyse van het failover-herstelsysteem uit te voeren.
Fase 2: Simuleren en emuleren
We herhalen onze eerder genoemde tip: de analyse van een DR-plan is slechts zo goed als de simulatieomgeving die ernaar streeft het potentieel van het plan te testen. DR-simulatie is een andere vorm van DR-testen en altijd de belangrijkste.
De simulatie helpt bij het onder de aandacht brengen van de onderstaande inzichten:
- Ten eerste, het vermogen van het systeem om aan zijn eisen te voldoen Herstelpunt doelstellingen en Hersteltijd doelstellingen worden gemeten en gekwantificeerd. Het kwantificeren van deze gegevens helpt bij het nemen van weloverwogen beslissingen.
- De robuustheid van het herstelsysteem wordt begrepen.
- Gegevensintegriteit, verlies en beveiliging worden gemeten. Zo wordt het tolerantieniveau van het systeem geïdentificeerd.
- Het proces kan de tekortkomingen van het plan uit de weg ruimen en de identificatie van geschikte tests in gang zetten om deze te verminderen.
Bovenstaande inzichten zijn om er maar een paar te noemen.
Bij de succesvolle simulatie van de omgeving, emuleert u het DR-plan om ideale doelstellingen na te streven en te bereiken. Daarom moeten er ongetwijfeld tijd en moeite worden geïnvesteerd in simulatie en emulatie om ervoor te zorgen dat in de toekomst opgelopen verliezen drastisch worden verminderd.
Fase 3: Consolideren
Gegevens verkregen uit de testfase zullen nauwgezet moeten worden bestudeerd om het DR-plan te consolideren. Het verwerken van de resultaten is geen gemakkelijke taak. DR-teamleden en technische enthousiasten moeten samenwerken om logische conclusies te trekken uit de verkregen testgegevens en het bestaande plan aan te passen om te voldoen aan de geïdentificeerde statistieken.
Zo wordt een iteratief proces van creëren, simuleren, emuleren en consolideren in gang gezet, een cyclus die elk ander softwareontwikkelingsproces nabootst.
Checklist voor de redding!
Ik kijk veel astronautenfilms... Meestal Star Wars. En zelfs Han en Chewie gebruiken een checklist. ~ Jon Stewart
Het testen van uw DR-plan tegen uw back-upstrategie klinkt misschien ontmoedigend en omslachtig, maar goede oude checklists zijn hier om te redden. Een eenvoudige checklist helpt het hele DR-team op schema te houden, deadlines, verwachtingen, te bereiken mijlpalen te bewaken, enz. Zoals eerder vermeld, is documentatie de sleutel tot intelligent en efficiënt werken. Ons volgende artikel presenteert een voorbeeldchecklist die als basissjabloon kan dienen voor onze gebruikers om verder aan te passen aan hun back-upvereisten. om een aan te vragen demonstratie, om te kiezen voor een gratis trial of neem voor verdere vragen contact op met onze vertrouwde ondersteuningsteam en ontvang direct begeleiding en ondersteuning. Zmanda is er voor jou!
