Er det vanskelig å forstå hovedpoenget når man snakker om DevOps? Vi har samlet for deg levende analogier, slående formuleringer og råd fra eksperter som vil hjelpe selv ikke-spesialister å komme til poenget. På slutten er bonusen Red Hat-ansattes egne DevOps.
Begrepet DevOps oppsto for 10 år siden og har gått fra en Twitter-hashtag til en kraftig kulturell bevegelse i IT-verdenen, en sann filosofi som oppmuntrer utviklere til å få ting gjort raskere, eksperimentere og iterere fremover. DevOps har blitt uløselig knyttet til konseptet digital transformasjon. Men som ofte skjer med IT-terminologi, har DevOps i løpet av de siste ti årene fått mange definisjoner, tolkninger og misoppfatninger om seg selv.
Derfor kan du ofte høre spørsmål om DevOps som, er det det samme som smidig? Eller er dette en spesiell metodikk? Eller er det bare enda et synonym for ordet "samarbeid"?
DevOps inkluderer mange forskjellige konsepter (kontinuerlig levering, kontinuerlig integrasjon, automatisering, etc.), så det kan være utfordrende å nedgrave det som er viktig, spesielt når du brenner for emnet. Denne ferdigheten er imidlertid veldig nyttig, uansett om du prøver å formidle ideene dine til dine overordnede eller bare fortelle noen fra familie eller venner om arbeidet ditt. Derfor, la oss legge til side de terminologiske nyansene til DevOps for nå og fokusere på det store bildet.
Hva er DevOps: 6 definisjoner og analogier
Vi ba eksperter forklare essensen av DevOps så enkelt og kort som mulig, slik at verdien blir tydelig for lesere med et hvilket som helst nivå av teknisk kunnskap. Basert på resultatene av disse samtalene har vi valgt ut de mest slående analogiene og slående formuleringene som vil hjelpe deg å bygge historien din om DevOps.
1. DevOps er en kulturell bevegelse
"DevOps er en kulturell bevegelse der begge parter (programvareutviklere og IT-systemdriftsspesialister) innser at programvare ikke gir reelle fordeler før noen begynner å bruke den: kunder, kunder, ansatte, ikke poenget," sier Eveline Oehrlich, seniorforsker analytiker ved DevOps Institute. "Derfor sikrer begge disse partene i fellesskap rask levering av programvare av høy kvalitet."
2. DevOps handler om å styrke utviklere.
"DevOps gir utviklere mulighet til å eie applikasjoner, kjøre dem og administrere levering fra start til slutt."
"Vanligvis omtales DevOps som en måte å fremskynde leveringen av applikasjoner til produksjon ved å bygge og implementere automatiserte prosesser," sier Jai Schniepp, direktør for DevOps-plattformer i forsikringsselskapet Liberty Mutual. "Men for meg er det en mye mer grunnleggende ting." DevOps gir utviklere mulighet til å eie applikasjoner eller spesifikke deler av programvare, kjøre dem og administrere leveringen fra start til slutt. DevOps eliminerer ansvarsforvirring og veileder alle som er involvert i å lage en automatisert, utviklerdrevet infrastruktur."
3. DevOps handler om samarbeid i å lage og levere applikasjoner.
"Enkelt sagt, DevOps er en tilnærming til programvareproduksjon og levering der alle jobber sammen," sier Gur Staf, president og leder for digital forretningsautomatisering i BMC.
4. DevOps er en pipeline
"Montering av transportbånd er bare mulig hvis alle delene passer sammen."
"Jeg vil sammenligne DevOps med en bilmonteringslinje," fortsetter Gur Staff. – Tanken er å designe og lage alle delene på forhånd slik at de så kan settes sammen uten individuell justering. Montering av transportbånd er kun mulig hvis alle delene passer sammen. De som designer og bygger en motor må vurdere hvordan den skal monteres på karosseriet eller rammen. De som lager bremsene må tenke på hjulene, og så videre. Det samme bør være tilfelle med programvare.
En utvikler som lager forretningslogikk eller et brukergrensesnitt må tenke på databasen som lagrer kundeinformasjon, sikkerhetstiltakene for å beskytte brukerdata, og hvordan alt dette vil fungere når tjenesten begynner å betjene et stort brukerpublikum, kanskje til og med flere millioner dollar. ."
«Å få folk til å samarbeide og tenke på de delene av jobben som andre gjør, i stedet for å fokusere utelukkende på sine egne oppgaver, er den største hindringen å overvinne. Hvis du kan gjøre dette, har du en utmerket sjanse for digital transformasjon, legger Gur Staff til.
5. DevOps er den rette kombinasjonen av mennesker, prosesser og automatisering
Jayne Groll, administrerende direktør for DevOps Institute, tilbød en flott analogi for å forklare DevOps. Med hennes ord, "DevOps er som en oppskrift med tre hovedkategorier av ingredienser: mennesker, prosess og automatisering. De fleste av disse ingrediensene kan hentes fra andre områder og kilder: Lean, Agile, SRE, CI/CD, ITIL, ledelse, kultur, verktøy. Hemmeligheten bak DevOps, som enhver god oppskrift, er hvordan man får de riktige proporsjonene og blandingen av disse ingrediensene for å øke hastigheten og effektiviteten til å lage og slippe applikasjoner.»
6. DevOps er når programmerere jobber som et Formel 1-team
"Rittet er ikke planlagt fra start til mål, men tvert imot, fra mål til start."
"Når jeg snakker om hva jeg kan forvente av et DevOps-initiativ, tenker jeg på et NASCAR- eller Formel 1-racingteam som et eksempel," sier Chris Short, senior manager for skyplattformmarkedsføring hos Red Hat og utgiver av DevOps sitt nyhetsbrev. – Lederen for et slikt lag har ett mål: å ta høyest mulig plass på slutten av løpet, tatt i betraktning de ressursene som er tilgjengelig for laget og utfordringene som møtte det. I dette tilfellet er løpet planlagt ikke fra start til mål, men tvert imot, fra mål til start. Først settes et ambisiøst mål, og deretter bestemmes måter å oppnå det på. Deretter blir de delt opp i underoppgaver og delegert til teammedlemmer.»
“Telaget bruker hele uken før løpet på å perfeksjonere pit-stoppet. Han trener styrke og kondisjonstrening for å holde seg i form til en slitsom løpsdag. Øver på å samarbeide for å løse eventuelle problemer som kan oppstå under løpet. På samme måte bør utviklingsteamet trene opp ferdighetene til å gi ut nye versjoner ofte. Har du slike ferdigheter og et velfungerende sikkerhetssystem, skjer lansering av nye versjoner i produksjon også oftere. I dette verdensbildet betyr økt hastighet økt sikkerhet, sier Short.
"Det handler ikke om å gjøre det "riktige," legger Short til, "det handler om å eliminere så mange ting som mulig som står i veien for det ønskede resultatet. Samarbeid og tilpass basert på tilbakemeldingene du får i sanntid. Vær forberedt på uregelmessigheter og arbeid for å forbedre kvaliteten for å minimere deres innvirkning på fremdriften mot målet ditt. Det er dette som venter oss i DevOps-verdenen.»
Slik skalerer du DevOps: 10 tips fra eksperter
Det er bare at DevOps og masse DevOps er helt forskjellige ting. Vi vil fortelle deg hvordan du overvinner barrierer på veien fra den første til den andre.
For mange organisasjoner begynner reisen til DevOps enkelt og behagelig. Små lidenskapelige team skapes, gamle prosesser erstattes med nye, og de første suksessene lar ikke vente på seg.
Akk, dette er bare en falsk glitter, en illusjon av fremgang, sier Ben Grinnell, administrerende direktør og leder for digitalt i konsulentselskapet North Highland. Tidlige seire er absolutt oppmuntrende, men de bidrar ikke til å nå det endelige målet om utbredt bruk av DevOps i hele organisasjonen.
Det er lett å se at resultatet er en splittelseskultur mellom «oss» og «dem».
"Ofte lanserer organisasjoner disse banebrytende prosjektene og tenker at de vil bane vei for mainstream DevOps, uten å vurdere om andre vil være i stand til eller villige til å følge den veien," forklarer Ben Grinnell. – Team for å implementere slike prosjekter rekrutteres vanligvis fra selvsikre «Varangians» som allerede har gjort noe lignende andre steder, men som er nye i organisasjonen din. Samtidig oppfordres de til å bryte og ødelegge reglene som forblir bindende for alle andre. Det er lett å se at resultatet er en kultur av «oss» og «dem» som hemmer overføringen av kunnskap og ferdigheter.»
"Og dette kulturelle problemet er bare en av grunnene til at DevOps er vanskelig å skalere. DevOps-team står overfor økte tekniske utfordringer som er typiske for raskt voksende IT-først-selskaper, sier Steve Newman, grunnlegger og styreleder i Scalyr.
«I den moderne verden endres tjenestene så snart behovet oppstår. Det er flott å hele tiden implementere og implementere nye funksjoner, men å koordinere denne prosessen og eliminere problemer som oppstår er en skikkelig hodepine, legger Steve Newman til. – I svært raskt voksende organisasjoner sliter ingeniører i tverrfunksjonelle team med å opprettholde synlighet til endring og de kaskadeeffektene på avhengighetsnivå det skaper. Dessuten er ingeniører ikke glade når de blir fratatt denne muligheten, og som et resultat blir det vanskeligere for dem å forstå essensen av problemene som oppstår.»
Hvordan overvinne disse utfordringene beskrevet ovenfor og gå over til masseadopsjon av DevOps i en stor organisasjon? Eksperter oppfordrer til tålmodighet, selv om det endelige målet ditt er å øke hastigheten på programvareutviklingssyklusen og forretningsprosessene.
1. Husk at kulturendring tar tid.
Jayne Groll, administrerende direktør, DevOps Institute: «Etter min mening bør utvidelsen av DevOps være like inkrementell og iterativ som smidig utvikling (og like berøre kultur). Agile og DevOps legger vekt på små team. Men etter hvert som disse teamene vokser i antall og integrering, ender vi opp med at flere tar i bruk nye måter å jobbe på, og som et resultat er det en massiv kulturell transformasjon.»
2. Bruk nok tid på å planlegge og velge en plattform
Eran Kinsbruner, ledende teknisk evangelist hos Perfecto: «For at skalering skal fungere, må DevOps-team først lære å kombinere tradisjonelle prosesser, verktøy og ferdigheter, og deretter sakte pleie og stabilisere hver enkelt fase av DevOps. Det hele starter med nøye planlegging av brukerhistorier og verdistrømmer, etterfulgt av skriving av programvare og versjonskontroll ved bruk av trunk-basert utvikling eller andre tilnærminger som er best egnet for forgrening og sammenslåing av kode."
«Så kommer integrasjons- og testfasen, hvor en skalerbar plattform for automatisering allerede er nødvendig. Det er her det er viktig for DevOps-teamene å velge riktig plattform som passer deres ferdighetsnivå og sluttmålene for prosjektet.
Neste fase er distribusjon til produksjon, og dette bør være helautomatisert ved hjelp av orkestreringsverktøy og containere. Det er viktig å ha virtualiserte miljøer på alle stadier av DevOps (produksjonssimulator, QA-miljø og faktisk produksjonsmiljø) og alltid kun bruke de nyeste dataene for tester for å få relevante konklusjoner. Analytics må være smart og i stand til å behandle store data med raske og handlingsrettede tilbakemeldinger.»
3. Ta skyldfølelsen fra ansvaret.
Gordon Haff, RedHat-evangelist: «Å skape et system og en atmosfære som tillater og oppmuntrer til eksperimentering, gir mulighet for det som kalles vellykkede feil i smidig programvareutvikling. Dette betyr ikke at ingen andre er ansvarlige for feil. Faktisk blir det enda enklere å identifisere hvem som er ansvarlig, siden "å være ansvarlig" ikke lenger betyr "å forårsake en ulykke." Det vil si at essensen av ansvar endres kvalitativt. Fire faktorer blir kritiske: omfanget av forstyrrelser, tilnærminger, produksjonsprosesser og insentiver.» (Du kan lese mer om disse faktorene i Gordon Huffs artikkel «DevOps-leksjoner: 4 aspekter ved sunne eksperimenter.»)
4. Rydd banen fremover
Ben Grinnell, administrerende direktør og leder for digital i konsulentselskapet North Highland: «For å oppnå skala anbefaler jeg å lansere et «stirydning»-program sammen med banebrytende prosjekter. Målet med dette programmet er å rydde opp i søppelet som DevOps-pionerene etterlater seg, som utdaterte regler og slike ting, slik at veien videre forblir klar."
"Gi folk organisatorisk støtte og fremdrift gjennom kommunikasjon som går langt utover pionergruppen ved å feire suksessene til nye måter å jobbe på. Trener folk som er involvert i den neste bølgen av DevOps-prosjekter og er nervøse for å bruke DevOps for første gang. Og husk at disse menneskene er veldig forskjellige fra pionerene.»
5. Demokratiser verktøy
Steve Newman, grunnlegger og styreleder i Scalyr: «Verktøy skal ikke skjules for folk, og de skal være relativt enkle å lære for alle som er villige til å bruke tid. Hvis muligheten til å forespørre logger er begrenset til tre personer "sertifisert" til å bruke et verktøy, vil du alltid ha maksimalt tre personer tilgjengelig for å håndtere problemet, selv om du har et veldig stort datamiljø. Det er med andre ord en flaskehals her som kan føre til alvorlige (forretningsmessige) konsekvenser.»
6. Skap ideelle forhold for teamarbeid
Tom Clark, leder for Common Platform ved ITV: «Du kan gjøre hva som helst, men ikke alt på en gang. Så sett deg store mål, begynn i det små og kom deg fremover i raske iterasjoner. Over tid vil du utvikle et rykte for å få ting gjort, så andre vil også bruke metodene dine. Og ikke bekymre deg for å bygge et svært effektivt team. Gi i stedet folk ideelle arbeidsforhold og effektivitet vil følge etter."
7. Ikke glem Conways Law og Kanban-tavler
Logan Daigle, direktør for programvarelevering og DevOps-strategi hos CollabNetVersionOne: «Det er viktig å forstå konsekvensene av Conways lov. I min løse parafrase sier denne loven at produktene vi lager og prosessene vi bruker for å gjøre det, inkludert DevOps, viser seg å være strukturert på samme måte som vår organisasjon."
«Hvis det er mange siloer i en organisasjon, og kontroll skifter hender mange ganger ved planlegging, bygging og utgivelse av programvare, vil effekten av skalering være null eller kortvarig. Hvis en organisasjon bygger tverrfunksjonelle team rundt produkter som er finansiert med markedsfokus, øker sjansene for suksess dramatisk.»
"Et annet viktig aspekt ved skalering er å vise alt arbeid som pågår (WIP, workinprogress) på Kanban-tavler. Når en organisasjon har et sted hvor folk kan se disse tingene, oppmuntrer det sterkt til samarbeid, noe som har en positiv innvirkning på skalering.»
8. Se etter gamle arr
Manuel Pais, DevOps-konsulent og medforfatter av Team Topologies: "Å ta DevOps-praksis utover Dev og Ops selv og prøve å bruke dem på andre funksjoner er neppe en optimal tilnærming. Dette vil sikkert ha en viss innvirkning (for eksempel ved å automatisere manuell kontroll), men mye mer kan oppnås hvis vi begynner med å forstå leverings- og tilbakemeldingsprosessene.»
"Hvis det er gamle arr i en organisasjons IT-system - prosedyrer og styringsmekanismer som ble implementert som et resultat av tidligere hendelser, men som har mistet sin relevans (på grunn av endringer i produkter, teknologier eller prosesser) - så må de absolutt fjernes eller jevnet ut, i stedet for å automatisere ineffektive eller unødvendige prosesser.»
9. Ikke oppdrett DevOps-alternativer
Anthony Edwards, driftsdirektør i Eggplant: «DevOps er et veldig vagt begrep, så hvert lag ender opp med sin egen versjon av DevOps. Og det er ikke noe verre når en organisasjon plutselig har 20 varianter av DevOps som ikke kommer særlig godt overens sammen. Det er umulig for hvert av de tre utviklingsteamene å ha sitt eget, spesielle grensesnitt mellom utvikling og produktledelse. Produktene skal heller ikke ha sine egne unike forventninger til håndtering av tilbakemeldinger når de overføres til en produksjonssimulator. Ellers vil du aldri kunne skalere DevOps.»
10. Forkynn forretningsverdien til DevOps
Steve Newman, grunnlegger og styreleder i Scalyr: «Arbeid for å gjenkjenne verdien av DevOps. Lær og snakk gjerne om fordelene med det du gjør. DevOps er en utrolig tids- og pengesparing (bare tenk: mindre nedetid, kortere gjennomsnittlig tid til gjenoppretting), og DevOps-teamene må utrettelig understreke (og forkynne) viktigheten av disse initiativene for forretningssuksess. På denne måten kan du utvide sirkelen av tilhengere og øke innflytelsen til DevOps i organisasjonen."
BONUS
På Våre egne DevOps kommer 13. september – ja, Red Hat, som programvareprodusent, har sine egne DevOps-team og praksiser.
Vår ingeniør Mark Birger, som utvikler interne automasjonstjenester for andre grupper i hele organisasjonen, vil fortelle sin egen historie på rent russisk – hvordan Red Hat DevOps-teamet migrerte applikasjoner fra Hat Virtualization virtuelle miljøer administrert av Ansible til et fullverdig containerformat på OpenShift-plattformen.
Men det er ikke alt:
Når organisasjoner har flyttet arbeidsbelastninger til containere, kan det hende at tradisjonelle applikasjonsovervåkingsmetoder ikke fungerer. I den andre foredraget vil vi forklare vår motivasjon for å endre måten vi logger på og vise fortsettelsen av veien som førte oss til moderne logg- og overvåkingsmetoder.
Kilde: www.habr.com