Nedavno su ovakve reklame preplavile internet. Uprkos prijatnoj plati, ne može se ne postiditi što je unutra upisana divlja jeres. U početku se pretpostavlja da se „DevOps“ i „inženjer“ mogu nekako spojiti u jednu riječ, a zatim slijedi nasumična lista zahtjeva, od kojih su neki jasno kopirani sa upražnjenog mjesta za sisadmin.
U ovom postu želeo bih da pričam malo o tome kako smo došli do ove tačke života, šta je DevOps zapravo i šta da radimo sa njim sada.
Ovakva slobodna radna mjesta mogu se osuđivati na svaki mogući način, ali činjenica ostaje: ima ih mnogo, a tržište trenutno funkcionira tako. Održali smo devops konferenciju i otvoreno izjavljujemo: “ - nije za DevOps inženjere." Ovo će mnogima izgledati čudno i divlje: zašto ljudi koji rade potpuno komercijalni događaj idu protiv tržišta. Sad ć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 funkcionira na kvalitetu proizvoda. Kada programeri samo programiraju, ali ne žele da čuju ništa o testiranju, softver je prepun grešaka. Kada administratore nije briga kako i zašto je softver napisan, podrška se pretvara u pakao.
Na primjer, opisivanje razlike između administratora sistema i SRE pristupa upravljanju uslugama . Zanimljive studije su sprovedene unutar — jasno je da najbolji programeri nekako uspijevaju implementirati nove promjene u produkciju 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štaja. Za detaljnu raspravu o ovim statistikama u kontekstu testiranja, možete pogledati glavnu riječ Baruha Sadogurskog na našoj drugoj konferenciji, Heisenbug.
„Kada nema dogovora među drugovima,
Stvari im neće ići dobro,
I ništa neće izaći iz toga, samo muka.
Jednom davno labud, rak i štuka..."
Šta mislite, koji dio web programera stvarno razumije uvjete pod kojima se njihove aplikacije koriste u produkciji? Koliko će njih otići do administratora i pokušati shvatiti šta će se dogoditi ako se baza podataka sruši? I ko će od njih otići do testera i zamoliti ih da ih nauče kako pravilno pišu testove? A tu su i zaštitari, menadžeri proizvoda i gomila 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 su bile dobre - toliko dobre da su postale žrtve vlastitog uspjeha. Neki sumnjivi regruteri i trgovci ljudima, koji imaju svoju atmosferu, počeli su da se vrte oko cijele ove teme.
Zamislite: juče ste pravili shawarmu u Khimkiju, a danas ste već veliki čovjek, stariji regruter. Postoji cijeli proces traženja i odabira kandidata, sve nije lako, treba razumjeti. Recimo da šef odjela kaže: pronađite stručnjaka za X. Dodijelimo riječ "inženjer" X i gotovi smo. Trebate Linux? Pa, ovo je definitivno Linux inženjer, ako želite DevOps, onda DevOps inženjer. Konkurs se ne sastoji samo od naslova, već se mora uneti i neki tekst. Najlakši način je da unesete skup ključnih riječi iz Google-a, ovisno o vašoj mašti. DevOps se sastoji od dvije riječi – “Dev” i “Ops”, što znači da moramo zalijepiti ključne riječi koje se odnose na programere i administratore sve u jednu gomilu. Ovako se pojavljuju slobodna radna mjesta 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 određenog "devops" superheroja, koji će sve konfigurirati da se rasporede kod Dženkinsa i sreća će doći. Oh, kad bi bar sve bilo tako jednostavno. „A ovo je i način na koji možete uloviti sistem administratore“, misli HR, „to je moderna riječ, ključne riječi su iste, oni bi trebali uhvatiti mamac“.
Potražnja stvara ponudu, a sva ova slobodna mjesta za smeće popunjena su suludim brojem sistemskih administratora koji su shvatili: sve možete učiniti isto kao i prije, ali dobijete nekoliko puta više nazivajući sebe "devops". Kao što ste konfigurisali servere preko SSH ručno jedan po jedan, nastavićete da ih konfigurišete, ali sada je ovo navodno devops praksa. Ovo je neka vrsta kompleksnog fenomena, dijelom vezan uz potcjenjivanje klasičnih admina i hype oko DevOpsa, ali generalno, dogodilo se ono što se dogodilo.
Dakle, imamo ponudu i potražnju. Začarani krug koji se hrani. To je ono protiv čega se borimo (uključujući stvaranje DevOops konferencije).
Naravno, pored sistemskih administratora koji su se preimenovali u “devops”, postoje i drugi učesnici – na primjer, profesionalni SRE ili programeri infrastrukture kao koda.
Šta ljudi rade u DevOps-u (zaista)
Dakle, želite da napredujete u učenju i primeni DevOps praksi. Ali kako to učiniti, u kojem smjeru gledati? Očigledno, ne biste se trebali slijepo oslanjati na popularne ključne riječi.
Ako postoji posao, neko bi ga trebao obaviti. Već smo saznali da to nisu „devops inženjeri“, ko su onda? Čini se ispravnijim to formulirati ne u smislu pozicija, već u smislu specifičnih područja rada.
Prvo, možete se pozabaviti srži DevOps-a – procesima i kulturom. Kultura je spor i težak posao, i iako je tradicionalno odgovornost menadžera, svi su na ovaj ili onaj način uključeni, od programera do administratora. Prije par mjeseci Tim Lister :
“Kultura je određena osnovnim vrijednostima organizacije. Ljudi to obično ne primjećuju, ali budući da smo godinama radili u konsaltingu, navikli smo da to primjećujemo. Uđete u kompaniju i bukvalno za nekoliko minuta počnete da osjećate šta se dešava. Mi to zovemo "ukus". Ponekad je ovaj miris zaista dobar. Ponekad izaziva mučninu. (...) Ne možete promijeniti kulturu dok se ne shvate vrijednosti i uvjerenja iza određenih akcija. Ponašanje je lako uočiti, ali je teško tražiti vjerovanja. DevOps je samo odličan primjer kako stvari postaju sve složenije.”
Naravno, postoji i tehnički dio problema. Ako se vaš novi kod testira za mjesec dana, ali bude objavljen tek godinu dana kasnije, a fizički je nemoguće sve to ubrzati, možda nećete biti u skladu s dobrim praksama. Dobre prakse su podržane dobrim alatima. Na primjer, s idejom Infrastructure-as-Code na umu, možete koristiti bilo šta, od AWS CloudFormation i Terraform do Chef-Ansible-Puppet. Sve ovo morate znati i umjeti, a to je već prilično inženjerska disciplina. Važno je ne brkati uzrok sa posljedicom: prvo radite po principima SRE pa tek onda implementirate ove principe u obliku nekih specifičnih tehničkih rješenja. Istovremeno, SRE je vrlo sveobuhvatna metodologija koja vam ne govori kako da postavite Jenkinsa, već o pet osnovnih principa:
- Poboljšana komunikacija između uloga i odjela
- Prihvatanje grešaka kao sastavnog dela posla
- Pravljenje promjena postepeno
- Korištenje alata i druge automatizacije
- Mjerenje svega što se može izmjeriti
Ovo nije samo neki skup izjava, već konkretan . Na primjer, na putu prihvatanja grešaka, morat ćete razumjeti rizike, izmjeriti dostupnost i nedostupnost usluga koristeći nešto poput SLI () i SLO (), naučite pisati obdukcije i učinite da njihovo pisanje ne bude strašno.
U SRE disciplini, upotreba alata je samo jedan dio uspjeha, iako važan. Moramo se stalno tehnički razvijati, gledati šta se dešava u svijetu i kako se to može primijeniti u našem radu.
Zauzvrat, Cloud Native rješenja su sada postala vrlo popularna. Kako je danas definirala Cloud Native Computing Foundation, Cloud Native tehnologije omogućavaju organizacijama da razvijaju i pokreću skalabilne aplikacije u današnjim dinamičkim okruženjima, kao što su javni, privatni i hibridni oblaci. Primjeri uključuju kontejnere, servisne mreže, mikroservise, nepromjenjivu infrastrukturu i deklarativne API-je. Sve ove tehnike omogućavaju da labavo povezani sistemi ostanu elastični, upravljivi i vrlo uočljivi. Dobra automatizacija omogućava inženjerima da prave velike promjene često i sa predvidljivim rezultatima, a da to ne predstavlja napor. Sve ovo je podržano gomilom dobro poznatih alata kao što su Docker i Kubernetes.
Ova prilično složena i široka definicija je zbog činjenice da je područje također prilično složeno. S jedne strane, tvrdi se da bi nove promjene ovom sistemu trebalo jednostavno dodati. S druge strane, shvatiti kako stvoriti neku vrstu kontejneriziranog okruženja u kojem labavo povezane usluge žive na softverski definiranoj infrastrukturi i tamo se isporučuju koristeći kontinuirani CI/CD, te izgraditi DevOps prakse oko svega toga - sve to zahtijeva više nego jesti psa.
Šta učiniti sa svim tim
Svako rješava ove probleme na svoj način: na primjer, možete objaviti normalne konkurse da biste prekinuli začarani krug. Možete shvatiti što znače riječi kao što su DevOps i Cloud Native i koristiti ih ispravno i precizno. Možete se razvijati u DevOps-u i svojim primjerom pokazati prave pristupe.
Pravimo konferenciju , što pruža priliku da se dublje udubimo u stvari o kojima smo upravo razgovarali. Za to postoji nekoliko grupa izvještaja:
- Procesi i kultura;
- Inženjering pouzdanosti lokacije;
- Cloud Native;
Kako odabrati gdje ići? Postoji suptilna tačka. S jedne strane, DevOps se odnosi na interakciju i zaista želimo da prisustvujete prezentacijama iz različitih blokova. S druge strane, ako ste razvojni menadžer koji je došao na konferenciju da se koncentriše na jedan konkretan zadatak, onda vas niko ne ograničava - očigledno, ovo će biti blok o procesima i kulturi. Ne zaboravite da ćete nakon konferencije imati snimke (nakon popunjavanja obrasca za povratne informacije), tako da kasnije uvijek možete pogledati manje važne prezentacije.
Očigledno, na samoj konferenciji ne možete ići na tri staze odjednom, pa program organizujemo na način da svaki termin ima teme za svačiji ukus.
Ostaje samo da shvatite šta da radite ako ste DevOps inženjer! Prvo pokušajte da odredite šta zapravo radite. Obično vole da zovu ovu reč:
- Programeri koji rade na infrastrukturi. Grupe izvještaja o SRE i Cloud Native su najprikladnije za vas.
- Sistemski administratori. Ovde je sve komplikovanije. DevOops se ne bavi sistemskom administracijom. Srećom, na internetu postoji mnogo odličnih konferencija, knjiga, članaka, video zapisa 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 Native-om, onda bismo vas voljeli vidjeti! Razmislite o ovome: vi radite administraciju, a šta ćete onda? Kako biste izbjegli da se iznenada nađete u neugodnoj situaciji, naučite sada.
Postoji još jedna opcija: ustrajete i nastavite da tvrdite da jeste konkretno DevOps inženjer i ništa drugo, šta god to značilo. Onda vas moramo razočarati, DevOops nije konferencija za DevOps inženjere!
Slide from u Minhenu
DevOops 2020 Moskva će se održati od 29. do 30. aprila u Moskvi, ulaznice su već dostupne .
Alternativno, možete do 8. februara. Imajte na umu da prilikom popunjavanja obrasca morate odabrati ciljnu publiku koja će imati najviše koristi od vašeg izvještaja (u listi je zakopano iznenađenje).
izvor: www.habr.com