Er det svært at fange essensen, når man taler om DevOps? Vi har samlet klare analogier, præcise formuleringer og råd fra eksperter, der hjælper selv ikke-specialister med at forstå essensen. Som bonus er der en egen DevOps fra Red Hat-medarbejdere.
Begrebet DevOps opstod for 10 år siden og har bevæget sig fra et hashtag på Twitter til en kraftfuld kulturbevægelse i IT-verdenen, en ægte filosofi der opfordrer udviklere til hurtigt at opnå resultater, eksperimentere og fremme deres arbejde gennem iterationer. DevOps er blevet uadskilleligt knyttet til begrebet digital transformation. Men som det ofte ses med IT-terminologi, har DevOps i løbet af et årti fået mange definitioner, fortolkninger og misforståelser.
Derfor hører man ofte spørgsmål som, er det det samme som agile? Eller er det en speciel metode? Eller er det bare et andet synonym for ordet 'samarbejde'?
DevOps omfatter mange forskellige koncepter (kontinuerlig levering, kontinuerlig integration, automatisering osv.), så det kan være svært at fremhæve hovedpunkterne, især når man har en interesse i emnet. Men denne evne er meget nyttig, uanset om du prøver at kommunikere dine idéer til ledelsen eller fortæller om dit arbejde til familiemedlemmer eller bekendte. Så lad os sætte de terminologiske nuancer af DevOps til side og fokusere på det overordnede billede.
Hvad er DevOps: 6 definitioner og analogier
Vi har bedt eksperter om at forklare essensen af DevOps så enkelt og kort som muligt, så dens værdi bliver tydelig for læsere med enhver teknisk baggrund. Efter disse samtaler har vi udvalgt de mest markante analogier og præcise formuleringer, der hjælper dig med at opbygge din fortælling om DevOps.
1. DevOps – det er en kulturbevægelse
«DevOps – det er en kulturbevægelse, hvor begge sider (softwareudviklere og IT-driftsspecialister) anerkender, at software ikke giver reel værdi, før nogen begynder at bruge det: kunder, klienter, medarbejdere, det er ligegyldigt,» siger Eveline Oehrlich, senior analytiker-researcher ved DevOps Institute. «Derfor sikrer begge parter sammen hurtig og kvalitetsmæssig levering af software.»
2. DevOps – det er det, der giver udviklerne magt
«DevOps giver udviklere beføjelser til at eje applikationer, starte dem og styre leveringen fra start til slut»
«Normalt taler man om DevOps som en måde at fremskynde levering af applikationer til produktion ved at opbygge og anvende automatiserede processer, – siger Jai Schniepp, direktør for DevOps-platforme i forsikringsselskabet Liberty Mutual. – Men for mig er det en meget mere grundlæggende ting. DevOps giver udviklere beføjelser til at eje applikationer eller specifikke dele af software, til at starte dem og styre leveringen fra start til slut. DevOps fjerner forvirringen omkring ansvar og fører alle deltagere i processen mod at skabe en automatiseret og udviklerstyret infrastruktur».
3. DevOps er samarbejde om skabelse og levering af applikationer
«Kort sagt er DevOps en tilgang til produktion og levering af software, hvor alle arbejder sammen», – bemærker Gur Staff, præsident og leder af digital forretningsautomatisering hos BMC.
4. DevOps er en samlebåndsproces
«Samlebåndsproduktion er kun mulig, hvis alle dele passer sammen».
«Jeg ville sammenligne DevOps med samlebåndet i bilproduktionen, – fortsætter Gur Staff. – Ideen er at designe og lave alle dele på forhånd, så de senere kan samles uden individuel tilpasning. Samlebåndsproduktion er kun mulig, hvis alle dele passer sammen. Dem, der designer og laver motoren, skal tænke over, hvordan den skal fastgøres til karrosseriet eller rammen. Dem, der laver bremserne, skal tænke over hjulene, og så videre. Det skal være det samme med softwaren.
Udvikleren, der skaber forretningslogik eller brugerflade, skal tænke over databasen, der opbevarer oplysninger om kunderne, over sikkerhedsforanstaltningerne for at beskytte brugerdata, samt hvordan alt dette vil fungere, når tjenesten begynder at betjene et stort, måske endda millionpublikum af brugere».
«At skabe samarbejde blandt mennesker og få dem til at tænke på de dele af arbejdet, som andre udfører, i stedet for kun at fokusere på deres egne opgaver, er den største hindring, der skal overvindes. Hvis man lykkes med dette, får man fremragende chancer for digital transformation», tilføjer Gur Staff.
5. DevOps er den rigtige kombination af mennesker, processer og automatisering
Jayne Groll, administrerende direktør for DevOps Institute, præsenterede en fremragende analogi til at forklare DevOps. Ifølge hende: «DevOps er som en opskrift, der har tre hovedkategorier af ingredienser: mennesker, processer og automatisering. De fleste af disse ingredienser kan komme fra andre områder og kilder: Lean, Agile, SRE, CI/CD, ITIL, ledelse, kultur, værktøjer. Hemmeligheden bag DevOps, ligesom enhver god opskrift, er at finde de rigtige proportioner og blande disse ingredienser for at øge hastigheden og effektiviteten i arbejdet med at udvikle og levere applikationer».
6. DevOps er, når programmører arbejder som et Formel 1-hold
«Løbet planlægges ikke fra start til mål, men derimod fra mål til start».
«Når jeg taler om, hvad man kan forvente af en DevOps-initiativ, giver jeg et eksempel på et racingteam i NASCAR eller Formel 1, – siger Chris Short, hovedmarkedsføringschef for Red Hats cloud platforms og udgiver af nyhedsbrevet DevOps'ish. – En teamleder har én mål: at ende så højt som muligt i løbet, givet de ressourcer teamet har haft og de udfordringer, de har mødt. Løbet planlægges ikke fra start til mål, men derimod fra mål til start. Først sættes et ambitiøst mål, hvorefter man definerer veje til at nå det. Derefter opdeles de i delopgaver og delegeres til teammedlemmerne».
«Hele ugen før løbet finpudser teamet pitstop. De træner i styrke og kondition for at være i god form på den udmattende racedag. De øver teamwork for at håndtere eventuelle problemer, der måtte opstå under løbet. På samme måde bør udviklingsteamet træne evnerne til at frigive nye versioner hyppigt. Med disse færdigheder og et velfungerende sikkerhedssystem kan lanceringen af nye versioner i produktion også ske oftere. I denne tankegang betyder øget hastighed øget sikkerhed,» siger Short.
«Det handler ikke om at gøre ‘de rigtige ting’, – tilføjer Short, – men om at fjerne så mange hindringer som muligt på vejen mod det ønskede resultat. Samarbejd og tilpas jer ud fra den feedback, I får i realtid. Vær forberedt på afvigelser og arbejd på at forbedre kvaliteten for at mindske deres indvirkning på målet. Det er præcis, hvad der venter os i DevOps-verdenen.»
Hvordan man skalerer DevOps: 10 råd fra eksperter
Simpel DevOps og masseskala DevOps er to helt forskellige ting. Vi vil fortælle, hvordan man overvinder barriererne fra det første til det andet.
For mange organisationer begynder vejen til DevOps let og tiltalende. Små passionerede teams oprettes, gamle processer erstattes af nye, og de første succeser lader ikke vente på sig.
Desværre er dette blot falsk glans, en illusion af fremskridt, som Ben Grinnell, Managing Director og leder af det digitale rådgivningsområde i North Highland, siger. Tidlige sejre er selvfølgelig opmuntrende, men hjælper ikke med at nå det endelige mål, nemlig massebrug af DevOps i organisationen.
Det er let at se, at der dannes en kultur af opdeling mellem ‘vi’ og ‘de’.
«Ofte lancerer organisationer sådanne banebrydende projekter i håbet om, at de vil banebryde vejen for bredt DevOps, uden at tænke over, om andre ønsker at gå denne vej,« forklarer Ben Grinnell. «Teams, der arbejder med sådanne projekter, sammensættes ofte af overbeviste 'vikingere', som allerede har lavet noget lignende andre steder, men som er nye i jeres organisation. De opmuntres til at bryde og omgå de regler, der fortsat gælder for alle andre. Det er nemt at se, at resultatet bliver en kultur, hvor der skabes en kløft mellem 'vi' og 'de', hvilket hæmmer overførsel af viden og færdigheder.«
«Og dette kulturelle problem er blot en af årsagerne til, at DevOps er svært at skalere. DevOps-teams står over for stigende tekniske kompleksiteter, som er typiske for hurtigt voksende virksomheder, der har satset på IT-teknologier,« siger Steve Newman, grundlægger og formand for Scalyr.
«I den moderne verden ændres tjenester straks, så snart behovet opstår. At implementere og lancere nye funktioner er selvfølgelig fantastisk, men at koordinere denne proces og håndtere opståede problemer er en ægte hovedpine,« tilføjer Steve Newman. «I meget hurtigt voksende organisationer kæmper ingeniører i tværfunktionelle teams for at bevare muligheden for at følge med i ændringerne og de deraf følgende kaskadeeffekter på afhængigheder. Desuden er ingeniører bestemt ikke begejstrede, når de fratages denne mulighed, og som følge heraf bliver det sværere for dem at forstå kernen i de problemer, der opstår.«
Hvordan kan man så overvinde de nævnte udfordringer og overgå til bred anvendelse af DevOps i en stor organisation? Eksperter opfordrer til at udvise tålmodighed, selvom jeres endelige mål er at fremskynde softwareudviklingscyklussen og forretningsprocesserne.
1. Husk, at ændringer i kulturen tager tid
Jayne Groll, administrerende direktør for DevOps Institute: «Jeg mener, at DevOps-udvidelsen bør være lige så gradvis og iterativ som agil udvikling (og lige så meget berøre kulturen). I Agile og DevOps fokuseres der på små teams. Men i takt med at antallet og integrationen af sådanne teams vokser, får vi flere og flere mennesker, der anvender nye arbejdsmetoder, og som følge heraf opstår en omfattende kulturel transformation».
2. Brug tilstrækkelig tid på planlægning og valg af platform
Eran Kinsbruner, ledende teknisk evangelist hos Perfecto: «For at skaleringsprocessen fungerer, må DevOps-teams i starten lære at kombinere traditionelle processer, værktøjer og kompetencer, og derefter langsomt opbygge hver fase af DevOps og stabilisere den. Det hele starter med nøje planlægning af brugerhistorier og værdistrømme, hvorefter der følger en fase af softwareudvikling og versionskontrol ved brug af trunk-based development eller andre tilgange, der er mest velegnede til kodernes forgrening og sammenlægning».
«Dernæst følger en fase med integration og test, hvor en skalerbar platform til automatisering er nødvendig. Her er det vigtigt for DevOps-teams at vælge den rigtige platform, der passer til deres færdigheder og de overordnede mål for projektet.
Den næste fase er implementering i produktionsmiljøet, og den skal være helt automatiseret ved hjælp af orkestreringsværktøjer og containere. Det er vigtigt at have virtualiserede miljøer på alle faser af DevOps (simulator for produktionsmiljø, kvalitetskontrolmiljø og selve produktionsmiljøet) og altid anvende de nyeste data til test for at få relevante indsigter. Analytik skal være intelligent og capabel til at håndtere store data med hurtig og effektiv feedback».
3. Befri ansvar fra skyldfornemmelse
Gordon Haff, evangelist hos RedHat: At skabe et system og en atmosfære, der tillader og fremmer eksperimenter, muliggør såkaldte succesfulde fejl i agile softwareudvikling. Det betyder ikke, at ingen længere kan holdes ansvarlig for fejl. Faktisk bliver det lettere at finde en ansvarlig, fordi at 'være ansvarlig' ikke længere betyder 'at blive synderen'. Med andre ord ændrer essensen af ansvarlighed sig kvalitativt. Her bliver fire faktorer ekstremt vigtige: omfanget af fejlen, tilgange, produktionsprocesser og incitamenter. (Du kan læse mere om disse faktorer i Gordon Hauffs artikel "DevOps lessons: 4 aspects of healthy experiments".)
4. Ryd vejen fremad
Ben Grinnell, administrerende direktør og leder af digital teknologi i konsulentfirmaet North Highland: "For at opnå skalering anbefaler jeg at lancere et 'rydning af vejen' program sammen med pionerprojekter. Målet med dette program er at fjerne det rod, som bliver efter pionererne i DevOps, såsom forældede regler og lignende, så vejen fremad forbliver fri."
"Giv folk organisatorisk støtte og skab momentum gennem kommunikation, der rækker langt ud over gruppen af pionerer, ved at fejre succeserne med de nye arbejdsmetoder bredt. Uddan folk, der er involveret i den næste bølge af DevOps-projekter og som er nervøse for, at de bruger DevOps for første gang. Og husk, at disse personer er meget forskellige fra pionererne."
5. Gør værktøjerne mere demokratiske
Steve Newman, grundlægger og formand for Scalyr: "Værktøjerne bør ikke skjules for folk, og de skal være relativt enkle at lære for alle, der er villige til at investere tid i det. Hvis muligheden for at anmode om logs kun gives til tre personer 'certificeret' til at arbejde med et bestemt værktøj, vil du altid have maksimalt tre personer, der kan håndtere det relevante problem, selvom du har et meget stort beregningsmiljø. Med andre ord, her opstår der en flaskehals, som kan have alvorlige (for forretningen) konsekvenser."
6. Skab ideelle betingelser for teamets arbejde
Tom Clark, leder af Common Platform i ITV: «Du kan gøre hvad som helst, men ikke alt på én gang. Så sæt store mål, start småt og bevæg dig fremad med hurtige iterationer. Over tid vil du opnå et omdømme som et team, der får tingene til at ske, hvilket gør, at andre også vil ønske at anvende jeres metoder. Og jagter ikke opbygningen af et højt effektivt team. Sørg i stedet for, at folk har de bedste betingelser for at arbejde, og effektiviteten vil komme af sig selv».
7. Glem ikke Conway's lov og kanban-tavler.
Logan Daigle, direktør for softwarelevering og DevOps-strategi hos CollabNetVersionOne: «Det er vigtigt at være opmærksom på konsekvenserne af Conway's lov. I min frie omskrivning siger denne lov, at de produkter, vi skaber, og de processer, vi bruger, inklusive DevOps, ender med at være struktureret ligesom vores organisation».
«Hvis der er stor fragmentering i organisationen, og ledelsen skifter hænder mange gange under planlægning, udvikling og frigivelse af software, vil skaleringsresultatet være nul eller kortvarigt. Men hvis organisationen danner tværfunktionelle teams omkring produkter, der finansieres med fokus på markedet, så stiger chancerne for succes dramatisk».
«En anden vigtig aspekt ved skalering er at vise alt arbejde, der er i gang (WIP, work-in-progress), på kanban-tavlerne. Når der skabes et sted i organisationen, hvor folk kan se disse ting, fremmer det samarbejdet betydeligt, hvilket har en positiv indvirkning på skaleringen».
8. Søg efter gamle ar.
Manuel Pais, DevOps-konsulent og medforfatter af bogen 'Team Topologies': «At anvende DevOps-praksis uden for selve Dev og Ops og forsøge at anvende dem på andre funktioner kan næppe kaldes en optimal tilgang. Det vil uden tvivl give en vis effekt (for eksempel ved at automatisere manuel styring), men der kan opnås meget mere ved at starte med at forstå leverings- og feedbackprocesserne.»
«Hvis der i en organisations IT-system er gamle ar – procedurer og styringsmekanismer, der blev implementeret som følge af tidligere hændelser, men som har mistet relevans (på grund af ændringer i produkter, teknologier eller processer), så skal de uden tvivl fjernes eller glattes ud, og ikke automatiseres ineffektive eller unødvendige processer».
9. Skab ikke flere varianter af DevOps
Antony Edwards, direktør for produktion hos Eggplant: «DevOps er et meget vagt udtryk, som gør, at hver team får sin egen variant af DevOps. Og der er ikke noget værre end, når der i en organisation er 20 forskellige versioner af DevOps, der ikke rigtig trives sammen. Det kan ikke være, at hver af de tre udviklingsteams har sit eget unikke interface mellem udvikling og produktledelse. Det kan heller ikke være, at produkter har deres egne, unikke forventninger til håndtering af feedback, når de flyttes til simuleringen af produktionsmiljøet. Ellers vil det aldrig lykkes for jer at skalere DevOps».
10. Forkæl værdien af DevOps for forretningen
Steve Newman, grundlægger og formand for Scalyr: «Arbejd på at anerkende værdien af DevOps. Lær og vær ikke genert med at fortælle om fordelene ved det, I laver. DevOps sparer utrolig meget tid og penge (bare tænk: færre nedbrud, kortere gennemsnitlig genopretningstid), og DevOps-teams skal utrætteligt fremhæve (og prædike) vigtigheden af disse initiativer for forretningssucces. På den måde kan I udvide kredsen af fortalere og styrke DevOps' indflydelse i organisationen».
BONUS
På Den 13. september ankommer vores egen DevOps – ja, hos Red Hat har vi, som softwareproducent, vores egne DevOps-teams og praksisser.
Vores ingeniør Mark Birger, som arbejder med udvikling af interne automatiseringstjenester til andre grupper i hele organisationen, vil på klart dansk fortælle sin egen historie – hvordan Red Hats DevOps-team migrerede applikationer fra virtuelle miljøer drevet af Hat Virtualization, kontrolleret af Ansible, til et fuldt containerformat på OpenShift-platformen.
Men det er stadig ikke alt:
Efter at organisationer har flyttet arbejdsbelastning til containere, kan traditionelle metoder til overvågning af applikationer ikke fungere. I den anden rapport vil vi forklare vores motivation til at ændre måden, vi registrerer på, og vise fortsættelsen af den rejse, der har ført os til moderne metoder til logføring og overvågning.
Kilde: habr.com
