Att flytta från "det funkar i Kubernetes" till "det håller i produktion"

Vi har alla varit där. Appen snurrar perfekt lokalt i Docker. Man containeriserar den, drar upp en Kubernetes-miljö och plötsligt är den "deployad". Alla är glada.

Sedan kommer verkligheten.

Det som funkar för att visa upp en app är sällan samma sak som krävs när riktiga användare, riktiga data och riktiga problem dyker upp mitt i natten.

Vad som skiljer en utvecklingsmiljö från produktion

En utvecklingskluster och en produktionskluster delar egentligen bara containerhanteraren. Allt annat skiljer sig åt.

I utvecklingsmiljön ser det ofta ut så här:

• Minikube lokalt
• Självsignerade certifikat som bara fungerar på egen maskin
• Testdomäner som *.127.0.0.1.nip.io
• Inloggningsuppgifter i vanliga miljövariabler
• Manuell körning av helm install
• Övervakning som ska komma "senare"
• Backuper som aldrig testats

I produktionen måste man kunna svara på helt andra frågor:

• Hur kör vi deployment utan att någon behöver klicka?
• Var ligger hemligheterna, och vem får tillgång till dem?
• Vad händer om lagringen kraschar?
• Kan vi återställa från backup om något går snett?
• Följer vi säkerhetsregler?
• Ser vi problemen innan användarna gör det?

Dessa saker är inte finesser. De är vad som gör att en app kan användas av ett företag.

En stegvis väg till stabil drift

Att gå från "det funkar på min maskin" till "vi kan driva detta på riktigt" tar en serie av steg. Det handlar inte om nya funktioner – det handlar om att bygga stabilitet.

Steg 1: Grunderna på plats

Man börjar med att få de viktigaste komponenterna att prata med varandra:

• Riktiga domännamn i stället för testdomäner
• En riktig inloggningslösning (OIDC eller SAML)
• Data lagras utanför klustret – databaser och filhantering behöver egna lösningar
• Hantering av hemligheter som inte bygger på YAML-filer i Git

Det här steget syns sällan för användarna. Men utan det blir allt som följer skört.

Steg 2: Appen måste fungera

Nu när grunderna är rätt behöver appen själv klara av att arbeta med dem:

• Inloggning måste fungera från början till slut
• Filuppladdningar måste hamna i stabil lagring
• Caching måste vara stabil och inte timeout
• Trafik måste hanteras på rätt sätt

Det är här man ser att många antaganden från utvecklingsmiljön bryter ner i produktion.

Steg 3: Kontroll över förändringar

Manual helm install blir snart en börda. Man behöver:

• GitOps: klustrets tillstånd beskrivs i Git,而不是 i någon enskilds historia
• Automatisk validering innan deployment sker
• Loggar över vem som gjorde vad och när
• Möjlighet att rulla tillbaka vid problem

GitOps handlar inte bara om att automatisera – det handlar om att säkerställa att varje förändring är granskad, testable och återställbar.

Steg 4: Återställning är möjligt

Det här är ofta en punkt där många team faller. De tror att backuper finns och går vidare.

Backuper är värdelösa om man aldrig har testat att återställa från dem.

Realistisk produktionsberedskap kräver:

• Automatiska backup-scheman för både databaser och konfiguration
• Återställning som regelbundet testas – inte bara en gång
• Tydliga mål för hur snabbt man kan återställa och hur mycket data man kan tillåta att loss
• Dokumenterade förfaranden som inte bero på en persons minne

Steg 5: Se vad som händer

Finally, you need to know what's actually happening:

• Mätningar av appens prestanda, användning av resurser och fel
• Dashboards som visar hälsotillstånd av klustret
• Varningar som väcker rätt person när problem uppstår
• Loggar som kan sökas och behålls tillräckligt länge för att diagnoseera problem

Observability är hur man går från "hoppas" till "vet".