Demistificirani DevOps: To je kultura tvrtke, a ne pojedinac superheroj!

Kako bi adekvatnije objasnili pojam DevOps i koje točno probleme DevOps pokušava ukloniti, pokušajmo se vratiti u vrijeme prije DevOpsa i sagledatI način na koji su stvari tada funkcionirale između odjela programera i operative.

Jednom davno… operativci i programeri slabo su se sporazumijevali

Zamislite klasično postavljene odjele programera i operative razdvojene nevidljivim „zidom“. Programeri razviju neki kod kojeg bace preko metaforičkog zida na stranu operativnog odjela, čija je odgovornost nesmetano izvođenje istog. Operativni odjel imao je malo razumijevanja o samom kodu, a programerski odjel zauzvrat imao je limitirano razumijevanje prakse i načina na koji stvari funkcioniraju u odjelu operative.

Svaki je odjel bio za sebe, briga programera bila je vezana uz isporuku koda operativi i želju da se taj kod čim prije implementira, dok je operativa brinula o pouzdanosti koda te je željela da se stvari odrađuju sporije, sve kako bi osigurala tj. održala stabilnost platforme.

Takav pristup stvorio je savršeno plodno tlo za nastanak međuodjelnih tenzija u svim fazama plasiranja novog proizvoda što bi se u konačnici u najgorem slučaju odrazilo na korisničko iskustvo – u vidu kašnjenja ili ispada usluge. Osobno mi se u glavi zapečatila poštapalica koja se stalno ponavljala kod svakog bugfixa: „ovaj bugfix će riješiti 10 bugova, ali će prouzročitI 15 novih“ i nažalost, obično je to bio i slučaj.

Kao rješenje, spasiti dan dolazi Joda u vidu DevOpsa

Njegove načine možemo raščlaniti u nekoliko ključnih metoda:

1. Rušenje međuodjelnog metaforičkog zida i povećanje komunikacije;
2. Prihvaćanje neuspjeha;
3. Manje inkrementalne promjene;
4. Automatizacija procesa;
5. Monitoring.

Rušenje zida i povećanje komunikacije

Odjeli koji su dosad funkcionirali kao odvojeni entiteti, svaki sa svojim ciljevima i pravilima (“razvij novu funkcionalnost” u odnosu na “održavaj sustav stabilnim”) nemaju mjesta u DevOps kulturi gdje je naglasak upravo na zajedničkom timskom radu: od planiranja pa sve do implementacije i plasiranja proizvoda korisnicima.

Na što konkretno mislim pod „rušenje metaforičkog zida“? Mislim na kolaboraciju od samih početaka projekata, gdje i developerska i operativna strana zajedničkim snagama, znajući cilj koji moraju postići, dolaze do najboljeg i najsigurnijeg plana kako će ga ostvariti.

Prihvaćanje neuspjeha

Teško je očekivati da stvari rade savršeno kad uzmemo u obzir koliko računala mogu biti nepouzdana, a kad u cijelu jednadžbu ubacimo ljude, postotak neuspjeha raste. Što nije znak za obeshrabrenje i da odmah bacimo sve kroz prozor, već je na neuspjeh potrebno gledati kao na pozitivnu stvar.

A kada je to neuspjeh pozitivna stvar?

Ne možemo očekivati da će sve ideje i odluke uvijek biti uspješne, naravno da neće, ali kad se nađemo u toj situaciji važno je sagledati problem iz različitih kuteva, istražiti što je dovelo do nje i poduzeti korake, tj. primijeniti upravo naučeno kako bi izbjegli ponavljanje istog problema. Najlakše je tražiti pojedinca/ce na koje će se prebaciti krivnja, što je pogrešno jer samim time ubijamo volju, kreativnost i želju istih za inovativnim rješenjima.

Ovime lagano zadiremo u tzv. „No-blame“ kulturu i jasan pokazatelj u cijeloj industriji, ne samo unutar IT-a: tvrtke koje su prihvatile takvu kulturu prema svojim zaposlenicima u relativno kratkom roku pokazuju veću uspješnost u svojem području naspram tvrtka s tradicionalnim odnosom prema neuspjehu.

View this post on Instagram

A post shared by Mercedes-AMG PETRONAS F1 Team (@mercedesamgf1)

Jako dobar primjer tvrtke koja je prihvatila no-blame kulturu – i trenutno, djelomičnim zaslugama upravo takvog načina pristupa plovi na vrhuncu uspješnosti – je Mercedes-AMG Petronas F1 momčad na čelu s Toto Wolffom, po postocima nedvojbeno najuspješniji tim u povijesti Formule 1. Za sve koje zanima nešto više postoji jedan zanimljiv članak koji povezuje njihovu uspješnost sa, između ostalog, no blame kulturom.

Manje inkrementalne promjene

Zašto manje inkrementalne promjene. Kada promjene ili uvođenje nove funkcionalnosti gradiramo na nekoliko manjih cjelina olakšavamo si pregled, razumijevanje i lakšu kontrolu nad utjecajem koji će ta promjena donijeti u postojeće okruženje.

Ako i dođe do neželjenog ishoda u vidu buga ili ispada sustava – proces uklanjanja istog svest će se na vraćanje prethodne konfiguracije, a samim time smanjujemo negativan utjecaj na korisnika.

Automatizacija procesa

Svakodnevni posao uključuje široku raznolikost operacija koje obavljamo. Bitno je identificirati repetitivne poslove kako bi se lakše i efikasnije fokusirali na razvoj novih proizvoda, funkcionalnosti, poboljšanje efikasnosti postojećih procesa, evaluacije novih alata. Samim time u relativno kratkom roku uočilo bi se smanjenje ljudskih pogrešaka i povećanje produktivnosti.

Postoje razni alati koji nam u ovome mogu pomoći, a koje ćemo sad samo nabrojati: Kubernetes, Docker, Ansible, Terraform, ArgoCD, a više objasniti u eventualnim budućim osvrtima na temu.

Monitoring

Ne mogu dovoljno naglasiti koliko je monitoring bitan.

Sve dosad navedeno lagano pada u vodu ako ne monitoriramo platformu, jer nam upravo monitoring omogućuje osiguranje kvalitete proizvoda, uspješnosti novih funkcionalnosti, prihvaćenost istih od strane tržišta te praćenje ide li razvoj u dobrom smjeru.

Postoje razni alati koji nam omogućavaju instantan uvid u rad same platforme u trenutku kad smo deployali novu funkcionalnost, alati koji će nam definirati točan trenutak i razlog koji je doveo do nestabilnosti/problema u radu platforme – što će nam u konačnici osigurati pravovremenu reakciju na probleme i uklanjanje istih.

DevOps se mora prakticirati na razini čitave tvrtke

Znam nekoliko tvrtka koje imaju zaposlenog jednog čovjeka pod okriljem DevOpsa, što je u potpunosti krivi pristup. DevOps je takozvana kultura, način rada koji mora biti prakticiran od strane tvrtke kao cjeline. Drugim riječima – ne postoji pojedini odjel ili pojedina osoba zaslužna i odgovorna za razvoj i implementaciju funkcionalnosti, već ovisno o tvrtki radi se o cjelini ili grupi ljudi.

Kada gledamo produkt tvrtke, planiranje i razvoj tog produkta, ne smijemo zaboraviti na operativu i produkciju, ponašanje produkta u tom okruženju, nadalje tu je i sigurnosni aspekt i osiguranje kvalitete. Gledamo sve kao cjelinu, dijelimo zaslužnost i odgovornost prema produktu.

Vrlo je lako kod implementacije DevOpsa otići u pogrešnom smjeru i nađemo se, recimo, u situaciji gdje najbitnija stvar i mjerilo uspjeha postane broj završenih zadataka, što naravno iza sebe dovodi dodatne probleme te, na kraju, u pokušaju unaprjeđenja smo napravili više štete.

Daleko najgore što tvrtka može napraviti je implementiranje DevOpsa s jednostavnim ciljem smanjenja OPEX (ili operativnih) troškova. Kod implementacije DevOps metode, važno je jasno postaviti ciljeve, koje probleme tom implementacijom želimo eliminirati te kada se nešto ispostavi pogrešnom odlukom, pravovremeno reagirati i uz kolaboraciju s ljudima kojih će se ta implementacija ticati – doći do adekvatnog rješenja.

Sve što treba DevOpsu je…

Često sam se znao pitati koje su to onda najvrjednije vještine za DevOps, koje sve alate bi trebao poznavati kako bi kao pojedinac biti kompetitivniji na današnjem tržištu, koliko programskih jezika treba znati i slično…

Po nekom osobnom iskustvu unutar IT industrije i činjenici da obožavam istraživati način na koji funkcioniraju tvrtke iz ostalih grana industrije rekao bih da je najvrjednija vještina koju pojedinac može imati fleksibilnost i mogućnost brzog učenja. To između ostalog znači znati gdje primijeniti različite tehnologije, imati fokus na alate koji će riješiti izazove s kojima se tvrtka susreće i pratiti tržište novih tehnologija za potencijalne buduće potrebe. A kao glavnu stavku izdvojio bi zatomljavanje straha od neuspjeha, jer jedino tako će se kreativnost u vama razvijati.

S ovakvim mindsetom, bilo da se radi o studentima pri završetku studija ili ljudima s nizom godina radnog iskustva, samo je nebo granica.

Naposljetku, možemo zaključiti da DevOps nije pojedinac, već kultura, kolektiv inženjerskih umova iz različitih grana IT industrije koji operiraju pod istim kišobranom s ciljem lakšeg, jednostavnijeg razvoja, implementacije i održavanja različitih kompleksnih IT sustava.