Težko je ujeti bistvo, ko govorimo o DevOpsu? Zbrali smo jasne analogije, udarne formulacije in nasvete strokovnjakov, ki bodo pomagali razumeti tudi tistim, ki niso strokovnjaki. Na koncu še bonusa – lastni DevOps zaposlenih Red Hat.
Termin DevOps se je pojavil pred 10 leti in prešel pot od heštagov na Twitterju do močnega kulturnega gibanja v svetu IT, prave filozofije, ki spodbuja razvijalce k hitrejšemu doseganju rezultatov, eksperimentiranju in napredovanju po metodi iteracij. DevOps je postal nedeljivo povezan s pojmom digitalne transformacije. Ampak kot je pogosto pri IT terminologiji, je v desetih letih DevOps obrál množico opredelitev, razlag in zablod.
Zato je o DevOpsu pogosto slišati vprašanja, kot so, ali je to isto kot agilno? Ali je to posebna metodologija? Ali je to le še en sinonim za besedo "sodelovanje"?
DevOps vključuje mnogo različnih konceptov (nenešno dostavljanje, nenešna integracija, avtomatizacija itd.), zato je lahko težko izluščiti bistvo, še posebej, če do teme niste brezbrižni. Vendar je to znanje zelo koristno, ne glede na to, ali poskušate prenesti svoje ideje svojemu nadrejenemu ali pa preprosto pripovedujete o svojem delu nekomu izmed svojcev ali znancev. Zato bomo zaenkrat pustili ob strani terminološke nianse DevOpsa in se osredotočili na celotno sliko.
Kaj je DevOps: 6 opredelitev in analogij
Prosili smo strokovnjake, da razložijo bistvo DevOpsa na kar najpreprostejši in najkrajši način, da bi njeno vrednost razumel bralec katere koli ravni tehnične usposobljenosti. Na podlagi teh pogovorov smo izbrali najsvetlejše analogije in udarne formulacije, ki vam bodo pomagale oblikovati svojo pripoved o DevOpsu.
1. DevOps – to je kulturno gibanje
«DevOps – to je kulturno gibanje, v okviru katerega obe strani (razvijalci programske opreme in strokovnjaki za delovanje IT sistemov) priznajo, da programska oprema ne prinaša prave koristi, dokler je ne začne uporabljati nekdo: naročniki, stranke, zaposleni, ni važno,« pravi Eveline Oehrlich, višja analitičarka raziskovalka v Inštitutu DevOps. «Zato obe strani skupaj zagotavljata hitro in kakovostno dostavo programske opreme».
2. DevOps – to je tisto, kar daje moč razvijalcem
„DevOps empowers developers with the ability to own applications, deploy them, and manage delivery from start to finish“
„Typically, DevOps is discussed as a way to speed up application delivery to production by building and employing automated processes,” says Jai Schniepp, director of DevOps platforms at Liberty Mutual insurance. “But for me, it is a much more fundamental matter. DevOps gives developers the authority over applications or specific parts of software, to deploy them and manage delivery from beginning to end. DevOps eliminates confusion regarding responsibility and guides all participants in the process towards creating an automated and developer-managed infrastructure.”
3. DevOps is about collaboration in creating and delivering applications
„In simple terms, DevOps is an approach to software production and delivery where everyone works together,” notes Gur Staff, president and head of digital business automation at BMC.
4. DevOps is a pipeline
„A pipeline assembly is only possible if all parts fit together.”
„I would compare DevOps to an assembly line for cars,” continues Gur Staff. “The idea is to design and create all parts in advance so they can be assembled without individual adjustments. A pipeline assembly is only possible if all parts fit one another. Those who design and create the engine must consider how to attach it to the chassis or frame. Those who make the brakes need to think about the wheels, and so on. The same applies to software.”
A developer creating business logic or a user interface must consider the database that holds customer information, the security measures to protect user data, and how all this will function when the service serves a large, possibly even millions-strong audience of users.”
„Zagotovi, da ljudje sodelujejo in razmišljajo o tistih delih dela, ki jih opravljajo drugi, namesto da se osredotočajo izključno na svoje naloge – to je največja ovira, ki jo je treba premagati. Če to uspe, imate odlične možnosti za digitalno preobrazbo,“ dodaja Gur Staf.
5. DevOps je prava kombinacija ljudi, procesov in avtomatizacije.
Jayne Groll, izvršna direktorica Inštituta DevOps, je predlagala odlično analogijo za razlago DevOps-a. Po njenih besedah je „DevOps kot kulinarični recept, v katerem so trije osnovni kategorije sestavin: ljudje, procesi in avtomatizacija. Večina teh sestavin se lahko vzame iz drugih področij in virov: Lean, Agile, SRE, CI/CD, ITIL, vodstvo, kultura, orodja. Ključ do DevOps-a, kot pri katerem koli dobrem receptu, je v pravilnem izbiranju proporcij in mešanju teh sestavin, da se poveča hitrost in učinkovitost pri ustvarjanju in izdaji aplikacij.“
6. DevOps je, kadar programerji delajo kot ekipa Formule 1.
„Dirka se ne načrtuje od starta do cilja, ampak obratno, od cilja do starta.“
„Ko govorim o tem, česa pričakovati od iniciative DevOps, navajam primer dirkaške ekipe NASCAR ali Formule 1,“ pravi Chris Short, glavni vodja za trženje oblačnih platform Red Hat in urednik novičnika DevOps’ish. „Vodja takšne ekipe ima en sam cilj: doseči najvišjo možno mesto na koncu dirke, ob upoštevanju razpoložljivih virov in izzivov, s katerimi se ekipa sooča. Pri tem se dirka ne načrtuje od starta do cilja, ampak obratno, od cilja do starta. Najprej se postavi ambiciozen cilj, nato se določijo poti za njegovo dosego. Po tem se razdelijo v podnaloge in dodelijo članom ekipe.“
„Cel teden pred dirko ekipa izpopolnjuje postopek pit-stop. Opravljajo moč in kardio treninge, da ostanejo v formi na napornem dirkaškem dnevu. Vadijo usklajeno delovanje pri reševanju morebitnih težav, ki se lahko pojavijo med dirko. Podobno se mora razvojna ekipa usposabljati za pogosto sproščanje novih različic. S takšnimi veščinami in delujočim sistemom varnosti je sproščanje novih različic v produkcijo tudi pogostejše. V okviru tega prepričanja povečanje hitrosti pomeni povečanje varnosti,” pravi Short.
„Gre za to, da ne gre za „pravilne stvari“, dodaja Short, „temveč za odpravljanje čim več stvari, ki ovirajo dosego želenega rezultata. Sodelujte in prilagajajte se glede na povratne informacije, ki jih prejemate v realnem času. Bodite pripravljeni na anomaliije in delajte na izboljšanju kakovosti, da zmanjšate njihov vpliv na napredovanje k cilju. To nas čaka v svetu DevOps.“
Kako razširiti DevOps: 10 nasvetov strokovnjakov
Preprost DevOps in množični DevOps sta popolnoma različni stvari. Povedali vam bomo, kako premagati ovire na poti od prvega do drugega.
Za mnoge organizacije je pot do DevOps začenjala enostavno in prijetno. Ustvarjajo se majhne strastne ekipe, stari procesi so zamenjani z novimi, prve uspehe pa ni težko doseči.
Žal je to le lažni sijaj, iluzija napredka, kot pravi Ben Grinnell, izvršni direktor in vodja oddelka za digitalno tehnologijo svetovalnega podjetja North Highland. Zgodnje zmage so vsekakor obetavne, vendar ne pomagajo doseči končnega cilja, in sicer množične uporabe DevOps v organizaciji.
Zlahka je videti, da se tako oblikuje kultura delitve na „mi“ in „oni“.
«Pogosto organizacije začenjajo tovrstne pionirske projekte, prepričane, da bodo utirale pot množičnemu DevOpsu, ne da bi razmišljale, ali se bodo drugi želeli in mogli podati na to pot,« pojasnjuje Ben Greennell. «Ekipo za izvajanje teh projektov običajno sestavljajo samozavestni 'vikingi', ki so že izvajali kaj podobnega drugje, a so novinci v vaši organizaciji. Hkrati jih spodbujajo, da rušijo in uničujejo pravila, ki ostajajo obvezna za vse druge. Enostavno je opaziti, da se tako oblikuje kultura ločitve na 'mi' in 'oni', kar ovira prenos znanja in veščin.»
«In ta kulturna težava je le en od razlogov, zakaj je DevOps težko razširiti. DevOps ekipe se soočajo z naraščajočimi tehničnimi težavami, značilnimi za hitro razvijajoče se podjetja, ki stavijo na IT-tehnologije,« pravi Steve Newman, ustanovitelj in predsednik uprave podjetja Scalyr.
«V sodobnem svetu se storitve spreminjajo takoj, ko se pojavi potreba. Nenehno izvajati in uvajati nove funkcije je seveda odlično, toda usklajevati ta postopek in odpravljati vznikle težave je prava glavobol,« dodaja Steve Newman. «V zelo hitro rastočih organizacijah se inženirji v sestavljenih ekipah trudijo, da ohranijo sposobnost spremljanja sprememb in povzročajočih kaskadnih učinkov na ravni odvisnosti. Poleg tega inženirje nikakor ne veseli, ko jih prikrajšajo za to sposobnost in jim posledično postane težje razumeti naravo vzniklih težav.»
Kako premagati zgoraj omenjene izzive in preiti na množično uporabo DevOps v veliki organizaciji? Strokovnjaki pozivajo, naj razvijete potrpljenje, tudi če je vaš končni cilj pospešitev cikla razvoja programske opreme in poslovnih procesov.
1. Ne pozabite, da potrebujejo spremembe v kulturi čas
Jayne Groll, izvršna direktorica Inštituta DevOps: «Po mojem mnenju bi morala biti širitev DevOps prav tako postopna in iterativna kot agilni razvoj (in prav tako obravnavati kulturo). V Agile in DevOps je poudarek na majhnih ekipah. Vendar pa, ko se število in integracija teh ekip povečuje, dobivamo vedno več ljudi, ki uvajajo nove delovne metode, kar posledično vodi k obsežni kulturni transformaciji».
2. Dajte dovolj časa za načrtovanje in izbiro platforme
Eran Kinsbruner, glavni tehnični evangelist podjetja Perfecto: «Da bi bila širitev uspešna, se morajo DevOps ekipe sprva naučiti kombinirati tradicionalne procese, orodja in veščine, nato pa postopoma razvijati vsako fazo DevOps in jo stabilizirati. Vse se začne z natančnim načrtovanjem uporabniških zgodb in tokov ustvarjanja vrednosti, nato pa sledi faza pisanja programske opreme in nadzora različic z uporabo trunk-based development ali drugih pristopov, ki so najbolj primerni za razvejitve in združevanje kode».
«Sledi faza integracije in testiranja, kjer je potrebna skalabilna platforma za avtomatizacijo. In tukaj je za DevOps ekipe ključno izbrati pravo platformo, ki ustreza njihovim veščinam in končnim ciljem projekta.
Naslednja faza je implementacija v produkcijsko okolje, ki mora biti povsem avtomatizirana z uporabo orodij za orkestracijo in kontejnerje. Pri tem je pomembno imeti virtualizirana okolja v vseh fazah DevOps (simulator produkcijskega okolja, okolje za nadzor kakovosti in samo produkcijsko okolje) ter vedno uporabljati le najnovejše podatke za teste, da bi pridobili актуalne vpoglede. Analitika mora biti inteligentna in sposobna obdelovati velike podatke z hitro in učinkovito povratno informacijo».
3. Osvobodite odgovornost od okusa krivde
Gordon Haff, evangelist podjetja RedHat: „Ustvarjanje sistema in vzdušja, ki dovoljuje in spodbuja eksperimente, omogoča uresničitev tistih uspešnih napak v agilnem razvoju programske opreme. To ne pomeni, da za napake ne odgovarja več nihče. V resnici je iskanje odgovornega še lažje, saj 'biti odgovoren' ne pomeni več 'postati krivec za nesrečo'. To pomeni, da se bistvo odgovornosti kakovostno spreminja. Ob tem postanejo izjemno pomembni štirje dejavniki: obseg napake, pristopi, proizvodni procesi in spodbude.“ (Več o teh dejavnikih lahko preberete v članku Gordona Haffa „DevOps lessons: 4 aspects of healthy experiments“.)
4. Očistite pot naprej
Ben Grinnell, izvršni direktor in vodja področja digitalnih tehnologij svetovalne firme North Highland: „Da bi dosegli razširitev, priporočam, da ob projektih pionirjev začnete tudi program 'očistimo pot'. Cilj tega programa je odstranjevanje smeti, ki ostajajo za pionirji DevOps, kot so neveljavna pravila in druge podobne stvari, da pot naprej ostane prosta.“
„Zagotovite organizacijsko podporo in dajte zagon s komunikacijo, ki presega skupino pionirjev, ter široko proslavite uspehe novih delovnih metod. Usposabljajte ljudi, ki sodelujejo v naslednji valovi projektov DevOps in so živčni, ker DevOps uporabljajo prvič. In ne pozabite, da so ti ljudje bistveno drugačni od pionirjev.“
5. Učinite orodja bolj demokratična
Steve Newman, ustanovitelj in predsednik uprave podjetja Scalyr: „Orodij ni treba skrivati pred ljudmi, in morajo biti razmeroma enostavna za učenje za vsakogar, ki je pripravljen vložiti čas vanje. Če je možnost zahtevanja logov omogočena le trem ljudem, 'certificiranim' za delo s katerim koli orodjem, boste vedno imeli največ tri osebe, sposobne rešiti ustrezen problem, tudi če imate zelo veliko računalniško okolje. Drugimi besedami, to ustvari ozko grlo, ki lahko povzroči resne (za posel) posledice.“
6. Ustvarite idealne pogoje za delo ekipe
Tom Clark, vodja področja Common Platform v telekomunikacijski družbi ITV: „Lahko storite karkoli, a ne vse hkrati. Zato postavite velike cilje, začnite počasi in napredujte s hitrimi iteracijami. Sčasoma boste pridobili ugled ekipe, ki ji uspeva, tako da bodo drugi želeli uporabljati vaše metode. Ne zasledujte visokoučinkovitosti ekipe. Namesto tega zagotovite ljudem idealne pogoje za delo, učinkovitost pa bo prišla sama od sebe.“
7. Ne pozabite na Conwayev zakon in kanban tablo
Logan Daigle, direktor za dostavo programske opreme in strategijo DevOps pri podjetju CollabNetVersionOne: „Pomembno je zavedati se posledic Conwayevega zakona. V mojem prostem prevodu ta zakon pravi, da so izdelki, ki jih ustvarjamo, in procesi, ki jih pri tem uporabljamo, vključno z DevOps, organizirani tako, kot je naša organizacija.“
„Če je v organizaciji visoka razdrobljenost, in ko pri načrtovanju, ustvarjanju in sproščanju programske opreme upravljanje večkrat prehaja iz rok v roke, bo učinek skaliranja ničelni ali kratkotrajen. Če pa organizacija oblikuje čez funkcionalne ekipe okoli izdelkov, ki so financirani ob upoštevanju trga, se možnosti za uspeh drastično povečajo.“
„Še en pomemben vidik skaliranja je, da na kanban tablah prikažemo vse delo, ki je v teku (WIP, work in progress). Ko v organizaciji obstaja prostor, kjer ljudje lahko vidijo takšne stvari, to močno spodbuja sodelovanje, kar pozitivno vpliva na skaliranje.“
8. Iščite stare brazgotine
Manuel Pais, svetovalec za DevOps in soavtor knjige „Team Topologies“: „Izvoz praks DevOps iz lastnega Dev in Ops ter poskus njihove uporabe za druge funkcije zagotovo ne moremo obravnavati kot optimalen pristop. To bo nedvomno prineslo določen učinek (na primer z avtomatizacijo ročnega upravljanja), vendar lahko dosežemo mnogo več, če začnemo z razumevanjem procesov dostave in povratnih informacij“.
„Če v IT-sistemu organizacije obstajajo stari madeži – postopki in mehanizmi upravljanja, ki so bili uvedeni kot posledica prejšnjih incidentov, vendar so izgubili pomembnost (zaradi spremembe izdelkov, tehnologij ali procesov), jih je seveda treba odstraniti ali izravnati, ne pa avtomatizirati neučinkovitih ali nepotrebnih procesov.“
9. Ne ustvarjajte različic DevOps
Antony Edwards, direktor proizvodnje podjetja Eggplant: „DevOps je zelo nejasen izraz, zato ima vsaka ekipa svojo različico DevOps. Nič ni hujšega, kot ko v organizaciji nastane kar 20 različnih različic DevOps, ki se ne ujemajo dobro med seboj. Ne sme biti, da ima vsaka od treh razvojnih ekip svoj, posebni vmesnik med razvojem in upravljanjem izdelka. Prav tako ne sme biti, da imajo izdelki svoje, edinstvene pričakovanja glede obravnave povratnih informacij pri selitvi v simulacijo proizvodnega okolja. V nasprotnem primeru DevOps nikoli ne bo mogoče razširiti.“
10. Poudarjajte vrednost DevOps za podjetje
Steve Newman, ustanovitelj in predsednik uprave podjetja Scalyr: „Delajte na priznanju vrednosti DevOps. Naučite se in ne bojte se govoriti o koristih tega, kar počnete. DevOps izjemno prihrani čas in denar (le pomislite: manj izpadov, krajši povprečni čas okrevanja), ekipe DevOps pa morajo nepretrgoma poudarjati (in propagirati) pomembnost teh pobud za uspeh podjetja. Tako boste lahko razširili število privržencev in okrepili vpliv DevOps v organizaciji.“
BONUS
Na 13. septembra bo naš lastni DevOps – da, Red Hat, kot proizvajalec programske opreme, ima svoje DevOps ekipe in prakse.
Naš inženir Mark Birger, ki se ukvarja z razvojem storitev notranje avtomatizacije za druge skupine v celotni organizaciji, bo v slovenščini delil svojo zgodbo – kako je DevOps ekipa Red Hat migrirala aplikacije iz virtualnih okolij Hat Virtualization, upravljanih z Ansible, v celovit kontejnerski format na platformi OpenShift.
Ampak to niti ni vse:
Ko je organizacija prenesla delovne obremenitve v kontejnerje, tradicijski načini spremljanja aplikacij morda ne bodo delovali. V drugem poročilu bomo razložili naše razloge za spremembo pristopa k beleženju in pokazali nadaljevanje poti, ki nas je pripeljala do sodobnih metod beleženja in spremljanja.
Izvor: habr.com
