Kontinuitet och katastrofberedskap i Azure — börja med två siffror

De flesta samtal om katastrofberedskap börjar i fel ände — i tjänster och funktioner. "Ska vi ha geo-replikering? Behöver vi Azure Site Recovery?" Det är rätt frågor, men för tidigt ställda. De två siffror som faktiskt styr designen ställs sällan först: hur länge får systemet vara nere, och hur mycket data får gå förlorad?

RTO och RPO: de två tal allt hänger på

RTO (Recovery Time Objective) är hur lång tid det får ta att få systemet i drift igen efter ett avbrott. RPO (Recovery Point Objective) är hur mycket data verksamheten tål att förlora, mätt i tid — en timmes transaktioner, en dags, en sekunds.

Båda är verksamhetsbeslut, inte tekniska. En orderplattform där ett RPO på en timme innebär förlorade beställningar har helt andra krav än en intern rapportportal som kan byggas om från källdata över en helg. Vår första uppgift är att sätta siffrorna per system — inte ett värde för hela organisationen, utan ett per tjänst efter vad ett avbrott faktiskt kostar.

När siffrorna finns blir resten arkitektur i stället för åsikt.

Backup, hög tillgänglighet och katastrofberedskap är inte samma sak

Tre begrepp blandas ofta ihop, och skillnaden avgör vad man faktiskt får för pengarna:

Hög tillgänglighet (HA) håller systemet uppe genom fel inom en region — en nod som dör, en zon som faller bort. I Azure är det tillgänglighetszoner och zonredundanta tjänster. HA skyddar inte mot att en hel region blir otillgänglig.
Katastrofberedskap (DR) tar över när en hel region faller — genom att kunna köra vidare från en annan geografisk plats.
Backup är din sista utväg mot det HA och DR inte skyddar mot: felaktig data, en borttagen resurs, ett ransomware-angrepp. Replikering kopierar troget även dina misstag; backup låter dig gå tillbaka i tiden.

Ett system kan ha förstklassig HA och ändå sakna både DR och användbar backup. De löser olika problem och behöver var för sig.

Byggstenarna i Azure

Med RTO och RPO satta väljer vi verktyg därefter — inte tvärtom:

Tillgänglighetszoner ger HA inom en region och bör vara utgångspunkten för allt verksamhetskritiskt. Kostnaden är låg i förhållande till skyddet.
Parade regioner och georedundant lagring (GRS/GZRS) replikerar data till en andra region. Grunden för DR när en hel region går ner.
Azure Backup med lämplig lagringstid och oföränderliga (immutable) valv skyddar mot radering och angrepp — inte bara mot maskinvarufel.
Failover-grupper för Azure SQL och motsvarande mönster för andra datatjänster gör återställningen till en styrd övergång i stället för en manuell räddningsaktion under press.
Azure Site Recovery orkestrerar failover för hela arbetslaster där det behövs.

Varje steg upp i den här listan kostar mer i pengar och komplexitet. Poängen är inte att köpa allt, utan att matcha nivån mot vad ett avbrott faktiskt kostar verksamheten. Att skydda en intern portal som ett betalflöde är också ett fel — bara ett dyrare.

En plan du inte har testat är en gissning

Det här är den del som oftast hoppas över, och den enda som avgör om resten var värd något. En återställningsplan som aldrig körts skarpt är inte en plan — det är ett antagande, och antaganden brister just när det gäller.

Vi provar failover på riktigt, planerat och återkommande: mäter det faktiska RTO:t mot målet, verifierar att data faktiskt är intakt vid den återställningspunkt vi lovat, och skriver ner var det skavde. Nästan varje första test avslöjar något — ett beroende ingen tänkt på, en behörighet som saknas i den andra regionen, ett steg i återställningen som bara fanns i någons huvud. Bättre att hitta det på en tisdag än under ett skarpt avbrott.

Var vi brukar börja

När vi går in i en befintlig miljö börjar vi sällan med tekniken. Vi sätter oss med verksamheten och sätter RTO och RPO per system, kartlägger vad som redan finns mot de siffrorna, och gör glappen synliga och prissatta. Därifrån blir katastrofberedskap ett antal medvetna avvägningar i stället för en känsla av att man "nog borde ha bättre backup".

Har ni system där ni inte vet vad ett längre avbrott skulle kosta — eller en plan som aldrig blivit prövad — är det oftast där vi börjar.