Ar hyn o bryd, dyma bron y sefyllfa drutaf ar y farchnad. Mae’r ffwdan ynghylch peirianwyr “DevOps” y tu hwnt i bob terfyn y gellir ei ddychmygu, a hyd yn oed yn waeth gyda pheirianwyr Uwch DevOps.
Rwy'n gweithio fel pennaeth yr adran integreiddio ac awtomeiddio, dyfalwch y datgodio Saesneg - DevOps Manager. Mae'n annhebygol bod y trawsgrifiad Saesneg yn adlewyrchu ein gweithgareddau dyddiol, ond mae'r fersiwn Rwsieg yn yr achos hwn yn fwy cywir. Oherwydd natur fy ngweithgarwch, mae'n naturiol bod angen i mi gyfweld ag aelodau o'm tîm yn y dyfodol, a thros y flwyddyn ddiwethaf, mae tua 50 o bobl wedi mynd trwodd i mi, ac mae'r un nifer wedi'u torri i ffwrdd ar rag-sgrin gyda fy ngweithwyr.
Rydym yn dal i chwilio am gydweithwyr, oherwydd y tu ôl i label DevOps mae haen fawr iawn o wahanol fathau o beirianwyr yn cuddio.
Mae popeth sydd wedi'i ysgrifennu isod yn fy marn bersonol i, nid oes rhaid i chi gytuno ag ef, ond rwy'n cyfaddef y bydd yn ychwanegu rhywfaint o liw at eich agwedd at y pwnc. Er gwaethaf y risg o syrthio allan o ffafr, rwy’n cyhoeddi fy marn oherwydd credaf fod ganddo le i fod.
Mae gan gwmnïau ddealltwriaeth wahanol o bwy yw peirianwyr DevOps ac, er mwyn llogi adnodd yn gyflym, maen nhw'n hongian y label hwn ar bawb. Mae'r sefyllfa'n eithaf rhyfedd, gan fod cwmnïau'n barod i dalu taliadau afrealistig i'r bobl hyn, gan dderbyn, yn y rhan fwyaf o achosion, weinyddwr offer ar eu cyfer.
Felly pwy yw peirianwyr DevOps?
Gadewch i ni ddechrau gyda hanes ei ymddangosiad - roedd Gweithrediadau Datblygu yn ymddangos fel cam arall tuag at optimeiddio rhyngweithio mewn timau bach i gynyddu cyflymder cynhyrchu cynnyrch, fel canlyniad disgwyliedig. Y syniad oedd cryfhau'r tîm datblygu gyda gwybodaeth am weithdrefnau a dulliau o reoli'r amgylchedd cynnyrch. Mewn geiriau eraill, rhaid i'r datblygwr ddeall a gwybod sut mae ei gynnyrch yn gweithio o dan amodau penodol, rhaid iddo ddeall sut i ddefnyddio ei gynnyrch, pa nodweddion yr amgylchedd y gellir eu haddasu i wella perfformiad. Felly, ers peth amser, ymddangosodd datblygwyr gyda dull DevOps. Ysgrifennodd datblygwyr DevOps sgriptiau adeiladu a phecynnu i symleiddio eu gweithgareddau a pherfformiad yr amgylchedd cynhyrchu. Fodd bynnag, dechreuodd cymhlethdod pensaernïaeth datrysiadau a dylanwad cilyddol cydrannau seilwaith dros amser ddirywio perfformiad yr amgylcheddau; gyda phob iteriad, roedd angen dealltwriaeth gynyddol ddyfnach o rai cydrannau, gan leihau cynhyrchiant y datblygwr oherwydd y ychwanegol. costau deall cydrannau a systemau tiwnio ar gyfer tasg benodol. Tyfodd cost y datblygwr ei hun, cost y cynnyrch ynghyd ag ef, neidiodd y gofynion ar gyfer datblygwyr newydd yn y tîm yn sydyn, oherwydd roedd angen iddynt hefyd dalu am gyfrifoldebau'r “seren” datblygiad ac, yn naturiol, daeth y “sêr” yn llai. a llai ar gael. Mae'n werth nodi hefyd, yn fy mhrofiad i, mai ychydig o ddatblygwyr sydd â diddordeb yn y manylion prosesu pecynnau gan gnewyllyn y system weithredu, rheolau llwybr pecynnau, ac agweddau diogelwch gwesteiwr. Y cam rhesymegol oedd denu gweinyddwr sy'n gyfarwydd â hyn a rhoi cyfrifoldebau tebyg iddo, a oedd, diolch i'w brofiad, yn ei gwneud hi'n bosibl cyflawni'r un dangosyddion am gost is o'i gymharu â chost datblygiad "seren". Rhoddwyd gweinyddwyr o'r fath mewn tîm a'i brif dasg oedd rheoli amgylcheddau prawf a chynhyrchu, yn unol â rheolau tîm penodol, gydag adnoddau'n cael eu dyrannu i'r tîm penodol hwn. Dyma sut, mewn gwirionedd, yr ymddangosodd DevOps ym meddyliau'r mwyafrif.
Yn rhannol neu'n gyfan gwbl, dros amser, dechreuodd y gweinyddwyr systemau hyn ddeall anghenion y tîm penodol hwn ym maes datblygu, sut i wneud bywyd yn haws i ddatblygwyr a phrofwyr, sut i gyflwyno diweddariad a pheidio â gorfod aros dros nos ddydd Gwener yn y swyddfa, cywiro gwallau lleoli. Aeth amser heibio, a nawr roedd y “sêr” yn weinyddwyr system a oedd yn deall yr hyn yr oedd datblygwyr ei eisiau. Er mwyn lleihau'r effaith, dechreuodd cyfleustodau rheoli ddod i fyny; cofiodd pawb yr hen ddulliau dibynadwy o ynysu lefel yr OS, a oedd yn ei gwneud hi'n bosibl lleihau'r gofynion ar gyfer diogelwch, rheoli rhan y rhwydwaith, a chyfluniad y gwesteiwr fel a. cyfan ac, o ganlyniad, lleihau'r gofynion ar gyfer “sêr” newydd.
Mae peth “gwych” wedi ymddangos – docker. Pam gwych? Ydy, dim ond oherwydd bod creu arwahanrwydd mewn croot neu garchar, yn ogystal ag OpenVZ, yn gofyn am wybodaeth ddibwys o'r OS, mewn cyferbyniad, mae'r cyfleustodau'n caniatáu ichi greu amgylchedd cais ynysig ar westeiwr penodol gyda phopeth angenrheidiol y tu mewn a'r llaw dros yr awenau datblygu eto, a dim ond gydag un gwesteiwr yn unig y gall gweinyddwr y system ymdopi, gan sicrhau ei ddiogelwch a'i argaeledd uchel - symleiddio rhesymegol. Ond nid yw cynnydd yn aros yn ei unfan ac mae systemau unwaith eto'n dod yn fwyfwy cymhleth, mae mwy a mwy o gydrannau, nid yw un gwesteiwr bellach yn diwallu anghenion y system ac mae angen adeiladu clystyrau, rydym eto'n dychwelyd at weinyddwyr system sy'n gallu adeiladu'r systemau hyn.
Beicio ar ôl cylch, mae systemau amrywiol yn ymddangos sy'n symleiddio datblygiad a / neu weinyddu, mae systemau offeryniaeth yn ymddangos, sydd, hyd nes y bydd angen i chi wyro oddi wrth y broses safonol, yn hawdd i'w defnyddio. Ymddangosodd pensaernïaeth microservice hefyd gyda'r nod o symleiddio popeth a ddisgrifir uchod - llai o berthnasoedd, yn haws i'w rheoli. Yn fy mhrofiad i, ni wnes i ddod o hyd i bensaernïaeth microservice yn gyfan gwbl, byddwn yn dweud 50 i 50 - daeth 50 y cant o ficrowasanaethau, blychau du, i mewn, wedi'u prosesu allan, mae'r 50 arall yn monolith wedi'i rwygo, gwasanaethau'n methu â gweithio ar wahân i gydrannau eraill. . Roedd hyn oll unwaith eto yn gosod cyfyngiadau ar lefel gwybodaeth datblygwyr a gweinyddwyr.
Mae “siglenni” tebyg yn lefel y wybodaeth arbenigol am adnodd penodol yn parhau hyd heddiw. Ond rydyn ni'n crwydro ychydig, mae yna lawer o bwyntiau sy'n werth eu hamlygu.
Peiriannydd Adeiladu / Peiriannydd Rhyddhau
Peirianwyr hynod arbenigol a ddaeth i'r amlwg fel modd o safoni prosesau adeiladu meddalwedd a rhyddhau. Yn y broses o gyflwyno Agile eang, mae'n ymddangos nad oedd galw amdanynt bellach, ond mae hyn ymhell o fod yn wir. Ymddangosodd yr arbenigedd hwn fel modd o safoni cydosod a chyflwyno meddalwedd ar raddfa ddiwydiannol, h.y. defnyddio technegau safonol ar gyfer holl gynhyrchion y cwmni. Gyda dyfodiad DevOps, collodd datblygwyr eu swyddogaethau yn rhannol, gan mai'r datblygwyr a ddechreuodd baratoi'r cynnyrch i'w gyflwyno, ac o ystyried y seilwaith newidiol a'r dull o gyflawni cyn gynted â phosibl heb ystyried ansawdd, dros amser fe wnaethant droi'n stopiwr o newidiadau, gan fod cadw at safonau ansawdd yn anochel yn arafu danfoniadau. Felly, yn raddol, ymfudodd rhan o ymarferoldeb peirianwyr Adeiladu/Rhyddhau i ysgwyddau gweinyddwyr systemau.
Ops mor wahanol
Rydym yn symud ymlaen ac eto presenoldeb ystod eang o gyfrifoldebau ac mae diffyg personél cymwys yn ein gwthio tuag at arbenigo llym, fel madarch ar ôl glaw, mae Gweithrediadau amrywiol yn ymddangos:
- TechOps - gweinyddwyr system enikey aka HelpDesk Engineer
- LiveOps - gweinyddwyr system sy'n bennaf gyfrifol am amgylcheddau cynhyrchu
- CloudOps - gweinyddwyr system sy'n arbenigo mewn cymylau cyhoeddus Azure, AWS, GCP, ac ati.
- PlatOps/InfraOps/SysOps - gweinyddwyr systemau seilwaith.
- NetOps - gweinyddwyr rhwydwaith
- SecOps - gweinyddwyr system sy'n arbenigo mewn diogelwch gwybodaeth - cydymffurfiaeth PCI, cydymffurfiaeth CIS, clytio, ac ati.
Mae DevOps (mewn theori) yn berson sy'n deall yn uniongyrchol holl brosesau'r cylch datblygu - datblygu, profi, deall pensaernïaeth y cynnyrch, sy'n gallu asesu risgiau diogelwch, yn gyfarwydd â dulliau ac offer awtomeiddio, o leiaf yn uchel. lefel, yn ogystal â hyn, hefyd yn deall cyn ac ar ôl prosesu cymorth rhyddhau cynnyrch. Person sy'n gallu gweithredu fel eiriolwr dros Weithrediadau a Datblygiad, sy'n caniatáu cydweithrediad ffafriol rhwng y ddau biler hyn. Yn deall prosesau cynllunio gwaith gan dimau a rheoli disgwyliadau cwsmeriaid.
Er mwyn cyflawni'r math hwn o waith a chyfrifoldebau, rhaid i'r person hwn fod â'r modd i reoli nid yn unig y prosesau datblygu a phrofi, ond hefyd rheolaeth y seilwaith cynnyrch, yn ogystal â chynllunio adnoddau. Ni ellir lleoli DevOps yn y ddealltwriaeth hon naill ai mewn TG, neu mewn ymchwil a datblygu, na hyd yn oed yn y PMO; rhaid iddo gael dylanwad yn yr holl feysydd hyn - cyfarwyddwr technegol y cwmni, y Prif Swyddog Technegol.
Ydy hyn yn wir yn eich cwmni? - Yr wyf yn amau. Yn y rhan fwyaf o achosion, TG neu Ymchwil a Datblygu yw hyn.
Bydd diffyg arian a’r gallu i ddylanwadu ar o leiaf un o’r tri maes gweithgaredd hyn yn symud pwysau’r problemau tuag at ble mae’r newidiadau hyn yn haws eu cymhwyso, megis cymhwyso cyfyngiadau technegol ar ryddhau mewn cysylltiad â chod “budr” yn ôl statig. systemau dadansoddwr. Hynny yw, pan fydd y PMO yn gosod terfyn amser llym ar gyfer rhyddhau ymarferoldeb, ni all Ymchwil a Datblygu gynhyrchu canlyniad o ansawdd uchel o fewn y terfynau amser hyn a'i gynhyrchu cystal ag y gall, gan adael ail-ffactoreiddio yn ddiweddarach, mae DevOps sy'n ymwneud â TG yn blocio'r rhyddhau gan ddefnyddio dulliau technegol. . Mae diffyg awdurdod i newid y sefyllfa, yn achos gweithwyr cyfrifol, yn arwain at amlygiad o orgyfrifoldeb am yr hyn na allant ddylanwadu arno, yn enwedig os yw'r gweithwyr hyn yn deall ac yn gweld camgymeriadau, a sut i'w cywiro - "Bliss yw anwybodaeth", ac o ganlyniad i losgi allan a cholli'r gweithwyr hyn.
Marchnad adnoddau DevOps
Edrychwn ar sawl swydd wag ar gyfer swyddi DevOps o wahanol gwmnïau.
Rydym yn barod i gwrdd â chi os ydych:
- Rydych chi'n berchen ar Zabbix ac yn gwybod beth yw Prometheus;
- Iptables;
- Myfyriwr PhD BASH;
- Yr Athro Ansible;
- Guru Linux;
- Gwybod sut i ddefnyddio dadfygio a dod o hyd i broblemau cymhwysiad ynghyd â datblygwyr (php/java/python);
- Nid yw llwybro yn eich gwneud yn hysterig;
- Talu sylw sylweddol i ddiogelwch system;
- Gwneud copi wrth gefn o “unrhyw beth a phopeth”, a hefyd adfer y “unrhyw beth a phopeth” hwn yn llwyddiannus;
- Rydych chi'n gwybod sut i ffurfweddu'r system yn y fath fodd ag i gael yr uchafswm allan o'r lleiafswm;
- Gosod atgynhyrchu cyn mynd i'r gwely ar Postgres a MySQL;
- Mae sefydlu ac addasu CI/CD yr un mor angenrheidiol i chi â brecwast/cinio/cinio.
- Meddu ar brofiad gydag AWS;
- Yn barod i ddatblygu gyda'r cwmni;
Felly:
- o 1 i 6 - gweinyddwr system
- 7 - ychydig o weinyddiaeth rhwydwaith, sydd hefyd yn cyd-fynd â gweinyddwr y system, Lefel ganol
- 8 - ychydig o ddiogelwch, sy'n orfodol ar gyfer gweinyddwr system lefel ganol
- 9-11 - Gweinyddwr y System Ganol
- 12 — Yn dibynnu ar y tasgau a neilltuwyd, naill ai Gweinyddwr y System Ganol neu Beiriannydd Adeiladu
- 13 - Rhithwiroli - Gweinyddwr System Ganol, neu'r CloudOps fel y'i gelwir, gwybodaeth uwch am wasanaethau safle cynnal penodol, ar gyfer defnydd effeithlon o arian a lleihau'r llwyth ar gynnal a chadw
Wrth grynhoi'r swydd wag hon, gallwn ddweud bod Gweinyddwr System Canol / Uwch yn ddigon i'r bechgyn.
Gyda llaw, ni ddylech rannu gweinyddwyr yn gryf ar Linux / Windows. Wrth gwrs, deallaf fod gwasanaethau a systemau’r ddau fyd hyn yn wahanol, ond yr un yw’r sail i’r cyfan ac mae unrhyw weinyddwr hunan-barch yn gyfarwydd â’r naill a’r llall, a hyd yn oed os nad yw’n gyfarwydd, bydd peidio â bod yn anodd i weinyddwr cymwys ddod yn gyfarwydd ag ef.
Gadewch i ni ystyried swydd wag arall:
- Profiad o adeiladu systemau llwyth uchel;
- Gwybodaeth ragorol am Linux OS, meddalwedd system gyffredinol a stac gwe (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Profiad gyda systemau rhithwiroli (KVM, VMWare, LXC/Docker);
- Hyfedredd mewn ieithoedd sgriptio;
- Dealltwriaeth o egwyddorion gweithredu rhwydweithiau protocol rhwydwaith;
- Dealltwriaeth o egwyddorion adeiladu systemau sy'n goddef diffygion;
- Annibyniaeth a menter;
Edrychwn ar:
- 1 – Uwch Weinyddwr System
- 2 - Yn dibynnu ar yr ystyr a roddir yn y pentwr hwn - Gweinyddwr System Canol/Uwch
- 3 - Gall profiad gwaith, gan gynnwys, olygu - “Ni chododd y clwstwr, ond creodd a rheolodd beiriannau rhithwir, roedd un gwesteiwr Docker, nid oedd mynediad i gynwysyddion ar gael” - Gweinyddwr y System Ganol
- 4 - Gweinyddwr System Iau - ie, gweinyddwr nad yw'n gwybod sut i ysgrifennu sgriptiau awtomeiddio sylfaenol, waeth beth fo'r iaith, nid gweinyddwr - enikey.
- 5 - Gweinyddwr y System Ganol
- 6 – Uwch Weinyddwr System
I grynhoi - Gweinyddwr System Canol/Uwch
Un arall:
- Devops profiad;
- Profiad o ddefnyddio un neu fwy o gynhyrchion i greu prosesau CI/CD. Bydd Gitlab CI yn fantais;
- Gweithio gyda chynwysyddion a rhithwiroli; Os oeddech chi'n defnyddio docker, da, ond os oeddech chi'n defnyddio k8s, gwych!
- Profiad o weithio mewn tîm ystwyth;
- Gwybodaeth o unrhyw iaith raglennu;
Gawn ni weld:
- 1 - Hmm... Beth mae'r bois yn ei olygu? =) Yn fwyaf tebygol, nid ydyn nhw eu hunain yn gwybod beth sydd wedi'i guddio y tu ôl iddo
- 2 - Peiriannydd Adeiladu
- 3 - Gweinyddwr y System Ganol
- 4 - Sgil meddal, ni fyddwn yn ei ystyried am y tro, er bod Agile yn beth arall sy'n cael ei ddehongli mewn ffordd sy'n gyfleus.
- 5 - Rhy verbose - gallai fod yn iaith sgriptio neu'n iaith gryno. Tybed a fydd ysgrifennu mewn Pascal a Basic yn yr ysgol yn addas iddyn nhw? =)
Hoffwn hefyd adael nodyn ynglŷn â phwynt 3 er mwyn cryfhau’r ddealltwriaeth o pam mae gweinyddwr y system yn ymdrin â’r pwynt hwn. Offeryniaeth yn unig yw Kubernetes, offeryn sy'n lapio gorchmynion uniongyrchol i yrwyr rhwydwaith a gwesteiwyr rhithwiroli / ynysu mewn cwpl o orchmynion ac sy'n caniatáu ichi wneud cyfathrebu â nhw yn haniaethol, dyna i gyd. Er enghraifft, gadewch i ni gymryd 'build framework’ Make, sydd, gyda llaw, nid wyf yn ystyried fframwaith. Ydw, dwi'n gwybod am y ffasiwn o wthio Gwnewch yn unrhyw le, lle mae'n angenrheidiol ac nad oes ei angen - lapio Maven yn Make, er enghraifft, o ddifrif?
Yn y bôn, dim ond deunydd lapio dros y gragen yw Make, gan symleiddio'r gorchmynion amgylchedd casglu, cysylltu a chrynhoi, yn union fel k8s.
Unwaith, cyfwelais ddyn a ddefnyddiodd k8s yn ei waith ar ben OpenStack, a siaradodd am sut yr oedd yn defnyddio gwasanaethau arno, fodd bynnag, pan ofynnais am OpenStack, daeth i'r amlwg ei fod yn cael ei weinyddu, yn ogystal â'i godi gan system. gweinyddwyr. Ydych chi wir yn meddwl nad yw person sydd wedi gosod OpenStack, waeth pa lwyfan y mae'n ei ddefnyddio y tu ôl iddo, yn gallu defnyddio k8s? =)
Nid DevOps yw'r ymgeisydd hwn mewn gwirionedd, ond Gweinyddwr System ac, i fod yn fwy manwl gywir, Gweinyddwr Kubernetes.
Gadewch inni grynhoi unwaith eto - bydd Gweinyddwr y System Ganol/Uwch yn ddigon iddynt.
Faint i'w bwyso mewn gramau
Ystod y cyflogau arfaethedig ar gyfer y swyddi gwag a nodir yw 90k-200k
Nawr hoffwn dynnu paralel rhwng gwobrau ariannol Gweinyddwyr System a Pheirianwyr DevOps.
Mewn egwyddor, i symleiddio pethau, gallwch chi wasgaru'r graddau yn seiliedig ar brofiad gwaith, er na fydd hyn yn fanwl gywir, ond at ddibenion yr erthygl bydd yn ddigon.
Profiad:
- hyd at 3 oed - Iau
- hyd at 6 oed - Canol
- mwy na 6 – Hŷn
Mae gwefan chwilio gweithwyr yn cynnig:
Gweinyddwyr System:
- Iau - 2 flynedd - 50k rhwb.
- Canol - 5 mlynedd - 70k rhwb.
- Hŷn - 11 oed - 100k rhwb.
Peirianwyr DevOps:
- Iau - 2 flynedd - 100k rhwb.
- Canol - 3 blynedd - 160k rhwb.
- Hŷn - 6 oed - 220k rhwb.
Yn ôl profiad “DevOps”, defnyddiwyd profiad a effeithiodd o leiaf rywsut ar yr SDLC.
O'r uchod mae'n dilyn mewn gwirionedd nad oes angen DevOps ar gwmnïau, a hefyd y gallent arbed o leiaf 50 y cant o'r costau a gynlluniwyd yn wreiddiol trwy logi Gweinyddwr; ar ben hynny, gallent ddiffinio cyfrifoldebau'r person y maent yn chwilio amdano yn gliriach. a llenwi'r angen yn gyflymach. Ni ddylem hefyd anghofio bod rhaniad clir o gyfrifoldebau yn ein galluogi i leihau'r gofynion ar gyfer personél, yn ogystal â chreu awyrgylch mwy ffafriol yn y tîm, oherwydd absenoldeb gorgyffwrdd. Mae mwyafrif helaeth y swyddi gwag yn llawn cyfleustodau a labeli DevOps, ond nid ydynt yn seiliedig ar ofynion gwirioneddol ar gyfer Peiriannydd DevOps, dim ond ceisiadau am weinyddwr offer.
Mae'r broses o hyfforddi peirianwyr DevOps hefyd wedi'i chyfyngu i set o weithiau penodol, cyfleustodau, ac nid yw'n darparu dealltwriaeth gyffredinol o'r prosesau a'u dibyniaethau. Mae'n sicr yn dda pan all person ddefnyddio AWS EKS gan ddefnyddio Terraform, ar y cyd â'r car ochr Fluentd yn y clwstwr hwn a stack AWS ELK ar gyfer y system logio mewn 10 munud, gan ddefnyddio dim ond un gorchymyn yn y consol, ond os nad yw'n deall y egwyddor prosesu logiau ei hun a'r hyn sydd ei angen arnynt, os nad ydych chi'n gwybod sut i gasglu metrigau arnynt ac olrhain diraddiad y gwasanaeth, yna yr un enikey fydd hi o hyd sy'n gwybod sut i ddefnyddio rhai cyfleustodau.
Mae'r galw, fodd bynnag, yn creu cyflenwad, a gwelwn farchnad orboethedig iawn ar gyfer sefyllfa DevOps, lle nad yw'r gofynion yn cyfateb i'r rôl wirioneddol, ond dim ond yn caniatáu i weinyddwyr system ennill mwy.
Felly pwy ydyn nhw? DevOps neu weinyddwyr system barus? =)
Sut i barhau i fyw?
Dylai cyflogwyr lunio gofynion yn fwy manwl gywir a chwilio am yr union rai sydd eu hangen, a pheidio â thaflu labeli o gwmpas. Nid ydych chi'n gwybod beth mae DevOps yn ei wneud - nid oes eu hangen arnoch chi yn yr achos hwnnw.
Gweithwyr - Dysgwch. Gwella'ch gwybodaeth yn gyson, edrych ar y darlun cyffredinol o brosesau ac olrhain y llwybr i'ch nod. Gallwch chi ddod yn pwy bynnag rydych chi ei eisiau, mae'n rhaid i chi geisio.
Ffynhonnell: hab.com