Je li teško shvatiti glavnu poantu kada govorimo o DevOps-u? Za vas smo prikupili živopisne analogije, upečatljive formulacije i savjete stručnjaka koji će čak i nestručnjacima pomoći da prijeđu na stvar. Na kraju, bonus je vlastiti DevOps zaposlenika Red Hata.
Izraz DevOps nastao je prije 10 godina i prešao je put od hashtaga na Twitteru do snažnog kulturnog pokreta u IT svijetu, istinske filozofije koja potiče programere da brže obavljaju stvari, eksperimentiraju i ponavljaju. DevOps je postao neraskidivo povezan s konceptom digitalne transformacije. Ali kao što se često događa s IT terminologijom, DevOps je u proteklih deset godina stekao mnoge definicije, tumačenja i pogrešne predodžbe o sebi.
Stoga se često mogu čuti pitanja o DevOps-u poput, je li to isto što i agile? Ili je to neka posebna metodologija? Ili je to samo još jedan sinonim za riječ "suradnja"?
DevOps uključuje mnogo različitih koncepata (kontinuirana isporuka, kontinuirana integracija, automatizacija, itd.), tako da otkrivanje onoga što je važno može biti izazovno, pogotovo ako ste strastveni oko te teme. No, ova vještina je vrlo korisna, bez obzira na to pokušavate li svoje ideje prenijeti nadređenima ili jednostavno nekome iz obitelji ili prijateljima pričate o svom poslu. Stoga, ostavimo sada po strani terminološke nijanse DevOpsa i usredotočimo se na veliku sliku.
Što je DevOps: 6 definicija i analogija
Zamolili smo stručnjake da što jednostavnije i kraće objasne bit DevOps-a kako bi njegova vrijednost postala jasna čitateljima s bilo kojom razinom tehničkog znanja. Na temelju rezultata ovih razgovora odabrali smo najupečatljivije analogije i upečatljive formulacije koje će vam pomoći da izgradite svoju priču o DevOps-u.
1. DevOps je kulturni pokret
"DevOps je kulturni pokret u kojem obje strane (programeri softvera i stručnjaci za rad IT sustava) prepoznaju da softver ne donosi stvarne koristi sve dok ga netko ne počne koristiti: klijenti, klijenti, zaposlenici, a ne bit", kaže Eveline Oehrlich, viša istraživačica analitičar na DevOps institutu. “Stoga obje ove strane zajednički osiguravaju brzu i kvalitetnu isporuku softvera.”
2. DevOps je o osnaživanju programera.
"DevOps omogućuje programerima da posjeduju aplikacije, pokreću ih i upravljaju isporukom od početka do kraja."
"O DevOpsu se obično govori kao o načinu da se ubrza isporuka aplikacija u proizvodnju izgradnjom i implementacijom automatiziranih procesa", kaže Jai Schniepp, direktor DevOps platformi u osiguravajućem društvu Liberty Mutual. "Ali za mene je to mnogo temeljnija stvar." DevOps omogućuje programerima da posjeduju aplikacije ili određene dijelove softvera, pokreću ih i upravljaju njihovom isporukom od početka do kraja. DevOps eliminira zbrku oko odgovornosti i vodi sve uključene u stvaranje automatizirane infrastrukture vođene razvojnim programerima.”
3. DevOps je o suradnji u stvaranju i isporuci aplikacija.
"Jednostavno rečeno, DevOps je pristup proizvodnji i isporuci softvera u kojem svi rade zajedno", kaže Gur Staf, predsjednik i voditelj automatizacije digitalnog poslovanja u BMC-u.
4. DevOps je cjevovod
"Sastavljanje pokretne trake moguće je samo ako svi dijelovi pristaju zajedno."
“Usporedio bih DevOps s trakom za sklapanje automobila,” nastavlja Gur Staff. – Ideja je unaprijed osmisliti i izraditi sve dijelove kako bi se onda mogli sastavljati bez individualnog podešavanja. Montaža pokretne trake moguća je samo ako svi dijelovi pristaju zajedno. Oni koji dizajniraju i izrađuju motor moraju razmisliti o tome kako ga montirati na tijelo ili okvir. Oni koji prave kočnice moraju misliti na kotače i tako dalje. Isto bi trebalo biti i sa softverom.
Programer koji stvara poslovnu logiku ili korisničko sučelje mora razmišljati o bazi podataka koja pohranjuje informacije o korisnicima, sigurnosnim mjerama za zaštitu korisničkih podataka i kako će sve to funkcionirati kada usluga počne služiti velikoj, možda čak višemilijunskoj korisničkoj publici ."
“Natjerati ljude da surađuju i razmišljaju o dijelovima posla koje drugi rade, umjesto da se fokusiraju samo na vlastite zadatke, najveća je prepreka koju treba prevladati. Ako to možete učiniti, imate izvrsne šanse za digitalnu transformaciju,” dodaje Gur Staff.
5. DevOps je prava kombinacija ljudi, procesa i automatizacije
Jayne Groll, izvršna direktorica DevOps instituta, ponudila je sjajnu analogiju kako bi objasnila DevOps. Prema njezinim riječima, “DevOps je poput recepta s tri glavne kategorije sastojaka: ljudi, proces i automatizacija. Većina ovih sastojaka može se uzeti iz drugih područja i izvora: Lean, Agile, SRE, CI/CD, ITIL, vodstvo, kultura, alati. Tajna DevOps-a, kao i svakog dobrog recepta, je kako dobiti prave omjere i mješavinu ovih sastojaka za povećanje brzine i učinkovitosti kreiranja i objavljivanja aplikacija.”
6. DevOps je kada programeri rade kao tim Formule 1
“Utrka nije planirana od starta do cilja, nego naprotiv, od cilja do starta.”
"Kada govorim o tome što očekivati od DevOps inicijative, mislim na NASCAR ili trkaći tim Formule 1 kao primjer", kaže Chris Short, viši menadžer marketinga platforme u oblaku u Red Hatu i izdavač DevOpsovog biltena. – Vođa takvog tima ima jedan cilj: zauzeti što više mjesto na kraju utrke, uzimajući u obzir resurse kojima tim raspolaže i izazove koji su ga zadesili. U ovom slučaju, utrka se ne planira od starta do cilja, već naprotiv, od cilja do starta. Najprije se postavlja ambiciozan cilj, a zatim se određuju načini za njegovo postizanje. Zatim se dijele na podzadatke i delegiraju članovima tima.”
“Tim provodi cijeli tjedan prije utrke usavršavajući zaustavljanje u boksu. Radi vježbe snage i kardio vježbe kako bi ostao u formi za naporan dan utrke. Vježba zajednički rad na rješavanju problema koji se mogu pojaviti tijekom utrke. Isto tako, razvojni tim trebao bi uvježbati vještinu čestog izdavanja novih verzija. Ako imate takve vještine i dobro funkcionirajući sigurnosni sustav, lansiranje novih verzija u proizvodnju također se događa češće. U ovom svjetonazoru, veća brzina znači veću sigurnost”, kaže Short.
“Ne radi se o tome da radimo 'pravu stvar',” dodaje Short, “već o eliminiranju što je više moguće stvari koje stoje na putu željenom ishodu. Surađujte i prilagođavajte se na temelju povratnih informacija koje primate u stvarnom vremenu. Budite spremni na anomalije i radite na poboljšanju kvalitete kako biste smanjili njihov utjecaj na napredak prema vašem cilju. To je ono što nas čeka u svijetu DevOps-a.”
Kako skalirati DevOps: 10 savjeta stručnjaka
Samo što su DevOps i masovni DevOps potpuno različite stvari. Reći ćemo vam kako prevladati prepreke na putu od prvog do drugog.
Za mnoge organizacije, putovanje u DevOps počinje lako i ugodno. Stvaraju se mali strastveni timovi, stari procesi zamjenjuju se novima, a prvi uspjesi se ne čekaju dugo.
Jao, ovo je samo lažni sjaj, iluzija napretka, kaže Ben Grinnell, direktor i voditelj digitalnog odjela konzultantske tvrtke North Highland. Rane pobjede svakako su ohrabrujuće, ali ne pomažu u postizanju krajnjeg cilja širokog usvajanja DevOps-a u cijeloj organizaciji.
Lako je vidjeti da je rezultat kultura podjele između “nas” i “njih”.
“Često organizacije pokreću ove pionirske projekte misleći da će utrti put za mainstream DevOps, bez razmatranja hoće li drugi moći ili htjeti slijediti taj put,” objašnjava Ben Grinnell. – Timovi za provedbu ovakvih projekata obično se regrutiraju od samouvjerenih “Varajaga” koji su već radili nešto slično na drugim mjestima, ali su novi u vašoj organizaciji. Istodobno ih se potiče da krše i uništavaju pravila koja ostaju obvezujuća za sve ostale. Lako je vidjeti da je rezultat kultura “nas” i “njih” koja koči prijenos znanja i vještina.”
“A ovaj kulturni problem samo je jedan od razloga zašto je DevOps teško mjeriti. DevOps timovi suočavaju se s povećanim tehničkim izazovima koji su tipični za brzorastuće IT tvrtke,” rekao je Steve Newman, osnivač i predsjednik Scalyr-a.
“U modernom svijetu usluge se mijenjaju čim se ukaže potreba. Sjajno je stalno implementirati i implementirati nove značajke, ali koordinacija ovog procesa i otklanjanje problema koji se pojavljuju prava je glavobolja, dodaje Steve Newman. – U vrlo brzorastućim organizacijama, inženjeri u međufunkcionalnim timovima bore se za održavanje vidljivosti promjena i kaskadnih učinaka na razini ovisnosti koje one stvaraju. Štoviše, inženjeri nisu sretni kada su lišeni te mogućnosti i, kao rezultat toga, postaje im teže razumjeti bit problema koji se pojavljuju.”
Kako prevladati gore opisane izazove i krenuti prema masovnom usvajanju DevOpsa u velikoj organizaciji? Stručnjaci pozivaju na strpljenje, čak i ako je vaš krajnji cilj ubrzati razvojni ciklus softvera i poslovne procese.
1. Zapamtite da je za promjenu kulture potrebno vrijeme.
Jayne Groll, izvršna direktorica, DevOps Institute: “Po mom mišljenju, širenje DevOps-a trebalo bi biti inkrementalno i iterativno kao i agilni razvoj (i jednako se doticati kulture). Agile i DevOps naglašavaju male timove. Ali kako ti timovi rastu u broju i integraciji, sve više ljudi prihvaća nove načine rada, a kao rezultat toga dolazi do goleme kulturne transformacije.”
2. Posvetite dovoljno vremena planiranju i odabiru platforme
Eran Kinsbruner, vodeći tehnički evangelist u Perfectu: “Da bi skaliranje uspjelo, DevOps timovi prvo moraju naučiti kombinirati tradicionalne procese, alate i vještine, a zatim polako njegovati i stabilizirati svaku pojedinačnu fazu DevOpsa. Sve počinje pažljivim planiranjem korisničkih priča i tokova vrijednosti, nakon čega slijedi pisanje softvera i kontrola verzija korištenjem razvoja temeljenog na deblu ili drugih pristupa koji su najprikladniji za grananje i spajanje koda.”
“Tada dolazi faza integracije i testiranja, gdje je već potrebna skalabilna platforma za automatizaciju. Ovdje je važno da DevOps timovi odaberu pravu platformu koja odgovara njihovoj razini vještina i krajnjim ciljevima projekta.
Sljedeća faza je implementacija u proizvodnju i to bi trebalo biti potpuno automatizirano pomoću alata za orkestraciju i spremnika. Važno je imati virtualizirana okruženja u svim fazama DevOps-a (simulator proizvodnje, QA okruženje i stvarno proizvodno okruženje) i uvijek koristiti samo najnovije podatke za testove kako bi se dobili relevantni zaključci. Analitika mora biti pametna i sposobna obraditi velike podatke s brzim i djelotvornim povratnim informacijama.”
3. Izbacite krivnju iz odgovornosti.
Gordon Haff, RedHat evangelist: “Stvaranje sustava i atmosfere koji dopušta i potiče eksperimentiranje omogućuje ono što je poznato kao uspješni neuspjesi u agilnom razvoju softvera. To ne znači da nitko drugi nije odgovoran za neuspjehe. Zapravo, identificirati tko je odgovoran postaje još lakše, jer "biti odgovoran" više ne znači "izazvati nesreću". Odnosno, kvalitativno se mijenja bit odgovornosti. Četiri čimbenika postaju kritična: opseg poremećaja, pristupi, proizvodni procesi i poticaji.” (Možete pročitati više o ovim čimbenicima u članku Gordona Huffa "DevOps lekcije: 4 aspekta zdravih eksperimenata.")
4. Očistite put naprijed
Ben Grinnell, direktor i voditelj digitalnog odjela konzultantske tvrtke North Highland: “Kako bi se postigao razmjer, preporučujem pokretanje programa “raščišćavanja staza” zajedno s pionirskim projektima. Cilj ovog programa je očistiti smeće koje DevOps pioniri ostavljaju za sobom, poput zastarjelih pravila i sličnih stvari, tako da put naprijed ostane jasan.”
“Pružite ljudima organizacijsku podršku i zamah kroz komunikaciju koja nadilazi pionirsku skupinu tako što ćete naširoko slaviti uspjehe novih načina rada. Trenirajte ljude koji su uključeni u sljedeći val DevOps projekata i nervozni su zbog prve upotrebe DevOpsa. I zapamtite da se ti ljudi jako razlikuju od pionira.”
5. Demokratizirajte alate
Steve Newman, osnivač i predsjednik Scalyr-a: „Alati ne bi trebali biti skriveni od ljudi i trebali bi biti relativno laki za naučiti svakoga tko je spreman uložiti vrijeme. Ako je mogućnost postavljanja upita za zapisnike ograničena na tri osobe "certificirane" za korištenje alata, uvijek ćete imati maksimalno tri osobe dostupne za rješavanje problema, čak i ako imate vrlo veliko računalno okruženje. Drugim riječima, ovdje postoji usko grlo koje može dovesti do ozbiljnih (poslovnih) posljedica.”
6. Stvorite idealne uvjete za timski rad
Tom Clark, voditelj zajedničke platforme na ITV-u: “Možeš sve, ali ne sve odjednom. Stoga postavite velike ciljeve, počnite s malim i krenite naprijed u brzim ponavljanjima. S vremenom ćete steći reputaciju da obavljate stvari, pa će i drugi htjeti koristiti vaše metode. I ne brinite o izgradnji vrlo učinkovitog tima. Umjesto toga, osigurajte ljudima idealne radne uvjete i učinkovitost će uslijediti.”
7. Ne zaboravite na Conwayev zakon i Kanban ploče
Logan Daigle, direktor isporuke softvera i DevOps strategije u CollabNetVersionOne: “Važno je razumjeti posljedice Conwayeva zakona. U mojoj slobodnoj parafrazi, ovaj zakon kaže da su proizvodi koje stvaramo i procesi koje koristimo za to, uključujući DevOps, strukturirani na isti način kao i naša organizacija.”
„Ako postoji mnogo silosa u organizaciji, a kontrola mnogo puta prelazi iz ruke u ruke prilikom planiranja, izgradnje i izdavanja softvera, učinak skaliranja bit će nula ili će kratko trajati. Ako organizacija izgradi međufunkcionalne timove oko proizvoda koji se financiraju s tržišnim fokusom, tada se šanse za uspjeh dramatično povećavaju.”
„Još jedan važan aspekt skaliranja je prikaz svih radova koji su u tijeku (WIP, workinprogress) na Kanban pločama. Kada organizacija ima mjesto gdje ljudi mogu vidjeti te stvari, to uvelike potiče suradnju, što ima pozitivan učinak na skaliranje.”
8. Potražite stare ožiljke
Manuel Pais, DevOps konzultant i koautor Team Topologies: “Preuzimanje DevOps praksi izvan samog Dev and Ops i pokušaj njihove primjene na druge funkcije teško da je optimalan pristup. To će sigurno imati određenog utjecaja (na primjer, automatiziranjem ručne kontrole), ali mnogo više se može postići ako počnemo s razumijevanjem procesa isporuke i povratnih informacija.”
“Ako postoje stari ožiljci u IT sustavu organizacije – procedure i mehanizmi upravljanja koji su implementirani kao rezultat prošlih incidenata, ali su izgubili na važnosti (zbog promjena u proizvodima, tehnologijama ili procesima) – onda ih svakako treba ukloniti ili izglađen, umjesto automatizacije neučinkovitih ili nepotrebnih procesa.”
9. Nemojte uzgajati DevOps opcije
Anthony Edwards, direktor operacija u Eggplantu: “DevOps je vrlo nejasan pojam, tako da svaki tim na kraju ima svoju verziju DevOps-a. A nema ništa gore kada organizacija odjednom ima 20 varijanti DevOps-a koji se međusobno ne slažu najbolje. Nemoguće je da svaki od tri razvojna tima ima svoje, posebno sučelje između razvoja i upravljanja proizvodima. Proizvodi također ne bi trebali imati vlastita jedinstvena očekivanja za rukovanje povratnim informacijama kada se prenesu u simulator proizvodnje. U suprotnom, nikada nećete moći skalirati DevOps.”
10. Propovijedajte poslovnu vrijednost DevOps-a
Steve Newman, osnivač i predsjednik Scalyr-a: “Radite na prepoznavanju vrijednosti DevOps-a. Naučite i slobodno pričajte o prednostima onoga što radite. DevOps je nevjerojatna ušteda vremena i novca (samo pomislite: manje zastoja, kraće srednje vrijeme do oporavka), a DevOps timovi moraju neumorno naglašavati (i propovijedati) važnost ovih inicijativa za poslovni uspjeh. Na taj način možete proširiti krug pristaša i povećati utjecaj DevOps-a u organizaciji.”
BONUS
Na Naš vlastiti DevOps stići će 13. rujna - da, Red Hat, kao proizvođač softvera, ima svoje vlastite DevOps timove i prakse.
Naš inženjer Mark Birger, koji razvija usluge interne automatizacije za druge grupe u cijeloj organizaciji, ispričat će svoju priču na čistom ruskom - kako je Red Hat DevOps tim migrirao aplikacije iz virtualnih okruženja Hat Virtualization kojima upravlja Ansible u puni format spremnika na platformi OpenShift.
Ali to nije sve:
Nakon što organizacije premjeste radna opterećenja u spremnike, tradicionalne metode praćenja aplikacija možda neće raditi. U drugom predavanju ćemo objasniti našu motivaciju za promjenu načina zapisivanja i prikazati nastavak puta koji nas je doveo do modernih metoda zapisivanja i praćenja.
Izvor: www.habr.com