Nid oes unrhyw beirianwyr DevOps. Pwy sy'n bodoli wedyn, a beth i'w wneud ag ef?

Nid oes unrhyw beirianwyr DevOps. Pwy sy'n bodoli wedyn, a beth i'w wneud ag ef?

Yn ddiweddar, mae hysbysebion o'r fath wedi gorlifo'r Rhyngrwyd. Er gwaethaf y cyflog dymunol, ni all rhywun helpu ond bod yn embaras bod heresi gwyllt wedi'i ysgrifennu y tu mewn. Ar y dechrau tybir y gellir gludo “DevOps” a “peiriannydd” at ei gilydd mewn un gair, ac yna mae rhestr ar hap o ofynion, y mae rhai ohonynt wedi'u copïo'n glir o'r swydd wag sysadmin.

Yn y swydd hon hoffwn siarad ychydig am sut y cyrhaeddom y pwynt hwn o fywyd, beth yw DevOps mewn gwirionedd a beth i'w wneud ag ef nawr.

Gellir condemnio swyddi gwag o'r fath ym mhob ffordd bosibl, ond erys y ffaith: mae llawer ohonynt, a dyma sut mae'r farchnad yn gweithio ar hyn o bryd. Cynhaliom gynhadledd devops a datgan yn agored: “DevOops - nid ar gyfer peirianwyr DevOps." Bydd hyn yn ymddangos yn rhyfedd ac yn wyllt i lawer: pam mae pobl sy’n cynnal digwyddiad cwbl fasnachol yn mynd yn groes i’r farchnad. Nawr byddwn yn esbonio popeth.

Am ddiwylliant a phrosesau

Gadewch i ni ddechrau gyda'r ffaith nad yw DevOps yn ddisgyblaeth beirianyddol. Dechreuodd y cyfan gyda'r ffaith nad yw'r rhaniad rolau a sefydlwyd yn hanesyddol yn gweithio i ansawdd y cynhyrchion. Pan fydd rhaglenwyr yn rhaglennu yn unig, ond ddim eisiau clywed dim am brofi, mae'r feddalwedd yn frith o chwilod. Pan nad oes ots gan weinyddwyr sut neu pam mae'r feddalwedd wedi'i hysgrifennu, mae cefnogaeth yn troi'n uffern.

Er enghraifft, disgrifio'r gwahaniaeth rhwng gweinyddwr system a dull ARhPh o reoli gwasanaethau mae'r Google SRE Book enwog yn dechrau. Mae astudiaethau diddorol wedi'u cynnal o fewn Arolwg DORA - mae'n amlwg bod y datblygwyr gorau rywsut yn llwyddo i ddefnyddio newidiadau newydd i gynhyrchu yn gyflymach nag unwaith yr awr. Maent yn profi gyda'u dwylo dim mwy na 10% (gellir gweld hyn o DORA y llynedd). Sut maen nhw'n gwneud hyn? “Rhagori neu farw” medd un o benawdau’r adroddiad. Am drafodaeth fanwl o'r ystadegau hyn yng nghyd-destun profi, gallwch gyfeirio at gyweirnod Baruch Sadogursky “Mae gennym ni DevOps. Gadewch i ni danio'r holl brofwyr." yn ein cynhadledd arall, Heisenbug.

“Pan nad oes cytundeb ymhlith cymrodyr,
Fydd pethau ddim yn mynd yn dda iddyn nhw,
Ac ni ddaw dim ohono, dim ond poenydio.
Un tro, Alarch, Cimwch yr Afon a Phenhwyaid..."

Pa ran o raglenwyr gwe ydych chi'n meddwl sy'n deall mewn gwirionedd o dan yr amodau y mae eu cymwysiadau'n cael eu defnyddio wrth gynhyrchu? Faint ohonyn nhw fydd yn mynd at y gweinyddwyr ac yn ceisio darganfod beth fydd yn digwydd os bydd y gronfa ddata yn chwalu? A pha un ohonyn nhw fydd yn mynd at y profwyr ac yn gofyn iddyn nhw ddysgu sut i ysgrifennu profion yn gywir? Ac mae yna hefyd swyddogion diogelwch, rheolwyr cynnyrch, a chriw o bobl eraill.

Syniad cyffredinol DevOps yw creu cydweithrediad rhwng rolau ac adrannau. Yn gyntaf oll, cyflawnir hyn nid gan rai meddalwedd wedi'i ffurfweddu'n glyfar, ond trwy arfer cyfathrebu. Mae DevOps yn ymwneud â diwylliant, arferion, methodoleg a phrosesau. Nid oes unrhyw arbenigedd peirianneg a all ateb y cwestiynau hyn.

Cylch dieflig

O ble y daeth disgyblaeth “peirianneg devops” bryd hynny? Mae gennym fersiwn! Roedd syniadau DevOps yn dda - mor dda nes iddynt ddod yn ddioddefwyr eu llwyddiant eu hunain. Dechreuodd rhai recriwtwyr cysgodol a masnachwyr dynol, sydd â'u hawyrgylch eu hunain, chwyrlïo o amgylch y pwnc cyfan hwn.

Dychmygwch: ddoe roeddech chi'n gwneud shawarma yn Khimki, a heddiw rydych chi eisoes yn ddyn mawr, yn uwch recriwtiwr. Mae yna broses gyfan o chwilio a dewis ymgeiswyr, nid yw popeth yn hawdd, mae angen i chi ddeall. Dywedwch fod pennaeth adran yn dweud: dewch o hyd i arbenigwr yn X. Rydyn ni'n aseinio'r gair “peiriannydd” i X, ac rydyn ni wedi gorffen. Angen Linux? Wel, mae hwn yn bendant yn beiriannydd Linux, os ydych chi eisiau DevOps, yna peiriannydd DevOps. Mae'r swydd wag nid yn unig yn cynnwys teitl, ond hefyd mae'n rhaid nodi rhywfaint o destun y tu mewn. Y ffordd hawsaf yw nodi set o eiriau allweddol gan Google, yn dibynnu ar eich dychymyg. Mae DevOps yn cynnwys dau air - “Dev” ac “Ops”, sy'n golygu bod angen i ni gludo geiriau allweddol sy'n ymwneud â datblygwyr a gweinyddwyr i gyd mewn un pentwr. Dyma sut mae swyddi gwag yn ymddangos am hyfedredd mewn 42 o ieithoedd rhaglennu ac 20 mlynedd o ddefnyddio Kubernetes a Swarm ar yr un pryd. Diagram gweithio.

Dyma sut mae delwedd ddiystyr a didrugaredd o arwr “devops” penodol wedi gwreiddio ym meddyliau pobl, a fydd yn ffurfweddu pawb i’w defnyddio i Jenkins, a daw hapusrwydd. O, pe bai popeth mor syml yn unig. “A dyma hefyd sut y gallwch chi hela gweinyddwyr system,” meddai HR, “mae’n air ffasiynol, mae’r geiriau allweddol yr un peth, fe ddylen nhw gymryd yr abwyd.”

Mae'r galw yn creu cyflenwad, ac mae'r holl swyddi gwag sbwriel hyn wedi'u llenwi â nifer wallgof o weinyddwyr system a sylweddolodd: gallwch chi wneud popeth yr un peth ag o'r blaen, ond cael sawl gwaith yn fwy trwy alw'ch hun yn “devops.” Yn union fel y gwnaethoch chi ffurfweddu gweinyddwyr trwy SSH â llaw un ar y tro, byddwch yn parhau i'w ffurfweddu, ond nawr mae hwn i fod yn arfer devops. Mae hwn yn rhyw fath o ffenomen gymhleth, yn rhannol gysylltiedig â thanamcangyfrif gweinyddwyr clasurol a'r hype o amgylch DevOps, ond yn gyffredinol, yr hyn a ddigwyddodd, a ddigwyddodd.

Felly mae gennym gyflenwad a galw. Cylch dieflig sy'n bwydo ei hun. Dyma beth rydyn ni'n ymladd yn ei erbyn (gan gynnwys trwy greu cynhadledd DevOops).

Wrth gwrs, ar wahân i'r gweinyddwyr system sydd wedi ailenwi eu hunain yn “devops,” mae yna gyfranogwyr eraill - er enghraifft, SREs proffesiynol neu ddatblygwyr Isadeiledd-fel-Cod.

Beth mae pobl yn ei wneud yn DevOps (mewn gwirionedd)

Felly rydych chi am symud ymlaen i ddysgu a chymhwyso arferion DevOps. Ond sut i wneud hyn, i ba gyfeiriad i edrych? Yn amlwg, ni ddylech ddibynnu'n ddall ar eiriau allweddol poblogaidd.

Os oes swydd, dylai rhywun ei gwneud. Rydym eisoes wedi darganfod nad yw'r rhain yn “beirianwyr devops”, felly pwy ydyn nhw? Ymddengys yn fwy cywir llunio hyn nid o ran safbwyntiau, ond o ran meysydd gwaith penodol.

Yn gyntaf, gallwch fynd i'r afael â chalon DevOps - prosesau a diwylliant. Mae diwylliant yn fusnes araf ac anodd, ac er ei fod yn draddodiadol yn gyfrifoldeb rheolwyr, mae pawb yn cymryd rhan mewn rhyw ffordd neu'i gilydd, o raglenwyr i weinyddwyr. Ychydig fisoedd yn ôl Tim Lister dywedodd mewn cyfweliad:

“Mae diwylliant yn cael ei bennu gan werthoedd craidd y sefydliad. Fel arfer nid yw pobl yn sylwi ar hyn, ond ar ôl gweithio ym maes ymgynghori ers blynyddoedd lawer, rydym wedi arfer sylwi arno. Rydych chi'n dod i mewn i gwmni ac yn llythrennol o fewn ychydig funudau rydych chi'n dechrau teimlo beth sy'n digwydd. Rydyn ni'n galw hyn yn "blas". Weithiau mae'r arogl hwn yn dda iawn. Weithiau mae'n achosi cyfog. (...) Ni allwch newid diwylliant nes bod y gwerthoedd a'r credoau y tu ôl i weithredoedd penodol yn cael eu deall. Mae ymddygiad yn hawdd i'w arsylwi, ond mae chwilio am gredoau yn anodd. Mae DevOps yn enghraifft wych o sut mae pethau'n dod yn fwyfwy cymhleth."

Mae rhan dechnegol o’r mater hefyd, wrth gwrs. Os bydd eich cod newydd yn cael ei brofi mewn mis, ond yn cael ei ryddhau flwyddyn yn ddiweddarach yn unig, a'i bod yn gorfforol amhosibl cyflymu'r cyfan, efallai na fyddwch yn dilyn arferion da. Cefnogir arferion da gan offer da. Er enghraifft, gyda'r syniad o Isadeiledd-fel-Cod mewn golwg, gallwch ddefnyddio unrhyw beth o AWS CloudFormation a Terraform i Chef-Ansible-Puppet. Mae angen i chi wybod a gallu gwneud hyn i gyd, ac mae hon eisoes yn ddisgyblaeth beirianyddol eithaf. Mae'n bwysig peidio â drysu achos gydag effaith: yn gyntaf rydych chi'n gweithio yn unol ag egwyddorion ARhPh a dim ond wedyn yn gweithredu'r egwyddorion hyn ar ffurf rhai atebion technegol penodol. Ar yr un pryd, mae ARhPh yn fethodoleg gynhwysfawr iawn nad yw'n dweud wrthych sut i sefydlu Jenkins, ond tua phum egwyddor sylfaenol:

  • Gwell cyfathrebu rhwng rolau ac adrannau
  • Derbyn camgymeriadau fel rhan annatod o'r swydd
  • Gwneud newidiadau yn raddol
  • Defnyddio offer ac awtomeiddio arall
  • Mesur popeth y gellir ei fesur

Nid dim ond rhai set o ddatganiadau yw hyn, ond yn benodol canllaw i weithredu. Er enghraifft, ar y llwybr i dderbyn gwallau, bydd angen i chi ddeall y risgiau, mesur argaeledd a diffyg argaeledd gwasanaethau gan ddefnyddio rhywbeth fel SLI (dangosyddion lefel gwasanaeth) ac SLO (amcanion lefel gwasanaeth), dysgu sut i ysgrifennu post mortem a gwneud i'w hysgrifennu beidio â bod yn frawychus.

Yn y ddisgyblaeth ARhPh, dim ond un rhan o lwyddiant yw defnyddio offer, er ei fod yn un pwysig. Mae angen i ni ddatblygu'n dechnegol yn gyson, edrych ar yr hyn sy'n digwydd yn y byd a sut y gellir ei gymhwyso yn ein gwaith.

Yn eu tro, mae datrysiadau Cloud Native bellach wedi dod yn boblogaidd iawn. Fel y'i diffinnir gan y Cloud Native Computing Foundation heddiw, mae technolegau Cloud Native yn galluogi sefydliadau i ddatblygu a rhedeg cymwysiadau graddadwy yn amgylcheddau deinamig heddiw, megis cymylau cyhoeddus, preifat a hybrid. Mae enghreifftiau yn cynnwys cynwysyddion, rhwyllau gwasanaeth, microwasanaethau, seilwaith na ellir ei gyfnewid, ac APIs datganiadol. Mae'r holl dechnegau hyn yn caniatáu i systemau sydd wedi'u cyplysu'n llac aros yn elastig, yn hylaw ac yn weladwy iawn. Mae awtomeiddio da yn caniatáu i beirianwyr wneud newidiadau mawr yn aml a chyda chanlyniadau rhagweladwy heb ei wneud yn dasg. Cefnogir hyn i gyd gan bentwr o offer adnabyddus fel Docker a Kubernetes.

Mae'r diffiniad eithaf cymhleth ac eang hwn i'w briodoli i'r ffaith bod yr ardal hefyd yn eithaf cymhleth. Ar y naill law, dadleuir y dylid ychwanegu newidiadau newydd i'r system hon yn eithaf syml. Ar y llaw arall, darganfod sut i greu math o amgylchedd amwys lle mae gwasanaethau sydd wedi'u cyplysu'n llac yn byw ar seilwaith a ddiffinnir gan feddalwedd ac yn cael eu darparu yno gan ddefnyddio CI/CD parhaus, ac adeiladu arferion DevOps o gwmpas hyn i gyd - mae hyn i gyd yn gofyn am fwy. nag un bwyta y ci.

Beth i'w wneud â'r cyfan

Mae pawb yn datrys y problemau hyn yn eu ffordd eu hunain: er enghraifft, gallwch chi gyhoeddi swyddi gwag arferol i dorri'r cylch dieflig. Gallwch chi ddarganfod beth mae geiriau fel DevOps a Cloud Native yn ei olygu a'u defnyddio'n gywir ac i'r pwynt. Gallwch ddatblygu yn DevOps a dangos y dulliau cywir trwy eich esiampl.

Rydyn ni'n cynnal cynhadledd DevOops 2020 Moscow, sy'n rhoi cyfle i ymchwilio'n ddyfnach i'r pethau yr ydym newydd siarad amdanynt. Mae sawl grŵp o adroddiadau ar gyfer hyn:

  • Prosesau a diwylliant;
  • Peirianneg Dibynadwyedd Safle;
  • Brodorol Cwmwl;

Sut i ddewis ble i fynd? Mae pwynt cynnil yma. Ar y naill law, mae DevOps yn ymwneud â rhyngweithio, ac rydym wir eisiau ichi fynychu cyflwyniadau o wahanol flociau. Ar y llaw arall, os ydych chi'n rheolwr datblygu a ddaeth i'r gynhadledd i ganolbwyntio ar un dasg benodol, yna nid oes neb yn eich cyfyngu - yn amlwg, bydd hwn yn bloc am brosesau a diwylliant. Peidiwch ag anghofio y bydd gennych chi recordiadau ar ôl y gynhadledd (ar ôl llenwi'r ffurflen adborth), felly gallwch chi bob amser wylio cyflwyniadau llai pwysig yn nes ymlaen.

Yn amlwg, yn y gynhadledd ei hun ni allwch fynd ar dri thrac ar unwaith, felly rydym yn trefnu’r rhaglen yn y fath fodd fel bod gan bob slot amser bynciau at bob chwaeth.

Y cyfan sydd ar ôl yw deall beth i'w wneud os ydych chi'n beiriannydd DevOps! Yn gyntaf, ceisiwch benderfynu beth rydych chi'n ei wneud mewn gwirionedd. Fel arfer maen nhw'n hoffi galw'r gair hwn:

  • Datblygwyr sy'n gweithio ar seilwaith. Y grwpiau o adroddiadau am SRE a Cloud Native sydd fwyaf addas i chi.
  • Gweinyddwyr systemau. Mae'n fwy cymhleth yma. Nid yw DevOops yn ymwneud â gweinyddu system. Yn ffodus, mae yna lawer o gynadleddau, llyfrau, erthyglau, fideos rhagorol ar y Rhyngrwyd, ac ati ar y pwnc gweinyddu system. Ar y llaw arall, os oes gennych ddiddordeb mewn datblygu eich hun o ran deall diwylliant a phrosesau, dysgu am dechnolegau cwmwl a manylion bywyd gyda Cloud Native, yna byddem wrth ein bodd yn eich gweld! Meddyliwch am hyn: rydych chi'n gweinyddu, ac yna beth fyddwch chi'n ei wneud? Er mwyn osgoi cael eich hun mewn sefyllfa annymunol yn sydyn, dylech ddysgu nawr.

Mae opsiwn arall: rydych chi'n dal ati ac yn parhau i honni eich bod chi yn benodol peiriannydd DevOps a dim arall, beth bynnag mae hynny'n ei olygu. Yna mae'n rhaid i ni eich siomi, nid yw DevOops yn gynhadledd i beirianwyr DevOps!

Nid oes unrhyw beirianwyr DevOps. Pwy sy'n bodoli wedyn, a beth i'w wneud ag ef?
Llithro o adroddiad gan Konstantin Diener yn Munich

Cynhelir DevOops 2020 Moscow ar Ebrill 29-30 ym Moscow, mae tocynnau eisoes ar gael prynu ar y wefan swyddogol.

Fel arall, gallwch chi cyflwyno eich adroddiad tan Chwefror 8. Sylwch, wrth lenwi'r ffurflen, rhaid i chi ddewis y gynulleidfa darged a fydd yn elwa fwyaf o'ch adroddiad (mae syrpreis wedi'i gladdu y tu mewn i'r rhestr).

Ffynhonnell: hab.com

Ychwanegu sylw