Kaj je potrebno, da bo IT podjetje uspešno v letu 2019? Predavatelji na konferencah in srečanjih izrečejo veliko glasnih besed, ki običajnim ljudem niso vedno razumljive. Boj za čas uvajanja, mikrostoritve, opustitev monolita, transformacija DevOps in še veliko, veliko več. Če zavržemo verbalno lepoto in govorimo neposredno in v ruščini, potem se vse skrči na preprosto tezo: naredite visokokakovosten izdelek in to z udobjem za ekipo.
Slednje je postalo kritično pomembno. Podjetje je končno prišlo do zaključka, da udoben razvojni proces poveča produktivnost, in če je vse razhroščeno in deluje kot ura, daje tudi nekaj manevrskega prostora v kritičnih situacijah. Nekoč se je neki pameten človek zavoljo tega manevra domislil rezervnih kopij, a industrija se razvija in prišli smo do inženirjev DevOps - ljudi, ki proces interakcije med razvojem in zunanjo infrastrukturo spremenijo v nekaj ustreznega in ni povezano s šamanizmom.
Celotna ta »modularna« zgodba je čudovita, toda ... Tako se je zgodilo, da so nekatere skrbnike nenadoma poimenovali DevOps, od samih inženirjev DevOps pa so začeli zahtevati vsaj veščine telepatije in jasnovidnosti.
Preden govorimo o sodobnih problemih zagotavljanja infrastrukture, opredelimo, kaj razumemo pod tem pojmom. V tem trenutku se je situacija razvila tako, da smo prišli do dvojnosti tega koncepta: infrastruktura je lahko pogojno zunanja in pogojno notranja.
Z zunanjo infrastrukturo razumemo vse, kar zagotavlja funkcionalnost storitve ali produkta, ki ga ekipa razvija. To so aplikacijski ali spletni strežniki, gostovanje in druge storitve, ki zagotavljajo funkcionalnost izdelka.
Notranja infrastruktura vključuje storitve in opremo, ki jih uporablja sama razvojna ekipa in ostali zaposleni, ki jih je običajno veliko. To so interni strežniki sistemov za shranjevanje kode, lokalno razporejeni upravitelj opravil in vse, vse, vse, kar obstaja znotraj intraneta podjetja.
Kaj dela sistemski skrbnik v podjetju? Poleg dela upravljanja prav tega korporativnega intraneta pogosto nosi breme ekonomskih skrbi za zagotavljanje delovanja pisarniške opreme. Administrator je isti tip, ki bo iz zadnje sobe na hitro zvlekel novo sistemsko enoto ali rezervni prenosni računalnik, pripravljen za uporabo, dal svežo tipkovnico in se po vseh štirih plazil po pisarnah in raztegnil ethernetni kabel. Administrator je lokalni lastnik in vladar ne le notranjih in zunanjih strežnikov, ampak tudi vodja podjetja. Da, nekateri skrbniki lahko delajo samo v sistemski ravnini, brez strojne opreme. Treba jih je ločiti v ločen podrazred »skrbnikov infrastrukturnega sistema«. In nekateri so specializirani za servisiranje izključno pisarniške opreme, na srečo, če ima podjetje več kot sto ljudi, se delo nikoli ne konča. Toda nobeden od njiju ni devops.
Kdo so DevOps? Devops so fantje, ki govorijo o interakciji razvoja programske opreme z zunanjo infrastrukturo. Natančneje, sodobni devops so vključeni v procese razvoja in uvajanja veliko globlje, kot so bili kadar koli vpleteni skrbniki, ki so preprosto naložili posodobitve na ftp. Ena od ključnih nalog inženirja DevOps zdaj je zagotoviti udoben in učinkovito strukturiran proces interakcije med razvojnimi ekipami in infrastrukturo izdelkov. Ti ljudje so odgovorni za uvajanje sistemov za povrnitev in uvajanje; ti ljudje razbremenijo razvijalce in se čim bolj osredotočijo na svojo izjemno pomembno nalogo. Hkrati devops ne bo nikoli napeljal novega kabla ali izdal novega prenosnika iz zadnje sobe (c) KO
V čem je fora?
Na vprašanje "Kdo je DevOps?" polovica delavcev na terenu začne odgovarjati nekaj takega kot "No, skratka, to je admin, ki ..." in naprej v besedilu. Ja, nekoč, ko je poklic DevOps inženirja šele nastajal iz najbolj nadarjenih skrbnikov v smislu vzdrževanja storitev, razlike med njimi niso bile očitne vsem. Toda zdaj, ko sta se funkciji devopsa in admina v ekipi radikalno razlikovali, ju je nesprejemljivo zamenjevati ali celo enačiti.
Toda kaj to pomeni za posel?
Zaposlovanje, to je vse.
Odprete prosto delovno mesto za “Sistemskega skrbnika”, tam pa so navedene zahteve “interakcija z razvojem in strankami”, “sistem dostave CI/CD”, “vzdrževanje strežnikov in opreme podjetja”, “administracija internih sistemov” itd. na; razumete, da delodajalec govori neumnosti. Ulov je v tem, da bi moral biti naziv prostega delovnega mesta namesto »Sistemski administrator« »DevOps Engineer« in če se ta naziv spremeni, se vse postavi na svoje mesto.
Vendar, kakšen vtis človek dobi, ko bere takšno prosto delovno mesto? Da podjetje išče operaterja z več stroji, ki bo uvedel sistem za nadzor različic in nadzor in bo z zobmi stiskal twister ...
Da pa ne bi povečali stopnje zasvojenosti z drogami na trgu dela, je dovolj, da prosta delovna mesta poimenujete s pravimi imeni in jasno razumete, da sta inženir DevOps in sistemski administrator dve različni entiteti. Toda neustavljiva želja nekaterih delodajalcev, da kandidatu predstavijo čim širši seznam zahtev, vodi v dejstvo, da "klasični" sistemski skrbniki ne razumejo, kaj se dogaja okoli njih. Kaj, stroka mutira in so za časom?
Ne ne in še enkrat ne. Infrastrukturni skrbniki, ki bodo upravljali interne strežnike podjetja ali zasedali podporna mesta L2/L3 in pomagali drugim zaposlenim, niso odšli in ne bodo odšli.
Ali lahko ti strokovnjaki postanejo inženirji DevOps? Seveda lahko. Pravzaprav je to sorodno okolje, ki zahteva veščine sistemske administracije, vendar je poleg tega dodano delo z nadzorom, sistemi dostave in na splošno tesno sodelovanje z razvojno in testno ekipo.
Še ena težava DevOps
Pravzaprav vse ni omejeno samo na zaposlovanje in nenehno zmedo med admini in devopsi. Na neki točki se je podjetje soočilo s problemom dostave posodobitev in interakcije razvojne ekipe s končno infrastrukturo.
Morda je bilo takrat, ko je stric z iskrivimi očmi vstal na odru kakšne konference in rekel: »To delamo in temu pravimo DevOps. Ti fantje bodo rešili vse vaše težave« - in začel pripovedovati, kako dobro je življenje v podjetju po uvedbi praks DevOps.
Vendar pa ni dovolj najeti DevOps inženirja, da bo vse delovalo, kot mora. Podjetje mora opraviti popolno transformacijo DevOps, to pomeni, da mora biti vloga in zmogljivosti naših DevOps jasno razumljena tudi s strani ekipe za razvoj in testiranje izdelkov. Na to temo imamo »čudovito« zgodbo, ki v celoti ponazarja vso brutalnost, ki se ponekod dogaja.
Stanje. DevOps je potreben za uvedbo sistema za povrnitev različice, ne da bi se zares poglobili v to, kako bo deloval. Predpostavimo, da so znotraj sistema Uporabniki ločena polja za ime, priimek in geslo. Izide nova različica izdelka, toda za razvijalce je "povratek" samo čarobna paličica, ki bo vse popravila, pa sploh ne vedo, kako deluje. Tako so na primer v naslednjem popravku razvijalci združili polje z imenom in priimkom, ga uvedli v proizvodnjo, vendar je različica iz nekega razloga počasna. Kaj se dogaja? Vodstvo pride do devopsa in reče "Potegnite stikalo!", To pomeni, da ga prosi, naj se vrne na prejšnjo različico. Kaj počne devops? Vrne se na prejšnjo različico, a ker razvijalci niso želeli ugotoviti, kako je bila ta vrnitev izvedena, ekipi devops nihče ni povedal, da je treba tudi bazo podatkov vrniti nazaj. Posledično se nam vse sesuje in namesto počasnega spletnega mesta uporabniki vidijo napako “500”, ker stara verzija ne deluje s polji nove baze. Devops za to ne ve. Razvijalci so tiho. Vodstvo začne izgubljati živce in denar ter se spomni varnostnih kopij in ponudi vrnitev iz njih, da bo "vsaj nekaj delovalo." Posledično uporabniki čez nekaj časa izgubijo vse svoje podatke.
Orehi gredo seveda devopsu, ki "ni naredil pravega sistema za povrnitev nazaj", in nikogar ne briga, da so losi v tej zgodbi razvijalci.
Zaključek je preprost: brez običajnega pristopa k DevOpsu kot takemu je malo uporaben.
Glavna stvar, ki si jo morate zapomniti: DevOps inženir ni čarovnik in brez kakovostne komunikacije in dvosmerne interakcije z razvojem ne bo kos svojim nalogam. Razvijalcev ni mogoče pustiti samih s svojimi »težavami« ali jim dati ukaz »ne vtikajte se v razvijalce, njihova naloga je kodiranje«, nato pa upati, da bo v kritičnem trenutku vse delovalo, kot mora. Tako to ne gre.
V bistvu je DevOps kompetenca na meji med upravljanjem in tehnologijo. Poleg tega še zdaleč ni očitno, da bi moralo biti v tem koktajlu več tehnologije kot upravljanja. Če resnično želite zgraditi hitrejše in učinkovitejše razvojne procese, morate zaupati svoji ekipi devops. Pozna prava orodja, izvajal je podobne projekte, ve, kako to narediti. Pomagajte mu, poslušajte njegove nasvete, ne poskušajte ga izolirati v nekakšno avtonomno enoto. Če lahko skrbniki delajo sami, potem so devops v tem primeru neuporabni; ne bodo vam mogli pomagati, da postanete boljši, če sami ne želite sprejeti te pomoči.
In zadnja stvar: nehajte žaliti skrbnike infrastrukture. Imajo svojo, izjemno pomembno fronto dela. Da, skrbnik lahko postane inženir DevOps, vendar se to mora zgoditi na zahtevo osebe same in ne pod pritiskom. In nič ni narobe, če sistemski skrbnik želi ostati sistemski administrator - to je njegov ločen poklic in njegova pravica. Če želite opraviti poklicno preobrazbo, ne smete nikoli pozabiti, da boste poleg tehnoloških veščin morali nadgraditi tudi vodstvene. Najverjetneje bo na vas kot vodji, da združite vse te ljudi in jih naučite komunicirati v istem jeziku.
Vir: www.habr.com