Een IT disaster recovery plan dat je midden in de nacht kunt lezen
De meeste plannen die wij tegenkomen zijn niet fout, ze zijn onbruikbaar: te lang, te oud, en geschreven voor iemand die alles al weet. Dit is wat er wél in een IT disaster recovery plan hoort, en in welke vorm.
Zes onderdelen die er niet in mogen ontbreken
Alles wat er verder in staat is nuttig. Deze zes zijn het verschil tussen een plan dat werkt en een document dat bestaat.
- Wanneer het plan geldtEén zin die zegt wanneer je dit document openslaat, en wie dat mag besluiten. Zonder die zin blijft het liggen tijdens de storing waar het voor gemaakt is, omdat niemand durft te zeggen dat dit hem is.
- De volgorde van herstelWelke systemen eerst terug moeten en welke kunnen wachten, met de reden erbij. De reden is belangrijker dan de volgorde: die verandert namelijk, en dan kun je hem opnieuw afleiden in plaats van opnieuw bedenken.
- Per systeem: waar de kopie staatLocatie, hoe je erbij komt en wie de sleutels heeft. Inclusief de vraag hoe je erbij komt als de omgeving waar je normaal doorheen inlogt niet beschikbaar is — dat is de meest gemiste regel in elk plan.
- Afhankelijkheden tussen systemenWat er eerst moet draaien voordat het volgende systeem opstart: naamgeving, licenties, certificaten, koppelingen naar buiten. Deze lijst ontstaat vanzelf zodra je één keer echt hebt teruggezet, en vrijwel nooit daarvoor.
- Contactgegevens die buiten de omgeving staanTelefoonnummers van je eigen mensen, van leveranciers en van de partij die de lijn levert. Op papier of op een telefoon, niet in het systeem dat plat ligt.
- Hoe je weet dat het klaar isPer systeem één controle die zegt dat het werkelijk werkt, en niet alleen dat het aanstaat. Zonder dat komt de organisatie terug op iets wat half draait, en dan begint de tweede storing.
Waaraan je merkt dat een plan bruikbaar is
Vier eigenschappen die niets met de inhoud te maken hebben en alles met of het gebruikt wordt.
Het past op weinig pagina’s
De kern hoort in een handvol pagina’s te passen, met de details in bijlagen. Wie er tijdens een storing doorheen moet bladeren, leest hem niet.
Het is geschreven voor iemand anders
Niet voor de beheerder die het bouwde, maar voor de collega die dienst heeft. Dus zonder afkortingen die alleen intern bestaan, en met de stappen uitgeschreven.
Het is buiten de omgeving te openen
Een plan dat in de fileshare staat die je aan het herstellen bent, bestaat op dat moment niet. Een geprinte kopie op twee locaties is ouderwets en werkt.
Het draagt een datum en een eigenaar
Eén persoon die hem bijwerkt, en een datum waaraan je ziet hoe oud hij is. Een plan zonder eigenaar veroudert precies zo snel als de omgeving verandert.
Hoe het plan actueel blijft
Het onderhoud is waar plannen op stuklopen, niet het schrijven. Drie momenten waarop hij hoort te veranderen.
- Bij elke wijziging die iets toevoegt of weghaaltKomt er een systeem bij, gaat er een uit, verandert er een koppeling — dan verandert het plan mee. Dat werkt alleen als het onderdeel is van het wijzigingsproces en niet van een jaarlijkse opruimactie.
- Na elke oefeningElke oefening levert dingen op die anders bleken te lopen. Die gaan er meteen in, want over drie maanden weet niemand ze meer.
- Na elke echte storingOok als het goed ging. Juist dan, want dan is bekend wat werkte en waarom, en dat is het deel dat normaal nergens wordt opgeschreven.
- Bij een wisseling van leverancierAndere partij, andere telefoonnummers, andere afspraken over reactietijd. Een plan met het nummer van de vorige leverancier erin is erger dan een plan zonder nummer.
Verder lezen
Waar dit op aansluit.
Vragen die we hierover krijgen
De vragen die het vaakst langskomen, kort beantwoord.
Hoe lang moet een IT disaster recovery plan zijn?
De kern hoort op een handvol pagina’s te passen, met de details in bijlagen. Wie er tijdens een storing doorheen moet bladeren, leest hem niet — en dan is de lengte precies het probleem dat het plan had moeten oplossen.
Waar bewaar je het plan?
Buiten de omgeving die je aan het herstellen bent. Een plan op de fileshare die plat ligt bestaat op dat moment niet. Een geprinte kopie op twee locaties is ouderwets en werkt, en een kopie op een telefoon werkt ook.
Wie hoort het plan bij te houden?
Eén persoon met naam, en het bijwerken hoort in het wijzigingsproces te zitten in plaats van in een jaarlijkse opruimactie. Een plan zonder eigenaar veroudert precies zo snel als de omgeving verandert.
Laat ons het plan een keer stukmaken
Stuur op wat er nu ligt, of vertel wat er draait als er nog niets ligt. We lopen het langs op de zes onderdelen hierboven en zeggen welke er ontbreken.
Praktische IT-kennis in je inbox
Nieuwe gidsen over beheer, beveiliging en de werkplek, geschreven door de mensen die het werk doen. Geen verkooppraat, en afmelden kan met één klik.