DevOps hefur orðið mjög vinsælt umræðuefni undanfarin ár. Marga dreymir um að vera með, en eins og æfingin sýnir, oft aðeins vegna launastigsins.
Sumir skrá DevOps á ferilskrá sinni, þó þeir viti eða skilji ekki alltaf kjarna hugtaksins. Sumir halda að eftir að hafa lært Ansible, GitLab, Jenkins, Terraform og þess háttar (hægt að halda áfram með listann eftir smekk þínum), verðir þú strax „devopsist“. Þetta er auðvitað ekki satt.
Undanfarin ár hef ég aðallega tekið þátt í innleiðingu DevOps í ýmsum fyrirtækjum. Þar áður starfaði hann í meira en 20 ár við störf allt frá kerfisstjóra til upplýsingatæknistjóra. Sem stendur DevOps aðalverkfræðingur hjá Playgendary.
Hver er DevOps
Hugmyndin um að skrifa grein vaknaði eftir aðra spurningu: „hver er DevOps? Það er enn ekkert staðfest orð yfir hvað eða hver það er. Sum svörin eru nú þegar í þessu . Fyrst mun ég draga fram helstu atriðin úr henni og síðan mun ég deila athugunum mínum og hugsunum.
DevOps er ekki sérfræðingur sem hægt er að ráða, ekki safn tóla, og ekki deild þróunaraðila með verkfræðinga.
DevOps er heimspeki og aðferðafræði.
Með öðrum orðum, þetta er sett af starfsháttum sem hjálpar forriturum að hafa virkan samskipti við kerfisstjóra. Það er að segja að tengja saman og samþætta verkferla hvert í annað.
Með tilkomu DevOps hélst uppbygging og hlutverk sérfræðinga óbreytt (það eru verktaki, það eru verkfræðingar), en samspilsreglur hafa breyst. Mörkin milli deilda hafa verið óljós.
Lýsa má markmiðum DevOps í þremur liðum:
- Hugbúnaðurinn þarf að uppfæra reglulega.
- Hugbúnaður verður að vera fljótur.
- Hugbúnaðurinn ætti að vera notaður á þægilegan hátt og á stuttum tíma.
Það er ekkert eitt tól fyrir DevOps. Að stilla, afhenda og rannsaka nokkrar vörur þýðir ekki að DevOps hafi birst í fyrirtækinu. Það er mikið af verkfærum og þau eru öll notuð á mismunandi stigum, en þjóna einum sameiginlegum tilgangi.
Og þetta er aðeins hluti af DevOps verkfærunum
Ég hef tekið viðtöl við fólk um stöðu DevOps verkfræðings í meira en 2 ár núna og ég hef áttað mig á því hversu mikilvægt það er að skilja kjarna hugtaksins vel. Ég hef safnað ákveðnum reynslu, athugunum og hugsunum sem ég vil deila.
Af reynslu viðtals sé ég eftirfarandi mynd: Sérfræðingar sem líta á DevOps sem starfsheiti hafa yfirleitt misskilning við samstarfsmenn.
Það var sláandi dæmi. Ungur maður kom í viðtal með mörg gáfuleg orð á ferilskránni. Í síðustu þremur störfum sínum hafði hann 5-6 mánaða reynslu. Ég yfirgaf tvö sprotafyrirtæki vegna þess að þau „fóru ekki á flug“. En um þriðja fyrirtækið sagði hann að enginn skildi hann þar: verktaki skrifa kóða á Windows og forstjórinn þvingar þennan kóða til að vera „vafinn“ inn í venjulegan Docker og innbyggðan í CI/CD leiðsluna. Gaurinn sagði margt neikvætt um núverandi vinnustað sinn og samstarfsmenn sína - ég vildi bara svara: "Þannig að þú munt ekki selja fíl."
Síðan spurði ég hann spurningar sem er ofarlega á listanum hjá hverjum frambjóðanda.
— Hvað þýðir DevOps fyrir þig persónulega?
- Almennt séð eða hvernig skynja ég það?
Ég hafði áhuga á persónulegu áliti hans. Hann þekkti kenninguna og uppruna hugtaksins en var mjög ósammála þeim. Hann taldi að DevOps væri starfsheiti. Þetta er þar sem rót vandamála hans liggur. Sem og aðrir sérfræðingar með sömu skoðun.
Vinnuveitendur, sem hafa heyrt mikið um „töfra DevOps“, vilja finna mann sem mun koma og búa til þennan „töfra“. Og umsækjendur úr flokknum „DevOps er starf“ skilja ekki að með þessari nálgun munu þeir ekki geta staðið undir væntingum. Og almennt skrifuðu þeir DevOps á ferilskrána sína vegna þess að það er þróun og þeir borga mikið fyrir það.
DevOps aðferðafræði og heimspeki
Aðferðafræðin getur verið fræðileg og hagnýt. Í okkar tilviki er það sá seinni. Eins og ég nefndi hér að ofan er DevOps sett af starfsháttum og aðferðum sem notuð eru til að ná yfirlýstum markmiðum. Og í hverju tilviki, allt eftir viðskiptaferlum fyrirtækisins, getur það verið verulega mismunandi. Sem gerir það ekki betra eða verra.
DevOps aðferðafræðin er aðeins leið til að ná markmiðum.
Nú um hvað DevOps hugmyndafræðin er. Og þetta er líklega erfiðasta spurningin.
Það er frekar erfitt að setja fram stutt og hnitmiðað svar, því það hefur ekki enn verið formgert. Og þar sem fylgjendur DevOps heimspekinnar eru meira uppteknir í reynd, þá er einfaldlega enginn tími fyrir heimspeki. Hins vegar er þetta mjög mikilvægt ferli. Þar að auki er það beintengt verkfræðistarfsemi. Það er meira að segja sérhæft þekkingarsvið - .
Það var engin slík grein í háskólanum mínum, ég þurfti að læra allt á eigin spýtur með því að nota efni sem ég fann á tíunda áratugnum. Efnið er valkvætt fyrir verkfræðimenntun, þess vegna skortir á formfestingu svarsins. En þeir sem eru alvarlega á kafi í DevOps byrjar að finna fyrir ákveðnum „anda“ eða „ómeðvitaðri alhliða“ allra ferla fyrirtækisins.
Með því að nota mína eigin reynslu reyndi ég að formfesta nokkrar af „stoðum“ þessarar heimspeki. Niðurstaðan er eftirfarandi:
- DevOps er ekki eitthvað sjálfstætt sem hægt er að aðgreina í sérstakt þekkingar- eða virknisvæði.
- Allir starfsmenn fyrirtækisins ættu að hafa DevOps aðferðafræðina að leiðarljósi þegar þeir skipuleggja starfsemi sína.
- DevOps hefur áhrif á alla ferla innan fyrirtækis.
- DevOps er til til að draga úr tímakostnaði fyrir hvaða ferla sem er innan fyrirtækis til að tryggja þróun þjónustu þess og hámarks þægindi viðskiptavina.
- DevOps, á nútímamáli, er fyrirbyggjandi staða hvers starfsmanns fyrirtækisins, sem miðar að því að draga úr tímakostnaði og bæta gæði upplýsingatæknivara í kringum okkur.
Ég held að "postúlurnar" mínar séu sérstakt umræðuefni. En nú er eitthvað til að byggja á.
Hvað DevOps gerir
Lykilorðið hér er samskipti. Það eru mörg samskipti, upphafsmaður þeirra ætti að vera nákvæmlega þessi sami DevOps verkfræðingur. Afhverju er það? Vegna þess að þetta er heimspeki og aðferðafræði, og aðeins þá verkfræðiþekking.
Ég get ekki talað með 100% trausti um vestrænan vinnumarkað. En ég veit töluvert um DevOps markaðinn í Rússlandi. Auk hundruða viðtala hef ég síðastliðið eitt og hálft ár tekið þátt í hundruðum tæknilegra forsölu fyrir „Innleiðing DevOps“ þjónustu fyrir stór rússnesk fyrirtæki og banka.
Í Rússlandi er DevOps enn mjög ungt, en þegar vinsælt efni. Eftir því sem ég best veit var skortur á slíkum sérfræðingum í Moskvu einni árið 2019 meira en 1000 manns. Og orðið Kubernetes fyrir vinnuveitendur er næstum eins og rauð tuska fyrir naut. Fylgjendur þessa tóls eru tilbúnir til að nota það jafnvel þar sem það er ekki nauðsynlegt og efnahagslega arðbært. Vinnuveitandinn skilur ekki alltaf í hvaða tilfellum hvað er réttara að nota og með réttri uppsetningu kostar viðhald á Kubernetes klasa 2-3 sinnum meira en að dreifa forriti með hefðbundnu klasakerfi. Notaðu það þar sem þú virkilega þarfnast þess.
Að innleiða DevOps er dýrt miðað við peninga. Og það er aðeins réttlætanlegt þar sem það hefur í för með sér efnahagslegan ávinning á öðrum sviðum, en ekki eitt og sér.
DevOps verkfræðingar eru í raun frumkvöðlar - það eru þeir sem ættu að vera fyrstir til að innleiða þessa aðferðafræði í fyrirtækinu og byggja upp ferla. Til að þetta gangi vel þarf sérfræðingurinn stöðugt að hafa samskipti við starfsmenn og samstarfsmenn á öllum stigum. Eins og ég segi venjulega ættu allir starfsmenn fyrirtækisins að taka þátt í DevOps innleiðingarferlinu: frá ræstingakonu til forstjóra. Og þetta er forsenda. Ef yngri meðlimurinn í teyminu veit ekki og skilur ekki hvað DevOps er og hvers vegna ákveðnar skipulagsaðgerðir eru gerðar, þá mun árangursrík innleiðing ekki virka.
Einnig þarf DevOps verkfræðingur að nota stjórnunarúrræði af og til. Til dæmis til að sigrast á „umhverfismótstöðu“ - þegar teymið er ekki tilbúið til að samþykkja DevOps verkfæri og aðferðafræði.
Verktaki ætti aðeins að skrifa kóða og próf. Til að gera þetta þarf hann ekki ofur öfluga fartölvu sem hann mun setja á og styðja á staðnum allan innviði verkefnisins. Til dæmis, framhlið verktaki geymir alla þætti forritsins á fartölvu sinni, þar á meðal gagnagrunninum, S3 keppinautinum (minio) o.s.frv. Það er, hann eyðir miklum tíma í að viðhalda þessum staðbundnu innviðum og glímir einn við öll vandamál slíkrar lausnar. Í stað þess að þróa kóða fyrir framhliðina. Slíkt fólk getur verið mjög ónæmt fyrir öllum breytingum.
En það eru lið sem þvert á móti eru fús til að kynna ný tæki og aðferðir og taka virkan þátt í þessu ferli. Þrátt fyrir að jafnvel í þessu tilfelli hafi ekki verið hætt við samskipti milli DevOps verkfræðingsins og liðsins.
Þegar DevOps er ekki þörf
Það eru aðstæður þar sem DevOps er ekki þörf. Þetta er staðreynd - það þarf að skilja og samþykkja hana.
Í fyrsta lagi á þetta við um öll fyrirtæki (sérstaklega lítil fyrirtæki), þegar hagnaður þeirra er ekki beint háður tilvist eða fjarveru upplýsingatæknivara sem veita viðskiptavinum upplýsingaþjónustu. Og hér erum við ekki að tala um vefsíðu fyrirtækisins, hvort sem það er kyrrstætt „viðskiptakort“ eða með kraftmiklum fréttablokkum osfrv.
DevOps er krafist þegar ánægja viðskiptavinar þíns og löngun hans til að snúa aftur til þín veltur á framboði þessara upplýsingaþjónustu fyrir samskipti við viðskiptavininn, gæðum þeirra og miðun.
Sláandi dæmi er einn þekktur banki. Fyrirtækið er ekki með hefðbundnar skrifstofur viðskiptavina, skjalaflæði fer fram með pósti eða sendiboðum og margir starfsmenn vinna heima. Fyrirtækið er hætt að vera bara banki og að mínu mati hefur það breyst í upplýsingatæknifyrirtæki með þróaða DevOps tækni.
Mörg önnur dæmi og fyrirlestra má finna í upptökum af þemafundum og ráðstefnum. Ég heimsótti sum þeirra persónulega - þetta er mjög gagnleg reynsla fyrir þá sem vilja þróast í þessa átt. Hér eru tenglar á YouTube rásir með góðum fyrirlestrum og efni um DevOps:
Horfðu nú á fyrirtækið þitt og hugsaðu um þetta: Hversu mikið er fyrirtæki þitt og hagnaður þess háð upplýsingatæknivörum til að gera samskipti viðskiptavina kleift?
Ef fyrirtækið þitt selur fisk í lítilli verslun og eina upplýsingatæknivaran er tvær 1C: Enterprise stillingar (bókhald og UNF), þá er varla skynsamlegt að tala um DevOps.
Ef þú vinnur hjá stóru verslunar- og framleiðslufyrirtæki (t.d. framleiðir þú veiðiriffla), þá ættirðu að hugsa um það. Þú getur tekið frumkvæðið og komið á framfæri við stjórnendur þínar horfur á innleiðingu DevOps. Jæja, og á sama tíma, leiða þetta ferli. Fyrirbyggjandi staða er ein af mikilvægum kenningum DevOps hugmyndafræðinnar.
Stærð og rúmmál árlegrar veltu er ekki aðalviðmiðið til að ákvarða hvort fyrirtæki þitt þurfi DevOps.
Ímyndum okkur stórt iðnaðarfyrirtæki sem hefur ekki bein samskipti við viðskiptavini. Til dæmis, sumir bílaframleiðendur og bílaframleiðendur. Ég er ekki viss núna, en af fyrri reynslu minni, í mörg ár fóru öll samskipti viðskiptavina fram í gegnum tölvupóst og síma.
Viðskiptavinir þeirra eru takmarkaður listi yfir bílasala. Og hverjum og einum er úthlutað sérfræðingi frá framleiðanda. Allt innra skjalaflæði á sér stað í gegnum SAP ERP. Innri starfsmenn eru í meginatriðum viðskiptavinir upplýsingakerfisins. En þessu IS er stjórnað með klassískum aðferðum til að stjórna klasakerfum. Sem útilokar möguleikann á að nota DevOps venjur.
Þess vegna er niðurstaðan: fyrir slík fyrirtæki er innleiðing DevOps ekki eitthvað afar mikilvægt, ef við munum markmið aðferðafræðinnar frá upphafi greinarinnar. En ég útiloka ekki að þeir noti nokkur DevOps verkfæri í dag.
Aftur á móti eru mörg lítil fyrirtæki sem þróa hugbúnað með DevOps aðferðafræði, heimspeki, starfsháttum og verkfærum. Og þeir telja að kostnaðurinn við að innleiða DevOps sé kostnaðurinn sem gerir þeim kleift að keppa á áhrifaríkan hátt á hugbúnaðarmarkaðnum. Dæmi um slík fyrirtæki má sjá .
Aðalviðmiðið til að skilja hvort DevOps sé þörf: hvaða gildi upplýsingatæknivörurnar þínar hafa fyrir fyrirtækið og viðskiptavini.
Ef aðalvara fyrirtækisins sem skilar hagnaði er hugbúnaður þarftu DevOps. Og það er ekki svo mikilvægt ef þú færð raunverulegan pening með því að nota aðrar vörur. Þetta felur einnig í sér netverslanir eða farsímaforrit með leikjum.
Allir leikir eru til þökk sé fjármögnun: beint eða óbeint frá leikmönnum. Hjá Playgendary þróum við ókeypis farsímaleiki með yfir 200 manns sem taka beinan þátt í sköpun þeirra. Hvernig notum við DevOps?
Já, nákvæmlega það sama og lýst er hér að ofan. Ég er í stöðugum samskiptum við þróunaraðila og prófunaraðila og stunda innri þjálfun fyrir starfsmenn um DevOps aðferðafræði og verkfæri.
Við erum nú virkir að nota Jenkins sem CI/CD leiðslutæki til að framkvæma allar samsetningarleiðslur með Unity og dreifingu í kjölfarið í App Store og Play Market. Meira úr klassíska verkfærakistunni:
- Asana - fyrir verkefnastjórnun. Samþætting við Jenkins hefur verið stillt.
- Google Meet - fyrir myndbandsfundi.
- Slack - fyrir samskipti og ýmsar viðvaranir, þar á meðal tilkynningar frá Jenkins.
- Atlassian Confluence - fyrir skjöl og hópvinnu.
Tafarlausar áætlanir okkar fela í sér að kynna kyrrstöðugreiningu með því að nota SonarQube og framkvæma sjálfvirkar notendaprófanir með seleni á stöðugu samþættingarstigi.
Í stað þess að niðurstöðu
Mig langar að enda á eftirfarandi hugsun: til að verða mjög hæfur DevOps verkfræðingur er mikilvægt að læra hvernig á að eiga samskipti við fólk í beinni útsendingu.
DevOps verkfræðingur er liðsmaður. Og ekkert annað. Frumkvæði í samskiptum við samstarfsmenn ætti að koma frá honum en ekki undir áhrifum sumra aðstæðna. DevOps sérfræðingur verður að sjá og leggja til bestu lausnina fyrir teymið.
Og já, innleiðing hvers konar lausnar mun krefjast mikillar umræðu og í lokin gæti hún breyst með öllu. Með því að þróa sjálfstætt, leggja fram hugmyndir og hrinda í framkvæmd, hefur slíkur einstaklingur aukið gildi bæði fyrir teymið og vinnuveitandann. Sem að lokum endurspeglast í upphæð mánaðarlegrar þóknunar hans eða í formi viðbótarbónusa.
Heimild: www.habr.com