Vores seneste blogindlæg handlede om De 3 beredskabsdyder, som du kan læse her. Denne gang fortsætter vi i beredskabets verden og ser nærmere på scenarier og strategier.
Først skal vi lige have noget terminologi på plads.
Et beredskabsscenarie er en defineret situation, man kan blive udsat for og som beredskabsplanen håndterer.
En beredskabsstrategi er måden hvorpå man vælger at håndtere et givent scenarie i en beredskabsplan.
Mange har svært ved at få helt styr på disse begreber, fordi man tit forbinder ordet "strategi" med et helt overordnet dokument, der beskriver virksomhedens visioner og fremtidsplaner. Men i det her tilfælde er det altså strategier for, hvordan vi vil håndtere brand, systemnedbrud, virusangreb, mv. Så ordet strategi er altså korrekt nok, men bare sat i kontekst til et specifikt scenarie.
Hvor skal jeg starte?
Hvordan udvælger man så disse scenarier, som ens beredskab skal kunne håndtere?
Kunsten ligger i, at man ikke skal være for specifik, men alligevel specifik nok til at vi kan bruge det til noget.
For hvis vi tror, vi kan lave en udtømmende liste over detaljerede scenarier vi kan blive ramt af, så ender vi med at blive ramt af det scenarie vi ikke havde forudset.
Så i stedet for en liste af scenarier der ser således ud:
- Brand i datacenter
- Skybrud der påvirker datacenter
- Længerevarende strømafbrud i datacenter
- Hærværk på datacenter
- etc.
- har vi et scenarie der hedder: Datacenter ude af drift.
For faktum er, at vi skal kunne håndtere en situation, hvor vi ikke kan bruge vores datacenter - uanset hvad grunden er. Dermed undgår vi en masse unødigt tekst i vores beredskabsplan (se De 3 beredskabsdyder) og vi signalerer, at vores beredskabsplan er designet til at kunne håndtere flere situationer.
Så rent praktisk kan man afholde en workshop med udvalgte medarbejdere i organisationen og fastlægge hvilke scenarier vores beredskabsplan skal omfatte.
Som nævnt ovenfor, kunne et scenarie være: Datacenter ude af drift. Andre eksempler på scenarier kunne være:
- Nedbrud på kritisk system
- Nedbrud på en kritisk virtuel server
- Nedbrud på SQL server
- Omfattende virusudbrud
- Hackerangreb
- Nøgleleverandør går konkurs
- Informationslæk
- etc.
Som det ses, er de af forskellig detaljeringsniveau og her gælder det om at finde sit rette niveau.
Strategier
Når man nu har fastlagt hvilke scenarier ens beredskab skal omfatte, er det tid til at finde ud af, hvad man kan gøre ved det. Altså definere beredskabsstrategierne.
Det er altid nemmere at beskrive ens strategier på forhånd, så man ikke skal finde på for mange løsninger i situationen. Derfor skal man også passe på med rent "action team" baseret beredskab. Der er simpelthen for meget stress og pres til at man kan forvente, at folk kan finde frem til og effektuere den rigtige løsning i situationen.
For at beskrive sine strategier, gør man rent praktisk det, at man definerer de skridt vi skal gennemgå for at håndtere den givne situation. Dette kan eventuelt gøres på workshop’en nævnt ovenfor.
Og der er det vigtigt at tænke hele situationen igennem:
- Skal der mobiliseres en konsulent/leverandør?
- Kan vi forud definere et subset af data, der er særligt kritiske og skal genetableres først?
- Husk kommunikation!
- Husk test!
- Hvilke forudsætninger er der for denne strategi?
- Hvilken rækkefølge skal systemer startes i?
- etc.
En beredskabsstrategi bør heller ikke være for detaljeret. Vi skal beskrive de forskellige aktiviteter og deres rækkefølge, men vi skal ikke beskrive ned i "højre hånds tommel- og pegefinger" niveau.
Hvis der er behov for at beskrive præcist, hvordan man f.eks. teknisk geninstallerer en applikation, så bør dette ligge i nogle disaster recovery-procedurer eller noget systemdokumentation.
Når scenarier og strategier er på plads, har man i virkeligheden sin beredskabsplans rygrad og er godt på vej til en fornuftig beredskabsplan.
Har du erfaringer med at lave effektive, pragmatiske og operationelle beredskabsplaner? Så del dem gerne i kommentarfeltet nedenfor.
Øvrige ressourcer:
Tilmeld dig vores øvrige webinarer og arrangementer her.
