Kaj je potrebno za uspeh IT-podjetja v letu 2019? Predavatelji na konferencah in meetupih govorijo veliko glasnih in ne vedno razumljivih besed za navadne ljudi. Boj za čas namestitve, mikroservisi, opustitev monolita, transformacija DevOps in še mnogo drugega. Če odmemo besedno umetnost in govorimo preprosto, vse to vodi do enostavnega sporočila: ustvarite kakovosten izdelek in to storite s udobjem za ekipo.
Zadnje je postalo kritično pomembno. Poslovni svet je končno prišel do spoznanja, da udoben proces razvoja povečuje produktivnost, in če je vse urejeno in deluje brezhibno, daje tudi določeno mero svobode v kritičnih situacijah. Včasih je nekdo pameten izumil varnostne kopije, da bi omogočil to svobodo, vendar se industrija razvija, in prišli smo do DevOps inženirjev — ljudi, ki proces sodelovanja med razvojem in zunanjimi infrastrukturnimi storitvami spreminjajo v nekaj razumljivega in ne povezanega s šamanizmom.
Vsa ta zgodba o 'po modulu' je čudovita, a... Tako se je zgodilo, da so nekateri administratorji hitro prešli v DevOps, in od samih DevOps inženirjev se zahtevajo, najmanj, veščine telepatije in jasnovidnosti.
Preden se pogovorimo o sodobnih težavah zagotavljanja infrastrukture, se dogovorimo, kaj pod tem pojmom razumemo. K trenutnemu trenutku se je situacija razvila tako, da smo prišli do dvoumnosti te definicije: infrastruktura je lahko pogojno zunanja in pogojno notranja.
Pod zunanjo infrastrukturo razumemo vse, kar zagotavlja delovanje storitve ali izdelka, ki ga razvija ekipa. To so strežniki aplikacije ali spletne strani, gostovanje in druge storitve, ki zagotavljajo delovanje izdelka.
Notranja infrastruktura vključuje storitve in opremo, ki jo uporablja sama ekipa razvijalcev in drugi zaposleni, katerih običajno ni malo. To so notranji strežniki sistemov za shranjevanje kode, lokalno nameščen upravljalnik nalog in vse, kar obstaja v okviru korporatnega intraneta.
Kaj pa počne sistemski administrator v podjetju? Poleg upravljanja korporativnega intraneta na njem pogosto leži breme skrbi za zagotavljanje delovanja pisarniške opreme. Administrator je tisti tip, ki hitro prinese nov sistem iz skladišča ali pripravljen prenosnik, predaja svežo tipkovnico in se plazi po pisarnah ter vleče Ethernet kabel. Administrator je lokalni gospodar in vladar ne le notranjih in zunanjih strežnikov, ampak tudi poslovnih zadev. Da, nekateri administratorji lahko delujejo le v sistemski ravni, brez strojne opreme. Te je vredno izpostaviti kot posebna podkategorija 'infrastrukturnih sistemskih administratorjev'. Nekateri pa se specializirajo izključno za vzdrževanje pisarniške opreme, kar je dobro, saj, če podjetje zaposluje več kot sto ljudi, dela nikoli ne zmanjka. Ampak niti eni niti drugi niso DevOps.
In kdo so DevOps? DevOps so fantje, ki se ukvarjajo z interakcijo razvoja programske opreme z zunanjimi infrastrukturnimi sistemi. Natančneje, sodobni DevOps so globlje vključeni v procese razvoja in uvajanja kot kdajkoli prej administratori, ki so preprosto nalagali posodobitve na ftp. Ena ključnih nalog DevOps inženirja danes je zagotavljanje udobnega in učinkovito sestavljenega procesa sodelovanja med razvojnimi ekipami in infrastrukturnimi sistemi produkta. Ti ljudje so odgovorni za izvajanje sistemov za vrnitev in uvajanje, ti ljudje odstranjujejo del bremena z razvijalcev in se v največji meri osredotočajo na svojo izjemno pomembno nalogo. Pri tem DevOps nikoli ne bo vlekel novega kabla ali predajal novega prenosnika iz skladišča (c) KO
Kje je trik?
Ko vprašanju „Kaj je DevOps?“ polovica zaposlenih na tem področju začne odgovarjati nekaj v smislu „No, to je, skratka, tako administrator, ki...“ in nato nadaljuje. Da, nekoč, ko je poklic DevOps inženirja le nastajal iz najtalentiranejših administratorjev za vzdrževanje storitev, razlike med njima niso bile očitne. A danes, ko se funkcije devopsa in administratorja v ekipi drastično razlikujejo, je zmeda med njima, pa tudi to, da ju enačimo — nedopustna.
Ampak kaj to pomeni za posel?
Zaposlitev, to je ključ.
Odprete razpis za delovno mesto „Sistemskega administratorja“, in tam so navedene zahteve „sodelovanje z razvojem in naročniki“, „CI/CD sistem“, „vzdrževanje strežnikov in opreme podjetja“, „administracija notranjih sistemov“ in tako naprej; razumete, da delodajalec nosi neko neumnost. Trapastost je v tem, da bi namesto „Sistemskega administratorja“ v naslovu razpisa moralo stati „DevOps inženir“, in če se ta naslov spremeni, potem vse postane jasneje.
Kakšno doživetje pa se ustvari ob branju takega razpisa? Da podjetje išče večpreklopnika, ki bo zagnal sistem za nadzor različic in monitoring ter s svojimi zobmi obdelal vsajeno rožico ...
In ker, da ne bi zvišali temperature delirija na trgu dela, je dovolj, da delovne razpise imenujemo prav in jasno razumemo, da sta DevOps inženir in sistemski administrator dve različni entiteti. A neustavljiva želja nekaterih delodajalcev po predstavitvi čim širšega seznama zahtev kandidatov povzroča, da „klasični“ sistemski administratorji prenehajo razumeti, kaj se dogaja okoli njih. Da, poklic se mutira in oni so zašli iz realnosti?
Ne, ne in še enkrat ne. Infrastrukturni administratorji, ki bodo upravljali notranje strežnike podjetja, ali zasedali mesta L2/L3 podpore in pomagali drugim zaposlenim, nikamor niso šli in se ne nameravajo umakniti.
Ali lahko ti strokovnjaki postanejo DevOps inženirji? Seveda, lahko. V bistvu je to sorodno okolje, ki zahteva veščine sistemskega skrbništva, poleg tega pa vključuje tudi delo z nadzornimi sistemi, sistemi dostave in, na splošno, tesno sodelovanje s skupino za razvoj in testiranje.
Še en problem DevOps-a
Dejansko se težave ne omejujejo samo na zaposlitev in nenehne zmede med skrbniki in devopsi. V nekem trenutku se je podjetje soočilo s problemom dostave posodobitev in sodelovanja razvojne ekipe z končno infrastrukturo.
Morda je to bilo takrat, ko se je na oder neke konference povzpel tip z žarečimi očmi in dejal: 'Mi naredimo tako in temu pravimo DevOps. Ti fantje bodo rešili vse vaše težave' — in začel pripovedovati, kako dobro se živi v podjetju po uvedbi DevOps praks.
Vendar pa ni dovolj, da podjetje zaposli DevOps inženirja, da bi vse delovalo 'kot mora'. Podjetje mora v celoti preiti na DevOps transformacijo, torej morajo biti vloga in zmožnosti našega devopsa jasno priznane tudi v razvojni in testni ekipi. O tej temi imamo 'čudovito' zgodbo, ki v celoti ponazarja vso grozoto, ki se dogaja.
Situacija. Od devopsa se traži da razviju sistem za vraćanje verzija, a da se previše ne udubljuju kako će to raditi. Pretpostavimo da u sistemu Users postoje posebna polja za ime, prezime i lozinku. Dolazi nova verzija proizvoda, ali za programere „vraćanje“ je jednostavno čarobni štapić koji sve popravlja, i oni nemaju predstavu kako to funkcioniše. Na primer, u jednom novom patchu programeri su spojili polja za ime i prezime, uveli to u produkciju, a verzija usporava iz nekog razloga. Šta se događa? Uprava dolazi do devopsa i govori „Povuci prekidač!“, što znači da ga mole da se vrati na prethodnu verziju. Šta radi devops? Vraća se na prethodnu verziju, ali pošto programeri nisu hteli da se upuste u to kako se to vraćanje radi, niko devopsu nije rekao da treba da vrati i bazu podataka. Na kraju, sve nam pada, a korisnici umesto usporenog sajta vide grešku „500“, jer stara verzija ne funkcioniše sa poljima nove baze. Devops o tome nije informisan. Programeri ćute. Uprava počinje da gubi živce i novac i seti se bekapa, predlažući da se vrate sa njih, da „bar nešto funkcioniše“. U rezultat, korisnici gube sve svoje podatke za određeni vremenski period.
Naravno, devops dobija kritike, jer „nije napravio pravi sistem vraćanja“, dok programeri u ovoj priči nikoga ne zanimaju.
Zaključak je jednostavan: bez normalnog pristupa DevOps-u, kao takvom, koristi od njega nisu velike.
Najvažnije što treba zapamtiti jeste da DevOps inženjer nije čarobnjak, i bez kvalitetne komunikacije i dvostrane interakcije s razvojem, neće moći da se nosi sa svojim zadacima. Devopse ne treba ostaviti nasamo sa svojim „problemima“ ili im dati instrukciju „ne zadirkuj razvojnim timom, njihovo je da kodiraju“, a zatim se nadati da će sve raditi ispravno u kritičnom trenutku. Tako to ne funkcioniše.
V bistvu je DevOps kompetenca na meji med menedžmentom in tehnologijo. In daleč od tega, da bi bilo očitno, da bi moralo biti v tem koktejlu tehnologij več kot menedžmenta. Če želite resnično zgraditi hitrejše in učinkovitejše procese razvoja, morate zaupati svojemu DevOpsu. Pozna potrebna orodja, uresničeval je podobne projekte in ve, kako to narediti. Pomagajte mu, prisluhnite njegovim nasvetom, ne poskušajte ga izolirati v nekakšno avtonomno enoto. Če lahko skrbniki delajo sami, so DevOpsi v tem primeru nepotrebni, ne morejo vam pomagati, da postanete boljši, če te pomoči ne želite sprejeti.
In na koncu: prenehajte žaliti infrastrukturne skrbnike. Imajo svoj, izjemno pomemben del dela. Da, skrbnik lahko postane DevOps inženir, vendar se to mora zgoditi po lastni želji, ne pod prisilo. Nič ni narobe s tem, da sistemski administrator želi ostati sistemski administrator — to je njegova posebna poklicna pot in pravica. Če pa je želja po profesionalni transformaciji, je pomembno, da se ne pozabi, da bo treba razvijati ne le tehnološke veščine, temveč tudi vodstvene. Vse te ljudi bo treba združiti in jih naučiti komunicirati v istem jeziku, verjetno pa boste to morali storiti prav vi kot vodja.
Izvor: habr.com
