U posljednje vrijeme takvi su oglasi preplavili internet. Iako je plaća primamljiva, ne može a da ne smeta što unutar njih piše potpuna besmislica. U početku se pretpostavlja da se 'DevOps' i 'inženjer' mogu nekako spojiti u jednu riječ, a zatim slijedi nasumičan popis zahtjeva, od kojih je dio očito prekopiran iz oglasa za sistemskog administratora.
U ovom postu želim malo razgovarati o tome kako smo došli do ovoga, što DevOps zapravo jest i što sada učiniti s tim.
Takve oglase možemo osuditi, ali činjenica je da ih ima puno i to je trenutno situacija na tržištu. Organizirali smo DevOps konferenciju i otvoreno izjavljujemo: — nije za DevOps inženjere. Mnogima će ovo zvučati čudno i neprihvatljivo: zašto ljudi koji rade potpuno komercijalni događaj idu protiv tržišta. Sada ćemo to objasniti.
O kulturi i procesima
Počnimo s tim da DevOps nije inženjerska disciplina. Sve je počelo od toga da povijesno razdvajanje uloga ne doprinosi kvaliteti proizvoda. Kada programeri samo programiraju, ali ne žele ništa čuti o testiranju — softver je prepun grešaka. Kada administratorima nije stalo do toga kako i zašto je softver napisan — podrška postaje pakao.
Na primjer, opis razlike između sistema administracije i SRE pristupa upravljanju uslugama . Zanimljive studije provedene su u okviru — vidljivo je da najbolji programeri na neki način uspijevaju implementirati nove promjene u produkciju brže nego jednom u satu. Oni također ne testiraju ručno više od 10% (to se može vidjeti u ). Kako im to uspijeva? 'Excel ili umri' – kaže jedan od naslova izvještaja. Za detaljnu raspravu o ovoj statistici u sklopu testiranja možete se obratiti keynoteu Barucha Sadogurskog na našoj drugoj konferenciji, Heisenbug.
'Kada među prijateljima nema slaganja,
Njihovo djelo neće ići,
I iz njega će izaći ne posao, već mučenje.
Jednom su Labud, Rak i Štuka...'
Kako mislite, koja je točka web programera koja zaista razumije u kojim se uvjetima njihovi aplikacije koriste u produkciji? Koliko njih će otići do administratora i pokušati saznati što će se dogoditi prilikom pada baze podataka? A tko će otići do testera i zamoliti ih da ih nauče kako ispravno pisati testove? A tu su još i sigurnosni stručnjaci, menadžeri proizvoda, cijela hrpa ljudi.
Osnovna ideja DevOps-a je uspostavljanje suradnje između uloga i odjela. To se prije svega postiže ne nekim složenim softverskim rješenjima, već praksom komunikacije. DevOps je o kulturi, praksi, metodologiji i procesima. Ne postoji takva inženjerska profesija koja bi odgovarala na ta pitanja.
Zatvoreni krug
Odakle je tada potekla disciplina 'devops inženjerstva'? Imamo verziju! Ideje DevOps-a bile su tako dobre — toliko dobre da su postale žrtve vlastitog uspjeha. Oko ove teme počeli su se okupljati sumnjivi regruteri i trgovci ljudima, koji imaju svoju specifičnu atmosferu.
Zamislite: jučer ste u Himkama radili s shawarmom, a danas ste već velika osoba, senior regruter. Tu je cijeli proces traženja i odabira kandidata, sve nije jednostavno, treba razumjeti. Recimo, šef odjela kaže: pronađi stručnjaka za X. Dodajemo riječ 'inženjer' uz X i stvar je riješena. Treba Linux? Pa to je definitivno Linux-inženjer, ako želite DevOps — DevOps-inženjer. Oglas nije samo naslov, već unutra treba napisati i neki tekst. Najlakše je ubaciti set ključnih riječi s Googlea, koliko tko može smisliti. DevOps se sastoji od dvije riječi — 'Dev' i 'Ops', znači, treba spojiti ključne riječi povezane s programerima i administratorima u jednu hrpu. Tako se pojavljuju oglasi o poznavanju 42 programska jezika i 20 godina korištenja Kubernetes-a i Swarm-a istovremeno. Radna shema.
Tako se u svijesti ljudi ukorijenio besmisleni i nemilosrdni lik nekog superjunaka-‘devopsa’, koji će svima prilagoditi deploy na Jenkins-u, i tada će nastati sreća. Ah, kad bi sve bilo tako jednostavno. 'A još tako mogu potraživati sistemske administratore,' misli HR, 'to je moderna riječ, iste ključne riječi, trebali bi se uhvatiti.'
Potražnja stvara ponudu, i na sve te glupave oglase za posao naletjelo je nevjerojatno mnogo sistemskih administratora koji su shvatili: mogu raditi sve isto što i prije, ali dobivati nekoliko puta više, nazvavši se "devopsima". Kako si do sada podešavao servere preko SSH-a jedan po jedan, tako ćeš i dalje raditi, ali sad je to navodno devops praksa. To je neka složena pojava, djelomično povezana s nedovoljnom procjenom klasičnih administratora i hypeom oko DevOps-a, ali u svakom slučaju — što je tu je, to se dogodilo.
Dakle, imamo potražnju i ponudu. Zatvoreni krug koji se sam sebe hrani. S tim se mi borimo (između ostalog, organizirajući konferenciju DevOops).
Naravno, osim sistemskih administratora koji su se preimenovali u "devopse", postoje i drugi sudionici — na primjer, profesionalni SRE-ovi ili programeri Infrastructure-as-Code.
Čime se ljudi zapravo bave u DevOps-u
Dakle, želite napredovati u učenju i primjeni DevOps praksi. Ali kako to postići, u kojem smjeru gledati? Očito, slijepim vođenjem popularnim ključnim riječima ne treba se zamarati.
Ako posao postoji, netko se njime mora baviti. Već smo utvrdili da to nisu "devops inženjeri", pa tko onda? Čini se da je ispravnije to formulisati ne u pojmovima radnih mjesta, već u pojmovima konkretnih područja rada.
Prvo, možete se baviti samim srcem DevOps-a — procesima i kulturom. Kultura je spor i težak posao, i iako je to tradicionalno područje odgovornosti rukovoditelja, na ovaj ili onaj način u tome sudjeluju svi, od programera do administratora. Prije nekoliko mjeseci Tim Lister :
"Kultura se postavlja osnovnim vrijednostima organizacije. Obično ljudi to ne primjećuju, ali mi, radeći u konzultantskim poslovima dugi niz godina, navikli smo to primjećivati. Uđeš u kompaniju i doslovno nakon nekoliko minuta počneš osjećati što se događa. Mi to nazivamo 'aromom'. Ponekad je ta aroma zaista dobra. Ponekad izaziva mučninu. (…) Ne možeš promijeniti kulturu dok se ne osvijeste vrijednosti i uvjerenja koja stoje iza određenih postupaka. Ponašanje je lako primijetiti, ali pronalaženje uvjerenja je teško. DevOps je upravo izvrstan primjer kako sve postaje sve složenije i složenije."
Postoji i tehnička strana problema, naravno. Ako novi kod stigne na testiranje kroz mjesec dana, a u verziji se pojavi tek nakon godinu dana, te fizički nije moguće ubrzati sve to — do dobrih praksi možda se i ne stigne. Dobre prakse podržavaju dobri alati. Na primjer, držeći u glavi ideju Infrastructure-as-Code, možete koristiti bilo što, od AWS CloudFormation-a i Terraform-a do Chef-Ansible-Puppet-a. Sve to treba znati i umjeti, i to je već uvelike inženjerska disciplina. Važno je ne miješati uzrok i posljedicu: najprije radite po principima SRE, a tek potom konkretizirate te principe kroz neka specifična tehnička rješenja. Pri tome, SRE je vrlo kompleksna metodologija koja ne govori o tome kako postaviti Jenkins, već o pet osnovnih principa:
- Unapređenje suradnje među ulogama i odjelima
- Prihvaćanje grešaka kao neizostavni dio posla
- Postepeno uvođenje promjena
- Korištenje alata i automatizacije
- Mjerenje svega što se može mjeriti
To nije samo skup izjava, već konkretno . Na primjer, na putu prihvaćanja grešaka potrebno je razjasniti rizike, izmjeriti dostupnost i nedostupnost servisa pomoću nečega poput SLI () i SLO (), naučiti pisati postmorteme i učiniti da njihovo pisanje ne bude zastrašujuće.
U disciplini SRE, korištenje alata samo je jedan od dijelova uspjeha, iako ne manje važan. Moramo se neprekidno razvijati u tehničkom smislu, pratiti što se događa u svijetu i kako to možemo primijeniti u svom radu.
U posljednje vrijeme, rješenja Cloud Native postala su vrlo popularna. Prema suvremenom shvaćanju Cloud Native Computing Foundation, tehnologije Cloud Native omogućuju organizacijama razvoj i pokretanje skalabilnih aplikacija u modernim dinamičkim okruženjima poput javnih, privatnih i hibridnih oblaka. Kao primjeri može se navesti kontejneri, servisni mrežni slojevi, mikroservisi, nepromjenjiva infrastruktura i deklarativni API-ji. Sve ove tehnike omogućuju slabo povezanim sustavima da ostanu elastični, upravljivi i dobro uočljivi. Dobra automatizacija omogućava inženjerima da često provode velike promjene s predvidivim ishodima, bez da to postane iznimno naporan posao. Sve to podržava skup poznatih alata kao što su Docker i Kubernetes.
Ova definicija je prilično složena i opširna, što je rezultat složenosti samog područja. S jedne strane, tvrdi se da nove promjene u ovaj sustav trebaju biti dovoljno jednostavne za implementaciju. S druge strane, kako se snaći u tome kako stvoriti određeno kontejnerizirano okruženje u kojem slabo povezane usluge žive na softverski definiranom infrastrukturi, te se isporučuju putem kontinuiranog CI/CD-a i postaviti DevOps prakse oko cijele te strukture — za to je potrebno značajno znanje i iskustvo.
Što učiniti s tim svime
Svaka osoba rješava te probleme na svoj način: primjerice, može se objaviti normalne natječaje za posao kako bi se prekinuo začarani krug. Može se shvatiti što znače pojmovi poput DevOps i Cloud Native i pravilno ih koristiti. Može se razvijati u području DevOps-a i svojim primjerom pokazati ispravne pristupe.
Organiziramo konferenciju , koja pruža priliku da dublje razumijemo stvari o kojima smo upravo razgovarali. Za to postoje nekoliko skupina prezentacija:
- Procesi i kultura;
- Inženjerstvo pouzdanosti web stranica;
- Cloud Native;
Kako odabrati kuda ići? Postoji mala stvar. S jedne strane, DevOps se odnosi na interakciju, i želimo da odete na prezentacije iz različitih blokova. S druge strane, ako ste voditelj razvoja koji je došao na konferenciju da se fokusira na jedan konkretan zadatak, nitko vas ne ograničava — očito, to će biti blok o procesima i kulturi. Ne zaboravite da će vam nakon konferencije ostati snimke (nakon popunjavanja obrasca za povratne informacije), tako da ćete uvijek moći pogledati manje važne prezentacije kasnije.
Očito je da na samoj konferenciji ne možete ići na tri programa odjednom, zbog toga tako formiramo program da u svakom vremenskom slotu budu teme za svakoga.
Samo još treba shvatiti što učiniti ako ste DevOps inženjer! Prvo, pokušajte odrediti čime se zapravo bavite. Obično ovim izrazom vole nazivati:
- Programere koji se bave infrastrukturom. Za vas će najviše odgovarati grupe prezentacija o SRE i Cloud Native.
- Sistemske administratore. Ovdje je teže. DevOops nije o sistemskom administriranju. Na sreću, o sistemskom administriranju postoji mnoštvo izvrsnih konferencija, knjiga, članaka, videa na internetu itd. S druge strane, ako vas zanima razvijati se u razumijevanju kulture i procesa, učenju o oblaku i detaljima života s Cloud Native, bilo bi nam drago da vas vidimo! Razmislite o tome: vi se bavite administracijom, a što ćete dalje raditi? Da se ne biste iznenada našli u neugodnoj situaciji, trebate početi učiti već sada.
Postoji još jedna opcija: uporno tvrdite da ste upravo DevOps inženjer i ništa drugo, što god to značilo. Tada vas moramo razočarati, DevOops nije konferencija za DevOps inženjere!
Slajd iz u Münchenu
DevOops 2020 Moskva održat će se 29.-30. travnja u Moskvi, karte se već mogu .
Osim toga, možete do 8. veljače. Imajte na umu da pri popunjavanju obrasca trebate odabrati ciljanu publiku kojoj će vaša prezentacija donijeti najveću korist (unutar popisa je skrivena iznenađenja).
Izvor: habr.com
