Kaj je potrebno za uspeh IT-podjetja v letu 2019? Predavatelji na konferencah in meet-upih govorijo veliko močnih in ne vedno razumljivih besed normalnim ljudem. Boj za čas izvajanja, mikroservisi, opustitev monolita, DevOps transformacija in še veliko več. Če odmjerimo besedno lepoto in govorimo jasno, se vse strne v preprost tezo: ustvarite kakovosten izdelek in poskrbite za udobje vaše ekipe med procesom.
To je postalo kritično pomembno. Poslovanje je končno prišlo do spoznanja, da udoben razvojni proces povečuje produktivnost, in če je vse usklajeno in deluje kot ura, daje tudi določeno manevrski prostor v kritičnih situacijah. Nekdanji pametni človek je zaradi tega manevra uvedel varnostne kopije, a industrija napreduje, prišli smo do DevOps inženirjev — ljudi, ki proces sodelovanja razvoja in zunanje infrastrukture preoblikujejo v nekaj smiselnega in ne povezanega s šamanskim delom.
Vsa ta zgodba o „po modulih“ je čudovita, a... Tako se je zgodilo, da so nekateri skrbniki postali DevOps, od samih DevOps inženirjev pa so začeli zahtevati vsaj veščine telepatije in preroštva.
Preden govorimo o sodobnih izzivih zagotavljanja infrastrukture, se opredelimo, kaj pod tem izrazom razumemo. Situacija je trenutno tako, da smo prišli do dvojne narave tega pojma: infrastruktura je lahko poimenovana kot zunanja in notranja.
Pod zunanjo infrastrukturo razumemo vse, kar zagotavlja delovanje storitve ali produkta, s katero se ukvarja ekipa. Sem spadajo strežniki aplikacij ali spletnih strani, gostovanje in druge storitve, ki zagotavljajo delovanje produkta.
Notranja infrastruktura vključuje storitve in opremo, ki jih uporablja sama ekipa razvoja 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 se zaposleni v podjetju ukvarja? Poleg skrbništva nad omrežjem in upravljanja podjetniškega intraneta, so na njegovih ramenih tudi gospodarske skrbi za zagotavljanje delovanja pisarniške opreme. Administrator je tisti fant, ki hitro prinese nov sistem iz skladišča ali delujoč rezervni prenosnik, izda svežo tipkovnico in se plazi po pisarnah s podaljškom Ethernet kabla. Administrator je lokalni gospodar in mojster ne samo notranjih in zunanjih strežnikov, ampak tudi gospodarskih zadev. Da, nekateri administratorji lahko delajo le na sistemski ravni, brez strojne opreme. Te je treba izpostaviti v ločeno podkategorijo "infrastrukturnih sistemskih administratorjev". Nekdo pa se specializira izključno za vzdrževanje pisarniške opreme, kar je še posebej pomembno, če podjetje zaposluje več kot sto ljudi, dela nikoli ne zmanjka. Vendar niti eni niti drugi niso DevOps.
Kdo pa so DevOps? DevOps so fantje, ki se ukvarjajo z interakcijo razvoja programske opreme z zunanjimi infrastrukturalnimi elementi. Natančneje, sodobni DevOps so globlje vključeni v procese razvoja in implementacije kot so bili kdaj koli admini, ki so zgolj nalagali posodobitve na FTP. Ena od ključnih nalog DevOps inženirja danes je zagotavljanje udobno in učinkovito postavljenega procesa sodelovanja med ekipami za razvoj in infrastrukturo izdelka. Ti ljudje so odgovorni za uvajanje sistemov za vračila in implementacijo, ti ljudje razbremenijo razvijalce in se maksimalno osredotočijo na svojo izjemno pomembno nalogo. Pri tem DevOps nikoli ne bo vlekel novega kabla ali izdal novega prenosnika iz skladišča (c) KO
Kje je trik?
Na vprašanje „Kaj je DevOps?“ polovica zaposlenih v panogi začne odgovarjati nekaj takega kot „No, to je, na kratko, tak administrator, ki...“ in tako naprej. Da, nekoč, pred davnimi časi, ko se je poklic DevOps inženirja šele rodil iz najbolj nadarjenih administratorjev za upravljanje storitev, razlike med njimi niso bile očitne. A danes, ko so funkcije devopsa in administratorja v timu postale radikalno drugačne, je nedopustno zamenjevati ju, kaj šele postavljati med njimi znak enakosti.
Toda v kaj to prinaša za podjetje?
Najem, v tem je vse.
Odprli ste razpis za delovno mesto „Sistemski administrator“, tam pa so navedene zahteve „sodelovanje z razvijalci in naročniki“, „CI/CD sistem dostave“, „upravljanje strežnikov in opreme podjetja“, „administracija notranjih sistemov“ in tako naprej; razumete, da delodajalec govori neumnosti. Težava je v tem, da bi v naslovu razpisa namesto „Sistemski administrator“ moralo pisati „DevOps inženir“, in če to spremenite, se vse postavi na svoje mesto.
Kakšen vtis pa ustvarja branje takega razpisa? Da podjetje išče „večopravilca“, ki bo tudi sistem za nadzor različic in nadzor postavil, in s sistemom se bo boril s zobmi…
Da, da, da. Da bi se izognili povečevanju „narkomanije“ na trgu dela, je dovolj, da imenujemo razpise po njihovih pravih imenih in jasno razumemo, da sta DevOps inženir in sistemski administrator dve različni entiteti. A brezobzirna želja nekaterih delodajalcev, da potencialnemu kandidatu postavijo čim širši seznam zahtev, vodi v to, da „klasični“ sistemski administratorji prenehajo razumeti, kaj se dogaja okoli njih. Kaj, poklic se mutira in zaostajajo za življenjem?
Ne, ne in še enkrat ne. Infrastrukturni administratorji, ki bodo upravljali notranje strežnike podjetja ali zasedli mesta L2/L3 podpore in pomagali drugim zaposlenim, nikamor niso izginili in se ne nameravajo umakniti.
Ali lahko ti strokovnjaki postanejo inženirji DevOps? Seveda lahko. V bistvu gre za sorodno področje, ki zahteva znanja sistemskega administriranja, a poleg tega vključuje tudi delo z nadzornimi sistemi, sistemi dostave in predvsem tesno sodelovanje z razvojnimi in testnimi ekipami.
Še en problem DevOps
Dejansko se težave ne končajo le z zaposlovanjem in stalno zmedo med administratorji in devopsovci. V nekem trenutku se je podjetje soočilo s težavo pri dostavi posodobitev in sodelovanju razvojne ekipe z končno infrastrukturo.
Morda je bilo to takrat, ko je na oder neke konference stopil tip z iskrico v očeh in dejal: 'Tako delamo mi in temu pravimo DevOps. Ti fantje bodo rešili vse vaše težave' — in začel pripovedovati, kako dobro je v podjetju po uvedbi DevOps praks.
Vendar pa ni dovolj, da zaposlite inženirja DevOps, da bi vse delovalo 'kot treba'. Podjetje mora opraviti celotno DevOps transformacijo, kar pomeni, da morajo tudi na strani razvojne in testne ekipe jasno razumeti vlogo in sposobnosti našega devopsa. O tem imamo 'čudovito' zgodbo, ki v celoti ponazarja vso občasno divjost, ki se dogaja.
Situacija. Od DevOps-a se zahteva da postavi sistem za vraćanje verzija, bez previše objašnjenja o tome kako bi to trebalo da funkcioniše. Pretpostavimo da unutar sistema Korisnici — postoje posebna polja za ime, prezime i lozinku. Dolazi nova verzija proizvoda, ali za programere "vracanje" je samo čarobna štapica koja sve popravlja, i ne imaju pojma kako to funkcioniše. Dakle, na primer, programeri su u poslednjem patch-u spojili polja imena i prezimena, izbacili to u produkciju, a verzija usporava iz nekog razloga. Šta se dešava? Menadžment dolazi do DevOps-a 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 želeli da se bave tim kako se to vraćanje vrši, niko DevOps-u nije rekao da treba da vrati i bazu. Na kraju imamo totalan ruš, i korisnici umesto usporene stranice vide grešku "500", jer stara verzija ne funkcioniše sa poljima nove baze. DevOps o tome ne zna. Programeri ćute. Menadžment počinje da gubi živce i novac i priseća se baken, predlažući da se vrati na njih, da bi "bar nešto radilo". Kao rezultat, korisnici gube sve svoje podatke za određeni vremenski period.
Naravno, najviše uvek strada DevOps, koji "nije napravio pravi sistem vraćanja", dok programeri u ovoj priči nikoga ne zanimaju.
Zaključak je jednostavan: bez normalnog pristupa DevOps-u, nema mnogo koristi od njega.
Najvažnije što treba zapamtiti: DevOps inženjer nije čarobnjak, i bez kvalitetne komunikacije i obostrane interakcije sa razvojem, neće moći da se nosi sa svojim zadacima. DevOps-ovi ne mogu ostati sami sa svojim "problemima" ili dobiti nalog "ne mešaj se u rad programera, njihovo je da kodiraju", a zatim se nadati da će u kritičnom trenutku sve funkcionisati kako treba. To jednostavno ne funkcioniše.
Dejansko, DevOps predstavlja kompetence na meji med managementom in tehnologijami. Pri tem ni očitno, da bi v tem koktajlu tehnologij moralo biti več kot managementa. Če želite resnično zgraditi hitrejše in učinkovitejše procese razvoja, morate zaupati svojemu DevOpsu. Pozna potrebna orodja, je izvajal podobne projekte in ve, kako delati. Pomagajte mu, poslušajte njegove nasvete, ne poskušajte ga izolirati v neke vrste avtonomno enoto. Če lahko skrbniki delujejo sami, potem so DevOpsi v tem primeru nepotrebni, ne bodo vam mogli pomagati, da postanete boljši, če ne boste želeli sprejeti te pomoči.
In zadnje: prenehajte užaljevati skrbnike infrastrukture. Imajo svoj, izjemno pomemben del dela. Da, skrbnik lahko postane DevOps inženir, vendar se to mora zgoditi po lastni želji posameznika, ne pa pod prisilo. Nič ni narobe, če želi sistemski skrbnik ostati sistemski skrbnik — to je njegova posebna poklica in njegove pravice. Če pa želite opraviti profesionalno transformacijo, morate v nobenem primeru ne pozabiti, da boste morali razvijati ne le tehnološke sposobnosti, temveč tudi vodstvene. Vse te ljudi boste morali združiti in jih naučiti, da komunicirajo v istem jeziku, kar boste verjetno morali storiti vi kot vodja.
Izvor: habr.com
