Af hverju ættu kerfisstjórar, forritarar og prófunaraðilar að læra DevOps venjur?

Af hverju ættu kerfisstjórar, forritarar og prófunaraðilar að læra DevOps venjur?

Hvert á að fara með þessa þekkingu, hvað á að gera í verkefninu og hversu mikið á að vinna sér inn, hvað á að segja og spyrja í viðtali - segir Alexander Titov, framkvæmdastjóri Express 42 og höfundur netnámskeið „DevOps venjur og verkfæri“.

Halló! Þrátt fyrir að hugtakið DevOps hafi verið til síðan 2009, er enn engin samstaða í rússneska samfélaginu. Þú hefur sennilega tekið eftir því að sumir líta á DevOps sem sérgrein, aðrir líta á það sem heimspeki og aðrir telja hugtakið safn af tækni. Ég hef þegar komið fram margoft með fyrirlestra um þróun þessarar stefnu, svo ég mun ekki fara nánar út í þessa grein. Leyfðu mér bara að segja að á Express 42 erum við með eftirfarandi í því:

DevOps er ákveðin aðferðafræði, menning þess að búa til stafræna vöru, þegar allir sérfræðingar í teyminu taka þátt í framleiðslu.

Í klassískri fyrirtækjaþróun fer allt í röð: Forritun, prófun og aðeins síðan rekstur, og hraði þessa ferlis frá hugmynd til framleiðslu er 3 mánuðir. Þetta er alþjóðlegt vandamál fyrir stafrænar vörur, vegna þess að það er ómögulegt að fá fljótt endurgjöf frá viðskiptavinum.

Í DevOps eru verkfæri og aðferðir hönnuð til að tryggja að þróunar-, prófunar- og rekstrarferlar gangi samtímis.

Hvað leiðir af þessari nálgun?

  • Þú getur ekki ráðið einhvern „verkfræðing“ sem mun koma og leysa öll vandamál með framleiðslu. Allt liðið verður að beita tækninni.

    Af hverju ættu kerfisstjórar, forritarar og prófunaraðilar að læra DevOps venjur?

  • DevOps er EKKI næsta form kerfisstjóra til að uppfæra í. „DevOps verkfræðingur“ hljómar um það bil það sama og „lipur verktaki“.

    Af hverju ættu kerfisstjórar, forritarar og prófunaraðilar að læra DevOps venjur?

  • Ef teymi notar Kubernetes, Ansible, Prometheus, Mesosphere og Docker þýðir það ekki að DevOps venjur hafi verið innleiddar þar.

    Af hverju ættu kerfisstjórar, forritarar og prófunaraðilar að læra DevOps venjur?

Lífið eftir DevOps verður aldrei það sama

DevOps nálgunin er í fyrsta lagi annar hugsunarháttur, skynjun á þróun í heild og stað manns í ferlinu. Við skiptum netnámskeiðinu okkar í 2 blokkir:

1. Sjálfsákvörðunarréttur

Í fyrsta lagi skoðum við ítarlega kjarna DevOps nálgunarinnar og nemendur uppgötva ný hlutverk í teyminu, sjá hver svarar meira og ákveða sjálfir í hvaða átt þeir eiga að þróast.

2. Verkfæri og venjur

Nemendur ná tökum á tiltekinni tækni frá sjónarhóli DevOps aðferðarinnar.

Hægt er að nota DevOps verkfæri bæði í DevOps nálguninni og í klassískri þróun. Augljósasta dæmið væri að nota Ansible stillingarstjórnunartólið. Það var búið til og hugsað til að innleiða DevOps aðferðina „Infrastructure as Code“ sem þýðir að mismunandi ástandi kerfisins er lýst, allt frá stýrikerfisstillingum til forritahugbúnaðar. Lýsingunni er skipt í lög og gerir þér kleift að stjórna flókinni uppsetningu sem er stöðugt að breytast. En verkfræðingar nota oft Ansible sem leið til að keyra bash forskriftir á mörgum vélum. Þetta er hvorki slæmt né gott, en þú verður að skilja að tilvist Ansible tryggir ekki tilvist DevOps í fyrirtækinu.

Við erum á ferli námskeið Þú verður á kafi í því ferli að þróa forrit sem líkist hinum fræga Reddit, byrjar með einlita útgáfu þess, færist skref fyrir skref yfir í örþjónustur. Skref fyrir skref munum við ná tökum á nýjum verkfærum: Git, Ansible, Gitlab og klára með Kubernetes og Prometheus.

Hvað varðar starfshætti munum við fylgja aðferðum þeirra þriggja leiða sem lýst er í DevOps handbókinni - stöðugar sendingaraðferðir, endurgjöfarvenjur og kjarninn í öllu námskeiðinu er að æfa stöðugt nám ásamt kerfinu þínu.

Hvað gefur þessi þekking hverjum og einum af sérfræðingunum?

Fyrir kerfisstjóra

Starfshættir munu leyfa þér að hverfa frá stjórnun í átt að því að búa til samfellda afhendingarleiðslu og innviðavettvang fyrir afhendingu hugbúnaðar. Aðalatriðið er að hann býr til vöru - innviðavettvang fyrir þróunaraðila sem hjálpar þeim að ýta fljótt breytingum sínum á framleiðslu.

Áður voru kerfisstjórar síðasta vígið, eftir það fer allt í framleiðslu. Og í grundvallaratriðum tóku þeir þátt í stöðugri slökkvistörfum - í ljósi þess er frekar erfitt að kafa ofan í þarfir fyrirtækisins, hugsa um vöruna og ávinninginn fyrir notandann.
Þökk sé DevOps aðferðinni breytist hugsunin. Kerfisstjórinn skilur hvernig á að þýða stillingarnar í kóða, hvaða venjur eru til fyrir þetta.

Þetta er mikilvægt vegna þess að fyrirtæki átta sig í auknum mæli á því að þau þurfa ekki bara að gera allt sjálfvirkt, þ.e. í því sem stjórnendur gamla skólakerfisins voru í raun vanir að gera, sem plús þetta tjáðu lítið og upplýstu liðið ekki um allar breytingar sem gerðar voru. Nú eru liðin að leita að þeim sem verða framleiðandi innri innviðavörunnar og hjálpa til við að sameina aðskilda ferla í eitt.

Hönnuðir

Framkvæmdaraðilinn hættir að hugsa aðeins í reikniritum. Hann öðlast færni í að vinna með innviði, kunnáttu í byggingarvitund um landslag. Slíkur þróunaraðili skilur hvernig forritið virkar, hvernig það fer í gegnum samfellda afhendingarleiðslu, hvernig á að fylgjast með því, hvernig á að skrá það þannig að það gagnist viðskiptavininum. Þess vegna gerir öll þessi þekking þér kleift að skrifa viðeigandi kóða.

Fyrir prófunaraðila

Prófun hefur lengi verið að færast yfir í sjálfvirka stillingu; við segjum öll að mörg próf eigi ekki að gera heldur skrifleg :) Prófun verður hluti af allri afhendingu vörunnar þinnar. Prófari þarf ekki aðeins að læra hvernig á að skrifa kóða, heldur einnig að skilja hvernig á að samþætta hann í samfelld afhendingarkerfi, hvernig á að fá endurgjöf frá kóðanum á öllum stigum afhendingar og hvernig á að bæta stöðugt prófanir til að greina villur sem snemma og hægt er.

Svo kemur í ljós að öll þrjú stigin eiga sér stað samtímis. Til dæmis gæti það litið svona út:

Framkvæmdaraðilinn skrifar kóðann, skrifar strax próf fyrir hann og lýsir docker ílát fyrir kóðann sem ætti að keyra. Þar er líka strax lýst því eftirliti sem mun fylgjast með rekstri þessarar þjónustu í framleiðslu og skuldbindur sig allt þetta.

Þegar samfelld samþætting hefst keyra ferlar samtímis. Þjónustan byrjar og er stillt. Á sama tíma fer docker gámurinn í gang og athugað er að hann sé í gangi. Á sama tíma fara allar upplýsingar í skógarhöggskerfið. Og svo framvegis á hverju stigi þróunar - það reynist vera raunverulegt teymisvinna kerfisstjóra, þróunaraðila og prófunaraðila.

Ég lærði DevOps, hvað næst?

Eins og þú veist er einn á sviði ekki stríðsmaður. Ef fyrirtæki þitt notar ekki þessa aðferð mun áunnin færni liggja aðgerðarlaus. Og eftir að hafa kynnst DevOps nálgun, muntu líklegast ekki vilja vera tannhjól í fyrirtækjaþróun. Það gæti verið ein undantekning: þú ert kerfisstjóri í teyminu og getur endurbyggt öll ferli á nýjan hátt. Það er þess virði að bæta við hér að það eru mörg fyrirtæki sem nota þessa nálgun og þau verða ekki fyrir áhrifum af lokuninni og eru að leita að sérfræðingum. Vegna þess að DevOps snýst um að búa til vörur á netinu.

Og nú um það góða: vald á DevOps starfsháttum og verkfærum er um það bil +30% af verðmæti þínu á vinnumarkaði. Laun byrja frá 140 þúsund rúblum, en eru auðvitað ákvörðuð af helstu sérgrein þinni og virkni.

Hægt er að skoða laus störf merkt „innviðamiðuð“ þar sem er sjálfvirkni prófana, þróun á smáþjónustuforritum með skýjatækni, laus störf fyrir innviðaverkfræðinga og alls kyns tilvísanir í DevOps. Mundu bara að hvert fyrirtæki þýðir eitthvað öðruvísi með þessari skilgreiningu - lestu lýsinguna vandlega.

Við upphaf námskeiðsins okkar kom innsýn til mín - margir eftir námskeiðið falla í gildru DevOps verkfræðings. Þeir finna laust starf með ofangreindum titli, fá gott tilboð og koma svo til vinnu og átta sig á því að þeir verða að halda úti þriggja blaðsíðna bash-handriti í Jenkins. Hvar eru Kubernetes, ChatOps, kanaríútgáfur og allt það? En það er ekkert, því fyrirtækið þarf ekki DevOps sem aðferðafræði heldur notar einstakar nýjungar.

Þetta er ástæða til að kanna ítarlega frá fyrirtækinu hvernig hugbúnaðarafhendingarferlið virkar, tæknistaflann og hvaða ábyrgð þú munt sinna.

Ef vinnuveitandinn svarar spurningum þínum óhlutbundið, eins og úr bók, án smáatriði, þá er líklegast ekkert DevOps ferli í fyrirtækinu ennþá, en þetta er ekki ástæða til að neita, rannsaka fyrirtækið og vörur þess, hvort það sé á netinu þjónustu sem fyrirtækið þróar sjálft, farsímaforrit, vöruhugmyndir.

Ef já, þá skýrðu hvort þú verður að vinna beint með þessi kerfi eða hvort möguleiki sé á láréttri hreyfingu til teyma þessara þjónustu á sama tíma og þú sýnir góðan árangur í DevOps starfsháttum. Ef já, þá er það þess virði að fara og vera virkur og gagnlegur, og ef þú klárar námskeiðið okkar er það síðara tryggt.

Það er mikilvægt að hafa í huga að Devops iðkendur öðlast raunverulegt gildi aðeins með reynslu í þróun/stjórnun/prófun. Aðeins þá verður þekkingin ekki óhlutbundin, heldur auðgar sérfræðinginn (í öllum skilningi). Þess vegna er hugmyndin um að „læra DevOps frá grunni“ um það bil sú sama og að læra að „nota linsur frá grunni“ ef þú hefur aldrei haft myndavél í höndunum eða stjórnað myndatöku. Til að hjálpa þér að ákveða hvort námskeiðið sé rétt fyrir þig höfum við gert inntökupróf sem mun athuga nægilega þekkingu þína.

Ég held að ein af brögðunum námskeið — að á meðan á þjálfun stendur ákveður hver nemandi sjálfur í hvaða átt hann vill þróast. Við sjáum oft umskipti þegar þróunaraðili verður innviðaverkfræðingur og stjórnandi áttar sig á því að hann hefur áhuga á að skrifa kóða - þá lærir hann frekar tungumálið og bætir við það með áunninni DevOps færni. Því bjóðum við sérstaklega velkomna þá sem telja að starfsferill þeirra standi á tímamótum. Námskeiðið hefst 28. maí en hægt er að vera með 2 vikum eftir að kennsla hefst. Þú getur skoðað dagskrána og tekið prófið по ссылке. Sjáumst á OTUS!

Heimild: www.habr.com

Bæta við athugasemd