V zadnjem času so tovrstni oglasi zasuli internet. Kljub privlačni plači ne more spregledati, da znotraj pišejo povsem nenavadne stvari. Sprva se domneva, da se 'DevOps' in 'inženir' nekako združita v eno besedo, nato pa sledi naključni seznam zahtev, del katerih je očitno prepisan iz oglasa za sistemskega administratorja.
V tej objavi bi rad nekoliko spregovoril o tem, kako smo prišli do tega, kar je DevOps v resnici, in kaj zdaj s tem narediti.
Tovrstne zaposlitve lahko kritiziramo na različne načine, a dejstvo ostaja dejstvo: je veliko jih in tak je trg trenutno. Organizirali smo DevOps konferenco in odprto izjavljamo: ' — ni za DevOps inženirje'. Tu se bo mnogim zdelo čudno in nenavadno: zakaj se ljudje, ki organizirajo povsem komercialni dogodek, upravljajo proti trgu. Sedaj bomo to razložili.
O kulturi in procesih
Začnimo s tem, da DevOps ni inženirska disciplina. Vse se je začelo s tem, da dosedanja razdelitev vlog ne deluje v dobro kakovosti produktov. Ko programerji samo programirajo, ne želijo slišati nič o testiranju — programska oprema je polna napak. Ko administratorjem ni mar, kako in zakaj je programska oprema napisana — podpora postane pekel.
Na primer, opis razlike med pristopom sistemskega administratorja in SRE k upravljanju storitev, Zanimive raziskave so bile izvedene v okviru — kaže, da najboljših razvijalci na nek način uspejo uvajati nove spremembe v produkcijo hitreje, kot enkrat na uro. Tudi sami ročno testirajo največ 10% (kar se vidi iz Kako jim to uspe? 'Excel ali umri' – pravi eden od naslovov poročila. Za podrobno razpravo o teh statističnih podatkih v kontekstu testiranja se lahko obrnete na glavnega nagovor Barucha Sadogurskega, na drugi naši konferenci, Heisenbug.
'Ko ni soglasja med tovariši,
zadeva ne bo šla naprej,
iz njega ne bo prišlo nič, le mučenje.
Nekega dne so Labod, Raka in Šuka…'
Kako mislite, koji deo web programera zaista razume u kojim uslovima se njihovi aplikacije koriste na produkciji? Koliko njih će otići kod administratora i pokušati da sazna šta će se desiti kada baza padne? A ko će od njih otići kod testerâ i zamoliti ih da ih nauče kako ispravno pisati testove? A tu su još i bezbednjaci, menadžeri proizvoda i mnogo drugih ljudi.
Osnovna ideja DevOps-a je da se uspostavi saradnja između uloga i odeljenja. Pre svega, to se ne postiže nekim složenim softverom, već praksom komunikacije. DevOps je kultura, praksa, metodologija i procesi. Ne postoji takva inženjerska specijalnost koja bi odgovarala na ova pitanja.
Zatvoreni krug
Odakle je onda nastala disciplina 'devops inženjerstva'? Imamo teoriju! DevOps ideje su se pokazale odličnim — toliko odličnim da su postale žrtve svog uspeha. Oko cijele ove teme počeli su se okupljati sumnjivi regruteri i trgovci ljudima, koji imaju svoju specifičnu atmosferu.
Zamislite: juče ste u Himmku pravili šaurmu, a danas ste već važna osoba, senior regruter. Tu je ceo proces traženja i selekcije kandidata, nije jednostavno, treba razumeti. Recimo, šef odeljenja kaže: nađi stručnjaka za X. Doplata je reč 'inženjer' pored X, i stvar rešena. Treba vam Linux? Pa to je sigurno Linux-inženjer, želite DevOps — DevOps-inženjer. Oglas se ne sastoji samo od naslova, već je potrebno napisati neki tekst unutra. Najlakše je napisati skup ključnih reči iz Google-a, koliko ko može da smisli. DevOps se sastoji od dve reči — 'Dev' i 'Ops', znači, treba spojiti ključne reči vezane za programere i administeratore, sve u jednu hrpu. Tako se pojavljuju oglasi o poznavanju 42 programskih jezika i 20 godina korišćenja Kubernetes-a i Swarm-a istovremeno. Radna shema.
Tako je u svesti ljudi ukorenjen besmislen i nemilosrdan imidž nekog superjunaka-'devops-a', koji će svima podesiti deploy na Jenkins-u, i sreća će doći. Ah, kad bi sve bilo tako jednostavno. "A, tako se mogu loviti sistem administratori," misli HR, "reč je moderna, ključne reči su iste, moraju se javiti."
Povpraševanje ustvarja ponudbo, in na te vandalske zaposlitve je priletelo neverjetno število sistemskih administratorjev, ki so spoznali, da lahko delajo vse isto kot prej, a prejemajo več, če se poimenujejo za 'devopse'. Tako kot si prej konfiguriral strežnike preko SSH, jih boš še naprej konfiguriral sam, zdaj pa naj bi to bilo devops-praktika. To je nekakšna zapletena pojavnost, delno povezana z undervalued klasičnimi administracijami in hypeom okoli DevOps, toda na splošno — to, kar imamo, imamo.
Torej imamo povpraševanje in ponudbo. Zaprt krog, ki se samo podpira. S tem se borimo (vključno z ustvarjanjem konference DevOops).
Nedvomno, poleg sistemskih administratorjev, ki so se preimenovali v 'devopse', so tudi drugi udeleženci — na primer, profesionalni SRE-ji ali razvijalci Infrastructure-as-Code.
Kaj ljudje dejansko počnejo v DevOps?
Torej, želite napredovati v učenju in uporabi praks DevOps. Kako to doseči, v katero smer gledati? Očitno ni smiselno slepo slediti priljubljenim ključnim besedam.
Če obstaja delo, ga nekdo mora opravljati. Že smo ugotovili, da to niso 'devops inženirji', kdo torej? Zdi se, da je bolj primerno to formulirati ne v terminologiji delovnih mest, temveč v kontekstu konkretnih smeri dela.
Prvič, lahko se ukvarjate z osrčjem DevOps — procesi in kulturo. Kultura ni nekaj, kar se hitro razvije, in čeprav je to tradicionalno področje odgovornosti voditeljev, so na to kako ali tako vključeni vsi, od programerjev do administratorjev. Pred nekaj meseci je Tim Lister :
"Kultura je določena z osnovnimi vrednotami organizacije. Ljudje tega običajno ne opazijo, vendar smo v svetovanju skozi leta zaslužili to opazovati. Vstopiš v podjetje in dobesedno po nekaj minutah začneš čutiti, kaj se dogaja. To imenujemo 'aroma'. Včasih je ta aroma res dobra. Včasih povzroča slabost. (...) Ne moreš spremeniti kulture, preden so bile prepoznane vrednote in prepričanja, ki stoje za konkretnimi dejanji. Obnašanje je enostavno opazovati, medtem ko je težko iskati prepričanja. DevOps je prav to odličen primer, kako vse postaja vedno bolj zapleteno."
Obstaja tudi tehnični vidik vprašanja. Če vaš nov koda pride na testiranje čez mesec dni, in v izdaji se znajde šele čez leto, ter fizično ni mogoče pospešiti vsega tega - do dobrih praks mogoče ne bo prihodila. Dobre prakse podpirajo dobri instrumenti. Na primer, ob upoštevanju ideje Infrastructure-as-Code, lahko uporabite karkoli, od AWS CloudFormation in Terraform do Chef-Ansible-Puppet. Vse to je treba poznati in znati, in to že predstavljajo inženirsko disciplino. Pomembno je, da ne zmešamo vzroka in posledic: na začetku delate po načelih SRE in šele nato ta načela utelešate v obliki nekaterih specifičnih tehničnih rešitev. Pri tem pa je SRE zelo kompleksna metodologija, ki ne govori o tem, kako nastavite Jenkins, ampak o petih osnovnih načelih:
- Izboljšanje interakcije med vlogami in oddelki
- Sprejemanje napak kot neizogibnega dela dela
- Postopno uvajanje sprememb
- Uporaba orodij in druge avtomatizacije
- Merjenje vsega, kar je mogoče meriti
To ni le nek nabor trditev, temveč konkretno . Na primer, na poti sprejemanja napak se boste morali spoprijeti z tveganji, izmeriti dostopnost in nedostopnost storitev s pomočjo nečesa, kar imenujemo SLI () in SLO (), naučiti se pisati postmortume in poskrbeti, da jih bo mogoče pisati brez strahu.
V disciplini SRE je uporaba orodij le del uspeha, čeprav pomemben. Neprestano se moramo razvijati na tehničnem področju, opazovati, kaj se dogaja po svetu in kako to lahko uporabimo v svojem delu.
Trenutno su rešenja zasnovana na oblaku veoma popularna. Prema savremenom razumevanju Cloud Native Computing Foundation, Cloud Native tehnologije omogućavaju organizacijama da razvijaju i pokreću skalabilne aplikacije u savremenim dinamičnim okruženjima, kao što su javni, privatni i hibridni oblaci. Kao primer možemo navesti kontejneri, servis-mreže, mikroservise, nepromenljivu infrastrukturu i deklarativne API. Sve ove tehnike omogućavaju slabo povezanim sistemima da ostanu elastični, upravljivi i dobro praćeni. Dobra automatizacija omogućava inženjerima da često i sa predvidljivim rezultatima prave velike izmene, ne pretvarajući to u mučan posao. Sve to podržava skup poznatih alata, kao što su Docker i Kubernetes.
Ova prilično složena i obimna definicija proizilazi iz činjenice da je i oblast veoma složena. S jedne strane, tvrdi se da novi zahtevi u ovu sistemsku strukturu treba da se dodaju relativno lako. S druge strane, da bi se razumeo način na koji se stvara određeno kontejnerizovano okruženje u kojem slabo povezane usluge funkcionišu na softverski definišenoj infrastrukturi i isporučuju putem kontinuirane integracije i isporuke (CI/CD), te izgradili DevOps prakse oko svega toga — tu se mora proći kroz mnogo praktičnog iskustva.
Šta uraditi sa svim tim
Svako rešava ove probleme na svoj način: na primer, mogu se objaviti normalne radne ponude kako bi se prekinula zatvorena petlja. Može se istražiti značenje pojmova kao što su DevOps i Cloud Native i koristiti ih ispravno i u pravom kontekstu. Takođe, može se razvijati u DevOps-u i svojim primerom demonstrirati ispravne pristupe.
Organizujemo konferenciju , koja pruža priliku da dublje istražimo teme o kojima smo upravo razgovarali. Za to postoje nekoliko grupa predavanja:
- Procesi i kultura;
- Inženjerstvo pouzdanosti sajta;
- Cloud Native;
Kako izbrati, kam iti? Tukaj je tanek trenutek. Po eni strani je DevOps povezovanje, in zelo želite, da se udeležite predavanj iz različnih blokov. Po drugi strani, če ste vodja razvoja, ki je prišel na konferenco, da se osredotočite na eno posebno nalogo, vas nihče ne omejuje — očitno bo to blok o procesih in kulturi. Ne pozabite, da boste po konferenci imeli na voljo posnetke (po izpolnitvi obrazca za povratne informacije), zato jih boste lahko kadarkoli pogledali kasneje, čeprav niso tako pomembni.
Očitno na sami konferenci ne morete iti hkrati na tri proge, zato program oblikujemo tako, da so v vsakem časovnem bloku teme za vsak okus.
Samo razumeti morate, kaj storiti, če ste DevOps inženir! Najprej poskušajte določiti, s čim se pravzaprav ukvarjate. Običajno s tem izrazom ljubimo imenovati:
- Razvijalce, ki se ukvarjajo z infrastrukturo. Za vas so najbolj primerni sklopi predavanj o SRE in Cloud Native.
- Sistemske administratorje. Tukaj je bolj zapleteno. DevOops ni o sistemskem administriranju. Na srečo obstaja veliko odličnih konferenc, knjig, člankov, videov in podobno o sistemskem administriranju. Po drugi strani, če vas zanima razvoj razumevanja kulture in procesov, študij oblačnih tehnologij in podrobnosti življenja s Cloud Native, vas bomo z veseljem videli! Pomislite na to: ukvarjate se z administracijo, kaj boste počeli naprej? Da se ne bi presenetljivo znašli v neprijetni situaciji, se je smiselno usposabljati že zdaj.
Obstaja še ena možnost: vztrajate in še naprej trdite, da ste natančno DevOps inženir in nikakor drugače, kar koli že to pomeni. Takrat vas moramo razočarati, DevOops ni konferenca za DevOps inženirje!
Slide iz v Münchenu
DevOops 2020 Moskva bo potekala 29-30 aprila v Moskvi, vstopnice so že na voljo .
Poleg tega lahko do 8. februarja. Upoštevajte, da morate pri izpolnjevanju obrazca izbrati ciljno publiko, ki ji bo vaše predavanje prineslo največ koristi (v seznamu je skrit presenečenje).
Izvor: habr.com
