Kes on DevOps ja millal seda ei vajata

DevOps teema on viimastel aastatel muutunud väga populaarseks. Paljud soovivad sellesse valdkonda astuda, kuid praktika näitab, et tihti on põhjuseks ainult palgatase.

Mõned inimesed mainivad oma CV-s DevOps'i, kuigi nad ei pruugi alati mõista termini olemust. Keegi arvab, et kui ta õpib Ansible'i, GitLab'i, Jenkins'i, Terraform'i ja sarnased (nimekirja võib jätkata vastavalt maitsele), siis muutub ta kohe 'devops'iks. See pole muidugi nii.

Viimased paar aastat olen peamiselt tegelenud DevOps'i rakendamisega 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?

Artikli kirjutamise idee tekkis pärast järjekordset küsimust: 'kes on DevOps?'. Ruumis pole endiselt kindlat mõistet, mida või kes see on. Osa vastustest on juba selles video. Esmalt toome välja peamised teesid, seejärel jagan oma tähelepanekuid ja mõtteid.

DevOps ei ole spetsialist, keda saab palgata, ei ole see tööriistade kogum, ega ka arendajate ja inseneride osakond.

DevOps on filosoofia ja metodoloogia.

Teisisõnu, see on praktikate kogum, mis aitab arendajatel aktiivselt suhtlemisel süsteemiadministraatoritega. See tähendab, et siduda ja integreerida tööprossid üksteisega.

DevOps'i tekkimisega jäi struktuur ja spetsialistide rollid samaks (on arendajad, on insenerid), kuid muutusid suhtlemise reeglid. Osakondade piirid on hägustunud.

DevOps'i eesmärke võib kirjeldada kolme punktiga:

• Tarkvara peab uuendama regulaarsete ajavahemike järel.
• Tarkvara peab olema kiirelt loodud.
• Tarkvara peab olema mugav ja kiiresti juurutatav.

DevOps'il ei ole ühte ainsat tööriista. Määratlemine, seadistamine ja mitme toote õppimine ei tähenda, et ettevõttes on olemas DevOps. Tööriistu on väga palju ja need on seotud erinevate etappidega, kuid teenivad ühte ühist eesmärki.

Ja see on alles osa DevOps'i tööriistadest.

Olen juba rohkem kui 2 aastat intervjueerinud inimesi DevOps-inseneri positsioonile ja olen aru saanud, kui oluline on mõista termini olemust. Olen kogunud spetsiaalset kogemust, tähelepanekuid ja mõtteid, mida soovin jagada.

Intervjueerimise kogemuse põhjal näen sellist pilti: neil spetsialistidel, kes arvavad, et DevOps on amet, on tavaliselt kolleegidega arusaamatused..

Oli erekordne näide. Intervjuule tuli noormees, kelle CV-s oli hulk nutikaid sõnu. Viimases kolmes töökohas oli tal praktika 5-6 kuud. Kahest idufirmast lahkus ta, kuna need "ei lennanud". Kolmanda ettevõtte kohta ütles ta, et seal ei mõista teda keegi: arendajad kirjutavad koodi Windowsi jaoks ja direktor sunnib seda koodi "pakendama" tavapärasesse Dockerisse ja integreerima CI/CD torustikku. Poisil oli palju negatiivset rääkida oma praegusest töökohast ja kolleegidest - nii et tahtsin vastata: "Sa ei müü elevanti."

Siis esitasin talle küsimuse, mis on minu nimekirjas iga kandidaadi jaoks üks esimesi.

— Mida tähendab DevOps isiklikult sinu jaoks?
— Üldiselt või kuidas ma seda tajun?

Mind huvitas tema isiklik arvamus. Ta teadis teooriat ja termini päritolu, kuid oli sellega kategooriliselt mittes согласен. Ta arvas, et DevOps on ametikoht. Just siin peitub tema probleemide juur. Nagu ka teistel spetsialistidel, kellel on sama arvamus.

Tööandjad, kuuldes "DevOpsi maagia" kohta, soovivad leida inimest, kes tuleb ja loob selle "maagia". Ja need kandidaadid, kes arvavad, et "DevOps on ametikoht", ei mõista, et sellise lähenemisega nad ei saa ootusi õigustada. Ja üldiselt, nad on oma CV-sse kirjutanud DevOps, kuna see on trend ja selle eest makstakse palju.

DevOpsi metoodika ja filosoofia

Metoodika võib olla teoreetiline ja praktiline. Meie puhul – teine. Nagu ma eespool mainisin, on DevOps kogum praktikatest ja strateegiatest, mida kasutatakse soovitud eesmärkide saavutamiseks. Ja igal juhul, sõltuvalt ettevõtte äriprotsessidest, võib see oluliselt erineda. Mis ei tee seda paremaks või halvemaks.

DevOpsi metoodika on vaid vahend seatud eesmärkide saavutamiseks.

Nüüd sellest, mis on DevOpsi filosoofia. Ja see on tõenäoliselt kõige raskem küsimus.

Lühikese ja sisuka vastuse formuleerimine on piisavalt keeruline, kuna see pole veel formaliseeritud. Ja kuna DevOpsi filosoofia pooldajad tegelevad rohkem praktikaga, pole filosoofeerimiseks lihtsalt aega. Sellegipoolest on see väga oluline protsess. Ja see on otseselt seotud inseneritegevusega. On isegi spetsialiseeritud teadmiste valdkond — tehnika filosoofia.

Minu ülikoolis ei olnud sellist ainet, pidin kõik iseseisvalt õppima 90ndatel leitud materjalide põhjal. Teema ei ole insenerihariduse jaoks kohustuslik, seega puudub ka vastuse formaliseerimine. Kuid need inimesed, kes on tõsiselt süvenenud DevOps-i, hakkavad tunnetama mingit "vaimu" või "teadmatult kõikehõlmavust" kõigis ettevõtte protsessides.

Olen oma kogemuste põhjal püüdnud formaliseerida mõned selle filosoofia "postulaadid". Tulemuseks on järgmine:

• DevOps ei ole iseseisev asi, mida saaks eraldi teadus- või tegevusvaldkonnana välja tuua.
• DevOps-i metoodikat peaksid järgima kõik ettevõtte töötajad, planeerides oma tegevust.
• DevOps puudutab kõiki protsesse ettevõttes.
• DevOps eksisteerib, et vähendada ajakulusid igasuguste protsesside jaoks ettevõttes, tagades teenuste arengu ja maksimaalse kliendi mugavuse.
• DevOps, tänapäeva keeles, on iga ettevõtte töötaja proaktiivne positsioon, mis on suunatud ajakulude vähendamisele ja ümbritsevate IT-toodete kvaliteedi parandamisele.

Arvan, et minu "postulaadid" on eraldi arutelu teema. Kuid nüüd on millegi najal alustada.

Mida teeb DevOps

Siin on võtmesõna - suhtlemine. Suure hulga suhtlemiste algataja peaks olema just see DevOps-insener. Miks? Sest see on filosoofia ja metoodika, ning alles seejärel inseneriteadmised.

Lääne tööjõuturust ei saa ma 100% kindlusega rääkida. Kuid Venemaa DevOps turust tean ma üsna palju. Viimase pooleteise aastaga olen osalenud sadades tehnilistes eeltöötlemistes teenuse "DevOps-i rakendamine" jaoks suurtes Venemaa ettevõtetes ja pankades.

Venemaal on DevOps veel väga noor, kuid juba trenditeema. Nii palju kui mina tean, oli 2019. aastal Moskvas selliste spetsialistide puudus üle 1000 inimese. Ja sõna Kubernetes on tööandjate jaoks peaaegu nagu punane rätt pulli jaoks. Selle tööriista austajad on valmis seda kasutama isegi seal, kus see ei ole vajalik ega majanduslikult kasulik. Tööandja ei mõista alati, millistes olukordades on mõistlikum kasutada, ja korraliku klastrite kasutuselevõtu korral maksab Kubernetes'i klastrite sisu 2-3 korda rohkem kui rakenduse häälestamine tavapärase klastriskeemi järgi. Kasutage seda seal, kus see tõeliselt vajalik on.

DevOps'i rakendamine rahaga vaadates on kallis. Ja seda põhjendatakse ainult seal, kus see toob majanduslikku kasu teistes valdkondades, mitte iseenesest.

DevOps-insenerid on tegelikult teerajajad — just nemad peaksid esimesena seda metoodikat ettevõttes rakendama ja protsesse üles ehitama. Selleks, et see oleks edukas, peab spetsialist pidevalt suhtlema töötajate ja kolleegidega igal tasandil. Nagu ma tavaliselt ütlen, peavad DevOps'i rakendamisse olema kaasatud kõik ettevõtte töötajad: koristajast kuni tegevjuhini. Ja see on kohustuslik tingimus. Kui meeskonna noorim liige ei tea ega mõista, mis on DevOps ja miks teatud organisatsioonilised tegevused toimuvad, ei õnnestu edukas rakendamine.

Samuti peab DevOps-insener aeg-ajalt kasutama haldussuutlikkust. Näiteks, et ületada „keskkonna vastupanu” — kui meeskond ei ole valmis võtma omaks DevOps'i tööriistu ja metoodikat.

Arendaja peaks kirjutama ainult koodi ja teste. Selleks ei vaja ta supervõimekaid sülearvuteid, millega ta kohapeal kogu projekti infrastruktuuri üles seab ja toetab. Näiteks front-end arendaja hoiab endal sülearvutis kõik rakenduse elemendid, sealhulgas andmebaasi, S3 emulaatori (minio) jne. See tähendab, et ta kulutab palju aega selle kohaliku infrastruktuuri hooldamiseks ja üksinda võitleb kõigi sellise lahenduse probleemidega. Selle asemel, et arendada koodi esiosa jaoks. Sellised inimesed võivad muutuda igasuguste muudatuste vastasteks.

Kuid on ka meeskondi, kes on vastupidi rõõmsad uute tööriistade ja meetodite kasutuselevõtust ning osalevad aktiivselt selles protsessis. Isegi sellisel juhul ei ole kommunikatsioon DevOps-inseneri ja meeskonna vahel kuhugi kadunud.

Kui DevOps'i ei vajata

On olukordi, kus DevOps'i ei vajata. See on fakt — seda tuleb mõista ja aktsepteerida.

Esiteks puudutab see kõiki ettevõtteid (eriti väikeettevõtteid), kui nende kasum ei sõltu otseselt IT-toodetest, mis pakuvad klientidele teabeteenuseid. Ja siinkohal ei ole jutt ettevõtte veebisaidist, olgu see staatiline "visiitkaart" või dünaamilised uudistetooted jne.

DevOps'i on vaja, kui nende teabeteenuste olemasolu, kvaliteet ja sihtrikkus, mis aitavad kliendisuhtlust, mõjutavad teie kliendi rahulolu ja tema soovi tagasi tulla just teie juurde.

Selge näide on üks tuntud pank. Ettevõttel ei ole traditsioonilisi klienditeeninduse büroosid, dokumentatsioon käib posti või kullerite kaudu, ja paljud töötajad töötavad kodus. Ettevõte ei ole enam lihtsalt pank, vaid minu arvates on see muutunud IT-ettevõtteks, millel on arenenud DevOps-tehnoloogiad.

Palju teisi näiteid ja loenguid leidub temaatiliste ürituste ja konverentside salvestustes. Osa neist olen külastanud isiklikult — see on väga kasulik kogemus neile, kes soovivad selles valdkonnas areneda. Siin on lingid YouTube'i kanalitele, kus on häid loenguid ja materjale DevOps'i kohta:

• DevOops
• DevOpsConf
• HighLoad++
• Flant
• MailRu Cloud Solution

Nüüd vaadake oma äri ja mõelge sellele: kui palju teie ettevõte ja selle kasum sõltuvad IT-toodetest, mis tagavad kliendisuhtluse?

Kui teie ettevõte müüb kala väikestes poodides ja ainus IT-toode on kaks 1C: Ettevõtte konfiguratsiooni (Raamatupidamine ja UHF), siis ei ole ilmselt mõtet DevOps'ist rääkida.

Kuid kui töötate suures jaotuse ja tootmise ettevõttes (näiteks tootmate jahipüsse), siis tasub mõelda. Te saate algatada ja edastada oma juhtkonnale DevOps'i rakendamise perspektiive. Samuti võite selle protsessi juhtimise endale võtta. Proaktiivne hoiak on üks DevOps'i filosoofia olulisi principe.

Aasta finantskäibe suurus ja maht ei ole peamine kriteerium, et määrata, kas teie ettevõttele on vajalik DevOps.

Kujutame ette suurt tööstusettevõtet, mis ei suhtu otse klientidega. Näiteks mõned autotootjad ja autotööstusettevõtted. Hetkel ei ole ma kindel, aga minu varasemast kogemusest tulenevalt toimus kogu suhtlus klientidega aastaid läbi e-posti ja telefoni.

Nende kliendid on piiratud nimekiri autode edasimüüjatest. Igaühe juurde on määratud tootja esindaja. Kogu sisemine dokumentatsioon toimub ERP SAP kaudu. Sisemised töötajad on sisuliselt infok süsteemi kliendid. Kuid selle infok süsteemi juhtimine toimub klassikaliste klastrite juhtimise meetodite kaudu, mis välistab DevOps'i praktikate kasutamise.

Seega järeldus: sarnastele ettevõtetele ei ole DevOps'i rakendamine kriitiliselt oluline, kui meenutada artikli alguses mainitud metoodika eesmärke. Kuid ei välista, et nad kasutavad täna mõningaid DevOps'i tööriistu.

Teisest küljest on palju väikeseid ettevõtteid, mis arendavad tarkvara, kasutades DevOps'i metoodikat, filosoofiat, praktikaid ja tööriistu. Nad arvavad, et DevOps'i rakendamise kulud on kulud, mis võimaldavad neil tõhusalt konkureerida tarkvaraturul. Selliseid ettevõtteid võib näha. siin.

Peamine kriteerium, et mõista, kas DevOps on vajalik: kui tähtsad on teie IT-tooted ettevõtte ja klientide jaoks.

Kui ettevõtte peamine toode, mis toob kasumit, on tarkvara — vajate DevOps'i. Ja ei ole nii oluline, kui tõeliselt raha teenite teiste kaupadega. Siia võib kuulu Interneti-poode või mobiilirakendusi mängudega.

Igasugused mängud eksisteerivad tänu rahastusele: kas otse või kaudselt mängijate poolt. Playgendary's arendame tasuta mobiilmänge, mille loomises osaleb rohkem kui 200 inimest. Kuidas meie kasutame DevOps'i?

Jaa, täpselt nii nagu eespool kirjeldatud. Suhtlen pidevalt arendajate ja testijatega, korraldan töötajatele siseõpet DevOps'i metoodika ja tööriistade osas.

Praegu kasutame aktiivselt Jenkinsit CI/CD torude tööriistana, et täita kõiki Unity kogumisseadmete ja sellele järgnevate rakenduste juurutamiseks App Store'is ja Play Marketis. Veel klassikaline tööriistade valik:

• Asana — projektide haldamiseks. Integreerimine Jenkinsiga on seadistatud.
• Google Meet — videokohtumiste korraldamiseks.
• Slack — kommunikatsiooniks ja erinevate teavituste jaoks, sealhulgas Jenkinsist saadud teavituste jaoks.
• Atlassian Confluence — dokumenteerimiseks ja rühmatööks.

Lähitulevikus plaanime rakendada staatilist koodi analüüsi SonarQube'i abil ja läbi viia automatiseeritud UI-testimise Seleniumi vahenditega pideva integreerimise etapis.

Lõpetuseks

Soovin lõpetada järgmise mõttega: et saada kõrgelt kvalifitseeritud DevOps-inseneriks, on eluliselt tähtis õppida tõhusat inimestevaheline suhtlemist.

DevOps-insener on meeskonna mängija. Ja mitte muidu. Initsiatiiv suhtlemiseks kolleegidega peab tulema temalt endalt, mitte mingi olukorra ajendil. DevOps-spetsialist peab nägema ja pakkuma meeskonnale parimat lahendust.

Ja jah, iga lahenduse rakendamine nõuab palju arutelusid, ning lõpuks võib see täiesti muutuda. Iseseisvalt arenedes, pakkudes ja tehes oma ideid — selline inimene omab üha suuremat väärtust nii meeskonna kui ka tööandja jaoks. Mis lõppkokkuvõttes kajastub tema kuusissetulekus või lisapreemiates.

Allikas: habr.com