Vad är platform engineering? En praktisk guide för team
Summary
Vad är platform engineering? Det är att bygga och driva en intern plattform där utvecklare själva får miljöer, pipelines, tjänster och skyddsräcken utan att skicka ärenden. Ett litet team behandlar vägen från idé till produktion som en produkt, och utvecklarna är kunderna. Här går vi igenom vad ett plattformsteam bygger, hur det skiljer sig från DevOps och SRE och när det lönar sig.
Vad är platform engineering i praktiken? Det är att bygga och driva en intern plattform som ger utvecklare självbetjäning till allt de behöver för att leverera mjukvara: miljöer, pipelines, tjänster, dokumentation och skyddsräcken. Ett litet team behandlar vägen mellan "jag har en idé" och "det körs i produktion" som en produkt, och utvecklarna är dess kunder. Målet är mindre väntan, färre ärenden och färre verktyg att lära sig.
Du har troligen redan upplevt problemet. En ny tjänst behöver ett repo, en pipeline, en databas, hemligheter, dashboards och en jourlista, och varje del ligger bakom en egen wikisida eller en person i Slack.
Varför uppstod platform engineering överhuvudtaget?
"Du bygger den, du driver den" fungerade bra när ett team ägde en tjänst och en handfull verktyg. Det slutade skala när verktygskedjan växte till Kubernetes, Terraform, tre CI-system, en hemlighetshanterare, ett service mesh och en observabilitetsstack. Varje produktutvecklare förväntades nu vara en deltidsinfrastrukturingenjör.
Kostnaden syns som kognitiv belastning, inte som en rad i en budget. En utvecklare som behöver 90 minuter för att ta reda på vilket Helm-chart som är det "rätta" har inte saktats ner av brist på kompetens. Hen har saktats ner av brist på standardval.
Platform engineering är korrigeringen. I stället för att be varje team sätta ihop samma stack från noll bygger ett dedikerat team den en gång, gör den till det enkla valet och håller den i gott skick. Analytiker ser samma tryck: Gartner förväntar sig att 80 procent av stora mjukvaruorganisationer har plattformsteam för platform engineering år 2026, upp från 45 procent 2022.
Vad bygger ett plattformsteam egentligen?
Strunta i leverantörernas diagram ett ögonblick. I de flesta företag levererar ett plattformsteam fyra saker.
En intern utvecklarplattform (IDP). Uppsättningen självbetjäningsverktyg och arbetsflöden ovanpå din molnmiljö och ditt CI. Det kan vara en Backstage-portal, en leverantörsprodukt eller ett väl underhållet repo med mallar och en CLI.
Golden paths. Åsiktsstyrda, supportade vägar för vanliga uppgifter, till exempel "skapa en ny API-tjänst" eller "lägg till en kö".
Skyddsräcken. Policy, skanning och kostnadsgränser som gäller som standard, så att det säkra alternativet också är det lata.
Dokumentation och upptäckbarhet. En katalog som svarar på "vem äger den här tjänsten, var finns runbooken och vad är den beroende av?"
Inget av detta kräver en ny produktkategori. Många bra plattformar började som en cookiecutter-mall och en README som någon höll uppdaterad.
Vad är en golden path, och varför ignorerar team dem?
CNCF beskriver en golden path som en "templated composition of well-integrated code and capabilities for rapid project development", en definition som Google Cloud går igenom med ett Spring Boot-exempel. Med enkla ord är det en mall som ger en ny tjänst repo, pipeline, loggning och deploy-konfiguration redan första dagen.
Felbilden är lika enkel. En väg som ingen bad om, byggd utan att prata med de team som ska gå den, ligger på en adoption i enstaka procent medan plattformsteamet undrar varför utvecklarna fortsätter att öppna ärenden. Vägen måste vara kortare än kringlösningen, annars väljer folk kringlösningen.
Två regler håller golden paths levande:
Belagd, inte inhägnad. Utvecklare får lämna vägen, men de tar själva supportansvaret för det de bygger utanför den.
Ägd som en produkt. Någon läser feedbacken, följer adoptionen och tar bort vägar som ingen använder.
Är platform engineering bara DevOps med nytt namn?
Delvis, och det ärliga svaret är mer användbart än marknadsföringens. DevOps är en kultur: gemensamt ägarskap mellan utveckling och drift, korta återkopplingsslingor. Platform engineering är ett sätt att göra den kulturen hållbar i stor skala genom att förvandla upprepat driftarbete till en produkt.
SRE är en annan disciplin igen. SRE:er sätter tillförlitlighetsmål, mäter dem och bestämmer när man ska sluta leverera för att skydda dem. Ett plattformsteam bygger den belagda vägen. Ett SRE-team säger hur mycket risk du har råd med på den.
DevOps är en kultur och en uppsättning metoder. Resultatet är gemensamt ägarskap och automation, och det brukar misslyckas genom att bli en jobbtitel och en ärendekö.
SRE är en tillförlitlighetsdisciplin. Resultatet är SLO:er, felbudgetar och en incidentprocess, och det brukar misslyckas genom att bli en jourlista utan befogenheter.
Platform engineering är ett internt produktteam. Resultatet är en självbetjäningsplattform och golden paths, och det brukar misslyckas genom att bli en plattform som ingen använder.
Felbilderna är den del att läsa två gånger. Ett plattformsteam som tar emot ärenden och bygger allt som efterfrågas är ett omdöpt driftteam, och det ärver alla gamla köproblem.
När är ett plattformsteam värt bemanningen?
Hoppa över det om du har färre än cirka 30 ingenjörer och en eller två tjänster. I den storleken klarar en bra mallrepo och en delad Terraform-modul jobbet, och ett heltidsbemannat plattformsteam blir overhead. Några personer i ett team på tio blir tyst plattformen ändå, och det är helt okej.
Det börjar löna sig när du ser samma signaler upprepa sig:
Nya tjänster tar veckor att nå produktion, mest för att de väntar på andra.
Tre team har löst samma deploy-problem på tre olika sätt.
Att onboarda en ny ingenjör innebär en hög tyst kunskap och mycket "fråga Priya, hon vet".
Säkerhets- och compliancegranskningar sker i slutet, per team, för hand.
Den minsta användbara versionen är det Team Topologies kallar den tunnaste livsdugliga plattformen: precis tillräckligt för att ta bort den största upprepade smärtan, väl dokumenterat och inget mer. Börja med det arbetsflöde som kostar flest timmar över team, oftast "skapa en ny tjänst" eller "skaffa en förhandsvisningsmiljö".
Feature management är ett bra exempel på en förmåga som är billigare som delad tjänst än som tio privata.
En flaggtjänst som alla team kan anropa, med samma granskningsspår och samma städregler, sparar varje team från att bygga ett eget halvfungerande toggle-system. Oavsett om du köper eller bygger den hör den hemma på plattformen och inte i varje repo.
Vad har en plattform med att läsa kod att göra?
Mer än diagrammen erkänner. En plattform är bara så användbar som kunskapen runt den. När en utvecklare frågar "hur autentiserar tjänst A mot tjänst B?" finns svaret i kod, konfiguration och en runbook som kanske är sex månader gammal.
Här bränner plattformsteam tyst bort tid. De är de som får Slack-frågan som börjar med "var är X konfigurerat?" och svarar från minnet, igen, för femte gången den här veckan. Effekten syns när ett repo växer förbi 80 000 rader och plattformsteamet blir ett mänskligt sökindex.
Några verktyg hjälper här, och de löser olika halvor av problemet. Docs-as-code-verktyg håller den skrivna delen nära källkoden.
Kodmedvetna assistenter svarar på frågor om själva koden. Sourcegraphs assistent riktar sig mot stora organisationer med många repon och säljs till företag på offert, så den passar plattformsteam i stora miljöer bättre än ett team på femton personer.
För vardagsarbetet i editorn täcker en generell assistent mycket, med förbehållet att den bara känner till den kontext du ger den.
Mönstret vi skulle kopiera: lägg golden path-mallarna, ägarkatalogen och ett sökbart index över koden på samma ställe, och låt nya ingenjörer ställa sina frågor där innan de frågar en person. Det går också att mäta i timmar. Om plattformsteamet får färre än tio frågor om "var är det här konfigurerat" i veckan efter att du gjort det, så fungerade det.
Hur börjar man utan att bygga en katedral?
De flesta plattformssatsningar som misslyckas gör det genom att börja med verktyget. Den bättre ordningen är människor, sedan vägar, sedan verktyg.
Intervjua tio utvecklare. Fråga var de förlorar tid mellan en mergad PR och en körande funktion. Du kommer att höra samma tre svar.
Välj en väg och leverera den inom en månad. En enda mall för "ny tjänst" som fungerar från början till slut slår en portal med 40 tomma rutor.
Mät före och efter. Följ tiden till första deploy för en ny tjänst och tiden till första mergade PR för en ny medarbetare. De två siffrorna säger mer än någon nöjdhetsenkät.
Publicera en färdplan och en changelog. Plattformsarbete är osynligt om du inte gör det synligt.
Ta bort saker. Pensionera vägar och verktyg som ingen använder. En mindre plattform som folk litar på slår en större som de går runt.
Motstå lusten att köpa en portal först. En portal ovanpå ett rörigt set arbetsflöden ger dig en snyggare röra, och en katalog med 247 poster, varav hälften är inaktuella, är värre än ingen katalog alls.
Vad går fel, och hur upptäcker du det tidigt?
Tre felmönster återkommer gång på gång.
Helpdesk-plattformen. Förfrågningar kommer via ärende, teamet utför dem för hand och kallar det självbetjäning. Test: kan en utvecklare slutföra den vanliga uppgiften utan att prata med någon?
Mandatplattformen. Ledningen beordrar alla team till plattformen innan den är bra. Adoptionssiffrorna ser fantastiska ut och stämningen rasar. Låt användningen förtjänas under de första sex månaderna.
Allt-plattformen. Varje förfrågan blir en funktion, ytan växer och kvaliteten sjunker. Säg nej, skriftligt, med skäl.
En användbar tidig varningssignal är förhållandet mellan Slack-frågor och dokumenterade svar. Om samma fråga dyker upp tre gånger på en månad och det varken finns dokument, mall eller automation för den, är det nästa punkt i backloggen.
Att göra det på måndag innebär i praktiken att välja det som slösar mest tid över team och göra det tråkigt. För de flesta företag är det att skapa en ny tjänst eller få en testmiljö. Skriv vägen, lägg den där folk hittar den, räkna timmarna den sparar och bestäm först sedan om du behöver ett större team.
Platform engineering är inte en verktygskedja du installerar. Det är ett beslut att behandla interna utvecklare som kunder, och beviset på att du fattade beslutet är en kortare sträcka mellan en ny medarbetares första dag och hens första mergade ändring.