Platform engineering för AI-utveckling
Ge människor och agenter stödda sätt att skapa, ändra och drifta tjänster. Behandla plattformen som en underhållen produkt.
Publicerad av TaigaSå skriver vi
Det här lär du dig
- Förklara hur AI förändrar plattformens användare.
- Definiera ett arbetsflöde som plattformen stöder med kontroller och en undantagsväg.
- Skilj en projektmall från en underhållen plattformsförmåga.
Ge prototyper en väg till produktion
Människor kan utforska idéer med olika AI-verktyg medan organisationen ger en gemensam väg till produktion. Plattformsteamet gör vägen tydlig, stödd och upprepningsbar.
Samla användaruppgift, exempelflöde, tillgänglig källkod och avsedda data för en användbar prototyp. Bedöm om koden ska anpassas eller byggas om utifrån lärda krav. Verifiera applikation, utvecklingsverktyg och körmiljö mot nödvändiga kontroller före verkliga autentiseringsuppgifter eller konfidentiell indata.
Om tjänsten måste köras i er infrastruktur ska ni erbjuda stödd driftsättning till era molnkonton eller nätverk. Ta med identitet, hemlighetshantering, releaseunderlag, övervakning och återställning. Granska modellernas dataflöden separat; ägande av körmiljön styr inte varje utvecklingstjänst.
Behandla plattformen som en produkt för användarna
En plattform ger team stödda förmågor att bygga och drifta programvara. De kan omfatta identitet, miljöer, leveranspipelines, databaser, övervakning och policykontroller. Den användbara enheten är ett helt arbetsflöde som möter ett återkommande behov.
CNCF beskriver plattformar som förmågor utformade kring interna användare, med konsekventa gränssnitt och självservice där det passar. En portal kan visa förmågorna, men en portal är inte ensam plattformen. CNCF Platforms White Paper.
Börja med verklig efterfrågan. I ett fiktivt företag behöver flera team en intern webbtjänst med personalinloggning och hanterad databas. Bygg en stödd väg för behovet innan du lägger till en bred katalog av sällan använda funktioner.
Räkna agenter som plattformsanvändare
En AI-agent kan snabbt generera infrastrukturkod. Utan aktuell plattformskontext kan den också välja en region, ett identitetsmönster eller en driftsättningsmetod som saknar stöd. Snabbare generering löser inte saknade organisatoriska begränsningar.
Ge agenten ett tillförlitligt gränssnitt. Definiera indata, tillåtna värden, utdata och felbeteende. Ge exempel som matchar installerad version. Returnera fel som går att agera på utan att exponera hemligheter. Tillämpa samma auktoriseringskontroller på människor och agenter.
För den interna tjänsten kan förfrågan identifiera ansvarig, datakategori, miljö, återställningskrav och stödd körmiljö. Plattformen kan sedan välja en granskad konfiguration eller förklara varför ett separat beslut behövs.
Definiera den stödda vägen och dess gränser
| Förmåga | Plattformens ansvar | Produktens ansvar |
|---|---|---|
| Personalidentitet | Stödd integration och identitetens livscykel | Applikationsroller och affärsauktorisering |
| Databastjänst | Provisioneringsgränssnitt och definierad tjänstedrift | Datamodell, frågebeteende och tillåtna data |
| Leveranspipeline | Skyddad exekvering och artefakthantering | Relevanta tester och acceptans av ändringen |
| Övervakning | Insamling och larmfunktion | Tjänstemål och åtgärdsbar respons |
Detta är en exempelfördelning. Bekräfta den med faktiska team och leverantörer. Odefinierat ansvar försvinner inte för att en plattform finns.
Publicera en undantagsväg för krav utanför standardlösningen. Identifiera beslutsansvarig och nödvändigt underlag. En svår undantagsprocess kan få team att skapa system utan stöd utanför plattformen.
Underhåll tjänster efter skapandet
En mall är en startversion. Den rättar inte automatiskt applikationerna som skapats från den. Bestäm hur plattformsändringar når befintliga tjänster och hur kompatibilitet kontrolleras.
Versionshantera gemensamma gränssnitt och moduler. Meddela villkor för borttagning. Ge en stödd migrering där det behövs. Följ vilka tjänster som ligger kvar på berörda versioner när en säkerhetsrättning krävs.
Gör inte plattformsteamet till en manuell godkännandekö för varje rutinåtgärd. Automatisera upprepningsbara kontroller och reservera mänskliga beslut för olösta konsekvenser. Mät lyckad användning, väntetid, återställningsresultat och underhållsinsats.
Koppla plattformen till programvarufabriken
Platform engineering definierar stödda förmågor och driftgränser. En programvarufabrik kopplar ihop krav, planering, implementation, underlag och leverans. De kan komplettera varandra när fabriken planerar mot den faktiska plattformen.
Ta med löpande drift i utvärderingen. Verifiera vem som skannar nya sårbarheter, driftsätter rättningar, reagerar på incidenter och underhåller complianceunderlag. Förmågorna behöver överenskommet omfång och ansvariga; begreppet ”programvarufabrik” garanterar dem inte.
Bedöm integrationen konkret: kan en genererad ändring använda befintlig driftsättningsväg och bevara kontrollerna? Kan teamet granska varför ett undantag behövdes? Vem uppdaterar gemensam kontext när plattformen ändras?
DORA:s forskning placerar AI-förmåga i den omgivande organisationen. Använd perspektivet för att bedöma hela arbetsflödet, inklusive arbetet som blir kvar hos plattformsteamet. DORA:s rapport 2025.
Gör övningen
Utforma en plattformsförmåga för en intern webbtjänst. Ange indata, utdata, tillåtna identiteter, kontroller, felhantering och ansvarig. Lägg till en uppgraderingsväg för befintliga tjänster och en undantagsväg för krav som standardlösningen inte stöder.
Ladda ned övningsblad (Markdown)Kontrollera din förståelse
Källor och vidare läsning
Relaterad läsning från Taiga
Om du avmarkerar valet raderas alla framsteg som sparats i den här webbläsaren.
Framstegen stannar i webbläsaren. Inget konto, ingen spårning.