Mae'r cwestiwn "sut i weithredu devops" wedi bod o gwmpas ers blynyddoedd, ond nid oes llawer o ddeunyddiau da. Weithiau rydych chi'n dioddef hysbysebion gan ymgynghorwyr nad ydyn nhw mor smart sydd angen gwerthu eu hamser, waeth sut. Weithiau mae'r rhain yn eiriau amwys, hynod gyffredinol am sut mae llongau megagorfforaethau yn aredig ehangder y bydysawd. Mae'r cwestiwn yn codi: beth sydd o bwys i ni? Annwyl awdur, a allwch chi lunio'ch syniadau'n glir mewn rhestr?
Mae hyn i gyd yn deillio o'r ffaith nad oes llawer o ymarfer a dealltwriaeth wirioneddol o ganlyniad trawsnewidiadau diwylliant y cwmni wedi cronni. Mae newidiadau mewn diwylliant yn bethau hirdymor, na fydd eu canlyniadau'n ymddangos mewn wythnos neu fis. Rydym angen rhywun digon hen i fod wedi gweld sut mae cwmnïau wedi cael eu hadeiladu a methu dros y blynyddoedd.
John Willis - un o dadau DevOps. Mae gan John ddegawdau o brofiad yn gweithio gyda nifer enfawr o gwmnïau. Yn ddiweddar, dechreuodd John sylwi ar batrymau penodol sy'n digwydd wrth weithio gyda phob un ohonynt. Gan ddefnyddio'r archdeipiau hyn, mae John yn arwain cwmnïau ar y llwybr gwirioneddol o drawsnewid DevOps. Darllenwch fwy am yr archeteipiau hyn yn y cyfieithiad o'i adroddiad o gynhadledd DevOops 2018.
Am y siaradwr:
Mwy na 35 mlynedd mewn rheoli TG, cymryd rhan mewn creu rhagflaenydd OpenCloud yn Canonical, cymryd rhan mewn 10 startups, dau ohonynt yn gwerthu i Dell a Docker. Ar hyn o bryd mae'n Is-lywydd DevOps ac Arferion Digidol yn SJ Technologies.
Nesaf mae'r stori o safbwynt Ioan.
Fy enw i yw John Willis a'r lle hawsaf i ddod o hyd i mi yw ar Twitter, . Mae gen i'r un arallenw ar Gmail a GitHub. A gallwch ddod o hyd i recordiadau fideo o fy adroddiadau a chyflwyniadau ar eu cyfer.
Mae gen i lawer o gyfarfodydd gyda CIOs o gwmnïau mawr amrywiol. Yn aml iawn maen nhw'n cwyno nad ydyn nhw'n deall beth yw DevOps, ac mae pawb sy'n ceisio ei esbonio iddyn nhw yn siarad am rywbeth gwahanol. Cwyn gyffredin arall yw nad yw DevOps yn gweithio, er ei bod yn ymddangos bod y cyfarwyddwyr yn gwneud popeth fel yr eglurwyd iddynt. Yr ydym yn sôn am gwmnïau mawr sy’n fwy na chan mlwydd oed. Ar ôl siarad â nhw, deuthum i'r casgliad, ar gyfer llawer o broblemau, nad technoleg uchel sydd fwyaf addas, ond yn hytrach atebion technoleg isel. Am wythnosau bûm yn siarad â phobl o wahanol adrannau. Beth welwch chi yn y llun cyntaf un yn y post yw fy mhrosiect olaf, dyma sut roedd yr ystafell yn edrych ar ôl tri diwrnod o waith.
Beth yw DevOps?
Yn wir, os gofynnwch i 10 o bobl wahanol, byddant yn rhoi 10 ateb gwahanol. Ond dyma'r peth diddorol: bydd pob un o'r deg ateb hyn yn gywir. Nid oes ateb anghywir yma. Roeddwn yn eithaf dwfn i DevOps, am tua 10 mlynedd, a fi oedd yr Americanwr cyntaf yn y DevOpsDay cyntaf. Ni ddywedaf fy mod yn gallach na phawb sy'n ymwneud â DevOps, ond prin fod unrhyw un sydd wedi gwario cymaint o ymdrech arno. Credaf fod DevOps yn digwydd pan ddaw cyfalaf dynol a thechnoleg at ei gilydd. Rydym yn aml yn anghofio am y dimensiwn dynol, er ein bod yn siarad llawer am bob math o ddiwylliannau.
Nawr mae gennym lawer o ddata, pum mlynedd o ymchwil academaidd, profi damcaniaethau ar raddfa ddiwydiannol. Yr hyn y mae'r astudiaethau hyn yn ei ddweud wrthym yw, os ydych chi'n cyfuno rhai patrymau ymddygiad mewn diwylliant sefydliadol, gallwch chi gyflawni cyflymiad o 2000x. Mae'r cyflymiad hwn yn cael ei gyfateb gan welliant cyfartal mewn sefydlogrwydd. Mae hwn yn fesuriad meintiol o'r budd y gall DevOps ei gynnig i unrhyw gwmni. Ychydig flynyddoedd yn ôl, roeddwn i'n siarad am DevOps i Brif Swyddog Gweithredol cwmni Fortune 5000. Pan oeddwn i'n paratoi ar gyfer y cyflwyniad, roeddwn i'n nerfus iawn oherwydd roedd yn rhaid i mi grynhoi fy mlynyddoedd o brofiad mewn 5 munud.
Yn y diwedd rhoddais y canlynol Diffiniad o DevOps: Mae'n set o arferion a phatrymau sy'n galluogi trawsnewid cyfalaf dynol yn gyfalaf sefydliadol perfformiad uchel. Un enghraifft yw'r ffordd y mae Toyota wedi gweithredu am y 50 neu 60 mlynedd diwethaf.
(O hyn ymlaen, darperir diagramau o'r fath nid fel deunydd cyfeirio, ond fel darluniau. Bydd eu cynnwys yn wahanol ar gyfer pob cwmni newydd. Fodd bynnag, gellir gweld y llun ar wahân a'i ehangu
Un o'r arferion mwyaf llwyddiannus o'r fath yw mapio ffrwd gwerth. Mae nifer o lyfrau da wedi'u hysgrifennu am hyn, a'r rhai mwyaf llwyddiannus gan Karen Martin. Ond dros y flwyddyn ddiwethaf, rwyf wedi dod i'r casgliad bod hyd yn oed y dull hwn yn rhy uwch-dechnoleg. Yn sicr mae ganddo lawer o fanteision ac rwyf wedi ei ddefnyddio llawer. Ond pan fydd y Prif Swyddog Gweithredol yn gofyn ichi pam na all ei gwmni newid i gledrau newydd, mae'n rhy gynnar i siarad am fapio ffrydiau gwerth. Mae yna lawer o gwestiynau llawer mwy sylfaenol y mae'n rhaid eu hateb yn gyntaf.
Rwy'n meddwl mai'r camgymeriad y mae llawer o'm cydweithwyr yn ei wneud yw eu bod yn rhoi canllaw pum pwynt i'r cwmni ac yna'n dod yn ôl chwe mis yn ddiweddarach i weld beth ddigwyddodd. Mae gan hyd yn oed cynllun da fel mapio ffrydiau gwerth, fannau dall, gadewch i ni ddweud. Ar ôl cannoedd o gyfweliadau gyda chyfarwyddwyr cwmnïau amrywiol, rwyf wedi datblygu patrwm penodol sy'n ein galluogi i dorri i lawr y broblem yn ei gydrannau, a nawr byddwn yn trafod pob un o'r cydrannau hyn yn eu trefn. Cyn cymhwyso unrhyw atebion technolegol, rwy'n defnyddio'r patrwm hwn, ac o ganlyniad, mae fy holl waliau wedi'u gorchuddio â diagramau. Yn ddiweddar roeddwn yn gweithio gyda chronfa gydfuddiannol ac yn y diwedd, cefais 100-150 o gynlluniau o'r fath.
Mae diwylliant gwael yn bwyta dulliau da ar gyfer brecwast
Y prif syniad yw hyn: ni fydd unrhyw swm o Lean, Agile, SAFE a DevOps yn helpu os yw diwylliant y sefydliad ei hun yn ddrwg. Mae fel deifio i ddyfnderoedd heb offer sgwba neu weithredu heb belydr-x. Mewn geiriau eraill, i aralleirio Drucker a Deming: bydd diwylliant sefydliadol gwael yn llyncu unrhyw system dda heb dagu arni.
I ddatrys y brif broblem hon, mae angen i chi gymryd y camau canlynol:
- Gwneud Pob Gwaith yn Weladwy: mae angen i chi wneud yr holl waith yn weladwy. Nid yn yr ystyr bod yn rhaid iddo gael ei arddangos ar ryw sgrin o reidrwydd, ond yn yr ystyr bod yn rhaid iddo fod yn weladwy.
- Systemau Rheoli Gwaith Cyfunol: mae angen cydgrynhoi systemau rheoli. Yn y broblem o wybodaeth “lwythol” a gwybodaeth sefydliadol, mewn 9 achos allan o 10 y dagfa yw pobl. Yn y llyfr roedd y broblem gydag un person sengl, Brent, a achosodd i'r prosiect fod tair blynedd ar ei hôl hi. Ac rwy'n rhedeg i mewn i'r “Brents” hyn ym mhobman. I ddatrys y tagfeydd hyn, defnyddiaf y ddwy eitem nesaf ar ein rhestr.
- Methodoleg Theori Cyfyngiadau: theori cyfyngiadau.
- Haciau cydweithio: haciau cydweithio.
- Toyota Kata (): Ni fyddaf yn siarad llawer am y Toyota Kata. Os oes diddordeb, ar fy github ar bron bob un o'r pynciau hyn.
- Sefydliad sy'n canolbwyntio ar y farchnad: sefydliad sy'n canolbwyntio ar y farchnad.
- Archwilwyr sifft-chwith: archwiliad ar gamau cynnar y cylch.
Rwy'n dechrau gweithio gyda sefydliad yn syml iawn: rwy'n mynd i'r cwmni ac yn siarad â'r gweithwyr. Fel y gwelwch, dim technoleg uchel. Y cyfan sydd ei angen yw rhywbeth i ysgrifennu arno. Rwy'n casglu sawl tîm mewn un ystafell ac yn dadansoddi'r hyn y maent yn ei ddweud wrthyf o safbwynt fy 7 archdeip. Ac yna dwi'n rhoi marciwr iddyn nhw eu hunain ac yn gofyn iddyn nhw ysgrifennu popeth maen nhw wedi'i ddweud yn uchel hyd yn hyn ar y bwrdd. Fel arfer yn y mathau hyn o gyfarfodydd mae un person sy'n ysgrifennu popeth i lawr, ac ar y gorau gall ysgrifennu 10% o'r drafodaeth. Gyda'm dull, gellir codi'r ffigur hwn i tua 40%.
(Gellir gweld y llun hwn ar wahân )
Mae fy ymagwedd yn seiliedig ar waith William Schneider. ). Mae'r ymagwedd yn seiliedig ar y syniad y gellir rhannu unrhyw sefydliad yn bedwar sgwâr. Mae’r cynllun hwn i mi fel arfer yn ganlyniad gweithio gyda’r cannoedd hynny o gynlluniau eraill sy’n codi wrth ddadansoddi sefydliad. Tybiwch fod gennym sefydliad sydd â lefel uchel o reolaeth, ond â chymhwysedd isel. Mae hwn yn opsiwn hynod annymunol: pan fydd pawb ar flaen y gad, ond does neb yn gwybod beth i'w wneud.
Opsiwn ychydig yn well yw un sydd â lefel uchel o reolaeth a chymhwysedd. Os yw cwmni o'r fath yn broffidiol, yna efallai nad oes angen DevOps arno. Mae'n fwyaf diddorol gweithio gyda chwmni sydd â lefel uchel o reolaeth, cymhwysedd isel a chydweithrediad, ond ar yr un pryd lefel uchel o ddiwylliant (amaethu). Mae hyn yn golygu bod gan y cwmni lawer o bobl sy'n hoffi gweithio yno ac mae'r trosiant llafur yn isel.
(Gellir gweld y llun hwn ar wahân )
Mae'n ymddangos i mi bod dulliau gyda chanllawiau anhyblyg yn y pen draw yn rhwystro cyflawni'r gwirionedd. Mewn mapio ffrydiau gwerth yn arbennig, mae llawer o reolau ynghylch sut y dylid strwythuro gwybodaeth. Yn ystod camau cynnar y gwaith, yr wyf yn sôn amdano nawr, nid oes angen y rheolau hyn ar neb. Os yw person sydd â marciwr yn ei ddwylo yn disgrifio'r sefyllfa wirioneddol yn y cwmni ar y bwrdd, dyma'r ffordd orau o ddeall y sefyllfa. Nid yw gwybodaeth o'r fath yn cyrraedd cyfarwyddwyr. Ar hyn o bryd, mae'n wirion torri ar draws y person a dweud iddo dynnu rhyw fath o saeth yn anghywir. Ar y cam hwn, mae'n well defnyddio rheolau syml, er enghraifft: gellir creu tynnu aml-lefel yn syml trwy ddefnyddio marcwyr aml-liw.
Rwy'n ailadrodd, dim technoleg uchel. Mae'r marciwr du yn darlunio realiti gwrthrychol sut mae popeth yn gweithio. Gyda marciwr coch, mae pobl yn nodi'r hyn nad ydyn nhw'n ei hoffi am y sefyllfa gyfredol. Mae'n bwysig eu bod yn ysgrifennu hwn, nid fi. Pan af at y CIO ar ôl cyfarfod, nid wyf yn cynnig rhestr o 10 peth y mae angen eu trwsio. Rwy'n ymdrechu i ddod o hyd i gysylltiadau rhwng yr hyn y mae pobl yn y cwmni yn ei ddweud a phatrymau profedig presennol. Yn olaf, mae marciwr glas yn awgrymu atebion posibl i'r broblem.
(Gellir gweld y llun hwn ar wahân )
Mae enghraifft o'r dull hwn bellach wedi'i ddangos uchod. Ar ddechrau'r flwyddyn hon roeddwn i'n gweithio gydag un banc. Roedd y bobl ddiogelwch yno yn argyhoeddedig na ddylent ddod i adolygiadau dylunio a gofynion.
(Gellir gweld y llun hwn ar wahân )
Ac yna buom yn siarad â phobl o adrannau eraill ac mae'n troi allan tua 8 mlynedd yn ôl, datblygwyr meddalwedd tanio gweithwyr diogelwch oherwydd eu bod yn arafu gwaith. Ac yna trodd yn waharddiad, a gymerwyd yn ganiataol. Er mewn gwirionedd nid oedd gwaharddiad.
Aeth ein cyfarfod yn ei flaen mewn modd hynod ddryslyd: am tua thair awr, ni allai pum tîm gwahanol egluro i mi beth oedd yn digwydd rhwng y cod a’r cynulliad. Ac mae'n ymddangos mai dyma'r peth symlaf. Mae'r rhan fwyaf o ymgynghorwyr DevOps yn rhagdybio ymlaen llaw bod pawb eisoes yn gwybod hyn.
Yna daeth y person â gofal llywodraethu TG, a oedd wedi bod yn dawel am bedair awr, yn fyw yn sydyn ar ôl cyrraedd ei bwnc, a bu'n ein meddiannu am amser hir iawn. O'r diwedd gofynais iddo beth oedd ei farn am y cyfarfod, ac nid anghofiaf byth ei ateb. Dywedodd: “Roeddwn i’n arfer meddwl mai dim ond dwy ffordd oedd gan ein banc o gyflwyno meddalwedd, ond nawr rwy’n gwybod bod pump ohonyn nhw, a doeddwn i ddim hyd yn oed yn gwybod am dri.”
(Gellir gweld y llun hwn ar wahân )
Roedd y cyfarfod diwethaf yn y banc hwn gyda'r tîm meddalwedd buddsoddi. Gyda hi y daeth i'r amlwg bod ysgrifennu diagramau gyda marciwr ar ddalen o bapur yn well nag ar fwrdd, a hyd yn oed yn well nag ar fwrdd clyfar.
Y lluniau a welwch yw sut olwg oedd ar ystafell gynadledda'r gwesty ar bedwerydd diwrnod ein cyfarfod. Ac fe wnaethom ddefnyddio'r cynlluniau hyn i chwilio am batrymau, hynny yw, archdeipiau.
Felly, dwi'n gofyn cwestiynau i'r gweithwyr, maen nhw'n ysgrifennu'r atebion gyda marcwyr o dri lliw (du, coch a glas). Rwy'n dadansoddi eu hatebion ar gyfer archeteipiau. Nawr, gadewch i ni drafod yr holl archeteipiau mewn trefn.
1. Gwneud Pob Gwaith yn Weladwy: Gwneud gwaith yn weladwy
Mae gan y rhan fwyaf o gwmnïau rydw i'n gweithio gyda nhw ganran uchel iawn o waith anhysbys. Er enghraifft, dyma pan fydd un gweithiwr yn dod at un arall ac yn gofyn yn syml am gael gwneud rhywbeth. Mewn sefydliadau mawr, efallai y bydd 60% o waith heb ei gynllunio. Ac nid yw hyd at 40% o'r gwaith wedi'i ddogfennu mewn unrhyw ffordd. Pe bai'n Boeing, ni fyddwn byth yn mynd ar ei awyren eto yn fy mywyd. Os mai dim ond hanner y gwaith sydd wedi'i ddogfennu, yna ni wyddys a yw'r gwaith hwn yn cael ei wneud yn gywir ai peidio. Mae pob dull arall yn troi allan yn ddiwerth - nid oes unrhyw bwynt ceisio awtomeiddio unrhyw beth, oherwydd efallai mai'r 50% hysbys yw'r rhan fwyaf cydlynol a chlir o'r gwaith, na fydd ei awtomeiddio yn rhoi canlyniadau gwych, a'r gwaethaf oll. pethau yn yr hanner anweledig. Yn absenoldeb dogfennaeth, mae'n amhosibl dod o hyd i bob math o haciau a gwaith cudd, peidio â dod o hyd i dagfeydd, yr union “Brents” hynny y soniais amdanynt eisoes. Mae yna lyfr hyfryd gan Dominica DeGrandis . Mae hi'n datgelu pum "gollyngiad amser" gwahanol (lladron amser):
- Gormod o Waith yn y Broses (WIP)
- Dibyniaethau Anhysbys
- Gwaith Heb ei Gynllunio
- Blaenoriaethau sy'n gwrthdaro
- Gwaith Esgeuluso
Mae hwn yn ddadansoddiad gwerthfawr iawn ac mae'r llyfr yn wych, ond mae'r holl gyngor hwn yn ddiwerth os mai dim ond 50% o'r data sy'n weladwy. Gellir defnyddio'r dulliau a gynigir gan Dominica os cyflawnir cywirdeb o fwy na 90%. Rwy'n sôn am sefyllfaoedd lle mae bos yn rhoi tasg 15 munud i isradd, ond mae'n cymryd tri diwrnod iddo; ond nid yw y bos yn gwybod yn iawn fod yr isradd hon yn ymddibynu ar bedwar neu bump o bobl eraill.
Mae Prosiect Phoenix yn stori hyfryd am brosiect a oedd dair blynedd yn rhy hwyr. Mae un o’r cymeriadau yn wynebu cael ei ddiswyddo oherwydd hyn, ac mae’n cyfarfod â chymeriad arall sy’n cael ei gyflwyno fel rhyw fath o Socrates. Mae'n helpu i ddarganfod beth yn union aeth o'i le. Mae'n ymddangos bod gan y cwmni un gweinyddwr system, a'i enw yw Brent, ac mae'r holl waith yn mynd trwyddo rywsut. Yn un o'r cyfarfodydd, gofynnir i un o'r is-weithwyr: pam mae pob tasg hanner awr yn cymryd wythnos? Yr ateb yw cyflwyniad syml iawn o theori ciwio a chyfraith Little, ac yn y cyflwyniad hwn mae'n ymddangos bod pob awr o waith yn cymryd 90 awr ar ddeiliadaeth o 9%. Mae angen anfon pob tasg at saith o bobl eraill, fel bod yr awr honno'n dod yn 63 awr, 7 gwaith 9. Yr hyn rwy'n ei ddweud yw, er mwyn defnyddio Little's Law neu unrhyw ddamcaniaeth ciwio gymhleth, mae angen i chi gael data o leiaf.
Felly pan fyddaf yn siarad am welededd, nid wyf yn golygu bod popeth ar y sgrin, ond bod gennych chi ddata o leiaf. Pan fyddant yn gwneud, mae'n troi allan yn aml bod yna lawer iawn o waith heb ei gynllunio sy'n cael ei anfon rywsut i Brent pan nad oes ei angen. Ac mae Brent yn foi gwych, ni fydd byth yn dweud na, ond nid yw'n dweud wrth neb sut mae'n gwneud ei waith.
Pan fydd y gwaith yn weladwy, gellir dosbarthu'r data yn daclus (dyna beth mae Dominika yn ei wneud yn y llun), gellir defnyddio tynnu'r gollyngiadau pum amser, a gellir cymhwyso awtomeiddio.
2. Cyfuno Systemau Rheoli Gwaith: Rheoli Tasgau
Mae'r archeteipiau dwi'n siarad amdanyn nhw yn fath o byramid. Os gwneir yr un cyntaf yn gywir, yna mae'r ail eisoes yn fath o ychwanegiad. Nid yw llawer o'r rhain yn gweithio i fusnesau newydd, mae angen eu cadw mewn cof ar gyfer cwmnïau mwy fel y Fortune 5000. Roedd gan y cwmni diwethaf i mi weithio iddo 10 system docynnau. Roedd gan un tîm Remedy, ysgrifennodd un arall ryw fath o'i system ei hun, roedd traean yn defnyddio Jira, ac roedd rhai yn ymwneud ag e-bost. Mae'r un broblem yn codi os oes gan y cwmni 30 o wahanol bibellau, ond nid oes gennyf amser i drafod pob achos o'r fath.
Rwy’n trafod gyda phobl yn union sut mae tocynnau’n cael eu creu, beth sy’n digwydd iddyn nhw nesaf, a sut maen nhw’n cael eu hosgoi. Y peth mwyaf diddorol yw bod pobl yn ein cyfarfodydd yn siarad yn eithaf didwyll. Gofynnais faint o bobl sy'n rhoi "mân / dim effaith" ar docynnau a ddylai mewn gwirionedd gael "effaith fawr". Mae'n troi allan bod bron pawb yn gwneud hyn. Nid wyf yn ymwadu ac yn ceisio ym mhob ffordd bosibl i beidio ag adnabod pobl. Pan fyddant yn cyfaddef rhywbeth i mi yn ddiffuant, nid wyf yn rhoi'r person i ffwrdd. Ond pan fydd bron pawb yn osgoi'r system, mae'n golygu mai gwisgo ffenestr yw'r holl ddiogelwch yn ei hanfod. Felly, ni ellir dod i unrhyw gasgliadau o ddata'r system hon.
I ddatrys y broblem tocyn, mae angen i chi ddewis un brif system. Os ydych chi'n defnyddio Jira, cadwch ef Jira. Os oes unrhyw ddewis arall, gadewch iddo fod yr unig un. Y gwir amdani yw y dylid ystyried tocynnau fel cam arall yn y broses ddatblygu. Rhaid i bob gweithred gael tocyn, a rhaid iddo lifo drwy'r llif gwaith datblygu. Anfonir tocynnau at y tîm, sy'n eu postio ar y bwrdd stori ac yna'n cymryd cyfrifoldeb amdanynt.
Mae hyn yn berthnasol i bob adran, gan gynnwys seilwaith a gweithrediadau. Yn yr achos hwn, mae'n bosibl ffurfio o leiaf rhyw syniad credadwy o'r sefyllfa. Unwaith y bydd y broses hon wedi'i sefydlu, daw'n hawdd yn sydyn i nodi pwy sy'n gyfrifol am bob cais. Oherwydd nawr nid ydym yn derbyn 50%, ond 98% o wasanaethau newydd. Os yw'r broses graidd hon yn gweithio, yna mae cywirdeb yn gwella drwy'r system gyfan.
Piblinell gwasanaethau
Unwaith eto, dim ond i gorfforaethau mawr y mae hyn yn berthnasol. Os ydych chi'n gwmni newydd mewn maes newydd, torchwch eich llewys a gweithiwch gyda'ch Travis CI neu CircleCI. O ran cwmnïau Fortune 5000, achos dan sylw a ddigwyddodd yn y banc lle roeddwn i'n gweithio. Daeth Google atynt a dangoswyd diagramau o hen systemau IBM iddynt. Gofynnodd y dynion o Google mewn dryswch - ble mae'r cod ffynhonnell ar gyfer hyn? Ond nid oes cod ffynhonnell, dim hyd yn oed GUI. Dyma’r realiti y mae’n rhaid i sefydliadau mawr ymdrin ag ef: cofnodion banc 40 oed ar brif ffrâm hynafol. Mae un o'm cleientiaid yn defnyddio cynwysyddion Kubernetes gyda phatrymau Circuit Breaker, ynghyd â Chaos Monkey, i gyd ar gyfer y cymhwysiad KeyBank. Ond mae'r cynwysyddion hyn yn y pen draw yn cysylltu â chymhwysiad COBOL.
Roedd y dynion o Google yn gwbl hyderus y byddent yn datrys holl broblemau fy nghleient, ac yna dechreuon nhw ofyn cwestiynau: beth yw pibell ddata IBM? Dywedir wrthynt: cysylltydd yw hwn. Beth mae'n cysylltu ag ef? I'r system Sperry. A beth yw hynny? Ac yn y blaen. Ar yr olwg gyntaf mae'n ymddangos: pa fath o DevOps all fod? Ond mewn gwirionedd, mae'n bosibl. Mae systemau dosbarthu sy'n eich galluogi i drosglwyddo'r llif gwaith i'r timau cyflawni.
3. Theori Cyfyngiadau: Theory of Constraints
Gadewch i ni symud ymlaen at y trydydd archdeip: gwybodaeth sefydliadol / "llwythol". Fel rheol, mewn unrhyw sefydliad mae yna nifer o bobl sy'n gwybod popeth ac yn rheoli popeth. Dyma'r rhai sydd wedi bod yn y sefydliad hiraf ac sy'n gwybod yr holl atebion.
Pan ddaw hyn i fyny ar y diagram, rwy'n rhoi marciwr o amgylch pobl o'r fath yn benodol: er enghraifft, mae'n ymddangos bod Lou penodol yn bresennol ym mhob cyfarfod. Ac mae'n amlwg i mi: Brent lleol yw hwn. Pan fydd y CIO yn dewis rhyngof mewn crys-T a sneakers a'r boi o IBM mewn siwt, rwy'n cael fy newis oherwydd gallaf ddweud wrth y cyfarwyddwr bethau na fydd y boi arall yn eu dweud ac efallai na fydd y cyfarwyddwr yn hoffi eu clywed. . Dywedaf wrthynt mai'r dagfa yn eu cwmni yw rhywun o'r enw Fred a rhywun o'r enw Lou. Mae angen datglymu'r dagfa hon, mae angen cael eu gwybodaeth ganddynt un ffordd neu'r llall.
I ddatrys y math hwn o broblem, gallaf, er enghraifft, awgrymu defnyddio Slack. Bydd cyfarwyddwr call yn gofyn - pam? Yn nodweddiadol, mewn achosion o'r fath, mae ymgynghorwyr DevOps yn ateb: oherwydd bod pawb yn ei wneud. Os yw'r cyfarwyddwr yn smart iawn, bydd yn dweud: felly beth. A dyma lle mae'r ddeialog yn dod i ben. A fy ateb i hyn yw: oherwydd bod pedair tagfa yn y cwmni, Fred, Lou, Susie a Jane. Er mwyn sefydliadoli eu gwybodaeth, rhaid cyflwyno Slack yn gyntaf. Mae dy wikis i gyd yn nonsens llwyr achos does neb yn gwybod am eu bodolaeth. Os yw'r tîm peirianneg yn ymwneud â datblygiad pen blaen a phen ôl a bod angen i bawb wybod y gallant gysylltu â'r tîm datblygu pen blaen neu'r tîm seilwaith gyda chwestiynau. Dyna pryd mae'n debyg y bydd gan Lou neu Fred amser i ymuno â'r wici. Ac yna yn Slack efallai y bydd rhywun yn gofyn pam, dyweder, nad yw cam 5 yn gweithio. Ac yna bydd Lou neu Fred yn cywiro'r cyfarwyddiadau ar y wici. Os byddwch chi'n sefydlu'r broses hon, yna bydd llawer o bethau'n disgyn i'w lle ar eu pen eu hunain.
Dyma fy mhrif bwynt: er mwyn argymell unrhyw dechnolegau uchel, yn gyntaf mae'n rhaid i chi roi'r sylfaen ar eu cyfer mewn trefn, a gellir gwneud hyn gyda'r atebion technoleg isel sydd newydd eu disgrifio. Os byddwch chi'n dechrau gyda thechnolegau uchel ac nad ydych chi'n esbonio pam mae eu hangen, yna, fel rheol, nid yw hyn yn dod i ben yn dda. Mae un o'n cleientiaid yn defnyddio Azure ML, ateb rhad a syml iawn. Atebwyd tua 30% o'u cwestiynau gan y peiriant hunan-ddysgu ei hun. Ac ysgrifennwyd y peth hwn gan weithredwyr nad oeddent yn ymwneud â gwyddor data, ystadegau na mathemateg. Mae hyn yn arwyddocaol. Mae cost datrysiad o'r fath yn fach iawn.
4. Cydweithio haciau: Cydweithio haciau
Y pedwerydd archdeip yw'r angen i frwydro yn erbyn unigedd. Mae'r rhan fwyaf o bobl eisoes yn gwybod hyn: mae unigedd yn magu gelyniaeth. Os yw pob adran ar ei llawr ei hun, ac nad yw pobl yn croestorri â'i gilydd mewn unrhyw ffordd, ac eithrio yn yr elevator, yna mae gelyniaeth rhyngddynt yn codi'n hawdd iawn. Ond, i'r gwrthwyneb, os yw pobl yn yr un ystafell â'i gilydd, mae hi'n gadael ar unwaith. Pan fydd rhywun yn taflu rhywfaint o gyhuddiad cyffredinol, er enghraifft, nid yw rhyngwyneb o'r fath ac o'r fath byth yn gweithio, nid oes dim byd haws i ddadadeiladu cyhuddiad o'r fath. Mae angen i'r rhaglenwyr a ysgrifennodd y rhyngwyneb ddechrau gofyn cwestiynau penodol, a bydd yn dod yn amlwg yn fuan, er enghraifft, bod y defnyddiwr yn defnyddio'r offeryn yn anghywir yn unig.
Mae yna lawer o ffyrdd i oresgyn unigedd. Gofynnwyd i mi unwaith ymgynghori ar gyfer banc yn Awstralia, ond gwrthodais wneud hynny oherwydd bod gennyf ddau o blant a gwraig. Y cyfan y gallwn ei wneud i'w helpu oedd argymell adrodd straeon graffigol. Mae hyn yn rhywbeth y profwyd ei fod yn gweithio. Ffordd ddiddorol arall yw cyfarfodydd coffi heb lawer o fraster. Mewn sefydliad mawr, mae hwn yn opsiwn ardderchog ar gyfer lledaenu gwybodaeth. Yn ogystal, gallwch gynnal devopsdays mewnol, hacathons, ac ati.
5. Hyfforddi Kata
Fel y rhybuddiais ar y dechrau, ni fyddaf yn siarad am hyn heddiw. Os oes gennych ddiddordeb, gallwch gymryd golwg .
Mae sgwrs dda ar y pwnc hwn hefyd gan Mike Rother:
6. Canolbwyntio ar y Farchnad: sefydliad sy'n canolbwyntio ar y farchnad
Mae yna wahanol broblemau yma. Er enghraifft, "I" pobl, "T" pobl a "E" pobl. Pobl “fi” yw'r rhai sy'n gwneud un peth yn unig. Yn nodweddiadol maent yn bodoli mewn sefydliadau ag adrannau ynysig. "T" yw pan fydd person yn dda ar un peth ond hefyd yn dda ar rai pethau eraill. "E" neu hyd yn oed "crib" yw pan fydd gan berson lawer o sgiliau.
Mae cyfraith Conwy yn gweithio yma (), y gellir ei nodi yn y ffurf fwyaf symlach fel a ganlyn: os bydd tri thîm yn gweithio ar y casglwr, yna casglwr tair rhan fydd y canlyniad. Felly, os oes lefel uchel o ynysu o fewn sefydliad, yna bydd hyd yn oed Kubernetes, Circuit breaker, estynadwyedd API a phethau ffansi eraill yn y sefydliad hwn yn cael eu trefnu yn yr un modd â'r sefydliad ei hun. Yn llym yn ôl Conwy ac er gwaethaf eich holl geeks ifanc.
Disgrifiwyd yr ateb i'r broblem hon lawer gwaith. Mae yna, er enghraifft, archeteipiau sefydliadol a ddisgrifiwyd gan Fernando Fernandez. Mae'r bensaernïaeth broblemus honno y soniais amdani, gydag unigedd, yn bensaernïaeth sy'n canolbwyntio ar swyddogaethau. Yr ail fath yw pensaernïaeth matrics gwaethaf, llanast o'r ddau arall. Y trydydd yw'r hyn a welir yn y mwyafrif o fusnesau cychwynnol, ac mae cwmnïau mawr hefyd yn ceisio cyfateb y math hwn. Mae'n sefydliad sy'n canolbwyntio ar y farchnad. Yma rydym yn gwneud y gorau i gyflawni'r ymateb cyflymaf i geisiadau cwsmeriaid. Weithiau gelwir hyn yn sefydliad fflat.
Mae llawer o bobl yn disgrifio'r strwythur hwn mewn gwahanol ffyrdd, rwy'n hoffi'r geiriad adeiladu/rhedeg timau, yn Amazon maen nhw'n ei alw dau dîm pizza. Yn y strwythur hwn, mae pob person math “I” yn cael eu grwpio o amgylch un gwasanaeth, ac yn raddol maen nhw'n dod yn agosach at deipio “T”, ac os yw'r rheolaeth gywir yn ei lle, gallant hyd yn oed ddod yn “E”. Y gwrthddadl gyntaf yma yw bod gan strwythur o'r fath elfennau diangen. Pam mae angen profwr arnoch ym mhob adran os gallwch chi gael adran arbennig o brofwyr? Rwy'n ateb i hyn: y costau ychwanegol yn yr achos hwn yw'r pris i'r sefydliad cyfan ddod yn fath “E” yn y dyfodol. Yn y strwythur hwn, mae'r profwr yn dysgu'n raddol am rwydweithiau, pensaernïaeth, dylunio, ac ati. O ganlyniad, mae pob cyfranogwr yn y sefydliad yn gwbl ymwybodol o bopeth sy'n digwydd yn y sefydliad. Os ydych chi eisiau gwybod sut mae'r cynllun hwn yn gweithio mewn diwydiant, darllenwch .
7. Archwilwyr sifft-chwith: archwiliad yn gynnar yn y cylch. Cydymffurfio â rheolau diogelwch sy'n cael eu harddangos
Dyma pan na fydd eich gweithredoedd yn pasio'r prawf arogli, fel petai. Nid yw'r bobl sy'n gweithio i chi yn dwp. Os ydynt, fel yn yr enghraifft uchod, yn gosod mân effaith/dim effaith ym mhobman, bod hyn wedi para tair blynedd, ac nad oedd neb wedi sylwi ar unrhyw beth, yna mae pawb yn gwybod yn iawn nad yw'r system yn gweithio. Neu enghraifft arall - bwrdd cynghori newid, lle mae angen cyflwyno adroddiadau bob dydd Mercher, dyweder. Mae yna grŵp o bobl yn gweithio yno (ddim yn talu'n dda iawn, gyda llaw) a ddylai, mewn egwyddor, wybod sut mae'r system yn ei chyfanrwydd yn gweithio. A thros y pum mlynedd diwethaf, mae'n debyg eich bod wedi sylwi bod ein systemau yn hynod gymhleth. Ac mae'n rhaid i bump neu chwech o bobl wneud penderfyniad am newid na wnaethant ac nad ydynt yn gwybod dim amdano.
Wrth gwrs, nid yw'r dull hwn yn gweithio. Mae'n rhaid i mi gael gwared ar bethau o'r fath oherwydd nid yw'r bobl hyn yn amddiffyn y system. Rhaid i'r penderfyniad gael ei wneud gan y tîm ei hun, oherwydd rhaid i'r tîm fod yn gyfrifol amdano. Fel arall, mae sefyllfa baradocsaidd yn codi pan fydd rheolwr nad yw erioed wedi ysgrifennu cod yn ei fywyd yn dweud wrth y rhaglennydd pa mor hir y dylai ei gymryd i ysgrifennu cod. Roedd gan un cwmni y bûm yn gweithio ag ef 7 bwrdd gwahanol a oedd yn adolygu pob newid, gan gynnwys bwrdd pensaernïaeth, bwrdd cynnyrch, ac ati. Roedd hyd yn oed cyfnod aros gorfodol, er i un gweithiwr ddweud wrthyf nad oedd neb, mewn deng mlynedd o waith, erioed wedi gwrthod newid a wnaed gan y person hwn yn ystod y cyfnod gorfodol hwn.
Mae angen gwahodd archwilwyr i ymuno â ni, a pheidio â chael gwared arnynt. Dywedwch wrthynt eich bod yn ysgrifennu cynwysyddion deuaidd na ellir eu cyfnewid sydd, os byddant yn pasio'r holl brofion, yn parhau i fod yn ddigyfnewid am byth. Dywedwch wrthyn nhw fod gennych chi biblinell fel cod ac esboniwch beth mae hynny'n ei olygu. Dangoswch y cynllun canlynol iddynt: deuaidd darllen yn unig na ellir ei gyfnewid mewn cynhwysydd sy'n pasio pob prawf bregusrwydd; ac yna nid yn unig nad oes neb yn ei gyffwrdd, nid ydynt hyd yn oed yn cyffwrdd â'r system sy'n creu'r biblinell, gan ei fod hefyd yn cael ei greu yn ddeinamig. Mae gen i gleientiaid, Capital One, sy'n defnyddio Vault i greu rhywbeth fel blockchain. Nid oes angen i'r archwilydd ddangos “ryseitiau” gan y Cogydd; mae'n ddigon i ddangos y blockchain, ac o hynny mae'n amlwg beth ddigwyddodd i docyn Jira wrth gynhyrchu a phwy sy'n gyfrifol amdano.
Yn ôl , a grëwyd yn 2018 gan Sonatype, roedd 2017 biliwn o geisiadau lawrlwytho OSS yn 87.
Mae'r colledion oherwydd gwendidau yn ormodol. At hynny, nid yw’r ffigurau a welwch yn awr uchod yn cynnwys costau cyfle. Beth yw DevSecOps yn gryno? Gadewch imi ddweud ar unwaith nad oes gennyf ddiddordeb mewn siarad am ba mor llwyddiannus yw'r enw hwn. Y pwynt yw, ers i DevOps fod mor llwyddiannus, y dylem geisio ychwanegu diogelwch at y biblinell honno.
Enghraifft o'r dilyniant hwn:
Nid yw hwn yn argymhelliad ar gyfer cynhyrchion penodol, er fy mod yn eu hoffi i gyd. Cyfeiriais atynt fel enghraifft i ddangos bod DevOps, a oedd yn seiliedig i ddechrau ar y patrwm sefydliadol mewn diwydiant, yn caniatáu ichi awtomeiddio pob cam o'r gwaith ar gynnyrch.
Ac nid oes unrhyw reswm pam na allem gymryd yr un agwedd at ddiogelwch.
Cyfanswm
I gloi, byddaf yn rhoi rhai awgrymiadau ar gyfer DevSecOps. Mae angen i chi gynnwys archwilwyr yn y broses o greu eich systemau a threulio amser yn eu haddysgu. Mae angen i chi gydweithredu ag archwilwyr. Nesaf, mae angen i chi ymladd brwydr gwbl ddidostur yn erbyn pethau cadarnhaol ffug. Hyd yn oed gyda'r offeryn sganio bregusrwydd drutaf, gallwch chi greu arferion hynod wael ymhlith eich datblygwyr os nad ydych chi'n gwybod beth yw eich cymhareb signal-i-sŵn. Bydd datblygwyr yn cael eu llethu gan ddigwyddiadau a byddant yn eu dileu yn syml. Os clywsoch chi am stori Equifax, dyna beth ddigwyddodd yno fwy neu lai, lle anwybyddwyd y lefel rhybudd uchaf. Yn ogystal, mae angen esbonio gwendidau mewn ffordd sy'n ei gwneud yn glir sut maent yn effeithio ar y busnes. Er enghraifft, fe allech chi ddweud bod hyn yr un mor agored i niwed ag yn stori Equifax. Dylid trin gwendidau diogelwch yn yr un modd â materion meddalwedd eraill, hynny yw, dylid eu cynnwys yn y broses DevOps gyffredinol. Mae angen i chi weithio gyda nhw trwy Jira, Kanban, ac ati. Ni ddylai datblygwyr feddwl y bydd rhywun arall yn gwneud hyn - i'r gwrthwyneb, dylai pawb wneud hyn. Yn olaf, mae angen i chi wario egni ar hyfforddi pobl.
Dolenni defnyddiol
Dyma ychydig o sgyrsiau o gynhadledd DevOops a allai fod yn ddefnyddiol i chi:
- Sergey Berdnikov, Artyom Kalichkin - Stori lwyddiant, neu “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps ar raddfa: trasiedi Roegaidd mewn tair act (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Cymerwch gip ar DevOops 2020 Moscow - mae yna lawer o bethau diddorol yno hefyd.
Ffynhonnell: hab.com