> p p = = ” meta “> Av Joe McKendrick för Service Oriented | 14 augusti 2021 – 10:00 GMT (11:00 BST) | Ämne: IT -prioriteringar
Författarna till Puppets senaste branschomfattande DevOps-undersökning har lite råd till DevOps-förespråkare: sluta kalla det “DevOps”. Det skapar bara förvirring. Och kom inte ens igång med DevSecOps. De kommer också med ytterligare en intressant nyhet: en väl utformad IT-arkitektur kan hjälpa till att lösa företagskulturella frågor.
Foto: Joe McKendrick
Det är ordet från Puppets State of DevOps -rapport från 2021, som inkluderar erfarenheter från 2650 IT-, utvecklings- och informationssäkerhetspersonal. Det är inte så att DevOps sjunker i popularitet – 83% implementerar DevOps, och många ser fördelar, inklusive snabbare leverans av kvalitetsprogram.
“Vi tror starkt att närvaron av” DevOps -team “är förvirrande för branschen och många organisationer, och i de flesta fall hjälper det inte organisationer att utvecklas”, författare av undersökningsrapporten, ledda av Nigel Kersten, CTO för Puppet och Kate McCarthy , rektor på ClearPath Strategies, stat. “Enligt vår erfarenhet har organisationer som har mindre tvetydiga lagnamn, med mer tydligt definierade ansvar, mycket mer sannolikhet att ha en bättre IT -funktion.”
DevOps-funktioner belastas vanligtvis med en rad olika ansvarsområden, inklusive följande som identifierats genom enkätundersökarnas självbeskrivningar av sina team:
Traditionell infrastruktur & amp; drift Systemadministration End-to-end produktansvar Stöd för utvecklingsteam med en kombination av release automation, distribution pipelines och verktyg Bygga de besvärliga saker som applikationsutvecklare inte vill eller behöver bry sig om: infrastruktur, containertyg, övervakning och mätvärden. möjliggör DevOps -metoder i en organisation
“Bristande tydlighet kring teamidentiteter skapar betydande organisatorisk friktion och hindrar mjukvaruleverans på olika sätt”, säger Kersten och McCarthy. “Vi föreslår att organisationer går bort från användningen av” DevOps “-team mot tydligare lagnamn, och i synnerhet att användningen av ströminriktade
– och plattformsteam är en väldefinierad väg för att uppnå DevOps-framgångar i stor skala.”
Med andra ord kan DevOps vara den mekanism genom vilken lagens mål uppnås, men är inte ett mål i sig. Och säkerhet bör byggas in i dessa insatser från början – inte en separat “DevSecOps” -insats.
Puppet -teamet tittade också på ett mindre segment, det de kallar “högutvecklade företag” som har sett större framgång med DevOps -tillvägagångssätt, för att spåra vad de gör annorlunda än sina släpande kamrater. Till att börja med använder de en plattformsmetod, “gör det möjligt för utvecklare att få åtkomst till autentisering (62 procent), behållare orkestrering (60%) och service-till-tjänst-autentisering (53%), spårning och observerbarhet (49%) och loggningsförfrågan (47%) tjänster via självbetjäning. ” Detta uppnåddes “genom att förstå deras interna kunder och erbjuda en kuraterad uppsättning teknologier för infrastruktur och utvecklingsmöjligheter på deras plattform.”
Team ser också annorlunda ut i högutvecklade företag, konstaterar Puppet -teamet. De använder “en kombination av ströminriktade team och plattformsteam som det mest effektiva sättet att hantera lagets kognitiva belastning i stor skala, och de har ett litet antal lagtyper vars roll och ansvar tydligt förstås av deras angränsande lag.” Som sagt, 91% av de högutvecklade lagen rapporterar en tydlig förståelse av sitt ansvar till andra lag, jämfört med endast 46% av lågutvecklade lag. Dessutom rapporterar 89% av högutvecklade team att medlemmar i det egna teamet har tydliga roller, planer och mål för sitt arbete, jämfört med bara 46% av lågutvecklade team.
Högutvecklade team oroar sig mindre om företagskulturella frågor som tenderar att hämma DevOps -insatser. Det är inte så att de är mindre oroliga för kulturen, utan snarare har de skapat en teknikbunt som gör att arbetsflöden och information kan skala och snabbt flytta dit det behövs, en som “utnyttjar betydande automatisering och investerar i interna plattformar, Kersten och McCarthy. Kort sagt, för högutvecklade företag är kultur inte längre ett hinder. “
Undersökningen visar till exempel att 84% av de högutvecklade företagen elastiskt kan tillhandahålla och släppa möjligheter – i vissa fall automatiskt – för att snabbt skala utåt och inåt i förhållande till efterfrågan. Endast 17% av lågutvecklade företag kan skala elastiskt, rapporterar undersökningen. På samma sätt kan utvecklare på 79% av de högutvecklade företagen tillhandahålla beräkningsmöjligheter, till exempel servertid och nätverkslagring, efter behov automatiskt – jämfört med bara 16% av företagen på den lägsta nivån av DevOps -utveckling.
Relaterade ämnen:
Collaboration CXO Thought Leadership Innovation Tech and Work 