Ali je težko razumeti bistvo, ko govorimo o DevOps? Za vas smo zbrali živahne analogije, osupljive formulacije in nasvete strokovnjakov, ki bodo tudi nestrokovnjakom pomagali priti do bistva. Na koncu je bonus lasten DevOps zaposlenih v Red Hatu.
Izraz DevOps je nastal pred 10 leti in se je iz hashtaga na Twitterju spremenil v močno kulturno gibanje v svetu IT, pravo filozofijo, ki spodbuja razvijalce, da stvari opravijo hitreje, eksperimentirajo in nadaljujejo. DevOps je postal neločljivo povezan s konceptom digitalne transformacije. Toda kot se pogosto zgodi z IT terminologijo, je DevOps v zadnjih desetih letih pridobil številne definicije, interpretacije in napačne predstave o sebi.
Zato lahko pogosto slišite vprašanja o DevOps, kot je, ali je isto kot agile? Ali pa je to kakšna posebna metodologija? Ali pa je le še en sinonim za besedo »sodelovanje«?
DevOps vključuje veliko različnih konceptov (neprekinjeno zagotavljanje, neprekinjeno integracijo, avtomatizacijo itd.), zato je odkrivanje pomembnega lahko izziv, še posebej, če vas ta tema navdušuje. Vendar pa je ta veščina zelo uporabna, ne glede na to, ali poskušate svoje ideje posredovati nadrejenim ali o svojem delu preprosto pripovedujete nekomu iz družine ali prijateljem. Zato za zdaj pustimo ob strani terminološke nianse DevOps in se osredotočimo na širšo sliko.
Kaj je DevOps: 6 definicij in analogij
Strokovnjake smo prosili, naj bistvo DevOps razložijo čim bolj preprosto in na kratko, da bo njegova vrednost jasna bralcem s katero koli stopnjo tehničnega znanja. Na podlagi rezultatov teh pogovorov smo izbrali najbolj osupljive analogije in osupljive formulacije, ki vam bodo pomagale zgraditi vašo zgodbo o DevOps.
1. DevOps je kulturno gibanje
»DevOps je kulturno gibanje, v katerem obe strani (razvijalci programske opreme in strokovnjaki za delovanje sistemov IT) priznavata, da programska oprema ne prinaša resničnih koristi, dokler je nekdo ne začne uporabljati: stranke, stranke, zaposleni, ne bistvo,« pravi Eveline Oehrlich, višja raziskovalka analitik na inštitutu DevOps. "Zato obe strani skupaj zagotavljata hitro in kakovostno dostavo programske opreme."
2. DevOps je opolnomočenje razvijalcev.
"DevOps omogoča razvijalcem, da imajo aplikacije v lasti, jih izvajajo in upravljajo dostavo od začetka do konca."
»Običajno se o DevOps govori kot o načinu za pospešitev dostave aplikacij v proizvodnjo z gradnjo in implementacijo avtomatiziranih procesov,« pravi Jai Schniepp, direktor platform DevOps pri zavarovalnici Liberty Mutual. "Toda zame je to veliko bolj temeljna stvar." DevOps omogoča razvijalcem, da imajo v lasti aplikacije ali določene dele programske opreme, jih izvajajo in upravljajo njihovo dostavo od začetka do konca. DevOps odpravlja zmedo glede odgovornosti in vodi vse vpletene v ustvarjanje avtomatizirane infrastrukture, ki jo vodijo razvijalci.«
3. DevOps govori o sodelovanju pri ustvarjanju in dostavi aplikacij.
»Preprosto povedano, DevOps je pristop k izdelavi in dostavi programske opreme, kjer vsi delajo skupaj,« pravi Gur Staf, predsednik in vodja digitalne poslovne avtomatizacije pri BMC.
4. DevOps je cevovod
"Sestavljanje tekočega traku je možno le, če se vsi deli prilegajo skupaj."
»DevOps bi primerjal s tekočim trakom avtomobilov,« nadaljuje Gur Staff. – Ideja je načrtovati in izdelati vse dele vnaprej, tako da jih je potem mogoče sestaviti brez individualnega prilagajanja. Sestavljanje tekočega traku je možno le, če se vsi deli prilegajo skupaj. Tisti, ki načrtujejo in izdelujejo motor, morajo razmisliti o tem, kako ga pritrditi na karoserijo ali okvir. Tisti, ki delajo zavore, morajo misliti na kolesa itd. Enako bi moralo veljati za programsko opremo.
Razvijalec, ki ustvarja poslovno logiko ali uporabniški vmesnik, mora razmišljati o bazi podatkov, ki shranjuje podatke o strankah, o varnostnih ukrepih za zaščito podatkov o uporabnikih in o tem, kako bo vse to delovalo, ko bo storitev začela služiti velikemu, morda celo večmilijonskemu občinstvu uporabnikov. ."
»Največja ovira, ki jo je treba premagati, je pridobiti ljudi, da sodelujejo in razmišljajo o delih dela, ki ga opravljajo drugi, namesto da se osredotočajo zgolj na svoje naloge. Če vam to uspe, imate odlične možnosti za digitalno preobrazbo,« dodaja Gur Staff.
5. DevOps je prava kombinacija ljudi, procesov in avtomatizacije
Jayne Groll, izvršna direktorica inštituta DevOps, je ponudila odlično analogijo za razlago DevOps. Po njenih besedah je »DevOps kot recept s tremi glavnimi kategorijami sestavin: ljudje, proces in avtomatizacija. Večino teh sestavin je mogoče vzeti iz drugih področij in virov: Lean, Agile, SRE, CI/CD, ITIL, voditeljstvo, kultura, orodja. Skrivnost DevOps, tako kot vsakega dobrega recepta, je, kako doseči prava razmerja in mešanico teh sestavin za povečanje hitrosti in učinkovitosti ustvarjanja in izdajanja aplikacij.«
6. DevOps je, ko programerji delajo kot ekipa formule 1
"Dirka ni načrtovana od starta do cilja, ampak ravno nasprotno, od cilja do starta."
»Ko govorim o tem, kaj lahko pričakujem od pobude DevOps, pomislim na dirkalno ekipo NASCAR ali Formule 1 kot primer,« pravi Chris Short, višji vodja trženja platforme v oblaku pri Red Hat in izdajatelj glasila DevOps'ish. – Vodja takšne ekipe ima en sam cilj: zasesti najvišje možno mesto na koncu dirke, upoštevajoč sredstva, ki so na voljo ekipi, in izzive, ki so jo doleteli. V tem primeru dirka ni načrtovana od začetka do cilja, ampak nasprotno, od cilja do začetka. Najprej se postavi ambiciozen cilj, nato pa se določijo načini za njegovo dosego. Nato se razdelijo na podnaloge in prenesejo na člane ekipe.«
»Ekipa ves teden pred dirko izpopolnjuje postanek v boksih. Izvaja treninge za moč in kardio vadbo, da ostane v formi za naporen tekmovalni dan. Vadi sodelovanje pri reševanju težav, ki se lahko pojavijo med dirko. Podobno bi morala razvojna ekipa uriti veščino pogostega izdajanja novih različic. Če imate takšne sposobnosti in dobro delujoč varnostni sistem, se pogosteje zgodi tudi lansiranje novih različic v proizvodnjo. V tem pogledu na svet večja hitrost pomeni večjo varnost,« pravi Short.
»Ne gre za to, da naredimo 'pravo stvar',« dodaja Short, »gre za odpravo čim več stvari, ki stojijo na poti do želenega rezultata. Sodelujte in se prilagajajte na podlagi povratnih informacij, ki jih prejmete v realnem času. Bodite pripravljeni na anomalije in si prizadevajte izboljšati kakovost, da zmanjšate njihov vpliv na napredek pri doseganju cilja. To nas čaka v svetu DevOps.”
Kako razširiti DevOps: 10 nasvetov strokovnjakov
Samo DevOps in masovni DevOps sta popolnoma različni stvari. Povedali vam bomo, kako premagati ovire na poti od prvega do drugega.
Za mnoge organizacije se pot do DevOps začne enostavno in prijetno. Ustvarjajo se majhne strastne ekipe, stari procesi se zamenjujejo z novimi in prvi uspehi niso dolgo čakajoči.
Žal, to je samo lažni blišč, iluzija napredka, pravi Ben Grinnell, generalni direktor in vodja digitalnega oddelka pri svetovalnem podjetju North Highland. Zgodnje zmage so vsekakor spodbudne, vendar ne pomagajo doseči končnega cilja širokega sprejemanja DevOps v celotni organizaciji.
Zlahka je videti, da je rezultat kultura delitve med »nami« in »njimi«.
»Pogosto organizacije začnejo s temi pionirskimi projekti, misleč, da bodo utrle pot za mainstream DevOps, ne da bi razmišljale, ali bodo drugi lahko ali pripravljeni slediti tej poti,« pojasnjuje Ben Grinnell. – Ekipe za izvajanje takšnih projektov so običajno rekrutirane iz samozavestnih »Varjagov«, ki so že naredili nekaj podobnega drugje, a so novi v vaši organizaciji. Hkrati jih spodbujajo, da kršijo in uničujejo pravila, ki ostajajo zavezujoča za vse ostale. Zlahka je videti, da je rezultat kultura »nas« in »njih«, ki zavira prenos znanja in veščin.«
»In ta kulturni problem je le eden od razlogov, zakaj je DevOps težko prilagoditi. Ekipe DevOps se soočajo s povečanimi tehničnimi izzivi, ki so značilni za hitro rastoča podjetja, ki so na prvem mestu IT,« je povedal Steve Newman, ustanovitelj in predsednik Scalyrja.
»V sodobnem svetu se storitve spreminjajo takoj, ko se pojavi potreba. Nenehno implementirati in implementirati nove funkcije je odlično, a usklajevanje tega procesa in odpravljanje težav, ki se pojavljajo, je pravi glavobol, dodaja Steve Newman. – V zelo hitro rastočih organizacijah se inženirji v medfunkcionalnih ekipah trudijo ohraniti vidnost sprememb in kaskadnih učinkov na ravni odvisnosti, ki jih ustvarjajo. Še več, inženirji niso zadovoljni, ko so prikrajšani za to možnost in posledično težje razumejo bistvo težav, ki se pojavljajo.«
Kako premagati zgoraj opisane izzive in preiti na množično sprejetje DevOps v veliki organizaciji? Strokovnjaki pozivajo k potrpežljivosti, tudi če je vaš končni cilj pospešiti cikel razvoja programske opreme in poslovne procese.
1. Ne pozabite, da sprememba kulture zahteva čas.
Jayne Groll, izvršna direktorica inštituta DevOps: »Po mojem mnenju bi morala biti širitev DevOps tako postopna in ponavljajoča se kot agilni razvoj (in se enako dotikati kulture). Agile in DevOps poudarjata majhne ekipe. Ko pa te ekipe naraščajo v številu in se povezujejo, končamo z več ljudmi, ki sprejmejo nove načine dela, posledično pa pride do velike kulturne preobrazbe.«
2. Porabite dovolj časa za načrtovanje in izbiro platforme
Eran Kinsbruner, vodilni tehnični evangelist pri Perfecto: »Da bi skaliranje delovalo, se morajo ekipe DevOps najprej naučiti kombinirati tradicionalne procese, orodja in veščine, nato pa počasi negovati in stabilizirati vsako posamezno fazo DevOps. Vse se začne s skrbnim načrtovanjem uporabniških zgodb in tokov vrednosti, čemur sledi pisanje programske opreme in nadzor različic z uporabo debelnega razvoja ali drugih pristopov, ki so najbolj primerni za razvejanje in združevanje kode.«
»Nato pride faza integracije in testiranja, kjer je že potrebna razširljiva platforma za avtomatizacijo. Tukaj je za ekipe DevOps pomembno, da izberejo pravo platformo, ki ustreza njihovi ravni znanja in končnim ciljem projekta.
Naslednja faza je uvedba v proizvodnjo, ki bi morala biti popolnoma avtomatizirana z orodji za orkestracijo in vsebniki. Pomembno je imeti virtualizirana okolja na vseh stopnjah DevOps (proizvodni simulator, okolje QA in dejansko proizvodno okolje) in vedno uporabiti samo najnovejše podatke za preizkuse, da pridobimo ustrezne zaključke. Analitika mora biti pametna in sposobna obdelave velikih podatkov s hitrimi in učinkovitimi povratnimi informacijami.«
3. Prevzemite krivdo iz odgovornosti.
Gordon Haff, evangelist RedHat: »Ustvarjanje sistema in vzdušja, ki omogoča in spodbuja eksperimentiranje, omogoča tako imenovane uspešne napake pri agilnem razvoju programske opreme. To ne pomeni, da za napake ni odgovoren nihče drug. Pravzaprav postane ugotavljanje, kdo je odgovoren, še lažje, saj "biti odgovoren" ne pomeni več "povzročiti nesrečo". To pomeni, da se bistvo odgovornosti kvalitativno spremeni. Štirje dejavniki postanejo kritični: obseg motenj, pristopi, proizvodni procesi in spodbude.« (Več o teh dejavnikih lahko preberete v članku Gordona Huffa »Lekcije DevOps: 4 vidiki zdravih eksperimentov.«)
4. Očistite pot naprej
Ben Grinnell, generalni direktor in vodja digitalnega oddelka pri svetovalnem podjetju North Highland: »Za doseganje obsega priporočam uvedbo programa »čiščenja poti« skupaj s pionirskimi projekti. Cilj tega programa je počistiti smeti, ki jih pionirji DevOps pustijo za seboj, kot so zastarela pravila in podobne stvari, tako da pot naprej ostane jasna.«
»Dajte ljudem organizacijsko podporo in zagon s komunikacijo, ki presega pionirske skupine, tako da na široko slavite uspehe novih načinov dela. Usposabljajte ljudi, ki so vključeni v naslednji val projektov DevOps in so nervozni zaradi prve uporabe DevOps. In ne pozabite, da se ti ljudje zelo razlikujejo od pionirjev.”
5. Demokratizirajte orodja
Steve Newman, ustanovitelj in predsednik Scalyrja: »Orodja ne bi smela biti skrita pred ljudmi in morala bi se jih razmeroma enostavno naučiti za vsakogar, ki je pripravljen vložiti čas. Če je zmožnost poizvedovanja po dnevnikih omejena na tri osebe, ki so "certificirane" za uporabo orodja, boste imeli vedno na voljo največ tri osebe, ki bodo obravnavale težavo, tudi če imate zelo veliko računalniško okolje. Z drugimi besedami, tukaj je ozko grlo, ki lahko povzroči resne (poslovne) posledice.«
6. Ustvarite idealne pogoje za timsko delo
Tom Clark, vodja skupne platforme pri ITV: »Lahko narediš vse, a ne vsega naenkrat. Zato si postavite velike cilje, začnite z majhnimi in se hitro pomikajte naprej. Sčasoma si boste pridobili sloves, da boste stvari opravili, zato bodo tudi drugi želeli uporabiti vaše metode. In ne skrbite za sestavljanje zelo učinkovite ekipe. Namesto tega ljudem zagotovite idealne delovne pogoje in učinkovitost bo sledila.”
7. Ne pozabite na Conwayev zakon in Kanban table
Logan Daigle, direktor dostave programske opreme in strategije DevOps pri CollabNetVersionOne: »Pomembno je razumeti posledice Conwayevega zakona. V moji ohlapni parafrazi, ta zakon določa, da so izdelki, ki jih ustvarjamo, in procesi, ki jih uporabljamo za to, vključno z DevOps, strukturirani na enak način kot naša organizacija.«
»Če je v organizaciji veliko silosov in nadzor večkrat zamenja roke pri načrtovanju, gradnji in izdaji programske opreme, bo učinek skaliranja ničen ali kratkotrajen. Če organizacija zgradi medfunkcionalne ekipe okoli izdelkov, ki so financirani s tržno osredotočenostjo, potem se možnosti za uspeh močno povečajo.«
»Drug pomemben vidik skaliranja je prikaz celotnega dela v teku (WIP, workinprogress) na tablah Kanban. Ko ima organizacija prostor, kjer lahko ljudje vidijo te stvari, močno spodbuja sodelovanje, kar pozitivno vpliva na skaliranje.«
8. Poiščite stare brazgotine
Manuel Pais, svetovalec za DevOps in soavtor Team Topologies: »Prevzemanje praks DevOps onkraj samega Dev and Ops in poskus njihove uporabe v drugih funkcijah je komaj optimalen pristop. To bo zagotovo imelo določen učinek (na primer z avtomatizacijo ročnega nadzora), vendar lahko veliko več dosežemo, če začnemo z razumevanjem procesov dostave in povratnih informacij.«
»Če so v informacijskem sistemu organizacije stare brazgotine – postopki in mehanizmi upravljanja, ki so bili implementirani kot posledica preteklih incidentov, vendar so izgubili pomen (zaradi sprememb v izdelkih, tehnologijah ali procesih) –, potem jih je vsekakor treba odstraniti. ali zglajena, namesto da bi avtomatizirala neučinkovite ali nepotrebne procese.«
9. Ne vzgajajte možnosti DevOps
Anthony Edwards, direktor operacij pri Eggplant: »DevOps je zelo nejasen izraz, zato ima vsaka ekipa svojo različico DevOps. In nič hujšega ni, če ima organizacija nenadoma 20 vrst DevOps, ki se ne ujemajo najbolje skupaj. Nemogoče je, da bi imela vsaka od treh razvojnih ekip svoj, poseben vmesnik med razvojem in upravljanjem produkta. Izdelki tudi ne bi smeli imeti lastnih edinstvenih pričakovanj glede ravnanja s povratnimi informacijami, ko se prenesejo v proizvodni simulator. V nasprotnem primeru ne boste nikoli mogli povečati DevOps.«
10. Pridigajte o poslovni vrednosti DevOps
Steve Newman, ustanovitelj in predsednik Scalyrja: »Prizadevajte si prepoznati vrednost DevOps. Naučite se in se svobodno pogovarjajte o prednostih tega, kar počnete. DevOps je neverjeten prihranek časa in denarja (samo pomislite: manj izpadov, krajši srednji čas do okrevanja), ekipe DevOps pa morajo neutrudno poudarjati (in pridigati) pomen teh pobud za poslovni uspeh. Tako lahko razširite krog privržencev in povečate vpliv DevOps v organizaciji.”
BONUS
Na Naš lastni DevOps bo prišel 13. septembra - da, Red Hat ima kot proizvajalec programske opreme svoje ekipe in prakse DevOps.
Naš inženir Mark Birger, ki razvija storitve notranje avtomatizacije za druge skupine v celotni organizaciji, bo povedal svojo zgodbo v čisti ruščini – kako je ekipa Red Hat DevOps preselila aplikacije iz virtualnih okolij Hat Virtualization, ki jih upravlja Ansible, v polnopravni format vsebnika na platformo OpenShift.
To pa še ni vse:
Ko organizacije prenesejo delovne obremenitve v vsebnike, tradicionalne metode spremljanja aplikacij morda ne bodo delovale. V drugem predavanju bomo razložili našo motivacijo za spremembo načina beleženja in prikazali nadaljevanje poti, ki nas je pripeljala do sodobnih načinov beleženja in spremljanja.
Vir: www.habr.com