Tema DevOps postala je vrlo popularna posljednjih nekoliko godina. Mnogi žele postati dio toga, ali praksa pokazuje da se često ulazi samo zbog razine plaća.
Neki navode DevOps u svojim životopisima, iako ne razumiju uvijek suštinu pojma. Netko misli da će, ako prouči Ansible, GitLab, Jenkins, Terraform i slične alate (popis se može nastaviti prema vlastitom ukusu), odmah postati „devops”. Naravno, to nije točno.
Posljednjih nekoliko godina uglavnom se bavim implementacijom DevOps-a u raznim kompanijama. Prije toga sam radio više od 20 godina na pozicijama od sistemskog administratora do IT direktora. Trenutno sam DevOps Lead Engineer u Playgendary.
Tko je DevOps
Ideja za pisanje ovog članka pojavila se nakon još jednog pitanja: „tko je DevOps?”. Još uvijek ne postoji ustaljeni pojam što ili tko to zapravo jest. Djelomični odgovori već su navedeni u ovom . Prvo ću istaknuti glavne teze iz njega, a zatim podijeliti svoja zapažanja i misli.
DevOps nije stručnjak kojeg možete zaposliti, nije skup alata, niti odjel programera s inženjerima.
DevOps je filozofija i metodologija.
Drugim riječima, to je skup praksi koje pomažu u aktivnoj interakciji između programera i sistemskih administratora. To znači povezivanje i integriranje radnih procesa.
S pojavom DevOps-a struktura i uloge stručnjaka ostale su iste (ima programera, ima inženjera), ali su se promijenila pravila interakcije. Granice između odjela postale su nejasne.
Ciljeve DevOps-a možemo opisati s tri stavke:
- Softver se mora redovito ažurirati.
- Softver se mora razvijati brzo.
- Softver se mora lako i brzo implementirati.
DevOps nema jedinstveni alat. Konfigurirati, instalirati i proučiti nekoliko proizvoda ne znači da je DevOps stigao u kompaniju. Alata ima mnogo i svi se koriste u različitim fazama, ali služe jednoj zajedničkoj svrsi.
I to je samo dio alata DevOps-a.
Već više od 2 godine razgovaram s ljudima za poziciju DevOps inženjera i došao sam do spoznaje koliko je važno jasno razumjeti suštinu pojma. Akumulirano je specifično iskustvo, zapažanja i misli koje želim podijeliti.
Iz iskustva razgovora vidim sliku: stručnjaci koji smatraju da je DevOps pozicija obično imaju nesporazume s kolegama..
Bio je to jasan primjer. Na razgovor za posao došao je mladić s hrpom pametnih riječi u životopisu. Na posljednja tri radna mjesta imao je staž od 5-6 mjeseci. Iz dva startupa je otišao jer „nisu uspjeli“. A o trećoj tvrtki je rekao da ga tamo nitko ne razumije: developeri pišu kod za Windows, a direktor ga tjera da taj kod „zapakira“ u obični Docker i ugradi u CI/CD pipeline. Momak je puno negativnog pričao o svom trenutnom radnom mjestu i kolegama — jednostavno sam htio odgovoriti: „Pa ti ne možeš prodati slona“.
Potom sam mu postavio pitanje koje je jedno od prvih na mom popisu za svakog kandidata.
— Što za tebe osobno znači DevOps?
— Općenito ili kako to ja doživljavam?
Zanimao me je njegov osobni stav. Znao je teoriju i porijeklo pojma, ali se s njima strogo nije slagao. Smatrao je da je DevOps — pozicija. Tu leži korijen njegovih problema. Kao i kod drugih stručnjaka s istim mišljenjem.
Poslodavci, našačući o „magi DevOpsa“, žele pronaći osobu koja će doći i stvoriti tu „magiju“. A kandidati iz sfere „DevOps je pozicija“ ne razumiju da, s takvim pristupom, neće moći opravdati očekivanja. I, uopće, napisali su u svom životopisu DevOps, jer je to trend i zato se dobro plaća.
Metodologija i filozofija DevOps
Metodologija može biti teorijska i praktična. U našem slučaju — ovo drugo. Kao što sam prethodno spomenuo, DevOps je skup praksi i strategija koje se primjenjuju za postizanje postavljenih ciljeva. U svakom slučaju, ovisno o poslovnim procesima tvrtke, može se značajno razlikovati. Što ne čini ni bolje ni gore.
Metodologija DevOps samo je sredstvo za postizanje postavljenih ciljeva.
Sada o tome što je filozofija DevOps. I to je, vjerojatno, najteže pitanje.
Teško je formulirati kratak i jasan odgovor jer još nije formaliziran. I budući da se sljedbenici filozofije DevOps više bave praksom — nemaju vremena za filozofiranje. Ipak, to je vrlo važan proces. A izravno se odnosi na inženjersku djelatnost. Postoji čak i specijalizirano područje spoznaje — .
Na mom sveučilištu nije bilo takvog predmeta, pa sam sve morao učiti samostalno koristeći materijale koje sam uspio pronaći devedesetih. Tema nije obavezna za inženjsku naobrazbu, stoga ni odgovor nije formalan. Međutim, oni koji su se ozbiljno posvetili DevOps-u počinju osjećati određeni "duh" ili "nepreglednu sveobuhvatnost" svih procesa u kompaniji.
Na svom sam iskustvu pokušao formalizirati neke "postulate" ove filozofije. Evo što je ispalo:
- DevOps nije nešto samostalno što se može izdvojiti kao posebna grana znanja ili djelovanja.
- DevOps metodologijom trebaju se voditi svi zaposlenici kompanije prilikom planiranja svog djelovanja.
- DevOps obuhvaća sve procese unutar kompanije.
- DevOps postoji kako bi smanjio vremenske troškove svih procesa unutar kompanije kako bi osigurao razvoj njenih usluga i maksimalnu udobnost klijenta.
- DevOps, modernim rječnikom, predstavlja proaktivnu poziciju svakog zaposlenika kompanije koja je usmjerena na smanjenje vremenskih gubitaka i poboljšanje kvalitete IT proizvoda koji nas okružuju.
Mislim da su moji "postulati" posebna tema za raspravu. No, sada se imamo od čega odmaknuti.
Što radi DevOps
Ključna riječ ovdje je - komunikacije. Puno je komunikacija, inicijator kojih bi trebao biti upravo taj DevOps inženjer. Zašto? Zato što je to filozofija i metodologija, a tek potom inženjersko znanje.
O zapadnom tržištu rada ne mogu govoriti s 100% sigurnošću. No, o tržištu DevOps-a u Rusiji znam dosta. Osim stotina intervjua, u posljednjih godinu i pol sudjelovao sam u stotini tehničkih presaleova usluge "Implementacija DevOps-a" za velike ruske tvrtke i banke.
U Rusiji je DevOps još uvijek jako mlada, ali već trendovska tema. Koliko znam, samo u Moskvi je manjak takvih stručnjaka u 2019. godini iznosio više od 1000 osoba. A reč Kubernetes za poslodavce je gotovo kao crvena krpa za bika. Obdržavatelji ovog alata spremni su ga koristiti čak i tamo gdje to nije potrebno i ekonomski isplativo. Poslodavac ne razumije uvijek u kojim je slučajevima bolje što koristiti, a pri pravilnom rasporedu sadržaj klastera Kubernetes košta 2-3 puta više od rasporeda aplikacije prema običnoj klasterskoj shemi. Koristite ga tamo gdje je stvarno potreban.
Uvođenje DevOps-a s financijskog stajališta — skupo je. I opravdano je samo tamo gdje donosi ekonomsku korist u drugim područjima, a ne samo po sebi.
DevOps inženjeri su, zapravo, pioniri — upravo oni prvi trebaju uvesti ovu metodologiju u kompaniji i uspostaviti procese. Da bi to bilo uspješno, stručnjak mora stalno surađivati s zaposlenicima i kolegama na svim razinama. Kako obično kažem, u proces uvođenja DevOps-a trebaju biti uključeni svi zaposlenici kompanije: od čistačice do CEO-a. I to je obavezan uvjet. Ako najmlađi član tima ne zna i ne razumije što je DevOps i zašto se provode određene organizacijske radnje, uspješan uvođenje neće biti moguće.
Također, DevOps inženjer ponekad treba koristiti administrativne resurse. Na primjer, za prevladavanje "otpornosti okruženja" — kada tim nije spreman prihvatiti alate i metodologiju DevOps-a.
Programer treba pisati samo kod i testove. Za to mu nije potreban supermoćni laptop na kojem će razvijati i održavati lokalno cijelu infrastrukturu projekta. Na primjer, frontend inženjer drži na svom laptopu sve elemente aplikacije, uključujući bazu podataka, emulator S3 (minio) i drugo. To znači da troši mnogo vremena na održavanje te lokalne infrastrukture i sam se bori sa svim problemima takvog rješenja. Umjesto da razvija kod za frontend. Takve osobe mogu se snažno opirati bilo kakvim promjenama.
No postoje timovi koji, naprotiv, rado prihvaćaju uvođenje novih alata i metoda te aktivno sudjeluju u tom procesu. Ipak, čak i u takvom slučaju, komunikacija između DevOps inženjera i tima ostaje nužna.
Kada DevOps nije potreban
Postoje situacije kada DevOps nije potreban. To je činjenica koju treba razumjeti i prihvatiti.
Prije svega, to se odnosi na sve tvrtke (posebno mala poduzeća) čiji profit ne ovisi izravno o postojanju ili nepostojanju IT proizvoda koji pružaju informacijske usluge klijentima. Ovdje se ne radi o internetskoj stranici tvrtke, bila ona statična "vizitka" ili s dinamičkim novostima i sl.
DevOps je potreban kada uspjeh tih informativnih usluga koje omogućuju interakciju s klijentima, njihova kvaliteta i ciljanost utječu na zadovoljstvo vaših klijenata i njihovu želju da se ponovno vrate upravo vama.
Primjer je jedna poznata banka. Tvrtka nema klasične poslovnice, dokumentacija se razmjenjuje putem pošte ili kurira, a mnogi zaposlenici rade od kuće. Tvrtka više nije samo banka i, po mom mišljenju, postala je IT tvrtka s razvijenim DevOps tehnologijama.
Mnoge druge primjere i predavanja možete pronaći u zapisima tematskih meetupa i konferencija. Dio njih sam osobno posjetio — to je vrlo korisno iskustvo za one koji žele napredovati u tom području. Evo linkova na YouTube kanale s dobrim predavanjima i materijalima o DevOps-u:
Sada pogledajte svoje poslovanje i razmislite o sljedećem: koliko vaša tvrtka i njezin profit ovise o IT proizvodima koji omogućuju interakciju s klijentima?
Ako vaša tvrtka prodaje ribu u maloj trgovini i jedini IT proizvod su dvije konfiguracije 1C: Poduzeće (Računovodstvo i UNF), malo je vjerojatno da ima smisla govoriti o DevOps-u.
Ako pak radite u velikom trgovačkom i proizvodnom poduzeću (npr. proizvodite lovačke puške), trebate se zamisliti. Možete pokazati inicijativu i prenijeti svojoj upravi perspektive uvođenja DevOps-a. Također, možete preuzeti vodeću ulogu u tom procesu. Proaktivna pozicija jedan je od važnih postulata filozofije DevOps.
Veličina i volumen godišnjeg financijskog prometa nisu glavni kriterij za određivanje treba li vašoj tvrtki DevOps.
Zamislimo veliku industrijsku tvrtku koja ne komunicira izravno s klijentima. Na primjer, neke automobilske kompanije i tvornice automobila. Sada nisam siguran, ali iz mog prošlog iskustva, dugi niz godina cijela komunikacija s klijentima odvijala se putem e-pošte i telefona.
Njihovi klijenti su ograničeni popis automobilskih distributera. I za svakog je pridružen specijalist proizvođača. Sav unutarnji dokumentarni proces odvija se putem ERP SAP-a. Unutarnji zaposlenici zapravo su klijenti informacijskog sustava. No upravljanje tim IS-om obavlja se klasičnim sredstvima upravljanja klaster sustavima. To isključuje mogućnost korištenja DevOps praksi.
Iz toga proizlazi da za takve tvrtke implementacija DevOps-a nije nešto kritično važno, ako se prisjetimo ciljeva metodologije na početku članka. Međutim, ne isključujem mogućnost da danas koriste neke alate DevOps-a.
S druge strane, postoji mnogo malih tvrtki koje razvijaju softver koristeći metodologiju, filozofiju, prakse i alate DevOps. I smatraju da su troškovi implementacije DevOps-a troškovi koji im omogućuju učinkovito natjecanje na tržištu softvera. Primjere takvih tvrtki možete vidjeti .
Glavni kriterij za razumijevanje treba li vam DevOps: koliku važnost vaši IT proizvodi imaju za tvrtku i klijente.
Ako je glavni proizvod tvrtke koji donosi profit softver — trebate DevOps. I nije važno ako zarađujete stvarni novac kroz druge proizvode. Ovo također uključuje internetske trgovine ili mobilne aplikacije s igrama.
Svake igre postoje zahvaljujući financiranju: izravnom ili neizravnom od strane igrača. U Playgendary razvijamo besplatne mobilne igre u čijem neposrednom stvaranju sudjeluje više od 200 osoba. Kako koristimo DevOps?
Da, na isti način kao što je opisano iznad. Kontinuirano komuniciram s programerima i testerima, provodim interne obuke zaposlenika o metodologiji i alatima DevOps.
Trenutno aktivno koristimo Jenkins kao alat za CI/CD pipeline za izvođenje svih građevinskih konveja s Unityjem i za kasniji deploy u App Store i Play Market. Također iz klasičnog seta alata:
- Asana — za upravljanje projektima. Postavljena integracija s Jenkins-om.
- Google Meet — za provođenje video sastanaka.
- Slack — za komunikaciju i razna obavještenja, uključujući notifikacije iz Jenkins-a.
- Atlassian Confluence — za dokumentiranje i grupni rad.
U bliskoj budućnosti planiramo uvođenje statičke analize koda pomoću SonarQube-a i provođenje automatiziranog UI testiranja sredstvima Seleniuma u fazi Kontinuirane Integracije.
Umjesto zaključka
Želim završiti sljedećom mišlju: da biste postali visoko kvalificirani DevOps inženjer, od životne je važnosti naučiti aktivno komunicirati s ljudima.
DevOps inženjer je timski igrač. I ništa manje od toga. Inicijativa u komunikaciji s kolegama treba dolaziti od njega samog, a ne pod utjecajem nekih okolnosti. DevOps stručnjak treba vidjeti i ponuditi najbolje rješenje za tim.
I da, implementacija bilo kakvog rješenja zahtijevat će puno rasprava, a na kraju može čak i promijeniti. Samostalno se razvijajući, predlažući i provodeći svoje ideje — takva osoba predstavlja sve veću vrijednost kako za tim, tako i za poslodavca. Što se, na kraju, odražava i na visini njegove mjesečne naknade ili u obliku dodatnih bonusa.
Izvor: habr.com
