Tankeledare
Börja förbereda dig nu för nästa molnavbrott

Stora molnincidenter som den vi såg denna vecka är oundvikliga. Dessa fyra metoder kan hjälpa ditt företag att hantera situationen.
Med otaliga timmar av förlorad produktivitet, finansiella system som störts för miljontals användare, och potentiellt hundratals miljarder dollar förlorade, var denna veckas AWS-avbrott en obehaglig dag för globala IT-team. Det var förstås också den värsta globala molnkatastrofen sedan den senaste… och till den nästa.
Oavsett om du använder AWS, GCP, Azure eller någon annan plattform, är stora avbrott en del av molnverkligheten. Vad kan ditt företag göra för att mildra effekterna? Nedan kommer jag att ge fyra steg som ditt team kan vidta omedelbart.
Var skeptisk – och gör din läxa.
Ofta går team mot katastrof genom att gå in i molnavtal med antagandet att stora molnföretag är inhämtat pålitliga. Det är sant att de mest pålitliga företagen har förtjänat sin rykte av en anledning. Samtidigt erbjuder varje moln och hyperscaler ett brett utbud av infrastrukturalternativ – AWS Nordamerika har 31 tillgänglighetszoner och 31 Edge-nätverksplatser – och vissa alternativ är betydligt mer tillförlitliga än andra.
Faktum är att AWS: s US-EAST-1-region, som orsakade denna veckas avbrott, hade varit bakom stora störningar 2020, 2021 och 2023, och det var länge känt i vissa IT-kretsar som den minst tillförlitliga regionen. Många företag förstod förmodligen situationen men tog en kalkylerad risk med tanke på regionens låga kostnad och rikliga utbud. Men med tanke på avbrottets omfattning är det omöjligt att inte fundera på hur många företag som togs helt på sängen – och skulle ha valt de mer tillförlitliga regionerna om de hade varit medvetna om kompromissen. Jag har personligen träffat IT-chefer som valde att flytta till andra AWS-regioner efter dåliga upplevelser med US-EAST-1 i det förflutna.
Lektionen här är att göra din läxa när det gäller molninfrastrukturalternativ, oavsett vilket moln du arbetar med. Platser att börja på inkluderar gratisverktyg som cloudprice, Cloudping, och de historiska incidentvyerna från hyperscaler-tillhandahållna Cloud Service Health-verktyg.
Välj portabelt över molntillverkat.
När du konstruerar molnkonfigurationer är den enklare vägen att gå molntillverkat. Men medan det är bekvämt att välja applikationer som är färdigbyggda av och för din molntjänst, lämnar dessa molntillverkade alternativ dig mer utsatt om ditt moln går ner.
För att undvika den extra lagern av molnberoende, välj oberoende och/eller öppen källkodsprodukter där det är möjligt. Några exempel på ersättningar inkluderar de nedan:
|
Kategori |
Inbyggt erbjudandeexempel |
Öppen källkodsalternativ inkluderar… |
|
Autentisering och identitet |
AWS Cognito |
Keycloak |
|
Sökning |
Azure Monitor |
Elasticsearch |
|
Relationella databaser |
Google Cloud SQL |
PostgreSQL |
|
NoSQL-databaser |
AWS DynamoDB |
MongoDB |
|
Containerorkestrering |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Övervakning och observerbarhet |
Google Cloud Monitoring |
Prometheus + Grafana |
|
Meddelandeköer |
AWS SQS/SNS |
Apache Kafka |
|
Objektlagring |
Azure Blob Storage |
MinIO |
|
API-gateway |
Google Cloud API Gateway |
Kong |
Det är sant att bygga mer av din molnstapel från grunden innebär mer arbete för dina team. Men i min erfarenhet, när du har infrastrukturen uppe och körs, finns det lite eller ingen skillnad mellan att lägga till arbetsbelastning till en etablerad hemmagjord infrastruktur eller att köra på en molntillverkad. Och fördelarna i form av motståndskraft – för att inte tala om minskat molnbundet – gör oberoende alternativ mycket värdefulla.
Konstruera för fel.
Med tanke på att molnfel kommer att ske, se till att konstruera dina produkter med molnfel i åtanke. Ett exempel att titta på är Datadog: i en incident 2023 förlorade företaget plötsligt åtkomst till över hälften av sina Kubernetes-noder i produktion och omkonstruerade helt sin katastrofmetod som svar. Förändringar inkluderade att ta bort arkitektoniska flaskhalsar och hantera teknisk skuld så att partiella fel inte skulle skapa en kedjereaktion genom systemet, förbättra datainmatning och lagring för ökad datatillgänglighet under avbrott, och bygga system för att automatiskt återhämta sig i stor skala. En bra plats att börja på är att följa Datadogs rekommendation att “börja med vad som är viktigt för slutanvändaren” och bygga säkerhetsåtgärder för att skydda det som är viktigast.
Kör på minst två moln.
Det bästa sättet att inte vara beroende av molnfel är molnredundans. Att uppnå sann molnfluiditet är en enorm uppgift för många företag, eftersom det är extremt svårt att översätta infrastruktur från ett moln till ett annat. Men att bygga ut infrastruktur på bara två moln är en stark – och ofta genomförbar – plats att börja på. Kritiskt för att göra detta är att ha ett team på plats med en expert inom varje moln som du kör på.
Det är sant att ingenting kan skydda företag helt från effekterna av ett massivt avbrott som det vi såg denna vecka. Men med rätt due diligence, en molnportabel approach, konstruktion för fel och användning av “dual-cloud” som en trappsteg till sann moln, kan företag vara betydligt mer smidiga när nästa stora molnincident slår till.












