DevOps on viimastel aastatel muutunud väga populaarseks teemaks. Paljud inimesed unistavad sellega liitumisest, kuid nagu praktika näitab, sageli ainult palgataseme tõttu.
Mõned inimesed loetlevad DevOpsi oma CV-s, kuigi nad ei tea ega mõista alati selle termini olemust. Mõni arvab, et peale Ansible, GitLabi, Jenkinsi, Terraformi ja muu taolise õppimist (nimekirja võib oma maitse järgi jätkata) saab kohe “devopsist”. See pole muidugi tõsi.
Viimased paar aastat olen tegelenud peamiselt DevOpsi juurutamisega erinevates ettevõtetes. Enne seda töötas ta üle 20 aasta erinevatel ametikohtadel süsteemiadministraatorist IT direktorini. Praegu Playgendary DevOpsi juhtivinsener.
Kes on DevOps
Mõte kirjutada artikkel tekkis pärast teist küsimust: "kes on DevOps?" Siiani pole kindlat terminit, mis või kes see on. Mõned vastused on juba selles . Esmalt toon sellest välja põhipunktid ning seejärel jagan oma tähelepanekuid ja mõtteid.
DevOps ei ole palgatav spetsialist, kommunaalteenuste komplekt ega inseneridega arendajate osakond.
DevOps on filosoofia ja metoodika.
Teisisõnu, see on tavade kogum, mis aitab arendajatel süsteemiadministraatoritega aktiivselt suhelda. Ehk siis tööprotsesse omavahel siduda ja integreerida.
DevOpsi tulekuga jäid spetsialistide struktuur ja rollid samaks (on arendajaid, on insenere), kuid suhtlusreeglid on muutunud. Osakondadevahelised piirid on hägustunud.
DevOpsi eesmärke saab kirjeldada kolmes punktis:
- Tarkvara tuleb regulaarselt uuendada.
- Tarkvara tuleb teha kiiresti.
- Tarkvara tuleks juurutada mugavalt ja lühikese ajaga.
DevOpsi jaoks pole ühte tööriista. Mitme toote seadistamine, tarnimine ja uurimine ei tähenda, et DevOps on ettevõttesse ilmunud. Tööriistu on palju ja neid kõiki kasutatakse erinevatel etappidel, kuid neil on üks ühine eesmärk.
Ja see on vaid osa DevOpsi tööriistadest
Olen DevOpsi inseneri ametikohal inimesi intervjueerinud juba üle 2 aasta ja olen aru saanud, kui oluline on mõista selgelt termini olemust. Mul on kogunenud konkreetsed kogemused, tähelepanekud ja mõtted, mida tahan jagada.
Intervjuu kogemusest näen järgmist pilti: spetsialistidel, kes peavad DevOpsi ametinimetuseks, tekib tavaliselt kolleegidega arusaamatusi.
Ilmekas näide oli. Noormees tuli intervjuule, kelle CV-s oli palju nutikaid sõnu. Viimasel kolmel töökohal oli tal 5-6 kuud kogemust. Ma lahkusin kahest idufirmast, sest need ei tõusnud. Kolmanda ettevõtte kohta aga ütles ta, et seal ei saa keegi temast aru: arendajad kirjutavad koodi Windowsis ja direktor sunnib selle koodi tavalisse Dockerisse “pakkima” ja CI/CD torujuhtmesse sisse ehitama. Kutt ütles oma praeguse töökoha ja kolleegide kohta palju negatiivset - tahtsin lihtsalt vastata: "Ei müü te elevanti."
Seejärel esitasin talle küsimuse, mis on minu nimekirjas iga kandidaadi jaoks kõrgel kohal.
— Mida DevOps teile isiklikult tähendab?
- Üldiselt või kuidas ma seda tajun?
Mind huvitas tema isiklik arvamus. Ta teadis selle termini teooriat ja päritolu, kuid ta ei nõustunud nendega. Ta uskus, et DevOps oli ametinimetus. Siin peitubki tema probleemide juur. Nagu ka teised samal arvamusel spetsialistid.
Tööandjad, kes on DevOpsi maagiast palju kuulnud, tahavad leida inimest, kes tuleb ja loob selle "maagia". Ja kandidaadid kategooriast "DevOps on töö" ei saa aru, et selle lähenemisviisiga ei suuda nad ootusi täita. Ja üldiselt kirjutasid nad oma CV-sse DevOpsi, sest see on trend ja nad maksavad selle eest palju.
DevOpsi metoodika ja filosoofia
Metoodika võib olla teoreetiline ja praktiline. Meie puhul on see teine. Nagu ma eespool mainisin, on DevOps tavade ja strateegiate kogum, mida kasutatakse seatud eesmärkide saavutamiseks. Ja igal juhul, sõltuvalt ettevõtte äriprotsessidest, võib see oluliselt erineda. Mis ei tee asja paremaks ega halvemaks.
DevOpsi metoodika on vaid vahend eesmärkide saavutamiseks.
Nüüd sellest, mis on DevOpsi filosoofia. Ja see on ilmselt kõige raskem küsimus.
Lühikest ja sisutihedat vastust on üsna raske sõnastada, sest see pole veel vormistatud. Ja kuna DevOpsi filosoofia järgijad tegelevad rohkem praktikaga, siis pole lihtsalt aega filosofeerimiseks. See on aga väga oluline protsess. Pealegi on see otseselt seotud inseneritegevusega. Seal on isegi spetsiaalne teadmiste valdkond - .
Minu ülikoolis sellist ainet ei olnud, pidin kõike iseseisvalt õppima, kasutades 90ndatel leiduvaid materjale. Teema on inseneriharidusele vabatahtlik, sellest ka vastuse vormistamatus. Kuid need inimesed, kes on DevOpsi tõsiselt sukeldunud, hakkavad tundma teatud "vaimu" või "teadvuseta kõikehõlmavust" kõigis ettevõtte protsessides.
Kasutades oma kogemusi, püüdsin vormistada mõned selle filosoofia "postulaadid". Tulemus on järgmine:
- DevOps ei ole midagi sõltumatut, mida saab eraldada eraldi teadmiste või tegevuste valdkonnaks.
- Kõik ettevõtte töötajad peaksid oma tegevusi planeerides lähtuma DevOps metoodikast.
- DevOps mõjutab kõiki ettevõttesiseseid protsesse.
- DevOps on loodud selleks, et vähendada ettevõtte mis tahes protsesside ajakulusid, et tagada oma teenuste areng ja klientide maksimaalne mugavus.
- DevOps on tänapäevases keeles iga ettevõtte töötaja proaktiivne positsioon, mille eesmärk on vähendada ajakulu ja parandada meid ümbritsevate IT-toodete kvaliteeti.
Ma arvan, et minu “postulaadid” on omaette aruteluteema. Aga nüüd on, millele toetuda.
Mida DevOps teeb
Siin on võtmesõnaks suhtlemine. Kommunikatsioone on palju, mille algatajaks peaks olema täpselt see sama DevOpsi insener. Miks nii? Sest see on filosoofia ja metoodika ning alles siis inseneriteadmised.
Ma ei saa rääkida 100% kindlusega Lääne tööturust. Kuid ma tean üsna palju DevOpsi turust Venemaal. Lisaks sadadele intervjuudele olen viimase pooleteise aasta jooksul osalenud sadades Venemaa suurettevõtetele ja pankadele suunatud teenuse “DevOps juurutamine” tehnilistes eelmüügis.
Venemaal on DevOps veel väga noor, kuid juba trendikas teema. Minu teada oli ainuüksi Moskvas sellistest spetsialistidest 2019. aastal puudus üle 1000 inimese. Ja sõna Kubernetes on tööandjate jaoks peaaegu nagu punane kalts härjale. Selle tööriista järgijad on valmis seda kasutama ka seal, kus see pole vajalik ja majanduslikult tasuv. Tööandja ei saa alati aru, millistel juhtudel on õigem kasutada ning õige juurutamise korral maksab Kubernetese klastri ülalpidamine 2-3 korda rohkem kui tavapärase klastriskeemi abil rakenduse juurutamine. Kasutage seda seal, kus seda tõesti vajate.
DevOpsi juurutamine on rahaliselt kallis. Ja see on õigustatud ainult siis, kui see toob majanduslikku kasu teistes valdkondades, mitte üksi.
DevOpsi insenerid on tegelikult teerajajad – just nemad peaksid esimesena selle metoodika ettevõttes juurutama ja protsesse üles ehitama. Et see õnnestuks, peab spetsialist pidevalt suhtlema kõikidel tasanditel töötajate ja kolleegidega. Nagu ma tavaliselt ütlen, peaksid DevOpsi juurutamise protsessi kaasama kõik ettevõtte töötajad: alates koristajast kuni tegevjuhini. Ja see on eeltingimus. Kui meeskonna kõige noorem liige ei tea ega mõista, mis on DevOps ja miks teatud organisatsioonilisi toiminguid tehakse, siis edukas juurutamine ei toimi.
Samuti peab DevOpsi insener aeg-ajalt kasutama haldusressurssi. Näiteks "keskkonnakindluse" ületamiseks – kui meeskond pole valmis DevOpsi tööriistu ja metoodikat aktsepteerima.
Arendaja peaks kirjutama ainult koodi ja teste. Selleks ei vaja ta ülivõimsat sülearvutit, millel ta kogu projekti infrastruktuuri juurutab ja kohapeal toetab. Näiteks esiotsa arendaja hoiab oma sülearvutis kõiki rakenduse elemente, sealhulgas andmebaasi, S3 emulaatorit (minio) jne. See tähendab, et ta kulutab palju aega selle kohaliku infrastruktuuri hooldamisele ja võitleb üksi kõigi sellise lahenduse probleemidega. Selle asemel, et arendada esikülje koodi. Sellised inimesed võivad olla väga vastupidavad mis tahes muutustele.
Kuid on meeskondi, kes, vastupidi, tutvustavad hea meelega uusi tööriistu ja meetodeid ning osalevad selles protsessis aktiivselt. Kuigi ka sel juhul ei katkestatud DevOpsi inseneri ja meeskonna vahelist suhtlust.
Kui DevOpsi pole vaja
On olukordi, kus DevOpsi pole vaja. See on fakt – seda tuleb mõista ja aktsepteerida.
Esiteks puudutab see kõiki ettevõtteid (eriti väikeettevõtteid), mille kasum ei sõltu otseselt klientidele infoteenuseid pakkuvate IT-toodete olemasolust või puudumisest. Ja siin me ei räägi ettevõtte veebisaidist, olgu see siis staatiline "visiitkaart" või dünaamiliste uudisteplokkidega vms.
DevOps on vajalik, kui teie kliendi rahulolu ja soov teie juurde uuesti naasta sõltub nende teabeteenuste kättesaadavusest kliendiga suhtlemiseks, nende kvaliteedist ja sihtimisest.
Ilmekas näide on üks tuntud pank. Ettevõttel puuduvad traditsioonilised kliendikontorid, dokumendivoog toimub posti või kullerite kaudu ning paljud töötajad töötavad kodus. Ettevõte on lakanud olemast pelgalt pank ja minu arvates on muutunud IT-ettevõtteks, millel on arenenud DevOps tehnoloogiad.
Temaatiliste kohtumiste ja konverentside salvestustelt leiab palju teisigi näiteid ja loenguid. Külastasin mõnda neist isiklikult - see on väga kasulik kogemus neile, kes soovivad selles suunas areneda. Siin on lingid YouTube'i kanalitele, kus on head loengud ja materjalid DevOpsi kohta:
Vaadake nüüd oma ettevõtet ja mõelge sellele: kui palju sõltub teie ettevõte ja selle kasum IT-toodetest, et võimaldada klientidega suhtlemist?
Kui teie ettevõte müüb kala väikeses poes ja ainus IT-toode on kaks 1C: Enterprise konfiguratsiooni (Accounting ja UNF), siis DevOpsist pole mõtet rääkida.
Kui töötate suures kaubandus- ja tootmisettevõttes (näiteks toodate jahipüsse), peaksite sellele mõtlema. Saate võtta initsiatiivi ja edastada oma juhtkonnale DevOpsi juurutamise väljavaated. Noh, ja samal ajal juhtige seda protsessi. Proaktiivne positsioon on DevOpsi filosoofia üks olulisi põhimõtteid.
Aastase finantskäibe suurus ja maht ei ole peamine kriteerium, mille põhjal otsustada, kas teie ettevõte vajab DevOpsi.
Kujutagem ette suurt tööstusettevõtet, mis ei suhtle otseselt klientidega. Näiteks mõned autotootjad ja autotootjad. Ma pole praegu kindel, kuid minu varasemast kogemusest lähtudes on paljude aastate jooksul kogu klientidega suhtlemine toimunud e-posti ja telefoni teel.
Nende klientideks on piiratud nimekiri automüüjatest. Ja igaühele on tootja määratud spetsialist. Kogu sisemine dokumendivoog toimub SAP ERP kaudu. Sisetöötajad on sisuliselt infosüsteemi kliendid. Kuid seda IS-i juhitakse klassikaliste klastrisüsteemide haldamise vahenditega. Mis välistab DevOpsi tavade kasutamise võimaluse.
Siit järeldus: selliste ettevõtete jaoks pole DevOpsi juurutamine midagi kriitilise tähtsusega, kui meenutada artikli algusest peale metoodika eesmärke. Kuid ma ei välista, et nad kasutavad täna mõnda DevOpsi tööriistu.
Teisest küljest on palju väikeettevõtteid, kes arendavad tarkvara DevOpsi metoodikat, filosoofiat, tavasid ja tööriistu kasutades. Ja nad usuvad, et DevOpsi juurutamise kulud on kulud, mis võimaldavad neil tarkvaraturul tõhusalt konkureerida. Näiteid sellistest ettevõtetest võib näha .
Peamine kriteerium DevOpsi vajalikkuse mõistmiseks: milline väärtus on teie IT-toodetel ettevõtte ja klientide jaoks.
Kui ettevõtte põhitoode, mis kasumit toodab, on tarkvara, on sul vaja DevOpsi. Ja see pole nii oluline, kui teenite teiste toodetega päris raha. See hõlmab ka veebipoode või mängudega mobiilirakendusi.
Kõik mängud on olemas tänu rahastamisele: mängijatelt otse või kaudselt. Playgendarys arendame tasuta mobiilimänge, mille loomisega on otseselt seotud üle 200 inimese. Kuidas me DevOpsi kasutame?
Jah, täpselt sama, mis ülalpool kirjeldatud. Suhtlen pidevalt arendajate ja testijatega ning viin läbi töötajatele DevOpsi metoodika ja tööriistade sisekoolitusi.
Nüüd kasutame Jenkinsit aktiivselt CI/CD torujuhtmete tööriistana kõigi koostekonveierite käivitamiseks Unityga ja seejärel juurutamiseks App Store'i ja Play Marketisse. Veel klassikalisest tööriistakomplektist:
- Asana – projektijuhtimiseks. Integratsioon Jenkinsiga on konfigureeritud.
- Google Meet – videokoosolekute jaoks.
- Slack - side ja erinevate hoiatuste, sealhulgas Jenkinsi märguannete jaoks.
- Atlassian Confluence – dokumenteerimiseks ja rühmatööks.
Meie lähiplaanide hulka kuulub staatilise koodianalüüsi juurutamine SonarQube'i abil ja automaatse kasutajaliidese testimise läbiviimine seleeni abil pideva integreerimise etapis.
Selle asemel, et järeldus
Tahaksin lõpetada järgmise mõttega: kõrgelt kvalifitseeritud DevOpsi inseneriks saamiseks on ülioluline õppida inimestega reaalajas suhtlema.
DevOpsi insener on meeskonnamängija. Ja ei midagi muud. Initsiatiiv kolleegidega suhtlemisel peaks tulema temalt, mitte mingite asjaolude mõjul. DevOpsi spetsialist peab nägema ja pakkuma meeskonnale parimat lahendust.
Ja jah, iga lahenduse rakendamine nõuab palju arutelu ja lõpuks võib see üldse muutuda. Iseseisvalt arenedes, oma ideid välja pakkudes ja ellu viides on selline inimene üha suurema väärtusega nii meeskonnale kui ka tööandjale. Mis lõppkokkuvõttes kajastub tema igakuise töötasu suuruses või lisaboonuste näol.
Allikas: www.habr.com