De fem pelarna i effektiv molndrift

Vi strukturerar molndrift kring fem samverkande pelare. Missar du en, kompenserar inte de andra.

Automatisering och Infrastructure as Code

IaC är inte valfritt i seriös molndrift. Varje manuell ändring i en molnkonsol är en skuld – en konfiguration som inte kan reproduceras, granskas eller rullas tillbaka. Terraform har etablerat sig som branschstandard för multicloud-miljöer, medan Pulumi erbjuder ett alternativ för team som föredrar att skriva infrastruktur i Python, TypeScript eller Go.

Det vi ser fungera i praktiken:

• Git som single source of truth – all infrastrukturkod versionshanteras, granskas via pull requests och appliceras via CI/CD-pipeline
• Modulär design – återanvändbara moduler per tjänst, inte monolitiska Terraform-konfigurationer
• Policy as Code – verktyg som Open Policy Agent (OPA) eller Sentinel som validerar att infrastruktur uppfyller säkerhetskrav innan den provisioneras
• Drift detection – automatiserade kontroller som identifierar avvikelser mellan önskad och faktisk konfiguration

Managerad DevOps

Observerbarhet – mer än övervakning

Övervakning berättar att något är fel. Observerbarhet berättar varför. Distinktionen är kritisk i distribuerade molnmiljöer där en enda användarförfrågan kan passera tiotals mikrotjänster.

Observerbarhet bygger på tre signaltyper:

1. Mätvärden (metrics) – numeriska tidsserier: CPU, latens, felfrekvens, ködjup

2. Loggar – strukturerade händelser från applikationer och infrastruktur

3. Spårning (traces) – en förfrågans väg genom systemet, end-to-end

OpenTelemetry har blivit den de facto-standarden för instrumentering och stöds av alla stora observerbarhetsplattformar. Enligt CNCFs Annual Survey är adoption av OpenTelemetry i kraftig tillväxt bland organisationer som kör Kubernetes i produktion.

Opsios perspektiv: Det vanligaste problemet vi ser är inte brist på data – det är för mycket data utan kontext. Hundratals larm som triggrar varje vecka, varav 95 % är brus. Effektiv observerbarhet handlar om att korrelera signaler och eskalera det som faktiskt kräver mänsklig uppmärksamhet.

Säkerhet och regelefterlevnad

Molnsäkerhet är inte ett lager du lägger på efteråt. Det måste vara inbyggt i varje steg: från hur infrastruktur provisioneras (IaC med säkerhetspolicyer), via hur åtkomst hanteras (minsta möjliga behörighet, zero trust), till hur incidenter detekteras och hanteras.

NIS2-direktivet ställer nu explicita krav på organisationer inom essential och important entities. I praktiken innebär det:

• Riskanalys och dokumenterade säkerhetsrutiner
• Incidentrapportering till myndigheter inom 24 timmar
• Ledningens personliga ansvar för cybersäkerhet
• Supply chain-säkerhet – inklusive er molnleverantör och MSP

GDPR (särskilt artiklarna 25, 32 och 35) ställer krav på dataskydd by design, lämpliga tekniska och organisatoriska åtgärder samt konsekvensbedömningar. Integritetsskyddsmyndigheten (IMY) har de senaste åren aktivt granskat svenska organisationers molnanvändning.

Praktiskt: Vi rekommenderar att köra alla produktionsarbetsbelastningar med europeiskt dataresidens – AWS eu-north-1 (Stockholm), Azure Sweden Central eller GCP europe-north1 (Hamina). Det förenklar GDPR-efterlevnad och eliminerar Schrems II-diskussioner för huvuddelen av er data.

Molnsäkerhet

FinOps – kostnadshantering som kultur

Flexeras State of the Cloud har konsekvent visat att kostnadshantering rankas som den enskilt största utmaningen för organisationer med molninfrastruktur. Det handlar sällan om att molnet är för dyrt – det handlar om att ingen har kontroll.

FinOps är inte ett verktyg, det är en driftdisciplin med tre faser:

1. Inform – synliggör kostnader per team, tjänst och miljö. Tagga allt

2. Optimize – rightsizing, reserved instances, savings plans, spot-instanser för feltoleranta arbetsbelastningar

3. Operate – löpande governance med budgetar, anomalidetektering och kostnadsansvar i teamen

Vanliga besparingsåtgärder vi implementerar:

• Automatisk nedstängning av utvecklingsmiljöer utanför arbetstid (sparar typiskt 60–70 % av dev/test-kostnaden)
• Rightsizing baserat på faktisk användning, inte uppskattningar
• Migrering till Graviton/ARM-baserade instanser på AWS – bättre prestanda per krona
• Spot-instanser för batchbearbetning och CI/CD-runners

Cloud FinOps

Incidenthantering och SRE-principer

Site Reliability Engineering (SRE), som Google formaliserade, har gett branschen ett ramverk för att behandla drift som en ingenjörsdisciplin. Kärnidén: istället för att sikta på 100 % tillgänglighet (som är oändligt dyrt) definierar du error budgets – hur mycket otillgänglighet du tolererar.

En effektiv incidentprocess ser ut så här:

1. Detektion – automatiserade larm baserade på SLI:er (Service Level Indicators), inte godtyckliga tröskelvärden

2. Eskalering – tydlig on-call-rotation med definierade eskaleringssteg

3. Respons – dokumenterade runbooks för kända scenarion, war rooms för okända

4. Återställning – fokus på att återställa tjänsten först, rotkausanalys efter

5. Postmortem – blameless genomgång som resulterar i konkreta åtgärder

I Opsios 24/7 SOC/NOC hanterar vi incidenter för kunder som varken har volymen eller budgeten att bemanna en egen dygnet runt-funktion. Det kritiska är inte vem som sitter med övervakningen, utan att processen finns, fungerar och förbättras.

Multicloud och hybridmiljöer: verklighet kontra vision

De flesta organisationer kör multicloud – men ofta av misstag snarare än strategi. Ett förvärv tog med sig Azure, utvecklingsavdelningen valde GCP för ML och produktionssystemen kör på AWS. Plötsligt har du tre molnplattformar utan gemensam driftmodell.

Medveten multicloud innebär gemensamma lager för:

• Identitet och åtkomst – centraliserad IAM via exempelvis Azure AD / Entra ID eller Okta
• Observerbarhet – en plattform som korrelerar data från alla molnleverantörer
• IaC – Terraform som abstraktionslager (men var realistisk – leverantörsspecifika funktioner kräver leverantörsspecifik kod)
• Kostnadshantering – aggregerad vy, inte tre separata dashboards

Managerade molntjänster

Kubernetes i driftperspektiv

Kubernetes har blivit standardplattformen för containerorkestrering, men driftkomplexiteten är betydande. CNCFs Annual Survey visar att adoption fortsätter växa, men att operativ mognad varierar kraftigt.

Våra rekommendationer:

• Använd managerad Kubernetes (EKS, AKS, GKE) om ni inte har en dedikerad plattformsgrupp. Att drifta ett eget kontrollplan är sällan värt insatsen.
• GitOps med Flux eller Argo CD – deklarativ deploy via Git, inte manuella kubectl-kommandon
• Resurslimiter på alla pods – utan dem får ni noisy neighbor-problem och oförutsägbara kostnader
• Uppgradera regelbundet – Kubernetes släpper nya versioner tre gånger per år och stöder typiskt de senaste tre versionerna

Molnmigrering

Hur du kommer igång – en pragmatisk väg

Att omvandla molndriften sker inte över en natt. Här är en sekvens som fungerar:

Månad 1–2: Grundläggande hygien

• Implementera konsekvent taggning av alla resurser
• Aktivera grundläggande övervakning och larm
• Dokumentera er nuvarande arkitektur

Månad 3–4: Automatisering

• Migrera befintlig infrastruktur till IaC (börja med nya resurser, importera befintliga gradvis)
• Etablera CI/CD-pipelines för applikationsdeploy
• Inför policy-as-code för säkerhetsbaslinjer

Månad 5–6: Optimering

• Starta FinOps-praxis med veckovisa kostnadsgenomgångar
• Implementera rightsizing-rekommendationer
• Etablera incidenthanteringsprocess med on-call-schema

Löpande: Mognad

• SLO/SLI-baserad övervakning
• Blameless postmortems efter varje incident
• Regelbundna spelövningar (game days) för att testa motståndskraft

Vanliga frågor

Vad är skillnaden mellan molndrift och traditionell IT-drift?

Traditionell IT-drift utgår från fysisk infrastruktur med långa ändringsprocesser. Molndrift bygger på programmerbara resurser, API-styrd automatisering och en tjänstemodell där du betalar per förbrukning. Tempot är högre, feedbacklooparna kortare och ansvarsfördelningen mellan leverantör och kund (shared responsibility) är fundamental.

Hur börjar man med FinOps i praktiken?

Starta med att tagga alla resurser konsekvent – per team, tjänst och miljö. Aktivera Cost Explorer eller motsvarande verktyg i er molnplattform. Inför veckovisa kostnadsgenomgångar med ansvariga team. Nästa steg är att automatisera nedstängning av oanvända resurser och implementera reserved instances eller savings plans för förutsägbara arbetsbelastningar.

Vilka verktyg behövs för molndrift?

Grundstacken inkluderar IaC-verktyg (Terraform eller Pulumi), CI/CD-plattform (GitHub Actions, GitLab CI), observerbarhetsplattform (Datadog, Grafana + Prometheus), SIEM för säkerhet och ett kostnadshanteringsverktyg. Exakt val beror på er molnplattform och mognadsnivå.

Måste vi ha ett eget NOC/SOC för molndrift?

Inte nödvändigtvis. Många organisationer saknar volymen för att bemanna dygnet runt. En managerad tjänsteleverantör (MSP) med 24/7 SOC/NOC kan ge samma eller bättre täckning till lägre kostnad. Det viktiga är att incidenthantering, eskalering och övervakning faktiskt fungerar – inte var teamet sitter.

Hur påverkar NIS2 vår molndrift?

NIS2-direktivet, som trätt i kraft i EU, ställer krav på riskhantering, incidentrapportering inom 24 timmar och ledningsansvar för cybersäkerhet. I praktiken innebär det att er molndrift behöver dokumenterade processer, automatiserad loggning, regelbundna säkerhetsgranskningar och en incidenthanteringsplan som faktiskt testas.