DevOps je postao vrlo popularna tema u posljednjih nekoliko godina. Mnogi ljudi sanjaju o tome da joj se pridruže, ali, kako pokazuje praksa, često samo zbog visine plaća.
Neki ljudi navode DevOps u svom životopisu, iako ne znaju ili razumiju uvijek bit pojma. Neki misle da ćete nakon proučavanja Ansiblea, GitLaba, Jenkinsa, Terraforma i sličnih (popis se može nastaviti prema vašem ukusu) odmah postati “devopsist”. To, naravno, nije istina.
Posljednjih nekoliko godina uglavnom sam se bavio implementacijom DevOps-a u raznim tvrtkama. Prije toga radio je više od 20 godina na pozicijama od sistemskog administratora do IT direktora. Trenutno DevOps Lead Engineer u Playgendaryju.
Tko je DevOps
Ideja za pisanjem članka nastala je nakon još jednog pitanja: “tko je DevOps?” Još uvijek nema ustaljenog termina za što ili tko je to. Neki od odgovora su već u ovome . Prvo ću istaknuti glavne točke iz njega, a zatim ću podijeliti svoja zapažanja i razmišljanja.
DevOps nije stručnjak koji se može zaposliti, niti skup uslužnih programa, niti odjel programera s inženjerima.
DevOps je filozofija i metodologija.
Drugim riječima, to je skup praksi koje programerima pomažu u aktivnoj interakciji s administratorima sustava. Odnosno povezati i integrirati radne procese jedne u druge.
Pojavom DevOpsa struktura i uloge stručnjaka ostale su iste (postoje programeri, postoje inženjeri), ali su se promijenila pravila interakcije. Zamaglile su se granice između odjela.
Ciljevi DevOps-a mogu se opisati u tri točke:
- Softver se mora redovito ažurirati.
- Softver se mora napraviti brzo.
- Softver bi se trebao implementirati jednostavno i u kratkom vremenu.
Ne postoji jedinstveni alat za DevOps. Konfiguriranje, isporuka i proučavanje nekoliko proizvoda ne znači da se DevOps pojavio u tvrtki. Postoji mnogo alata i svi se koriste u različitim fazama, ali služe jednoj zajedničkoj svrsi.
A ovo je samo dio DevOps alata
Već više od 2 godine intervjuiram ljude za poziciju DevOps inženjera i shvatio sam koliko je važno jasno razumjeti bit pojma. Sakupio sam konkretna iskustva, zapažanja i razmišljanja koja želim podijeliti.
Iz iskustva s intervjua vidim sljedeću sliku: stručnjaci koji DevOps smatraju nazivom posla obično imaju nesporazume s kolegama.
Bio je jedan upečatljiv primjer. Mladić je došao na razgovor s puno pametnih riječi u životopisu. Na zadnja tri posla imao je 5-6 mjeseci staža. Napustio sam dva startupa jer "nisu zaživjeli". Ali o trećoj tvrtki rekao je da ga tamo nitko ne razumije: programeri pišu kod na Windowsima, a direktor prisiljava da se ovaj kod "zamota" u obični Docker i integrira u CI/CD cjevovod. Tip je rekao puno negativnih stvari o svom trenutnom radnom mjestu i svojim kolegama - samo sam htio odgovoriti: "Dakle, nećete prodati slona."
Tada sam mu postavio pitanje koje je kod svakog kandidata visoko na mojoj listi.
— Što vama osobno znači DevOps?
- Općenito ili kako ja to doživljavam?
Zanimalo me njegovo osobno mišljenje. Znao je teoriju i porijeklo pojma, ali se s njima nije slagao. Vjerovao je da je DevOps naziv posla. Tu leži korijen njegovih problema. Kao i drugi stručnjaci s istim mišljenjem.
Poslodavci, nakon što su čuli puno o “čaroliji DevOpsa”, žele pronaći osobu koja će doći i stvoriti tu “čaroliju”. A kandidati iz kategorije “DevOps je posao” ne shvaćaju da ovakvim pristupom neće moći ispuniti očekivanja. I, općenito, u životopisu su napisali DevOps jer je to trend i skupo ga plaćaju.
DevOps metodologija i filozofija
Metodologija može biti teorijska i praktična. U našem slučaju, to je drugi. Kao što sam već spomenuo, DevOps je skup praksi i strategija koje se koriste za postizanje navedenih ciljeva. I u svakom slučaju, ovisno o poslovnim procesima tvrtke, može se značajno razlikovati. Što ga ne čini boljim ili lošijim.
DevOps metodologija samo je sredstvo za postizanje ciljeva.
Sada o tome što je DevOps filozofija. A ovo je vjerojatno najteže pitanje.
Vrlo je teško formulirati kratak i jezgrovit odgovor, jer on još nije formaliziran. A budući da su pristaše DevOps filozofije više angažirani u praksi, jednostavno nema vremena za filozofiranje. Međutim, ovo je vrlo važan proces. Štoviše, izravno je povezan s inženjerskim aktivnostima. Postoji čak i specijalizirano područje znanja - .
Na mom fakultetu nije postojao takav predmet, morao sam sve učiti sam koristeći materijale koje sam mogao pronaći 90-ih. Tema je izborna za inženjersko obrazovanje, stoga nedostatak formalizacije odgovora. Ali oni ljudi koji su ozbiljno uronjeni u DevOps počinju osjećati određeni "duh" ili "nesvjesnu sveobuhvatnost" svih procesa tvrtke.
Koristeći se vlastitim iskustvom, pokušao sam formalizirati neke od “postulata” ove filozofije. Rezultat je sljedeći:
- DevOps nije nešto neovisno što se može izdvojiti u zasebno područje znanja ili aktivnosti.
- Svi zaposlenici tvrtke trebaju se pri planiranju svojih aktivnosti voditi DevOps metodologijom.
- DevOps utječe na sve procese unutar tvrtke.
- DevOps postoji kako bi smanjio vremenske troškove za sve procese unutar tvrtke kako bi osigurao razvoj svojih usluga i maksimalnu udobnost korisnika.
- DevOps, modernim jezikom rečeno, proaktivna je pozicija svakog zaposlenika tvrtke usmjerena na smanjenje vremenskih troškova i poboljšanje kvalitete IT proizvoda oko nas.
Mislim da su moji “postulati” posebna tema za raspravu. Ali sada se ima na čemu graditi.
Što DevOps radi
Ključna riječ ovdje je komunikacija. Puno je komunikacija čiji bi inicijator trebao biti upravo taj isti DevOps inženjer. Zašto je to? Jer ovo je filozofija i metodologija, a tek onda inženjersko znanje.
Ne mogu sa 100% pouzdanjem govoriti o zapadnom tržištu rada. Ali znam dosta o DevOps tržištu u Rusiji. Uz stotine intervjua, tijekom proteklih godinu i pol dana sudjelovao sam u stotinama tehničkih pretprodaja usluge “Implementacija DevOps” za velike ruske tvrtke i banke.
U Rusiji je DevOps još uvijek vrlo mlada, ali već popularna tema. Koliko ja znam, samo u Moskvi nedostatak takvih stručnjaka u 2019. bio je više od 1000 ljudi. A riječ Kubernetes za poslodavce je gotovo kao crvena krpa za bika. Pristaše ovog alata spremni su ga koristiti čak i tamo gdje to nije potrebno i ekonomski isplativo. Poslodavac ne razumije uvijek u kojim slučajevima je prikladnije koristiti, a uz pravilnu implementaciju, održavanje Kubernetes klastera košta 2-3 puta više od implementacije aplikacije pomoću konvencionalne sheme klastera. Koristite ga tamo gdje vam je stvarno potreban.
Implementacija DevOpsa je skupa u smislu novca. A opravdana je samo tamo gdje donosi ekonomsku korist na drugim područjima, a ne sama za sebe.
DevOps inženjeri su zapravo pioniri – oni su ti koji bi trebali prvi implementirati ovu metodologiju u tvrtku i graditi procese. Da bi to bilo uspješno, specijalist mora stalno komunicirati sa zaposlenicima i kolegama na svim razinama. Kao što obično kažem, svi zaposlenici tvrtke trebaju biti uključeni u proces implementacije DevOps-a: od čistačice do direktora. A ovo je preduvjet. Ako najmlađi član tima ne zna i ne razumije što je DevOps i zašto se provode određene organizacijske radnje, tada uspješna implementacija neće uspjeti.
Također, DevOps inženjer s vremena na vrijeme mora koristiti administrativni resurs. Na primjer, za prevladavanje "otpora okoline" - kada tim nije spreman prihvatiti DevOps alate i metodologiju.
Programer bi trebao pisati samo kod i testove. Za to mu ne treba super-moćno prijenosno računalo na kojem će implementirati i lokalno podržavati cjelokupnu infrastrukturu projekta. Na primjer, front-end programer drži sve elemente aplikacije na svom prijenosnom računalu, uključujući bazu podataka, S3 emulator (minio) itd. Odnosno, on provodi puno vremena održavajući tu lokalnu infrastrukturu i sam se bori sa svim problemima takvog rješenja. Umjesto razvoja koda za front. Takvi ljudi mogu biti vrlo otporni na bilo kakve promjene.
Ali postoje timovi koji, naprotiv, rado uvode nove alate i metode te aktivno sudjeluju u tom procesu. Iako ni u ovom slučaju komunikacija između DevOps inženjera i tima nije prekinuta.
Kada DevOps nije potreban
Postoje situacije kada DevOps nije potreban. To je činjenica – treba je razumjeti i prihvatiti.
Prije svega, to se odnosi na sve tvrtke (osobito mala poduzeća), kada njihova dobit ne ovisi izravno o prisutnosti ili odsutnosti IT proizvoda koji pružaju informacijske usluge klijentima. Ovdje ne govorimo o web stranici tvrtke, bilo da se radi o statičkoj "posjetnici" ili s dinamičkim blokovima vijesti itd.
DevOps je potreban kada zadovoljstvo vašeg klijenta i njegova želja da vam se ponovno vrati ovisi o dostupnosti ovih informacijskih usluga za interakciju s klijentom, njihovoj kvaliteti i ciljanosti.
Upečatljiv primjer je jedna poznata banka. Tvrtka nema uobičajene urede za klijente, protok dokumentacije odvija se putem pošte ili kurira, a mnogi zaposlenici rade od kuće. Tvrtka je prestala biti samo banka i, po mom mišljenju, postala IT tvrtka s razvijenim DevOps tehnologijama.
Brojni drugi primjeri i predavanja mogu se pronaći u snimkama tematskih susreta i konferencija. Neke sam osobno posjetio - ovo je vrlo korisno iskustvo za one koji se žele razvijati u tom smjeru. Evo poveznica na YouTube kanale s dobrim predavanjima i materijalima o DevOps-u:
Sada pogledajte svoje poslovanje i razmislite o ovome: Koliko vaša tvrtka i njezina dobit ovise o IT proizvodima koji omogućuju interakciju s korisnicima?
Ako vaša tvrtka prodaje ribe u maloj trgovini, a jedini IT proizvod su dvije konfiguracije 1C: Enterprise (Računovodstvo i UNF), onda nema smisla govoriti o DevOps-u.
Ako radite u velikom trgovačkom i proizvodnom poduzeću (na primjer, proizvodite lovačke puške), trebali biste razmisliti o tome. Možete preuzeti inicijativu i prenijeti svom menadžmentu izglede za implementaciju DevOps-a. Pa, i u isto vrijeme, voditi ovaj proces. Proaktivna pozicija jedno je od važnih načela DevOps filozofije.
Veličina i obujam godišnjeg financijskog prometa nije glavni kriterij za određivanje treba li vašoj tvrtki DevOps.
Zamislimo veliko industrijsko poduzeće koje ne komunicira izravno s kupcima. Na primjer, neki proizvođači automobila i tvrtke za proizvodnju automobila. Sada nisam siguran, ali iz mog prošlog iskustva dugi niz godina sva interakcija s klijentima odvijala se putem e-pošte i telefona.
Njihovi klijenti su ograničeni popis trgovaca automobilima. I svakom je dodijeljen stručnjak od proizvođača. Sav interni protok dokumenata odvija se kroz SAP ERP. Interni zaposlenici su u biti klijenti informacijskog sustava. Ali ovaj IS je kontroliran klasičnim načinima upravljanja klasterskim sustavima. Što isključuje mogućnost korištenja DevOps praksi.
Stoga zaključak: za takve tvrtke implementacija DevOps-a nije nešto kritično važno, ako se prisjetimo ciljeva metodologije s početka članka. Ali ne isključujem da danas koriste neke DevOps alate.
S druge strane, postoje mnoge male tvrtke koje razvijaju softver koristeći DevOps metodologiju, filozofiju, prakse i alate. I vjeruju da je trošak implementacije DevOpsa trošak koji im omogućuje učinkovito natjecanje na tržištu softvera. Primjeri takvih tvrtki mogu se vidjeti .
Glavni kriterij za razumijevanje je li DevOps potreban: koju vrijednost vaši IT proizvodi imaju za tvrtku i klijente.
Ako je glavni proizvod tvrtke koji donosi profit softver, potreban vam je DevOps. I nije toliko važno zarađujete li pravi novac koristeći druge proizvode. To također uključuje internetske trgovine ili mobilne aplikacije s igrama.
Sve igre postoje zahvaljujući financiranju: izravno ili neizravno od igrača. U Playgendaryju razvijamo besplatne mobilne igre s više od 200 ljudi koji su izravno uključeni u njihovu izradu. Kako koristimo DevOps?
Da, potpuno isto kao što je gore opisano. Konstantno komuniciram s programerima i testerima te provodim internu edukaciju zaposlenika o DevOps metodologiji i alatima.
Sada aktivno koristimo Jenkins kao alat za CI/CD cjevovode za izvršavanje svih sklopovskih cjevovoda s Unityjem i naknadnu implementaciju u App Store i Play Market. Više iz klasičnog alata:
- Asana - za upravljanje projektima. Integracija s Jenkinsom je konfigurirana.
- Google Meet - za video sastanke.
- Slack - za komunikaciju i razna upozorenja, uključujući obavijesti od Jenkinsa.
- Atlassian Confluence - za dokumentaciju i grupni rad.
Naši neposredni planovi uključuju uvođenje statičke analize koda pomoću SonarQubea i provođenje automatiziranog testiranja korisničkog sučelja pomoću Seleniuma u fazi kontinuirane integracije.
Umjesto zaključka
Želio bih završiti sa sljedećom mišlju: da biste postali visokokvalificirani DevOps inženjer, bitno je naučiti kako komunicirati uživo s ljudima.
DevOps inženjer je timski igrač. I nista vise. Inicijativa u komunikaciji s kolegama trebala bi dolaziti od njega, a ne pod utjecajem nekih okolnosti. DevOps stručnjak mora vidjeti i predložiti najbolje rješenje za tim.
I da, o implementaciji bilo kojeg rješenja trebat će puno rasprave, a na kraju se može i promijeniti. Samostalno se razvijajući, predlažući i ostvarujući svoje ideje, takva osoba postaje sve vrijednija kako za tim tako i za poslodavca. Što se, u konačnici, očituje u visini njegove mjesečne naknade ili u vidu dodatnih bonusa.
Izvor: www.habr.com