V zadnjem času so tovrstni oglasi preplavili splet. Kljub prijetni plači si človek ne more kaj, da ne bi bil sram, da je notri zapisana divja herezija. Sprva se domneva, da je mogoče "DevOps" in "inženir" nekako zlepiti v eno besedo, nato pa obstaja naključen seznam zahtev, od katerih so nekatere jasno kopirane iz prostega delovnega mesta sistemskega skrbnika.
V tem prispevku bi rad nekaj govoril o tem, kako smo prišli do te točke življenja, kaj DevOps v resnici je in kaj storiti z njim zdaj.
Takšna prosta delovna mesta je mogoče obsojati na vse mogoče načine, a dejstvo ostaja: veliko jih je in trg trenutno deluje tako. Izvedli smo devops konferenco in odkrito izjavljamo: “ - ne za inženirje DevOps." Marsikomu se bo to zdelo nenavadno in divje: zakaj ljudje, ki delajo popolnoma komercialen dogodek, gredo proti trgu. Zdaj bomo vse razložili.
O kulturi in procesih
Začnimo z dejstvom, da DevOps ni inženirska disciplina. Vse se je začelo s tem, da zgodovinsko uveljavljena delitev vlog ne deluje na kakovost izdelkov. Ko programerji samo programirajo, vendar nočejo slišati ničesar o testiranju, je programska oprema polna hroščev. Ko skrbnikom ni vseeno, kako in zakaj je programska oprema napisana, se podpora spremeni v pekel.
Na primer, opis razlike med sistemskim skrbnikom in pristopom SRE k upravljanju storitev . Znotraj so bile opravljene zanimive študije — jasno je, da najboljšim razvijalcem nekako uspe uvesti nove spremembe v produkcijo hitreje kot enkrat na uro. Z rokami testirajo največ 10% (to je razvidno iz ). Kako jim to uspe? "Excel or die", pravi eden od naslovov poročila. Za podrobno razpravo o teh statističnih podatkih v kontekstu testiranja se lahko obrnete na osrednji govor Barucha Sadogurskega na naši drugi konferenci, Heisenbug.
"Ko med tovariši ni soglasja,
Stvari jim ne bodo šle dobro,
In iz tega ne bo nič, samo muke.
Nekoč so bili labod, rak in ščuka ...«
Kateri del spletnih programerjev po vašem mnenju res razume pogoje, pod katerimi se njihove aplikacije uporabljajo v proizvodnji? Koliko jih bo šlo do skrbnikov in poskušalo ugotoviti, kaj se bo zgodilo, če se baza podatkov sesuje? In kdo od njih bo šel do preizkuševalcev in jih prosil, naj jih naučijo pravilno pisati teste? Tu so tudi varnostniki, produktni menedžerji in kup drugih ljudi.
Splošna ideja DevOps je ustvariti sodelovanje med vlogami in oddelki. Prvič, to se ne doseže z neko pametno konfigurirano programsko opremo, ampak s prakso komunikacije. DevOps govori o kulturi, praksah, metodologiji in procesih. Ni inženirske specialnosti, ki bi lahko odgovorila na ta vprašanja.
Začaran krog
Od kod potem disciplina »devops inženiring«? Imamo različico! Ideje DevOps so bile dobre – tako dobre, da so postale žrtve lastnega uspeha. Okoli te teme so se začeli vrteti nekateri sumljivi naborniki in trgovci z ljudmi, ki imajo svoje ozračje.
Predstavljajte si: včeraj ste delali shawarmo v Khimkiju, danes pa ste že velik človek, višji kadrovnik. Obstaja cel proces iskanja in izbire kandidatov, vse ni enostavno, morate razumeti. Recimo, da vodja oddelka reče: poiščite strokovnjaka za X. Xu dodelimo besedo "inženir" in končali smo. Potrebujete Linux? No, to je zagotovo inženir za Linux, če želite DevOps, potem inženir za DevOps. Prosto delovno mesto ni sestavljeno samo iz naslova, ampak mora biti notri vnešeno tudi nekaj besedila. Najlažji način je, da vnesete niz ključnih besed iz Googla, odvisno od vaše domišljije. DevOps je sestavljen iz dveh besed – “Dev” in “Ops”, kar pomeni, da moramo ključne besede, povezane z razvijalci in skrbniki, zlepiti na en kup. Tako se pojavljajo prosta delovna mesta o znanju 42 programskih jezikov in 20 letih uporabe Kubernetes in Swarm hkrati. Delovni diagram.
Tako se je v glavah ljudi ukoreninila nesmiselna in neusmiljena podoba nekega "devopsovega" superjunaka, ki bo vse konfiguriral tako, da se bodo napotili k Jenkinsu in sreča bo prišla. Oh, ko bi le bilo vse tako preprosto. »In tudi tako lahko loviš sistemske skrbnike,« razmišlja HR, »to je modna beseda, ključne besede so enake, naj zajamejo vabo.«
Povpraševanje ustvarja ponudbo in vsa ta prosta delovna mesta v smeti so bila zapolnjena z norim številom sistemskih skrbnikov, ki so spoznali: vse lahko počnete enako kot prej, vendar dobite nekajkrat več, če se imenujete "devops". Tako kot ste konfigurirali strežnike prek SSH ročno enega za drugim, jih boste še naprej konfigurirali, zdaj pa je to menda praksa devops. To je nekakšen kompleksen pojav, delno povezan s podcenjevanjem klasičnih skrbnikov in hype okoli DevOps, a na splošno se je zgodilo, kar se je zgodilo.
Imamo torej ponudbo in povpraševanje. Začaran krog, ki hrani samega sebe. Proti temu se borimo (tudi z ustvarjanjem konference DevOops).
Seveda poleg sistemskih skrbnikov, ki so se preimenovali v "devops", obstajajo tudi drugi udeleženci - na primer profesionalni razvijalci SRE ali Infrastructure-as-Code.
Kaj ljudje počnejo v DevOps (v resnici)
Torej želite napredovati pri učenju in uporabi praks DevOps. Toda kako to storiti, v katero smer pogledati? Očitno se ne bi smeli slepo zanašati na priljubljene ključne besede.
Če je delo, naj ga nekdo opravi. Ugotovili smo že, da to niso “devops inženirji”, kdo pa so potem? Bolj pravilno se zdi, da to ne oblikujemo glede na položaje, ampak glede na posebna področja dela.
Najprej se lahko posvetite srcu DevOps – procesom in kulturi. Kultura je počasen in težaven posel, in čeprav je tradicionalno v pristojnosti menedžerjev, so tako ali drugače vpleteni vsi, od programerjev do administratorjev. Pred nekaj meseci Tim Lister :
»Kulturo določajo temeljne vrednote organizacije. Običajno ljudje tega ne opazimo, vendar smo zaradi dolgoletnega dela v svetovanju navajeni tega opaziti. Vstopite v podjetje in dobesedno v nekaj minutah začnete čutiti, kaj se dogaja. Temu pravimo "okus". Včasih je ta vonj res dober. Včasih povzroča slabost. (...) Ne morete spremeniti kulture, dokler ne razumete vrednot in prepričanj, ki stojijo za določenimi dejanji. Vedenje je lahko opazovati, težko pa je iskanje prepričanj. DevOps je le odličen primer, kako stvari postajajo vse bolj zapletene.«
Seveda obstaja tudi tehnični del zadeve. Če je vaša nova koda testirana v enem mesecu, vendar je izdana šele leto kasneje in je fizično nemogoče vse skupaj pospešiti, morda ne boste ustrezali dobrim praksam. Dobre prakse so podprte z dobrimi orodji. Na primer, z idejo Infrastructure-as-Code v mislih lahko uporabite karkoli, od AWS CloudFormation in Terraform do Chef-Ansible-Puppet. Vse to moraš znati in zmoči, to pa je že kar inženirska disciplina. Pomembno je, da ne zamenjate vzroka s posledico: najprej delate po načelih SRE in šele nato ta načela implementirate v obliki določenih tehničnih rešitev. Hkrati je SRE zelo obsežna metodologija, ki vam ne pove, kako nastaviti Jenkins, ampak približno pet osnovnih načel:
- Izboljšana komunikacija med vlogami in oddelki
- Sprejemanje napak kot sestavni del dela
- Postopno uvajanje sprememb
- Uporaba orodij in druge avtomatizacije
- Merjenje vsega, kar se da izmeriti
To ni samo niz izjav, ampak specifika . Na primer, na poti sprejemanja napak boste morali razumeti tveganja, izmeriti razpoložljivost in nerazpoložljivost storitev z uporabo nečesa, kot je SLI () in SLO (), naučite se pisati posmrtne oznanila in poskrbite, da njihovo pisanje ne bo strašljivo.
V disciplini SRE je uporaba orodij le en del uspeha, čeprav pomemben. Nenehno se moramo tehnično razvijati, gledati, kaj se dogaja v svetu in kako to uporabiti pri svojem delu.
Po drugi strani pa so rešitve Cloud Native postale zelo priljubljene. Kot je danes definirala Cloud Native Computing Foundation, tehnologije Cloud Native organizacijam omogočajo razvoj in izvajanje razširljivih aplikacij v današnjih dinamičnih okoljih, kot so javni, zasebni in hibridni oblaki. Primeri vključujejo vsebnike, storitvena omrežja, mikrostoritve, nespremenljivo infrastrukturo in deklarativne API-je. Vse te tehnike omogočajo, da ohlapno povezani sistemi ostanejo elastični, obvladljivi in zelo opazni. Dobra avtomatizacija omogoča inženirjem, da izvajajo velike spremembe pogosto in s predvidljivimi rezultati, ne da bi bilo to delo. Vse to je podprto s kupom znanih orodij, kot sta Docker in Kubernetes.
Ta precej zapletena in široka opredelitev je posledica dejstva, da je območje tudi precej kompleksno. Po eni strani se trdi, da je treba nove spremembe v ta sistem preprosto dodati. Po drugi strani pa ugotoviti, kako ustvariti nekakšno kontejnersko okolje, v katerem ohlapno povezane storitve živijo na programsko definirani infrastrukturi in se tja dostavljajo z uporabo neprekinjenega CI/CD, ter okoli vsega tega zgraditi prakse DevOps – vse to zahteva več kot en pojesti psa.
Kaj storiti z vsem tem
Te težave vsak rešuje na svoj način: na primer, lahko objavite običajna prosta delovna mesta, da prekinete začaran krog. Ugotovite lahko, kaj pomenita besedi, kot sta DevOps in Cloud Native, ter ju uporabite pravilno in natančno. V DevOps se lahko razvijate in s svojim primerom pokažete prave pristope.
Izvajamo konferenco , ki ponuja priložnost, da se poglobimo v stvari, o katerih smo pravkar govorili. Za to obstaja več skupin poročil:
- Procesi in kultura;
- inženiring zanesljivosti mesta;
- Cloud Native;
Kako izbrati, kam iti? Tukaj je subtilna točka. Po eni strani gre pri DevOps za interakcijo in resnično želimo, da se udeležite predstavitev iz različnih blokov. Po drugi strani pa, če ste vodja razvoja, ki je prišel na konferenco, da se osredotoči na eno specifično nalogo, potem vas nihče ne omejuje - očitno bo to blok o procesih in kulturi. Ne pozabite, da boste po konferenci (po izpolnitvi obrazca za povratne informacije) imeli posnetke, tako da si lahko manj pomembne predstavitve vedno ogledate kasneje.
Jasno je, da na sami konferenci ne morete iti v treh tirih hkrati, zato smo program organizirali tako, da ima vsak termin teme za vsak okus.
Vse kar ostane je razumeti, kaj storiti, če ste DevOps inženir! Najprej poskusite ugotoviti, kaj pravzaprav počnete. Običajno to besedo radi imenujejo:
- Razvijalci, ki delajo na infrastrukturi. Za vas sta najbolj primerni skupini poročil o SRE in Cloud Native.
- Sistemski skrbniki. Tukaj je bolj zapleteno. Pri DevOops ne gre za sistemsko administracijo. Na srečo je na internetu veliko odličnih konferenc, knjig, člankov, video posnetkov itd. na temo sistemske administracije. Po drugi strani pa, če vas zanima razvoj v smislu razumevanja kulture in procesov, spoznavanje tehnologij v oblaku in podrobnosti življenja z Cloud Native, potem vas bomo radi videli! Razmislite o tem: opravljate administracijo in kaj boste potem počeli? Da se ne bi nenadoma znašli v neprijetni situaciji, se morate naučiti zdaj.
Obstaja še ena možnost: vztrajaš in še naprej trdiš, da si natančneje inženir DevOps in nič drugega, karkoli že to pomeni. Potem vas moramo razočarati, DevOops ni konferenca za inženirje DevOps!
Diapozitiv iz v Münchnu
DevOops 2020 Moskva bo potekal od 29. do 30. aprila v Moskvi, vstopnice so že na voljo .
Druga možnost je, da lahko do 8. februarja. Upoštevajte, da morate pri izpolnjevanju obrazca izbrati ciljno skupino, ki ji bo vaše poročilo najbolj koristilo (na seznamu je zakopano presenečenje).
Vir: www.habr.com