Forfatterne til Puppets seneste DevOps-undersøgelse i hele branchen har lidt råd til DevOps-tilhængere: stop med at kalde det “DevOps.” Det skaber kun forvirring. Og kom ikke engang i gang med DevSecOps. De bringer også en anden interessant nyhed: en veldesignet it-arkitektur kan hjælpe med at løse virksomhedskulturelle problemer.
Foto: Joe McKendrick
Sådan lyder ordet fra Puppets State of DevOps -rapport fra 2021, som omfatter erfaringer fra 2.650 fagfolk inden for IT, udvikling og informationssikkerhed. Det er ikke, at DevOps falder i popularitet – 83% implementerer DevOps, og mange ser fordele, herunder hurtigere levering af kvalitetssoftware.
“Vi tror stærkt på, at tilstedeværelsen af” DevOps -teams “er forvirrende for industrien og mange organisationer, og i de fleste tilfælde hjælper det ikke med at udvikle organisationer,” siger undersøgelsens rapportens forfattere, ledet af Nigel Kersten, CTO for Puppet og Kate McCarthy , rektor ved ClearPath Strategies, stat. “Vores erfaring er, at organisationer, der har mindre tvetydige teamnavne, med mere klart definerede ansvarsområder, er langt mere tilbøjelige til at have en it -funktion, der fungerer bedre.”
DevOps-funktioner har typisk en række ansvarsområder, herunder følgende identificeret gennem undersøgelsessvarendes selvbeskrivelser af deres teams:
Traditionel infrastruktur & amp; operationer Systemadministration End-to-end produktansvar Understøttelse af udviklingsteam med en kombination af frigivelsesautomatisering, implementeringsrørledninger og værktøj Opbygning af de akavede ting, som applikationsudviklere ikke ønsker eller skal bekymre sig om: infrastruktur, containerstoffer, overvågning og metrics. muliggøre DevOps -praksis på tværs af en organisation
“Manglende klarhed omkring teamidentiteter skaber betydelig organisatorisk friktion og hindrer softwarelevering på forskellige måder,” rådgiver Kersten og McCarthy. “Vi foreslår, at organisationer bevæger sig væk fra brugen af” DevOps “-team mod tydeligere teamnavne, og især at brugen af stream-tilpassede
– og platformteam er en veldefineret vej til at opnå DevOps-succes i stor skala.”
Med andre ord kan DevOps være den mekanisme, hvormed teams mål opnås, men er ikke et mål i sig selv. Og sikkerhed bør være indbygget i disse bestræbelser fra starten – ikke en separat “DevSecOps” indsats.
Puppet -teamet kiggede også på et mindre segment, det de kalder “højt udviklede firmaer”, der har oplevet større succes med DevOps -tilgange, for at spore, hvad de gør anderledes end deres halende jævnaldrende. Til at begynde med tager de en platformstilgang “, der gør det muligt for udviklere at få adgang til godkendelse (62 procent), containerorkestrering (60%) og service-til-service-godkendelse (53%), sporing og observerbarhed (49%) og logningsanmodning (47%) tjenester via selvbetjening. ” Dette blev opnået “ved at forstå deres interne kunder og tilbyde et kurateret sæt teknologier til infrastruktur og udviklingsmuligheder på deres platform.”
Hold ser også anderledes ud i højt udviklede virksomheder, observerer Puppet -teamet. De anvender “en kombination af strømjusterede teams og platformsteam som den mest effektive måde at håndtere teamets kognitive belastning på i skala, og de har et lille antal holdtyper, hvis rolle og ansvar klart forstås af deres tilstødende teams.” Oplysende rapporterer 91% af højt udviklede teams en klar forståelse af deres ansvar over for andre teams sammenlignet med kun 46% af lavudviklede teams. Derudover rapporterer 89% af højt udviklede teams, at medlemmer af deres eget team har klare roller, planer og mål for deres arbejde sammenlignet med kun 46% af lavudviklede teams.
Meget udviklede teams bekymrer sig mindre om virksomhedskulturelle spørgsmål, der har en tendens til at hæmme DevOps -indsatsen. Det er ikke, at de er mindre bekymrede for kulturen, men snarere har de skabt en teknologisk stak, der gør det muligt for arbejdsgange og information at skalere og flytte hurtigt til det sted, det er nødvendigt, en der “udnytter betydelig automatisering og investerer i interne platforme, Kersten og McCarthy. Kort sagt, for højt udviklede virksomheder er kultur ikke længere en barriere. “
For eksempel viser undersøgelsen, at 84% af de højt udviklede virksomheder elastisk kan levere og frigive muligheder – i nogle tilfælde automatisk – for hurtigt at skalere udad og indad i forhold til efterspørgslen. Kun 17% af lavudviklede virksomheder kan skalere elastisk, rapporterer undersøgelsen. På samme måde kan udviklere i 79% af de højt udviklede virksomheder levere computermuligheder, f.eks. Servertid og netværkslagring, efter behov automatisk – mod kun 16% af virksomhederne på det laveste niveau af DevOps -udvikling.
Relaterede emner:
Collaboration CXO Thought Leadership Innovation Tech and Work