Nedavno su takve reklame preplavile internet. Unatoč ugodnoj plaći, čovjeku ne može ne biti neugodno što je unutra zapisana divlja hereza. U početku se pretpostavlja da se "DevOps" i "inženjer" mogu nekako spojiti u jednu riječ, a zatim postoji nasumični popis zahtjeva, od kojih su neki jasno kopirani iz upražnjenog mjesta sysadmina.
U ovom postu želio bih govoriti malo o tome kako smo došli do ove točke života, što je zapravo DevOps i što s njime sada učiniti.
Ovakva slobodna radna mjesta mogu se osuđivati na sve moguće načine, ali činjenica ostaje: ima ih mnogo, a tržište trenutno tako funkcionira. Održali smo devops konferenciju i otvoreno izjavljujemo: “ - nije za DevOps inženjere." Ovo će se mnogima učiniti čudnim i divljim: zašto ljudi koji rade potpuno komercijalan događaj idu protiv tržišta. Sada ćemo sve objasniti.
O kulturi i procesima
Počnimo s činjenicom da DevOps nije inženjerska disciplina. Sve je počelo činjenicom da povijesno uspostavljena podjela uloga ne ide u prilog kvaliteti proizvoda. Kad programeri samo programiraju, ali ne žele čuti ništa o testiranju, softver je prepun grešaka. Kad administratore nije briga kako i zašto je softver napisan, podrška se pretvara u pakao.
Na primjer, opisivanje razlike između administratora sustava i SRE pristupa upravljanju uslugama . Unutar su provedena zanimljiva istraživanja — jasno je da najbolji programeri nekako uspijevaju implementirati nove promjene u proizvodnju brže od jednom na sat. Testiraju rukama ne više od 10% (to se vidi iz ). Kako to rade? “Excel or die” kaže jedan od naslova izvješća. Za detaljnu raspravu o ovim statistikama u kontekstu testiranja, možete pogledati uvodnu riječ Barucha Sadogurskog na našoj drugoj konferenciji, Heisenbug.
"Kad nema dogovora među drugovima,
Stvari im neće ići dobro,
I ništa neće izaći iz toga, samo muka.
Bio jednom labud, rak i štuka..."
Što mislite, koji dio web programera stvarno razumije uvjete pod kojima se njihove aplikacije koriste u proizvodnji? Koliko njih će otići do administratora i pokušati shvatiti što će se dogoditi ako se baza podataka sruši? A tko će od njih otići do ispitivača i tražiti od njih da ih nauče kako pravilno pisati testove? A tu su i zaštitari, voditelji proizvoda i hrpa drugih ljudi.
Opća ideja DevOps-a je stvaranje suradnje između uloga i odjela. Prije svega, to se ne postiže nekim pametno konfiguriranim softverom, već vježbom komunikacije. DevOps se bavi kulturom, praksama, metodologijom i procesima. Ne postoji inženjerska specijalnost koja može odgovoriti na ova pitanja.
Začarani krug
Odakle onda disciplina “devops inženjering”? Imamo verziju! DevOps ideje bile su dobre – toliko dobre da su postale žrtve vlastitog uspjeha. Oko cijele te teme počeli su se motati neki sumnjivi regruteri i trgovci ljudima koji imaju svoju atmosferu.
Zamislite: jučer ste radili shawarmu u Khimkiju, a danas ste već veliki čovjek, stariji regrut. Postoji cijeli proces traženja i odabira kandidata, nije sve jednostavno, treba razumjeti. Recimo da voditelj odjela kaže: nađite stručnjaka za X. Dodijelimo riječ "inženjer" X-u i gotovi smo. Trebate Linux? Pa, ovo je definitivno Linux inženjer, ako želite DevOps, onda DevOps inženjer. Upražnjeno mjesto ne sastoji se samo od naslova, već se unutra mora unijeti i neki tekst. Najlakši način je unijeti skup ključnih riječi s Googlea, ovisno o vašoj mašti. DevOps se sastoji od dvije riječi - “Dev” i “Ops”, što znači da trebamo spojiti ključne riječi koje se odnose na programere i administratore, sve u jednu hrpu. Tako se pojavljuju natječaji o poznavanju 42 programska jezika i 20 godina korištenja Kubernetesa i Swarma istovremeno. Radni dijagram.
Tako se u glavama ljudi ukorijenila besmislena i nemilosrdna slika izvjesnog "devops" superheroja koji će sve konfigurirati da se rasporede na Jenkinsa i sreća će doći. Oh, kad bi samo sve bilo tako jednostavno. "Ovo je i način na koji možete loviti administratore sustava", smatra HR, "to je moderna riječ, ključne riječi su iste, trebali bi zagrizti mamac."
Potražnja stvara ponudu, a sva ta upražnjena radna mjesta u smeću popunila je suluda količina administratora sustava koji su shvatili: možete raditi sve isto kao i prije, ali dobiti nekoliko puta više nazivajući se "devops". Baš kao što ste ručno konfigurirali poslužitelje putem SSH-a jedan po jedan, nastavit ćete ih konfigurirati, ali sada je to navodno devops praksa. Riječ je o nekakvom složenom fenomenu, djelomično vezanom uz podcjenjivanje klasičnih administratora i hype oko DevOpsa, ali općenito, što se dogodilo, bilo je.
Dakle, imamo ponudu i potražnju. Začarani krug koji hrani sam sebe. To je ono protiv čega se borimo (uključujući stvaranje DevOops konferencije).
Naravno, osim administratora sustava koji su se preimenovali u "devops", postoje i drugi sudionici - na primjer, profesionalni SRE-ovi ili Infrastructure-as-Code programeri.
Što ljudi rade u DevOpsu (stvarno)
Dakle, želite napredovati u učenju i primjeni DevOps praksi. Ali kako to učiniti, u kojem smjeru gledati? Očito, ne biste se trebali slijepo oslanjati na popularne ključne riječi.
Ako ima posla, netko ga treba raditi. Već smo saznali da to nisu “devops inženjeri”, tko su onda? Čini se da je ispravnije to formulirati ne u smislu položaja, već u smislu određenih područja rada.
Prvo, možete se pozabaviti srcem DevOps-a — procesima i kulturom. Kultura je spor i težak posao, a iako je tradicionalno odgovornost menadžera, svi su uključeni na ovaj ili onaj način, od programera do administratora. Prije nekoliko mjeseci Tim Lister :
“Kultura je određena temeljnim vrijednostima organizacije. Obično ljudi to ne primjećuju, ali budući da smo godinama radili u savjetovanju, navikli smo to primjećivati. Uđete u tvrtku i doslovno za nekoliko minuta počnete osjećati što se događa. To zovemo "okus". Ponekad je ovaj miris stvarno dobar. Ponekad uzrokuje mučninu. (...) Ne možete promijeniti kulturu dok se ne razumiju vrijednosti i uvjerenja koja stoje iza određenih postupaka. Lako je promatrati ponašanje, ali teško je tražiti uvjerenja. DevOps je samo izvrstan primjer kako stvari postaju sve složenije.”
Tu je, naravno, i tehnički dio problema. Ako se vaš novi kôd testira za mjesec dana, ali bude objavljen tek godinu dana kasnije, a fizički ga je nemoguće sve ubrzati, možda nećete biti u skladu s dobrim praksama. Dobre prakse podupiru dobri alati. Na primjer, s idejom Infrastructure-as-Code na umu, možete koristiti bilo što, od AWS CloudFormation i Terraform do Chef-Ansible-Puppet. Sve to treba znati i moći, a to je već poprilična inženjerska disciplina. Važno je ne brkati uzrok s posljedicom: prvo radite prema načelima SRE-a, a tek onda implementirajte ta načela u obliku nekih specifičnih tehničkih rješenja. U isto vrijeme, SRE je vrlo sveobuhvatna metodologija koja vam ne govori kako postaviti Jenkins, već o pet osnovnih principa:
- Poboljšana komunikacija između uloga i odjela
- Prihvaćanje pogrešaka kao sastavnog dijela posla
- Promjene unosite postupno
- Korištenje alata i druge automatizacije
- Mjerenje svega što se izmjeriti može
Ovo nije samo skup izjava, već specifičnost . Na primjer, na putu prihvaćanja pogrešaka morat ćete razumjeti rizike, mjeriti dostupnost i nedostupnost usluga koristeći nešto poput SLI-ja () i SLO (), naučite pisati obdukcije i neka njihovo pisanje ne bude strašno.
U SRE disciplini korištenje alata je samo jedan dio uspjeha, iako važan. Trebamo se stalno tehnički razvijati, gledati što se događa u svijetu i kako to primijeniti u našem radu.
Zauzvrat, Cloud Native rješenja sada su postala vrlo popularna. Kao što je danas definirala Cloud Native Computing Foundation, Cloud Native tehnologije omogućuju organizacijama razvoj i pokretanje skalabilnih aplikacija u današnjim dinamičnim okruženjima, kao što su javni, privatni i hibridni oblaci. Primjeri uključuju spremnike, servisne mreže, mikroservise, nepromjenjivu infrastrukturu i deklarativne API-je. Sve ove tehnike omogućuju labavo povezanim sustavima da ostanu elastični, upravljivi i vrlo vidljivi. Dobra automatizacija omogućuje inženjerima uvođenje velikih promjena često i s predvidljivim rezultatima, a da to ne bude dosadan posao. Sve to podržava hrpa dobro poznatih alata kao što su Docker i Kubernetes.
Ova prilično komplicirana i široka definicija je posljedica činjenice da je područje također prilično složeno. S jedne strane, tvrdi se da bi se nove promjene ovom sustavu trebale jednostavno dodati. S druge strane, shvatiti kako stvoriti neku vrstu kontejnerskog okruženja u kojem labavo povezane usluge žive na softverski definiranoj infrastrukturi i tamo se isporučuju pomoću kontinuiranog CI/CD-a, i oko svega toga izgraditi DevOps prakse - sve to zahtijeva više nego jedan pojesti psa.
Što učiniti sa svim ovim
Svatko te probleme rješava na svoj način: na primjer, možete objaviti normalne natječaje da prekinete začarani krug. Možete shvatiti što riječi kao što su DevOps i Cloud Native znače i koristiti ih ispravno i do točke. Možete se razvijati u DevOps-u i svojim primjerom pokazati prave pristupe.
Radimo konferenciju , što pruža priliku da dublje proniknemo u stvari o kojima smo upravo razgovarali. Za to postoji nekoliko skupina izvješća:
- Procesi i kultura;
- Inženjering pouzdanosti mjesta;
- Izvorni oblak;
Kako odabrati kamo ići? Ovdje postoji jedna suptilna točka. S jedne strane, DevOps je o interakciji i stvarno želimo da prisustvujete prezentacijama iz različitih blokova. S druge strane, ako ste voditelj razvoja koji je došao na konferenciju koncentrirati se na jedan konkretan zadatak, onda vas nitko ne ograničava – očito će ovo biti blok o procesima i kulturi. Ne zaboravite da ćete nakon konferencije imati snimke (nakon što ispunite obrazac za povratne informacije), tako da manje bitna izlaganja uvijek možete pogledati kasnije.
Očito, na samoj konferenciji ne možete ići na tri staze odjednom, pa smo program organizirali na način da svaki termin ima teme za svačiji ukus.
Sve što preostaje je razumjeti što učiniti ako ste DevOps inženjer! Prvo pokušajte odrediti što zapravo radite. Obično ovu riječ vole zvati:
- Programeri koji rade na infrastrukturi. Grupe izvješća o SRE i Cloud Native su najprikladnije za vas.
- Administratori sustava. Ovdje je kompliciranije. DevOops se ne bavi administracijom sustava. Srećom, na internetu postoji mnogo izvrsnih konferencija, knjiga, članaka, videa itd. na temu sistemske administracije. S druge strane, ako ste zainteresirani za razvoj sebe u smislu razumijevanja kulture i procesa, učenja o cloud tehnologijama i detaljima života s Cloud Nativeom, onda bismo vas voljeli vidjeti! Razmislite o ovome: radite administraciju, a što ćete onda? Kako biste izbjegli da se odjednom nađete u neugodnoj situaciji, trebali biste naučiti sada.
Postoji još jedna opcija: ustraješ i nastaviš tvrditi da jesi konkretno DevOps inženjer i ništa drugo, što god to značilo. Onda vas moramo razočarati, DevOops nije konferencija za DevOps inženjere!
Slajd iz u Münchenu
DevOops 2020 Moskva održat će se od 29. do 30. travnja u Moskvi, ulaznice su već dostupne .
Alternativno, možete do 8 veljače. Napominjemo da prilikom ispunjavanja obrasca morate odabrati ciljanu publiku koja će imati najviše koristi od vašeg izvješća (postoji iznenađenje zakopano unutar popisa).
Izvor: www.habr.com