Nawr mae pwnc DevOps ar hype. Piblinell Integreiddio a Chyflawni Parhaus mae pawb yn ei roi ar waith. Ond nid yw'r rhan fwyaf bob amser yn rhoi sylw dyledus i sicrhau dibynadwyedd systemau gwybodaeth ar wahanol gamau o'r Piblinell CI/CD. Yn yr erthygl hon hoffwn siarad am fy mhrofiad o awtomeiddio gwiriadau ansawdd meddalwedd a gweithredu senarios posibl ar gyfer ei “hunan-iachâd”.
Rwy'n gweithio fel peiriannydd yn adran rheoli gwasanaeth TG cwmni . Fy maes arbenigedd craidd yw gweithredu systemau monitro perfformiad ceisiadau ac argaeledd amrywiol. Rwy'n aml yn cyfathrebu â chwsmeriaid TG o wahanol rannau o'r farchnad ynghylch materion cyfredol ynghylch monitro ansawdd eu gwasanaethau TG. Y prif nod yw lleihau'r amser cylch rhyddhau a chynyddu amlder rhyddhau. Mae hyn, wrth gwrs, i gyd yn dda: mwy o ddatganiadau - mwy o nodweddion newydd - defnyddwyr mwy bodlon - mwy o elw. Ond mewn gwirionedd, nid yw pethau bob amser yn gweithio'n dda. Gyda chyfraddau defnyddio uchel iawn, mae'r cwestiwn yn codi ar unwaith am ansawdd ein datganiadau. Hyd yn oed gyda phiblinell gwbl awtomataidd, un o'r heriau mwyaf yw symud gwasanaethau o brofi i gynhyrchu heb effeithio ar uptime cymhwysiad a phrofiad y defnyddiwr.
Yn seiliedig ar ganlyniadau nifer o sgyrsiau gyda chwsmeriaid, gallaf ddweud bod rhyddhau rheolaeth ansawdd, y broblem o ddibynadwyedd cais a'r posibilrwydd o "hunan-iachau" (er enghraifft, rholio yn ôl i fersiwn sefydlog) ar wahanol gamau o'r CI /Mae piblinell CD ymhlith y pynciau mwyaf cyffrous a pherthnasol.
Yn ddiweddar, roeddwn i fy hun yn gweithio ar ochr y cwsmer - yn y gwasanaeth cymorth meddalwedd cymwysiadau bancio ar-lein. Roedd pensaernïaeth ein cais yn defnyddio nifer fawr o ficrowasanaethau hunan-ysgrifenedig. Y peth tristaf yw na allai pob datblygwr ymdopi â chyflymder uchel y datblygiad; roedd ansawdd rhai microwasanaethau yn dioddef, a arweiniodd at lysenwau doniol iddyn nhw a'u crewyr. Roedd straeon am ba ddeunyddiau y gwnaed y cynhyrchion hyn ohonynt.
"Ffurfio'r broblem"
Mae amlder uchel y gollyngiadau a nifer fawr o ficrowasanaethau yn ei gwneud hi'n anodd deall gweithrediad y cais yn ei gyfanrwydd, yn y cam profi ac yn y cam gweithredol. Mae newidiadau'n digwydd yn gyson ac mae'n anodd iawn eu rheoli heb offer monitro da. Yn aml, ar ôl rhyddhau noson yn y bore, mae datblygwyr yn eistedd fel ar keg powdr ac yn aros am ddim i dorri, er bod pob siec yn llwyddiannus yn y cam profi.
Mae un pwynt arall. Yn y cam profi, mae ymarferoldeb y feddalwedd yn cael ei wirio: gweithredu prif swyddogaethau'r cais ac absenoldeb gwallau. Mae asesiadau perfformiad ansoddol naill ai ar goll neu nid ydynt yn ystyried pob agwedd ar y cais a'r haen integreiddio. Efallai na fydd rhai metrigau yn cael eu gwirio o gwbl. O ganlyniad, pan fydd chwalfa yn digwydd mewn amgylchedd cynhyrchu, dim ond pan fydd defnyddwyr go iawn yn dechrau cwyno y mae'r adran cymorth technegol yn dod i wybod amdano. Hoffwn leihau effaith meddalwedd o ansawdd isel ar ddefnyddwyr terfynol.
Un o'r atebion yw gweithredu prosesau ar gyfer gwirio ansawdd meddalwedd ar wahanol gamau o'r Piblinell CI/CD, ac ychwanegu gwahanol senarios ar gyfer adfer y system pe bai argyfwng. Cofiwn hefyd fod gennym DevOps. Mae busnesau'n disgwyl derbyn cynnyrch newydd cyn gynted â phosibl. Felly, rhaid i'n holl wiriadau a sgriptiau fod yn awtomataidd.
Rhennir y dasg yn ddwy gydran:
- rheoli ansawdd gwasanaethau yn ystod y cam profi (i awtomeiddio'r broses o ddal cynulliadau o ansawdd isel);
- rheoli ansawdd meddalwedd yn yr amgylchedd cynhyrchu (mecanweithiau ar gyfer canfod problemau yn awtomatig a senarios posibl ar gyfer eu hunan-iachâd).
Offeryn ar gyfer monitro a chasglu metrigau
Er mwyn cyflawni'r nodau a osodwyd, mae angen system fonitro sy'n gallu canfod problemau a'u trosglwyddo i systemau awtomeiddio ar wahanol gamau o'r biblinell CI/CD. Bydd hefyd yn beth cadarnhaol os yw'r system hon yn darparu metrigau defnyddiol ar gyfer gwahanol dimau: datblygu, profi, gweithredu. Ac mae'n hollol wych os yw ar gyfer busnes hefyd.
I gasglu metrigau, gallwch ddefnyddio set o wahanol systemau (Prometheus, ELK Stack, Zabbix, ac ati), ond, yn fy marn i, atebion dosbarth APM sydd fwyaf addas ar gyfer y tasgau hyn (), a all symleiddio'ch bywyd yn fawr.
Fel rhan o fy ngwaith yn y gwasanaeth cymorth, dechreuais wneud prosiect tebyg gan ddefnyddio datrysiad dosbarth APM gan Dynatrace. Nawr, yn gweithio i integreiddiwr, rwy'n gwybod y farchnad systemau monitro yn eithaf da. Fy marn oddrychol: Dynatrace sydd fwyaf addas ar gyfer datrys problemau o'r fath.
Mae Dynatrace yn darparu golwg llorweddol o weithrediad pob defnyddiwr ar lefel gronynnog i lawr i lefel gweithredu'r cod. Gallwch olrhain y gadwyn gyfan o ryngweithio rhwng gwasanaethau gwybodaeth amrywiol: o lefelau pen blaen cymwysiadau gwe a symudol, gweinyddwyr cymwysiadau pen ôl, bws integreiddio i alwad benodol i'r gronfa ddata.
. Adeiladu awtomatig o'r holl ddibyniaethau rhwng cydrannau system
. Canfod ac adeiladu llwybr gweithredu'r gwasanaeth yn awtomatig
Cofiwn hefyd fod angen inni integreiddio â gwahanol offer awtomeiddio. Yma mae gan yr ateb API cyfleus sy'n eich galluogi i anfon a derbyn amrywiol fetrigau a digwyddiadau.
Nesaf, gadewch i ni symud ymlaen i edrych yn fanylach ar sut i ddatrys y problemau hyn gan ddefnyddio system Dynatrace.
Tasg 1. Awtomeiddio rheoli ansawdd gwasanaethau yn ystod y cam profi
Yr her gyntaf yw dod o hyd i broblemau cyn gynted â phosibl ar y gweill ar gyfer cyflwyno ceisiadau. Dim ond adeiladau cod “da” ddylai gyrraedd cynhyrchiant. I wneud hyn, dylai eich piblinell yn y cam profi gynnwys monitorau ychwanegol i wirio ansawdd eich gwasanaethau.
Gadewch i ni edrych gam wrth gam ar sut i weithredu hyn ac awtomeiddio'r broses hon:
Mae'r ffigur yn dangos llif y camau profi ansawdd meddalwedd awtomataidd:
- defnyddio system fonitro (gosod asiantau);
- nodi digwyddiadau ar gyfer asesu ansawdd eich meddalwedd (metrigau a gwerthoedd trothwy) a'u trosglwyddo i'r system fonitro;
- cynhyrchu profion llwyth a pherfformiad;
- casglu data perfformiad ac argaeledd yn y system fonitro;
- trosglwyddo data profion yn seiliedig ar ddigwyddiadau asesu ansawdd meddalwedd o'r system fonitro i'r system CI/CD. Dadansoddiad awtomatig o wasanaethau.
Cam 1. Defnyddio'r system fonitro
Yn gyntaf mae angen i chi osod yr asiantau yn eich amgylchedd prawf. Ar yr un pryd, mae gan y datrysiad Dynatrace nodwedd braf - mae'n defnyddio'r asiant cyffredinol OneAgent, sydd wedi'i osod ar enghraifft OS (Windows, Linux, AIX), yn canfod eich gwasanaethau yn awtomatig ac yn dechrau casglu data monitro arnynt. Nid oes angen i chi ffurfweddu asiant ar wahân ar gyfer pob proses. Bydd y sefyllfa'n debyg ar gyfer llwyfannau cwmwl a chynwysyddion. Ar yr un pryd, gallwch hefyd awtomeiddio'r broses gosod asiant. Mae Dynatrace yn cyd-fynd yn berffaith â'r cysyniad "isadeiledd fel cod" (): Mae sgriptiau parod a chyfarwyddiadau ar gyfer pob llwyfan poblogaidd. Rydych chi'n ymgorffori'r asiant yng nghyfluniad eich gwasanaeth, a phan fyddwch chi'n ei ddefnyddio, rydych chi'n derbyn gwasanaeth newydd ar unwaith gydag asiant sydd eisoes yn gweithio.
Cam 2: Diffiniwch eich digwyddiadau ansawdd meddalwedd
Nawr mae angen i chi benderfynu ar y rhestr o wasanaethau a gweithrediadau busnes. Mae'n bwysig ystyried yn union y gweithrediadau defnyddwyr hynny sy'n hanfodol i'ch gwasanaeth o ran busnes. Yma rwy'n argymell ymgynghori â dadansoddwyr busnes a systemau.
Nesaf, mae angen i chi benderfynu pa fetrigau rydych chi am eu cynnwys yn yr adolygiad ar gyfer pob lefel. Er enghraifft, gallai hyn fod yn amser gweithredu (wedi'i rannu'n gyfartaledd, canolrif, canraddau, ac ati), gwallau (rhesymegol, gwasanaeth, seilwaith, ac ati) a metrigau seilwaith amrywiol (pentwr cof, casglwr sbwriel, cyfrif edau, ac ati).
Er mwyn awtomeiddio a rhwyddineb defnydd gan dîm DevOps, mae'r cysyniad o “Monitro fel Cod” yn ymddangos. Yr hyn yr wyf yn ei olygu wrth hyn yw y gall datblygwr / profwr ysgrifennu ffeil JSON syml sy'n diffinio metrigau sicrhau ansawdd meddalwedd.
Gadewch i ni edrych ar enghraifft o ffeil JSON o'r fath. Defnyddir gwrthrychau o API Dynatrace fel parau allwedd/gwerth (mae disgrifiad API i'w weld yma ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}Mae'r ffeil yn amrywiaeth o ddiffiniadau cyfres amser:
- timeseriesId – y metrig sy'n cael ei wirio, er enghraifft, Amser Ymateb, Cyfrif Gwallau, Cof a ddefnyddir, ac ati;
- agregu - lefel agregu metrig, yn ein hachos ni cyf, ond gallwch ddefnyddio unrhyw un sydd ei angen arnoch (cyf, min, uchafswm, swm, cyfrif, canradd);
- tagiau - tag gwrthrych yn y system fonitro, neu gallwch nodi dynodwr gwrthrych penodol;
- difrifol a rhybudd - mae'r dangosyddion hyn yn rheoleiddio gwerthoedd trothwy ein metrigau; os yw gwerth y prawf yn fwy na'r trothwy difrifol, yna nodir nad yw ein hadeiladwaith yn llwyddiannus.
Mae'r ffigur canlynol yn dangos enghraifft o'r defnydd o drothwyon o'r fath.
Cam 3: Cynhyrchu Llwyth
Unwaith y byddwn wedi pennu lefelau ansawdd ein gwasanaeth, mae angen i ni gynhyrchu llwyth prawf. Gallwch ddefnyddio unrhyw un o'r offer profi rydych chi'n gyfforddus â nhw, fel Jmeter, Selenium, Neotys, Gatling, ac ati.
Mae system fonitro Dynatrace yn eich galluogi i gipio metadata amrywiol o'ch profion a chydnabod pa brofion sy'n perthyn i ba gylchred rhyddhau a pha wasanaeth. Argymhellir ychwanegu penawdau ychwanegol at geisiadau prawf HTTP.
Mae'r ffigur canlynol yn dangos enghraifft lle, gan ddefnyddio'r pennawd ychwanegol X-Dynatrace-Test, rydym yn nodi bod y prawf hwn yn ymwneud â phrofi gweithrediad ychwanegu eitem at y drol.
Pan fyddwch chi'n rhedeg pob prawf llwyth, rydych chi'n anfon gwybodaeth gyd-destunol ychwanegol at Dynatrace gan ddefnyddio'r Event API o'r gweinydd CI/CD. Yn y modd hwn, gall y system wahaniaethu rhwng gwahanol brofion.
. Digwyddiad yn y system fonitro am ddechrau profi llwyth
Cam 4-5. Casglu data perfformiad a throsglwyddo data i'r system CI/CD
Ynghyd â'r prawf a gynhyrchir, trosglwyddir digwyddiad i'r system fonitro ynghylch yr angen i gasglu data ar wirio dangosyddion ansawdd gwasanaeth. Mae hefyd yn nodi ein ffeil JSON, sy'n diffinio'r metrigau allweddol.
Digwyddiad am yr angen i wirio ansawdd y meddalwedd a gynhyrchir ar y gweinydd CI/CD i'w anfon i'r system fonitro
Yn ein enghraifft, gelwir y digwyddiad gwirio ansawdd perfSigDynatraceReport (Perfformiad_Llofnod) - mae hwn yn barod ar gyfer integreiddio â Jenkins, a ddatblygwyd gan y bechgyn o T-Systems Multimedia Solutions. Mae pob digwyddiad lansio prawf yn cynnwys gwybodaeth am y gwasanaeth, rhif adeiladu, ac amser profi. Mae'r ategyn yn casglu gwerthoedd perfformiad ar amser adeiladu, yn eu gwerthuso, ac yn cymharu'r canlyniad â gofynion adeiladu blaenorol a gofynion anweithredol.
Digwyddiad yn y system fonitro am ddechrau gwiriad ansawdd adeiladu.
Ar ôl cwblhau'r prawf, trosglwyddir yr holl fetrigau ar gyfer asesu ansawdd meddalwedd yn ôl i system integreiddio barhaus, er enghraifft, Jenkins, sy'n cynhyrchu adroddiad ar y canlyniadau.
Canlyniad ystadegau ar wasanaethau ar y gweinydd CI/CD.
Ar gyfer pob adeilad unigol, rydym yn gweld ystadegau ar gyfer pob metrig rydyn ni'n ei osod trwy gydol y prawf cyfan. Rydym hefyd yn gweld a oedd troseddau mewn gwerthoedd trothwy penodol (rhybudd a throthwyon difrifol). Yn seiliedig ar fetrigau cyfanredol, mae'r adeilad cyfan wedi'i farcio'n sefydlog, yn ansefydlog neu wedi methu. Hefyd, er hwylustod, gallwch ychwanegu dangosyddion at yr adroddiad sy'n cymharu'r adeilad presennol â'r un blaenorol.
Gweld ystadegau manwl ar wasanaethau ar y gweinydd CI/CD.
Cymhariaeth fanwl o ddau gynulliad
Os oes angen, gallwch fynd i ryngwyneb Dynatrace ac yno gallwch weld yr ystadegau ar gyfer pob un o'ch adeiladau yn fwy manwl a'u cymharu â'i gilydd.
Cymharu ystadegau adeiladu yn Dynatrace.
Canfyddiadau
O ganlyniad, rydym yn cael gwasanaeth “monitro fel gwasanaeth”, wedi'i awtomeiddio ar y gweill integreiddio parhaus. Dim ond rhestr o fetrigau mewn ffeil JSON y mae angen i'r datblygwr neu'r profwr ei ddiffinio, ac mae popeth arall yn digwydd yn awtomatig. Rydym yn derbyn rheolaeth ansawdd tryloyw ar ddatganiadau: pob hysbysiad am berfformiad, defnydd adnoddau neu atchweliadau pensaernïol.
Tasg 2. Awtomeiddio rheoli ansawdd meddalwedd mewn amgylchedd cynhyrchu
Felly, rydym wedi datrys y broblem o sut i awtomeiddio'r broses fonitro yn y cam profi yn Piblinell. Fel hyn rydym yn lleihau canran y gwasanaethau o ansawdd isel sy'n cyrraedd yr amgylchedd cynhyrchu.
Ond beth i'w wneud os bydd meddalwedd drwg yn cael ei werthu, neu os bydd rhywbeth yn torri. Ar gyfer iwtopia, roeddem eisiau mecanweithiau i ganfod problemau yn awtomatig ac, os yn bosibl, y system ei hun i adfer ei swyddogaeth, o leiaf gyda'r nos.
I wneud hyn, mae angen i ni, trwy gyfatebiaeth â'r adran flaenorol, ddarparu ar gyfer gwiriadau ansawdd meddalwedd awtomatig yn yr amgylchedd cynhyrchu a'u seilio ar senarios ar gyfer hunan-iachâd y system.
Awtogywiro fel cod
Mae gan y rhan fwyaf o gwmnïau eisoes sylfaen wybodaeth gronedig o wahanol fathau o broblemau cyffredin a rhestr o gamau gweithredu i'w trwsio, er enghraifft, ailgychwyn prosesau, glanhau adnoddau, treiglo fersiynau yn ôl, adfer newidiadau cyfluniad annilys, cynyddu neu leihau nifer y cydrannau yn y clwstwr, gan newid yr amlinelliad glas neu wyrdd ac ati.
Er bod yr achosion defnydd hyn wedi bod yn hysbys ers blynyddoedd gan lawer o'r timau rwy'n siarad â nhw, ychydig iawn sydd wedi meddwl amdanynt neu fuddsoddi yn eu hawtomeiddio.
Os meddyliwch am y peth, nid oes unrhyw beth yn rhy gymhleth wrth weithredu prosesau ar gyfer perfformiad cais hunan-iacháu; mae angen i chi gyflwyno senarios gwaith hysbys eich gweinyddwyr eisoes ar ffurf sgriptiau cod (y cysyniad “awto-atgyweirio fel cod”) , a ysgrifenasoch ymlaen llaw ar gyfer pob achos penodol. Dylai sgriptiau atgyweirio awtomatig gael eu hanelu at ddileu achos sylfaenol y broblem. Chi eich hun sy'n pennu'r camau gweithredu cywir i ymateb i ddigwyddiad.
Gall unrhyw fetrig o'ch system fonitro weithredu fel sbardun i lansio'r sgript, y prif beth yw bod y metrigau hyn yn pennu'n gywir bod popeth yn ddrwg, gan na fyddech am gael pethau cadarnhaol ffug mewn amgylchedd cynhyrchiol.
Gallwch ddefnyddio unrhyw system neu set o systemau: Prometheus, ELK Stack, Zabbix, ac ati. Ond byddaf yn rhoi rhai enghreifftiau yn seiliedig ar ddatrysiad APM (bydd Dynatrace yn enghraifft eto) a fydd hefyd yn helpu i wneud eich bywyd yn haws.
Yn gyntaf, mae popeth yn ymwneud â pherfformiad o ran gweithrediad y cais. Mae'r datrysiad yn darparu cannoedd o fetrigau ar wahanol lefelau y gallwch eu defnyddio fel sbardunau:
- lefel defnyddiwr (porwyr, cymwysiadau symudol, dyfeisiau IoT, ymddygiad defnyddwyr, trosi, ac ati);
- lefel gwasanaeth a gweithrediadau (perfformiad, argaeledd, gwallau, ac ati);
- lefel seilwaith cymhwysiad (metrigau OS gwesteiwr, JMX, MQ, gwe-weinydd, ac ati);
- lefel platfform (rhithwiroli, cwmwl, cynhwysydd, ac ati).
Monitro lefelau yn Dynatrace.
Yn ail, fel y dywedais yn gynharach, mae gan Dynatrace API agored, sy'n ei gwneud hi'n hawdd iawn integreiddio â systemau trydydd parti amrywiol. Er enghraifft, anfon hysbysiad i'r system awtomeiddio pan eir y tu hwnt i baramedrau rheoli.
Isod mae enghraifft ar gyfer rhyngweithio ag Ansible.
Isod byddaf yn rhoi ychydig o enghreifftiau o ba fath o awtomeiddio y gellir ei wneud. Dim ond rhan o'r achosion yw hyn; dim ond eich dychymyg a galluoedd eich offer monitro all gyfyngu ar eu rhestr yn eich amgylchedd.
1. Defnydd gwael – dychwelyd fersiwn
Hyd yn oed os byddwn yn profi popeth yn dda iawn mewn amgylchedd prawf, mae siawns o hyd y gallai datganiad newydd ladd eich cais mewn amgylchedd cynhyrchu. Nid yw'r un ffactor dynol wedi'i ganslo.
Yn y ffigwr canlynol gwelwn fod naid sydyn yn amser cyflawni gweithrediadau ar y gwasanaeth. Mae dechrau'r naid hon yn cyd-fynd â'r amser y'i defnyddiwyd i'r cais. Rydym yn trosglwyddo'r holl wybodaeth hon fel digwyddiadau i'r system awtomeiddio. Os na fydd perfformiad y gwasanaeth yn dychwelyd i normal ar ôl yr amser a osodwyd gennym, yna gelwir sgript yn awtomatig sy'n rholio'r fersiwn yn ôl i'r hen un.
Diraddio perfformiad gweithrediadau ar ôl lleoli.
2. Llwytho adnoddau ar 100% - ychwanegu nod at lwybro
Yn yr enghraifft ganlynol, mae'r system fonitro yn pennu bod un o'r cydrannau yn profi llwyth CPU 100%.
Llwyth CPU 100%
Mae sawl senario gwahanol yn bosibl ar gyfer y digwyddiad hwn. Er enghraifft, mae'r system fonitro hefyd yn gwirio a yw'r diffyg adnoddau yn gysylltiedig â chynnydd yn y llwyth ar y gwasanaeth. Os felly, yna gweithredir sgript sy'n ychwanegu nod yn awtomatig i'r llwybro, a thrwy hynny adfer ymarferoldeb y system gyfan.
Graddio ar ôl digwyddiad
3. Diffyg lle ar y gyriant caled - glanhau disg
Credaf fod llawer o bobl eisoes wedi awtomeiddio’r prosesau hyn. Gan ddefnyddio APM, gallwch hefyd fonitro'r gofod rhydd ar yr is-system ddisg. Os nad oes lle neu os yw'r ddisg yn rhedeg yn araf, rydyn ni'n galw sgript i'w lanhau neu ychwanegu lle.
Llwyth disg 100%
4. Gweithgaredd defnyddiwr isel neu drawsnewid isel - newid rhwng canghennau glas a gwyrdd
Rwy'n aml yn gweld cwsmeriaid yn defnyddio dwy ddolen (defnydd glas-wyrdd) ar gyfer cymwysiadau mewn amgylchedd cynhyrchu. Mae hyn yn caniatáu ichi newid yn gyflym rhwng canghennau wrth gyflwyno datganiadau newydd. Yn aml, ar ôl eu defnyddio, gall newidiadau dramatig ddigwydd nad ydynt yn amlwg ar unwaith. Yn yr achos hwn, efallai na welir dirywiad mewn perfformiad ac argaeledd. Er mwyn ymateb yn gyflym i newidiadau o'r fath, mae'n well defnyddio metrigau amrywiol sy'n adlewyrchu ymddygiad defnyddwyr (nifer y sesiynau a chamau gweithredu defnyddwyr, trosi, cyfradd bownsio). Mae'r ffigur canlynol yn dangos enghraifft lle, pan fydd cyfraddau trosi yn gostwng, mae newid rhwng canghennau meddalwedd yn digwydd.
Cyfradd trosi yn disgyn ar ôl newid rhwng canghennau meddalwedd.
Mecanweithiau ar gyfer canfod problemau yn awtomatig
Yn olaf, rhoddaf un enghraifft arall ichi o pam rwy'n hoffi Dynatrace fwyaf.
Yn y rhan o fy stori am awtomeiddio gwiriadau ansawdd o gynulliadau mewn amgylchedd prawf, fe wnaethom bennu'r holl werthoedd trothwy â llaw. Mae hyn yn arferol ar gyfer amgylchedd prawf; mae'r profwr ei hun yn pennu'r dangosyddion cyn pob prawf yn dibynnu ar y llwyth. Mewn amgylchedd cynhyrchu, mae'n ddymunol bod problemau'n cael eu canfod yn awtomatig, gan gymryd i ystyriaeth fecanweithiau sylfaenol amrywiol.
Mae gan Dynatrace offer deallusrwydd artiffisial adeiledig diddorol sydd, yn seiliedig ar fecanweithiau ar gyfer pennu metrigau afreolaidd (llinell sylfaen) ac adeiladu map o ryngweithio rhwng yr holl gydrannau, gan gymharu a chydberthynu digwyddiadau â'i gilydd, yn pennu anghysondebau yng ngweithrediad eich gwasanaeth ac yn darparu manylion manwl. gwybodaeth am bob problem ac achos sylfaenol.
Trwy ddadansoddi dibyniaethau rhwng cydrannau yn awtomatig, mae Dynatrace yn penderfynu nid yn unig ai'r gwasanaeth problemus yw'r achos sylfaenol, ond hefyd ei ddibyniaeth ar wasanaethau eraill. Yn yr enghraifft isod, mae Dynatrace yn monitro ac yn gwerthuso iechyd pob gwasanaeth yn awtomatig wrth gyflawni'r trafodion, gan nodi gwasanaeth Golang fel yr achos sylfaenol.
Enghraifft o bennu achos sylfaenol methiant.
Mae'r ffigur canlynol yn dangos y broses o fonitro problemau gyda'ch cais o ddechrau digwyddiad.
Delweddu problem sy'n dod i'r amlwg gydag arddangos yr holl gydrannau a digwyddiadau arnynt
Casglodd y system fonitro gronoleg gyflawn o ddigwyddiadau yn ymwneud â'r broblem a gododd. Yn y ffenestr o dan y llinell amser gwelwn yr holl ddigwyddiadau allweddol ar bob un o'r cydrannau. Yn seiliedig ar y digwyddiadau hyn, gallwch osod gweithdrefnau ar gyfer cywiro awtomatig ar ffurf sgriptiau cod.
Yn ogystal, rwy'n eich cynghori i integreiddio system fonitro gyda'r Ddesg Wasanaeth neu draciwr bygiau. Pan fydd problem yn digwydd, mae datblygwyr yn derbyn gwybodaeth gyflawn yn gyflym i'w dadansoddi ar lefel y cod yn yr amgylchedd cynhyrchu.
Casgliad
O ganlyniad, yn y diwedd, cawsom biblinell CI/CD gyda gwiriadau ansawdd meddalwedd awtomataidd yn rhan o'r Piblinell. Rydym yn lleihau nifer y cynulliadau o ansawdd isel, yn cynyddu dibynadwyedd y system gyfan, ac os bydd ein system yn dal i fethu, rydym yn lansio mecanweithiau i'w hadfer.
Mae'n bendant yn werth buddsoddi ymdrech i awtomeiddio monitro ansawdd meddalwedd; nid yw bob amser yn broses gyflym, ond dros amser bydd yn dwyn ffrwyth. Rwy'n argymell, ar ôl datrys digwyddiad newydd yn yr amgylchedd cynhyrchu, eich bod chi'n meddwl ar unwaith pa fonitorau i'w hychwanegu ar gyfer gwiriadau yn yr amgylchedd prawf er mwyn osgoi adeiladu gwael rhag mynd i mewn i gynhyrchu, a hefyd creu sgript i gywiro'r problemau hyn yn awtomatig.
Gobeithiaf y bydd fy enghreifftiau yn eich helpu yn eich ymdrechion. Bydd gennyf ddiddordeb hefyd mewn gweld eich enghreifftiau o fetrigau a ddefnyddir i roi systemau hunan-iachau ar waith.
Ffynhonnell: hab.com