Šta je potrebno da bi IT kompanija bila uspješna u 2019. godini? Predavači na konferencijama i skupovima govore mnogo glasnih riječi koje nisu uvijek razumljive normalnim ljudima. Borba za vrijeme implementacije, mikroservise, napuštanje monolita, DevOps transformacija i još mnogo, mnogo više. Ako odbacimo verbalnu ljepotu i govorimo direktno i na ruskom, onda se sve svodi na jednostavnu tezu: napravi kvalitetan proizvod i učini to s udobnošću za tim.
Ovo poslednje je postalo kritično važno. Biznis je konačno došao do zaključka da udoban proces razvoja povećava produktivnost, a ako je sve otklonjeno i radi kao sat, daje i prostor za manevar u kritičnim situacijama. Nekada davno, radi ovog manevra, neka pametna osoba je smislila sigurnosne kopije, ali industrija se razvija i došli smo do DevOps inženjera - ljudi koji proces interakcije između razvoja i eksterne infrastrukture pretvaraju u nešto adekvatno i nije u vezi sa šamanizmom.
Cijela ova “modularna” priča je divna, ali... Tako se dogodilo da su neki od administratora naglo prozvali DevOps, a od samih DevOps inženjera se počelo zahtijevati da posjeduju barem vještine telepatije i vidovitosti.
Prije nego što govorimo o savremenim problemima obezbjeđivanja infrastrukture, hajde da definišemo šta podrazumevamo pod ovim pojmom. U ovom trenutku situacija se tako razvila da smo došli do dualnosti ovog koncepta: infrastruktura može biti uslovno eksterna i uslovno unutrašnja.
Pod eksternom infrastrukturom podrazumijevamo sve ono što osigurava funkcionalnost usluge ili proizvoda koji tim razvija. To su serveri aplikacija ili web stranica, hosting i druge usluge koje osiguravaju funkcionalnost proizvoda.
Interna infrastruktura uključuje usluge i opremu koju koristi sam razvojni tim i drugi zaposleni, kojih je obično mnogo. To su interni serveri sistema za pohranu koda, lokalno raspoređeni upravitelj zadataka i sve, sve, sve što postoji unutar korporativnog intraneta.
Šta radi sistem administrator u kompaniji? Pored rada na administriranju ovog korporativnog intraneta, on često nosi teret ekonomskih briga kako bi se osigurala operativnost kancelarijske opreme. Administrator je isti onaj tip koji će brzo izvući novu sistemsku jedinicu ili rezervni laptop spreman za upotrebu iz pomoćne prostorije, dati novu tastaturu i puzati na sve četiri kroz kancelarije, protežući Ethernet kabl. Administrator je lokalni vlasnik i vladar ne samo internih i eksternih servera, već i izvršni direktor. Da, neki administratori mogu raditi samo u sistemskoj ravni, bez hardvera. Trebalo bi ih razdvojiti u posebnu podklasu „administratora sistema infrastrukture“. A neki se specijalizuju za servis isključivo kancelarijske opreme; srećom, ako kompanija ima više od stotinu ljudi, posao nikad ne prestaje. Ali nijedan od njih nije devops.
Ko su DevOps? Devops su ljudi koji govore o interakciji razvoja softvera sa eksternom infrastrukturom. Preciznije, moderni devopsi su uključeni u procese razvoja i implementacije mnogo dublje nego što su ikada bili uključeni administratori koji su jednostavno uploadovali ažuriranja na ftp. Jedan od ključnih zadataka DevOps inženjera sada je da osigura udoban i efikasno strukturiran proces interakcije između razvojnih timova i infrastrukture proizvoda. Upravo su ovi ljudi odgovorni za implementaciju sistema za vraćanje i implementaciju; upravo ti ljudi preuzimaju dio opterećenja programera i maksimalno se koncentrišu na svoj izuzetno važan zadatak. U isto vrijeme, devops nikada neće pokrenuti novi kabel ili izdati novi laptop iz stražnje sobe (c) KO
u čemu je kvaka?
Na pitanje "Ko je DevOps?" polovina radnika na terenu počinje da odgovara nešto poput „Pa ukratko, ovo je admin koji...“ i dalje u tekstu. Da, nekada, kada je profesija DevOps inženjera tek izlazila iz najtalentovanijih administratora po pitanju održavanja servisa, razlike među njima nisu bile očigledne svima. Ali sada, kada su funkcije devops-a i admina u timu postale radikalno različite, neprihvatljivo je međusobno ih brkati, pa čak i izjednačavati.
Ali šta to znači za biznis?
Zapošljavanje, sve je o tome.
Otvarate konkurs za “System Administrator”, a tu su navedeni zahtjevi “interakcija sa razvojem i kupcima”, “CI/CD sistem isporuke”, “održavanje servera i opreme kompanije”, “administracija internih sistema” i sl. on; razumiješ da poslodavac priča gluposti. Kvaka je u tome što bi umjesto “System Administrator” upražnjeno radno mjesto trebalo da bude “DevOps inženjer”, a ako se ovo zvanje promijeni, onda sve dolazi na svoje mjesto.
Međutim, kakav utisak steknete kada pročitate ovakav konkurs? Da kompanija traži operatera sa više mašina koji će postaviti i sistem za kontrolu verzija i nadzor i koji će zubima stiskati twister...
Ali da se ne bi povećao stepen ovisnosti o drogama na tržištu rada, dovoljno je nazvati slobodna radna mjesta pravim imenom i jasno shvatiti da su DevOps inženjer i sistem administrator dva različita subjekta. Ali nezadrživa želja nekih poslodavaca da predoče što širu listu zahtjeva kandidatu dovodi do toga da „klasični“ sistem administratori prestaju razumjeti šta se oko njih događa. Šta, struka mutira a oni su u zaostatku?
Ne ne i još jednom ne. Administratori infrastrukture, koji će upravljati internim serverima kompanije, ili zauzimati L2/L3 pozicije podrške i pomagati drugim zaposlenima, nisu otišli i neće otići.
Mogu li ovi stručnjaci postati DevOps inženjeri? Naravno da mogu. U stvari, ovo je povezano okruženje koje zahtijeva vještine sistemske administracije, ali pored toga, dodaje se rad sa sistemima za praćenje, isporuku i općenito bliska interakcija s timom za razvoj i testiranje.
Još jedan DevOps problem
Zapravo, sve nije ograničeno samo na zapošljavanje i stalnu zbrku između administratora i devopsa. U nekom trenutku, posao se suočio sa problemom isporuka ažuriranja i interakcije razvojnog tima sa finalnom infrastrukturom.
Možda je to bilo kada je ujak blistavih očiju ustao na binu neke konferencije i rekao: „Mi to radimo i zovemo to DevOps. Ovi momci će riješiti sve vaše probleme” - i počeo je pričati kako je dobar život u kompaniji nakon implementacije DevOps praksi.
Međutim, nije dovoljno unajmiti DevOps inženjera kako bi sve funkcioniralo kako treba. Kompanija mora proći potpunu transformaciju DevOps-a, odnosno ulogu i mogućnosti našeg DevOps-a također moraju biti jasno shvaćene od strane tima za razvoj i testiranje proizvoda. Imamo „divnu“ priču na ovu temu koja u potpunosti ilustruje svu brutalnost koja se dešava na nekim mestima.
Situacija. DevOps je neophodan za implementaciju sistema za vraćanje verzije bez stvarnog upuštanja u to kako će on funkcionirati. Pretpostavimo da u sistemu Korisnici postoje posebna polja za ime, prezime i lozinku. Izlazi nova verzija proizvoda, ali za programere je "povratak" samo čarobni štapić koji će sve popraviti, a oni ni sami ne znaju kako to funkcionira. Tako su, na primjer, u sljedećoj zakrpi programeri kombinirali polja za ime i prezime, pustili ga u proizvodnju, ali verzija je iz nekog razloga spora. Šta se dešava? Menadžment dolazi u devops i kaže “Povuci prekidač!”, odnosno traži od njega da se vrati na prethodnu verziju. Šta devops radi? Vraća se na prethodnu verziju, ali pošto programeri nisu hteli da shvate kako je ovo vraćanje urađeno, niko nije rekao devops timu da je potrebno vratiti i bazu podataka. Kao rezultat, sve nam se ruši, a umjesto spore web stranice korisnici vide grešku „500“, jer stara verzija ne radi sa poljima nove baze podataka. Devops ne zna za ovo. Programeri ćute. Menadžment počinje gubiti živce i novac i prisjeća se rezervnih kopija, nudeći im da se povuku s njih kako bi „barem nešto uspjelo“. Kao rezultat, korisnici gube sve svoje podatke tokom određenog vremenskog perioda.
Orasi, naravno, idu u devops, koji "nije napravio odgovarajući sistem vraćanja", i nikog nije briga što su losovi u ovoj priči programeri.
Zaključak je jednostavan: bez normalnog pristupa DevOps-u kao takvom, on je od male koristi.
Glavna stvar koju treba zapamtiti: DevOps inženjer nije mađioničar, a bez kvalitetne komunikacije i dvosmjerne interakcije s razvojem, neće se nositi sa svojim zadacima. Razvijači ne mogu ostati sami sa svojim "problemima" ili dobiti naredbu "ne petljajte se sa programerima, njihov posao je da kodiraju", a zatim se nadati da će u kritičnom trenutku sve funkcionirati kako treba. To ne radi tako.
U suštini, DevOps je kompetencija na granici između menadžmenta i tehnologije. Štaviše, daleko je od očiglednog da bi u ovom koktelu trebalo biti više tehnologije nego menadžmenta. Ako zaista želite izgraditi brže i efikasnije razvojne procese, morate vjerovati svom devops timu. Poznaje prave alate, realizovao je slične projekte, zna kako se to radi. Pomozite mu, poslušajte njegov savjet, ne pokušavajte ga izolirati u nekakvu autonomnu jedinicu. Ako administratori mogu raditi sami, onda su devops u ovom slučaju beskorisni; neće vam moći pomoći da postanete bolji ako sami ne želite prihvatiti ovu pomoć.
I poslednja stvar: prestanite vrijeđati administratore infrastrukture. Oni imaju svoj, izuzetno važan front posla. Da, administrator može postati DevOps inženjer, ali to bi trebalo da se desi na zahtev same osobe, a ne pod pritiskom. I nema ništa loše u činjenici da sistem administrator želi da ostane sistem administrator - to je njegova posebna profesija i njegovo pravo. Ako želite da prođete kroz profesionalnu transformaciju, onda nikada ne smijete zaboraviti da ćete morati izgraditi ne samo tehnološke, već i menadžerske vještine. Najvjerovatnije će na vama kao vođi biti da spojite sve ove ljude i naučite ih da komuniciraju na istom jeziku.
izvor: www.habr.com