Tervezés és rangsorolás

Megtudhatja, hogyan azonosíthatja a platformmérnöki erőfeszítések céljait a platformmérnöki képességmodell alapján, hogyan ismerheti meg a gyakori forgatókönyveket, és hogyan mérheti a sikert. Mérje fel a sikert úgy, hogy a céljait üzleti célokra méri.

Célok és kulcsforgatókönyvek azonosítása

Első lépésként a platformmérnöki képességmodell használatával mérje fel, hogy a szervezet hol van ma. A modell segítségével diagramon ábrázolhatja, hogy a szervezet hol található hat alapvető platformmérnöki képesség között: befektetés, bevezetés, irányítás, kiépítés és felügyelet, interfészek, valamint mérés és visszajelzés. Egyes képességekben minden szervezet fejlettebb, mint másoknál. Ha már tudja, hol áll ma a szervezete, kiválaszthatja, hogy mely képességeket szeretné növelni. További információ: Az aktuális gyakorlatok értékelése és a jövőbeli célok meghatározása.

A platformtervezési célokat folyamatosan megtervezheti és frissítheti. Ha tisztában van azzal, hogy mit szeretne nyerni a platformfejlesztésbe való befektetésből, az sokat segíthet a szervezeti támogatás kiépítésében.

A platformmérnöki vezető egyszer azt mondta: "Nem csinálok semmit a platformmérnöki területén, amíg nincs belőle valami, amit nyerhetek." – Peter, platformmérnöki vezető, multinacionális tech vállalat

Amikor a célokra gondol, azokat a platformfejlesztéssel kapcsolatos üzleti célokra is ki kell terjednie, nem pedig egy adott fejlesztői csapat sajátosságaira. A magas szintű platformfejlesztés általános céljai a következők:

• Növelje az alkalmazás minőségét, és csökkentse a hibákat és problémákat a kiadás során.
• A biztonság javítása és a biztonsági incidensek számának csökkentése, illetve a gyakori biztonsági rések és kitettségek (CVE-k) észlelése az éles környezetben.
• A kockázat csökkentése a jobb megfelelőség révén olyan területeken, mint a licencelés, az akadálymentesség, az adatvédelem vagy a kormányzati szabályozás.
• Az üzleti értékhez vezető idő felgyorsítása az összetettség és a többletterhelés csökkentésével, valamint a kódmegosztás előmozdításával az inner source gyakorlatok alkalmazásával.
• Csökkentheti a fejlesztési vagy üzemeltetési költségeket, minimalizálhatja a duplikációt, és javíthatja az automatizálást.

A legfontosabb cél kiválasztása kritikus fontosságú, mivel a cél határozza meg, hogyan gondolkodik a rangsorolásról.

Még jobb, ha egyetért a célkitűzésekről és a kulcsfontosságú eredményekről (OKRs) a vezetéssel és a belső partnerekkel, segít mérhető célokat meghatározni a beruházások jelenlegi fázisában. (Más tervezési megközelítések is hasonló fogalmak, ha a szervezet valami mást használ.) A legjobb OKR-ek azok, amelyeket konkrét mérték alapján állíthat be, mivel eltávolítja a szubjektivitást.

Elvégzendő forgatókönyvek és feladatok

A célok azonosítása után válassza ki a fő forgatókönyveket a teendőlista és az ütemterv kivezetéséhez. Lásd például a következő forgatókönyveket és a kapcsolódó feladatokat.

Forgatókönyv: Új alkalmazás létrehozásának megkezdése

• A szervezeti ajánlott eljárások és szabályzatok megismerése és alkalmazása
• Új adattár létrehozása
• Eszközök kiépítése
• Közös infrastruktúra kiépítése
• Csoporttagok hozzáférésének biztosítása
• CI/CD-folyamatok létrehozása
• Fejlesztési infrastruktúra kiépítése
• Kezdeti üzembe helyezés a "csövek" teszteléséhez

Forgatókönyv: Új tag hozzáadása vagy eltávolítása egy meglévő csapathoz

• Eszközökhöz és szolgáltatásokhoz való hozzáférés frissítése
• Fejlesztői gép beállítása
• A csapattag alkalmazásokra való felkészítése
• Alkalmazás tesztkörnyezetének létrehozása
• A lekéréses kérelem létrehozása és áttekintése

Forgatókönyv: Infrastruktúra hozzáadása vagy frissítése meglévő alkalmazáshoz

• A szervezeti ajánlott eljárások és az elérhető lehetőségek ismertetése
• Infrastruktúra frissítése vagy hozzáadása kódösszetevőkként
• Alkalmazás tesztkörnyezetének létrehozása
• Frissítések ellenőrzése
• Módosítások bevezetése más környezetekben

Forgatókönyv: Eszköz hozzáadása vagy frissítése meglévő csapathoz

• A szervezeti ajánlott eljárások és az elérhető lehetőségek ismertetése
• Új eszköz használatának kérése
• Csapattag eszközökhöz való hozzáférésének frissítése
• (Ha van) Eszköz integrálása ügyfelekbe vagy CI/CD-folyamatokba

Forgatókönyv: Meglévő API, SDK vagy szolgáltatás megkeresése vagy újrafelhasználása

• Az elérhető API-k, SDK-k vagy szolgáltatások felderítése
• Annak felmérése, hogy megfelel-e az igényeknek
• Bármilyen kérdés esetén csatlakozzon a tulajdonos csapathoz
• Alkalmazásba vétel

Forgatókönyv: Reagálás műveleti incidensre

• Értesítés egy problémáról
• Annak felmérése, hogy az alkalmazáskódhoz vagy az infrahez (vagy mindkettőhöz) kapcsolódik-e
• Tesztkörnyezet létrehozása, amely tükrözi a prod (ha eltérő)
• Módosítások végrehajtása, tesztelés, sávon kívüli kiadás

Forgatókönyv: Biztonsági incidens gyors elhárítása

• Értesítés egy problémáról
• A problémák szélességének felmérése (mely rendszerek)
• Annak megismerése, hogy az ügyfelekre közvetlenül hatással van-e
• Tesztkörnyezet létrehozása, amely tükrözi a prod (ha eltérő)
• Módosítások végrehajtása, tesztelés, sávon kívüli kiadás
• Kommunikáció az érintettekkel

Forgatókönyv: Használaton kívüli eszköz

• Az eszközhasználat ismertetése
• A felhasználók értesítése az elavulásról
• (Nem kötelező) A felhasználók új eszközre való migrálásának koordinálása

Forgatókönyv: Az architektúra új alkalmazásmodelljének bevezetése

• Javasolt architektúra próbaüzeme
• Beállítás a próbaeredmények alapján
• Ajánlott eljárások dokumentációja frissítése
• Sablonok létrehozása, automatizálás frissítése, szabályzatok és szabályozás

Alkalmazásmegfelelőség naplózása (GDPR, akadálymentesség, infrastruktúra-szabványok)

• Az aktuális megfelelőségi szabályok ismertetése
• Annak ellenőrzése, hogy az alkalmazás megfelel-e a szabályoknak
• Az eltérések javításának határidejének meghatározása
• Módosítások végrehajtása, tesztelés, kiadás

Számos forgatókönyv több szerepkörre is vonatkozik. Gondoljon a metrikákra, hogy hogyan fogja mérni a javulást.

Problémáktól a fogalmakig

Ezután ismerje meg a fejlesztők és más szerepkörök által az Ön által azonosított forgatókönyvekkel és feladatokkal kapcsolatos legnagyobb problémákat. Célszerű lehet megvizsgálni az új termékeket, hogy pótolják az észlelt hiányosságokat, de ha ezek a termékek nem oldják meg a súlyos problémát, akkor nem valószínű, hogy elfogadtatásra vagy elismerésre találnának.

Számos megközelítés segíthet az ilyen jellegű vizsgálatokban, például a Hipotézis progressziós keretrendszerében. Még ha nem is használ formalizált folyamatot, például a Hipotézis progressziós keretrendszerét, akkor is érdemes megkérdezni a fejlesztőket, hogy milyen feladatokat kell elvégezniük a vitafórum hatókörének meghatározásához, majd azonosítaniuk kell a munkájuk során felmerülő legnagyobb problémákat. Ha már világos képet kapott arról, mik ezek a problémák, lépjen tovább a megoldási tervek kidolgozására. Ez segít biztosítani, hogy a fejlesztők által használni kívánt funkciókat hozzon létre.

Ha gyorsan meg szeretné ismételni ezt a folyamatot, azonosítsa az ügyfelet közvetlenül a belső fejlesztői platform csapatában képviselő személyeket. Ezt a szerepkört általában termékmenedzsernek nevezik (még akkor is, ha más beosztással rendelkeznek), és a tudásuk növekedésével képesek pontosan előrejelezni az eredményeket kisebb döntésekhez, és meghatározni, hogy mikor van szükség további interjúkra. Így az agilitása folyamatosan növekszik, miközben a belső ügyfeleknek nyújtott értékre összpontosít.

Indokolja meg a kezdeti befektetéseit

Ha már rendelkezik érvényesített problémákkal és fogalmakkal, akkor jó helyzetben van, hogy eldöntse, hol kell befektetnie. A megoldások értékelésekor azonban vegye figyelembe a szükséges előzetes beruházásokat és hosszú távú karbantartást. A legkisebb erőfeszítési megoldás, amely képes megoldani a problémát, általában a megfelelő megoldás, amellyel kezdeni kell, de gyakran a karbantartási munka dönti el, hogy a befektetés sikeres-e.

Másképpen fogalmazva, ne hozzon létre olyan megoldásokat, amelyek az út későbbi szakaszaira irányulnak, hacsak nem igazán szükséges.

Miután azonosította a legritkább életképes platformot (TVP- t) ( például a platform minimálisan életképes termékét ), tesztelje azt egy fejlesztői csapattal, amelyek hajlandóak visszajelzést adni. Ha a próbamegoldás megoldja azokat a problémákat, amelyekkel ezek a csapatok szembesülnek, nem kell bajlódnia azzal, hogy valakit keres, aki érdeklődik a részvétel iránt.

Az új képességek vagy módosítások próbaüzeme során rögzítenie kell néhány fontos metrikát, hogy meg tudja mérni, hogy a koncepció sikeres volt-e a bevezetés előtt.

Sikeresség mérése és érték igazolása

A siker mérése fontos része a termék szemléletének. A kisebb sikerek már szerény beruházásokkal is lefektethetik az alapokat, amelyekre a nagyobb beruházások épülhetnek.

Nehéz lehet például finanszírozást vagy bevásárlást biztosítani a megfelelőségi erőfeszítésekhez, mert működési adónak tekinthetők az üzleti értéket szolgáltató fejlesztői csapatok számára. A termékszemlélet megváltoztathatja ezt az észlelést. A termékszemlére való odafigyeléssel biztosítani szeretné, hogy a belső fejlesztői platform ügyfelei elégedettek legyenek, és hogy az érdekelt felek üzleti céljai teljesüljenek. A metrikák lehetővé tették, hogy tényekkel bizonyítsa, hogy üzleti értéket nyújt. Az OKR-ek beállítása segíthet, különösen akkor, ha olyan metrikákkal rendelkezik, amelyekkel eltávolíthatja a szubjektív torzításokat. Még ha ma nem is mér semmit, beállíthatja a tanulási OKR-t egy alapvetés létrehozásához, amelyet majd pontosít, miután ez az alapvetés ismertté válik.

Az alábbiakban jól ismert metrikákat mutatunk be, amelyek alapján megállapíthatja, hogy a csapat, amellyel dolgozik, értéket kap-e az éppen létrehozott metrikából. Összpontosítson azokra, amelyek segítenek felmérni, hogy Ön, és a fejlesztői csapat és ügyfelei elérik-e a céljaikat. Az alábbi metrikák például segítenek felmérni, hogy a platform hozzájárul-e egy hatékony mérnöki szervezethez:

• Az üzleti érték elérésének sebessége/ideje: Az első kódleolvasási kérelem befejezésének mediánideje (előkészítés), az építési és tesztelési folyamatok mediánideje percben (például: CI), a kódleolvasási kérelem egyesítésének mediánideje.
• Szoftverminőség: Havonta létrehozott incidensek (problémák) (a fejlesztők száma normalizálva), a helyreállítás átlagos ideje (MTTR), a biztonsági probléma kivizsgálásának és elhárításának átlagos ideje.
• Platform egyszerű használata: Nettó felhasználói elégedettség (NSAT)
• Virágzó ökoszisztéma: Az alábbi kérdések átlagos pontszáma a felmérésben: "Képessé tesznek arra, hogy a legjobb munkámat végezzem," "a legtöbb nap feltölt energiával a munkám," "értelmes számomra a munkám."

Ezeket a metrikákat ezután szervezeti, csapat vagy projekt szerint bonthatja fel. A kezdeti lépésként meg kell mérnie néhány alapvonalat, de ahogy javítja a platformját, megfigyelheti, hogy ezek a metrikák változnak.

Egyéb metrikák, amelyeket Ön vagy a szponzorai is érdekelhetnek a mérésben, a következők lehetnek:

Area	Példák metrikákra
Szoftverkézbesítési teljesítmény	DevOps Research and Assessment (DORA): Az átfutási idő, az üzembe helyezés gyakorisága, a hibaarány módosítása, a szolgáltatás visszaállításának ideje (MTTR)
Operations	DORA (MTTR), hiba közötti átlagos idő (MTBF), nyugtázás átlagos ideje, végfelhasználói rendelkezésre állás, késés, átviteli sebesség metrikák, csapatonkénti költség, üzembe helyezésenkénti költség
Platformképesség-bevezetési metrikák	Az eszközökkel vagy szolgáltatásokkal rendelkező csapatok vagy fejlesztők száma az idő függvényében, a platformot használó adattárak százalékos aránya, a legnépszerűbb sablonok, folyamatok stb.

A metrikák összegyűjtése időt és energiát igényel, ezért fontos, hogy a kritikus metrikákra összpontosítsunk az ön által azonosított alapvető célokhoz, különösen az OKRs-eket használó célokhoz. Az OpenTelemetry-alapú termékek, például az Application Insights segíthetnek.

Mindenképpen mérje fel a platform könnyű használhatóságát, és ellenőrizze, hogy rendszeresen van-e virágzó ökoszisztémája. Ezek a metrikák gyakran hiányoznak a belső rendszerekből, és vezető szerepet kapnak a szélesebb körű üzleti célok elérésében, mivel a részvétel kritikus fontosságú a siker szempontjából. Azt is segít tudni, hogy ideje-e további ügyfélfejlesztést végezni, hogy megtudja, hol folytassa a következőt.

Egyéb tippek

A kezdéstől függetlenül tartsa szem előtt, hogy tervezzen a változásra, kezdjen új alkalmazásokkal a pilóták számára, összpontosítson a meglévő felhasználói élmény fokozására, fogadja el a minimális jogosultság elvét, tervezze meg a szabályozott kísérletezést, és minimalizálja a testreszabást.

Tervezett változtatás

A célalkalmazási platform idővel fejlődni fog, és előfordulhat, hogy nem tudja egyszerre migrálni az összes meglévő befektetést. Gondolja át, hogyan támogathat több változatot az idő függvényében, és hogyan tervezheti meg a módosításokat.

Ötletek érvényesítése újabb alkalmazásokkal

Kezdje az új, megfelelő méretű alkalmazásokkal, amikor új platform- vagy platformképességeket tesztel. Ez azt is lehetővé teszi, hogy tapasztalatot szerezzen a platform termékként való kezelésében. Kerüld el, hogy elindíts replatformálási projekteket, mivel menet közben tanulsz, és a nagy meglévő alkalmazások gyakran egyedi igényekkel rendelkeznek, amelyek csak a replatformálási munka során derülnek ki. Emiatt a siker ilyen típusú erőfeszítésekhez kapcsolása elvárásbeli eltéréseket vagy késői problémákat eredményezhet. Az újabb dolgokkal kezdve növelheti a bizalmát az irányában és az általuk nyújtott értékben. Ez csökkenti a nagyobb erőfeszítések kezelésének kockázatát. Másként fogalmazva, ha biztos abban, hogy az emberek jól kezdhetnek, és megfelelően folytathatják, akkor egyszerűbbé válik a kampány irányítása a tapasztalat alapján. Ha ez a megközelítés nem lehetséges, érdemes alapos elemzést végezni, elvárásokat beállítani, és fokozatosan lépkedni ahelyett, hogy mindent egyszerre próbálna módosítani.

Összpontosítson a meglévő gravitációs középpontokra a felhasználói élmények érdekében, mielőtt újakat hoz létre

A fejlesztők nagyobb valószínűséggel alkalmazzák és használják az új képességeket, amikor olyan felületen jelennek meg, amelyet már szeretnek és használnak. A fogalmak új képességek biztosítása érdekében történő kiértékelése során mindenképpen vizsgálja meg azokat a lehetőségeket, amelyek kiterjesztik a meglévő gravitációs központokat. A szerkesztők/azonosítók (Visual Studio, VS Code), DevOps-csomagok (GitHub, Azure DevOps), meglévő CLI-k vagy meglévő belső portálok például hatékonyabbak lehetnek, mint egy teljesen új portál vagy más UX. További információ: Felhasználói élmények.

Tegyük fel a minimális jogosultság elvét.

Tegyük fel, hogy a fejlesztők korlátozott hozzáféréssel rendelkeznek az alsóbb rétegbeli rendszerekhez például az infrastruktúra kiépítéséhez. Az önkiszolgáló szolgáltatásokhoz való hozzáférés engedélyezéséhez szabályozott módon kell engedélyeznie ezt a hozzáférést.

Szabályozott kísérletezés megtervezése

Kísérletezzen nagyobb vagy kockázatos módosítások bevezetése előtt. Nem kell mindent teljesen automatizálni a kezdéshez. Az automatikusan aktivált manuális munkafolyamat nagyszerű módszer lehet az ötletek kipróbálására.

Alkalmazásplatform testreszabásának minimalizálása

Kerülje az egyéni alkalmazásplatform-képességek használatát, amelyeket a szoftvergyártók által az idő múlásával kiadott képességek elhomályosíthatnak. Például futásidejű üzemeltetés, szolgáltatáshálók, identitásrendszerek stb. Ha sürgős igény merül fel egy olyan területen, amelyről gyanítja, hogy ilyen lehet, tervezzen több megvalósítási lehetőséget, mivel a hosszú távú karbantartás valószínűleg idővel változtatásokat követelhet meg.

Kapcsolódó tartalom

• Szoftvermérnöki rendszerek alkalmazása