No is it ûnderwerp fan DevOps op hype. Trochrinnende yntegraasje en levering Pipeline elkenien is it útfieren. Mar de measten betelje net altyd genôch omtinken foar it garandearjen fan de betrouberens fan ynformaasjesystemen yn ferskate stadia fan 'e CI / CD Pipeline. Yn dit artikel wol ik graach prate oer myn ûnderfining yn it automatisearjen fan softwarekwaliteitskontrôles en it ymplementearjen fan mooglike senario's foar har "self-healing".
Ik wurkje as yngenieur yn 'e ôfdieling IT-tsjinstbehear fan in bedriuw . Myn kearngebiet fan saakkundigens is de ymplemintaasje fan ferskate systemen foar tafersjoch fan tapassingsprestaasjes en beskikberens. Ik kommunisearje faak mei IT-klanten út ferskate merksegminten oangeande aktuele problemen oangeande it kontrolearjen fan de kwaliteit fan har IT-tsjinsten. It haaddoel is om de tiid fan 'e release-syklus te minimalisearjen en de frekwinsje fan releases te ferheegjen. Dit is fansels allegear goed: mear releases - mear nije funksjes - mear tefreden brûkers - mear winst. Mar yn werklikheid, dingen wurkje net altyd goed. Mei tige hege ynset tariven, komt de fraach fuortendaliks oer de kwaliteit fan ús releases. Sels mei in folslein automatisearre pipeline is ien fan 'e grutste útdagings it ferpleatsen fan tsjinsten fan testen nei produksje sûnder ynfloed op uptime fan applikaasjes en brûkersûnderfining.
Op grûn fan de resultaten fan tal fan petearen mei klanten, kin ik sizze dat release kwaliteit kontrôle, it probleem fan tapassing betrouberens en de mooglikheid fan syn "self-healing" (bygelyks, rôlje werom nei in stabile ferzje) op ferskate stadia fan de CI /CD pipeline binne ûnder de meast spannende en relevante ûnderwerpen.
Koartlyn haw ik sels wurke oan 'e klantkant - yn' e stipetsjinst foar online bankingapplikaasjesoftware. De arsjitektuer fan ús applikaasje brûkte in grut oantal selsskreaune mikrotsjinsten. It treurichste is dat net alle ûntwikkelders it hege tempo fan ûntwikkeling koene omgean; de kwaliteit fan guon mikrotsjinsten lijde, wat oanlieding joech ta grappige bynammen foar har en har makkers. Der wiene ferhalen oer hokker materialen dizze produkten makke wiene.
"Formulearring fan it probleem"
De hege frekwinsje fan releases en in grut oantal mikrotsjinsten meitsje it lestich om de wurking fan 'e applikaasje as gehiel te begripen, sawol yn' e testfase as yn 'e operasjonele poadium. Feroarings komme konstant foar en it is heul lestich om se te kontrolearjen sûnder goede tafersjochynstruminten. Faak, nei in nacht frijlitting yn 'e moarn, ûntwikkelders sitte as op in poeder keg en wachtsje op neat te brekken, hoewol't alle kontrôles wiene suksesfol op it test stadium.
Der is noch ien punt. Yn it teststadium wurdt de funksjonaliteit fan 'e software kontrolearre: de ymplemintaasje fan' e haadfunksjes fan 'e applikaasje en it ûntbrekken fan flaters. Kwalitative prestaasjesbeoardielingen ûntbrekke of nimme gjin rekken mei alle aspekten fan 'e applikaasje en de yntegraasjelaach. Guon metriken wurde miskien hielendal net kontrolearre. As gefolch, as in steuring plakfynt yn in produksjeomjouwing, fynt de ôfdieling technyske stipe it allinich as echte brûkers begjinne te klagen. Ik wol de ynfloed fan software fan lege kwaliteit op ein brûkers minimalisearje.
Ien fan 'e oplossingen is om prosessen te ymplementearjen foar it kontrolearjen fan softwarekwaliteit yn ferskate stadia fan' e CI / CD Pipeline, en ferskate senario's ta te foegjen foar it werstellen fan it systeem yn gefal fan in need. Wy ûnthâlde ek dat wy DevOps hawwe. Bedriuwen ferwachtsje sa gau mooglik in nij produkt te krijen. Dêrom moatte al ús kontrôles en skripts automatisearre wurde.
De taak is ferdield yn twa komponinten:
- kwaliteitskontrôle fan gearkomsten yn 'e teststadium (om it proses fan it fangen fan assemblies fan lege kwaliteit te automatisearjen);
- software kwaliteitskontrôle yn 'e produksjeomjouwing (meganismen foar automatyske deteksje fan problemen en mooglike senario's foar har selshealing).
Tool foar it kontrolearjen en sammeljen fan metriken
Om de ynstelde doelen te berikken is in tafersjochsysteem nedich dat problemen kin ûntdekke en oerdrage oan automatisearringssystemen yn ferskate stadia fan 'e CI / CD-pipeline. It sil ek in posityf ding wêze as dit systeem nuttige metriken leveret foar ferskate teams: ûntwikkeling, testen, operaasje. En it is perfoarst prachtich as it ek foar bedriuw is.
Om metriken te sammeljen kinne jo in set fan ferskate systemen brûke (Prometheus, ELK Stack, Zabbix, ensfh.), Mar, nei myn miening, binne oplossings fan APM-klasse it bêste geskikt foar dizze taken (), wat jo libben sterk kin ferienfâldigje.
As ûnderdiel fan myn wurk yn 'e stipetsjinst begon ik in ferlykber projekt te dwaan mei in APM-klasse-oplossing fan Dynatrace. No, wurkjen foar in yntegrator, ken ik de merk foar tafersjochsystemen frij goed. Myn subjektive miening: Dynatrace is it bêste geskikt foar it oplossen fan sokke problemen.
Dynatrace biedt in horizontale werjefte fan elke brûkersoperaasje op in korrelige nivo oant it koade-útfiernivo. Jo kinne de hiele keatling fan ynteraksje folgje tusken ferskate ynformaasjetsjinsten: fan 'e front-end nivo's fan web- en mobile applikaasjes, back-end-applikaasjetsjinners, yntegraasjebus oant in spesifike oprop nei de databank.
. Automatyske konstruksje fan alle ôfhinklikens tusken systeemkomponinten
. Automatyske opspoaren en oanlis fan it paad fan tsjinst operaasje
Wy betinke ek dat wy moatte yntegrearje mei ferskate automatisearring ark. Hjir hat de oplossing in handige API wêrmei jo ferskate metriken en eveneminten kinne ferstjoere en ûntfange.
Litte wy dan fierder gean nei in mear detaillearre blik op hoe't jo dizze problemen kinne oplosse mei it Dynatrace-systeem.
Taak 1. Automatisearring fan kwaliteitskontrôle fan gearkomsten yn 'e teststadium
De earste útdaging is om problemen sa betiid mooglik te finen yn 'e pipeline foar tapassing fan tapassing. Allinich "goede" koade builds moatte produksje berikke. Om dit te dwaan, moat jo pipeline yn it teststadium ekstra monitors omfetsje om de kwaliteit fan jo tsjinsten te kontrolearjen.
Litte wy stap foar stap sjen hoe't jo dit ymplementearje en dit proses automatisearje:
De figuer toant de stream fan automatyske stappen foar testen fan softwarekwaliteit:
- ynset fan in tafersjochsysteem (ynstallaasje fan aginten);
- it identifisearjen fan eveneminten foar it beoardieljen fan de kwaliteit fan jo software (metriken en drompelwearden) en it oerdragen nei it tafersjochsysteem;
- generaasje fan load- en prestaasjestests;
- sammelje prestaasjes en beskikberensgegevens yn it tafersjochsysteem;
- oerdracht fan testgegevens basearre op eveneminten foar beoardieling fan softwarekwaliteit fan it tafersjochsysteem nei it CI / CD-systeem. Automatyske analyze fan gearkomsten.
Stap 1. Ynset fan it tafersjochsysteem
Earst moatte jo de aginten yn jo testomjouwing ynstallearje. Tagelyk hat de Dynatrace-oplossing in moaie funksje - it brûkt de universele agent OneAgent, dy't is ynstalleare op in OS-eksimplaar (Windows, Linux, AIX), detektearret jo tsjinsten automatysk en begjint tafersjochgegevens oer har te sammeljen. Jo hoege net in aparte agint te konfigurearjen foar elk proses. De situaasje sil fergelykber wêze foar wolk- en kontenerplatfoarms. Tagelyk kinne jo it ynstallaasjeproses fan agent ek automatisearje. Dynatrace past perfekt yn it konsept "ynfrastruktuer as koade" (): D'r binne klearmakke skripts en ynstruksjes foar alle populêre platfoarms. Jo ynbêde de agint yn 'e konfiguraasje fan jo tsjinst, en as jo it ynsette, krije jo fuortendaliks in nije tsjinst mei in al wurkjende agent.
Stap 2: Definiearje jo eveneminten foar softwarekwaliteit
No moatte jo beslute oer de list fan tsjinsten en saaklike operaasjes. It is wichtich om krekt dy brûkersoperaasjes te rekkenjen dy't saaklik kritysk binne foar jo tsjinst. Hjir ried ik oan om te rieplachtsjen mei saaklike en systeemanalisten.
Dêrnei moatte jo bepale hokker metriken jo wolle opnimme yn 'e resinsje foar elk nivo. Dit kin bygelyks útfieringstiid wêze (ferdield yn gemiddelde, mediaan, percentiles, ensfh.), Flaters (logysk, tsjinst, ynfrastruktuer, ensfh.) En ferskate ynfrastruktuermetriken (ûnthâldheap, garbage collector, thread count, ensfh.).
Foar automatisearring en gemak fan gebrûk troch it DevOps-team ferskynt it konsept fan "Monitoring as Code". Wat ik hjirmei bedoel is dat in ûntwikkelder / tester in ienfâldige JSON-bestân kin skriuwe dy't metriken foar softwarekwaliteit definiearret.
Litte wy nei in foarbyld sjen fan sa'n JSON-bestân. Objekten fan 'e Dynatrace API wurde brûkt as kaai / wearde-pearen (API-beskriuwing is hjir te finen ).
{
"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
}
]
}De triem is in array fan tiidrige definysjes:
- timeseriesId - de metryske wurdt kontrolearre, Bygelyks, Response Tiid, Flater count, Unthâld brûkt, ensfh;
- aggregaasje - nivo fan metrike aggregaasje, yn ús gefal avg, mar jo kinne ien brûke dy't jo nedich binne (avg, min, max, sum, count, percentile);
- tags - foarwerp tag yn it tafersjoch systeem, of jo kinne opjaan in spesifike foarwerp identifier;
- serieus en warskôging - dizze yndikatoaren regelje de drompelwearden fan ús metriken; as de testwearde de swiere drompel grutter is, dan wurdt ús bou markearre as net suksesfol.
De folgjende figuer lit in foarbyld sjen fan it brûken fan sokke drompels.
Stap 3: Laden generaasje
As wy de kwaliteitsnivo's fan ús tsjinst hawwe bepaald, moatte wy in testlading generearje. Jo kinne elk fan 'e testynstruminten brûke wêrmei jo noflik binne, lykas Jmeter, Selenium, Neotys, Gatling, ensfh.
It tafersjochsysteem fan Dynatrace lit jo ferskate metadata fan jo tests fêstlizze en werkenne hokker tests hearre ta hokker release-syklus en hokker tsjinst. It is oan te rieden om ekstra kopteksten ta te foegjen oan HTTP-testoanfragen.
De folgjende figuer lit in foarbyld sjen wêr't wy, mei help fan de ekstra koptekst X-Dynatrace-Test, oanjaan dat dizze test relatearret oan it testen fan de wurking fan it tafoegjen fan in item oan 'e karre.
As jo elke loadtest útfiere, stjoere jo ekstra kontekstuele ynformaasje nei Dynatrace mei de Event API fan 'e CI / CD-tsjinner. Op dizze manier kin it systeem ûnderskiede tusken ferskate testen.
. Event yn it tafersjochsysteem oer it begjin fan loadtesten
Stap 4-5. Sammelje prestaasjesgegevens en oerdrage gegevens nei it CI / CD-systeem
Tegearre mei de oanmakke test wurdt in evenemint oerdroegen oan it tafersjochsysteem oer de needsaak om gegevens te sammeljen oer it kontrolearjen fan yndikatoaren fan tsjinstkwaliteit. It spesifiseart ek ús JSON-bestân, dat de kaaimetriken definiearret.
Event oer de needsaak om te kontrolearjen de kwaliteit fan software oanmakke op de CI / CD tsjinner foar ferstjoeren nei it tafersjochsysteem
Yn ús foarbyld wurdt it evenemint foar kwaliteitskontrôle neamd perfSigDynatraceReport (Performance_Signature) - dit is klear foar yntegraasje mei Jenkins, dat waard ûntwikkele troch de jonges fan T-Systems Multimedia Solutions. Elk teststartevenemint befettet ynformaasje oer de tsjinst, buildnûmer en testtiid. De plugin sammelt prestaasjeswearden op bouwtiid, evaluearret se en fergeliket it resultaat mei eardere builds en net-funksjonele easken.
Event yn it tafersjochsysteem oer it begjin fan in boukwaliteitskontrôle.
Nei't de test foltôge is, wurde alle metriken foar it beoardieljen fan softwarekwaliteit werombrocht nei in trochgeande yntegraasjesysteem, bygelyks Jenkins, dy't in rapport generearret oer de resultaten.
It resultaat fan statistiken oer gearkomsten op de CI / CD tsjinner.
Foar elke yndividuele bou sjogge wy statistiken foar elke metrik dy't wy yn 'e heule test ynstelle. Wy sjogge ek as d'r oertredings wiene yn bepaalde drompelwearden (warskôging en swiere thrashholds). Op grûn fan aggregearre metriken wurdt de heule build markearre as stabyl, ynstabyl of mislearre. Ek kinne jo foar it gemak yndikatoaren tafoegje oan it rapport dy't de hjoeddeistige build fergelykje mei de foarige.
Besjoch detaillearre statistiken oer gearkomsten op de CI / CD tsjinner.
Detaillearre ferliking fan twa gearkomsten
As it nedich is, kinne jo nei de Dynatrace-ynterface gean en dêr kinne jo de statistiken foar elk fan jo builds yn mear detail besjen en se mei elkoar fergelykje.
Fergeliking fan buildstatistiken yn Dynatrace.
befinings
As gefolch krije wy in tsjinst "monitoring as in tsjinst", automatisearre yn 'e trochgeande yntegraasjepipeline. De ûntwikkelder of tester hoecht allinich in list fan metriken te definiearjen yn in JSON-bestân, en al it oare bart automatysk. Wy krije transparante kwaliteitskontrôle fan releases: alle notifikaasjes oer prestaasjes, boarneferbrûk of arsjitektoanyske regressions.
Taak 2. Automatisearring fan software kwaliteit kontrôle yn in produksje omjouwing
Dat, wy hawwe it probleem oplost hoe't jo it tafersjochproses kinne automatisearje yn 'e teststadium yn Pipeline. Op dizze manier minimalisearje wy it persintaazje assemblies fan lege kwaliteit dy't de produksjeomjouwing berikke.
Mar wat te dwaan as minne software úteinlik ferkocht wurdt, of wat gewoan brekt. Foar in utopy woene wy meganismen om automatysk problemen te ûntdekken en, as it mooglik is, it systeem sels om syn funksjonaliteit te herstellen, op syn minst nachts.
Om dit te dwaan, moatte wy, yn analogy mei de foarige seksje, soargje foar automatyske kwaliteitskontrôles fan software yn 'e produksjeomjouwing en se basearje op senario's foar selshealing fan it systeem.
Autokorrigearje as koade
De measte bedriuwen hawwe al in opboude kennisbasis fan ferskate soarten mienskiplike problemen en in list mei aksjes om se te reparearjen, bygelyks it op 'e nij opstarten fan prosessen, it opromjen fan boarnen, it weromdraaien fan ferzjes, it herstellen fan ûnjildige konfiguraasjewizigingen, it fergrutsjen of ferminderjen fan it oantal komponinten yn it kluster, it wikseljen fan de blauwe of griene omtrek en ensfh.
Hoewol dizze gebrûksgefallen al jierren bekend binne troch in protte fan 'e teams mei wa't ik praat, hawwe in pear tocht oer of ynvestearre yn it automatisearjen fan se.
As jo der oer neitinke, is d'r neat te yngewikkeld by it ymplementearjen fan prosessen foar selshealjende applikaasjeprestaasjes; jo moatte de al bekende wurksenario's fan jo behearders presintearje yn 'e foarm fan koadeskripts (it konsept "auto-fix as koade") , dy't jo foar elk spesifike gefal skreaun hawwe. Automatyske reparaasjeskripts moatte rjochte wêze op it eliminearjen fan 'e root oarsaak fan it probleem. Jo sels bepale de juste aksjes om te reagearjen op in ynsidint.
Elke metrik fan jo tafersjochsysteem kin fungearje as in trigger om it skript te starten, it wichtichste is dat dizze metriken krekt bepale dat alles min is, om't jo gjin falske positiven wolle krije yn in produktive omjouwing.
Jo kinne elk systeem of set fan systemen brûke: Prometheus, ELK Stack, Zabbix, ensfh. Mar ik sil jaan wat foarbylden basearre op in APM oplossing (Dynatrace sil wêze in foarbyld wer) dat sil ek helpe meitsje dyn libben makliker.
As earste is d'r alles relatearre oan prestaasjes yn termen fan tapassingsoperaasje. De oplossing biedt hûnderten metriken op ferskate nivo's dy't jo kinne brûke as triggers:
- brûkersnivo (browsers, mobile applikaasjes, IoT-apparaten, brûkersgedrach, konverzje, ensfh.);
- nivo fan tsjinst en operaasjes (prestaasjes, beskikberens, flaters, ensfh.);
- applikaasje-ynfrastruktuernivo (host OS-metriken, JMX, MQ, webserver, ensfh.);
- platfoarmnivo (virtualisaasje, wolk, kontener, ensfh.).
Kontrolearje nivo's yn Dynatrace.
Twad, lykas ik earder sei, Dynatrace hat in iepen API, dy't it heul maklik makket om te yntegrearjen mei ferskate systemen fan tredden. Bygelyks, it ferstjoeren fan in notifikaasje nei it automatisearringssysteem as kontrôleparameters wurde oerskreaun.
Hjirûnder is in foarbyld foar ynteraksje mei Ansible.
Hjirûnder sil ik in pear foarbylden jaan fan hokker soarte automatisearring kin wurde dien. Dit is gewoan in diel fan 'e gefallen; har list yn jo omjouwing kin allinich wurde beheind troch jo ferbylding en de mooglikheden fan jo tafersjoch-ark.
1. Min ynset - ferzje rollback
Sels as wy alles tige goed testen yn in testomjouwing, is d'r noch in kâns dat in nije release jo applikaasje kin deadzje yn in produksjeomjouwing. Deselde minsklike faktor is net annulearre.
Yn 'e folgjende figuer sjogge wy dat d'r in skerpe sprong is yn' e útfieringstiid fan operaasjes op 'e tsjinst. It begjin fan dizze sprong komt oerien mei de tiid fan ynset nei de applikaasje. Wy stjoere al dizze ynformaasje as eveneminten oer nei it automatisearringssysteem. As de prestaasjes fan 'e tsjinst net werom nei normaal nei de tiid dy't wy ynsteld hawwe, dan wurdt automatysk in skript neamd dat de ferzje weromdraait nei de âlde.
Degradaasje fan operaasjeprestaasjes nei ynset.
2. Resource laden op 100% - foegje in knooppunt ta routing
Yn it folgjende foarbyld bepaalt it tafersjochsysteem dat ien fan 'e komponinten 100% CPU-load belibbet.
CPU load 100%
D'r binne ferskate ferskillende senario's mooglik foar dit evenemint. Bygelyks, it tafersjochsysteem kontrolearret ek oft it gebrek oan boarnen is ferbûn mei in tanimming fan 'e lading op' e tsjinst. As dat sa is, dan wurdt in skript útfierd dat automatysk in knooppunt taheakket oan de routing, en dêrmei de funksjonaliteit fan it systeem as gehiel weromsette.
Skaalfergrutting nei in ynsidint
3. Gebrek oan romte op 'e hurde skiif - skiif cleaning
Ik tink dat in protte minsken dizze prosessen al automatisearre hawwe. Mei APM kinne jo ek de frije romte kontrolearje op it skiifsubsysteem. As der gjin romte is of de skiif rint stadich, neame wy in skript om it skjin te meitsjen of romte ta te foegjen.
Skiif laden 100%
4. Lege brûkersaktiviteit of lege konverzje - wikselje tusken blauwe en griene tûken
Ik sjoch faak dat klanten twa loops brûke (blau-grien ynset) foar applikaasjes yn in produksjeomjouwing. Hjirmei kinne jo fluch wikselje tusken tûken by it leverjen fan nije releases. Faak kinne, nei ynset, dramatyske feroarings foarkomme dy't net daliks te merken binne. Yn dit gefal kin degradaasje yn prestaasjes en beskikberens net wurde waarnommen. Om fluch te reagearjen op sokke wizigingen, is it better om ferskate metriken te brûken dy't brûkersgedrach reflektearje (oantal sesjes en brûkersaksjes, konverzje, bounce rate). De folgjende figuer lit in foarbyld sjen wêryn, as konverzje tariven sakje, it wikseljen tusken softwaretûken foarkomt.
Konverzjetaryf sakket nei it wikseljen tusken softwaretûken.
Mechanismen foar automatyske probleemdeteksje
Uteinlik sil ik jo noch ien foarbyld jaan fan wêrom't ik Dynatrace it meast leuk fyn.
Yn it diel fan myn ferhaal oer it automatisearjen fan kwaliteitskontrôles fan gearstallingen yn in testomjouwing, hawwe wy alle drompelwearden manuell bepaald. Dit is normaal foar in testomjouwing; de tester sels bepaalt de yndikatoaren foar elke test ôfhinklik fan 'e lading. Yn in produksjeomjouwing is it winsklik dat problemen automatysk wurde ûntdutsen, rekken hâldend mei ferskate basismeganismen.
Dynatrace hat ynteressante ynboude ark foar keunstmjittige yntelliginsje dy't, basearre op meganismen foar it bepalen fan abnormale metriken (baselining) en it bouwen fan in kaart fan ynteraksje tusken alle komponinten, it fergelykjen en korrelearjen fan eveneminten mei elkoar, anomalies bepale yn 'e wurking fan jo tsjinst en detaillearre leverje ynformaasje oer elk probleem en root oarsaak.
Troch automatysk te analysearjen fan ôfhinklikens tusken komponinten, bepaalt Dynatrace net allinich oft de problematyske tsjinst de oarsaak is, mar ek de ôfhinklikens fan oare tsjinsten. Yn it foarbyld hjirûnder kontroleart en evaluearret Dynatrace automatysk de sûnens fan elke tsjinst binnen de útfiering fan transaksjes, en identifisearret de Golang-tsjinst as de root-oarsaak.
In foarbyld fan it bepalen fan de oarsaak fan in mislearring.
De folgjende figuer toant it proses fan tafersjoch op problemen mei jo applikaasje fan it begjin fan in ynsidint.
Fisualisaasje fan in opkommende probleem mei werjefte fan alle komponinten en eveneminten derop
It tafersjochsysteem sammele in folsleine gronology fan eveneminten yn ferbân mei it probleem dat ûntstie. Yn it finster ûnder de tiidline sjogge wy alle wichtige eveneminten op elk fan 'e komponinten. Op grûn fan dizze eveneminten kinne jo prosedueres ynstelle foar automatyske korreksje yn 'e foarm fan koadeskripts.
Derneist advisearje ik jo om in tafersjochsysteem te yntegrearjen mei Service Desk as in bug tracker. As in probleem optreedt, ûntfange ûntwikkelders fluch folsleine ynformaasje om it te analysearjen op koadenivo yn 'e produksjeomjouwing.
konklúzje
As gefolch, wy einige mei in CI / CD pipeline mei ynboude automatisearre software kwaliteit kontrôles yn Pipeline. Wy minimalisearje it oantal assemblies fan lege kwaliteit, ferheegje de betrouberens fan it systeem as gehiel, en as ús systeem noch mislearret, lansearje wy meganismen om it te herstellen.
It is perfoarst de muoite wurdich te ynvestearjen yn it automatisearjen fan softwarekwaliteitsmonitoring; it is net altyd in fluch proses, mar oer de tiid sil it frucht drage. Ik advisearje dat jo nei it oplossen fan in nij ynsidint yn 'e produksjeomjouwing daliks tinke oer hokker monitors jo moatte tafoegje foar kontrôles yn' e testomjouwing om te foarkommen dat in minne build yn produksje komt, en ek in skript meitsje om dizze problemen automatysk te korrigearjen.
Ik hoopje dat myn foarbylden jo sille helpe yn jo ynspanningen. Ik sil ek ynteressearre wêze om jo foarbylden te sjen fan metriken dy't brûkt wurde om selshealingsystemen te ymplementearjen.
Boarne: www.habr.com