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
