Nou is die onderwerp van DevOps op die hype. Deurlopende integrasie en afleweringspyplyn implementeer alles en nog wat. Maar die meeste skenk nie altyd die nodige aandag daaraan om die betroubaarheid van inligtingstelsels in verskeie stadiums van die CI/CD-pyplyn te verseker nie. In hierdie artikel wil ek graag praat oor my ervaring in die outomatisering van sagtewarekwaliteitkontroles en die implementering van moontlike scenario's vir die "selfgenesing daarvan".
Ek werk as 'n ingenieur in die IT-diensbestuursafdeling van 'n maatskappy . My profielrigting is die implementering van verskeie stelsels vir die monitering van die werkverrigting en beskikbaarheid van toepassings. Ek kommunikeer dikwels met IT-kliënte van verskillende marksegmente oor aktuele kwessies wat verband hou met die monitering van die kwaliteit van hul IT-dienste. Die hooftaak is om die vrystellingsiklustyd te verminder en die frekwensie van hul vrystelling te verhoog. Dit is natuurlik alles goed: meer vrystellings - meer nuwe funksies - meer tevrede gebruikers - meer wins. Maar in werklikheid werk dinge nie altyd goed uit nie. Met baie hoë ontplooiingskoerse duik die vraag oor die kwaliteit van ons vrystellings dadelik op. Selfs met 'n ten volle outomatiese pyplyn, is een van die grootste uitdagings om dienste van toetsing na produksie te verskuif sonder om uptyd en gebruikersinteraksie met die toepassing te beïnvloed.
Gebaseer op die resultate van talle gesprekke met kliënte, kan ek sê dat vrystelling kwaliteit beheer, die probleem van toepassing betroubaarheid en die moontlikheid van sy "self-genesing" (byvoorbeeld, rol terug na 'n stabiele weergawe) in verskeie stadiums van die CI / CD-pyplyn is van die mees opwindende en relevante onderwerpe.
Onlangs het ek self aan die kliëntekant gewerk – in die instandhoudingsdiens vir aanlynbanktoepassingsprogrammatuur. Die argitektuur van ons toepassing het 'n groot aantal selfgeskrewe mikrodienste gebruik. Die hartseerste is dat nie alle ontwikkelaars die hoë tempo van ontwikkeling kon hanteer nie, die kwaliteit van sommige mikrodienste wat gely het, wat aanleiding gegee het tot snaakse byname vir hulle en hul skeppers. Verhale het verskyn oor watter materiale hierdie produkte gemaak is.
"Formulering van die probleem"
Die hoë frekwensie van vrystellings en 'n groot aantal mikrodienste maak dit moeilik om die werking van die toepassing as geheel te verstaan, beide in die toetsstadium en in die operasionele stadium. Veranderinge gebeur heeltyd en dit is baie moeilik om dit te beheer sonder goeie moniteringsinstrumente. Dikwels, na 'n nagtelike vrystelling in die oggend, sit ontwikkelaars soos op 'n kruitvat en wag vir niks om te breek nie, hoewel alle kontroles in die toetsstadium suksesvol was.
Daar is nog een punt. Tydens die toetsfase word die funksionaliteit van die sagteware nagegaan: die prestasie van die hooffunksies van die toepassing en die afwesigheid van foute. Kwalitatiewe prestasieskattings ontbreek of neem nie alle aspekte van die toepassing en die integrasielaag in ag nie. Sommige maatstawwe word dalk glad nie nagegaan nie. As gevolg hiervan, as 'n onklaarraking in 'n produksie-omgewing plaasvind, sal die tegniese ondersteuningsafdeling eers daarvan weet wanneer regte gebruikers begin kla. Ek wil die impak van lae-gehalte sagteware op eindgebruikers minimaliseer.
Een oplossing is om sagteware-gehalteversekeringsprosesse in verskeie stadiums van die CI / CD-pyplyn te implementeer, verskeie scenario's by te voeg vir stelselherstel in geval van ongelukke. Onthou ook dat ons DevOps het. Die besigheid verwag om so vinnig as moontlik 'n nuwe produk te kry. Daarom moet al ons tjeks en skrifte geoutomatiseer word.
Die taak is in twee dele verdeel:
- gehaltebeheer van samestellings tydens die toetsstadium (om die proses om lae-gehalte samestellings te vang te outomatiseer);
- sagteware kwaliteitbeheer in die produksie-omgewing (meganismes vir outomatiese opsporing van probleme en moontlike scenario's vir hul selfgenesing).
Gereedskap vir die monitering en insameling van statistieke
Om die gestelde doelwitte te verwesenlik, word 'n moniteringstelsel vereis wat probleme kan opspoor en dit aan outomatiseringstelsels kan rapporteer op verskeie stadiums van die CI / CD-pyplyn. Dit sal ook positief wees as hierdie stelsel nuttige maatstawwe vir verskeie spanne verskaf: ontwikkeling, toetsing, bedryf. En dit is absoluut wonderlik, as dit vir besigheid is.
Om metrieke in te samel, kan jy 'n kombinasie van verskillende stelsels gebruik (Prometheus, ELK Stack, Zabbix, ens.), maar na my mening is APM-klasoplossings die beste geskik vir hierdie take (), wat jou lewe baie kan vereenvoudig.
As deel van my werk in instandhouding, het ek 'n soortgelyke projek begin doen deur Dynatrace se APM-klasoplossing te gebruik. Nou, as ek in 'n integrator werk, ken ek die mark van moniteringstelsels redelik goed. My subjektiewe mening: Dynatrace is die beste geskik vir sulke take.
Die Dynatrace-oplossing bied 'n horisontale vertoning van elke gebruikeroperasie met 'n diep korreligheid tot op die vlak van kode-uitvoering. Jy kan die hele ketting van interaksie tussen verskeie inligtingsdienste naspoor: van die vlakke van front-end web en mobiele toepassings, back-end toepassingsbedieners, die integrasiebus tot 'n spesifieke oproep na die databasis.
. Outomatiese bou van alle afhanklikhede tussen stelselkomponente
. Outomatiese opsporing en konstruksie van die diensoperasiepad
Onthou ook dat ons met verskeie outomatiseringsinstrumente moet integreer. Hier het die oplossing 'n gerieflike API waarmee u verskeie maatstawwe en gebeurtenisse kan stuur en ontvang.
Kom ons gaan dan verder na 'n meer gedetailleerde oorweging van hoe om die take wat met die Dynatrace-stelsel gestel is, op te los.
Taak 1. Outomatisering van gehaltebeheer van samestellings by die toetsstadium
Die eerste taak is om probleme so vroeg as moontlik in die stadiums van die aansoekleweringspyplyn te vind. Slegs "goeie" kodebou moet die produksie-omgewing bereik. Om dit te doen, moet bykomende monitors in jou pyplyn ingesluit word tydens die toetsstadium om die kwaliteit van jou dienste na te gaan.
Kom ons oorweeg stap vir stap hoe om dit te implementeer en hierdie proses te outomatiseer:
Die figuur toon die vloei van outomatiese sagteware-gehalteversekeringstappe:
- ontplooiing van 'n moniteringstelsel (installering van agente);
- bepaling van gebeure vir die beoordeling van die kwaliteit van jou sagteware (metrieke en drempels) en oordrag daarvan na die moniteringstelsel;
- generering van vrag- en werkverrigtingtoetse;
- die insameling van data oor prestasie en beskikbaarheid in die moniteringstelsel;
- oordrag van toetsdata gebaseer op sagteware kwaliteit assesseringsgebeurtenisse vanaf die moniteringstelsel na die CI/CD-stelsel. Outomatiese ontleding van samestellings.
Stap 1. Ontplooi die moniteringstelsel
Eerstens moet jy die agente in jou toetsomgewing installeer. Terselfdertyd het die Dynatrace-oplossing 'n goeie kenmerk - dit gebruik die OneAgent universele agent, wat op die OS-instansie geïnstalleer is (Windows, Linux, AIX), bespeur outomaties jou dienste en begin moniteringsdata daaroor insamel. Jy hoef nie 'n agent vir elke proses afsonderlik op te stel nie. ’n Soortgelyke situasie sal vir wolk- en houerplatforms wees. Terselfdertyd kan u ook die proses van installering van agente outomatiseer. Dynatrace pas perfek in die konsep van "infrastruktuur as kode" (): daar is klaargemaakte skrifte en instruksies vir alle gewilde platforms. Jy bed die agent in jou dienskonfigurasie in, en wanneer jy dit ontplooi, kry jy dadelik 'n nuwe diens met 'n reeds lopende agent.
Stap 2. Definieer jou sagteware kwaliteit assessering gebeure
Nou moet jy besluit oor die lys van dienste en sakebedrywighede. Dit is belangrik om presies daardie gebruikersbedrywighede in ag te neem wat sake-kritiek vir jou diens is. Hier beveel ek aan om met sake- en stelselontleders te konsulteer.
Vervolgens moet jy bepaal watter maatstawwe jy vir elke vlak by die resensie wil insluit. Dit kan byvoorbeeld uitvoeringstyd wees (verdeel in gemiddeld, mediaan, persentiele, ens.), foute (logies, diens, infrastruktuur, ens.) en verskeie infrastruktuurmaatstawwe (geheuehoop, vullisverwyderaar, draadtelling, ens.).
Vir outomatisering en gebruiksgemak deur die DevOps-span, kom die konsep van "Monitoring as Code" na vore. Wat ek hiermee bedoel, is dat 'n ontwikkelaar/toetser 'n eenvoudige JSON-lêer kan skryf wat die QA-metrieke vir die sagteware definieer.
Kom ons kyk na 'n voorbeeld van so 'n JSON-lêer. Voorwerpe van die Dynatrace API word as 'n sleutel/waarde-paar gebruik (API-beskrywing kan hier gevind word ).
{
"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
}
]
}Die lêer is 'n reeks tydreeksdefinisies (tydreekse):
- timeseriesId - die maatstaf om byvoorbeeld reaksietyd, fouttelling, geheue gebruik, ens. na te gaan;
- samevoeging - die vlak van samevoeging van metrieke, in ons geval gem., maar u kan enige gebruik wat u benodig (gemiddeld, min, maksimum, som, telling, persentiel);
- tags – objek tag in die moniteringstelsel, of jy kan 'n spesifieke objek identifiseerder spesifiseer;
- ernstig en waarskuwing - hierdie aanwysers reguleer die drempelwaardes van ons statistieke, as die waarde van die toetse die ernstige drempel oorskry, word ons samestelling as onsuksesvol gemerk.
Die volgende figuur toon 'n voorbeeld van die gebruik van sulke asblikke.
Stap 3. Laai Generasie
Nadat ons die gehaltevlakke van ons diens bepaal het, moet ons 'n toetslading genereer. Jy kan enige van die toetsinstrumente gebruik wat vir jou gerieflik is, soos Jmeter, Selenium, Neotys, Gatling, ens.
Die Dynatrace-moniteringstelsel laat jou toe om verskeie metadata van jou toetse vas te vang en te herken watter toets tot watter vrystellingsiklus en watter diens behoort. Dit word aanbeveel om bykomende opskrifte by te voeg om HTTP-versoeke te toets.
Die volgende figuur toon 'n voorbeeld waar ons 'n addisionele X-Dynatrace-Test-opskrif gebruik om te merk dat hierdie toets verband hou met die toets van 'n add-to-cart-bewerking.
Wanneer jy elke lastoets uitvoer, stuur jy addisionele kontekstuele inligting na Dynatrace met behulp van die gebeurtenis-API vanaf die CI/CD-bediener. Die stelsel kan dus tussen verskillende toetse onderskei.
. Gebeurtenis in die moniteringstelsel oor die bekendstelling van vragtoetsing
Stap 4-5. Vang prestasiedata vas en dra data oor na die CI/CD-stelsel
Saam met die gegenereerde toets word 'n gebeurtenis oor die behoefte om data in te samel oor die kontrolering van diensgehalte-aanwysers na die moniteringstelsel oorgedra. Dit spesifiseer ook ons JSON-lêer, wat sleutelmaatstawwe definieer.
Gebeurtenis oor die behoefte om die kwaliteit van sagteware wat op die CI / CD-bediener gegenereer word, na te gaan om na die moniteringstelsel te stuur
In ons voorbeeld word die kwaliteitkontrole-gebeurtenis genoem perfSigDynatraceReport (Prestasie_Handtekening) - dit is gereed vir integrasie met Jenkins, wat ontwikkel is deur die ouens van T-Systems Multimedia Solutions. Elke toetsbekendstellingsgeleentheid bevat inligting oor die diens, bounommer en toetstyd. Die inprop versamel prestasiewaardes tydens 'n bou, evalueer dit en vergelyk die resultaat met vorige bouwerk en nie-funksionele vereistes.
'n Gebeurtenis in die moniteringstelsel oor die begin van 'n boukwaliteitkontrole.
Nadat die toets voltooi is, word alle sagteware kwaliteit assessering maatstawwe teruggeplaas na 'n deurlopende integrasiestelsel, byvoorbeeld Jenkins, wat 'n verslag oor die resultate genereer.
Die resultaat van boustatistieke op die CI/CD-bediener.
Vir elke individuele bouwerk sien ons statistieke vir elke maatstaf wat ons deur die hele toets instel. Ons sien ook of daar oortredings in sekere drempels (waarskuwing en ernstige asblikke) was. Op grond van die kumulatiewe tellings word die hele bou gemerk as Stabiel, Onstabiel of Misluk. Ook, vir gerief, kan jy aanwysers van vergelyking van die huidige vergadering met die vorige een by die verslag voeg.
Bekyk gedetailleerde statistieke oor geboue op die CI/CD-bediener.
Gedetailleerde vergelyking van twee geboue
Indien nodig, kan jy na die Dynatrace-koppelvlak gaan en die statistieke vir elkeen van jou bouwerk in meer besonderhede bekyk en dit met mekaar vergelyk.
Vergelyking van boustatistieke in Dynatrace.
Bevindinge
As gevolg hiervan, kry ons die "monitering as 'n diens" diens, outomaties in die deurlopende integrasie pyplyn. 'n Ontwikkelaar of toetser hoef net 'n lys metrieke in 'n JSON-lêer te definieer, en alles anders gebeur outomaties. Ons kry deursigtige gehaltebeheer van vrystellings: alle kennisgewings oor werkverrigting, hulpbronverbruik of argitektoniese regressies.
Taak 2. Outomatisering van sagteware kwaliteitbeheer in die produksie-omgewing
Dus, ons het die probleem opgelos hoe om die moniteringsproses in die toetsstadium in Pipeline te outomatiseer. Op hierdie manier verminder ons die persentasie lae-gehalte bouwerk wat die produksie-omgewing bereik.
Maar wat om te doen as slegte sagteware steeds die mark bereik, of iets net breek. Vir 'n utopie wou ons meganismes hê om probleme outomaties op te spoor en, indien moontlik, het die stelsel self sy werkverrigting herstel, ten minste snags.
Om dit te doen, in analogie met die vorige afdeling, moet ons outomatiese sagteware-gehaltekontroles in die produksie-omgewing verskaf en skrifte vir stelselselfgenesing daaronder lê.
Outokorrigeer as kode
Die meeste maatskappye het reeds 'n opgehoopte kennisbasis van verskeie soorte algemene probleme en 'n lys van aksies om dit reg te stel, soos om prosesse te herbegin, hulpbronne skoon te maak, weergawes terug te rol, verkeerde konfigurasieveranderinge te herstel, die aantal komponente in 'n cluster, skakel blou of groen buitelyn, en ander
Alhoewel hierdie gebruiksgevalle al jare lank bekend is aan baie van die spanne met wie ek praat, het min daaraan gedink en daarin belê om dit te outomatiseer.
As u daaraan dink, is daar niks baie ingewikkeld in die implementering van selfgenesingsprosesse vir die gesondheid van die toepassing nie, u moet die reeds bekende werkscenario's van u administrateurs in die vorm van kodeskrifte aanbied (die konsep van "outokorreksie" as kode”) wat jy vooraf vir elke spesifieke geval geskryf het. Outomatiese regstellingsskrifte moet daarop fokus om die hoofoorsaak van die probleem op te los. Jy bepaal die korrekte insidentreaksie-aksies.
Enige maatstaf van jou moniteringstelsel kan dien as 'n sneller om die skrip te laat loop, die belangrikste ding is dat hierdie maatstawwe akkuraat bepaal dat alles sleg is, aangesien jy nie vals positiewes in 'n produktiewe omgewing wil kry nie.
Jy kan enige stelsel of kombinasie van stelsels gebruik: Prometheus, ELK Stack, Zabbix, ens. Maar ek sal 'n paar voorbeelde gee gebaseer op die APM-oplossing (weereens Dynatrace sal 'n voorbeeld wees) wat ook sal help om jou lewe makliker te maak.
Eerstens is daar alles wat verband hou met gesondheid in terme van toepassingswerking. Die oplossing bied honderde statistieke op verskillende vlakke wat u as snellers kan gebruik:
- gebruikersvlak (blaaiers, mobiele toepassings, IoT-toestelle, gebruikersgedrag, omskakeling, ens.);
- vlak van diens en bedrywighede (prestasie, beskikbaarheid, foute, ens.);
- toepassingsinfrastruktuurlaag (gasheerbedryfstelselstatistieke, JMX, MQ, webbediener, ens.);
- platformvlak (virtualisering, wolk, houer, ens.).
Monitering van vlakke in Dynatrace.
Tweedens, soos ek vroeër gesê het, het Dynatrace 'n oop API, wat dit baie gerieflik maak om dit met verskeie derdeparty-stelsels te integreer. Byvoorbeeld, die stuur van 'n kennisgewing aan die outomatiseringstelsel wanneer beheerparameters oorskry word.
Hieronder is 'n voorbeeld vir interaksie met Ansible.
Hieronder sal ek 'n paar voorbeelde gee van watter soort outomatisering gedoen kan word. Dit is net 'n deel van die gevalle, hul lys in jou omgewing word dalk net deur jou verbeelding en die vermoëns van jou moniteringsinstrumente beperk.
1. Slegte ontplooiing - weergawe terugrol
Selfs al toets ons alles baie goed in 'n toetsomgewing, is daar steeds 'n kans dat 'n nuwe vrystelling jou toepassing in 'n produksie-omgewing kan doodmaak. Dieselfde menslike faktor is nie gekanselleer nie.
In die volgende figuur sien ons dat daar 'n skerp sprong is in die uitvoeringstyd van bedrywighede op die diens. Die begin van hierdie sprong val saam met die ontplooiingstyd vir die toepassing. Ons gee al hierdie inligting as gebeurtenisse deur na die outomatiseringstelsel. As die diens nie na normaal terugkeer na die tyd wat ons gespesifiseer het nie, word 'n skrip outomaties genoem wat die weergawe na die ou een terugrol.
Bedryfsprestasie agteruitgang na ontplooiing.
2. Laai hulpbronne onder 100% - voeg 'n nodus by die roetering
In die volgende voorbeeld bepaal die moniteringstelsel dat een van die komponente 100% SVE-benutting ervaar.
SVE gebruik 100%
Daar is verskeie moontlike scenario's vir hierdie gebeurtenis. Byvoorbeeld, die moniteringstelsel kontroleer ook of die gebrek aan hulpbronne geassosieer word met 'n toename in die las op die diens. Indien wel, word 'n skrip uitgevoer wat outomaties 'n nodus by die roete voeg, en sodoende die stelsel as geheel herstel.
Onderskaal ná die voorval
3. Geen hardeskyfspasie nie - Skyfskoonmaak
Ek dink dat baie van hierdie prosesse reeds geoutomatiseer is. Met behulp van APM kan u ook die vrye spasie op die skyfsubstelsel monitor. In die afwesigheid van spasie of stadige skyfwerking, roep ons die skrif om skoon te maak of spasie by te voeg.
Skyf laai 100%
4. Lae gebruikeraktiwiteit of lae omskakeling - skakel tussen blou en groen tak
Ek sien gereeld dat klante twee lusse (blou-groen ontplooiing) gebruik vir toepassings in 'n produksie-omgewing. Dit laat jou toe om vinnig tussen takke te wissel wanneer nuwe vrystellings afgelewer word. Dikwels, na die ontplooiing, kan kardinale veranderinge plaasvind wat nie onmiddellik opmerklik is nie. Terselfdertyd kan agteruitgang in prestasie en beskikbaarheid nie waargeneem word nie. Om vinnig op sulke veranderinge te reageer, is dit beter om verskeie maatstawwe te gebruik wat gebruikersgedrag weerspieël (aantal sessies en gebruikeraksies, omskakeling, weieringkoers). Die volgende figuur toon 'n voorbeeld waarin 'n omskakeling tussen sagtewaretakke plaasvind wanneer 'n omskakeling val.
Daling in omskakeling na oorskakeling tussen sagteware takke.
Outomatiese probleemopsporingsmeganismes
Aan die einde sal ek nog een voorbeeld gee, waarvoor ek die meeste van Dynatrace hou.
In die deel van my storie oor die outomatisering van die kwaliteitskontrole van samestellings in 'n toetsomgewing, het ons al die drempelwaardes met die hand bepaal. Vir 'n toetsomgewing is dit normaal, die toetser bepaal self die aanwysers voor elke kontrole, afhangende van die vrag. In 'n produksie-omgewing is dit wenslik dat probleme outomaties opgespoor word, met inagneming van die verskillende basislynmeganismes.
Dynatrace het interessante ingeboude kunsmatige intelligensie-instrumente wat, gebaseer op die meganismes vir die bepaling van anomale metrieke (basislyn) en die bou van 'n interaksiekaart tussen alle komponente, vergelyking en korrelasie van gebeure met mekaar, onreëlmatighede in u diens bepaal en gedetailleerde inligting oor elkeen verskaf. probleem en oorsaak.
Deur outomaties afhanklikhede tussen komponente te ontleed, bepaal Dynatrace nie net of 'n problematiese diens die hoofoorsaak is nie, maar ook die afhanklikheid daarvan van ander dienste. In die voorbeeld hieronder monitor en evalueer Dynatrace outomaties die gesondheid van elke diens as deel van die transaksie, identifiseer die Golang-diens as die hoofoorsaak.
'n Voorbeeld van die bepaling van die hoofoorsaak van 'n mislukking.
Die volgende figuur toon die proses van monitering van probleme met jou aansoek vanaf die begin van 'n voorval.
Visualisering van die opkomende probleem met die vertoon van alle komponente en gebeurtenisse daarop
Die moniteringstelsel het 'n volledige chronologie van gebeure versamel oor die probleem wat ontstaan het. In die venster onder die tydlyn sien ons al die sleutelgebeurtenisse op elk van die komponente. Op grond van hierdie gebeure kan u prosedures vir outomatiese regstelling in die vorm van kodeskrifte stel.
Verder raai ek jou aan om 'n moniteringstelsel met Service Desk of 'n foutspoorder te integreer. As 'n probleem voorkom, ontvang ontwikkelaars vinnig volledige inligting vir die ontleding daarvan op die kodevlak in die produksie-omgewing.
Gevolgtrekking
As gevolg hiervan, het ons 'n CI / CD-pyplyn met ingeboude outomatiese sagteware kwaliteitkontroles in Pipeline. Ons verminder die aantal lae-gehalte samestellings, verhoog die betroubaarheid van die stelsel as geheel, en as ons steeds 'n stelsel wanfunksie het, begin ons meganismes om dit te herstel.
Dit is beslis die moeite werd om in die outomatisering van sagtewarekwaliteitmonitering te belê, dit is nie altyd 'n vinnige proses nie, maar mettertyd sal dit vrugte afwerp. Ek beveel aan dat jy, nadat jy 'n nuwe voorval in die produksie-omgewing opgelos het, dadelik moet dink oor watter monitors om by te voeg vir kontrole in die toetsomgewing om te verhoed dat 'n slegte bou in produksie kom, en ook 'n script skep om hierdie probleme outomaties reg te stel.
Ek hoop dat my voorbeelde jou sal help in jou pogings. Ek sal ook belangstel om jou voorbeelde te sien van maatstawwe wat gebruik word om selfgenesende stelselgesondheid te implementeer.
Bron: will.com