Da li je teško shvatiti glavnu poentu kada govorimo o DevOps-u? Prikupili smo za vas živopisne analogije, upečatljive formulacije i savjete stručnjaka koji će čak i nestručnjacima pomoći da dođu do stvari. Na kraju, bonus je vlastiti DevOps zaposlenika Red Hata.
Termin DevOps nastao je prije 10 godina i od hashtag-a na Twitteru postao je moćni kulturni pokret u IT svijetu, istinska filozofija koja ohrabruje programere da stvari rade brže, eksperimentišu i ponavljaju. DevOps je postao neraskidivo povezan s konceptom digitalne transformacije. Ali kao što se često dešava sa IT terminologijom, u proteklih deset godina DevOps je stekao mnoge definicije, tumačenja i zablude o sebi.
Stoga često možete čuti pitanja o DevOps-u poput, da li je to isto što i agile? Ili je ovo neka posebna metodologija? Ili je to samo još jedan sinonim za riječ "saradnja"?
DevOps uključuje mnogo različitih koncepata (kontinuirana isporuka, kontinuirana integracija, automatizacija, itd.), tako da otkrivanje onoga što je važno može biti izazov, posebno kada ste strastveni o ovoj temi. Međutim, ova vještina je vrlo korisna, bez obzira pokušavate li svoje ideje prenijeti nadređenima ili jednostavno nekome iz porodice ili prijatelja pričate o svom poslu. Stoga, ostavimo po strani terminološke nijanse DevOps-a za sada i fokusiramo se na širu sliku.
Šta je DevOps: 6 definicija i analogija
Zamolili smo stručnjake da što jednostavnije i kraće objasne suštinu DevOps-a kako bi njegova vrijednost postala jasna čitaocima sa bilo kojim nivoom tehničkog znanja. Na osnovu 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 operaciju IT sistema) prepoznaju da softver ne donosi stvarne koristi dok ga neko ne počne koristiti: kupci, klijenti, zaposlenici, a ne poenta,” kaže Eveline Oehrlich, viši istraživač analitičar na DevOps institutu. “Stoga obje ove strane zajednički osiguravaju brzu i kvalitetnu isporuku softvera.”
2. DevOps se odnosi na osnaživanje programera.
“DevOps omogućava programerima da posjeduju aplikacije, pokreću ih i upravljaju isporukom od početka do kraja.”
„Obično se o DevOps-u govori kao o načinu da se ubrza isporuka aplikacija u proizvodnju izgradnjom i implementacijom automatizovanih procesa“, kaže Jai Schniepp, direktor DevOps platformi u osiguravajućoj kompaniji Liberty Mutual. “Ali za mene je to mnogo fundamentalnija stvar.” DevOps omogućava programerima da posjeduju aplikacije ili određene dijelove softvera, pokreću ih i upravljaju njihovom isporukom od početka do kraja. DevOps eliminiše zabunu odgovornosti i vodi sve koji su uključeni u kreiranje automatizovane infrastrukture koju vode programeri.”
3. DevOps se odnosi na saradnju u kreiranju i isporuci aplikacija.
“Jednostavno rečeno, DevOps je pristup proizvodnji i isporuci softvera gdje svi rade zajedno,” kaže Gur Staf, predsjednik i šef digitalne automatizacije poslovanja u BMC-u.
4. DevOps je cjevovod
“Sastavljanje transportera je moguće samo ako se svi dijelovi uklapaju zajedno.”
„Uporedio bih DevOps sa linijom za sklapanje automobila“, nastavlja Gur Staff. – Ideja je da se svi delovi dizajniraju i izrade unapred kako bi se potom mogli sastaviti bez individualnog prilagođavanja. Montaža transportera je moguća samo ako se svi dijelovi uklapaju. Oni koji dizajniraju i grade motor moraju razmotriti kako ga montirati na karoseriju ili okvir. Oni koji prave kočnice moraju misliti na točkove i tako dalje. Isto bi trebalo biti i sa softverom.
Programer koji kreira poslovnu logiku ili korisničko sučelje mora razmišljati o bazi podataka u kojoj se pohranjuju podaci 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 i višemilionskoj korisničkoj publici. ."
„Natjerati ljude da sarađuju i razmišljaju o dijelovima posla koje drugi rade, umjesto da se fokusiraju samo na svoje zadatke, najveća je prepreka koju treba savladati. Ako to možete učiniti, imate odlične š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 njenim riječima, „DevOps je poput recepta sa tri glavne kategorije sastojaka: ljudi, proces i automatizacija. Većina ovih sastojaka može se preuzeti iz drugih područja i izvora: Lean, Agile, SRE, CI/CD, ITIL, liderstvo, kultura, alati. Tajna DevOps-a, kao i svakog dobrog recepta, je kako dobiti prave proporcije i mješavinu ovih sastojaka kako biste povećali brzinu i efikasnost kreiranja i objavljivanja aplikacija.”
6. DevOps je kada programeri rade kao tim Formule 1
“Utrka nije planirana od početka do kraja, već naprotiv, od cilja do starta.”
“Kada govorim o tome što očekivati od DevOps inicijative, mislim na trkački tim NASCAR ili Formule 1 kao primjer,” kaže Chris Short, viši menadžer marketinga platformi u oblaku u Red Hatu i izdavač DevOps-ovog biltena. – Vođa takvog tima ima jedan cilj: zauzeti najviše moguće mjesto na kraju trke, uzimajući u obzir resurse koji su timu na raspolaganju i izazove koji su ga zadesili. U ovom slučaju, utrka se ne planira od početka do kraja, već naprotiv, od cilja do starta. Prvo se postavlja ambiciozan cilj, a zatim se određuju načini za njegovo postizanje. Zatim se dijele na podzadatke i delegiraju članovima tima.”
“Tim provede cijelu sedmicu prije trke usavršavajući pit stop. Radi treninge snage i kardio da bi ostao u formi za naporan dan trke. Vježbe radeći zajedno na rješavanju problema koji se mogu pojaviti tokom utrke. Isto tako, razvojni tim bi trebao trenirati vještinu čestog objavljivanja novih verzija. Ako imate takve vještine i dobro funkcionirajući sigurnosni sistem, puštanje novih verzija u proizvodnju također se događa češće. U ovom svjetonazoru, povećana brzina znači veću sigurnost”, kaže Short.
„Ne radi se o tome da uradite ’pravu stvar’“, dodaje Short, „nego je da se eliminiše što više stvari koje stoje na putu do željenog ishoda. Sarađujte i prilagođavajte se na osnovu povratnih informacija koje dobijate u realnom vremenu. Budite spremni na anomalije i radite na poboljšanju kvalitete kako biste smanjili njihov utjecaj na napredak ka 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 savladati barijere na putu od prve do druge.
Za mnoge organizacije, putovanje do DevOps-a počinje lako i ugodno. Stvaraju se mali strastveni timovi, stari procesi se zamjenjuju novima, a prvi uspjesi ne čekaju dugo.
Nažalost, ovo je samo lažni sjaj, iluzija napretka, kaže Ben Grinnell, izvršni direktor i voditelj digitalnog sektora u konsultantskoj kući North Highland. Rane pobjede su svakako ohrabrujuće, ali ne pomažu u postizanju krajnjeg cilja širokog usvajanja DevOps-a u cijeloj organizaciji.
Lako je uočiti da je rezultat kultura podjele između “nas” i “njih”.
„Organizacije često pokreću ove pionirske projekte misleći da će utrti put za mainstream DevOps, ne razmišljajući o tome hoće li drugi moći ili će htjeti slijediti taj put“, objašnjava Ben Grinnell. – Timovi za realizaciju ovakvih projekata obično se regrutuju od samouverenih „Varaga“ koji su već uradili nešto slično na drugim mestima, ali su novi u vašoj organizaciji. Istovremeno, oni se ohrabruju da krše i unište pravila koja ostaju obavezujuća za sve ostale. Lako je uočiti da je rezultat kultura “nas” i “njih” koja koči prijenos znanja i vještina.”
“A ovaj kulturni problem je samo jedan od razloga zašto je DevOps teško razmjeriti. DevOps timovi se suočavaju sa povećanim tehničkim izazovima koji su tipični za brzorastuće IT kompanije“, rekao je Steve Newman, osnivač i predsednik Scalyra.
“U savremenom svijetu usluge se mijenjaju čim se za to ukaže potreba. Sjajno je stalno implementirati i implementirati nove funkcije, ali koordiniranje ovog procesa i eliminisanje problema koji se pojavljuju je prava glavobolja, dodaje Steve Newman. – U vrlo brzorastućim organizacijama, inženjeri u timovima koji rade na različitim funkcijama bore se da održe vidljivost promjena i kaskadnih efekata na nivou zavisnosti koje ona stvara. Štaviše, inženjeri nisu sretni kada su lišeni ove mogućnosti i, kao rezultat toga, postaje im teže razumjeti suštinu problema koji se pojavljuju.”
Kako prevazići ove gore opisane izazove i preći na masovno usvajanje DevOps-a u velikoj organizaciji? Stručnjaci pozivaju na strpljenje, čak i ako je vaš krajnji cilj ubrzati ciklus razvoja softvera i poslovne procese.
1. Zapamtite da promjena kulture zahtijeva vrijeme.
Jayne Groll, izvršni direktor, DevOps institut: „Po mom mišljenju, proširenje DevOps-a treba da bude inkrementalno i iterativno kao i agilni razvoj (i da se podjednako dotiče kulture). Agile i DevOps naglašavaju male timove. Ali kako ti timovi rastu u broju i integraciji, na kraju imamo sve više ljudi koji usvajaju nove načine rada, a kao rezultat dolazi do ogromne kulturne transformacije.”
2. Provedite dovoljno vremena planirajući i birajući platformu
Eran Kinsbruner, vodeći tehnički evanđelista u kompaniji Perfecto: „Da bi skaliranje funkcioniralo, DevOps timovi prvo moraju naučiti kombinirati tradicionalne procese, alate i vještine, a zatim polako njegovati i stabilizirati svaku pojedinačnu fazu DevOps-a. Sve počinje pažljivim planiranjem korisničkih priča i tokova vrijednosti, nakon čega slijedi pisanje softvera i kontrole verzija koristeći razvoj zasnovan na trunkovima ili druge pristupe koji su najprikladniji za grananje i spajanje koda.”
“Onda 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 njihovom nivou 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 kontejnera. Važno je imati virtuelizirana 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 za obradu velikih podataka s brzim i djelotvornim povratnim informacijama.”
3. Skinite krivicu iz odgovornosti.
Gordon Haff, RedHat Evangelist: „Kreiranje sistema i atmosfere koji dozvoljavaju i podstiču eksperimentisanje omogućava ono što je poznato kao uspešni neuspesi u agilnom razvoju softvera. To ne znači da niko drugi nije odgovoran za neuspjehe. U stvari, identifikovanje ko je odgovoran postaje još lakše, jer „biti odgovoran“ više ne znači „prouzrokovati nesreću“. Odnosno, suština odgovornosti se kvalitativno mijenja. Četiri faktora postaju kritična: obim poremećaja, pristupi, proizvodni procesi i poticaji.” (Više o ovim faktorima možete pročitati u članku Gordona Huffa “DevOps lekcije: 4 aspekta zdravih eksperimenata.”)
4. Očistite put naprijed
Ben Grinnell, generalni direktor i šef digitalnog sektora u konsultantskoj kući North Highland: „Da bi se postigao obim, preporučujem pokretanje programa „čišćenja puta“ zajedno sa 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 ostaje jasan.”
„Dajte ljudima organizacionu podršku i zamah kroz komunikaciju koja nadilazi pionirsku grupu tako što ćete naširoko slaviti uspjehe novih načina rada. Obučite ljude koji su uključeni u sljedeći val DevOps projekata i koji su nervozni zbog prvog korištenja DevOps-a. I zapamtite da se ovi ljudi veoma razlikuju od pionira.”
5. Demokratizirajte alate
Steve Newman, osnivač i predsjednik Scalyra: „Alati ne bi trebali biti skriveni od ljudi i trebali bi biti relativno laki za učenje za svakoga ko želi da uloži vrijeme. Ako je mogućnost upita dnevnika ograničena na tri osobe "certificirane" za korištenje alata, uvijek ćete imati najviše tri osobe na raspolaganju za rješavanje problema, čak i ako imate vrlo veliko računarsko okruženje. Drugim riječima, ovdje postoji usko grlo koje može dovesti do ozbiljnih (poslovnih) posljedica.”
6. Stvoriti idealne uslove za timski rad
Tom Clark, šef Zajedničke platforme na ITV-u: „Možete sve, ali ne sve odjednom. Zato postavite velike ciljeve, počnite s malim i idite naprijed u brzim iteracijama. Vremenom ćete razviti reputaciju za obavljanje stvari, tako da će i drugi htjeti koristiti vaše metode. I ne brinite o izgradnji veoma efikasnog tima. Umjesto toga, obezbijedite ljudima idealne uslove za rad i efikasnost ć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 Konvejevog zakona. U mojoj slobodnoj parafrazi, ovaj zakon kaže da proizvodi koje stvaramo i procesi koje koristimo za to, uključujući DevOps, ispada da su strukturirani na isti način kao i naša organizacija.”
“Ako postoji mnogo silosa u organizaciji, a kontrola mijenja ruke mnogo puta prilikom planiranja, izgradnje i izdavanja softvera, efekat skaliranja će biti nula ili će biti kratkotrajan. Ako organizacija gradi 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 prikazivanje svih radova u toku (WIP, workinprogress) na Kanban pločama. Kada organizacija ima mjesto gdje ljudi mogu vidjeti ove stvari, to uvelike potiče saradnju, što ima pozitivan utjecaj na skaliranje.”
8. Potražite stare ožiljke
Manuel Pais, DevOps konsultant i koautor Team Topologies: „Preuzimanje DevOps praksi izvan samih Dev-a i Ops-a i pokušaj da ih se primeni na druge funkcije teško da je optimalan pristup. Ovo će sigurno imati nekog utjecaja (na primjer, automatizacijom 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 sistemu 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 neefikasnih 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. I nema ništa gore kada organizacija odjednom ima 20 varijanti DevOps-a koji se ne slažu baš najbolje zajedno. Nemoguće je da svaki od tri razvojna tima ima svoj, poseban interfejs između razvoja i upravljanja proizvodom. Niti proizvodi ne bi trebali imati svoja jedinstvena očekivanja za rukovanje povratnim informacijama kada se prebace na simulator proizvodnje. U suprotnom, nikada nećete moći skalirati DevOps.”
10. Propovijedajte poslovnu vrijednost DevOps-a
Steve Newman, osnivač i predsjednik Scalyra: “Radite na prepoznavanju vrijednosti DevOps-a. Naučite i slobodno pričajte o prednostima onoga što radite. DevOps je nevjerovatna 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 pristalica i povećati utjecaj DevOps-a u organizaciji.”
BONUS
U Naš vlastiti DevOps stiže 13. septembra - da, Red Hat, kao proizvođač softvera, ima svoje 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 punopravni format kontejnera na platforma OpenShift.
Ali to nije sve:
Jednom kada organizacije prebace radna opterećenja u kontejnere, tradicionalne metode praćenja aplikacija možda neće raditi. U drugom govoru ćemo objasniti našu motivaciju za promjenu načina na koji vodimo evidenciju i pokazati nastavak puta koji nas je doveo do modernih metoda evidentiranja i praćenja.
izvor: www.habr.com