A felderítés javítása és a hulladék eltávolítása leltározással és kapcsolatkövetéssel
Ahogy a szervezet növekszik, úgy nő a nyomon követendő dolgok mennyisége is. Előfordulhat, hogy nyomon kell követnie a kódot, az API-kat, a tárolókat, a virtuális gépeket, az üzenetkezelési témaköröket, a csapattagságot, a projekt tulajdonjogát stb. A méretezés során nem ritka, hogy gyakran találnak duplikatív erőfeszítéseket, mert az egyik csapat nem tud a másikról. Amikor az emberek a csapatok között mozognak, új személyek csatlakoznak a vállalathoz, és mások távoznak, a projektek elárvulhatnak. Ha nem kezelik, ez technikai sprawl és hulladékhoz vezethet egyszerűen azért, mert nem lehet könnyen felderíteni, ami már létezik. Ez egy gyakori kihívás. Vegyük például ezt az idézetet:
Rengeteg tároló vagy [VM] példány fut. Törölhetjük a régi virtuális gépeinket? Senki sem tudja. Ki kell találnunk egy módot a régi dolgok tisztítására és a megfelelő címkék használatára, hogy tudjuk, ki a tulajdonos vagy csapat, aki tájékoztathat minket arról, hogy mit tehetünk, és mi az életciklus.... Nem tudjuk, hogy le tudunk-e állítani egy adott virtuális gépet, mert nem tudjuk biztosan, hogy mi fog történni. - Martin, DevOps-mérnök, Large Logistics Company
A nyomon követés, a biztonság és az újrafelhasználás javítása testreszabott leltárakon keresztül
Egy készletre van szüksége, amely segít nyomon követni azokat a "dolgokat", amelyeket létrehozott vagy beépített az ökoszisztémában, amelyeket a belső ügyfelek érthető módon vizualizálhatnak.
A leltár javíthatja a biztonságot, előléptetheti az újrafelhasználást, és általában megkönnyíti a felderítést. Az Azure Deployment Environments például kódként (IaC) írja le és követi nyomon az infrastruktúrán keresztül létrehozott összetett infrastruktúrát olyan absztrakt környezetként , amely olyan szinten van, amelyet a fejlesztés és a műveletek egyaránt képesek megérteni. Hasonlóképpen, az Azure API Center lehetővé teszi a fejlesztők számára az API-k felderítését és használatát. Az olyan csomagregisztrációs adatbázisok, mint a GitHub Packages vagy az Azure Artifacts (vagy a jóváhagyott csomagok és SDK-k egyéb leltárai) javítják az ellátási lánc biztonságát. Ezen eszközök mindegyike készletet biztosít a hulladék kezeléséhez, nyomon követéséhez és tisztításához.
A leltárak létrehozásának vagy alkalmazásának értékelésekor fontos döntés annak meghatározása, hogy milyen széles körben látható legyen a tartalmuk. Ne feledje, hogy itt nincs jó vagy rossz válasz. Egyes vállalatok egy nyitott konyha megközelítés, ahol "mindenki láthatja, hogy az élelmiszer készül, de csak néhány ember tudja főzni." A nyílt konyhával a fejlesztők teljes körűen láthatják a szoftvereszközöket, de csak azokat az eszközöket módosíthatják, amelyekért ők felelősek. Ezzel szemben a szabályozott vállalatok szigorúbb szabályokkal rendelkezhetnek, ahol még a projektnevek láthatósága is érzékenynek tekinthető.
Felderítés és nyomon követés javítása kapcsolatokon keresztül
A platformmérnöki eljárások szempontjából kritikus fontosságú egy vagy több leltárrendszer használata, amelyek segítenek nyomon követni, és elkerülik a műszaki sprawlot. Kezdetben elegendő lehet, ha egy készletlistából álló készletkészletet hoz létre. Bár a kezdéshez nem szükséges, a felderíthetőséget is javíthatja, ha több leltárban lévő különböző eszközök közötti kapcsolatokat ad hozzá. A szükséges láthatósági szinttől függetlenül a központosított összesítési ponttal a csapatok gyorsan kereshetnek és felderíthetik a számukra elérhető összes eszközt. Ez elősegíti az újrafelhasználást, csökkenti a redundanciát, és konzisztens szabályozási megközelítést hoz létre.
Fontolja meg az API-definíció és az interfészt implementáló üzembe helyezett alkalmazáskód közötti kapcsolatot. A kód tárolása egy adattárban történik, amelyet egy csapat kezel, és dokumentációt nyújt a használatáról. Dev, test, prod és még ideiglenes tesztkörnyezetek is létrejönnek. Natív felhőbeli forgatókönyvekben előfordulhat, hogy a környezetek egy megosztott Kubernetes-fürtön lesznek üzembe helyezve. Az API-t fejlesztő fejlesztői csapatnak és annak minden belső fogyasztójának képesnek kell lennie az egyes dolgokkal kapcsolatos információk beszerzésére, de az erőforrások összefüggése nem egyértelmű.
Első lépésként használjon egy olyan egyszerű wikilapot, amely segít nyomon követni, hogyan kapcsolódnak egymáshoz az egyes objektumok. A dokumentáció azonban gyorsan öregszik, és nehéz lehet megtalálni és elemezni is. Ideális esetben egy kapcsolati grafikont tartalmazó rendszerrel rendelkezik, amely képes arra, hogy a felhasználói felületek a leltárban keresztül haladjanak ezen kapcsolatokon. A felderíthetőség javításához képesnek kell lennie több típusú leltárban vagy gráfban tárolt dolgok összekapcsolására. Előfordulhat, hogy nem kell közvetlenül felhasználnia a készleteket, de valószínűleg egy API-katalógusrendszer információihoz szeretné társítani.
A digitális tár analógiának használatához hasznos lehet a katalógusban található elemeket (sablonokat) társítani az eredményként kapott készlet tartalmához. Ha például rájön, hogy az egyik sablon nem biztonságos konfigurációt hoz létre, gyorsan meg kell találnia a sablont létrehozó összes erőforrást a javításukhoz. Még a megfelelő alkalmazássablonok is alapvetően kezdőcsomagok ebben a katalógusban, amelyek más típusú katalóguselemekhez (például IaC-sablonokhoz) kapcsolódnak. Ezeknek a társításoknak a nyomon követésével proaktívan megkeresheti azokat az alkalmazásokat, amelyek rossz IaC-sablonra hivatkoznak még akkor is, ha még nincs kiépítve infrastruktúra.
Ennek a fogalmi, magas szintű fejlesztői platformdiagramnak egy egyszerűsített változata ma néhány eszközkészletben és termékben megtalálható, bár az úgynevezett változó. A nyílt forráskódú portál eszközkészlete például Backstage.io szoftverkatalógusnak hívja, míg más termékek más kifejezéseket használnak. A legtöbb termék és eszközkészlet azonban feltételezi, hogy a szélesebb körű funkciókészletet használja, és megköveteli a készletek tartalmának duplikálását bennük. Ez a duplikálás azt jelenti, hogy a katalógus-adatbázis tartalma nem felhasználóspecifikus, elavulttá válhat, és nem a tényleges forrásrendszer felhasználói engedélyezési mechanizmusai vezérlik. Ez azonban jól működik a szervezet számára, ha nyitott konyhai megközelítést követ.
További információ azokról a fogalmakról, amelyek segíthetnek.