Olvasás angol nyelven

Megosztás a következőn keresztül:


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.

Célok és fő forgatókönyvek azonosítása

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.

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

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.

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

  • 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

Forgatókönyv: Új tag hozzáadása/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 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

Forgatókönyv: Meglévő alkalmazás infrastruktúrájának hozzáadása/frissíté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

Forgatókönyv: Add /update tool for existing team

  • 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

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

  • 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

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ó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

Forgatókönyv: Elavult 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 áttelepítésének koordinálása új eszközre

Forgatókönyv: Új alkalmazásmodell/ architektúra definiálása/ bevezetése

  • 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

Alkalmazásmegfelelőség naplózása (GDPR, akadálymentesség, infrastruktúraszabvá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 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.

A problémáktól a fogalmakig

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.

Készítse el az esetet a kezdeti befektetésekhez

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.

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

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.

Egyéb tippek

A kezdéstől függetlenül tartsa szem előtt az alábbi irányelveket.

Módosítás megtervezve

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.

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

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.

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

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 .

A minimális jogosultság elvének feltételezése

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, 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.

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

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.