Hverjir eru DevOps?

Í augnablikinu er þetta nánast dýrasta staðan á markaðnum. Ólætin í kringum „DevOps“ verkfræðinga eru yfir öllum hugsanlegum mörkum, og enn verra hjá eldri DevOps verkfræðingum.
Ég starfa sem yfirmaður samþættingar- og sjálfvirknideildar, giska á enska afkóðun - DevOps Manager. Það er ólíklegt að enska afritið endurspegli daglegar athafnir okkar, en rússneska útgáfan í þessu tilfelli er nákvæmari. Vegna eðlis starfsemi minnar er eðlilegt að ég þurfi að taka viðtöl við framtíðarmeðlimi í teyminu mínu og síðastliðið ár hafa um 50 manns farið í gegnum mig og sama fjöldi hefur verið klipptur af á forskjá hjá starfsmönnum mínum.

Við erum enn að leita að samstarfsmönnum, því á bak við DevOps merkið leynist mjög stórt lag af mismunandi gerðum verkfræðinga.

Allt sem skrifað er hér að neðan er mín persónulega skoðun, þú þarft ekki að vera sammála henni, en ég viðurkenni að það mun setja lit á afstöðu þína til efnisins. Þrátt fyrir hættuna á því að falla úr greipum, birti ég skoðun mína vegna þess að ég tel að hún eigi stað til að vera.

Fyrirtæki hafa mismunandi skilning á því hverjir DevOps verkfræðingar eru og til að geta ráðið auðlind fljótt hengja þau þennan merkimiða á alla. Staðan er nokkuð undarleg þar sem fyrirtæki eru tilbúin að greiða þessu fólki óraunhæf þóknun og fá í flestum tilfellum verkfærastjóra fyrir það.

Svo hverjir eru DevOps verkfræðingar?

Byrjum á sögu útlits þess - Þróunarrekstur birtist sem enn eitt skrefið í átt að hagræðingu samspils í litlum teymum til að auka hraða vöruframleiðslu, sem væntanleg afleiðing. Hugmyndin var að efla þróunarteymið með þekkingu á verklagi og nálgunum við stjórnun vöruumhverfis. Með öðrum orðum, verktaki verður að skilja og vita hvernig vara hans virkar við ákveðnar aðstæður, verður að skilja hvernig á að dreifa vöru sinni, hvaða eiginleika umhverfisins er hægt að aðlaga til að bæta árangur. Svo í nokkurn tíma birtust verktaki með DevOps nálgun. DevOps forritarar skrifuðu byggingar- og pökkunarforskriftir til að einfalda starfsemi sína og frammistöðu framleiðsluumhverfisins. Hins vegar fór flókið lausnararkitektúr og gagnkvæm áhrif innviðaíhluta með tímanum að versna frammistöðu umhverfisins; með hverri endurtekningu var krafist sífellt dýpri skilnings á ákveðnum hlutum, sem minnkaði framleiðni þróunaraðilans vegna viðbótar kostnaður við að skilja íhluti og stilla kerfi fyrir tiltekið verkefni. . Eigin kostnaður þróunaraðilans jókst, kostnaðurinn við vöruna ásamt því, kröfurnar til nýrra þróunaraðila í teyminu stækkuðu verulega, vegna þess að þeir þurftu líka að standa straum af ábyrgð þróunar„stjörnunnar“ og náttúrulega urðu „stjörnurnar“ minni og minna í boði. Það er líka athyglisvert að, samkvæmt minni reynslu, hafa fáir forritarar áhuga á sérstöðu pakkavinnslu með stýrikerfiskjarna, pakkaleiðarreglum og öryggisþáttum hýsingaraðila. Rökrétta skrefið var að laða að stjórnanda sem þekkir þetta og fela honum svipaðar skyldur, sem, þökk sé reynslu hans, gerði það mögulegt að ná sömu vísbendingum með lægri kostnaði miðað við kostnað við "stjörnu" þróun. Slíkir stjórnendur voru settir í teymi og var aðalverkefni hans að stjórna prófunar- og framleiðsluumhverfi, samkvæmt reglum tiltekins teymis, með fjármagni úthlutað til þessa tiltekna teymi. Svona birtist reyndar DevOps í hugum meirihlutans.

Að hluta eða öllu leyti, með tímanum, fóru þessir kerfisstjórar að skilja þarfir þessa tiltekna teymis á sviði þróunar, hvernig á að auðvelda þróunaraðilum og prófurum lífið, hvernig á að setja upp uppfærslu og þurfa ekki að gista á föstudegi í skrifstofunni, leiðrétta villur við uppsetningu. Tíminn leið og nú voru „stjörnurnar“ kerfisstjórar sem skildu hvað forritarar vildu. Til að lágmarka áhrifin fóru að koma upp stjórnunartól; allir mundu eftir gömlu og áreiðanlegu aðferðunum við að einangra stýrikerfisstigið, sem gerði það mögulegt að lágmarka kröfur um öryggi, stjórnun nethluta og hýsilstillingar sem a. heild og þar af leiðandi draga úr kröfum um nýjar „stjörnur“.

„Dásamlegur“ hlutur hefur birst - hafnarmaður. Hvers vegna dásamlegt? Já, aðeins vegna þess að það að búa til einangrun í chroot eða fangelsi, sem og OpenVZ, krafðist óléttrar þekkingar á stýrikerfinu, öfugt, tólið gerir þér kleift að búa til einangrað forritaumhverfi á ákveðnum hýsingaraðila með allt sem þarf inni og fyrir hendi. yfir stjórnartaumana aftur, og kerfisstjórinn getur aðeins stjórnað með aðeins einum gestgjafa, sem tryggir öryggi hans og mikið aðgengi - rökrétt einföldun. En framfarir standa ekki í stað og kerfi eru aftur að verða flóknari og flóknari, það eru fleiri og fleiri íhlutir, einn gestgjafi uppfyllir ekki lengur þarfir kerfisins og það þarf að byggja klasa, við erum aftur að snúa aftur til kerfisstjóra sem eru geta byggt upp þessi kerfi.

Hring eftir lotu birtast ýmis kerfi sem einfalda þróun og/eða stjórnun, hljómsveitarkerfi koma fram sem eru auðveld í notkun þar til þú þarft að víkja frá stöðluðu ferli. Örþjónustuarkitektúr birtist einnig með það að markmiði að einfalda allt sem lýst er hér að ofan - færri sambönd, auðveldara í stjórnun. Mín reynsla er sú að ég fann ekki algjörlega örþjónustuarkitektúr, ég myndi segja að 50 til 50 - 50 prósent af örþjónustu, svörtum kössum, komu inn, komu út unnin, hinar 50 eru rifinn einliða, þjónustur geta ekki virkað aðskildar frá öðrum íhlutir. Allt þetta setti aftur takmarkanir á þekkingarstig bæði forritara og stjórnenda.

Svipaðar „sveiflur“ í stigi sérfræðiþekkingar á tiltekinni auðlind halda áfram til þessa dags. En við víkjum aðeins, það eru mörg atriði sem vert er að draga fram.

Byggingarverkfræðingur/útgáfuverkfræðingur

Mjög sérhæfðir verkfræðingar sem komu fram sem leið til að staðla ferla og útgáfur hugbúnaðargerðar. Í því ferli að kynna útbreiddan Agile virðist sem þeir hættu að vera eftirsóttir, en það er langt frá því að vera raunin. Þessi sérhæfing birtist sem leið til að staðla samsetningu og afhendingu hugbúnaðar á iðnaðarskala, þ.e. nota staðlaða tækni fyrir allar vörur fyrirtækisins. Með tilkomu DevOps misstu verktaki að hluta til virkni sína, þar sem það voru verktaki sem fóru að undirbúa vöruna fyrir afhendingu, og í ljósi breyttra innviða og nálgunar til að afhenda eins fljótt og auðið er án tillits til gæða, breyttust þeir með tímanum í stöðvun breytinga, þar sem farið er að gæðastöðlum hægir óhjákvæmilega á afhendingum. Svo smám saman fluttist hluti af virkni Build/Release verkfræðinga yfir á herðar kerfisstjóra.

Ops eru svo mismunandi

Við höldum áfram og aftur tilvist fjölbreyttrar ábyrgðar og skortur á hæfu starfsfólki ýtir okkur í átt að strangri sérhæfingu, eins og sveppir eftir rigningu, ýmsar aðgerðir birtast:

  • TechOps - enikey kerfisstjórar aka HelpDesk Engineer
  • LiveOps - kerfisstjórar sem bera fyrst og fremst ábyrgð á framleiðsluumhverfi
  • CloudOps - kerfisstjórar sem sérhæfa sig í almenningsskýjum Azure, AWS, GCP o.s.frv.
  • PlatOps/InfraOps/SysOps - innviðakerfisstjórar.
  • NetOps - netkerfisstjórar
  • SecOps - kerfisstjórar sem sérhæfa sig í upplýsingaöryggi - PCI samræmi, CIS samræmi, patching o.fl.

DevOps er (í orði) einstaklingur sem skilur af eigin raun alla ferla þróunarferilsins - þróun, prófun, skilur vöruarkitektúr, er fær um að meta öryggisáhættu, þekkir nálganir og sjálfvirkniverkfæri, að minnsta kosti í hámarki. stigi, auk þessa, skilur einnig for- og eftirvinnslu stuðning við útgáfu vöru. Einstaklingur sem getur komið fram sem talsmaður bæði reksturs og þróunar, sem gerir ráð fyrir hagstæðri samvinnu á milli þessara tveggja stoða. Skilur ferla skipulagsvinnu teyma og stjórnun væntinga viðskiptavina.

Til að framkvæma þessa tegund vinnu og ábyrgðar verður þessi einstaklingur að hafa burði til að stjórna ekki aðeins þróunar- og prófunarferlum, heldur einnig stjórnun vöruinnviða, sem og auðlindaáætlun. DevOps í þessum skilningi er hvorki hægt að finna í upplýsingatækni, né í rannsóknum og þróun, eða jafnvel í PMO; það verður að hafa áhrif á öllum þessum sviðum - tæknistjóri fyrirtækisins, tæknistjóri.

Er þetta satt í þínu fyrirtæki? - Ég efast. Í flestum tilfellum er þetta annað hvort upplýsingatækni eða R&D.

Skortur á fjármunum og getu til að hafa áhrif á að minnsta kosti eitt af þessum þremur starfssviðum mun færa vægi vandamála í átt að því þar sem auðveldara er að beita þessum breytingum, svo sem beitingu tæknilegra takmarkana á útgáfum í tengslum við „óhreinan“ kóða samkvæmt static greiningarkerfi. Það er að segja, þegar PMO setur strangan frest til að gefa út virkni, getur R&D ekki skilað hágæða niðurstöðu innan þessara fresta og framleiðir hana eins og best verður á kosið, og skilur endurstillingu eftir til síðari tíma, DevOps sem tengjast upplýsingatækni hindrar útgáfuna með tæknilegum hætti . Skortur á heimild til að breyta aðstæðum, þegar um ábyrga starfsmenn er að ræða, leiðir til birtingarmyndar ofábyrgðar á því sem þeir geta ekki haft áhrif á, sérstaklega ef þessir starfsmenn skilja og sjá mistök og hvernig á að leiðrétta þau - "Sæla er fáfræði", og sem afleiðing af kulnun og missi þessara starfsmanna.

DevOps auðlindamarkaður

Við skulum skoða nokkur laus störf fyrir DevOps stöður frá mismunandi fyrirtækjum.

Við erum tilbúin að hitta þig ef þú:

  1. Þú átt Zabbix og veist hvað Prometheus er;
  2. Iptables;
  3. BASH doktorsnemi;
  4. Prófessor Ansible;
  5. Linux sérfræðingur;
  6. Vita hvernig á að nota villuleit og finna forritavandamál ásamt hönnuðum (php/java/python);
  7. Vegagerð gerir þig ekki hysterískan;
  8. Gefðu verulega eftirtekt til kerfisöryggis;
  9. Taktu öryggisafrit af "allt og allt", og endurheimtu einnig þetta "allt og allt";
  10. Þú veist hvernig á að stilla kerfið á þann hátt að ná hámarki út úr lágmarkinu;
  11. Settu upp afritun áður en þú ferð að sofa á Postgres og MySQL;
  12. Að setja upp og stilla CI/CD er eins nauðsynlegt fyrir þig og morgunmatur/hádegisverður/kvöldverður.
  13. Hafa reynslu af AWS;
  14. Tilbúinn til að þróa með fyrirtækinu;

Svo:

  • frá 1 til 6 - kerfisstjóri
  • 7 - smá netstjórnun, sem passar líka inn í kerfisstjórann, miðstig
  • 8 - smá öryggi, sem er nauðsynlegt fyrir miðstigs kerfisstjóra
  • 9-11 - Miðkerfisstjóri
  • 12 — Það fer eftir úthlutuðum verkefnum, annað hvort miðkerfisstjóri eða byggingarverkfræðingur
  • 13 - Sýndarvæðing - Miðkerfisstjóri, eða svokallaður CloudOps, háþróuð þekking á þjónustu tiltekinnar hýsingarsíðu, til að nýta fjármuni á skilvirkan hátt og draga úr álagi á viðhald

Þegar við tökum saman þetta lausa starf getum við sagt að mið-/eldri kerfisstjóri sé nóg fyrir strákana.

Við the vegur, þú ættir ekki sterklega að skipta stjórnendum á Linux / Windows. Auðvitað skil ég að þjónusta og kerfi þessara tveggja heima eru ólík, en grunnurinn fyrir alla er sá sami og sérhver stjórnandi sem ber virðingu fyrir sjálfum sér kannast við bæði einn og annan, og jafnvel þótt hann þekki ekki, mun það ekki erfitt fyrir hæfan stjórnanda að kynnast því.

Við skulum íhuga annað laust starf:

  1. Reynsla í að byggja upp háhleðslukerfi;
  2. Frábær þekking á Linux OS, almennum kerfishugbúnaði og vefstakka (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
  3. Reynsla af sýndarvæðingarkerfum (KVM, VMWare, LXC/Docker);
  4. Færni í forskriftarmálum;
  5. Skilningur á rekstrarreglum netsamskiptaneta;
  6. Skilningur á meginreglum þess að byggja bilunarþolin kerfi;
  7. Sjálfstæði og frumkvæði;

Við skulum skoða:

  • 1 - Yfirkerfisstjóri
  • 2 - Það fer eftir merkingunni sem sett er í þennan stafla - Mið-/Senior kerfisstjóri
  • 3 - Starfsreynsla, þar á meðal, gæti þýtt - "Klasinn vakti ekki, heldur bjó til og stjórnaði sýndarvélum, það var einn Docker gestgjafi, aðgangur að gámum var ekki tiltækur" - Miðkerfisstjóri
  • 4 - Yngri kerfisstjóri - já, stjórnandi sem kann ekki að skrifa grunn sjálfvirkniforskriftir, óháð tungumáli, ekki admin - enikey.
  • 5 - Miðkerfisstjóri
  • 6 - Yfirkerfisstjóri

Til að draga saman - Mið-/Senior kerfisstjóri

Annar:

  1. Eykur reynslu;
  2. Reynsla af því að nota eina eða fleiri vörur til að búa til CI/CD ferla. Gitlab CI mun vera kostur;
  3. Vinna með gáma og sýndarvæðingu; Ef þú notaðir docker, gott, en ef þú notaðir k8s, frábært!
  4. Reynsla af því að vinna í lipru teymi;
  5. Þekking á hvaða forritunarmáli sem er;

Látum okkur sjá:

  • 1 - Hmm... Hvað meina strákarnir? =) Líklegast vita þeir sjálfir ekki hvað leynist á bakvið það
  • 2 - Byggingarverkfræðingur
  • 3 - Miðkerfisstjóri
  • 4 - Mjúk færni, við munum ekki íhuga það í bili, þó að Agile sé annað sem er túlkað á þægilegan hátt.
  • 5 - Of orðrétt - það gæti verið forskriftarmál eða samsett. Ég velti því fyrir mér hvort það henti þeim að skrifa í Pascal og Basic í skólanum? =)

Ég vil líka skilja eftir aths. varðandi lið 3 til að efla skilning á því hvers vegna þessi liður fellur undir kerfisstjóra. Kubernetes er bara hljómsveit, tól sem vefur beinar skipanir til netrekla og sýndarvæðingar/einangrunarhýsinga í nokkrum skipunum og gerir þér kleift að gera samskipti við þá óhlutbundin, það er allt. Til dæmis, tökum „byggja ramma“ Make, sem ég lít á sem ramma ekki. Já, ég veit um tískuna að troða Make hvar sem er, þar sem það er nauðsynlegt og óþarft - að pakka Maven inn í Make, til dæmis, alvarlega?
Í meginatriðum er Make bara umbúðir yfir skelina, sem einfaldar samansafn, tengingar og safnumhverfisskipanir, rétt eins og k8s.

Einu sinni tók ég viðtal við gaur sem notaði k8s í starfi sínu ofan á OpenStack, og hann talaði um hvernig hann notaði þjónustu á það, hins vegar, þegar ég spurði um OpenStack, kom í ljós að það var stjórnað, auk þess að hækka með kerfi. stjórnendur. Heldurðu virkilega að sá sem hefur sett upp OpenStack, óháð því hvaða vettvang hann notar fyrir aftan sig, geti ekki notað k8s? =)
Þessi umsækjandi er í raun ekki DevOps, heldur kerfisstjóri og til að vera nákvæmari, Kubernetes stjórnandi.

Við skulum draga saman enn og aftur - Mið-/Senior kerfisstjóri verður nóg fyrir þá.

Hversu mikið á að vega í grömmum

Fyrirhuguð laun fyrir tilgreind laus störf eru á bilinu 90k-200k
Nú langar mig að draga hliðstæðu á milli peningalegra umbun kerfisstjóra og DevOps verkfræðinga.

Í grundvallaratriðum, til að einfalda hlutina, geturðu dreift einkunnum út frá starfsreynslu, þó að það sé ekki nákvæmt, en í tilgangi greinarinnar mun það duga.

Upplifun:

  1. allt að 3 ára - yngri
  2. allt að 6 ára - Mið
  3. fleiri en 6 – eldri

Starfsmannaleitarsíðan býður upp á:
Kerfisstjórar:

  1. Unglingur - 2 ára - 50 þúsund kr.
  2. Mið - 5 ár - 70k nudda.
  3. Eldri - 11 ára - 100 þúsund kr.

DevOps verkfræðingar:

  1. Unglingur - 2 ára - 100 þúsund kr.
  2. Mið - 3 ár - 160k nudda.
  3. Eldri - 6 ára - 220 þúsund kr.

Samkvæmt reynslunni af „DevOps“ var reynsla notuð sem hafði að minnsta kosti einhvern veginn áhrif á SDLC.

Af ofangreindu leiðir að í raun þurfa fyrirtæki ekki DevOps, og einnig að þau gætu sparað að minnsta kosti 50 prósent af upphaflega áætluðum kostnaði með því að ráða stjórnanda; þar að auki gætu þau skilgreint betur ábyrgð þess sem þau eru að leita að og fylla þörfina hraðar. Ekki má heldur gleyma því að skýr verkaskipting gerir okkur kleift að draga úr kröfum um mannskap, auk þess að skapa hagstæðara andrúmsloft í liðinu, þar sem skörun er ekki til staðar. Langflest laus störf eru full af tólum og DevOps merkjum, en þau eru ekki byggð á raunverulegum kröfum til DevOps verkfræðings, aðeins beiðnum um verkfærastjóra.

Ferlið við að þjálfa DevOps verkfræðinga er einnig takmarkað við safn af sérstökum verkum, tólum og veitir ekki almennan skilning á ferlunum og ósjálfstæði þeirra. Það er vissulega gott þegar einstaklingur getur sett upp AWS EKS með Terraform, ásamt Fluentd hliðarvagninum í þessum klasa og AWS ELK stafla fyrir skógarhöggkerfið á 10 mínútum, með því að nota aðeins eina skipun í stjórnborðinu, en ef hann skilur ekki meginreglan um að vinna úr sjálfum annálum og fyrir hvað þeir eru nauðsynlegir, ef þú veist ekki hvernig á að safna mælingum um þá og fylgjast með niðurbroti þjónustunnar, þá mun það samt vera sami enikey sem veit hvernig á að nota sum tól.

Eftirspurn skapar hins vegar framboð og við sjáum mjög ofhitnaðan markað fyrir DevOps stöðuna þar sem kröfurnar samsvara ekki raunverulegu hlutverki heldur leyfa kerfisstjórum aðeins að græða meira.

Svo hverjir eru þeir? DevOps eða gráðugir kerfisstjórar? =)

Hvernig á að halda áfram að lifa?

Atvinnurekendur ættu að móta kröfur nákvæmari og leita nákvæmlega til þeirra sem þörf er á en ekki henda merkimiðum. Þú veist ekki hvað DevOps gera - þú þarft þá ekki í því tilfelli.

Starfsmenn - Lærðu. Bættu stöðugt þekkingu þína, skoðaðu heildarmynd ferla og fylgdu leiðinni að markmiði þínu. Þú getur orðið hver sem þú vilt, þú verður bara að reyna.

Heimild: www.habr.com

Bæta við athugasemd