Er det svært at forstå hovedpointen, når man taler om DevOps? Vi har samlet levende analogier, slående formuleringer og råd fra eksperter til dig, der vil hjælpe selv ikke-specialister med at komme til sagen. Til sidst er bonussen Red Hat-medarbejdernes egne DevOps.
Begrebet DevOps opstod for 10 år siden og er gået fra et Twitter-hashtag til en stærk kulturel bevægelse i IT-verdenen, en sand filosofi, der tilskynder udviklere til at få tingene gjort hurtigere, eksperimentere og gentage fremad. DevOps er blevet uløseligt forbundet med konceptet digital transformation. Men som det ofte sker med it-terminologi, har DevOps i løbet af de sidste ti år fået mange definitioner, fortolkninger og misforståelser om sig selv.
Derfor kan du ofte høre spørgsmål om DevOps som, er det det samme som agile? Eller er det en speciel metode? Eller er det bare endnu et synonym for ordet "samarbejde"?
DevOps omfatter mange forskellige koncepter (kontinuerlig levering, kontinuerlig integration, automatisering osv.), så det kan være en udfordring at nedbryde det vigtige, især når du brænder for emnet. Men denne færdighed er meget nyttig, uanset om du prøver at formidle dine ideer til dine overordnede eller blot fortæller nogen fra din familie eller venner om dit arbejde. Lad os derfor lægge de terminologiske nuancer af DevOps til side for nu og fokusere på det store billede.
Hvad er DevOps: 6 definitioner og analogier
Vi bad eksperter om at forklare essensen af DevOps så enkelt og kort som muligt, så dets værdi bliver tydelig for læsere med ethvert niveau af teknisk viden. Baseret på resultaterne af disse samtaler har vi udvalgt de mest slående analogier og slående formuleringer, som vil hjælpe dig med at bygge din historie om DevOps.
1. DevOps er en kulturel bevægelse
"DevOps er en kulturel bevægelse, hvor begge parter (softwareudviklere og IT-systemdriftsspecialister) erkender, at software ikke giver reelle fordele, før nogen begynder at bruge det: kunder, kunder, medarbejdere, ikke pointen," siger Eveline Oehrlich, senior research analytiker ved DevOps Institute. "Derfor sikrer begge disse parter i fællesskab hurtig levering af software af høj kvalitet."
2. DevOps handler om at styrke udviklere.
"DevOps giver udviklere mulighed for at eje applikationer, køre dem og administrere levering fra start til slut."
"Typisk taler man om DevOps som en måde at fremskynde leveringen af applikationer til produktion ved at bygge og implementere automatiserede processer," siger Jai Schniepp, direktør for DevOps-platforme hos forsikringsselskabet Liberty Mutual. "Men for mig er det en meget mere grundlæggende ting." DevOps giver udviklere mulighed for at eje applikationer eller specifikke stykker software, køre dem og administrere deres levering fra start til slut. DevOps eliminerer ansvarsforvirring og guider alle involverede i at skabe en automatiseret, udviklerdrevet infrastruktur."
3. DevOps handler om samarbejde om at skabe og levere applikationer.
"Simpelt sagt er DevOps en tilgang til softwareproduktion og -levering, hvor alle arbejder sammen," siger Gur Staf, præsident og chef for digital business automation hos BMC.
4. DevOps er en pipeline
"Samling af transportbånd er kun mulig, hvis alle delene passer sammen."
"Jeg vil sammenligne DevOps med et bilsamlebånd," fortsætter Gur Staff. – Tanken er at designe og lave alle delene på forhånd, så de derefter kan samles uden individuel tilpasning. Samling af transportbånd er kun mulig, hvis alle dele passer sammen. De, der designer og bygger en motor, skal overveje, hvordan den skal monteres på karrosseriet eller rammen. Dem der laver bremserne skal tænke på hjulene og så videre. Det samme burde være tilfældet med software.
En udvikler, der skaber forretningslogik eller en brugergrænseflade, skal tænke over databasen, der gemmer kundeoplysninger, sikkerhedsforanstaltningerne for at beskytte brugerdata, og hvordan alt dette vil fungere, når tjenesten begynder at betjene en stor, måske endda multimillion-dollar brugerpublikum ."
”At få folk til at samarbejde og tænke over de dele af jobbet, som andre udfører, i stedet for udelukkende at fokusere på deres egne opgaver, er den største forhindring at overvinde. Hvis du kan gøre dette, har du en fremragende chance 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, tilbød en god analogi til at forklare DevOps. Med hendes ord, "DevOps er som en opskrift med tre hovedkategorier af ingredienser: mennesker, proces og automatisering. De fleste af disse ingredienser kan hentes fra andre områder og kilder: Lean, Agile, SRE, CI/CD, ITIL, ledelse, kultur, værktøjer. Hemmeligheden bag DevOps, som enhver god opskrift, er, hvordan man får de rigtige proportioner og blanding af disse ingredienser for at øge hastigheden og effektiviteten af at skabe og frigive applikationer."
6. DevOps er, når programmører arbejder som et Formel 1-hold
"Løbet er ikke planlagt fra start til slut, men tværtimod fra mål til start."
"Når jeg taler om, hvad jeg kan forvente af et DevOps-initiativ, tænker jeg på et NASCAR- eller Formel 1-racerhold som et eksempel," siger Chris Short, senior manager for cloud platform marketing hos Red Hat og udgiver af DevOps' nyhedsbrev. – Lederen af sådan et hold har ét mål: at indtage den højest mulige plads i slutningen af løbet, under hensyntagen til de ressourcer, der er til rådighed for holdet, og de udfordringer, der stødte på det. I dette tilfælde er løbet ikke planlagt fra start til slut, men tværtimod fra mål til start. Først opstilles et ambitiøst mål, og derefter fastlægges måder at nå det på. Derefter bliver de opdelt i underopgaver og uddelegeret til teammedlemmer.”
“Teamet bruger hele ugen før løbet på at perfektionere pitstoppet. Han dyrker styrketræning og cardio for at holde sig i form til en opslidende løbsdag. Øver i at arbejde sammen for at løse eventuelle problemer, der måtte opstå under løbet. Ligeledes bør udviklingsteamet træne evnen til at udgive nye versioner ofte. Har du sådanne kompetencer og et velfungerende sikkerhedssystem, sker lanceringen af nye versioner i produktion også oftere. I dette verdensbillede betyder øget hastighed øget sikkerhed,” siger Short.
"Det handler ikke om at gøre det 'rigtige'," tilføjer Short, "det handler om at eliminere så mange ting som muligt, der står i vejen for det ønskede resultat. Samarbejd og tilpas ud fra den feedback, du modtager i realtid. Vær forberedt på uregelmæssigheder, og arbejd på at forbedre kvaliteten for at minimere deres indvirkning på fremskridt mod dit mål. Det er det, der venter os i DevOps-verdenen."
Sådan skalerer du DevOps: 10 tips fra eksperter
Det er bare, at DevOps og masse DevOps er helt forskellige ting. Vi vil fortælle dig, hvordan du overvinder barrierer på vejen fra den første til den anden.
For mange organisationer begynder rejsen til DevOps nemt og behageligt. Små passionerede teams skabes, gamle processer erstattes med nye, og de første succeser lader ikke vente på sig.
Ak, dette er bare et falsk glimt, en illusion om fremskridt, siger Ben Grinnell, administrerende direktør og chef for digital hos konsulentfirmaet North Highland. Tidlige gevinster er bestemt opmuntrende, men de hjælper ikke med at nå det ultimative mål om udbredt anvendelse af DevOps på tværs af organisationen.
Det er let at se, at resultatet er en opdelingskultur mellem "os" og "dem".
"Ofte lancerer organisationer disse banebrydende projekter og tror, at de vil bane vejen for mainstream DevOps uden at overveje, om andre vil være i stand til eller villige til at følge den vej," forklarer Ben Grinnell. – Teams til at implementere sådanne projekter rekrutteres normalt fra selvsikre "Varangians", som allerede har lavet noget lignende andre steder, men er nye i din organisation. Samtidig opfordres de til at bryde og ødelægge de regler, der fortsat er bindende for alle andre. Det er let at se, at resultatet er en kultur af "os" og "dem", der hæmmer overførslen af viden og færdigheder."
"Og dette kulturelle problem er blot en af grundene til, at DevOps er svært at skalere. DevOps-teams står over for øgede tekniske udfordringer, som er typiske for hurtigtvoksende IT-first-virksomheder,” sagde Steve Newman, grundlægger og formand for Scalyr.
"I den moderne verden ændrer tjenester sig, så snart behovet opstår. Det er fantastisk konstant at implementere og implementere nye funktioner, men at koordinere denne proces og eliminere problemer, der opstår, er en reel hovedpine, tilføjer Steve Newman. – I meget hurtigt voksende organisationer kæmper ingeniører på tværfunktionelle teams for at bevare overblikket over forandringer og de kaskadeeffekter på afhængighedsniveau, det skaber. Desuden er ingeniører ikke glade, når de bliver frataget denne mulighed, og som følge heraf bliver det sværere for dem at forstå essensen af de problemer, der opstår.”
Hvordan overvinder man disse udfordringer beskrevet ovenfor og går over til masseadoption af DevOps i en stor organisation? Eksperter opfordrer til tålmodighed, selvom dit ultimative mål er at fremskynde din softwareudviklingscyklus og forretningsprocesser.
1. Husk at kulturændring tager tid.
Jayne Groll, administrerende direktør, DevOps Institute: "Efter min mening bør udvidelsen af DevOps være lige så trinvis og iterativ som agil udvikling (og lige så berøre kultur). Agile og DevOps lægger vægt på små teams. Men efterhånden som disse teams vokser i antal og integration, ender vi med, at flere mennesker tager nye måder at arbejde på, og som et resultat er der en massiv kulturel transformation.”
2. Brug nok tid på at planlægge og vælge en platform
Eran Kinsbruner, Lead Technical Evangelist hos Perfecto: “For at skalering skal virke, skal DevOps-teams først lære at kombinere traditionelle processer, værktøjer og færdigheder og derefter langsomt pleje og stabilisere hver enkelt fase af DevOps. Det hele starter med omhyggelig planlægning af brugerhistorier og værdistrømme, efterfulgt af skrivning af software og versionskontrol ved hjælp af trunk-baseret udvikling eller andre metoder, der er bedst egnede til at forgrene og flette kode."
”Så kommer integrations- og testfasen, hvor der allerede er behov for en skalerbar platform til automatisering. Det er her, det er vigtigt for DevOps-teams at vælge den rigtige platform, der passer til deres færdighedsniveau og projektets slutmål.
Den næste fase er udrulning til produktion, og dette bør være fuldt automatiseret ved hjælp af orkestreringsværktøjer og containere. Det er vigtigt at have virtualiserede miljøer på alle stadier af DevOps (produktionssimulator, QA-miljø og faktisk produktionsmiljø) og altid kun bruge de nyeste data til test for at opnå relevante konklusioner. Analytics skal være smart og i stand til at behandle big data med hurtig og handlingsvenlig feedback."
3. Tag skyldfølelsen fra ansvaret.
Gordon Haff, RedHat-evangelist: "At skabe et system og en atmosfære, der tillader og tilskynder til eksperimenter, giver mulighed for, hvad der er kendt som vellykkede fejl i agil softwareudvikling. Det betyder ikke, at ingen andre er ansvarlige for fejl. Faktisk bliver det endnu nemmere at identificere, hvem der er ansvarlig, da "at være ansvarlig" ikke længere betyder "at forårsage en ulykke." Det vil sige, at essensen af ansvar ændrer sig kvalitativt. Fire faktorer bliver kritiske: omfanget af forstyrrelser, tilgange, produktionsprocesser og incitamenter." (Du kan læse mere om disse faktorer i Gordon Huffs artikel "DevOps-lektioner: 4 aspekter af sunde eksperimenter.")
4. Ryd stien fremad
Ben Grinnell, administrerende direktør og chef for digital hos konsulentfirmaet North Highland: "For at opnå skala anbefaler jeg at lancere et "stirydning"-program sammen med banebrydende projekter. Målet med dette program er at rydde op i det affald, som DevOps-pionerer efterlader, som forældede regler og sådan noget, så vejen frem forbliver fri."
"Giv folk organisatorisk støtte og fremdrift gennem kommunikation, der går langt ud over pionergruppen ved i vid udstrækning at fejre succeserne med nye måder at arbejde på. Coach folk, der er involveret i den næste bølge af DevOps-projekter og er nervøse for at bruge DevOps for første gang. Og husk, at disse mennesker er meget forskellige fra pionererne.”
5. Demokratiser værktøjer
Steve Newman, grundlægger og formand for Scalyr: ”Værktøjer skal ikke skjules for folk, og de skal være relativt nemme at lære for alle, der er villige til at bruge tiden. Hvis muligheden for at forespørge logfiler er begrænset til tre personer, der er "certificeret" til at bruge et værktøj, vil du altid have maksimalt tre personer til rådighed til at håndtere problemet, selvom du har et meget stort computermiljø. Her er der med andre ord en flaskehals, som kan føre til alvorlige (forretningsmæssige) konsekvenser.”
6. Skab ideelle betingelser for teamarbejde
Tom Clark, leder af Common Platform på ITV: “Du kan gøre alt, men ikke alt på én gang. Så sæt store mål, start i det små, og kom videre i hurtige gentagelser. Med tiden vil du udvikle et ry for at få tingene gjort, så andre vil også gerne bruge dine metoder. Og du skal ikke bekymre dig om at opbygge et yderst effektivt team. Giv i stedet folk ideelle arbejdsforhold, og effektivitet vil følge efter."
7. Glem ikke Conway's Law og Kanban boards
Logan Daigle, Director of Software Delivery and DevOps Strategy hos CollabNetVersionOne: ”Det er vigtigt at forstå konsekvenserne af Conways lov. I min løse parafrase siger denne lov, at de produkter, vi skaber, og de processer, vi bruger til at gøre det, inklusive DevOps, viser sig at være struktureret på samme måde som vores organisation."
”Hvis der er mange siloer i en organisation, og kontrol skifter hænder mange gange, når man planlægger, bygger og frigiver software, vil effekten af skalering være nul eller kortvarig. Hvis en organisation opbygger tværfunktionelle teams omkring produkter, der er finansieret med markedsfokus, så øges chancerne for succes dramatisk.”
"Et andet vigtigt aspekt ved skalering er at vise alt igangværende arbejde (WIP, workinprogress) på Kanban-tavler. Når en organisation har et sted, hvor folk kan se disse ting, opmuntrer det i høj grad til samarbejde, hvilket har en positiv indvirkning på skalering.”
8. Se efter gamle ar
Manuel Pais, DevOps-konsulent og medforfatter af Team Topologies: "At tage DevOps-praksis ud over Dev og Ops selv og forsøge at anvende dem til andre funktioner er næppe en optimal tilgang. Dette vil helt sikkert have en vis indflydelse (for eksempel ved at automatisere manuel kontrol), men meget mere kan opnås, hvis vi starter med at forstå leverings- og feedbackprocesserne."
"Hvis der er gamle ar i en organisations it-system - procedurer og styringsmekanismer, der blev implementeret som følge af tidligere hændelser, men som har mistet deres relevans (på grund af ændringer i produkter, teknologier eller processer) - så skal de helt sikkert fjernes eller udjævnet i stedet for at automatisere ineffektive eller unødvendige processer."
9. Opdrætter ikke DevOps-muligheder
Anthony Edwards, driftsdirektør hos Aubergine: “DevOps er et meget vagt udtryk, så hvert hold ender med sin egen version af DevOps. Og der er ikke noget værre, når en organisation pludselig har 20 varianter af DevOps, der ikke passer særlig godt sammen. Det er umuligt for hvert af de tre udviklingsteams at have deres egen, særlige grænseflade mellem udvikling og produktstyring. Produkter bør heller ikke have deres egne unikke forventninger til håndtering af feedback, når de overføres til en produktionssimulator. Ellers vil du aldrig være i stand til at skalere DevOps.”
10. Forkynd forretningsværdien af DevOps
Steve Newman, grundlægger og formand for Scalyr: "Arbejd på at anerkende værdien af DevOps. Lær og tal gerne om fordelene ved det, du laver. DevOps er en utrolig tids- og pengebesparelse (tænk bare: mindre nedetid, kortere middeltid til genopretning), og DevOps-teams skal utrætteligt understrege (og prædike) vigtigheden af disse initiativer for forretningssucces. På denne måde kan du udvide kredsen af tilhængere og øge indflydelsen fra DevOps i organisationen.”
BONUS
On Vores egne DevOps ankommer den 13. september – ja, Red Hat har som softwareproducent sine egne DevOps-teams og -praksis.
Vores ingeniør Mark Birger, som udvikler interne automatiseringstjenester til andre grupper i hele organisationen, vil fortælle sin egen historie på rent russisk - hvordan Red Hat DevOps-teamet migrerede applikationer fra Hat Virtualization virtuelle miljøer administreret af Ansible til et fuldgyldigt containerformat på OpenShift-platformen.
Men det er ikke alt:
Når først organisationer har flyttet arbejdsbelastninger til containere, fungerer traditionelle applikationsovervågningsmetoder muligvis ikke. I den anden tale vil vi forklare vores motivation for at ændre måden, vi logger på, og vise fortsættelsen af den vej, der førte os til moderne logning og overvågningsmetoder.
Kilde: www.habr.com