CI/CD, platform engineering och SRE för team som vill leverera ofta och sova gott. Automatiserade pipelines, observability och en intern plattform som utvecklarna faktiskt vill använda.
Ett av de vanligaste missförstånden jag möter är att DevOps handlar om att anställa en 'DevOps-are' eller köpa in ett verktyg. I själva verket är DevOps en uppsättning principer – kortare cykler, automatiserad kvalitet, delat ansvar för drift – som tar olika form i varje organisation. Det jag faktiskt levererar är grunden för att de principerna ska fungera i praktiken: CI/CD-pipelines som gör deployment till en icke-händelse, infrastruktur som kod så att miljöer är reproducerbara, och observability som ger insyn i vad som faktiskt händer i produktion.
Min erfarenhet från dussintals team är att de största vinsterna sällan ligger i att välja rätt teknik. De ligger i att förenkla: färre steg i pipeline, färre miljöer, mindre onödig komplexitet. Ett team som kan deploya till produktion på 15 minuter med full automatisering har vunnit mer än ett team som har den mest avancerade Kubernetes-uppsättningen men ändå måste göra manuella steg vid varje release.
De flesta team jag börjar arbeta med befinner sig på nivån 'vi har en CI-server, men deployment görs manuellt från en utvecklares dator'. Steget därifrån till fullt automatiserad leverans med gröna pipelines som standard är större än många tror – men varje steg ger konkret nytta. Jag delar upp mognadsresan i fyra nivåer: manuell (allt görs för hand), delvis automatiserad (byggen är automatiska, men deployment är manuell), helt automatiserad (pipelines bygger, testar och deployar automatiskt), och slutligen självbetjäning (varje team kan skapa och deploya sina egna mikrotjänster utan att vänta på infrastrukturteamet).
Målet är alltid nivå 4 – men vägen dit går stegvis. För varje steg säkerställer jag att teamet hänger med: dokumentation, workshops och kunskapsöverföring så att mognadsökningen är beständig, inte beroende av en enskild person.
Traditionell övervakning talar om när något är trasigt. Observability – loggar, mätvärden och distribuerad spårning i kombination – talar om varför det är trasigt och vad som ledde fram till det. Skillnaden låter liten men är avgörande för hur snabbt ett team kan återhämta sig från en incident. Utan observability blir felsökning en detektivutredning där varje ny ledtråd kräver att någon manuellt loggar in på en server och letar.
Jag sätter upp observability i lager: först grundläggande loggning och mätvärden (så att ni vet att systemet lever), sedan strukturerad loggning med korrelations-ID:n (så att en användares resa kan följas genom flera tjänster), och slutligen SLO:er och larmtrösklar som triggar på avvikelser, inte på absoluta gränsvärden. Resultatet är ett team som sover bättre – för att de ser problemen innan kunderna gör det.
De organisationer vi arbetar med brottas oftast med minst ett av dessa.
Att få ut en ändring kräver manuella steg, en deploy-ansvarig och en nervös fredag. Teamet vågar inte släppa ofta.
Samma incidenter dyker upp om och om igen. Ingen tid att åtgärda grundorsaken.
Dev, test och prod skiljer sig åt. "Det funkar hos mig" är ett stående skämt - och en risk.
Att få en ny miljö, databas eller pipeline kräver ett ärende och en veckas väntan.
Selektivt urval av uppdrag - där senior teknisk kompetens gör störst skillnad.
Kartläggning av leveransflöde, miljöer och flaskhalsar. Konkret plan för snabbare och tryggare leverans.
Automatiserade bygg-, test- och deploy-pipelines så att releaser blir en icke-händelse.
Container-baserad körmiljö och Kubernetes uppsatt så att den går att drifta - inte bara demonstrera.
Terraform-baserade, identiska miljöer som är reproducerbara och granskningsbara.
Loggning, mätvärden, spårning och larm - plus SLO:er och incidentrutiner som faktiskt används.
Self-service för miljöer, pipelines och resurser så att teamet slutar vänta på infrastruktur.
Tydlig process från första samtalet till levererat resultat.
Förutsättningslöst samtal om leveransflöde, smärtpunkter och mål.
Genomlysning av pipelines, miljöer och incidentmönster. Prioriterad plan.
Pipelines, miljöer och observability byggs stegvis med veckovisa avstämningar.
Dokumentation, kod och kunskapsöverföring. Teamet äger plattformen.
Transparenta upplägg utan dolda kostnader. Alla priser exkl. moms.
Genomlysning av leveransflöde och miljöer med prioriterad åtgärdsplan.
Definierat projekt med tydlig scope - pipelines, miljöer eller intern plattform.
Löpande arbete med plattform, pipelines och observability med prioriterad tillgänglighet.
Läs mer om ämnet i våra artiklar.
Svar på det jag oftast får höra.
Inte nödvändigtvis. Kubernetes är kraftfullt men har en driftkostnad. För många team räcker enklare container- eller serverless-lösningar långt - valet styrs av era faktiska behov.
Ja. Ofta handlar arbetet om att stabilisera och förenkla det som redan finns snarare än att börja om - och att göra det begripligt för hela teamet.
Ja - AWS, Azure och GCP. Pipelines och infrastruktur byggs leverantörsoberoende med Terraform där det går.
Ja. Loggar, mätvärden, spårning och larm sätts upp så att ni ser problem innan användarna gör det - och så att felsökning går snabbt.
Nej - målet är att ert team äger plattformen. Jag bygger, dokumenterar och överför kunskap. Löpande rådgivning kan ske via retainer.
Nästa steg
Har ni en ambitiös idé eller ett tekniskt vägval där det är värt att tänka rätt från början? Hör av er - förutsättningslöst.
Ta kontakt