Varför borde organisationer ha ett dokument med en plan för disaster recovery? De främsta anledningarna är att det kan rädda er organisation från väldigt dyra kostnader samt ge insikter i hur väl rustade ni är för en kris och er motståndskraft mot kriser. I det här blogginlägget går jag igenom vad disaster recovery innebär och varför det är viktigt.
Jag kommer börja inlägget med en påhittad berättelse, som illustrerar hur verkligheten ofta ser ut. Efter berättelsen kommer vi gräva ner oss i vad en disaster recovery-plan är och hur skriver man en. Nu hoppar vi alltså in i berättelsen om Kim, som fick en mindre trevlig fredag på jobbet:
Kims historia
Det är fredag morgon och Kim gör sig själv en kopp kaffe och två skivor rostat bröd. Denna fredag är precis som alla andra fredagar de senaste åren, och det är absolut inget speciellt med den. Precis när hen sätter sig ner för att njuta av sin simpla men väldigt bekväma frukost ringer mobilen. Det är chefen som ringer och berättar att systemet som Kim underhåller ligger nere. Andra interna system, som är starkt beroende av det första systemet, ligger också nere. Företagets kunder har avtalat att systemet måste vara åter i bruk inom två timmar, annars måste skadestånd betalas. Att få upp systemet till brukligt skick blir därför prio ett.
Kim och kollegorna letar febrilt i loggar och dokumentation om hur man sätter upp systemet på nytt. Det var två år sedans det togs i bruk, och ingen kommer riktigt ihåg hur man satte upp det. Det har även skett vidareutveckling i systemet under dessa två år – den knapra dokumentation som fanns från förra installationen är inte längre fullständig. Det ser ut som om man inte kommer att klara av tvåtimmarsgränsen. I frustration utbrister en av Kims kollegor: "Vi skulle aldrig ha nedprioriterat disaster recovery-dokumentet!"
Det finns en uppgift i backloggen om att skapa ett dokument för disaster recovery. Uppgiften hade i början av arbetet med systemet prioriterats ner, till förmån för att implementera nya värdeskapande funktioner i systemet. Med tiden hade arbetet med att skapa dokumentet glömts bort och man fortsatte i stället med vidareutveckling av systemet.
Kim och kollegorna får upp systemet på eftermiddagen, flera timmar efter gränsen på två timmar och det är ett klart faktum: företaget har tappat stora intäkter på grund av att systemet legat nere och värre blir det när företagskunderna kommer med sina skadeståndskrav.
Kritiska system
Det vi läste i Kims historia är en risk som finns i nästan alla företag idag. Den gäller inte bara företag som befinner sig ute på internet; allt från internetleverantörer till dagligvaruhandel bygger idag på digitala system som bygger vidare på andra digitala system. Ett system i denna kedja kan orsaka stopp för flera organisationer, speciellt när något går sönder hos en underleverantör som levererar till flera kunder. Många av oss har nog Crowdstrike-incidenten nära i minnet, samt incidenten som inträffade år 2021 där Coop fick hålla stängt i dagar.
Min förhoppning med detta blogginlägg är att i alla fall några som läser det ska stanna upp, fundera över Kims historia och tänka "detta hade kunnat vara vi", för att sedan implementera en strategi för att hålla ett uppdaterat disaster recovery-dokument på plats. Jag kommer längre ner i inlägget gå igenom hur disaster recovery skiljer sig men även hänger ihop med business continuity, high availability och riskanalys. Jag går även igenom vilka kategorier man bör ha planer inom samt hur jag personligen strukturerar ett sådant här dokument.
Disaster recovery och dess syskon
Disaster recovery handlar om att återhämta sig till en acceptabel nivå av systemdrift. Disaster recovery plans är stegen man tar i en disaster recovery.
En bra startpunkt när man ska utföra en disaster recovery är att kolla på vilka service-level agreements (SLA) man har. Om man bara har interna system kanske man inte alltid har det nedskrivet, men det finns alltid förväntningar från förvaltare av ovanförliggande system. Frågan är bara om de själva känner till förväntningarna eller inte. Men de kommer väldigt tydligt klargöra det när det inte fungerar som de vill.
| Service-level agreement (SLA): Ett avtal med kunder som specificerar förväntningar på systemet så som upptid, svarstid på frågor, svarstid på incidenter och buggar, vilka tider på dygnet systemet förväntas vara nåbart m.m. |
Här behöver vi ta en kort paus för att göra en avstickare och nämna high availability architecture. När man sitter och skriver sin disaster recovery-plan kan man komma fram till att även med en bra plan kommer man inte kunna återställa ett system inom det tidsspann som specificeras i avtalet. Då behöver man fundera på om man behöver bygga sitt system för att hantera en hög tillgänglighet, så att systemet fortfarande fungerar när delar av det ligger nere.
| High Availability Architecture Bygger system på en nivå med redundans, så att det fortsätter att fungera även om en server eller till och med ett datacenter går ner. |
När man kör hög tillgänglighet på sina system så händer en del intressanta saker. Man kan till exempel behöva sätta i gång sin disaster recovery-process medan systemet fungerar (om systemet har degraderats till en sådan nivå att man inte längre kan hålla det uppe om degraderingen fortsätter).
Efter den avstickaren hoppar vi till en annan liten avstickare om hur disaster recovery fungerar tillsammans med riskanalyser. När man skriver sina planer kan man komma till sådana incidenter som skulle kunna inträffa, men där risken för det är så låg att det kostar mer att underhålla eller förbereda för den planen än att ta skadeståndet. Man kan då hitta andra vägar i riskanalyser för att i stället minska risken.
De fem riddarna av dåliga nyheter
När man ska skriva sin disaster recovery-plan så är tipset att bara fundera på konsekvenserna. Spara orsaken till händelserapporten. Under en incident så bryr vi oss bara om vad som är sönder och vad som behöver lagas. Många orsaker kan leda till samma konsekvens. Genom att tänka konsekvens har man färre disaster recovery-planer att skriva.
Till exempel: att serverrummet brinner upp eller att serverrummet blir översvämmat får båda samma konsekvens. Du behöver installera ditt system på en ny server som står i en annat serverrum.
De fem kategorier som jag delar in konsekvenserna i är följande:
- Förlust av teknologi
- Förlust av faciliteter
- Förlust av underleverantörer
- Förlust av arbetskraft
- Oförutsedda konsekvenser
Jag bjuder även på en bonus; en sjätte kategori som är för de stackars systemadministratörerna som även måste ratta sin egen hårdvara:
-
Förlust av hårdvara.
Själv har jag alltid haft lyxen att någon annan har rattat det åt mig och därmed ligger ansvaret på att ha en fungerande disaster recovery-plan för hårdvara på dem som hanterar hårdvaran.
Några av er här kanske stannar upp och skriker ut högt "men förlust av data då?". Jag personligen bakar in det i kategorin "Förlust av teknologi". Men om ni har ett datatungt system så är det fritt fram att bryta ut det till sin egen kategori.
Foto: Chuttersnap på Unsplash.
Förlust av teknologi
Vi börjar med den troligtvis största kategorin av de fem, förlust av teknologi. Denna kategori täcker all förlust utav teknologier man använder sig av. Om man har ett stort system kan det bli många olika disaster recovery-planer man behöver skriva.
Några exempel:
- Förlust av VM
- Förlust av mjukvara
- Förlust av databas
Förlust av anläggningar
Denna kategori handlar om förluster av det geografiska område där ditt system driftas. Det kan handla om förlust av en, flera eller alla datahallar. För oss som kör system i molnet kan det vara förlust av en, flera eller alla tillgänglighetsområden (som normalt kallas för availability zones).
Några exempel:
- Förlust av datacenter
- Förlust av tillgänglighetsområden
Förlust av underleverantörer
Underleverantörer är både en guldgruva och huvudvärk. De kan till exempel gå i konkurs, och helt plötsligt kan vi inte utnyttja supportavtalet med dem och de slutar fixa buggar och andra saker vi förlitar oss på att de ska göra. Eller som vi har sett historiskt – de kan bli utsatta för ransomware eller att en felaktig uppdatering pushas ut till deras kunder, det vill säga oss som använder deras system.
Några exempel:
- Konkurs
- Ransomware
- Felaktig uppdatering
Förlust av arbetskraft
Här har vi kategorin som kan vara den svåraste att skriva en plan och förbereda sig för – att man plötsligt förlorar sin arbetskraft. Inom detta område kan man använda den så kallade bussfaktorn. Teorin är ganska simpel, hur många anställda eller konsulter kan du förlora i bussolycka och fortfarande hålla igång arbetet? På många arbetsplatser är siffran förvånansvärt låg. Siffran behöver inte bara appliceras på just en bussolycka utan kan istället vara folk som skadar sig, drastiskt slutar eller som blir sjuka i en ny global pandemi.
I denna kategori är man ganska begränsad i vad man kan göra som systemadministratör och får troligtvis glatt gå till sina chefer och snacka företagspolitik. Ha så roligt.
Men denna kategori handlar inte bara om att förlora medarbetare, det kan vara att man förlorar tillgång till vissa system. Vad händer om man tappar bort certifikatet för att logga in på systemet?
Oförutsedda konsekvenser
Jag vet vad ni tänker. "Vem är det här som tror att man skriva planer för saker man inte har förväntat sig?". Här handlar det om den svarta svanen, det man inte trodde kunde hände förrän det händer. Det man kan göra här är att lista generella saker man ska göra när någon av de andra planerna inte fungerar eller är applicerbara.
Om man hamnar här så är risken stor att man troligen inte kommer klara av sin SLA. Men man ska fortfarande försöka få upp systemet så snabbt som möjligt för minimera skadeståndskraven.
Struktur för en bra disaster recovery-plan
När systemet ligger nere finns det stor risk att den stackaren som behöver få igång det igen är väldigt stressad. Stressade personer glömmer bort saker och kan försöka hitta genvägar – genvägar som kan bli senvägar.
Planerna bör vara nedskrivna på ett sätt som gör det lätt för en stressad person att genomföra dem. Jag rekommenderar att man skriver dem i formatet checklista där varje check är ett steg i formen, till exempel:
- Gå in på denna sida och notera värdet som finns.
- Kör scriptet som finns här. Använd värdet som parameter.
I början av varje plan kan jag även rekommendera att ha två olika fält. Ena fältet säger när planen senast har testats. System har ofta en fortsatt utveckling och man behöver testa och verifiera att stegen i planerna fortfarande funkar. Det andra fältet visar kvalitén på planen. Låt någon följa stegen och göra en recovery. Gick det bra? Fanns det några otydligheter eller fanns det områden som behöver träning och inte räcker med steg beskrivna i text?
Avslutande ord
När krisen inträffar kommer ni vara glada över att ni har en bra och organiserad disaster recovery-plan som går att förlita sig på. Det kommer spara er både tid och inkommande skadeståndskrav. En viktig del av ett företags arbete handlar inte bara om att öka vinsten, utan också om att behålla den vinst man redan har.
Glöm inte att också fysiskt skriva ut er disaster recovery-plan! Den är värdelös om systemet ni har sparat den i också ligger nere. Troligtvis har ert dokumentsystem lägre SLA än era affärssystem.
