DevOps tema je postala veoma popularna u poslednjih nekoliko godina. Mnogi sanjaju da joj se pridruže, ali, kako praksa pokazuje, često samo zbog visine plata.
Neki u svom životopisu navode DevOps, iako ne znaju uvijek i ne razumiju suštinu pojma. Neko misli da će nakon što je proučio Ansible, GitLab, Jenkins, Terraform i slično (lista se može nastaviti po vašem ukusu), odmah postati “devops”. To, naravno, nije tačno.
U proteklih nekoliko godina uglavnom sam bio uključen u implementaciju DevOps-a u raznim kompanijama. Prije toga, više od 20 godina radio je na pozicijama od sistem administratora do IT direktora. Trenutno DevOps vodeći inženjer u Playgendary.
Ko je DevOps
Ideja za pisanje članka nastala je nakon još jednog pitanja: „ko je DevOps?“. Još uvijek nema ustaljenog termina za šta ili ko je to. Neki od odgovora su već u ovome . Prvo ću istaknuti glavne teze iz njega, a zatim ću iznijeti svoja zapažanja i razmišljanja.
DevOps nije specijalista za zapošljavanje, nije skup uslužnih programa, niti razvojni odjel sa inženjerima.
DevOps je filozofija i metodologija.
Drugim riječima, to je skup praksi koji pomaže programerima da aktivno komuniciraju sa sistemskim administratorima. Odnosno, povezati i integrirati radne procese jedan u drugi.
Sa pojavom DevOps-a, struktura i uloge stručnjaka ostali su isti (postoje programeri, postoje inženjeri), ali su se pravila interakcije promijenila. Granice između odjeljenja su zamagljene.
DevOps ciljevi se mogu sažeti u tri tačke:
- Softver se mora redovno ažurirati.
- Softver se mora napraviti brzo.
- Softver bi trebao biti postavljen na jednostavan način i u kratkom vremenu.
DevOps nema niti jedan alat. Postavljanje, isporuka i učenje o više proizvoda ne znači da je DevOps u kompaniji. Postoji mnogo alata i svi su uključeni u različitim fazama, ali služe jednom zajedničkom cilju.
I to je samo dio DevOps alata
Više od 2 godine sam intervjuisao ljude za poziciju DevOps inženjera i shvatio sam koliko je važno jasno razumjeti suštinu pojma. Sakupio sam specifična iskustva, zapažanja i razmišljanja koja želim podijeliti.
Iz iskustva sa intervjua vidim ovu sliku: profesionalci koji smatraju DevOps pozicijom obično imaju nesporazume sa kolegama.
Postojao je odličan primjer. Mladić je došao na razgovor s gomilom šaljivih riječi u životopisu. Na posljednja tri mjesta rada imao je iskustvo od 5-6 mjeseci. Napustio je dva startupa jer "nisu poletjeli". Ali za treću kompaniju, rekao je da ga tamo niko ne razumije: programeri pišu kod za Windows, a direktor ovaj kod "umota" u uobičajeni Docker i ugradi u CI / CD cjevovod. Momak je rekao mnogo negativnih stvari o svom trenutnom radnom mjestu i kolegama - samo sam htio odgovoriti: "Dakle, nećeš prodati slona."
Onda sam mu postavio pitanje koje je jedno od prvih na mojoj listi za svakog kandidata.
Šta vama lično znači DevOps?
- Generalno, ili kako ja to doživljavam?
Zanimalo me je njegovo lično mišljenje. Poznavao je teoriju i porijeklo tog pojma, ali se s njima snažno nije slagao. Vjerovao je da je DevOps pozicija. Tu leži korijen njegovih problema. Kao i drugi stručnjaci istog mišljenja.
Poslodavci, koji su čuli mnogo o „magiji DevOpsa“, žele da pronađu osobu koja će doći i stvoriti ovu „čaroliju“. Ono što „DevOps je posao“ ne shvaćaju oni koji traže posao je da ovim pristupom neće moći ispuniti očekivanja. I, generalno, napisali su DevOps u svom životopisu, jer je to trend i oni mnogo plaćaju za to.
DevOps metodologija i filozofija
Metodologija je teorijska i praktična. U našem slučaju, 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 kompanije, može se značajno razlikovati. To ga ne čini boljim ili lošijim.
DevOps metodologija je samo sredstvo za postizanje vaših ciljeva.
Sada o tome koja je filozofija DevOps-a. A ovo je vjerovatno najteže pitanje.
Prilično je teško formulirati kratak i opsežan odgovor, jer još nije formaliziran. A pošto su pristalice DevOps filozofije više angažovane u praksi, jednostavno nema vremena za filozofiranje. Međutim, ovo je veoma važan proces. Štaviše, direktno vezano za inženjerske aktivnosti. Postoji čak i specijalizovano polje znanja - .
Na mom fakultetu nije postojao takav predmet, sve sam morao sam da učim koristeći materijale koje sam mogao pronaći 90-ih. Tema je izborna za inženjersko obrazovanje, pa otuda i nedostatak formalizacije odgovora. Ali oni ljudi koji su ozbiljno uronjeni u DevOps počinju osjećati određeni “duh” ili “nesvjesnu sveobuhvatnost” svih procesa kompanije.
Na osnovu sopstvenog iskustva, pokušao sam da formalizujem neke od „postulata“ ove filozofije. Ispostavilo se sljedeće:
- DevOps nije nešto nezavisno što se može odvojiti u zasebnu oblast znanja ili aktivnosti.
- DevOps metodologija treba da vodi sve zaposlene u kompaniji kada planiraju svoje aktivnosti.
- DevOps utiče na sve procese u kompaniji.
- DevOps postoji kako bi smanjio vrijeme utrošeno na bilo koje procese unutar kompanije kako bi osigurao razvoj njenih usluga i maksimalnu udobnost klijenta.
- DevOps je, moderno rečeno, proaktivna pozicija svakog zaposlenika kompanije, usmjerena na smanjenje vremenskih troškova i poboljšanje kvaliteta IT proizvoda oko nas.
Mislim da su moji "postulati" posebna tema za razgovor. Ali sada postoji nešto na čemu se može graditi.
Šta radi DevOps?
Ključna riječ ovdje je komunikacija. Postoji mnogo komunikacija, čiji bi inicijator trebao biti isti DevOps inženjer. Žašto je to? Jer to je filozofija i metodologija, pa tek onda inženjersko znanje.
Ne mogu sa 100% sigurnošću govoriti o zapadnom tržištu rada. Ali znam dosta o DevOps tržištu u Rusiji. Pored stotina intervjua, u proteklih godinu i po dana učestvovao sam u stotinama tehničkih pretprodaja na usluzi DevOps Implementation za velike ruske kompanije i banke.
U Rusiji je DevOps još uvijek vrlo mlad, ali već popularna tema. Koliko znam, samo u Moskvi je manjak takvih stručnjaka u 2019. iznosio više od 1000 ljudi. A riječ Kubernetes za poslodavce je skoro kao crvena krpa za bika. Pristaše ovog alata spremni su da ga koriste čak i tamo gdje nije potreban i nije ekonomski isplativ. Poslodavac ne razumije uvijek u kojim slučajevima je što je prikladnije koristiti, a uz pravilnu implementaciju, održavanje Kubernetes klastera košta 2-3 puta više od implementacije aplikacije koristeći konvencionalnu šemu klastera. Koristite ga tamo gde vam je zaista potrebno.
Implementacija DevOps-a je skupa u smislu novca. A opravdano je samo tamo gdje donosi ekonomske koristi u drugim oblastima, a ne samo po sebi.
DevOps inženjeri su, zapravo, pioniri - oni su prvi koji su implementirali ovu metodologiju u kompaniji i grade procese. Da bi ovo bilo uspješno, stručnjak mora u stalnoj interakciji sa zaposlenima i kolegama na svim nivoima. Kao što obično kažem, svi zaposleni u kompaniji treba da budu uključeni u proces implementacije DevOps-a: od čistačice do generalnog direktora. A to je preduslov. Ako najmlađi član tima ne zna i ne razumije šta je DevOps i zašto se izvode određene organizacijske radnje, uspješna implementacija neće uspjeti.
Takođe, DevOps inženjer mora s vremena na vrijeme koristiti administrativni resurs. Na primjer, za prevazilaženje "otpora okoline" - kada tim nije spreman da prihvati DevOps alate i metodologiju.
Programer bi trebao pisati samo kod i testove. Da bi to učinio, nije mu potreban super-moćan laptop na kojem će lokalno postaviti i održavati cjelokupnu infrastrukturu projekta. Na primjer, front-ender čuva sve elemente aplikacije na svom laptopu, uključujući bazu podataka, S3 (minio) emulator itd. Odnosno, provodi dosta vremena održavajući ovu lokalnu infrastrukturu i sam se bori sa svim problemima takvog rješenja. Umjesto razvoja koda za prednji dio. Takvi ljudi mogu snažno da se odupru svim promjenama.
Ali postoje timovi koji su, naprotiv, zadovoljni uvođenjem novih alata i metoda, i aktivno učestvuju u ovom procesu. Iako ni u ovom slučaju niko nije otkazao komunikaciju između DevOps inženjera i tima.
Kada DevOps nije potreban
Postoje situacije kada DevOps nije potreban. To je činjenica - to se mora razumjeti i prihvatiti.
Prije svega, ovo se odnosi na bilo koje kompanije (posebno mala preduzeća) kada njihov profit ne zavisi direktno od prisustva ili odsustva IT proizvoda koji pružaju informacijske usluge korisnicima. I ovdje ne govorimo o web stranici kompanije, bilo da je statična "vizit karta" ili sa dinamičkim blokovima vijesti, itd.
DevOps je neophodan kada dostupnost ovih informacionih servisa za interakciju sa klijentom, njihov kvalitet i ciljanost zavise od zadovoljstva vašeg klijenta i njegove želje da vam se ponovo vrati.
Dobro poznata banka je odličan primjer. Kompanija nema uobičajene kancelarije za klijente, tok dokumenata se odvija poštom ili kurirskom službom, a mnogi zaposleni rade od kuće. Kompanija je prestala da bude samo banka i, po mom mišljenju, se pretvorila u IT kompaniju sa razvijenim DevOps tehnologijama.
Mnogi drugi primjeri i predavanja mogu se naći u zapisima tematskih skupova i konferencija. Neke od njih sam lično posjetio - ovo je vrlo korisno iskustvo za one koji žele da se razvijaju u ovom pravcu. Evo linkova ka YouTube kanalima sa dobrim predavanjima i materijalima o DevOps-u:
Sada pogledajte svoje poslovanje i razmislite o ovome: Koliko vaša kompanija i njen profit zavise od IT proizvoda za pružanje korisničkog iskustva?
Ako vaša kompanija prodaje ribu u maloj radnji i jedini IT proizvod su dvije 1C konfiguracije: Enterprise (računovodstvo i UNF), onda nema smisla govoriti o DevOps-u.
Ako radite u velikom trgovačkom i proizvodnom preduzeću (na primjer, proizvodite lovačke puške), onda biste trebali razmisliti o tome. Možete preuzeti inicijativu i svom menadžmentu donijeti viziju implementacije DevOpsa. Pa, u isto vrijeme, voditi ovaj proces. Proaktivan stav je jedan od važnih postulata DevOps filozofije.
Veličina i obim godišnjeg finansijskog prometa nije glavni kriterijum za određivanje da li je vašoj kompaniji potreban DevOps.
Zamislite veliko industrijsko preduzeće koje nema direktnu interakciju sa kupcima. Na primjer, neki proizvođači automobila i automobilske kompanije. Sada nisam siguran, ali iz mog dosadašnjeg iskustva, dugi niz godina, sva interakcija sa kupcima se odvijala putem e-pošte i telefona.
Njihovi klijenti su ograničena lista dilera automobila. I za svaki je vezan stručnjak proizvođača. Sav interni tok dokumenata odvija se kroz SAP ERP. Interni zaposleni, zapravo, su klijenti informacionog sistema. Ali upravljanje ovim IS-om se vrši klasičnim sredstvima upravljanja klaster sistemima. Što isključuje mogućnost korištenja DevOps praksi.
Otuda zaključak: za takva preduzeća implementacija DevOps-a nije nešto kritično, ako se prisjetimo ciljeva metodologije s početka članka. Ali ne isključujem da danas koriste neke DevOps alate.
S druge strane, postoji mnogo malih kompanija koje razvijaju softver koristeći DevOps metodologiju, filozofiju, prakse i alate. I vjeruju da je trošak implementacije DevOps-a trošak koji im omogućava da se efikasno takmiče na tržištu softvera. Mogu se vidjeti primjeri takvih kompanija .
Glavni kriterijum za razumevanje da li je DevOps potreban: koliku vrednost vaši IT proizvodi imaju za kompaniju i kupce.
Ako je glavni profitabilni proizvod kompanije softver, potreban vam je DevOps. I nije toliko važno ako zarađujete pravi novac uz pomoć druge robe. To također može uključivati online trgovine ili mobilne aplikacije s igrama.
Sve igre postoje zahvaljujući finansiranju: direktno ili indirektno od igrača. U Playgendary-ju razvijamo besplatne mobilne igre s preko 200 ljudi koji su direktno uključeni u kreiranje. Kako koristimo DevOps?
Da, tačno kako je gore opisano. Stalno komuniciram sa programerima i testerima, sprovodim internu obuku o DevOps metodologiji i alatima za zaposlene.
Sada aktivno koristimo Jenkins kao alat za CI/CD pipelines za izvođenje svih montažnih cjevovoda sa Unity-om i naknadnom implementacijom na App Store i Play Market. Više iz klasičnog seta alata:
- Asana - za upravljanje projektima. Postavite integraciju sa Jenkinsom.
- Google Meet - za video sastanke.
- Slack - za komunikaciju i razne obavijesti, uključujući obavijesti od Jenkinsa.
- Atlassian Confluence - za dokumentaciju i grupni rad.
U bliskoj budućnosti planiramo implementirati statičku analizu koda koristeći SonarQube i provesti automatsko testiranje korisničkog sučelja koristeći Selenium u fazi kontinuirane integracije.
Umjesto zaključka
Želim da završim sa sledećom mišlju: da biste postali visokokvalifikovani DevOps inženjer, od vitalnog je značaja da naučite kako da komunicirate sa ljudima uživo.
DevOps inženjer je timski igrač. I ništa drugo. Inicijativa u komunikaciji sa kolegama treba da dolazi od njega, a ne pod uticajem bilo kakvih okolnosti. DevOps stručnjak treba da vidi i predloži najbolje rješenje za tim.
I da, implementacija bilo kojeg rješenja zahtijevat će mnogo diskusija, a na kraju se može i promijeniti. Samorazvoj, nuđenje i implementacija svojih ideja - takva osoba ima sve veću vrijednost i za tim i za poslodavca. Što se, u konačnici, ogleda u visini njegove mjesečne naknade ili u vidu dodatnih bonusa.
izvor: www.habr.com