DevOps je v zadnjih nekaj letih postal zelo priljubljena tema. Marsikdo sanja, da bi se mu pridružil, vendar, kot kaže praksa, pogosto le zaradi višine plač.
Nekateri ljudje navedejo DevOps v svojem življenjepisu, čeprav ne poznajo vedno bistva izraza. Nekateri mislijo, da boste po študiju Ansible, GitLab, Jenkins, Terraform in podobnih (seznam lahko nadaljujete po svojem okusu) takoj postali "devopsist". To seveda ne drži.
Zadnjih nekaj let se ukvarjam predvsem z implementacijo DevOps v različnih podjetjih. Pred tem je več kot 20 let delal na položajih od sistemskega skrbnika do direktorja informatike. Trenutno vodilni inženir DevOps pri Playgendary.
Kdo je DevOps
Ideja za pisanje članka je nastala po drugem vprašanju: "kdo je DevOps?" Še vedno ni ustaljenega izraza za to, kaj ali kdo je. Nekateri odgovori so že v tem . Najprej bom izpostavil glavne točke iz njega, nato pa bom delil svoja opažanja in misli.
DevOps ni strokovnjak, ki bi ga lahko najeli, ne niz pripomočkov in ne oddelek razvijalcev z inženirji.
DevOps je filozofija in metodologija.
Z drugimi besedami, to je nabor praks, ki razvijalcem pomaga pri aktivni interakciji s sistemskimi skrbniki. Se pravi povezovati in integrirati delovne procese enega v drugega.
S pojavom DevOps so struktura in vloge strokovnjakov ostale enake (so razvijalci, so inženirji), spremenila pa so se pravila interakcije. Meje med resorji so se zabrisale.
Cilje DevOps lahko opišemo v treh točkah:
- Programsko opremo je treba redno posodabljati.
- Programsko opremo je treba narediti hitro.
- Programsko opremo je treba namestiti priročno in v kratkem času.
Za DevOps ni enotnega orodja. Konfiguriranje, dobava in preučevanje več izdelkov ne pomeni, da se je DevOps pojavil v podjetju. Orodij je veliko in vsa se uporabljajo na različnih stopnjah, vendar služijo istemu namenu.
In to je le del orodij DevOps
Že več kot 2 leti sem intervjuval ljudi za položaj DevOps inženirja in spoznal sem, kako pomembno je jasno razumeti bistvo pojma. Nabral sem si konkretne izkušnje, opažanja in misli, ki jih želim deliti.
Iz izkušenj z intervjujem vidim naslednjo sliko: strokovnjaki, ki menijo, da je DevOps poklicni naziv, imajo običajno nesporazume s kolegi.
Bil je osupljiv primer. Mladenič je prišel na razgovor z veliko pametnimi besedami v življenjepisu. V zadnjih treh službah je imel 5-6 mesecev izkušenj. Dva startupa sem zapustil, ker »nista zaživela«. Toda o tretjem podjetju je rekel, da ga tam nihče ne razume: razvijalci pišejo kodo v sistemu Windows, direktor pa prisili, da se ta koda "zavije" v običajni Docker in integrira v cevovod CI/CD. Tip je povedal veliko negativnih stvari o svojem trenutnem delovnem mestu in svojih sodelavcih - hotel sem samo odgovoriti: "Torej ne boste prodali slona."
Nato sem mu zastavil vprašanje, ki je pri vsakem kandidatu visoko na mojem seznamu.
— Kaj vam osebno pomeni DevOps?
- Na splošno ali kako jaz to dojemam?
Zanimalo me je njegovo osebno mnenje. Poznal je teorijo in izvor izraza, vendar se z njima močno ni strinjal. Verjel je, da je DevOps poklicni naziv. Tu je korenina njegovih težav. Pa tudi drugi specialisti enakega mnenja.
Delodajalci, ki so slišali veliko o "čarovniji DevOps", želijo najti osebo, ki bo prišla in ustvarila to "čarovnijo". In kandidati iz kategorije »DevOps je delo« ne razumejo, da s tem pristopom ne bodo mogli izpolniti pričakovanj. In na splošno so v življenjepis napisali DevOps, ker je to trend in za to veliko plačajo.
Metodologija in filozofija DevOps
Metodologija je lahko teoretična in praktična. V našem primeru je to drugo. Kot sem omenil zgoraj, je DevOps nabor praks in strategij, ki se uporabljajo za doseganje zastavljenih ciljev. In v vsakem primeru, odvisno od poslovnih procesov podjetja, se lahko bistveno razlikuje. Kar pa ne pomeni boljšega ali slabšega.
Metodologija DevOps je le sredstvo za doseganje ciljev.
Zdaj pa o tem, kaj je filozofija DevOps. In to je verjetno najtežje vprašanje.
Precej težko je oblikovati kratek in jedrnat odgovor, ker še ni formaliziran. In ker se privrženci filozofije DevOps bolj ukvarjajo s prakso, preprosto ni časa za filozofiranje. Vendar je to zelo pomemben proces. Poleg tega je neposredno povezana z inženirskimi dejavnostmi. Obstaja celo specializirano področje znanja - .
Na moji univerzi tega predmeta ni bilo, vse sem moral študirati sam z materiali, ki sem jih našel v 90. letih. Tema je neobvezna za inženirsko izobraževanje, zato odgovor ni formaliziran. Toda tisti ljudje, ki so resno potopljeni v DevOps, začnejo čutiti določen "duh" ali "nezavedno celovitost" vseh procesov podjetja.
Na podlagi lastnih izkušenj sem poskušal formalizirati nekatere »postulate« te filozofije. Rezultat je naslednji:
- DevOps ni nekaj neodvisnega, kar bi lahko ločili v ločeno področje znanja ali dejavnosti.
- Vse zaposlene v podjetju bi morali pri načrtovanju svojih dejavnosti voditi metodologija DevOps.
- DevOps vpliva na vse procese v podjetju.
- DevOps obstaja, da zmanjša časovne stroške za vse procese v podjetju, da zagotovi razvoj svojih storitev in maksimalno udobje strank.
- DevOps, v sodobnem jeziku, je proaktivna pozicija vsakega zaposlenega v podjetju, namenjena zmanjšanju časovnih stroškov in izboljšanju kakovosti IT produktov okoli nas.
Mislim, da so moji "postulati" posebna tema za razpravo. Toda zdaj je treba na čem graditi.
Kaj počne DevOps
Ključna beseda pri tem je komunikacija. Obstaja veliko komunikacij, katerih pobudnik bi moral biti točno isti DevOps inženir. Zakaj? Kajti to je filozofija in metodologija, šele nato inženirsko znanje.
O zahodnem trgu dela ne morem govoriti s 100-odstotnim zaupanjem. Vem pa precej o trgu DevOps v Rusiji. Poleg stotih intervjujev sem v zadnjem letu in pol sodeloval pri stotinah tehničnih predprodaj za storitev »Implementation of DevOps« za velika ruska podjetja in banke.
V Rusiji je DevOps še zelo mlada, a že trendovska tema. Kolikor vem, je samo v Moskvi leta 2019 pomanjkanje takih strokovnjakov znašalo več kot 1000 ljudi. In beseda Kubernetes za delodajalce je skoraj kot rdeča krpa za bika. Privrženci tega orodja so ga pripravljeni uporabiti tudi tam, kjer to ni potrebno in ekonomsko donosno. Delodajalec ne razume vedno, v katerih primerih je primerneje uporabiti, in s pravilno uvedbo vzdrževanje gruče Kubernetes stane 2-3 krat več kot uvedba aplikacije z uporabo običajne sheme gruče. Uporabite ga tam, kjer ga res potrebujete.
Implementacija DevOps je drago v smislu denarja. In je upravičen le tam, kjer prinaša gospodarske koristi na drugih področjih, ne pa sam.
Inženirji DevOps so pravzaprav pionirji – oni so tisti, ki bi morali prvi implementirati to metodologijo v podjetje in graditi procese. Da bi bilo to uspešno, mora strokovnjak nenehno komunicirati z zaposlenimi in sodelavci na vseh ravneh. Kot običajno pravim, bi morali v proces implementacije DevOps sodelovati vsi zaposleni v podjetju: od čistilke do direktorja. In to je predpogoj. Če najmlajši član ekipe ne ve in ne razume, kaj je DevOps in zakaj se izvajajo določeni organizacijski ukrepi, potem uspešna implementacija ne bo delovala.
Poleg tega mora inženir DevOps občasno uporabiti administrativni vir. Na primer za premagovanje »odpora okolja« – ko ekipa ni pripravljena sprejeti orodij in metodologije DevOps.
Razvijalec naj piše samo kodo in teste. Za to ne potrebuje super zmogljivega prenosnika, na katerem bo namestil in lokalno podpiral celotno infrastrukturo projekta. Na primer, front-end razvijalec hrani vse elemente aplikacije na svojem prenosniku, vključno z bazo podatkov, emulatorjem S3 (minio) itd. To pomeni, da veliko časa porabi za vzdrževanje te lokalne infrastrukture in se sam bori z vsemi težavami takšne rešitve. Namesto razvijanja kode za sprednjo stran. Takšni ljudje so lahko zelo odporni na kakršne koli spremembe.
Toda obstajajo ekipe, ki nasprotno z veseljem uvajajo nova orodja in metode ter aktivno sodelujejo v tem procesu. Čeprav tudi v tem primeru komunikacija med inženirjem DevOps in ekipo ni bila preklicana.
Ko DevOps ni potreben
Obstajajo situacije, ko DevOps ni potreben. To je dejstvo – treba ga je razumeti in sprejeti.
Najprej to velja za vsa podjetja (zlasti mala podjetja), ko njihov dobiček ni neposredno odvisen od prisotnosti ali odsotnosti IT izdelkov, ki strankam zagotavljajo informacijske storitve. In tukaj ne govorimo o spletni strani podjetja, pa naj bo to statična "vizitka" ali z dinamičnimi bloki novic itd.
DevOps je potreben, ko je zadovoljstvo vaše stranke in njegova želja, da se ponovno vrne k vam, odvisna od razpoložljivosti teh informacijskih storitev za interakcijo s stranko, njihove kakovosti in ciljanja.
Osupljiv primer je ena dobro znana banka. Podjetje nima običajnih pisarn za stranke, pretok dokumentov poteka preko pošte ali kurirjev, veliko zaposlenih pa dela od doma. Podjetje ni več le banka in se je po mojem mnenju spremenilo v IT podjetje z razvitimi tehnologijami DevOps.
Številne druge primere in predavanja najdete v posnetkih tematskih srečanj in konferenc. Nekatere sem obiskal osebno - to je zelo koristna izkušnja za tiste, ki se želijo razvijati v tej smeri. Tu so povezave do YouTube kanalov z dobrimi predavanji in gradivi o DevOps:
Poglejte zdaj svoje podjetje in razmislite o tem: Koliko sta vaše podjetje in njegov dobiček odvisen od izdelkov IT, ki omogočajo interakcijo s strankami?
Če vaše podjetje prodaja ribe v majhni trgovini in sta edini IT produkt dve konfiguraciji 1C: Enterprise (Računovodstvo in UNF), potem nima smisla govoriti o DevOps.
Če delate v velikem trgovskem in proizvodnem podjetju (na primer proizvajate lovske puške), potem bi morali razmisliti o tem. Lahko prevzamete pobudo in svojemu vodstvu posredujete možnosti za implementacijo DevOps. No, in hkrati vodite ta proces. Proaktivna pozicija je eno od pomembnih načel filozofije DevOps.
Velikost in obseg letnega finančnega prometa nista glavno merilo za ugotavljanje, ali vaše podjetje potrebuje DevOps.
Predstavljajmo si veliko industrijsko podjetje, ki ne komunicira neposredno s strankami. Na primer nekateri proizvajalci avtomobilov in podjetja za proizvodnjo avtomobilov. Zdaj nisem prepričan, toda iz mojih preteklih izkušenj je več let vsa interakcija s strankami potekala prek e-pošte in telefona.
Njihove stranke so omejen seznam trgovcev z avtomobili. In vsakemu je dodeljen strokovnjak proizvajalca. Ves notranji pretok dokumentov poteka prek SAP ERP. Notranji zaposleni so v bistvu odjemalci informacijskega sistema. Toda ta IS je nadzorovan s klasičnimi načini upravljanja gručnih sistemov. Kar izključuje možnost uporabe praks DevOps.
Od tod sklep: za takšna podjetja implementacija DevOps ni nekaj kritično pomembnega, če se spomnimo ciljev metodologije z začetka članka. Vendar ne izključujem, da danes uporabljajo nekatera orodja DevOps.
Po drugi strani pa obstaja veliko malih podjetij, ki razvijajo programsko opremo z uporabo metodologije, filozofije, praks in orodij DevOps. In verjamejo, da so stroški implementacije DevOps stroški, ki jim omogočajo učinkovito konkuriranje na trgu programske opreme. Primere takšnih podjetij je mogoče videti .
Glavno merilo za razumevanje, ali je DevOps potreben: kakšno vrednost imajo vaši izdelki IT za podjetje in stranke.
Če je glavni izdelek podjetja, ki ustvarja dobiček, programska oprema, potrebujete DevOps. In ni tako pomembno, če zaslužite pravi denar z drugimi izdelki. Sem spadajo tudi spletne trgovine ali mobilne aplikacije z igrami.
Vse igre obstajajo zaradi financiranja: neposrednega ali posrednega s strani igralcev. Pri Playgendary razvijamo brezplačne mobilne igre, pri čemer je več kot 200 ljudi neposredno vključenih v njihovo ustvarjanje. Kako uporabljamo DevOps?
Da, popolnoma enako, kot je opisano zgoraj. Nenehno komuniciram z razvijalci in testerji ter izvajam interna izobraževanja za zaposlene o metodologiji in orodjih DevOps.
Zdaj aktivno uporabljamo Jenkins kot orodje za cevovode CI/CD za izvajanje vseh cevovodov za sestavljanje z Unity in poznejšo uvedbo v App Store in Play Market. Več iz klasičnega kompleta orodij:
- Asana - za vodenje projektov. Integracija z Jenkinsom je bila konfigurirana.
- Google Meet – za video srečanja.
- Slack - za komunikacijo in različna opozorila, vključno z obvestili Jenkinsa.
- Atlassian Confluence - za dokumentacijo in skupinsko delo.
Naši takojšnji načrti vključujejo uvedbo statične analize kode z uporabo SonarQube in izvajanje avtomatiziranega testiranja uporabniškega vmesnika z uporabo Seleniuma na stopnji neprekinjene integracije.
Namesto zaključka
Zaključil bi z naslednjo mislijo: če želite postati visoko kvalificiran DevOps inženir, se je nujno naučiti komunicirati z ljudmi v živo.
Inženir DevOps je timski igralec. In nič drugega. Pobuda pri komuniciranju s sodelavci naj prihaja od njega in ne pod vplivom nekaterih okoliščin. Strokovnjak za DevOps mora videti in predlagati najboljšo rešitev za ekipo.
In ja, implementacija katerekoli rešitve bo zahtevala veliko razprav, do konca pa se lahko tudi popolnoma spremeni. Takšna oseba, ki se samostojno razvija, predlaga in udejanja svoje ideje, postaja vedno večja vrednost tako za kolektiv kot za delodajalca. Kar se na koncu odraža v višini njegovega mesečnega prejemka ali v obliki dodatnih bonusov.
Vir: www.habr.com