Platformu inženierija MI izstrādei

Dodiet prototipiem ceļu uz produkcijas vidi

Cilvēki var izpētīt idejas ar dažādiem MI rīkiem, kamēr organizācija nodrošina kopīgu ceļu uz produkcijas vidi. Platformas komanda padara šo ceļu skaidru, atbalstītu un atkārtojamu.

Noderīgam prototipam apkopojiet lietotāja uzdevumu, darbplūsmas piemēru, pirmkodu, ja tas pieejams, un paredzētos datus. Novērtējiet, vai kodu pielāgot vai veidot no jauna pēc apgūtajām prasībām. Pirms īstiem piekļuves datiem vai konfidenciālas ievades pārbaudiet lietotni, izstrādes rīkus un izpildvidi pret nepieciešamajām kontrolēm.

Ja pakalpojumam jādarbojas jūsu infrastruktūrā, piedāvājiet atbalstītu izvietošanu savos mākoņa kontos vai tīklos. Iekļaujiet identitāti, slepeno datu apstrādi, laidiena pierādījumus, uzraudzību un atjaunošanu. Modeļa datu plūsmas pārskatiet atsevišķi; izpildvides pārvaldīšana nekontrolē katru izstrādes pakalpojumu.

Uztveriet platformu kā produktu tās lietotājiem

Platforma dod komandām atbalstītas iespējas programmatūras veidošanai un ekspluatācijai. Tās var ietvert identitāti, vides, piegādes pipeline, datubāzes, uzraudzību un politiku pārbaudes. Noderīgā vienība ir pilna darbplūsma, kas apmierina atkārtotu vajadzību.

CNCF apraksta platformas kā ap iekšējiem lietotājiem veidotas iespējas ar konsekventām saskarnēm un pašapkalpošanos, kur tā piemērota. Portāls var padarīt šīs iespējas pieejamas, bet portāls viens pats nav platforma. CNCF Platforms White Paper.

Sāciet ar īstu pieprasījumu. Izdomātā uzņēmumā vairākām komandām vajag iekšēju tīmekļa pakalpojumu ar darbinieku pieslēgšanos un pārvaldītu datubāzi. Izveidojiet atbalstītu ceļu šai vajadzībai, pirms pievienojat plašu reti lietotu funkciju katalogu.

Iekļaujiet aģentus platformas lietotāju vidū

MI aģents var ātri ģenerēt infrastruktūras kodu. Bez aktuāla platformas konteksta tas var arī izvēlēties neatbalstītu reģionu, identitātes paraugu vai izvietošanas metodi. Ātrāka ģenerēšana neatrisina trūkstošus organizācijas ierobežojumus.

Dodiet aģentam uzticamu saskarni. Definējiet ievadi, atļautās vērtības, izvadi un darbību kļūmes gadījumā. Sniedziet instalētajai versijai atbilstošus piemērus. Atgrieziet kļūdas, pēc kurām var rīkoties, neatklājot slepenos datus. Piemērojiet vienādas autorizācijas pārbaudes cilvēku un aģentu izsaukumiem.

Iekšējam pakalpojumam pieprasījums varētu norādīt atbildīgo, datu kategoriju, vidi, atjaunošanas prasību un atbalstīto izpildvidi. Tad platforma var izvēlēties pārskatītu konfigurāciju vai izskaidrot, kāpēc pieprasījumam vajag atsevišķu lēmumu.

Nosakiet atbalstīto ceļu un tā ierobežojumus

Tas ir sadalījuma piemērs. Apstipriniet to ar faktiskajām komandām un sniedzējiem. Nenoteikta atbildība nepazūd tāpēc, ka pastāv platforma.

Publicējiet izņēmuma kārtību prasībām ārpus noklusējuma risinājuma. Nosakiet lēmuma atbildīgo un nepieciešamos pierādījumus. Sarežģīts izņēmumu process var mudināt komandas radīt neatbalstītas sistēmas ārpus platformas.

Uzturiet pakalpojumus pēc izveides

Veidne ir sākuma versija. Tā automātiski nelabo no tās izveidotās lietotnes. Izlemiet, kā platformas izmaiņas nonāk esošajos pakalpojumos un kā tiek pārbaudīta saderība.

Versējiet kopīgās saskarnes un moduļus. Paziņojiet noņemšanas nosacījumus. Kur vajadzīgs, nodrošiniet atbalstītu migrāciju. Ja nepieciešams drošības labojums, sekojiet, kuri pakalpojumi paliek ietekmētajās versijās.

Nepārvērtiet platformas komandu par manuālu apstiprinājumu rindu katrai ikdienišķai darbībai. Automatizējiet atkārtojamas pārbaudes un atstājiet cilvēku lēmumus neatrisinātām sekām. Mēriet veiksmīgu lietojumu, gaidīšanas laiku, atjaunošanas rezultātus un uzturēšanas darbu.

Saistiet platformu ar programmatūras ražotni

Platformu inženierija definē atbalstītās iespējas un ekspluatācijas robežas. Programmatūras ražotne saista prasības, plānošanu, īstenošanu, pierādījumus un piegādi. Tās var papildināt viena otru, ja ražotne plāno pēc faktiskās platformas.

Iekļaujiet novērtējumā pastāvīgu ekspluatāciju. Pārbaudiet, kurš skenē jaunas ievainojamības, izvieto labojumus, reaģē uz incidentiem un uztur atbilstības pierādījumus. Šīm iespējām vajag saskaņotu tvērumu un atbildīgos; termins „programmatūras ražotne“ tās negarantē.

Novērtējiet integrāciju konkrētā vietā: vai ģenerēta izmaiņa var izmantot esošo izvietošanas ceļu un saglabāt tā kontroles? Vai komanda var pārbaudīt, kāpēc bija vajadzīgs izņēmums? Kurš atjaunina kopīgo kontekstu, kad platforma mainās?

DORA pētījums aplūko MI spējas apkārtējās organizācijas ietvaros. Izmantojiet šo skatījumu visas darbplūsmas vērtēšanai, tostarp darbam, kas paliek platformas komandai. DORA 2025. gada pārskats.