Förbättra identifieringen och eliminera avfall genom inventeringar och relationsspårning
Allt eftersom din organisation växer, så ökar även mängden saker som du behöver hålla reda på. Du kan behöva spåra kod, API:er, containrar, virtuella datorer (VM), meddelandeämnen, gruppmedlemskap, projektägarskap med mera. När du skalar är det inte ovanligt att hitta duplicerade ansträngningar ofta eftersom ett team inte känner till den andra. När människor flyttar mellan team, nya personer går med i företaget och andra lämnar, kan projekt bli föräldralösa. Om det inte hanteras kan detta leda till teknisk spridning och slöseri bara för att du inte enkelt kan upptäcka vad som redan finns. Detta är en vanlig utmaning. Tänk dig till exempel det här citatet:
Vi har massor av containrar eller [VM]-instanser som körs. Kan vi ta bort våra gamla virtuella datorer? Ingen vet. Vi måste komma på ett sätt att rensa upp gamla saker och använda rätt taggar så att vi vet vem som är ägare eller team som kan informera oss om vad vi kan göra och vad livscykeln är.... Vi vet inte om vi kan stänga av en viss virtuell dator eftersom vi inte är säkra på vad som kommer att hända. - Martin, DevOps-tekniker, stort logistikföretag
Förbättra spårning, säkerhet och återanvändning genom skräddarsydda inventeringar
En del av det du behöver är en inventering som hjälper dig att spåra alla "saker" som du har skapat eller byggt i ditt ekosystem som interna kunder kan visualisera på ett begripligt sätt.
En inventering kan förbättra säkerheten, främja återanvändning och göra identifieringen enklare. Azure-distributionsmiljöer beskriver och spårar till exempel komplex infrastruktur som skapats via infrastruktur som kod (IaC) som en abstrakt miljö som är på en nivå som både utveckling och åtgärder kan förstå. På samma sätt är Azure API Center ett sätt för utvecklare att identifiera och använda API:er. Paketregister som GitHub Packages eller Azure Artifacts (eller andra inventeringar av godkända paket och SDK:er) förbättrar säkerheten i leveranskedjan. Vart och ett av dessa verktyg innehåller en inventering som hjälper dig att hantera, spåra och rensa avfall.
När du utvärderar hur du ska skapa eller tillämpa dessa lager är ett viktigt beslut att avgöra hur brett synligt deras innehåll ska vara. Tänk på att det inte finns något rätt eller fel svar här. Vissa företag har ett öppet kök där "alla kan se maten förberedas, men bara ett fåtal människor kan laga den." Med ett öppet kök har utvecklare full insyn i programvarutillgångarna men kan bara ändra de tillgångar som de ansvarar för. På motsvarande sätt kan reglerade företag ha strängare regler, där även synlighet för projektnamn anses vara känslig.
Förbättra identifiering och spårning genom relationer
Att ha ett eller flera inventeringssystem som hjälper dig att spåra vad du har är viktigt för plattformstekniksmetoder och för att undvika teknisk spridning. Det kan räcka med en uppsättning platta inventeringslistor från början. Men även om det inte krävs för att starta kan du också förbättra identifieringen genom att lägga till relationer mellan olika tillgångar i flera lager. Oavsett vilken synlighetsnivå du behöver kan team snabbt söka efter och identifiera alla tillgängliga tillgångar genom att ha en central aggregeringspunkt. Detta främjar återanvändning, minskar redundans och upprättar en konsekvent styrningsmetod.
Överväg relationen mellan en API-definition och den distribuerade programkod som implementerar gränssnittet. Den här koden lagras på en lagringsplats och hanteras av ett team och innehåller dokumentation om dess användning. Utvecklings-, test-, prod- och till och med tillfälliga sandbox-miljöer skapas. I molnbaserade scenarier kan miljöerna distribueras till ett delat Kubernetes-kluster. Utvecklingsteamet som skapar API:et och eventuella interna användare av det måste kunna få information om var och en av dessa saker, men hur resurserna relaterar är inte uppenbart.
Till att börja med kan du använda något så enkelt som en wiki-sida för att spåra hur varje sak relaterar till varandra. Men dokumentationen åldras snabbt och kan vara svår både hitta och parsa. Vi rekommenderar att du har ett system med ett relationsdiagram som kan använda användargränssnitt för att bläddra igenom dessa relationer i din inventering. För att verkligen förbättra identifieringen måste du kunna associera saker som lagras i flera typer av lager eller grafer. Du kanske inte behöver använda inventeringar direkt, men du vill förmodligen kunna associera det med information i ett API-katalogsystem.
Om du vill använda den digitala butiksanalogin kan det också vara användbart att associera objekten (mallarna) i katalogen med det resulterande inventeringsinnehållet. Om du till exempel inser att en av dina mallar skapar en osäker konfiguration måste du snabbt hitta alla resurser som skapades i mallen för att åtgärda dem. Även starta rätt programmallar är i huvudsak starter kit paket i den här katalogen som kopplas till andra typer av katalogobjekt (som IaC-mallar). Om du spårar dessa associationer kan du proaktivt hitta alla program som refererar till en felaktig IaC-mall även om ingen infrastruktur har etablerats ännu.
En förenklad variant av det här konceptuella plattformsdiagrammet för utvecklare på hög nivå finns i några verktyg och produkter idag, men vad det kallas varierar. Till exempel anropar portalverktyget med öppen källkod Backstage.io detta en programvarukatalog medan andra produkter använder olika termer. De flesta av dessa produkter och verktyg förutsätter dock att du använder deras bredare funktionsuppsättning och kräver att innehållet i dina lager dupliceras inuti dem. Den här dupliceringen innebär att innehållet i katalogdatabasen inte är användarspecifikt, kan bli inaktuellt och inte styrs av det faktiska källsystemets mekanismer för användarauktorisering. Detta kan dock fungera bra för din organisation om du följer ett öppet kök.