DevOps teema on viimastel aastatel muutunud väga populaarseks. Paljud unistavad sellesse valdkonda sisenemisest, kuid praktika näitab, et sageli on see vaid palkade taseme tõttu.
Mõned lisavad oma CV-sse DevOps, kuigi nad ei pruugi alati mõista termini tähendust. Keegi arvab, et piisab Ansible'i, GitLabi, Jenkins'i, Terraform'i ja nende sarnaste teadmiste õppimisest, et koheselt "devopseks" saada. See pole sugugi nii.
Viimased paar aastat olen peamiselt tegelenud DevOpsi juurutamisega erinevates ettevõtetes. Enne seda töötasin üle 20 aasta ametikohtadel alates süsteemiadministraatorist kuni IT-direktorini. Praegu olen DevOps Lead Engineer Playgendarys.
Kes on DevOps
Idee selle artikli kirjutamiseks tekkis pärast taasühte küsimust: "kes on DevOps?". Senini pole kindlat mõistet, mis see on või kes see on. Osa vastuseid on juba selles . Esiteks toome välja peamised punktid sellest, seejärel jagan oma tähelepanekuid ja mõtteid.
DevOps ei ole spetsialist, kelle saab palgata, ei ole see tööriistade kogum, ega ka arendajate ja inseneride osakond.
DevOps on filosoofia ja metoodika.
Teisisõnu on see praktikate kogum, mis aitab arendajatel aktiivselt suhelda süsteemiadministraatoritega. See tähendab töövoogude sidumist ja integreerimist üksteisega.
DevOpsi saabumisega on struktuur ja spetsialistide rollid jäänud samaks (on arendajad, on insenerid), kuid suhtlemise reeglid on muutunud. Erakondade vahelised piirit on hägustunud.
DevOpsi eesmärke saab kirjeldada kolme punktiga:
- Tarkvara peab olema regulaarselt uuendatud.
- Tarkvara peab olema kiiresti arendatud.
- Tarkvara peab olema mugavalt ja lühikese aja jooksul juurutatav.
DevOpsil ei ole ühtegi kindlat tööriista. Mõne toote seadistamine, paigaldamine ja õppimine ei tähenda, et ettevõttes on DevOps. Tööriistu on palju ja neid kasutatakse erinevates etappides, kuid need teenivad ühte ühist eesmärki.
Ja see on vaid osa DevOps'i tööriistu.
Olen juba enam kui 2 aastat intervjueerinud inimesi DevOps-inseneri positsioonile ja olen aru saanud, kui oluline on mõista termini olemust. Olen kogunud spetsiifilist kogemust, tähelepanekuid ja mõtteid, mida tahan jagada.
Oma vestluste kogemuste põhjal näen ma sellist pilti: DevOps-i ametiks pidavatel spetsialistidel on tavaliselt oma kolleegidega arusaamatusi..
Oli silmatorkav näide. Töövestlusele tuli noormees, kellel oli CV-s palju tarku sõnu. Viimase kolme töökoha juures oli tal töökogemus 5–6 kuud. Kahest idufirmast lahkus ta, kuna need 'ei õnnestunud'. Kolmanda firma osas ütles ta, et seal ei mõista teda keegi: arendajad kirjutavad koodi Windowsis, kuid direktor sunnib seda koodi 'pakendama' tavalisse Dockerisse ja integreerima CI/CD torustikku. Noormees rääkis palju negatiivset oma praeguse töökoha ja kolleegide kohta – nii tahtnuks vastata: 'Nii et sa elevanti ei müü.'
Siis esitasin talle küsimuse, mis on minu kandidaatide nimekirjas üks esimesi.
— Mida DevOps sinu jaoks isiklikult tähendama peaks?
— Üldiselt või kuidas mina seda tajun?
Mind huvitas tema isiklik arvamus. Ta teadis teooriat ja termini päritolu, kuid oli nendega kategooriliselt eriarvamusel. Ta pidas, et DevOps on ametikoht. Siin peitub tema probleemide juur, nagu ka teistel spetsialistidel, kellel on sama arvamus.
Töötajad, kes on kuulnud 'DevOpsi maagiast', soovivad leida kedagi, kes tuleks ja selle 'maagiat' looma hakkaks. Kuid kandidaadid, kes arvavad, et 'DevOps on amet', ei mõista, et sellise lähenemisega ei suuda nad ootusi õigustada. Üldiselt on nad oma CV-s 'DevOps'i' maininud, sest see on trend ja palgad on head.
DevOpsi metodoloogia ja filosoofia
Metodoloogia võib olla teoreetiline ja praktiline. Meie puhul on tegemist teisega. Nagu ma juba mainisin, on DevOps kogum praktikate ja strateegiate, mida rakendatakse seatud eesmärkide saavutamiseks. Igas olukorras võib see, sõltuvalt ettevõtte äri protsessidest, oluliselt erineda, mis ei tee seda paremaks ega halvemaks.
DevOpsi metodoloogia on vaid vahend seatud eesmärkide saavutamiseks.
Nüüd räägime sellest, mis on DevOpsi filosoofia. Ja see on ilmselt kõige keerulisem küsimus.
Lühikese ja täpse vastuse formuleerimine ei ole kerge, kuna see pole veel formaliseeritud. Kuna DevOpsi filosoofia praktiseerijatel ei ole lihtsalt aega filosoofiateks, on see siiski äärmiselt oluline protsess. See on otseselt seotud inseneritegevusega. On isegi eraldi teadmiste valdkond — .
Minu ülikoolis sellist ainet ei õpetatud, pidin kõik ise 90ndatel leitud materjalide kaudu õppima. Teema ei ole insenerihariduse jaoks kohustuslik, seega puudub vastuse formaliseerimine. Kuid need inimesed, kes on tõeliselt DevOpsiga süvenenud, hakkavad tunnetama teatud 'vaimu' või 'teadvustamata universaalsust' kõigis ettevõtte protsessides.
Olen püüdnud oma kogemuste põhjal formaliseerida mõned selle filosoofia 'postulaadid'. Tulemus on järgmine:
- DevOps ei ole midagi iseseisvat, mida võiks välja tuua eraldi teadmiste või tegevuse suunana.
- DevOpsi metodoloogiast peaks kinni pidama kõik ettevõtte töötajad oma tegevuse planeerimisel.
- DevOps hõlmab kõiki protsesse ettevõtte sees.
- DevOps eksisteerib, et vähendada ettevõtte siseste protsesside ajakulu, et tagada teenuste areng ja maksimaalne mugavus kliendile.
- DevOps tähendab kaasaegses keeles iga töötaja proaktiivset positsiooni, mille eesmärk on vähendada ajakulusid ja parandada meie ümbritsevaid IT-tooteid.
Arvan, et minu „postulaadid“ on eraldi arutelu teema. Aga nüüd on vähemalt millegi pealt alustada.
Mida teeb DevOps
Siin on võtmesõna – kommunikatsioon. Väga palju kommunikatsioone, mille algataja peaks olema just see DevOps-insener. Miks just nii? Sest see on filosoofia ja metodologia, ning alles seejärel inseneriteadmised.
Lääne tööjõuturust ei saa 100% kindlusega rääkida. Kuid DevOps turust Venemaal tean ma üsna palju. Viimase pooleteise aasta jooksul olen osalenud sadades tehnilistes esitlustes teenuse 'DevOpsi rakendamine' kohta suurte Venemaa ettevõtete ja pankade jaoks.
Venemaal on DevOps veel üsna noor, kuid juba trendikas teema. Teadmiste kohaselt oli näiteks Moskvast 2019. aastal defitsiit sellistest spetsialistidest üle 1000 inimese. Ja sõna Kubernetes on tööandjatele peaaegu nagu punane riie härjale. Selle tööriista austajad on valmis seda kasutama isegi seal, kus see ei ole vajalik ega majanduslikult kasulik. Tööandja ei mõista alati, millal on mõistlik kasutada, samas kui korraliku rakendamise korral võib Kubernetes'i klastrite haldamine maksta kaks kuni kolm korda rohkem kui rakenduse käitamine tavalise klastriskeemi järgi. Kasutage seda seal, kus see tõeliselt vajalik on.
DevOpsi rakendamine rahalises plaanis on kallis. See on põhjendatud üksnes seal, kus see toob majanduslikku kasu teistes valdkondades, mitte ainuüksi enda pärast.
DevOps-insenerid on tõeliselt esirinnas — just nemad peavad esimesena rakendama seda metoodikat ja korraldama protsesse ettevõttes. Selleks, et see oleks edukas, peab spetsialist pidevalt suhtlema töötajate ja kolleegidega kõikidel tasanditel. Kuidas ma tavaliselt ütlen, peab DevOpsi rakendamise protsessis osalema kõik ettevõtte töötajad: koristajast kuni tegevjuhini. Ja see on hädavajalik tingimus. Kui meeskonna kõige noorem liige ei tea ega mõista, mis on DevOps ja miks teatud organisatsioonilised toimingud tehakse, siis pole edukat rakendamist võimalik saavutada.
Samuti peab DevOps-insener aeg-ajalt kasutama administratiivset suutlikkust. Näiteks keskkonna "vastupanemise" ületamiseks — kui meeskond ei ole valmis DevOpsi tööriistu ja metoodikat vastu võtma.
Arendaja peab kirjutama ainult koodi ja teste. Selleks ei ole tal vaja supervõimekaid sülearvuteid, millega ta kohapeal kogu projekti infrastruktuuri üles seaks ja toetaks. Näiteks front-end arendaja hoiab oma sülearvutis kõik rakenduse elemendid, sealhulgas andmebaasi, S3 simulaatori (minio) ja muud. See tähendab, et ta kulutab palju aega selle kohalikku infrastruktuuri toetamisele ja võitleb üksi kõigi selle lahendusega seotud probleemidega, selle asemel et arendada front-endi koodi. Sellised inimesed võivad igasugustele muudatustele tugevasti vastu seista.
Ent on ka meeskondi, kes vastupidi, on rõõmsad uute tööriistade ja meetodite rakendamise üle ning osalevad aktiivselt protsessis. Kuigi isegi sellisel juhul ei saa keegi unustada suhtlust DevOps inseneri ja meeskonna vahel.
Millal DevOps ei ole vajalik
On olukordi, kus DevOps ei ole vajalik. See on fakt — seda tuleb mõista ja vastu võtta.
Esiteks puudutab see kõiki ettevõtteid (eriti väikeseid ettevõtteid), kui nende kasum ei sõltu otseselt IT-toodetest, mis pakuvad klientidele infoteenuseid. Ja siin ei ole jutt ettevõtte veebisaidist, olgu see staatiline "visiitkaart" või dünaamiliste uudiste plokkidega jne.
DevOps on vajalik, kui teie klientide rahulolu ja nende soovi taas teie juurde tagasi tulla sõltub nendest infoteenustest, nende kvaliteedist ja suunatusest, millega suheldakse.
Heaks näiteks on üks tuntud pank. Ettevõttel puuduvad traditsioonilised kliendibürood, dokumendihaldus toimub posti või kullerite kaudu ning paljud töötajad töötavad kodus. Ettevõttest on saanud mitte lihtsalt pank, vaid minu arvates on see muutunud IT-ettevõtteks, millel on arenenud DevOps-tehnoloogiad.
Palju muid näiteid ja loenguid võib leida temaatiliste meetupide ja konverentside lindistustes. Osad neist olen isiklikult külastanud - see on väga kasulik kogemus neile, kes soovivad selles valdkonnas areneda. Siin on lingid YouTube'i kanalitele, kus on head loengud ja materjalid DevOpsi kohta:
Vaata nüüd oma ettevõtet ja mõtle sellele: kui palju sõltub teie ettevõte ja selle kasum IT-toodetest, mis tagavad kliendiga suhtlemise?
Kui teie ettevõte müüb kala väikeses kaupluses ja ainus IT-toode on kaks конфигурации 1С: Предприятие (Raamatupidamine ja UNF), siis ei ole mõtet rääkida DevOps'ist.
Kuid kui te töötate suures kaubandus- ja tootmisettevõttes (nt jahipüsside tootmine), siis tasub sellele mõelda. Saate algatada arutelu ja edastada oma juhtkonnale DevOps'i rakendamise võimalusi. Ja samal ajal juhtida seda protsessi. Proaktiivne lähenemine on üks DevOps'i filosoofia olulisi aluseid.
Ettevõtte suurus ja aastane finantstöötlemise maht ei ole peamine kriteerium, et kindlaks teha, kas teie ettevõttele on vajalik DevOps.
Kujutage ette suurt tööstusettevõtet, mis ei suhtle otse klientidega. Näiteks mõned autotootjad ja autotööstuse ettevõtted. Praegu ei ole ma kindel, aga minu varasema kogemuse põhjal toimus aastaid kogu kliendiga suhtlemine e-posti ja telefoni teel.
Nende kliendid on piiratud nimekiri automüüjatest. Igaühega on seotud tootja spetsialist. Kogu sisemine dokumendihaldus toimub ERP SAP kaudu. Sisedöötajad on tegelikult teabe süsteemi kliendid. Kuid selle IС-i haldamine toimub klassikaliste klastrihalduse vahendite kaudu. See välistab DevOps praktika kasutamise võimaluse.
Seega järeldame, et sellistele ettevõtetele ei ole DevOpsi rakendamine kriitilise tähtsusega, kui meenutada metodoloogia eesmärke artikli algusest. Kuid ei välista, et mõned DevOpsi tööriistad on nad tänapäeval kasutusele võtnud.
Teisest küljest on palju väikeseid ettevõtteid, mis arendavad tarkvara, kasutades DevOps'i metoodikat, filosoofiat, praktikaid ja tööriistu. Nad usuvad, et kulud DevOps'i rakendamiseks on vajalikud investeeringud, mis aitavad neil tõhusalt konkureerida tarkvaraturul. Selliseid ettevõtteid võib leida. .
Peamine kriteerium DevOps'i vajaduse mõistmiseks: kui oluline on teie IT-tooted ettevõttele ja klientidele.
Kui ettevõtte peamine kasumitoov toode on tarkvara – teil on vaja DevOps'i. Oluline ei ole, kui palju raha teenite teiste kaupadega. Siia alla võivad kuuluda ka veebipoed või mobiilimängud.
Kõik mängud eksisteerivad mängijate otsesest või kaudsest rahastamisest. Playgendary arendab tasuta mobiilseid mänge, mille loomises osalevad rohkem kui 200 inimest. Kuidas me kasutame DevOps'i?
Täpselt nii nagu eespool kirjeldatud. Suhtlen pidevalt arendajate ja testeritega, viin läbi sisekoolitusi DevOps'i metoodika ja tööriistade osas.
Praegu kasutame aktiivselt Jenkinsit CI/CD torude tööriistana, et teostada kõiki Unity ehitustorusid ning järgnevaks juurutamiseks App Store'i ja Play Market'i. Veel klassikalisest tööriistade komplektist:
- Asana — projektide haldamiseks. Integreerimine Jenkinsiga on seadistatud.
- Google Meet — videokohtumiste läbiviimiseks.
- Slack — suhtlemiseks ja erinevate teavituste jaoks, sealhulgas Jenkinsist saadud teated.
- Atlassian Confluence — dokumenteerimiseks ja grupitööks.
Lähitulevikus plaanime juurutada staatilist koodi analüüsi SonarQube abil ning teostada automatiseeritud UI-testimist Seleniumi vahenditega Jätkuva Integreerimise etapis.
Kokkuvõtte asemel
Soovin lõpetada järgmise mõttega: et saada kõrgetasemeliseks DevOps-inseneriks, on hädavajalik õppida inimesega suhtlema.
DevOps-insener on meeskonnamängija. Ja mitte teisiti. Initsiatiiv suhtlemiseks kolleegidega peaks tulema temalt endalt, mitte mingite asjaolude mõjul. DevOps-spetsialist peab nägema ja pakkuma meeskonnale parimat lahendust.
Ja, igasugune lahenduse rakendamine nõuab rohkelt arutelusid, kuid lõpuks võib see hoopis muutuda. Iseseisvalt arenedes, oma ideid pakkudes ja ellu viies — selline inimene omandab järjest enam väärtust nii meeskonna kui tööandja jaoks. Mis lõppkokkuvõttes kajastub ka tema igakuistes hüvedes või lisatasudes.
Allikas: habr.com
