Tervezés és rangsorolás
Megtudhatja, hogyan azonosíthatja a platformmérnöki törekvések céljait, áttekintheti a gyakori forgatókönyveket, és hogyan mérheti a sikert. A sikert úgy mérheti meg, hogy a céljait üzleti célokra méri.
A platformmérnöki vezető egyszer azt mondta: "Nem csinálok valamit a platform mérnöki, amíg van valami, amit nyerhetek belőle." - Peter, platformmérnöki vezető, Multinacionális Tech Company
Ahelyett, hogy áttekintené a képességek vagy funkciók rote ellenőrzőlistát, először is azonosítsa a platformmérnöki törekvések céljait. A célokat folyamatosan megtervezheti és frissítheti az idő múlásával. Ha azonban tisztában van azzal, hogy mit szeretne elérni a platformmérnöki folyamatba való befektetéssel, az hosszú utat vehet igénybe a szervezeti támogatás kiépítésében.
Miközben a céljaira gondol, azokat a platformmérnöki tevékenységhez kapcsolódó üzleti célokra is kiterjesztheti, nem pedig egy adott fejlesztői csapat sajátosságaira. Íme például néhány gyakori magas szintű platformtervezési cél:
- Növelje az alkalmazás minőségét, csökkentse a hibákat és problémákat a kiadás során.
- A biztonság javítása, a biztonsági incidensek számának csökkentése vagy az észlelt CVE-k egyszeri éles környezetben történő észlelése.
- 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 összetettség, a többletterhelés és a kódmegosztás belső forrásokkal való megosztásának elősegítésével felgyorsíthatja az üzleti idő értékét.
- Csökkentse a fejlesztési vagy üzemeltetési költségeket, minimalizálja a duplikációt, és javítsa az automatizálást.
Bár ezek a célkitűzések hosszú távú célok is lehetnek, a legfontosabb cél kiválasztása kritikus fontosságú, mivel ez határozza meg, hogyan gondolja át a rangsorolást.
Még jobb, ha a vezetőivel és belső partnereivel egyeztet a célokról és a legfontosabb eredményekről, segíthetnek mérhető célok kialakításában a beruházások jelenlegi szakaszá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.
Miután azonosította a céljait, azonosítsa azokat a kulcsfontosságú forgatókönyveket, amelyeket a hátralék és az ütemterv kivezetéséhez fog használni. Lásd például ezeket a forgatókönyveket és feladatokat.
- 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ői infrastruktúra kiépítése
- Kezdeti üzembe helyezés a "csövek" teszteléséhez
- 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 csapattagok felfutása az alkalmazásokban
- Alkalmazás tesztkörnyezetének létrehozása
- Az első lekérés létrehozása és áttekintése
- A szervezeti ajánlott eljárások és a rendelkezésre álló lehetőségek ismertetése
- Infrastruktúra frissítése és 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
- A szervezeti ajánlott eljárások és a rendelkezésre álló lehetőségek ismertetése
- Új eszköz használatának kérése
- A 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
- Elérhető API-k, SDK- és 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ás elfogadása
- Értesítés egy problémáról
- Annak felmérése, hogy az alkalmazáskód vagy az infrastrukturális kapcsolat (vagy mindkettő)
- Tesztkörnyezet létrehozása a prod tükrözése érdekében (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 szervizelése / Gyakori biztonsági rések és kitettségek (CVE) értesítés
- É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 ügyfeleket közvetlenül érinti-e a hatás
- Tesztkörnyezet létrehozása a prod tükrözése érdekében (ha eltérő)
- Módosítások végrehajtása, tesztelés, sávon kívüli kiadás
- Kommunikáció az érintettekkel
- Az eszközhasználat ismertetése
- A felhasználók értesítése az elavulásról
- (Nem kötelező) A felhasználók áttelepítésének koordinálása új eszközre
- Kísérleti javasolt architektúra
- Beállítás a próbaeredmények alapján
- Ajánlott eljárások dokumentációja
- Sablonok létrehozása, automatizálás frissítése, szabályzatok, irányítás
- 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 kijavítási határidejének meghatározása
- Módosítások végrehajtása, tesztelés, kiadás
Számos forgatókönyv egynél több szerepkörre vonatkozik, ezért érdemes a metrikákra is gondolni, hogy hogyan fogja megérteni, hogy a forgatókönyvek mennyivel javulnak.
Ezután azt javasoljuk, hogy keresse 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. Csábító lehet az új termékek vizsgálatának megkezdése, hogy kitöltsék az észlelt hiányosságokat, de ha ezek a termékek nem oldanak meg egy nagyobb fájdalompontot, nem valószínű, hogy elfogadják vagy értékelik őket.
Számos olyan megközelítés létezik, amely segíthet az ilyen jellegű vizsgálatban. Az egyik a Hipotézis progressziós keretrendszere. Még ha nem is használ formalizált folyamatot, például a Hipotézis progressziós keretrendszerét, sokat nyerhet a fejlesztők megkérdezéséből egy olyan feladatról, amelyet el kell végezni a vitafórum hatókörének meghatározásához, majd a munkájuk elvégzéséhez legnagyobb problémáik azonosításához. Ha már jól érzékeli, hogy mik ezek a problémák, továbbléphet a megoldásukkal kapcsolatos fogalmakra. Ez segít biztosítani, hogy olyan funkciókat hozhasson létre, amelyeket a fejlesztők használni szeretnének.
A folyamat gyors megismétléséhez azonosítania kell valakit, aki az ügyfél hangját közvetlenül a belső fejlesztői platform csapatában tudja képviselni. 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 lesznek pontosan előrejelezni a kisebb döntések eredményeit, és meghatározni, hogy mikor kell több interjút készíteni. Ez tartja fenn az agilitást, miközben továbbra is biztosítja, hogy a belső ügyfeleknek értéket nyújtson.
Ha már rendelkezik érvényesített problémákkal és fogalmakkal, jó helyzetben lesz, hogy érvet állítson be a befektetéshez. Ne feledje azonban, hogy az előzetes beruházások szintje és a hosszú távú karbantartás szükséges. A legkisebb erőfeszítéssel megoldható megoldás általában a megfelelő megoldás a kezdéshez, de gyakran a karbantartási munka dönti el, hogy a befektetés sikeres-e.
Másként fogalmazva, ne hozzon létre olyan megoldásokat, amelyek az utazás későbbi szakaszait célba érik, kivéve, ha valóban szükség van rá.
Miután azonosította a legvékonyabb működőképes platformját (TVP) (a platform MVP-je ), tesztelheti 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 bajt találnia, 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 megmérhesse, hogy a koncepció sikeres volt-e a bevezetés előtt.
Függetlenül attól, hogy az első befektetését teszi-e, a terméktudatos gondolkodás fontos része annak mérése, hogy mennyire sikeres. Ez nem csak segít tudni, hogy elérte-e a céljait, de még a kis sikerek szerény beruházások is lefektethetik az alapokat a nagyobb beruházások építeni.
Például nehéz lehet biztosítani a finanszírozást vagy a bevásárlást a megfelelőségi erőfeszítésekhez, mert ezek működési adóként tekinthetők az üzleti értéket szolgáltató fejlesztői csapatok számára. A termékszemlélet megváltoztathatja ezt a felfogást. Termékszemlére gondolva igyekszik biztosítani, 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é teszik, 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 sem mér semmit, beállíthat egy tanulási OKR-t egy alapterv beállításához, amelyet az alapterv ismerete után pontosít.
Az alábbi példák jól ismert metrikákra mutatnak be, amelyek alapján megállapíthatja, hogy a csapat, amellyel dolgozik, értéket kap-e az összeállításból. Nulla azok közül, amelyek segítenek felmérni, hogy Ön és a fejlesztői csapat ügyfelei elérik-e a céljait. 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:
- Sebesség/idő az üzleti értékhez: Az első lekéréses kérelem (előkészítés) befejezésének mediánja, a buildelési és tesztelési folyamatok medián perce (például CI), a lekéréses kérelem egyesítésének medián időpontja.
- Szoftverminőség: Havonta létrehozott incidensek (problémák) (a darabszám a devek számára normalizálva), a szervizelés átlagos ideje (MTTR), a biztonsági probléma kivizsgálásának és szervizelésének átlagos ideje.
- Platform könnyű használata: Nettó felhasználói elégedettség (NSAT)
- Virágzó ökoszisztéma: Az alábbi felmérésben szereplő kérdések átlagos pontszáma: "A legjobb munkámra vagyok jogosult", "a legtöbb nap energiával tölt el, amit csinálok", "a munkám értelmes számomra."
Ezután felbonthatja ezeket a metrikákat szervezet, csapat vagy projekt szerint. Első lépésként meg kell mérnie néhány alaptervet, de watch ezek a metrikák megváltozhatnak a platform fejlesztésekor.
Egyéb metrikák, amelyekre Ön vagy a szponzorai kíváncsiak, a következők lehetnek:
Terület | Példametrikák |
---|---|
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) |
Műveletek | 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ő múlásával, a platformot használó adattárak százalékos aránya, a legnépszerűbb sablonok, folyamatok stb. |
A metrikák gyűjtése időt és energiát igényel, ezért fontos a kritikus metrikákra összpontosítani az ön által azonosított alapvető célokhoz – különösen az OKR-eket használókhoz. Az OpenTelemetry-alapú termékek, például az Application Insights segíthetnek. Ettől függetlenül mindenképpen mérje a platform könnyű használatát, és ellenőrizze, hogy rendszeresen van-e virágzó ökoszisztémája. Ezek a metrikák gyakran kimaradnak a belső rendszerekből, és vezető mutatóként szolgálnak arra vonatkozóan, hogy megfelel-e a szélesebb körű üzleti céloknak, 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 annak megértéséhez, hogy hol kell továbbhaladnia.
A kezdéstől függetlenül tartsa szem előtt az alábbi irányelveket.
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. Érdemes végiggondolnia, hogyan támogathat egynél több változatot az idő múlásával, és hogyan tervezheti meg a módosításokat.
Az új platform- vagy platformképességek kipróbálásakor általában érdemes ésszerű méretű új alkalmazásokkal kezdeni. Ez azt is lehetővé teszi, hogy a platformot termékként kezelje. Ne feledje, hogy a projektek újraplatformozása elkezdődhet, mivel útközben megtanulhatja, és a nagy meglévő alkalmazásoknak gyakran egyedi igényeik vannak, amelyek csak az újraplatformozás során merülnek fel. Emiatt a sikernek az ilyen típusú erőfeszítésekhez való csatlakoztatása várakozási eltéréseket vagy késői törési problémákat eredményezhet. Az újabbaktól kezdve magabiztosan állíthatja be, hogy milyen értéket biztosít. Ez csökkenti a nagyobb erőfeszítések kezelésének kockázatát. Ha biztos benne, hogy az emberek jól kezdhetnek, és helyesen tudnak maradni, akkor könnyebbé válik a megfelelő kampány vezetése a tapasztalatokból tanultak alapján. Ha ez a megközelítés nem lehetséges, érdemes alapos elemzést végeznie, elvárásokat beállítania, és növekményesen lépnie ahelyett, hogy mindent egyszerre próbálna módosítani.
A fejlesztők nagyobb valószínűséggel fogadnak el és ragaszkodnak az új képességekhez, amikor olyanban jelennek meg, amit már kedvelnek é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 a meglévő "gravitációs központok" kiterjesztését teszik lehetővé. 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 felhasználói felület. További információért tekintse meg a felhasználói élményeket .
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.
Kísérletezzen, mielőtt jelentős vagy kockázatos módosításokat vezet be. Nem mindennek kell teljesen automatizáltnak lennie a kezdéshez. Az automatikusan aktivált manuális munkafolyamat nagyszerű módszer lehet az ötletek kipróbálására.
Próbálja meg elkerülni azokat az egyéni alkalmazásplatform-képességeket, amelyeket a szoftverszállítók idővel kibocsáthatnak. Ilyen például a futtatókörnyezet üzemeltetése, a szolgáltatáshálók, az identitásrendszerek stb. Ha sürgős szükségletet talál egy olyan területen, amelyről azt gyanítja, hogy a következőhöz hasonló, a hosszú távú karbantartás miatt valószínűleg több megvalósítási lehetőséget is tervezhet.