Dydd Gwener hapus pawb! Gyfeillion, heddiw rydym yn parhau â'r gyfres o gyhoeddiadau sy'n ymroddedig i'r cwrs , oherwydd bydd dosbarthiadau yn y grŵp newydd ar gyfer y cwrs yn dechrau ddiwedd yr wythnos nesaf. Felly, gadewch i ni ddechrau!
Mae monitro yn yn unig. Mae hon yn ffaith hysbys. Dewch â Nagios i fyny, rhedeg NRPE ar y system bell, ffurfweddu Nagios ar borthladd NRPE TCP 5666 ac mae gennych fonitro.
Mae mor hawdd nad yw'n ddiddorol. Nawr mae gennych fetrigau sylfaenol ar gyfer amser CPU, is-system disg, RAM, a gyflenwir yn ddiofyn i Nagios ac NRPE. Ond nid “monitro” fel y cyfryw yw hyn mewn gwirionedd. Dim ond y dechrau yw hyn.
(Fel arfer maen nhw'n gosod PNP4Nagios, RRDtool a Thruk, yn sefydlu hysbysiadau yn Slack ac yn mynd yn syth i nagiosexchange, ond gadewch i ni adael hynny allan am y tro).
Monitro da mewn gwirionedd yn eithaf cymhleth, mewn gwirionedd mae angen i chi wybod manylion mewnol y cais rydych chi'n ei fonitro.
Ydy monitro yn anodd?
Bydd unrhyw weinydd, boed yn Linux neu Windows, trwy ddiffiniad yn cyflawni rhyw ddiben. Apache, Samba, Tomcat, storio ffeiliau, LDAP - mae'r holl wasanaethau hyn fwy neu lai yn unigryw mewn un ffordd neu fwy. Mae gan bob un ei swyddogaeth ei hun, ei nodweddion ei hun. Mae yna wahanol ffyrdd o gael metrigau, DPA (dangosyddion perfformiad allweddol), sy'n ddiddorol i chi pan fydd y gweinydd dan lwyth.
Awdur y llun ar
(Hoffwn pe bai fy dangosfyrddau yn las neon - ochneidio'n freuddwydiol -... hmm...)
Rhaid i unrhyw feddalwedd sy'n darparu gwasanaethau gael mecanwaith i gasglu metrigau. Mae gan Apache fodiwl mod-status, yn dangos tudalen statws y gweinydd. Mae gan Nginx - stub_status. Mae gan Tomcat gymwysiadau gwe JMX neu arfer sy'n dangos metrigau allweddol. Mae gan MySQL orchymyn "dangos statws byd-eang" ac ati.
Felly pam nad yw datblygwyr yn cynnwys mecanweithiau tebyg yn y cymwysiadau y maent yn eu creu?
Ai dim ond datblygwyr sy'n gwneud hyn?
Nid yw lefel benodol o ddifaterwch i fewnosod metrigau wedi'i chyfyngu i ddatblygwyr. Gweithiais mewn cwmnïau lle buont yn datblygu cymwysiadau gan ddefnyddio Tomcat ac ni ddarparodd unrhyw un o'u metrigau eu hunain, dim logiau o weithgaredd gwasanaeth, ac eithrio logiau gwall Tomcat cyffredinol. Mae rhai datblygwyr yn cynhyrchu llawer o logiau sy'n golygu dim i weinyddwr y system sy'n ddigon anlwcus i'w darllen am 3:15 yn y bore.
Awdur y llun ar
Rhaid i beirianwyr systemau sy'n galluogi rhyddhau cynhyrchion o'r fath hefyd ysgwyddo rhywfaint o gyfrifoldeb am y sefyllfa. Ychydig o beirianwyr systemau sydd â'r amser na'r gofal i geisio echdynnu metrigau ystyrlon o foncyffion, heb gyd-destun y metrigau hynny a'r gallu i'w dehongli yng ngoleuni gweithgaredd cymhwyso. Nid yw rhai yn deall sut y gallant elwa ohono, heblaw am ddangosyddion "mae rhywbeth yn anghywir ar hyn o bryd (neu y bydd yn fuan) yn anghywir".
Rhaid i newid yn y meddwl am yr angen am fetrigau ddigwydd nid yn unig ymhlith datblygwyr, ond hefyd ymhlith peirianwyr systemau.
I unrhyw beiriannydd systemau sydd angen nid yn unig ymateb i ddigwyddiadau tyngedfennol, ond hefyd sicrhau nad ydynt yn digwydd, mae diffyg metrigau fel arfer yn rhwystr i wneud hynny.
Fodd bynnag, fel arfer nid yw peirianwyr systemau yn tincian â chod i wneud arian i'w cwmni. Mae angen datblygwyr arweiniol arnynt sy'n deall pwysigrwydd cyfrifoldeb y peiriannydd systemau wrth nodi problemau, codi ymwybyddiaeth o faterion perfformiad, ac yn y blaen.
Mae hyn yn difetha peth
Mae meddylfryd devops yn disgrifio'r synergedd rhwng meddwl datblygiad (dev) a gweithrediadau (ops). Rhaid i unrhyw gwmni sy'n honni ei fod yn "gwneud devops":
- dweud pethau mae'n debyg nad ydyn nhw'n eu gwneud (gan gyfeirio at The Princess Bride meme - "Dydw i ddim yn meddwl ei fod yn golygu'r hyn rydych chi'n meddwl ei fod yn ei olygu!")
- Annog agwedd o welliant cynnyrch parhaus.
Ni allwch wella cynnyrch ac yn gwybod ei fod wedi'i wella os nad ydych yn gwybod sut mae'n gweithio ar hyn o bryd. Ni allwch wybod sut mae cynnyrch yn gweithio os nad ydych yn deall sut mae ei gydrannau'n gweithio, y gwasanaethau y mae'n dibynnu arnynt, ei brif bwyntiau poen a thagfeydd.
Os nad ydych yn gwylio am dagfeydd posibl, ni fyddwch yn gallu dilyn y dechneg Five Whys wrth ysgrifennu Postmortem. Ni fyddwch yn gallu rhoi popeth ar un sgrin i weld sut mae cynnyrch yn gweithio neu wybod sut mae'n edrych yn "normal a hapus."
Turn i'r chwith, CHWITH, DYWEDODD I LEEEE—
I mi, un o egwyddorion allweddol Devops yw “shift left”. Mae newid i'r chwith yn y cyd-destun hwn yn golygu symud y posibilrwydd (dim cyfrifoldeb, ond dim ond galluoedd) i wneud pethau y mae peirianwyr systemau fel arfer yn poeni amdanynt, megis creu metrigau perfformiad, defnyddio logiau'n fwy effeithlon, ac ati, i'r chwith yn y Cylch Bywyd Cyflenwi Meddalwedd.
Awdur y llun ar
Rhaid i ddatblygwyr meddalwedd allu defnyddio a gwybod yr offer monitro y mae'r cwmni'n eu defnyddio er mwyn cyflawni monitro yn ei holl ffurfiau, metrigau, logio, rhyngwynebau monitro ac, yn bwysicaf oll, gwylio sut mae eu cynnyrch yn gweithio wrth gynhyrchu. Ni allwch gael datblygwyr i fuddsoddi ymdrech ac amser mewn monitro nes y gallant weld y metrigau a dylanwadu ar sut maent yn edrych, sut mae perchennog y cynnyrch yn eu cyflwyno i'r GTG yn y sesiwn friffio nesaf, ac ati.
Yn fyr
- Arwain eich ceffyl i'r dŵr. Dangoswch i ddatblygwyr faint o drafferth y gallant ei osgoi drostynt eu hunain, helpwch nhw i nodi'r DPA a'r metrigau cywir ar gyfer eu cymwysiadau fel bod llai o weiddi gan berchennog y cynnyrch y mae'r GTG yn ei weiddi. Dewch â nhw i'r golau, yn ysgafn ac yn dawel. Os na fydd hynny'n gweithio, yna llwgrwobrwyo, bygwth, a chajole naill ai nhw neu berchennog y cynnyrch i weithredu cael y metrigau hyn o'r cymwysiadau cyn gynted â phosibl, ac yna lluniwch y diagramau. Bydd hyn yn anodd gan na fydd yn cael ei ystyried yn flaenoriaeth a bydd llawer o brosiectau cynhyrchu refeniw yn yr arfaeth ar y cynllun cynnyrch. Felly, bydd angen achos busnes arnoch i gyfiawnhau'r amser a'r gost a dreulir yn gweithredu monitro yn y cynnyrch.
- Helpwch beirianwyr systemau i gael noson dda o gwsg. Dangoswch iddyn nhw fod defnyddio rhestr wirio “gadewch i ni ryddhau” ar gyfer unrhyw gynnyrch sy'n cael ei ryddhau yn beth da. A bydd sicrhau bod pob cais mewn cynhyrchu wedi'i orchuddio â metrigau yn eich helpu i gysgu'n well yn y nos trwy ganiatáu i ddatblygwyr weld beth sy'n mynd o'i le a ble. Fodd bynnag, y ffordd gywir i gythruddo a rhwystro unrhyw ddatblygwr, perchennog cynnyrch, neu GTG yw dyfalbarhau a gwrthsefyll. Bydd yr ymddygiad hwn yn effeithio ar ddyddiad rhyddhau unrhyw gynnyrch os arhoswch tan y funud olaf eto, felly symudwch i'r chwith eto a chynnwys y materion hyn yn eich cynllun prosiect cyn gynted â phosibl. Os oes angen, gwnewch eich ffordd i gyfarfodydd cynnyrch. Gwisgwch fwstas ffug a ffelt neu rywbeth, ni fydd byth yn methu. Cyfleu eich pryderon, dangos manteision clir, ac efengylu.
- Sicrhewch fod datblygiad (dev) a gweithrediadau (gweithredoedd) yn deall ystyr a chanlyniadau metrigau cynnyrch sy'n symud i'r parth coch. Peidiwch â gadael Ops fel unig warcheidwad iechyd cynnyrch, gwnewch yn siŵr bod datblygwyr yn cymryd rhan hefyd (#productsquads).
- Mae logiau yn beth gwych, ond felly hefyd fetrigau. Cyfunwch nhw a pheidiwch â gadael i'ch boncyffion ddod yn sbwriel mewn pelen fflamio enfawr o ddiwerth. Eglurwch a dangoswch i'r datblygwyr pam na fydd neb arall yn deall eu logiau, dangoswch iddynt sut brofiad yw edrych ar foncyffion diwerth am 3:15 yn y bore.
Awdur y llun ar
Dyna i gyd. Bydd deunydd newydd yn cael ei ryddhau wythnos nesaf. Os hoffech ddysgu mwy am y cwrs, rydym yn eich gwahodd i , a fydd yn cymryd lle ddydd Llun. Ac yn awr rydym yn draddodiadol yn aros am eich sylwadau.
Ffynhonnell: hab.com