Den senaste incidenten med Google Cloud i London är just den typ av händelse som borde få företag att ompröva vad motståndskraft i molnet egentligen innebär. Google uppgav att störningen orsakades av ett ”strömavbrott” som drabbade datacenter i London inom regionen europe-west2. Problemet uppstod tidigt på dagen och påverkade molntjänster som många organisationer är beroende av, antingen direkt via sina egna installationer eller indirekt via tredjepartsplattformar som körs på Google Cloud.
Det som gjorde denna incident betydelsefull var inte bara att en molnregion hade problem. Molninfrastruktur kan, precis som all annan infrastruktur, drabbas av fel. Det verkliga problemet var omfattningen av beroendekedjan. Banker, leveranstjänster, leverantörer av elcyklar, budgeteringsappar, vissa bokningstjänster via National Health Service-appen samt domstolarnas videolänksystem drabbades alla av störningen. Dessa tjänster kan verka helt oberoende av varandra, men i själva verket kan de dela samma underliggande molnleverantörer, regional infrastruktur, hanterade tjänster, nätverk, identitetssystem, API:er och operativa beroenden.
Google uppgav senare att tjänsterna hade återställts för de flesta drabbade arbetsbelastningarna, och att endast ett litet antal kunder fortfarande påverkades. Skadan var dock redan skedd. Händelsen visade hur mycket moderna företag är beroende av molnplattformar som är mycket kapabla men inte immuna mot fel. Den visade också att resiliens inte är något som företag automatiskt får genom att byta till en hyperscaler. En resilient arkitektur måste utformas, finansieras, testas och ägas.
Ta inte resiliens för givet
Många företag betraktar fortfarande resiliens i publika moln som ett problem för leverantören. De antar att eftersom en arbetsbelastning körs på en stor molnplattform är den i sig själv resilient. Det är en farlig antagande. Leverantörer av publika molntjänster erbjuder visserligen imponerande resiliensfunktioner. De tillhandahåller flera regioner, tillgänglighetszoner, hanterade databaser, replikeringsverktyg, lastbalansering, hållbarhet för objektlagring, säkerhetskopieringstjänster, övervakning och automatiserade återställningsalternativ. Men detta är byggstenar. De utgör inte en färdig resiliensstrategi.
Leverantören ansvarar för molnplattformens tillförlitlighet. Företaget ansvarar för hur dess applikationer använder den plattformen. Denna distinktion missförstås ofta. Om en applikation driftsätts i en enda region, är beroende av en hanterad databas, använder en identitetsväg och saknar en testad failover-process, kan molnleverantören inte på magisk väg göra den applikationen motståndskraftig. Leverantören kan återställa den underliggande infrastrukturen, men företaget äger fortfarande applikationsarkitekturen och driftsmodellen.
Det är här många molnprogram brister. Företag migrerar applikationer till det publika molnet och antar att diskussionen om resiliens är avslutad. I verkligheten kan de ha flyttat den enda felkällan från sitt eget datacenter till någon annans regionala infrastruktur. Plattformen är bättre, men utformningen kan fortfarande vara sårbar.
En växande beroendekedja
Molnresiliens har blivit svårare eftersom företagssystem numera är djupt sammankopplade. En typisk modern applikation består av en samling hanterade tjänster, API:er, identitetsplattformar, datalager, meddelandeköer, verktyg för observabilitet, distributionspipelines, säkerhetskontroller och integrationer från tredje part.
Detta skapar dolda risker. Ett företag kan tro att det har byggt en resilient applikation eftersom beräkningarna körs över flera zoner. Men databasen kan vara regional. Identitetsleverantören kan vara otillgänglig. DNS kan kräva manuellt ingripande. Ett betalnings-API från tredje part kan sluta fungera. Loggning och övervakning kan sluta fungera under incidenten. Säkerhetskopian kan finnas, men kanske inte har återställts på flera månader. Failover-processen kan vara beroende av en person som inte är tillgänglig.
Detta är det nya problemet med molnresiliens. Felet beror sällan bara på en enda server, en enda disk eller en enda nätverksenhet. Felet är ofta en kedja av beroenden. Företag måste inte bara förstå var applikationerna körs, utan också vad de är beroende av för att fungera. Ett verkligt program för motståndskraft börjar med att kartlägga beroenden på en praktisk nivå. Vilka tjänster är zonbaserade, regionala eller globala? Vilka är beroende av en leverantörs kontrollplan? Vilka tjänster från tredje part delar samma molnleverantör eller region? Vilka arbetsbelastningar kan fortsätta i nedsatt läge? Vilka stannar helt?
Utan den kartläggningen får företagen bara gissa.
Multicloud är ingen genväg
När avbrott i publika molntjänster inträffar är den reflexmässiga reaktionen ofta: ”Vi behöver multicloud.” Ibland stämmer det. Ofta är det en kostsam distraktion.
Multicloud kan minska beroendet av en enskild leverantör, men det kan också medföra en komplexitet som kan försämra motståndskraften. Att köra samma arbetsbelastning i två moln kräver duplicerad arkitektur, datareplikering, enhetliga säkerhetspolicyer, nätverkssamverkan mellan molnen, personal med rätt kompetens, styrning, övervakning, automatiserad driftsättning och processer för incidenthantering. Om dessa funktioner inte är fullt utvecklade blir multicloud till en spridd sårbarhet.
Det bättre svaret är arbetsbelastningsspecifik motståndskraft. Inte alla system behöver en aktiv-aktiv driftsättning över flera leverantörer. Vissa arbetsbelastningar kräver en arkitektur som spänner över flera regioner inom en och samma leverantör. Andra behöver aktiv-passiv failover. Vissa kräver stark säkerhetskopiering och återställning. Vissa kan tolerera timmar av driftstopp med minimal påverkan på verksamheten.
Företag bör klassificera applikationer efter hur affärskritiska de är. Kundorienterade system, intäktsplattformar, betalningar, logistik, klinisk verksamhet, identitetstjänster och regleringsrelaterade arbetsflöden kräver vanligtvis högre motståndskraft. Intern rapportering, utvecklingssystem och arbetsbelastningar med liten påverkan motiverar kanske inte samma investering.
Testning och ännu mer testning
En resiliensplan som inte har testats är bara en teori. Många företag har arkitekturdiagram som visar failover-vägar som aldrig har testats. De har säkerhetskopior som aldrig har återställts. De har återställningsmanualer som bygger på föråldrade steg. De har eskaleringsvägar som ser bra ut på papper men som misslyckas vid en faktisk incident.
Det är genom testning som motståndskraften blir verklig. Företag bör genomföra kontrollerade felövningar. De bör testa regional failover. De bör återställa produktionsliknande data från säkerhetskopior. De bör simulera förlusten av en hanterad tjänst, en identitetsleverantör, en nätverksväg eller ett API från tredje part. De bör mäta den faktiska återställningstiden istället för att förlita sig på antaganden.
Dessa tester avslöjar ofta att den svagaste delen av systemet är driftsmodellen, inte molnplattformen. Teamen kanske inte vet vem som kan godkänna failover. Företagsledare kanske inte vet hur ett nedsatt driftsläge ser ut. Ingenjörer kanske inte har behörighet att genomföra akuta ändringar. Övervakningen kanske inte visar den verkliga påverkan på kunderna. Kommunikationsteamen kanske inte har förberett vad de ska säga till kunder eller tillsynsmyndigheter.
Molnresiliens är både teknisk och organisatorisk. Arkitekturen är viktig, men det är även beslutsrätt, driftsmanualer, bemanning, kommunikation och praxis.
Kostnaden måste vara tydlig
Bättre motståndskraft kostar pengar. Driftsättning i flera regioner, replikerade databaser, ytterligare övervakning, trafikhantering, lagringsutrymme för säkerhetskopior, testmiljöer och kompetent driftspersonal ökar alla molnkostnaderna. Denna kostnad bör inte döljas eller betraktas som slöseri. Jämför den med kostnaden för driftstopp. Vad kostar en timmes driftstopp? Vad händer om kunderna inte kan komma åt sina pengar, genomföra köp, boka tid, skicka produkter eller använda kärntjänster? Vilka är de regulatoriska riskerna? Vilken skada åsamkas företagets anseende? Vilka avtalsenliga påföljder gäller? Vilka manuella lösningar finns, och hur länge kan de skalas upp?
När du har besvarat dessa frågor blir det lättare att motivera investeringar i resiliens. Vissa system förtjänar kostsamma lösningar. Andra gör det inte. Men åtminstone kommer beslutet att vara väl genomtänkt. Det värsta utfallet är oavsiktlig underinvestering, där ett affärskritiskt system har låg resiliens helt enkelt för att ingen har beräknat kostnaden för risken.