Að undanförnu hafa slíkar auglýsingar flætt yfir netið. Þrátt fyrir ánægjuleg laun er ekki hægt annað en að skammast sín fyrir að villt villutrú sé skrifuð inni. Í fyrstu er gert ráð fyrir að „DevOps“ og „engineer“ geti einhvern veginn verið límd saman í eitt orð, og síðan er tilviljunarkenndur listi yfir kröfur, sem sumar eru greinilega afritaðar úr sysadmin lausu embættinu.
Í þessari færslu langar mig að tala aðeins um hvernig við komumst á þennan stað lífsins, hvað DevOps er í raun og veru og hvað á að gera við það núna.
Slík laus störf er hægt að fordæma á allan mögulegan hátt, en staðreyndin er enn: þau eru mörg og þannig virkar markaðurinn um þessar mundir. Við héldum devops ráðstefnu og lýstum yfir opinskátt: „ - ekki fyrir DevOps verkfræðinga." Þetta mun mörgum þykja undarlegt og villt: hvers vegna fólk sem er að gera algjörlega auglýsingaviðburð gengur gegn markaðnum. Nú munum við útskýra allt.
Um menningu og ferli
Við skulum byrja á því að DevOps er ekki verkfræðigrein. Þetta byrjaði allt á því að hin sögulega staðfestu hlutverkaskipting virkar ekki fyrir gæði vöru. Þegar forritarar forrita aðeins, en vilja ekki heyra neitt um prófun, er hugbúnaðurinn fullur af villum. Þegar stjórnendum er sama hvernig eða hvers vegna hugbúnaðurinn er skrifaður breytist stuðningur í helvíti.
Til dæmis að lýsa muninum á kerfisstjóra og SRE nálgun við þjónustustjórnun . Áhugaverðar rannsóknir hafa verið gerðar innan — Það er ljóst að bestu verktaki tekst einhvern veginn að setja nýjar breytingar á framleiðslu hraðar en einu sinni á klukkustund. Þeir prófa með höndunum ekki meira en 10% (þetta má sjá af ). Hvernig gera þeir þetta? „Excel or die“ segir í einni af fyrirsögnum skýrslunnar. Fyrir nákvæma umfjöllun um þessa tölfræði í samhengi við prófun, geturðu vísað til grunntóns Baruch Sadogursky á hinni ráðstefnu okkar, Heisenbug.
„Þegar það er ekki samkomulag meðal félaga,
Það mun ekki ganga vel hjá þeim,
Og ekkert kemur út úr því, aðeins kvöl.
Einu sinni var Svanur, Kría og Piða...“
Hvaða hluti vefforritara heldurðu að skilji í raun við hvaða aðstæður forrit þeirra eru notuð í framleiðslu? Hversu margir þeirra munu fara til stjórnenda og reyna að átta sig á hvað gerist ef gagnagrunnurinn hrynur? Og hver þeirra mun fara til prófunaraðilanna og biðja þá um að kenna þeim hvernig á að skrifa próf rétt? Og það eru líka öryggisverðir, vörustjórar og fullt af öðru fólki.
Heildarhugmynd DevOps er að skapa samvinnu milli hlutverka og deilda. Í fyrsta lagi er þetta ekki náð með einhverjum snjall stilltum hugbúnaði, heldur með samskiptum. DevOps snýst um menningu, starfshætti, aðferðafræði og ferla. Það er engin verkfræðigrein sem getur svarað þessum spurningum.
Vítahringur
Hvaðan kom fræðigreinin „devops engineering“ þá? Við erum með útgáfu! Hugmyndir DevOps voru góðar — svo góðar að þær urðu fórnarlömb eigin velgengni. Sumir skuggalegir ráðunautar og mansalar, sem hafa sitt eigið andrúmsloft, fóru að hringsnúast um allt þetta efni.
Ímyndaðu þér: í gær varstu að búa til shawarma í Khimki og í dag ertu nú þegar stór maður, háttsettur ráðunautur. Það er heilt ferli við að leita og velja umsækjendur, allt er ekki auðvelt, þú þarft að skilja. Segjum að deildarstjórinn segi: finndu sérfræðing í X. Við gefum X orðið „verkfræðingur“ og við erum búnir. Þarftu Linux? Jæja, þetta er örugglega Linux verkfræðingur, ef þú vilt DevOps, þá DevOps verkfræðingur. Laus staða samanstendur ekki aðeins af titli, heldur þarf einnig að slá inn einhvern texta. Auðveldasta leiðin er að slá inn sett af leitarorðum frá Google, allt eftir ímyndunarafli þínu. DevOps samanstendur af tveimur orðum - „Dev“ og „Ops“, sem þýðir að við þurfum að líma saman leitarorð sem tengjast forriturum og stjórnendum, allt í einn bunka. Svona birtast laus störf um færni í 42 forritunarmálum og 20 ára notkun Kubernetes og Swarm samtímis. Vinnumynd.
Þannig hefur merkingarlaus og miskunnarlaus ímynd ákveðinnar „devops“ ofurhetju fest sig í sessi í huga fólks, sem mun stilla alla til að senda til Jenkins, og hamingjan mun koma. Ó, ef bara allt væri svona einfalt. „Og svona er líka hægt að elta kerfisstjóra,“ hugsar HR, „þetta er smart orð, leitarorðin eru þau sömu, þeir ættu að taka agnið.
Eftirspurn skapar framboð og öll þessi lausu störf hafa verið fyllt með geðveikum fjölda kerfisstjóra sem áttuðu sig á: þú getur gert allt eins og áður, en fengið margfalt meira með því að kalla sjálfan þig „devops“. Rétt eins og þú stilltir netþjóna í gegnum SSH handvirkt einn í einu, muntu halda áfram að stilla þá, en nú er þetta talið vera aðferð til að devops. Þetta er einhvers konar flókið fyrirbæri, að hluta til tengt vanmati á klassískum stjórnendum og hype í kringum DevOps, en almennt gerðist það sem gerðist.
Þannig að við höfum framboð og eftirspurn. Vítahringur sem nærir sig sjálfan. Þetta er það sem við erum að berjast gegn (þar á meðal með því að búa til DevOops ráðstefnuna).
Að sjálfsögðu, fyrir utan kerfisstjórana sem hafa endurnefna sig „devops“, eru aðrir þátttakendur - til dæmis faglegir SRE eða Infrastructure-as-Code forritarar.
Það sem fólk gerir í DevOps (í alvöru)
Svo þú vilt komast áfram í að læra og beita DevOps starfsháttum. En hvernig á að gera þetta, í hvaða átt á að horfa? Augljóslega ættir þú ekki að treysta í blindni á vinsæl leitarorð.
Ef það er starf, ætti einhver að vinna það. Við höfum þegar komist að því að þetta eru ekki „devops verkfræðingar“, hverjir eru það þá? Réttara virðist að móta þetta ekki út frá stöðum heldur út frá sérstökum starfssviðum.
Í fyrsta lagi geturðu fjallað um hjarta DevOps — ferla og menningu. Menning er hægur og erfiður bransi og þó hún sé jafnan á ábyrgð stjórnenda koma allir við sögu með einum eða öðrum hætti, allt frá forriturum til stjórnenda. Fyrir nokkrum mánuðum síðan Tim Lister :
„Menning ræðst af grunngildum stofnunarinnar. Yfirleitt tekur fólk ekki eftir þessu en eftir að hafa unnið við ráðgjöf í mörg ár erum við vön að taka eftir því. Þú kemur inn í fyrirtæki og bókstaflega innan nokkurra mínútna byrjar þú að finna hvað er að gerast. Við köllum þetta "bragð". Stundum er þessi lykt mjög góð. Stundum veldur það ógleði. (...) Þú getur ekki breytt menningu fyrr en þau gildi og viðhorf sem liggja að baki tilteknum aðgerðum eru skilin. Auðvelt er að fylgjast með hegðun en það er erfitt að leita að viðhorfum. DevOps er bara frábært dæmi um hvernig hlutirnir eru að verða flóknari og flóknari.“
Það er líka tæknilegur hluti af málinu, auðvitað. Ef nýi kóðinn þinn verður prófaður eftir mánuð, en er gefinn út aðeins ári síðar, og það er líkamlega ómögulegt að flýta þessu öllu, gætirðu ekki uppfyllt góðar venjur. Góð vinnubrögð eru studd af góðum verkfærum. Til dæmis, með hugmyndina um Infrastructure-as-Code í huga, geturðu notað allt frá AWS CloudFormation og Terraform til Chef-Ansible-Puppet. Þú þarft að kunna og geta gert þetta allt og þetta er nú þegar heilmikil verkfræðigrein. Það er mikilvægt að rugla ekki saman orsök og afleiðingu: fyrst vinnur þú samkvæmt meginreglum SRE og aðeins síðan innleiðir þessar reglur í formi ákveðinna tæknilegra lausna. Á sama tíma er SRE mjög yfirgripsmikil aðferðafræði sem segir þér ekki hvernig á að setja upp Jenkins, heldur um fimm grundvallarreglur:
- Bætt samskipti milli hlutverka og deilda
- Að samþykkja mistök sem óaðskiljanlegur hluti af starfinu
- Gera breytingar smám saman
- Notkun verkfæra og annarrar sjálfvirkni
- Að mæla allt sem hægt er að mæla
Þetta er ekki bara eitthvert sett af fullyrðingum, heldur sértækt . Til dæmis, á leiðinni til að samþykkja villur, þarftu að skilja áhættuna, mæla framboð og óframboð þjónustu með því að nota eitthvað eins og SLI () og SLO (), lærðu að skrifa skurðaðgerðir og gera ritun þeirra ekki skelfileg.
Í SRE greininni er notkun verkfæra aðeins einn þáttur í velgengni, þó mikilvægur. Við þurfum stöðugt að þróa tæknilega, skoða hvað er að gerast í heiminum og hvernig hægt er að beita því í okkar starfi.
Aftur á móti hafa Cloud Native lausnir nú orðið mjög vinsælar. Eins og skilgreint er af Cloud Native Computing Foundation í dag, gerir Cloud Native tækni fyrirtækjum kleift að þróa og keyra skalanlegt forrit í kraftmiklu umhverfi nútímans, svo sem opinberum, einkareknum og blendingsskýjum. Dæmi eru ílát, þjónustunet, örþjónustur, óbreytanleg innviði og yfirlýsingar API. Allar þessar aðferðir leyfa lauslega tengdum kerfum að vera teygjanlegt, viðráðanlegt og mjög áberandi. Góð sjálfvirkni gerir verkfræðingum kleift að gera stórar breytingar oft og með fyrirsjáanlegum árangri án þess að gera það að verkum. Allt þetta er stutt af stafla af vel þekktum verkfærum eins og Docker og Kubernetes.
Þessi frekar flókna og víðtæka skilgreining stafar af því að svæðið er líka nokkuð flókið. Annars vegar er því haldið fram að nýjum breytingum á þessu kerfi eigi að bæta á einfaldan hátt. Á hinn bóginn, til að finna út hvernig á að búa til eins konar gámaumhverfi þar sem lauslega tengd þjónusta býr á hugbúnaðarskilgreindum innviðum og er afhent þangað með því að nota samfellda CI/CD, og byggja upp DevOps starfshætti í kringum allt þetta - allt þetta krefst meira en einn étur hundinn.
Hvað á að gera við þetta allt
Allir leysa þessi vandamál á sinn hátt: til dæmis er hægt að birta venjuleg laus störf til að rjúfa vítahringinn. Þú getur fundið út hvað orð eins og DevOps og Cloud Native þýða og notað þau rétt og markvisst. Þú getur þróað í DevOps og sýnt fram á réttu aðferðirnar með fordæmi þínu.
Við erum að halda ráðstefnu , sem gefur tækifæri til að kafa dýpra í hlutina sem við töluðum um. Það eru nokkrir hópar skýrslna um þetta:
- Ferlar og menning;
- Verkfræði áreiðanleika vefsvæðis;
- Cloud Native;
Hvernig á að velja hvar á að fara? Hér er lúmskur punktur. Annars vegar snýst DevOps um samskipti og við viljum endilega að þú sækir kynningar frá mismunandi blokkum. Á hinn bóginn, ef þú ert þróunarstjóri sem kom á ráðstefnuna til að einbeita þér að einu tilteknu verkefni, þá takmarkar enginn þig - augljóslega mun þetta vera blokk um ferla og menningu. Ekki gleyma að þú verður með upptökur eftir ráðstefnuna (eftir að hafa fyllt út athugasemdareyðublaðið), svo þú getur alltaf horft á mikilvægari kynningar síðar.
Það er augljóst að á ráðstefnunni sjálfri er ekki hægt að fara á þrjár brautir í einu, þannig að við skipuleggjum dagskrána á þann hátt að hver tími hefur efni fyrir hvern smekk.
Allt sem er eftir er að skilja hvað á að gera ef þú ert DevOps verkfræðingur! Reyndu fyrst að ákvarða hvað þú gerir í raun og veru. Venjulega vilja þeir kalla þetta orð:
- Hönnuðir sem vinna við innviði. Skýrsluhóparnir um SRE og Cloud Native henta þér best.
- Kerfisstjórar. Þetta er flóknara hérna. DevOops snýst ekki um kerfisstjórnun. Sem betur fer er mikið af frábærum ráðstefnum, bókum, greinum, myndböndum á netinu o.s.frv. um kerfisstjórnun. Á hinn bóginn, ef þú hefur áhuga á að þróa sjálfan þig hvað varðar skilning á menningu og ferlum, læra um skýjatækni og smáatriði lífsins með Cloud Native, þá viljum við gjarnan sjá þig! Hugsaðu um þetta: þú ert að sinna stjórnun, og hvað ætlarðu þá að gera? Til að forðast að lenda skyndilega í óþægilegum aðstæðum ættir þú að læra núna.
Það er annar valkostur: þú heldur áfram og heldur áfram að halda því fram að þú sért það sérstaklega DevOps verkfræðingur og ekkert annað, hvað sem það þýðir. Þá verðum við að valda þér vonbrigðum, DevOops er ekki ráðstefna fyrir DevOps verkfræðinga!
Renndu frá í Munchen
DevOops 2020 Moscow verður haldin 29.-30. apríl í Moskvu, miðar eru nú þegar fáanlegir .
Að öðrum kosti getur þú til 8. febrúar. Vinsamlegast athugaðu að þegar þú fyllir út eyðublaðið verður þú að velja markhópinn sem mun hagnast mest á skýrslunni þinni (það er óvænt grafið inni á listanum).
Heimild: www.habr.com