Disaster Recovery-planning met bestaande platformapparatuur
Disaster Recovery-planning is altijd lastig; er zijn zoveel factoren en “wat als”-scenario’s waarmee rekening moet worden gehouden, en te veel investeren in de hersteloplossing kan op zichzelf al een kleine ramp worden. Een factor die bij DR-planning vaak over het hoofd wordt gezien, is dat u in geval van een ramp doorgaans bereid en zeer gewillig bent om waar nodig concessies te doen, omdat er al een ramp heeft plaatsgevonden. Het is tijd voor triage, niet voor business as usual.
Veel mensen gaan er meteen van uit dat als u voor uw live productiesystemen een capaciteit en prestatie van X nodig hebt, u eveneens X nodig zult hebben voor uw disaster recovery-systemen. In de praktijk is dit echter zelden het geval. In geval van een ramp kunt u, op zeldzame uitzonderingen na, uit de voeten met lagere prestaties en de beschikbaarheid van systemen beperken tot enkel de meer kritieke systemen, terwijl veel onderhoudsoperaties, waaronder vaak ook archiveringssystemen, worden opgeschort totdat de volledige productie is hersteld. Dit betekent dat uw disaster recovery-systeem vaak veel kleiner kan zijn dan uw primaire productiesystemen.
Disaster recovery-systemen zijn geen investeringen in productiviteit; het zijn indekkingen tegen uitval en moeten in dat licht worden bezien. Daarom is het een gangbare en effectieve strategie om de behoeften van het DR-systeem meer te benaderen vanuit het perspectief dat het “toereikend” is om de bedrijfsactiviteiten te handhaven, maar niet noodzakelijkerwijs voldoende om dit ook comfortabel of transparant te doen. Als er een volledige ramp toeslaat en het personeel te maken krijgt met traag ophalen van bestanden, langzamer dan normale databases, of het uitstellen van een diepgaande BI-analyse totdat de hoogwaardige productiesystemen zijn hersteld, zullen weinig mensen klagen. De meeste medewerkers, en zeker de meeste zakelijke beslissers, kunnen er veel begrip voor opbrengen dat een systeem zich in een storingstoestand bevindt en dat zij wellicht moeten helpen om zich zo goed mogelijk te redden totdat de volledige capaciteit is hersteld.
Met deze aanpak in gedachten kan het een effectieve strategie zijn om oudere platformen opnieuw in te zetten op disaster recovery-locaties wanneer er nieuwe platformen worden aangeschaft en geïmplementeerd voor het primaire productiegebruik. Hiermee kan een goedkope en eenvoudig te plannen “DR-pijplijn” ontstaan, waarbij de DR-locatie altijd de capaciteit heeft van uw “laatste vernieuwing”, wat in de meeste DR-scenario’s meer dan toereikend is. Dit kan een uitstekende manier zijn om apparatuur te benutten die anders ofwel regelrecht zou worden afgedankt, ofwel zou verleiden tot herinzet in productie door een emotionele reactie op basis van “sunk cost” op te roepen, iets wat we over het algemeen willen vermijden.
De sunk cost-denkfout is een lastige om te vermijden. Doordat u de apparatuur al bezit, is het heel gemakkelijk om het gevoel te krijgen dat het opnieuw inzetten ervan, zelfs wanneer er een nieuw ontworpen systeem wordt geïmplementeerd, buiten de systeemontwerpen en specificaties om, nuttig of goed is. En er zijn gevallen waarin dit waar zou kunnen zijn, maar hoogstwaarschijnlijk is dat niet zo. Maar net zoals we niet te emotioneel gehecht willen raken aan apparatuur enkel omdat we er al voor hebben betaald, willen we ook de waarde in de bestaande apparatuur die we al bezitten niet negeren. Dit is waar een geplande pijplijn naar een Disaster Planning-scenario in veel gevallen op een werkelijk uitstekende manier kan voortbouwen op wat we al hebben geïnvesteerd. We moeten wel onthouden dat dit waarschijnlijk zeer bruikbare apparatuur is met nog veel restwaarde, als we maar weten hoe we deze op de juiste manier kunnen inzetten om aan onze bestaande behoeften te voldoen.
Een sterk planningsproces voor de migratie van het productieplatform naar het disaster recovery-platform kan een uitstekende manier zijn om de budgetuitgaven te verlagen en tegelijkertijd uitstekende disaster recovery-resultaten te behalen.