Mae'r diffiniad o DevOps yn gymhleth iawn, felly mae'n rhaid i ni ddechrau'r drafodaeth amdano eto bob tro. Mae mil o gyhoeddiadau ar y pwnc hwn ar Habré yn unig. Ond os ydych chi'n darllen hwn, mae'n debyg eich bod chi'n gwybod beth yw DevOps. Achos dydw i ddim. helo fy enw i yw Alexander Titov (@), a byddwn yn siarad am DevOps yn unig a byddaf yn rhannu fy mhrofiad.
Rydw i wedi bod yn meddwl ers amser maith sut i wneud fy stori yn ddefnyddiol, felly bydd llawer o gwestiynau yma - y rhai rydw i'n eu gofyn i mi fy hun a'r rhai rydw i'n eu gofyn i gleientiaid ein cwmni. Trwy ateb y cwestiynau hyn, daw dealltwriaeth yn well. Dywedaf wrthych pam fod angen DevOps o'm safbwynt i, beth ydyw, eto, o'm safbwynt i, a sut i ddeall eich bod yn symud tuag at DevOps eto o'm safbwynt i. Bydd y pwynt olaf drwy gwestiynau. Trwy eu hateb drosoch eich hun, gallwch ddeall a yw'ch cwmni'n symud tuag at DevOps neu a oes problemau mewn rhyw ffordd.
Ar un adeg roeddwn yn marchogaeth y tonnau o uno a chaffael. Yn gyntaf, roeddwn i'n gweithio i gwmni cychwyn bach o'r enw Qik, yna fe'i prynwyd gan gwmni ychydig yn fwy o'r enw Skype, a brynwyd wedyn gan gwmni ychydig yn fwy o'r enw Microsoft. Ar y foment honno, dechreuais weld sut roedd y syniad o DevOps yn trawsnewid mewn cwmnïau o wahanol faint. Ar ôl hynny, dechreuais ddiddordeb mewn edrych ar DevOps o safbwynt y farchnad, a sefydlodd fy nghydweithwyr a minnau'r cwmni Express 42. Am 6 mlynedd bellach rydym wedi bod yn symud ar hyd tonnau'r farchnad.
Ymhlith pethau eraill, rwy'n un o drefnwyr cymuned DevOps Moscow a threfnydd DevOps-Days 2017, ond ni threfnais 2018. Mae Express 42 yn gweithio gyda llawer o gwmnïau. Rydyn ni'n tyfu DevOps yno, yn gwylio sut mae'n digwydd, yn dod i gasgliadau, yn dadansoddi, yn dweud wrth bawb ein casgliadau, ac yn hyfforddi pobl mewn arferion DevOps. Yn gyffredinol, rydym yn gwneud ein gorau i gynyddu ein profiad a'n harbenigedd yn hyn o beth.
Pam DevOps
Y cwestiwn cyntaf sy'n poeni pawb a bob amser yw - pam? Mae llawer o bobl yn meddwl mai dim ond awtomeiddio yw DevOps neu rywbeth tebyg a oedd gan bob cwmni eisoes.
- Roedd gennym ni Integreiddio Parhaus - mae hyn yn golygu bod gennym ni DevOps eisoes, a pham mae angen yr holl bethau hyn? Maen nhw'n cael hwyl dramor, ond maen nhw'n ein hatal ni rhag gweithio!
Dros 9 mlynedd o ddatblygiad y gymuned a methodoleg, mae eisoes wedi dod yn amlwg nad yw hyn yn dal i fod yn gliter marchnata, ond nid yw'n gwbl glir o hyd pam mae ei angen. Fel unrhyw offeryn a phroses, mae gan DevOps nodau penodol y mae'n eu cyflawni yn y pen draw.
Mae hyn i gyd oherwydd y ffaith bod y byd yn newid. Mae'n symud i ffwrdd oddi wrth y dull menter, pan fydd cwmnïau'n symud yn syth tuag at freuddwyd, fel y canodd ein clasur St Petersburg, o bwynt A i bwynt B yn ôl strategaeth benodol, gyda strwythur penodol wedi'i adeiladu ar gyfer hyn.
Mewn egwyddor, dylid adeiladu popeth mewn TG yn unol â'r dull hwn. Yma defnyddir TG yn unig i awtomeiddio prosesau.
Nid yw awtomeiddio yn newid yn aml, oherwydd pan fydd cwmni'n mynd i lawr rhigol sydd wedi'i sathru'n dda, beth sydd i'w newid? Mae'n gweithio - peidiwch â chyffwrdd ag ef. Nawr mae dulliau gweithredu yn y byd yn newid, ac mae'r un a elwir Agile yn awgrymu nad yw diweddbwynt B i'w weld ar unwaith.
Pan fydd cwmni'n mynd drwy'r farchnad, yn gweithio gyda chleient, mae'n archwilio'r farchnad yn gyson ac yn newid y pwynt diwedd B. Ar ben hynny, po fwyaf aml mae'r cwmni'n newid ei gyfeiriad, y mwyaf llwyddiannus yw hi yn y diwedd, oherwydd ei fod yn dewis mwy o farchnad cilfachau.
Mae'r strategaeth yn cael ei dangos gan gwmni diddorol y dysgais amdano yn ddiweddar. Mae One Box Shave yn wasanaeth danfon tanysgrifiad ar gyfer raseli ac ategolion eillio mewn blwch. Maent yn gwybod sut i addasu eu “blwch” ar gyfer gwahanol gleientiaid. Gwneir hyn gan feddalwedd benodol, sydd wedyn yn anfon yr archeb i'r ffatri Corea sy'n cynhyrchu'r cynnyrch.
Prynwyd y cynnyrch hwn gan Unilever am $1 biliwn. Mae bellach yn cystadlu â Gillette ac wedi tynnu cyfran sylweddol o ddefnyddwyr yn y farchnad Americanaidd i ffwrdd. Mae One Box Shave yn dweud:
- 4 llafn? Ydych chi o ddifrif? Pam mae angen hyn arnoch chi - nid yw'n gwella ansawdd yr eillio. Mae hufen, persawr arbennig a rasel o ansawdd uchel gyda dau lafn yn datrys llawer mwy o broblemau na'r 4 llafn Gillette gwirion hynny! A fyddwn ni'n cyrraedd 10 yn fuan?
Dyma sut mae'r byd yn newid. Mae Unilever yn honni bod ganddyn nhw system TG cŵl sy'n eich galluogi chi i wneud hyn. Yn y diwedd mae'n edrych fel cysyniad Amser-i-farchnad, nad oes neb wedi siarad amdano eisoes.
Nid pwynt Amser-i-farchnad yw pa mor aml rydym yn defnyddio. Yn aml gallwch chi ddefnyddio, ond bydd y cylchoedd rhyddhau yn hir. Os caiff cylchoedd rhyddhau tri mis eu harosod ar ei gilydd, gan eu symud fesul wythnos, mae'n ymddangos ei bod yn ymddangos bod y cwmni'n defnyddio unwaith yr wythnos. Ac o'r syniad i'r gweithredu terfynol mae'n cymryd 3 mis.
Mae amser-i-farchnad yn ymwneud â lleihau'r amser rhwng y syniad a'r gweithredu terfynol.
Yn yr achos hwn, mae meddalwedd yn rhyngweithio â'r farchnad. Dyma sut mae gwefan One Box Shave yn rhyngweithio â'r cleient. Nid oes ganddynt werthwyr - dim ond gwefan lle mae ymwelwyr yn clicio ac yn gadael dymuniadau. Yn unol â hynny, rhaid postio rhywbeth newydd yn gyson ar y wefan a'i ddiweddaru yn unol â dymuniadau. Er enghraifft, yn Ne Korea maen nhw'n eillio'n wahanol nag yn Rwsia, ac maen nhw'n hoffi arogl nid pinwydd, ond, er enghraifft, moron a fanila.
Gan fod angen newid cynnwys y wefan yn gyflym, mae datblygu meddalwedd yn newid yn fawr. Trwy feddalwedd mae'n rhaid i ni ddarganfod beth mae'r cleient ei eisiau. Yn flaenorol, fe wnaethom ddysgu hyn trwy rai ffyrdd cylchfan, er enghraifft, trwy reoli busnes. Yna fe wnaethon ni ei ddylunio, rhoi'r gofynion yn y system TG, ac roedd popeth yn cŵl. Nawr mae'n wahanol - mae meddalwedd yn cael ei ddylunio gan bawb sy'n ymwneud â'r broses, gan gynnwys peirianwyr, oherwydd trwy fanylebau technegol maen nhw'n dysgu sut mae'r farchnad yn gweithio a hefyd yn rhannu eu mewnwelediad â'r busnes.
Er enghraifft, yn Qik fe wnaethon ni ddysgu'n sydyn bod pobl yn hoff iawn o uwchlwytho rhestrau cyswllt i'r gweinydd, a gwnaethon nhw roi cymhwysiad i ni. I ddechrau, ni wnaethom feddwl am y peth. Mewn cwmni clasurol, byddai pawb wedi penderfynu mai nam oedd hwn, gan nad oedd y fanyleb yn dweud y dylai weithio'n wych a'i fod yn cael ei weithredu'n gyffredinol ar y pen-glin, byddent wedi diffodd y nodwedd a dweud: "Nid oes angen hyn ar unrhyw un, y peth pwysicaf yw bod y prif swyddogaeth yn gweithio.” . Ac mae'r cwmni technoleg yn gweld hyn fel cyfle ac yn dechrau newid y meddalwedd yn unol â hyn.
Ym 1968, lluniodd dyn â gweledigaeth, Melvin Conway, y syniad canlynol.
Mae'r sefydliad sy'n creu'r system wedi'i gyfyngu gan ddyluniad sy'n efelychu strwythur cyfathrebu'r sefydliad hwnnw.
Yn fwy manwl, er mwyn cynhyrchu systemau o fath gwahanol, rhaid i chi hefyd gael strwythur cyfathrebu o fewn cwmni o fath gwahanol. Os yw eich strwythur cyfathrebu yn uwch-hierarchaidd, yna ni fydd hyn yn caniatáu ichi greu systemau a all ddarparu dangosydd Amser i'r Farchnad uchel iawn.
Darllen all neb . Mae'n bwysig deall diwylliant neu athroniaeth DevOps oherwydd yr unig beth sy'n newid yn sylfaenol yn DevOps yw'r strwythur cyfathrebu rhwng timau.
O safbwynt proses, cyn DevOps, roedd pob cam: dadansoddeg, datblygu, profi, gweithredu, yn llinol.
Yn achos DevOps, mae'r holl brosesau hyn yn digwydd ar yr un pryd.
Amser-i-farchnad yw'r unig ffordd y gellir ei wneud. I bobl a oedd yn gweithio yn yr hen broses, mae hyn yn edrych braidd yn gosmig, ac yn gyffredinol felly.
Felly pam mae angen DevOps arnoch chi?
Ar gyfer datblygu cynnyrch digidol. Os nad oes gan eich cwmni gynnyrch digidol, nid oes angen DevOps - mae'n bwysig iawn.
Mae DevOps yn goresgyn cyfyngiadau cyflymder cynhyrchu meddalwedd dilyniannol. Ynddo mae pob proses yn digwydd ar yr un pryd.
Anhawster yn cynyddu. Pan fydd efengylwyr DevOps yn dweud wrthych y bydd yn ei gwneud hi'n haws i chi ryddhau meddalwedd, mae hyn yn nonsens.
Gyda DevOps, bydd pethau ond yn mynd yn fwy cymhleth.
Yn y gynhadledd ar stondin Avito, fe allech chi weld sut brofiad oedd gosod cynhwysydd Docker - tasg afrealistig. Mae'r cymhlethdod yn dod yn afresymol; mae'n rhaid i chi jyglo llawer o beli ar yr un pryd.
Mae DevOps yn newid y broses a'r sefydliad yn y cwmni yn llwyr - yn fwy manwl gywir, nid DevOps sy'n newid, ond y cynnyrch digidol. I ddod i DevOps, mae angen i chi newid y broses hon yn llwyr o hyd.
Cwestiynau i arbenigwr
Beth sydd gennych chi? Cwestiynau y gallwch eu gofyn i chi'ch hun wrth weithio mewn cwmni a datblygu fel arbenigwr.
A oes gennych strategaeth ar gyfer creu cynnyrch digidol? Os oes, mae hynny eisoes yn dda. Mae hyn yn golygu bod eich cwmni'n symud tuag at DevOps.
A yw eich cwmni eisoes yn creu cynnyrch digidol? Mae hyn yn golygu y gallwch chi godi lefel arall yn uwch a gwneud pethau'n fwy diddorol - eto o safbwynt DevOps. Dim ond o'r safbwynt hwn yr wyf yn siarad.
A yw eich cwmni yn un o arweinwyr y farchnad yn y gilfach cynnyrch digidol? Mae Spotify, Yandex, Uber yn gwmnïau sydd ar eu hanterth nawr o ran cynnydd technolegol.
Gofynnwch y cwestiynau hyn i chi'ch hun, ac os nad yw'r holl atebion, yna efallai na ddylech chi wneud DevOps yn y cwmni hwn. Os yw pwnc DevOps yn ddiddorol iawn i chi, efallai ... y dylech chi symud i gwmni arall? Os yw'ch cwmni eisiau mynd i mewn i DevOps, ond ichi ateb “Na” i'r holl gwestiynau, yna mae fel y rhinoseros hardd hwnnw na fydd byth yn newid.
Sefydliad
Fel y dywedais, yn ôl Cyfraith Conwy, mae trefniadaeth cwmni yn newid. Dechreuaf gyda'r hyn sy'n atal DevOps rhag treiddio y tu mewn i'r cwmni o safbwynt sefydliadol.
Y broblem o "ffynhonnau"
Mae'r gair Saesneg "Silo" yn cael ei gyfieithu yma i Rwsieg fel "wel". Pwynt y broblem hon yw hynny nid oes cyfnewid gwybodaeth rhwng timau. Mae pob tîm yn cloddio'n ddwfn i'w harbenigedd, heb adeiladu map cyffredin i'w lywio.
Mewn rhai ffyrdd mae hyn yn fy atgoffa o berson sydd newydd gyrraedd Moscow ac nad yw'n gwybod eto sut i lywio'r map metro. Mae Muscovites fel arfer yn adnabod eu hardal yn dda iawn, a ledled Moscow gallant lywio gan ddefnyddio'r map metro. Pan fyddwch chi'n dod i Moscow am y tro cyntaf, nid oes gennych chi'r sgil hon, ac rydych chi'n ddryslyd.
Mae DevOps yn awgrymu mynd trwy'r eiliad hon o ddryswch a bod pob adran yn cydweithio i adeiladu map rhyngweithio cyffredin.
Mae dau ffactor yn rhwystro hyn.
Canlyniad y system rheoli corfforaethol. Mae wedi'i adeiladu mewn “ffynhonnau” hierarchaidd ar wahân. Er enghraifft, mae rhai DPAau mewn cwmnïau sy'n cefnogi'r system hon. Ar y llaw arall, mae ymennydd person sy'n ei chael hi'n anodd mynd y tu hwnt i ffiniau eu harbenigedd a llywio'r system gyfan yn rhwystro. Mae'n anghyfforddus yn unig. Dychmygwch eich bod ym maes awyr Bangkok - ni fyddwch yn dod o hyd i'ch ffordd o gwmpas yn gyflym. Mae DevOps hefyd yn anodd ei lywio, a dyna pam mae pobl yn dweud bod angen i chi ddod o hyd i ganllaw i gyrraedd yno.
Ond y peth pwysicaf yw bod problem “ffynhonnau” i beiriannydd sydd wedi'i drwytho ag ysbryd DevOps, sydd wedi darllen Fowler a chriw o lyfrau eraill, yn cael ei mynegi yn y ffaith bod nid yw "ffynhonnau" yn caniatáu ichi wneud pethau "amlwg".. Rydyn ni'n aml yn dod at ein gilydd ar ôl DevOps Moscow, yn siarad â'n gilydd, ac mae pobl yn cwyno:
- Roeddem ni eisiau lansio CI, ond daeth i'r amlwg nad oedd ei angen ar reolwyr.
Mae hyn yn digwydd yn union oherwydd CI и Proses Cyflenwi Parhaus sydd ar ffin llawer o arholiadau. Yn syml, heb oresgyn y broblem o “ffynhonnau” ar y lefel sefydliadol, ni fyddwch yn gallu symud ymlaen, ni waeth beth a wnewch a waeth pa mor drist ydyw.
Mae pob cyfranogwr yn y broses yn y cwmni: datblygwyr cefn a blaen, profi, DBA, gweithrediad, rhwydwaith, yn cloddio yn eu cyfeiriad eu hunain, ac nid oes gan unrhyw un fap cyffredin ac eithrio'r rheolwr, sydd rywsut yn eu monitro ac yn eu rheoli gan ddefnyddio'r “rhannu a gorchfygu" dull.
Mae pobl yn ymladd am rai sêr neu fflagiau, mae pawb yn cloddio eu harbenigedd.
O ganlyniad, pan gyfyd y dasg o gysylltu hyn i gyd ac adeiladu piblinell gyffredin, ac nad oes angen ymladd am sêr a baneri mwyach, mae'r cwestiwn yn codi - beth i'w wneud beth bynnag? Mae angen dod i gytundeb rhywsut, ond ni ddysgodd neb i ni sut i wneud hyn yn yr ysgol. Rydyn ni wedi cael ein haddysgu ers yr ysgol: wythfed gradd - waw! - o'i gymharu â seithfed gradd! Mae yr un peth yma.
A yw'r un peth yn eich cwmni?
I wirio hyn, gallwch ofyn y cwestiynau canlynol i chi'ch hun.
A yw timau'n defnyddio offer cyffredin ac yn cyfrannu at newidiadau i'r offer cyffredin hynny?
Pa mor aml mae timau'n ad-drefnu - mae rhai arbenigwyr o un tîm yn symud i dîm arall? Mewn amgylchedd DevOps y daw hyn yn normal, oherwydd weithiau ni all person ddeall beth mae maes arall o arbenigedd yn ei wneud. Mae'n symud i adran arall, yn gweithio yno am bythefnos i greu map iddo'i hun o gyfeiriadaeth a rhyngweithio â'r adran hon.
Oes modd ffurfio pwyllgor newid a newid pethau? Neu a yw'n gofyn am law gref y rheolaeth a'r cyfeiriad uchaf? Ysgrifennais ar Facebook yn ddiweddar sut mae un banc anhysbys yn gweithredu offer trwy orchmynion: rydyn ni'n ysgrifennu gorchymyn, rydyn ni'n ei weithredu am flwyddyn, ac yn gweld beth sy'n digwydd. Mae hyn, wrth gwrs, yn hir ac yn drist.
Pa mor bwysig yw hi i reolwyr dderbyn cyflawniadau personol heb ystyried cyflawniadau'r cwmni?
Os atebwch y cwestiynau hyn drosoch eich hun, daw'n gliriach a oes gennych broblem o'r fath yn eich cwmni.
Isadeiledd fel cod
Ar ôl i'r broblem hon gael ei phasio, yr arfer pwysig cyntaf, hebddo mae'n anodd symud ymlaen ymhellach yn DevOps, yw seilwaith fel cod.
Yn fwyaf aml, mae seilwaith fel cod yn cael ei ganfod fel a ganlyn:
— Gadewch i ni awtomeiddio popeth mewn bash, gorchuddio ein hunain â sgriptiau fel bod gan weinyddwyr lai o waith llaw!
Ond nid yw hynny'n wir.
Mae seilwaith fel cod yn golygu eich bod yn disgrifio'r system TG rydych yn gweithio gyda hi ar ffurf cod er mwyn deall ei chyflwr yn gyson.
Ynghyd â thimau eraill, rydych chi'n creu map ar ffurf cod y gall pawb ei ddeall a'i lywio a'i lywio. Nid oes ots beth mae wedi'i wneud arno - Cogydd, Ansible, Halen, neu ddefnyddio ffeiliau YAML yn Kubernetes - does dim gwahaniaeth.
Yn y gynhadledd, dywedodd cydweithiwr o 2GIS sut y gwnaethant eu peth mewnol eu hunain ar gyfer Kubernetes, sy'n disgrifio strwythur systemau unigol. I ddisgrifio 500 o systemau, roedd angen teclyn ar wahân arnynt sy'n cynhyrchu'r disgrifiad hwn. Pan fo'r disgrifiad hwn, gall pawb wirio gyda'i gilydd, monitro newidiadau, sut i'w newid a'i wella, beth sydd ar goll.
Cytuno, nid yw sgriptiau bash unigol fel arfer yn darparu'r ddealltwriaeth hon. Yn un o’r cwmnïau lle roeddwn i’n gweithio, roedd hyd yn oed enw ar gyfer sgript “ysgrifennu yn unig” – pan mae’r sgript yn cael ei hysgrifennu, ond nid yw’n bosibl ei darllen mwyach. Rwy'n meddwl bod hyn yn gyfarwydd i chi hefyd.
Isadeiledd fel y mae cod cod sy’n disgrifio cyflwr presennol y seilwaith. Mae llawer o dimau cynnyrch, seilwaith a gwasanaeth yn cydweithio ar y cod hwn, ac yn bwysicaf oll, mae angen iddynt oll ddeall sut mae'r cod hwn yn gweithio mewn gwirionedd.
Mae'r cod yn cael ei gynnal yn unol ag arferion cod gorau: datblygu ar y cyd, adolygu cod, XP-rhaglennu, profi, tynnu ceisiadau, CI ar gyfer seilweithiau cod - mae hyn i gyd yn addas a gellir ei ddefnyddio.
Daw cod yn iaith gyffredin i bob peiriannydd.
Nid yw newid seilwaith mewn cod yn cymryd llawer o amser. Oes, gall cod seilwaith hefyd gael dyled dechnegol. Fel arfer mae timau yn dod ar ei draws flwyddyn a hanner ar ôl iddynt ddechrau gweithredu “isadeiledd fel cod” ar ffurf criw o sgriptiau neu hyd yn oed Ansible, y maent yn eu hysgrifennu fel cod sbageti, ac maent hefyd yn taflu sgriptiau bash i'r gymysgedd!
Mae'n bwysig: Os nad ydych wedi rhoi cynnig ar y stwff hwn eto, cofiwch hynny Nid yw Ansible yn bash! Darllenwch y ddogfennaeth yn ofalus, astudiwch yr hyn y maent yn ei ysgrifennu amdano.
Seilwaith fel cod yw gwahanu cod seilwaith yn haenau ar wahân.
Yn ein cwmni, rydym yn gwahaniaethu 3 haen sylfaenol, sy'n glir iawn ac yn syml, ond efallai y bydd mwy ohonynt. Gallwch edrych ar eich cod seilwaith a dweud a oes gennych y cyflwr hwn ai peidio. Os nad oes unrhyw haenau wedi'u hamlygu, yna mae angen i chi gymryd peth amser ac ailffactorio ychydig.
haen sylfaen - dyma sut mae'r OS, copïau wrth gefn a phethau lefel isel eraill yn cael eu ffurfweddu, er enghraifft, sut mae Kubernetes yn cael ei ddefnyddio ar y lefel sylfaenol.
Lefel gwasanaeth - dyma'r gwasanaethau yr ydych yn eu darparu i'r datblygwr: logio fel gwasanaeth, monitro fel gwasanaeth, cronfa ddata fel gwasanaeth, cydbwysedd fel gwasanaeth, ciw fel gwasanaeth, Cyflenwi Parhaus fel gwasanaeth - criw o wasanaethau y mae timau unigol yn gallu darparu ar gyfer datblygiad. Mae angen disgrifio hyn i gyd mewn modiwlau ar wahân yn eich system rheoli cyfluniad.
Yr haen lle gwneir ceisiadau ac yn disgrifio sut y byddant yn datblygu ar ben y ddwy haen flaenorol.
Cwestiynau rheoli
A oes gan eich cwmni storfa seilwaith cyffredin? A ydych yn rheoli dyled dechnegol yn eich seilwaith? A ydych yn defnyddio arferion datblygu mewn ystorfa seilwaith? A yw eich seilwaith wedi'i sleisio'n haenau? Gallwch wirio'r diagram Sylfaen-service-APP. Pa mor anodd yw hi i wneud newid?
Os ydych chi wedi profi ei bod wedi cymryd diwrnod a hanner i wneud newidiadau, mae hyn yn golygu bod gennych chi ddyled dechnegol a bod angen i chi weithio gydag ef. Rydych chi newydd faglu ar gribin dyled dechnegol yn eich cod seilwaith. Rwy'n cofio llawer o straeon o'r fath pan, er mwyn newid rhywfaint o CCTL, mae angen ichi ailysgrifennu hanner y cod seilwaith, oherwydd arweiniodd creadigrwydd a'r awydd i awtomeiddio popeth at y ffaith bod popeth wedi cyrydu ym mhobman, mae'r holl ddolenni wedi'u tynnu, a mae angen ailffactorio.
Cyflwyno'n Barhaus
Gadewch i ni gymharu debyd â chredyd. Yn gyntaf daw disgrifiad o'r seilwaith, a all fod yn eithaf sylfaenol. Nid oes rhaid i chi ddisgrifio popeth yn fanwl, ond mae angen rhywfaint o ddisgrifiad sylfaenol er mwyn i chi allu gweithio ag ef. Fel arall, nid yw'n glir beth i'w wneud gyda darpariaeth barhaus nesaf. Mae'r holl arferion hyn yn datblygu ar yr un pryd pan fyddwch chi'n dod i DevOps, ond mae'n dechrau gyda deall yr hyn sydd gennych chi a sut i'w reoli. Dyma'n union arfer seilwaith fel cod.
Unwaith y daw'n amlwg bod gennych chi a sut i'w reoli, byddwch chi'n dechrau darganfod sut i anfon cod y datblygwr i'r cynhyrchiad cyn gynted â phosibl. Yr wyf yn golygu ynghyd â'r datblygwr - rydym yn cofio am y broblem o "ffynhonnau", hynny yw, nid pobl unigol sy'n meddwl am hyn, ond tîm.
Pan fyddwn ni gyda Vanya Evtukhovich gwelodd y llyfr cyntaf Jez Humble a grwpiau o awduron "Cyflenwi Parhaus", a ryddhawyd yn 2009, buom yn meddwl am amser hir am sut i gyfieithu ei deitl i Rwsieg. Roeddent am ei gyfieithu fel “Cyson yn cyflenwi”, ond, yn anffodus, fe’i cyfieithwyd fel “Cyflenwi parhaus”. Ymddengys i mi fod rhywbeth Rwsiaidd yn ein henw ni, gyda phwysau.
Cyflwyno moddion yn gyson
Gellir lawrlwytho cod sydd yn y storfa cynnyrch bob amser i'w gynhyrchu. Efallai na fydd yn cael ei ddatchwyddo, ond mae bob amser yn barod ar ei gyfer. Yn unol â hynny, rydych chi bob amser yn ysgrifennu cod gyda theimlad anodd ei egluro o rywfaint o bryder o dan asgwrn eich cynffon. Mae’n ymddangos yn aml pan fyddwch yn cyflwyno cod seilwaith. Dylai'r teimlad hwn o bryder fod yn bresennol - mae'n sbarduno prosesau ymennydd sy'n eich galluogi i ysgrifennu cod ychydig yn wahanol. Dylid cofnodi hyn yn y rheolau o fewn y datblygiad.
Er mwyn cyflawni'n gyson, mae angen fformat arteffact arnoch sy'n rhedeg ar draws platfform seilwaith. Os ydych chi'n taflu “gwastraff bywyd” o wahanol fformatau ar draws platfform seilwaith, yna mae'n dod yn unedig, mae'n anodd ei gynnal, ac mae problem dyled dechnegol yn codi. Mae angen alinio fformat yr arteffact - mae hon hefyd yn dasg gyfunol: mae angen i ni i gyd ddod at ein gilydd, siffrwd yn ein hymennydd a meddwl am y fformat hwn.
Mae'r arteffact yn cael ei wella'n barhaus ac yn newid i weddu i'r amgylchedd cynhyrchu wrth iddo symud trwy'r biblinell ddosbarthu. Pan fydd arteffact yn symud ar hyd y biblinell, mae'n dod ar draws rhai pethau anghyfleus yn gyson ar ei gyfer, sy'n debyg i'r hyn y mae'r arteffact rydych chi'n ei roi mewn cynhyrchiad yn dod ar ei draws. Os mewn datblygiad clasurol mae hyn yn cael ei wneud gan weinyddwr system sy'n cyflwyno'r system, yna yn y broses DevOps mae hyn yn digwydd drwy'r amser: yma fe wnaethon nhw ei brofi gyda rhai profion, yma fe wnaethon nhw ei daflu i mewn i glwstwr Kubernetes, sy'n debyg fwy neu lai. i gynhyrchu, yna yn sydyn dechreuon nhw brofi llwyth .
Mae hyn braidd yn atgoffa rhywun o gêm Pac-Man - mae'r arteffact yn mynd trwy ryw fath o stori. Ar yr un pryd, mae'n bwysig rheoli a yw'r cod yn mynd trwy'r stori mewn gwirionedd ac a yw'n gysylltiedig â'ch cynhyrchiad rywsut. Gellir llusgo straeon o gynhyrchu i'r broses Cyflenwi Parhaus: roedd fel hyn pan syrthiodd rhywbeth, nawr gadewch i ni raglennu'r senario hwn y tu mewn i'r system. Bob tro bydd y cod yn mynd trwy'r senario hwn hefyd, ac ni fyddwch yn dod ar draws y broblem hon y tro nesaf. Byddwch yn dysgu amdano yn llawer cynt nag y mae'n cyrraedd eich cleient.
Strategaethau lleoli gwahanol. Er enghraifft, rydych chi'n defnyddio profion AB neu osodiadau caneri i brofi'r cod yn wahanol ar wahanol gleientiaid, cael gwybodaeth am sut mae'r cod yn gweithio, a llawer cynt na phan gaiff ei gyflwyno i 100 miliwn o ddefnyddwyr.
Mae “cyflenwi cyson” yn edrych fel hyn.
Nid yw'r broses gyflenwi Dev, CI, Test, PreProd, Prod yn amgylchedd ar wahân, mae'r rhain yn gamau neu orsafoedd gyda symiau gwrth-dân y mae'ch arteffact yn mynd trwyddynt.
Os oes gennych god seilwaith a ddisgrifir fel APP Gwasanaeth Sylfaenol yna mae'n helpu peidiwch ag anghofio'r holl sgriptiau, ac ysgrifennwch nhw fel cod ar gyfer yr arteffact hwn, hyrwyddo arteffact a'i newid wrth fynd.
Cwestiynau hunan-brawf
Mae'r amser rhwng disgrifiad nodwedd a rhyddhau i gynhyrchu mewn 95% o achosion yn llai nag wythnos? A yw ansawdd yr arteffact yn gwella ym mhob cam o'r biblinell? A oes stori y mae'n mynd drwyddi? Ydych chi'n defnyddio gwahanol strategaethau lleoli?
Os yw'r holl atebion yn gadarnhaol, yna rydych chi'n anhygoel o cŵl! Ysgrifennwch eich atebion yn y sylwadau - byddaf yn falch).
Adborth
Dyma'r arfer anoddaf oll. Yng nghynhadledd DevOpsConf, roedd cydweithiwr o Infobip, yn siarad amdano, ychydig yn ddryslyd yn ei eiriau, oherwydd mae hwn mewn gwirionedd yn arfer cymhleth iawn am y ffaith bod angen i chi fonitro popeth!
Er enghraifft, amser maith yn ôl, pan oeddwn yn gweithio yn Qik a sylweddolom fod angen inni fonitro popeth. Gwnaethom hyn, a bellach mae gennym 150 o eitemau yn Zabbix, sy’n cael eu monitro’n gyson. Roedd yn frawychus, trodd y cyfarwyddwr technegol ei fys at ei deml:
- Guys, pam yr ydych yn treisio y gweinydd gyda rhywbeth aneglur?
Ond yna digwyddodd digwyddiad a ddangosodd fod hon yn strategaeth cŵl iawn mewn gwirionedd.
Dechreuodd un o'r gwasanaethau chwalu'n gyson. I ddechrau, ni chwalodd, sy'n ddiddorol, ni ychwanegwyd y cod yno, oherwydd ei fod yn frocer sylfaenol, nad oedd ganddo ymarferoldeb busnes yn ymarferol - yn syml, anfonodd negeseuon rhwng gwasanaethau unigol. Ni newidiodd y gwasanaeth am 4 mis, ac yn sydyn dechreuodd ddamwain gyda'r gwall “bai segmentu”.
Cawsom sioc, agorodd ein siartiau yn Zabbix, a daeth i'r amlwg, wythnos a hanner yn ôl, bod ymddygiad ceisiadau yn y gwasanaeth API y mae'r brocer hwn yn ei ddefnyddio wedi newid yn fawr. Nesaf gwelsom fod amlder anfon math arbennig o neges wedi newid. Yn ddiweddarach cawsom wybod mai cleientiaid android oedd y rhain. Gofynnon ni:
— Dynion, beth ddigwyddodd i chi wythnos a hanner yn ôl?
Mewn ymateb, clywsom stori ddiddorol am sut yr oeddent wedi ailgynllunio'r UI. Mae'n annhebygol y bydd unrhyw un yn dweud ar unwaith eu bod wedi newid y llyfrgell HTTP. I gleientiaid Android, mae fel newid sebon yn yr ystafell ymolchi - nid ydyn nhw'n cofio. O ganlyniad, ar ôl 40 munud o sgwrs, fe wnaethom ddarganfod eu bod wedi newid y llyfrgell HTTP, a bod ei hamseriadau rhagosodedig wedi newid. Arweiniodd hyn at newid ymddygiad traffig ar y gweinydd API, a arweiniodd at sefyllfa a achosodd ras o fewn y brocer, a dechreuodd ddamwain.
Heb fonitro dwfn mae'n gyffredinol amhosibl agor hwn. Os yw’r sefydliad yn dal i gael y broblem o “ffynhonnau”, pan fydd pawb yn taflu arian at ei gilydd, gall hyn fyw ymlaen am flynyddoedd. Yn syml, rydych chi'n ailgychwyn y gweinydd oherwydd ei bod yn amhosibl datrys y broblem. Pan fyddwch chi'n monitro, olrhain, olrhain yr holl ddigwyddiadau sydd gennych chi, a defnyddio monitro fel profion - ysgrifennwch y cod a nodwch ar unwaith sut i'w fonitro, hefyd ar ffurf cod (mae gennym ni'r seilwaith fel cod eisoes), daw popeth yn glir sut ar gledr. Mae hyd yn oed problemau cymhleth o'r fath yn hawdd eu holrhain.
Casglwch yr holl wybodaeth am yr hyn sy'n digwydd i'r arteffact ym mhob cam o'r broses gyflwyno - nid wrth gynhyrchu.
Llwythwch y monitro i CI, a bydd rhai pethau sylfaenol eisoes yn weladwy yno. Yn ddiweddarach byddwch yn eu gweld yn Test, PredProd, a phrofi llwyth. Casglu gwybodaeth ar bob cam, nid yn unig metrigau, ystadegau, ond hefyd logiau: sut y mae'r cais yn cael ei gyflwyno, anghysondebau - casglwch bopeth.
Fel arall bydd yn anodd ei ddarganfod. Dywedais eisoes fod DevOps yn fwy cymhleth. Er mwyn ymdopi â'r cymhlethdod hwn, mae angen i chi gael dadansoddeg arferol.
Cwestiynau ar gyfer hunanreolaeth
Ai eich monitro a logio yw'r offeryn datblygu i chi? Wrth ysgrifennu cod, a yw eich datblygwyr, gan gynnwys chi, yn meddwl am sut i'w fonitro?
Ydych chi'n clywed am broblemau gan gwsmeriaid? Ydych chi'n deall y cleient yn well o fonitro a logio? Ydych chi'n deall y system yn well o fonitro a logio? A ydych yn newid y system yn syml oherwydd eich bod wedi gweld bod y duedd yn y system yn tyfu a’ch bod yn deall y bydd popeth yn marw ymhen 3 wythnos arall?
Unwaith y bydd gennych y tair cydran hyn, gallwch feddwl am ba fath o lwyfan seilwaith sydd gennych yn eich cwmni.
Llwyfan seilwaith
Nid y pwynt yw ei fod yn set o offer gwahanol sydd gan bob cwmni.
Pwynt platfform seilwaith yw bod pob tîm yn defnyddio'r offer hyn ac yn eu datblygu gyda'i gilydd.
Mae’n amlwg bod timau ar wahân sy’n gyfrifol am ddatblygu darnau unigol o’r llwyfan seilwaith. Ond ar yr un pryd, mae pob peiriannydd yn gyfrifol am ddatblygiad, perfformiad a hyrwyddo'r platfform seilwaith. Ar lefel fewnol mae'n dod yn offeryn cyffredin.
Mae pob tîm yn datblygu'r llwyfan seilwaith ac yn ei drin â gofal fel eu DRhA eu hunain. Yn eich DRhA rydych chi'n gosod gwahanol ategion i wneud popeth yn braf ac yn gyflym, ac yn ffurfweddu allweddi poeth. Pan fyddwch chi'n agor Sublime, Atom neu Visual Studio Code, mae gwallau cod yn arllwys i mewn ac rydych chi'n sylweddoli ei bod hi'n amhosibl gweithio o gwbl, rydych chi'n teimlo'n drist ar unwaith ac rydych chi'n rhedeg i drwsio'ch IDE.
Trin eich platfform seilwaith yr un ffordd. Os ydych yn deall bod rhywbeth o'i le arno, gadewch gais os na allwch ei drwsio eich hun. Os oes rhywbeth syml, golygwch ef eich hun, anfonwch gais tynnu, bydd y dynion yn ei ystyried a'i ychwanegu. Mae hwn yn ymagwedd ychydig yn wahanol at offer peirianneg ym mhen y datblygwr.
Mae'r platfform seilwaith yn sicrhau bod yr arteffact yn cael ei drosglwyddo o'r datblygiad i'r cleient gyda gwelliant parhaus mewn ansawdd. Mae'r IP wedi'i raglennu gyda set o straeon sy'n digwydd i'r cod wrth gynhyrchu. Dros y blynyddoedd o ddatblygiad, mae yna lawer o'r straeon hyn, mae rhai ohonyn nhw'n unigryw ac yn berthnasol i chi yn unig - ni ellir eu Googled.
Ar y pwynt hwn, mae'r platfform seilwaith yn dod yn fantais gystadleuol i chi, oherwydd bod ganddo rywbeth wedi'i ymgorffori ynddo nad yw yn offeryn y cystadleuydd. Po ddyfnaf yw eich eiddo deallusol, y mwyaf yw eich mantais gystadleuol o ran Amser-i-farchnad. Yn ymddangos yma problem clo gwerthwr: Gallwch chi gymryd platfform rhywun arall, ond gan ddefnyddio profiad rhywun arall, ni fyddwch chi'n deall pa mor berthnasol ydyw i chi. Ydy, ni all pob cwmni adeiladu platfform fel Amazon. Mae hon yn llinell anodd lle mae profiad y cwmni yn berthnasol i'w safle yn y farchnad, ac ni allwch ddefnyddio clo gwerthwr yno. Mae hyn hefyd yn bwysig i feddwl amdano.
Cynllun
Mae hwn yn ddiagram sylfaenol o lwyfan seilwaith a fydd yn eich helpu i sefydlu'r holl arferion a phrosesau mewn cwmni DevOps.
Gadewch i ni edrych ar yr hyn y mae'n ei gynnwys.
System offeryniaeth adnoddau, sy'n darparu CPU, cof, disg i gymwysiadau a gwasanaethau eraill. Ar ben hyn - gwasanaethau lefel isel: monitro, logio, CI/CD Engine, storio arteffactau, seilwaith fel cod system.
Gwasanaethau lefel uwch: cronfa ddata fel gwasanaeth, ciwiau fel gwasanaeth, Cydbwysedd Llwyth fel gwasanaeth, newid maint delwedd fel gwasanaeth, ffatri Data Mawr fel gwasanaeth. Ar ben hyn - piblinell sy'n darparu cod wedi'i addasu'n gyson i'ch cleient.
Rydych chi'n derbyn gwybodaeth am sut mae'ch meddalwedd yn gweithio i'r cleient, yn ei newid, yn cyflenwi'r cod hwn eto, yn derbyn gwybodaeth - ac felly rydych chi'n datblygu'r platfform seilwaith a'ch meddalwedd yn gyson.
Yn y diagram, mae'r biblinell ddosbarthu yn cynnwys llawer o gamau. Ond mae hwn yn ddiagram sgematig a roddir fel enghraifft - nid oes angen ei ailadrodd fesul un. Mae camau'n rhyngweithio â gwasanaethau fel pe baent yn wasanaethau - mae gan bob bricsen o'r platfform ei stori ei hun: sut mae adnoddau'n cael eu dyrannu, sut mae'r cymhwysiad yn cael ei lansio, yn gweithio gydag adnoddau, yn cael ei fonitro, a newidiadau.
Mae'n bwysig deall bod pob rhan o'r platfform yn cario stori, a gofynnwch i chi'ch hun pa stori y mae'r fricsen hon yn ei chario, efallai y dylid ei thaflu i ffwrdd a rhoi gwasanaeth trydydd parti yn ei le. Er enghraifft, a yw'n bosibl gosod Okmeter yn lle brics? Efallai bod y dynion eisoes wedi datblygu'r arbenigedd hwn yn llawer mwy nag sydd gennym ni. Ond efallai ddim - efallai bod gennym ni arbenigedd unigryw, mae angen i ni osod Prometheus a'i ddatblygu ymhellach.
Creu'r platfform
Mae hon yn broses gyfathrebu gymhleth. Pan fydd gennych arferion sylfaenol, byddwch yn dechrau cyfathrebu rhwng gwahanol beirianwyr ac arbenigwyr sy'n datblygu gofynion a safonau, ac yn eu newid yn gyson i wahanol offer a dulliau. Mae'r diwylliant sydd gennym ni yn DevOps yn bwysig yma.
Gyda diwylliant mae popeth yn syml iawn - mae'n ymwneud â chydweithio a chyfathrebu, hynny yw, yr awydd i weithio mewn maes cyffredin â'i gilydd, yr awydd i drin un offeryn gyda'i gilydd. Nid oes gwyddoniaeth roced yma - mae popeth yn syml iawn, banal. Er enghraifft, rydyn ni i gyd yn byw yn y fynedfa ac yn ei gadw'n lân - y fath lefel o ddiwylliant.
Beth sydd gennych chi?
Unwaith eto, cwestiynau y gallwch eu gofyn i chi'ch hun.
A yw'r platfform seilwaith wedi'i neilltuo? Pwy sy'n gyfrifol am ei ddatblygiad? Ydych chi'n deall manteision cystadleuol eich platfform seilwaith?
Mae angen ichi ofyn y cwestiynau hyn i chi'ch hun yn gyson. Os gellir trosglwyddo rhywbeth i wasanaethau trydydd parti, dylid ei drosglwyddo; os yw gwasanaeth trydydd parti yn dechrau rhwystro'ch symudiad, yna mae angen i chi adeiladu system yn eich hun.
Felly, DevOps...
... mae hon yn system gymhleth, rhaid iddi gael:
- Cynnyrch digidol.
- Modiwlau busnes sy'n datblygu'r cynnyrch digidol hwn.
- Timau cynnyrch sy'n ysgrifennu cod.
- Arferion Cyflwyno Parhaus.
- Llwyfannau fel gwasanaeth.
- Isadeiledd fel gwasanaeth.
- Isadeiledd fel cod.
- Arferion ar wahân ar gyfer cynnal dibynadwyedd, wedi'u hymgorffori yn DevOps.
- Arfer adborth sy'n disgrifio'r cyfan.
Gallwch ddefnyddio'r diagram hwn, gan amlygu ynddo'r hyn sydd gennych eisoes yn eich cwmni ar ryw ffurf: a yw wedi datblygu neu sydd angen ei ddatblygu o hyd.
Bydd drosodd ymhen ychydig wythnosau . fel rhan o RIT++. Dewch i'r gynhadledd, lle byddwch yn dod o hyd i lawer o adroddiadau cŵl am gyflenwi parhaus, seilwaith fel cod a thrawsnewid DevOps. , dyddiad cau pris olaf yw Mai 20
Ffynhonnell: hab.com