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

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

Kako osigurati da operativci i programeri rade kao cjelina? Kojim metodama DevOps može pomoći srušiti nevidljivi zid između ta dva tima te što je najpotrebnije stručnjacima koji bi tu ulogu trebali preuzeti... evo jedne perspektive koja bi vam mogla dati odgovore.

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

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.

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.

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…

Da, neki od ovih alata će vam trebati. Ali nakon ovog pročitanog teksta, ne želim da zapamtite kako je DevOps definiran i što sve spada pod tu terminologiju, želim da vam ostane da je to razmišljanje “out-of-the-box”.

Č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.

Pravila ponašanja

Na Netokraciji za vas stvaramo kvalitetan, autorski potpisan sadržaj i zaista se veselimo vašim kvalitetnim, kontruktivnim komentarima. Poštujmo stoga jedni druge prilikom komentiranja držeći se sljedećih pravila ponašanja:

  • Ne budite 💩: Nema vrijeđanja, diskriminiranja, ni psovanja (osim ako nije osobni izričaj, ali onda neka psovka bude općenita, a ne usmjerena prema nekome)
  • Samo kvalitetna rasprava, manje trolanja: Ne morate se ni sa kim slagati, ali budite konstruktivni i doprinesite raspravi! Svako trolanje, flameanje, koliko god "plesalo" na granici, leti van.
  • Imenom i prezimenom, nismo Anonymous 👤: Autor sadržaja stoji iza svog sadržaja, stoga stojite i vi iza svog komentara. Koristimo ime i prezime (Hrvoje Lončar) ili barem ime i inicijala (Hrvoje L.) te pravu email adresu. Kako koristimo podatke koje tamo ostavljate? Bacite oko na našu izjavu o privatnosti.

Sve ostale komentare ćemo s guštom spaliti, jer ne zaslužuju svoje mjesto na internetu.

Odgovori

Tvoja e-mail adresa neće biti objavljena.

Popularno

Tehnologija

Brate, trebam li stvarno uzeti Šaomi?

Xiaomi je u relativno kratkom vremenu postao brend koji se daleko najviše preporučuje u Hrvatskoj i regiji. Zašto?

Izrada web stranica

Kad vam u 2021. padne server, što očekivati od svog hosting poslužitelja?

Po muci se poznaju junaci pa tako i hosting poslužitelji. Kako izgleda posao s druge strane vašeg weba, otkrili smo.

Startupi i poslovanje

Kad bi umjesto nogometaša, jedan od najpoznatijih nogometnih menadžera vodio – programere…

Pojam voditelja tima u IT zajednici poprilično je širok. Različite tvrtke definiraju poziciju na različite načine te sama pozicija može uključivati različite vještine i odgovornosti. Kako onda opisati tu mističnu poziciju tako da ju opća populacija može lakše razumijeti?

Što ste propustili

Startupi i poslovanje

Od design-driven do data-driven tvrtke, kako je Score Alarm postao Superology

Superology će uskoro napuniti 10 godina, no njihov rebrending odvio se ne samo ususret toj velikoj obljetnici već kao posljedica rasta tvrtke koja je doktorirala razvoj digitalnog proizvoda u svom području.

Startupi i poslovanje

Počele su prijave za novu generaciju startup inkubatora Algebra LAB-a

Naš najdugovječniji inkubator kojeg je prošlo preko 150 startup projekata u potrazi je za svojom 14. generacijom polaznika.

Karijere

Ivan Šimić odlazi iz Netokracije

Pa, da. Kao što naslov kaže, "onaj drugi Ivan iz Netokracije" - od danas nije više u Netokraciji.

Startupi i poslovanje

Ona je Infobipov tehnički pisac, a hobi joj je učenje o hitnoj medicini

Pisanje tehničke dokumentacije uz istraživanje medicine i pandemije uzrokovane koronavirusom možda ne zvuče kao srodne stvari, ali Sara Tilly iz Infobipa ih uspješno spaja već dugo vremena. Kako joj takav pristup učenju pomaže danas u poslu?

Karijere

Klaudija Šarkanj nova je direktorica HR-a u Gideonu

Klaudija u Gideon Brothers dolazi iz Infobipa, a imat će ključnu ulogu u širenju Gideon tima.

Tehnologija

Brate, trebam li stvarno uzeti Šaomi?

Xiaomi je u relativno kratkom vremenu postao brend koji se daleko najviše preporučuje u Hrvatskoj i regiji. Zašto?