Esettanulmányok: Három platformmérnöki implementáció

Bár a platformmérnöki képességek modellel történő implementálásának különböző megközelítései vannak, a felhasználói kutatások azt mutatják, hogy a Microsoft-ügyfelek többsége három ügyfélszegmens egyikébe tartozik: a feltörekvő újító, a stratégiai fejlesztő és a platform úttörője. Ez a cikk végigvezeti egy esettanulmányon az egyes szegmensekben lévő valódi ügyfelek számára. A cégnevek el lesznek távolítva az adatvédelem érdekében.

Feltörekvő újító: Biztosítótársaság

Ügyfélszegmens	Fókuszterületek	Csoportméret	Szervezeti jellemzők	Gyakoriság
Feltörekvő újító	Gyors termékfejlesztés, manuális folyamatok automatizálása, hatékonysági problémák kezelése	1–5 (DevOpsból vagy felhőinfrastruktúra-csapatokból)	Azonosítja a szűk keresztmetszeteket a teljesítés javítása érdekében, és kezdi felismerni a szervezeti szintű megoldások iránti igényt	Második leggyakoribb

Egy nagy biztosítótársaság rájön, hogy különböző infrastruktúrával rendelkeznek, amelyek egy nagy technológiai verem között oszlanak el. Több platform és környezet létezik, és a fejlesztőknek nem sok módja van arra, hogy más csapatokra támaszkodva kezdjenek hozzá. A vállalatnak csökkentenie kell a növekvő munkaerőköltségeket, és szabványosítottabb rendszerekkel kell rendelkeznie.

"A fordulópont meglehetősen egyszerű volt. Tekintettel arra, hogy több mérnöki platformunk van, több infrakörnyezetünk, beleértve a hibridet is, nincsenek önkiszolgáló fejlesztői portálképességeink, és három hatalmas különböző stackünk van az architektúránkban, be kellett vezetnünk valami hasonlót, mint a Terraform, vagy egy nagyvállalati szintű megoldást, például a GitLab vagy a GitHub. A végpontok közötti tárolóalapú platformok kezeléséhez az OpenShifthez, az Ansible-hez a munkafolyamat-automatizáláshoz és a Backstage-hez hasonlót tekintettünk az idP-hez. Hatalmas értékelést hajtottunk végre, hogy szinergiát hozzunk létre egy ilyen nagy technológiai verem környezeten... Ez egy nagyon egyszerű költségszámítás arra, hogy 30%-kal csökkentsük a munkaerőt vagy a fejlesztői bázist." - A főépítész, a biztosítótársaságnál

Kihívás: Elsődleges kihívásaik a felhőköltségek emelkedése, a megfelelőségi problémák, az infrastruktúra-tervezési szakértelem hiánya, a nem megfelelő folyamatok és az inkonzisztens csapatkommunikáció.

A biztosítótársaság azt tervezi, hogy minden fejlesztési és üzembe helyezési tevékenységhez egységes platformot implementál az együttműködés elősegítése, a projektbeállítás felgyorsítása és a szabályozás egyszerűsítése érdekében. A vállalat mind az öt fő platform mérnöki hajtóerejének növekedésére összpontosít.

Befektetés: A vállalat egy külső partnerrel együttműködve implementálja a platformfejlesztést egy buildelési, üzemeltetési és átviteli (BOT) modell használatával. A külső partner fejleszti és működteti a platformot, mielőtt visszaküldené azt a szervezetnek, miután megszerezték a belső felügyelethez szükséges szakértelmet és kapacitást.

Örökbefogadás: Jelentős belső ellenállás áll fenn az új eljárások bevezetése ellen. A fejlesztők nem szeretnének átállni a hagyományos módszerekről az újabb platformokra és eszközkészletekre. Ennek leküzdése érdekében a szervezet vezetése a platformfejlesztés bevezetésére ösztönöz azáltal, hogy a hatékonysági előnyökhöz és az alkalmazottak céljainak részévé teszi azt.

Kormányzás: A megfelelőségért és a biztonságért a vállalati tervezési és üzembe helyezési (EPD) csapat felel. A központosított irányítási struktúra célja a magas biztonság fenntartása és a biztonsági rések elkerülése, ami kihívást jelent a decentralizáltság számára. A fejlesztők számára az üzembe helyezés demokratizálása felé halad a szabályozási protokollok fenntartása az adatszivárgások megelőzése és a megfelelőség biztosítása érdekében. A cél az, hogy egyensúlyt teremtsen a biztonság és az agilitás között.

Kiépítés: A vállalat egy integráltabb és önkiszolgálóbb modell alkalmazásával javítja a hatékonyságot, és csökkenti a kiépítési időt. A változás kulcsfontosságú hajtóereje a kiépítésre fordított idő és erőforrások lehetséges csökkentése.

Felületek: A szervezet nyílt forráskódú rugalmassága, költséghatékonysága és fejlesztői ismerete érdekében alkalmazza a Backstage-t. A cortexet is figyelembe vették. A Backstage kiválasztását a költségek és az integrációs képességek vezérelték.

Mérések és visszajelzések: Nehéz volt áttérni egy értelmesebb visszajelzési rendszerre, mert a vállalat régi mérési rendszerrel rendelkezik, és a műszaki metrikákat az üzleti KPI-khez kell igazítania. A vállalat azt tervezi, hogy a mérnöki munka és az üzleti eredmények összehangolásán dolgozik egy integráltabb mérési megközelítés érdekében. Az átállás során a vállalat olyan eszközöket és platformokat ad hozzá, amelyek valós idejű elemzést és megfigyelhetőséget biztosítanak.

Stratégiai tervező: Pénzügyi intézmény

Ügyfélszegmens	Fókuszterületek	Csoportméret	Szervezeti jellemzők	Gyakoriság
Stratégiai építő	Együttműködés, redundáns munka csökkentése, megosztott megoldások, szabványosítás, költségkezelés	1-15 műszaki szakértő (fejlesztők és infrastruktúra-szakemberek)	A vezetőség ügyfélként tekint a fejlesztőkre, részben integrált platformmérnöki funkciókkal (az önkiszolgáló funkció nem teljesen elfogadott)	Leggyakoribb

A pénzügyi intézmény a DevOps-érettség középszintjén van, néhány újrafelhasználható központi összetevővel, szabványosított irányelvekkel és alapszintű automatizálással, kóddal felügyelve. A szervezet elérte azt a pontot, ahol a fejlesztési csapatok mérete és eszközei és gyakorlatai sokfélesége jelentős költségeket okoz. Az intézmény több ezer egyéni eszközt használt a vállalaton belül, és számos összetett szervezeti igényt is kielégített. A bank azt tervezi, hogy "arany utat" kínál a fejlesztőknek a termelékenység javítása érdekében, amely rugalmasságot épít be, és elkerüli az egy méretre illeszkedő megközelítést.

Tehát az volt az ötlet, hogy megmutatjuk a fejlesztőknek, hogy ez az arany út egy módszer a dolgok elvégzésére, ami javítja a termelékenységet, de nem ez az egyetlen módszer. Ugye? Ezért elég helyet akartunk hagyni a fejlesztőnek, hogy úgy érezzék, hogy ők is képesek változtatni ezen az úton, amit mondunk nekik. Tehát amikor ezeket az útvonalakat definiálják a CTO-csapatban, a kérdés mindig az, hogy milyen útvonalakat kell meghatározni, amelyek a bankban lévő emberek többségének működni fognak? Mint mondtam, nagyon összetettek vagyunk. Több ezer eszközt használnak a bankban. Mindig az volt a legnagyobb probléma, hogy egy megoldás mindenkire alkalmazható." - ügyvezető igazgató, pénzintézet

Kihívás: Elsődleges kihívásuk a sok különböző eszköz és gyakorlat miatt jelentkező magas költségek és hatékonysági problémák. A vállalat biztosítani szeretné, hogy a platform megfeleljen az egyes csapatok egyedi igényeinek anélkül, hogy problémákat okozna, vagy hogy túlságosan irányelvalapú megközelítés lenne, amely akadályozhatja a bevezetést. A pénzintézet emellett nem rendelkezik az egyéni platformmegoldások házon belüli fejlesztéséhez szükséges szakértelemmel.

A pénzintézet három fő hajtóerő, a bevezetés, az irányítás, valamint a kiépítés és a felügyelet növekedésére szeretne összpontosítani. A bank növelni szeretné a platformmérnöki megoldás bevezetését, jobban integrálja a szabályozást, és automatizált erőforrás-kiépítési eszközöket szeretne létrehozni.

Befektetés: A pénzintézet egy központi mérnöki csapattal rendelkezik, amelynek 120 embere világszerte több helyen is jelen van. Körülbelül 20 tag alkotja a kiválósági központot (COE). A COE csapata a mérnöki ajánlott eljárásokat, a platformot és a DevOps-gyakorlatokat ismerteti az összes többi üzleti részlegben.

Örökbefogadás: A platformmérnöki csapat a COE-csapat által a mérnöki műveletek irányításához beállított szabályzatok kikényszerítésére összpontosít. A vállalat azt is tervezi, hogy nyilvánosan látható teljesítménymetrikákkal motiválja a csapatokat. Összességében a bank szigorú irányelvek és metrikák nélkül szeretné növelni a platformhasználatot. A COE-csapat továbbképzése során azonban kihívást jelent számukra a mérnöki csapatok által használt technológiák széles körű kezelése. Jelentős akadály, hogy a platform nem felel meg az egyes csapatok egyedi igényeinek, ami problémákat okozhat.

Kormányzás: A platformmérnöki megoldás egy belsőleg fejlesztett portál, amely központi központként szolgál a fejlesztők számára, eszközöket, útmutatókat, kódolási szabványokat és videókat kínálva. A megoldás tartalmaz egy tesztet a minimális vállalati követelményekről (MERS), amely biztosítja a megfelelőséget a kódolás megkezdése előtt. A portálon elérhető a Stack Overflow támogatási verziója, a minősített mérnökprofilok, valamint az új fejlesztők szabványokkal és eszközökkel való megismerkedése. A vállalat azt tervezi, hogy egyszerűsíti az erőforrás-kezelést, és integrálja a szabályozást a fejlesztési életciklusba, megszünteti a szűk keresztmetszeteket, és modern eszközkészlettel vonzza a legjobb technikai tehetségeket.

Kiépítés: A COE csapata "boldog utakat" hozott létre a fejlesztők számára, hogy a rugalmasság fenntartása mellett növeljék a termelékenységet. A cél az, hogy hatékony útvonalat kínáljon, miközben lehetővé teszi a testreszabást. Ezeknek az útvonalaknak a tervezésekor a CTO csapata a legtöbb fejlesztőt kiszolgálja, de a bank összetettsége, több ezer használatban lévő eszközzel, szabványosított megközelítést tesz lehetővé. A platform skálázásához a szervezet automatizált erőforrás-kiépítést tervez megvalósítani, hogy megfeleljen a számos mérnöki csapat különböző igényeinek.

Felületek: A belső fejlesztői portál elsősorban házon belül készült. Belsőleg DevOps-portálnak nevezik, bár a DevOpson túl szélesebb körű platformmérnöki funkciókat is magában foglal. A portál központosított erőforrásként szolgál a fejlesztők számára, és különféle eszközöket, tananyagokat, videókat és képzéseket tartalmaz, valamint hozzáférést biztosít az automatizálási eszközökhöz, önindító útmutatókhoz és tárolóalapú rendszerképekhez a fejlesztéshez. A portál olyan biztonsági eszközökkel is integrálva van, mint a Sonatype a kódkereséshez, és tartalmazza a jóváhagyott rendszerképek és a sablonkódok beállításjegyzékét.

Mérések és visszajelzések: A COE csapata nyitott a visszajelzésekre, és aktívan kér a mérnöki csapatoktól. A fejlesztői tanácsadók és a nagykövetek visszajelzést is gyűjtenek a COE-csapat nevében. A visszajelzési folyamat többnyire informális.

Platform úttörője: Szoftvervállalat

Ügyfélszegmens	Fókuszterületek	Csoportméret	Szervezeti jellemzők	Gyakoriság
Platform úttörője	A fejlesztők ügyfelekként való kezelése, a platform termékként való kezelése, erős fejlesztői élmény	16+ speciális csoportokkal	Hangsúlyozza az elszámoltathatóságot, a felhatalmazást és az innovációt, elősegíti az önkiszolgálást és a minimális kontextusváltást.	Legkevésbé gyakori

A szoftvervállalat magas szintű DevOps-fejlettséggel rendelkezik. A vállalat fejlesztői a vállalati irányelveknek megfelelően önkioszthatják a felhőszolgáltatásokat. A vállalat több mint 250 tagú nagy platformcsapata sikeresen kifejlesztett egyéni platformfejlesztési megoldásokat a szervezet számára. A vállalat azt tervezi, hogy megvizsgálja, hogyan fejleszthetik tovább szervezetüket a platformfejlesztéssel.

"Hogyan hagyhatjuk, hogy a fejlesztők gyorsabban és (olcsóbban) jobb szoftvereket nyújtsanak ?.. Még mindig meg kell vizsgálnunk és be kell fektetnünk abba, hogy mi lehet az ideális megoldás, amely a többfelhős stratégiánkhoz használható... van egy olyan rendszer, amely a fejlesztők igényeinek megfelelően méretezhető?.. A dokumentáció és az információk felderítéséhez házon belül beépített, generatív AI- és AI-alapú megoldásokat használunk. Célunk, hogy a fejlesztők elszámoltathatók legyenek." - vezető mérnöki vezető, szoftvervállalat

Kihívás: A vállalat elsődleges feladata, hogy kitalálja, hogyan finomíthatja tovább a már erős platformmérnöki gyakorlatait olyan módon, hogy pénzt takarítson meg, fedezze fel a generatív MI-t, növelje a bevezetést, és dolgozzon egy többfelhős környezetben.

A szoftvervállalat négy fő hajtóerőt tervez növelni: a beruházásokat, az bevezetést, a kiépítést és a felügyeletet, valamint a felületeket. A szoftvervállalat már magas szintű mérnöki szinten működik, és folytatni szeretné. A vállalat azt tervezi, hogy megvizsgálja a generatív MI (irányítás mellett) integrálásának, a platform elterjedésének növelésének és a metrikákra alapozott visszajelzési ciklusok megvalósításának módszereit.

Befektetés: A platformot a CTO és a CFO irodák együttműködésével finanszírozzák és támogatják. Az erőforrások átcsoportosításával létrehozott dedikált platformcsapat 250-280 tagot tartalmaz, például építészeket és mérnököket. A csapat felügyeli a számítást, a futtatókörnyezetet, a CI/CD-t, az eszközöket és a megfigyelhetőséget, a költséghatékonyságra összpontosítva. Generatív AI-t vizsgálnak az infrastruktúra méretezhetősége érdekében, de felismerik, hogy további kutatásokra és beruházásokra van szükség.

Örökbefogadás: A fejlesztők kezdetben elsősorban a költségoptimalizálás és a hatékonyság érdekében alkalmazták a platformot, amelyet a világjárvány vezérel. A belső kampányok, beleértve a hackathonokat, elősegítik a platformot, és olyan előnyöket mutatnak be, mint a szolgáltatás fejlettségi elemzései. A platform csapata nehezen győzte meg néhány csapatot, hogy a meglévő beállításokról a platformra lépjenek.

Kormányzás: A platform szabályozási modellje egy központi platformcsapat köré épül, amely az alapvető elemeket kezeli. Az egyes szolgáltatási csapatok beépülő modulokat adnak hozzá. Az összes közreműködésre vonatkozóan van egy felülvizsgálati folyamat, amely ellenőrzi, hogy azok megfelelnek-e a szervezeti szabványoknak, és megfelelnek-e a szélesebb igényeknek. A platformcsapat egy szolgáltatáskatalógust és szolgáltatástérképet tart fenn a metaadatok és függőségek nyomon követéséhez, amely segít az elszámoltathatóság és az erőforrás-kezelés biztosításában. Emellett külön szabályozási testületet hoztak létre kifejezetten az AI-alkalmazások számára a használatuk kezeléséhez és a szabványoknak való megfelelés biztosításához.

Kiépítés: A platformcsapat központosított, mégis rugalmas platformot biztosít az erőforrások létrehozásához, üzembe helyezéséhez és felügyeletéhez. A platform a Kubernetesre épül, és Argo CD-t használ a CI/CD-hez. Az eszköz egyénileg létrehozott sablonokat és előre definiált munkafolyamatokat kínál. A platform tartalmaz egy fejlesztői otthont, ahol a felhasználók kezelhetik az infrastruktúra életciklusát az üzembe helyezéstől az üzembe helyezésig. A Teams személyre szabott beépülő modulokkal bővíti a funkciókat. A cél a többfelhős infrastruktúra zökkenőmentes kezelése skálázható platformmal.

Felületek: A fejlesztők a platform fejlesztői otthonát használják az infrastruktúra, a kiépítés és a teljes fejlesztési életciklusuk kezelésére. A platform beépülő modulalapú architektúrája lehetővé teszi a testreszabást, míg a generatív AI javítja a dokumentációt és a kereshetőséget.

Mérések és visszajelzések: A szervezet felméréseken keresztül gyűjti a visszajelzéseket, és olyan metrikákat használ, mint a DORA (üzembe helyezés gyakorisága, átfutási idő, változási hibák aránya és a helyreállítás átlagos ideje) a platform hatékonyságának felméréséhez. Ezek a metrikák agilitásra és stabilitásra vannak kategorizálva a szűk keresztmetszetek azonosításához és az eredmények javításához.