DevOps nije titula niti rola – već način razmišljanja i delovanja

Razvoj i isporuka softvera je često dugačak, kompleksan i rizičan proces. Defekti i integracioni problemi se dešavaju u poslednjem momentu i prouzrokuju nezadovoljstvo razvojnih timova, klijenata i krajnjih korisnika.

Nedostatak saradnje između različitih timova često rezultuje implementacijom pogrešnih funkcionalnosti, integracionim greškama i međusobnim optužbama između timova. DevOps prakse su rezultat sistematičnih i kontinualnih poboljšanja procesa razvoja softvera i širokog spektra promena u kulturi i ponašanju koje se tiču kako samog načina rada, tako i načina tehničkih unapređenja procesa isporuke softvera.

U nastavku objašnjavamo zašto DevOps nije titula niti rola, nego način razmišljanja i delovanja i kako primeniti ovu praksu da donese najbolje moguće rezultate.

Bio jednom jedan vodopad…

U tradicionalnoj organizaciji procesa razvoja softvera, tok posla teče od poslovne ideje iz poslovnog ili marketing dela organizacije, ka odeljenjima za dizajn i menadžment proizvoda, koji razvijaju poslovnu ideju u niz poslovnih zahteva i specifikacija.

Ovi poslovni zahtevi se zatim predaju timovima za razvoj softvera koji ih prevode u softverski kod koji se sklapa u aplikaciju. Takva aplikacija se zatim proverava od strane odeljenja za kontrolu kvaliteta, koji je testiraju bazirano na njihovoj interpretaciji originalnih produktnih zahteva. Tim za IT Operacije priprema odgovarajuća okruženja i postavlja aplikacije. Na samom kraju, često veoma kasno, posao se testira sa strane sigurnosti od strane Infosec tima.

U tom procesu, timovi su često delovi različitih organizacionih celina, ponekad iz različitih kompanija, što značajno otežava samu isporuku. Razvojni (development) i timovi IT operacija (ITOps) imaju različite ciljeve.

Razvojni tim teži da što pre objavi nove funkcionalnosti i time unese promene u sistem, dok IT operacije žele da očuvaju stabilnost i samim time minimiziraju promene kao mogući uzrok nestabilnosti. Sam proces ima najmanje pet momenata predaje posla i informacija između timova, gde se gubi na pouzdanosti i kvalitetu.

Na kraju, ovi konflikti dovode do umanjenog kvaliteta softvera, usluge i nezadovoljavajućeg iskustva klijenata. Na taj način gubi se pažnja sa nečeg što bi trebalo da bude zajednički cilj svih, a to je brza, pouzdana i neprekidna isporuka softvera klijentima, što je Agile Manifesto princip #1.

“Kada su ljudi godinama zarobljeni u ovoj silaznoj spirali, posebno oni koji su nizvodno od razvoja, oni se često osećaju zaglavljenim u sistemu koji predodređuje neuspeh i ostavlja ih nemoćnim da menjaju ishode. Ovu nemoć često prati izgaranje, sa tim povezan osećaj umora, cinizma, pa čak i beznađa i očaja.” Gene Kim, Kevin Behr, George Spafford The Phoenix Project

DevOps prakse pokazuju pravi put napred

Uspešne IT organizacije koje primenjuju DevOps prakse, u odnosu na njihovu konkurenciju, razvijaju kod 30 puta brže, sa 60% više uspeha (manje grešaka), pri čemu je vreme realizacije promena (lead time) 200 puta brže, a 168 puta brže vreme oporavka posle incidenata (Mean Time To Restore). Ovakve kompanije imaju više stope rasta, ali takođe i više nivoe zadovoljstva zaposlenih. One konzistentno uspevaju da pruže stabilnu, pouzdanu i sigurnu uslugu svojim klijentima.

DevOps pristup omogućava organizacijama da kreiraju stabilan način rada, gde mali timovi efikasno i nezavisno razvijaju, testiraju i isporučuju kod, a samim tim dodaju vrednost svojim klijentima, brzo, sigurno i pouzdano. DevOps maksimizuje produktivnost, institucionalizuje učenje i razmenu znanja i iskustava unutar organizacije, kreirajući visok nivo poverenja i kulturu saradnje baziranu na visokom zadovoljstvu zaposlenih.

DevOps prakse se dopunjuju sa Lean i Agilnim praksama razvoja softvera i možemo ih podeliti u tri oblasti:

• Osiguravanje nesmetanog i brzog toka (Flow) posla od dizajna i razvoja proizvoda do operacija i na kraju prema naručiocu;
• Omogućavanje brzih povratnih sprega (Feedback) od operacija do razvoja, radi lakšeg otkrivanja, oporavka i, na kraju, sprečavanja ponovnog pojavljivanja problema;
• Stvaranje kulture visokog poverenja i kontinuiranog unapređenja (Continuous Improvement) koja omogućava inicijativu i eksperimentisanje i ugrađuje kulturu organizacionog učenja.

Šta su to Flow, Feedback, Continuous Learning and Improvement?

Cilj praksi Toka (Flow) je da se osigura nesmetan protok posla od dizajna proizvoda, preko razvoja do operacija. Pošto softverski kod ima svoju vrednost tek kada ga klijenti koriste na produkciji, cilj je povećati protok i smanjiti vreme realizacije od poslovne ideje do gotovog softvera isporučenog na produkciju.

U formi Kanban ili Scrum tabli vizualizujemo posao: product backlog items, defekte, produkcione incidente i sve ostalo. Onda organizujemo tok i promovišemo sistem rada baziran na prioritizaciji i odabiru posla od strane samih timova, po pull sistemu. Ovakva vizualizacija nam omogućava da radimo analizu tokova i daje nam početnu tačku za identifikaciju uskih grla, a samim tim i za unapređenja. Sama unapređenja uvek treba bazirati na uskim grlima, pošto će samo te akcije dovesti do stvarnih unapređenja, po teoriji ograničenja (theory of constraints).

Produktivan tok najčešće remete različiti oblici gubitaka (waste) koji mogu biti: defekti, delimično završen posao, čekanje, premeštanje, prebacivanje između zadataka, dodatni procesi koji ne dodaju vrednost, dodatne funkcionalnosti koje ne dodaju vrednost, nestandardan ili manuelan posao i heroizam. Pristup kontinualnog unapređenja ima za cilj da načini teškoće i gubitke vidljivima i da omogući njihovu eliminaciju.

Ove tehnike mogu da pomognu da se smanje gubici i unapredi tok:

• Smanjiti broj primopredaja (handover) pre svega posla i informacija između timova. Integrisali smo produktni dizajn, razvoj, testing i IT operacije, ne samo ljude, nego i aktivnosti, koje su planirane i izvršavane ili zajednički ili u paraleli.
• Kontinualna isporuka (Continuous Delivery) automatizacija testiranja i celokupne isporuke značajno pomaže da se smanji broj manuelnih grešaka i ubrza vreme isporuke.
• Smanjiti veličine isporuke, uz smanjenje intervala isporuke omogućava kvalitetniji fokus na manji broj funkcionalnosti, manje integracionih problema i manje defekata (videti pojam Single Piece Flow).
• Ograničiti posao u toku (Work in Progress) omogućava smanjenje gubitaka koji značajno degradiraju tok i lakšu identifikaciju problema koji sprečavaju da se pojedini zadaci završe.
• Kontinualna identifikacija i unapređenje ograničenja i eliminacija gubitaka, kao što su nejasni zahtevi, prekidi u podizanju okruženja, izvršavanje testova i neadekvatna arhitektura softvera.

Prakse povratnih sprega (Feedback) omogućavaju brze, konstantne i kontinualne povratne informacije, sa ciljem kreiranja pouzdanijeg, sigurnijeg i otpornijeg sistema. Naša kontinualna briga treba da bude da otkrijemo probleme rano, dok su još uvek dovoljno mali i laki za rešavanje i pre nego što prouzrokuju značajniju štetu.

Takođe, treba da obezbedimo da saznanja koja smo stekli u tom procesu ugradimo u budući rad. To možemo da postignemo samo ako kreiramo povratne sprege koje će nam omogućiti da vidimo probleme čim se dese. Greške i problemi koje one prouzrokuju su neizbežni, tako da je naš zadatak da kreiramo sigurno radno okruženje koje će omogućiti rad bez straha, a sa pouzdanjem da će greške biti otkrivene rano, mnogo pre nego što prouzrokuju ozbiljne posledice.

Ovakav pristup povećava osećaj sigurnosti i zadovoljstva svih članova tima, te otvara prostor i vreme za nove, kreativne ideje, a sledeće tehnike omogućavaju efikasnu povratnu spregu:

• Rešiti problem čim se pojavi. Tim ostavlja sve ostale zadatke dok se ne reši problem koji remeti tok.
• Timska odgovornost. Razvojni tim je odgovoran za aplikaciju tokom celog njenog životnog ciklusa, što uključuje i održavanje. Ništa nije u većoj meri motivišuće za razvojni tim da napravi kvalitetnu aplikaciju od saznanja da mogu biti probuđeni u bilo koje doba noći ako nešto ne radi kako treba.
• Automatska provera kvaliteta koda, peer-review i koordinacija izmena.
• Kreirati centralni sistem monitoringa i telemetrije. Monitoringom prikupljamo telemetriju koja nam omogućava da rano otkrivamo i lakše rešavamo probleme.
• Kontinualna analiza, dodavanje i unapređenje telemetrije. Sama telemetrija, uključujući i logove treba da je direktno dostupna timovima koji su odgovorni za sistem. Njihova je odgovornost da se telemetrija kontinualno dopunjava i prilagođava sistemu.
• Eksperimentisanje omogućuje donošenje pouzdanih poslovnih odluka baziranih na podacima koje proizilaze iz telemetrije. Kontinualna isporuka (Continuous Delivery) i sistem za telemetriju nam omogućavaju da verifikujemo poslovne ideje brže i da ulažemo napor u one koje će doneti najveću vrednost (na primer A/B testing).

DevOps prakse kontinualnog učenja i unapređenja (Continuous Learning and Improvement) kreiraju kulturu učenja i eksperimentisanja. Ova kultura obuhvata kreiranje individualnog znanja i iskustva i njegovo ugrađivanje u organizaciju sa glavnim ciljem unapređenja proizvoda i usluga.

Da bi ovo uopšte bilo moguće, neophodna je snažna kultura poverenja, bez mesta za krivicu ili strah. Takva kultura vodi do osećaja psihološke sigurnosti da kada se greške dese, a sigurno će se desiti, one neće biti velike, a sigurno će biti rano otkrivene i lako rešene. Takva kultura vodi i do pozitivnog radnog okruženja koje rezultuje u softverskim proizvodima visokog kvaliteta i visokom nivou zadovoljstva zaposlenih.

Ove metode su se pokazale dobrim za kontinualno učenje i unapređenje:

• Omogućiti organizaciono učenje kroz uspostavljanje kulture poverenja bez straha i krivljenja. Organizovanjem post-mortem sesija za analizu i otklanjanje problema, kako trenutnog, tako i sličnog u budućnosti, dolazimo do uzroka i sprečavamo slične situacije u budućnosti.
• Institucionalizovati kulturu svakodnevnog unapređenja rada, koja obuhvata rešavanje problema na strukturalan način, bez prečica i osigurava kontinualni fokus na to da se nivo tehničkog duga u sistemu adresira na adekvatan način. “U odsustvu unapređenja, procesi ne ostaju na istom nivou, nego usled entropije degradiraju tokom vremena”. The Phoenix Project

Naše iskustvo pokazuje da je DevOps pristup razvoju softvera moderan i sveobuhvatan način rada koji dovodi do toga da softverski proizvodi budu visokog kvaliteta, a da su zadovoljni i klijenti i korisnici. Ove prakse zahtevaju izmene u tehnološkom pristupu, kroz modernizaciju, automatizaciju i inovaciju.

Možda i bitnije, ovaj pristup zahteva promene u kulturi i ponašanju učesnika u razvoju softvera, pre svega u preuzimanju odgovornosti za proizvod i uslugu i unapređenje samog načina rada. Zato je to način razmišljanja i delovanja.