Unwaith eto am DevOps ac ARhPh

Yn seiliedig ar sgwrs sgwrs AWS Cymuned Minsk

Yn ddiweddar, mae brwydrau go iawn wedi cynyddu dros y diffiniad o DevOps ac SRE.
Er gwaethaf y ffaith bod trafodaethau ar y pwnc hwn eisoes wedi rhoi fy nannedd ar y blaen mewn sawl ffordd, gan gynnwys fi, penderfynais ddod â fy marn ar y pwnc hwn i lys cymuned Habra. I'r rhai sydd â diddordeb, croeso i gath. A gadewch i bopeth ddechrau o'r newydd!

cynhanes

Felly, yn yr hen amser, roedd tîm o ddatblygwyr meddalwedd a gweinyddwyr gweinyddwyr yn byw ar wahân. Ysgrifennodd y cyntaf y cod yn llwyddiannus, yr ail, gan ddefnyddio geiriau cynnes, serchog amrywiol wedi'u cyfeirio at y cyntaf, sefydlu'r gweinyddwyr, gan ddod o bryd i'w gilydd at y datblygwyr a derbyn mewn ymateb “mae popeth yn gweithio ar fy mheiriant.” Roedd y busnes yn aros am y meddalwedd, roedd popeth yn segur, roedd yn torri o bryd i'w gilydd, roedd pawb yn nerfus. Yn enwedig yr un a dalodd am y llanast cyfan hwn. Oes lampau gogoneddus. Wel, rydych chi eisoes yn gwybod o ble mae DevOps yn dod.

Genedigaeth arferion DevOps

Yna daeth dynion difrifol a dweud - nid diwydiant yw hwn, ni allwch weithio felly. A daethant â modelau cylch bywyd i mewn. Yma, er enghraifft, mae'r model V.

Unwaith eto am DevOps ac ARhPh
Felly beth ydyn ni'n ei weld? Daw busnes gyda chysyniad, mae penseiri yn dylunio datrysiadau, datblygwyr yn ysgrifennu cod, ac yna methiant. Mae rhywun rywsut yn profi'r cynnyrch, mae rhywun rywsut yn ei gyflwyno i'r defnyddiwr terfynol, ac yn rhywle yn allbwn y model gwyrth hwn mae cwsmer busnes unig yn aros am y tywydd a addawyd ger y môr. Daethom i’r casgliad bod angen dulliau arnom a fydd yn caniatáu inni sefydlu’r broses hon. Ac fe benderfynon ni greu arferion a fyddai'n eu gweithredu.

Digression telynegol ar y pwnc o beth yw ymarfer
Wrth ymarfer rwy'n golygu cyfuniad o dechnoleg a disgyblaeth. Enghraifft yw'r arfer o ddisgrifio seilwaith gan ddefnyddio cod terraform. Disgyblaeth yw sut i ddisgrifio seilwaith gyda chod, mae ym mhen y datblygwr, a thechnoleg yw'r teras ei hun.

Ac fe benderfynon nhw eu galw'n arferion DevOps - rwy'n credu eu bod yn golygu o Ddatblygu i Weithrediadau. Fe wnaethon ni feddwl am wahanol bethau clyfar - arferion CI/CD, arferion yn seiliedig ar yr egwyddor IaC, miloedd ohonyn nhw. Ac i ffwrdd â ni, mae datblygwyr yn ysgrifennu cod, mae peirianwyr DevOps yn trawsnewid disgrifiad y system ar ffurf cod yn systemau gweithio (ie, dim ond disgrifiad yw'r cod, yn anffodus, ond nid yw'n ymgorfforiad o'r system), mae'r ddarpariaeth yn parhau, ac yn y blaen. Ailhyfforddodd gweinyddwyr ddoe, ar ôl meistroli arferion newydd, yn falch fel peirianwyr DevOps, ac aeth popeth oddi yno. A bu hwyr, a bu bore... sori, nid oddi yno.

Nid yw'r cyfan yn dda eto, diolch i Dduw

Cyn gynted ag y tawelodd popeth, a dechreuodd “methodolegwyr” cyfrwys amrywiol ysgrifennu llyfrau trwchus ar arferion DevOps, cododd anghydfodau yn dawel ynghylch pwy oedd y peiriannydd DevOps drwg-enwog a bod DevOps yn ddiwylliant cynhyrchu, cododd anfodlonrwydd eto. Yn sydyn daeth i'r amlwg nad yw cyflwyno meddalwedd yn dasg gwbl ddibwys. Mae gan bob seilwaith datblygu ei bentwr ei hun, rhywle y mae angen i chi ei gydosod, rhywle y mae angen i chi ddefnyddio'r amgylchedd, yma mae angen Tomcat arnoch chi, yma mae angen ffordd gyfrwys a chymhleth i'w lansio - yn gyffredinol, mae'ch pen yn curo. Ac yn rhyfedd ddigon, roedd y broblem yn bennaf wrth drefnu prosesau - dechreuodd y swyddogaeth gyflenwi hon, fel tagfa, rwystro prosesau. Yn ogystal, nid oes neb yn canslo Gweithrediadau. Nid yw'n weladwy yn y model V, ond mae'r cylch bywyd cyfan ar y dde o hyd. O ganlyniad, mae angen rhywsut cynnal y seilwaith, monitro monitro, datrys digwyddiadau, a hefyd ymdrin â chyflawni. Y rhai. eistedd gydag un droed yn y ddau ddatblygiad a gweithrediad - ac yn sydyn trodd allan i fod yn Datblygu a Gweithrediadau. Ac yna roedd y hype cyffredinol ar gyfer microservices. A chyda nhw, dechreuodd datblygiad o beiriannau lleol symud i'r cwmwl - ceisiwch ddadfygio rhywbeth yn lleol, os oes dwsinau a channoedd o ficrowasanaethau, yna mae cyflwyno cyson yn dod yn fodd o oroesi. I “gwmni bach cymedrol” roedd popeth yn iawn, ond eto? Beth am Google?

SRE gan Google

Daeth Google, bwyta'r cacti mwyaf a phenderfynu - nid oes angen hyn arnom, mae angen dibynadwyedd arnom. A rhaid rheoli dibynadwyedd. A phenderfynais fod angen arbenigwyr arnom a fydd yn rheoli dibynadwyedd. Fe wnes i eu galw'n beirianwyr SR a dweud, dyna ni, gwnewch yn dda fel arfer. Dyma SLI, dyma SLO, dyma fonitro. A phrofodd ei drwyn i lawdriniaethau. A galwodd ei SRE “DevOps dibynadwy”. Mae'n ymddangos bod popeth yn iawn, ond mae yna un darn budr y gallai Google ei fforddio - ar gyfer sefyllfa peirianwyr SR, llogi pobl a oedd yn ddatblygwyr cymwys a hefyd yn gwneud ychydig o waith cartref ac yn deall gweithrediad systemau gweithio. Ar ben hynny, mae gan Google ei hun broblemau gyda llogi pobl o'r fath - yn bennaf oherwydd yma mae'n cystadlu â'i hun - mae angen disgrifio'r rhesymeg busnes i rywun. Neilltuwyd cyflenwi i beirianwyr rhyddhau, SR - mae peirianwyr yn rheoli dibynadwyedd (wrth gwrs, nid yn uniongyrchol, ond trwy ddylanwadu ar y seilwaith, newid y bensaernïaeth, olrhain newidiadau a dangosyddion, delio â digwyddiadau). Neis, gallwch chi ysgrifennu llyfrau. Ond beth os nad ydych chi'n Google, ond mae dibynadwyedd yn dal i fod yn bryder rhywsut?

Datblygu syniadau DevOps

Yn union wedyn cyrhaeddodd Docker, a dyfodd allan o lxc, ac yna systemau cerddorfaol amrywiol megis Docker Swarm a Kubernetes, a pheirianwyr DevOps yn anadlu allan - roedd uno arferion yn symleiddio cyflwyno. Fe'i symleiddiodd i'r fath raddau nes ei bod yn bosibl hyd yn oed allanoli darpariaeth i ddatblygwyr - beth yw deployment.yaml. Mae containerization yn datrys y broblem. Ac mae aeddfedrwydd systemau CI / CD eisoes ar lefel ysgrifennu un ffeil ac i ffwrdd â ni - gall y datblygwyr ei drin eu hunain. Ac yna rydym yn dechrau siarad am sut y gallwn wneud ein SRE ein hunain, gyda... neu o leiaf gyda rhywun.

Nid yw SRE ar Google

Wel, iawn, fe wnaethom gyflwyno'r danfoniad, mae'n ymddangos y gallwn anadlu allan, dychwelyd i'r hen ddyddiau, pan oedd gweinyddwyr yn gwylio llwyth y prosesydd, yn tiwnio'r systemau ac yn sipian yn dawel ar rywbeth annealladwy o fygiau mewn heddwch a thawelwch... Stop. Nid dyma pam wnaethon ni ddechrau popeth (sy'n drueni!). Yn sydyn mae'n ymddangos y gallwn fabwysiadu arferion rhagorol yn null Google yn hawdd - nid llwyth y prosesydd sy'n bwysig, ac nid pa mor aml rydyn ni'n newid y disgiau yno, neu'n gwneud y gorau o'r gost yn y cwmwl, ond mae'r metrigau busnes yr un peth yn ddrwg-enwog. SLx. Ac nid oes neb wedi tynnu rheolaeth seilwaith oddi arnynt, ac mae angen iddynt ddatrys digwyddiadau, a bod ar ddyletswydd o bryd i'w gilydd, ac aros ar ben prosesau busnes yn gyffredinol. A bois, dechreuwch raglennu fesul tipyn ar lefel dda, mae Google eisoes yn aros amdanoch chi.

I grynhoi. Yn sydyn, ond rydych chi eisoes wedi blino ar ddarllen ac ni allwch aros i boeri ac ysgrifennu at yr awdur mewn sylw ar yr erthygl. Mae DevOps fel arfer dosbarthu wedi bod ac y bydd. Ac nid yw'n mynd i unman. Mae ARhPh fel set o arferion gweithredol yn gwneud y ddarpariaeth hon yn llwyddiannus iawn.

Ffynhonnell: hab.com

Ychwanegu sylw