Nu er emnet DevOps på hype. Kontinuerlig integration og leveringspipeline alle implementerer det. Men de fleste er ikke altid opmærksomme på at sikre pålideligheden af informationssystemerne på forskellige stadier af CI/CD-pipelinen. I denne artikel vil jeg gerne fortælle om min erfaring med at automatisere softwarekvalitetstjek og implementere mulige scenarier for dets "selvhelbredelse".
Jeg arbejder som ingeniør i en virksomheds IT service management afdeling . Mit kerneområde af ekspertise er implementering af forskellige applikationsydelses- og tilgængelighedsovervågningssystemer. Jeg kommunikerer ofte med IT-kunder fra forskellige markedssegmenter vedrørende aktuelle problemstillinger vedrørende overvågning af kvaliteten af deres IT-tjenester. Hovedmålet er at minimere udgivelsescyklustiden og øge frekvensen af udgivelser. Dette er selvfølgelig alt sammen godt: flere udgivelser - flere nye funktioner - mere tilfredse brugere - mere overskud. Men i virkeligheden fungerer tingene ikke altid godt. Med meget høje implementeringsrater opstår spørgsmålet med det samme om kvaliteten af vores udgivelser. Selv med en fuldt automatiseret pipeline er en af de største udfordringer at flytte tjenester fra test til produktion uden at påvirke applikationens oppetid og brugeroplevelse.
Baseret på resultaterne af talrige samtaler med kunder kan jeg sige, at kvalitetskontrol af frigivelsen, problemet med applikationspålidelighed og muligheden for dens "selvhelbredende" (for eksempel rulle tilbage til en stabil version) på forskellige stadier af CI /CD pipeline er blandt de mest spændende og relevante emner.
For nylig arbejdede jeg selv på kundesiden - i netbankapplikationssoftwaresupporttjenesten. Arkitekturen af vores applikation brugte et stort antal selvskrevne mikrotjenester. Det mest sørgelige er, at ikke alle udviklere kunne klare det høje udviklingstempo; kvaliteten af nogle mikrotjenester led, hvilket gav anledning til sjove kaldenavne for dem og deres skabere. Der var historier om, hvilke materialer disse produkter var lavet af.
"Formulering af problemet"
Den høje frekvens af udgivelser og et stort antal mikrotjenester gør det vanskeligt at forstå driften af applikationen som helhed, både på teststadiet og på driftsstadiet. Ændringer sker konstant, og det er meget svært at kontrollere dem uden gode overvågningsværktøjer. Ofte, efter en natudgivelse om morgenen, sidder udviklere som på en krudttønde og venter på, at intet går i stykker, selvom alle kontroller var succesfulde på teststadiet.
Der er en pointe mere. På teststadiet kontrolleres softwarens funktionalitet: implementeringen af applikationens hovedfunktioner og fraværet af fejl. Kvalitative præstationsvurderinger mangler enten eller tager ikke højde for alle aspekter af applikationen og integrationslaget. Nogle metrics kontrolleres muligvis slet ikke. Som et resultat, når der opstår et nedbrud i et produktionsmiljø, finder den tekniske supportafdeling først ud af det, når rigtige brugere begynder at klage. Jeg vil gerne minimere virkningen af lavkvalitetssoftware på slutbrugere.
En af løsningerne er at implementere processer til kontrol af softwarekvalitet på forskellige stadier af CI/CD Pipeline, og tilføje forskellige scenarier til gendannelse af systemet i tilfælde af en nødsituation. Vi husker også, at vi har DevOps. Virksomheder forventer at modtage et nyt produkt så hurtigt som muligt. Derfor skal alle vores checks og scripts automatiseres.
Opgaven er opdelt i to dele:
- kvalitetskontrol af samlinger på teststadiet (for at automatisere processen med at fange samlinger af lav kvalitet);
- softwarekvalitetskontrol i produktionsmiljøet (mekanismer til automatisk registrering af problemer og mulige scenarier for deres selvhelbredelse).
Værktøj til overvågning og indsamling af metrics
For at nå de opstillede mål kræves et overvågningssystem, der kan detektere problemer og overføre dem til automatiseringssystemer på forskellige stadier af CI/CD-pipelinen. Det vil også være positivt, hvis dette system giver nyttige målinger til forskellige teams: udvikling, test, drift. Og det er helt vidunderligt, hvis det også er for erhvervslivet.
For at indsamle metrics kan du bruge et sæt forskellige systemer (Prometheus, ELK Stack, Zabbix osv.), men efter min mening er APM-klasse løsninger bedst egnede til disse opgaver (), hvilket i høj grad kan forenkle dit liv.
Som en del af mit arbejde i supporttjenesten begyndte jeg at lave et lignende projekt ved hjælp af en APM-klasseløsning fra Dynatrace. Nu, hvor jeg arbejder for en integrator, kender jeg markedet for overvågningssystemer ret godt. Min subjektive mening: Dynatrace er bedst egnet til at løse sådanne problemer.
Dynatrace giver en horisontal visning af hver brugerhandling på et granulært niveau ned til kodeudførelsesniveauet. Du kan spore hele kæden af interaktion mellem forskellige informationstjenester: fra front-end-niveauerne af web- og mobilapplikationer, back-end-applikationsservere, integrationsbus til et specifikt opkald til databasen.
. Automatisk opbygning af alle afhængigheder mellem systemkomponenter
. Automatisk detektering og konstruktion af servicedriftsstien
Vi husker også, at vi skal integrere med forskellige automatiseringsværktøjer. Her har løsningen en praktisk API, der giver dig mulighed for at sende og modtage forskellige metrics og begivenheder.
Lad os derefter gå videre til et mere detaljeret kig på, hvordan man løser disse problemer ved hjælp af Dynatrace-systemet.
Opgave 1. Automatisering af kvalitetskontrol af samlinger på teststadiet
Den første udfordring er at finde problemer så tidligt som muligt i applikationsleveringspipelinen. Kun "gode" kodebygninger bør nå produktion. For at gøre dette bør din pipeline på teststadiet omfatte yderligere skærme for at kontrollere kvaliteten af dine tjenester.
Lad os tage et trin-for-trin kig på, hvordan man implementerer dette og automatiserer denne proces:
Figuren viser strømmen af automatiske softwarekvalitetstesttrin:
- implementering af et overvågningssystem (installation af agenter);
- identifikation af hændelser til vurdering af kvaliteten af din software (metrics og tærskelværdier) og overførsel af dem til overvågningssystemet;
- generering af belastnings- og ydeevnetest;
- indsamling af præstations- og tilgængelighedsdata i overvågningssystemet;
- overførsel af testdata baseret på softwarekvalitetsvurderingshændelser fra overvågningssystemet til CI/CD-systemet. Automatisk analyse af samlinger.
Trin 1. Implementering af overvågningssystemet
Først skal du installere agenterne i dit testmiljø. Samtidig har Dynatrace-løsningen en fin funktion - den bruger den universelle agent OneAgent, som er installeret på en OS-instans (Windows, Linux, AIX), registrerer automatisk dine tjenester og begynder at indsamle overvågningsdata på dem. Du behøver ikke at konfigurere en separat agent for hver proces. Situationen vil være den samme for cloud- og containerplatforme. Samtidig kan du også automatisere agentinstallationsprocessen. Dynatrace passer perfekt ind i "infrastruktur som kode"-konceptet (): Der er færdige scripts og instruktioner til alle populære platforme. Du integrerer agenten i konfigurationen af din tjeneste, og når du implementerer den, modtager du straks en ny tjeneste med en allerede fungerende agent.
Trin 2: Definer dine softwarekvalitetsbegivenheder
Nu skal du beslutte dig for listen over tjenester og forretningsdrift. Det er vigtigt at tage højde for netop de brugeroperationer, der er forretningskritiske for din service. Her anbefaler jeg at rådføre sig med forretnings- og systemanalytikere.
Dernæst skal du bestemme, hvilke metrics du vil inkludere i anmeldelsen for hvert niveau. Det kan for eksempel være eksekveringstid (opdelt i gennemsnit, median, percentiler osv.), fejl (logiske, service, infrastruktur osv.) og forskellige infrastrukturmetrikker (hukommelsesbunke, skraldopsamler, trådantal osv.).
For automatisering og brugervenlighed for DevOps-teamet vises konceptet "Overvågning som kode". Hvad jeg mener med dette er, at en udvikler/tester kan skrive en simpel JSON-fil, der definerer softwarekvalitetssikringsmålinger.
Lad os se på et eksempel på sådan en JSON-fil. Objekter fra Dynatrace API'et bruges som nøgle/værdi-par (API-beskrivelse kan findes her ).
{
"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
}
]
}Filen er en række tidsseriedefinitioner:
- timesseriesId – den metrik, der kontrolleres, for eksempel responstid, fejlantal, brugt hukommelse osv.;
- aggregering - niveau for metrics aggregering, i vores tilfælde avg, men du kan bruge enhver, du har brug for (gns., min, max, sum, count, percentil);
- tags – objektmærke i overvågningssystemet, eller du kan angive en specifik objektidentifikator;
- alvorlig og advarsel - disse indikatorer regulerer tærskelværdierne for vores målinger; hvis testværdien overstiger den alvorlige tærskel, så er vores build markeret som ikke vellykket.
Følgende figur viser et eksempel på brugen af sådanne tærskler.
Trin 3: Indlæsningsgenerering
Når vi har fastlagt kvalitetsniveauerne for vores service, skal vi generere en testbelastning. Du kan bruge ethvert af de testværktøjer, du er fortrolig med, såsom Jmeter, Selenium, Neotys, Gatling osv.
Dynatraces overvågningssystem giver dig mulighed for at fange forskellige metadata fra dine tests og genkende hvilke tests der hører til hvilken udgivelsescyklus og hvilken service. Det anbefales at tilføje yderligere overskrifter til HTTP-testanmodninger.
Den følgende figur viser et eksempel, hvor vi ved hjælp af den ekstra overskrift X-Dynatrace-Test angiver, at denne test relaterer sig til at teste operationen med at tilføje en vare til indkøbskurven.
Når du kører hver belastningstest, sender du yderligere kontekstuelle oplysninger til Dynatrace ved hjælp af Event API fra CI/CD-serveren. På den måde kan systemet skelne mellem forskellige tests.
. Hændelse i overvågningssystemet om start af belastningstest
Trin 4-5. Indsaml ydeevnedata og overfør data til CI/CD-systemet
Sammen med den genererede test sendes en hændelse til overvågningssystemet om behovet for at indsamle data om kontrol af servicekvalitetsindikatorer. Den specificerer også vores JSON-fil, som definerer nøglemålingerne.
Begivenhed om behovet for at kontrollere kvaliteten af software genereret på CI/CD-serveren til afsendelse til overvågningssystemet
I vores eksempel kaldes kvalitetstjekhændelsen perfSigDynatraceReport (Performance_Signatur) - den er klar til integration med Jenkins, som blev udviklet af fyrene fra T-Systems Multimedia Solutions. Hver testlanceringsbegivenhed indeholder oplysninger om tjenesten, buildnummer og testtid. Pluginnet indsamler ydeevneværdier på byggetidspunktet, evaluerer dem og sammenligner resultatet med tidligere builds og ikke-funktionelle krav.
Hændelse i overvågningssystemet om starten af et byggekvalitetstjek.
Efter testen er gennemført, overføres alle målinger til vurdering af softwarekvalitet tilbage til et kontinuerligt integrationssystem, for eksempel Jenkins, som genererer en rapport om resultaterne.
Resultatet af statistik over samlinger på CI/CD-serveren.
For hver enkelt build ser vi statistikker for hver metric, vi sætter gennem hele testen. Vi ser også, om der var overtrædelser af visse tærskelværdier (advarsel og alvorlige tærskelværdier). Baseret på samlede metrics markeres hele buildet som stabilt, ustabilt eller mislykket. For nemheds skyld kan du også tilføje indikatorer til rapporten, der sammenligner den nuværende build med den forrige.
Se detaljerede statistikker om samlinger på CI/CD-serveren.
Detaljeret sammenligning af to samlinger
Hvis det er nødvendigt, kan du gå til Dynatrace-grænsefladen, og der kan du se statistikken for hver af dine builds mere detaljeret og sammenligne dem med hinanden.
Sammenligning af byggestatistik i Dynatrace.
Fund
Som et resultat får vi en "monitoring as a service"-tjeneste, automatiseret i den kontinuerlige integrationspipeline. Udvikleren eller testeren behøver kun at definere en liste over metrics i en JSON-fil, og alt andet sker automatisk. Vi modtager gennemsigtig kvalitetskontrol af udgivelser: alle meddelelser om ydeevne, ressourceforbrug eller arkitektoniske regressioner.
Opgave 2. Automatisering af software kvalitetskontrol i et produktionsmiljø
Så vi har løst problemet med, hvordan man automatiserer overvågningsprocessen på teststadiet i Pipeline. På denne måde minimerer vi procentdelen af lavkvalitetssamlinger, der når produktionsmiljøet.
Men hvad skal man gøre, hvis dårlig software ender med at blive solgt, eller noget bare går i stykker. For en utopi ville vi have mekanismer til automatisk at opdage problemer og, hvis det var muligt, selve systemet til at genoprette dets funktionalitet, i det mindste om natten.
For at gøre dette skal vi, analogt med det foregående afsnit, sørge for automatiske kvalitetstjek af software i produktionsmiljøet og basere dem på scenarier for selvhelbredelse af systemet.
Autokorrektur som kode
De fleste virksomheder har allerede en akkumuleret videnbase om forskellige typer almindelige problemer og en liste over handlinger til at løse dem, f.eks. genstart af processer, oprydning af ressourcer, tilbagerulning af versioner, gendannelse af ugyldige konfigurationsændringer, forøgelse eller formindskelse af antallet af komponenter i klyngen, skifte den blå eller grønne kontur og osv.
Selvom disse use cases har været kendt i årevis af mange af de teams, jeg taler med, har få tænkt på eller investeret i at automatisere dem.
Hvis du tænker over det, er der intet alt for kompliceret i at implementere processer til selvhelbredende applikationsydelse; du skal præsentere de allerede kendte arbejdsscenarier for dine administratorer i form af kodescripts (konceptet "auto-fix som kode") , som du skrev på forhånd for hver konkret sag. Automatiske reparationsscripts bør sigte mod at eliminere årsagen til problemet. Du bestemmer selv de korrekte handlinger for at reagere på en hændelse.
Enhver metrik fra dit overvågningssystem kan fungere som en trigger til at starte scriptet, det vigtigste er, at disse målinger præcist bestemmer, at alt er dårligt, da du ikke ønsker at få falske positiver i et produktivt miljø.
Du kan bruge ethvert system eller sæt af systemer: Prometheus, ELK Stack, Zabbix osv. Men jeg vil give nogle eksempler baseret på en APM-løsning (Dynatrace bliver et eksempel igen), som også vil være med til at gøre dit liv lettere.
For det første er der alt relateret til ydeevne med hensyn til applikationsdrift. Løsningen giver hundredvis af metrics på forskellige niveauer, som du kan bruge som triggere:
- brugerniveau (browsere, mobilapplikationer, IoT-enheder, brugeradfærd, konvertering osv.);
- serviceniveau og drift (ydelse, tilgængelighed, fejl osv.);
- applikationsinfrastrukturniveau (værts-OS-metrics, JMX, MQ, web-server osv.);
- platformsniveau (virtualisering, cloud, container osv.).
Overvågningsniveauer i Dynatrace.
For det andet, som jeg sagde tidligere, har Dynatrace en åben API, som gør det meget nemt at integrere med forskellige tredjepartssystemer. For eksempel at sende en meddelelse til automatiseringssystemet, når kontrolparametre overskrides.
Nedenfor er et eksempel på interaktion med Ansible.
Nedenfor vil jeg give et par eksempler på, hvilken form for automatisering der kan udføres. Dette er kun en del af tilfældene; deres liste i dit miljø kan kun begrænses af din fantasi og dine overvågningsværktøjers muligheder.
1. Dårlig implementering – tilbagerulning af version
Selvom vi tester alt meget godt i et testmiljø, er der stadig en chance for, at en ny udgivelse kan dræbe din applikation i et produktionsmiljø. Den samme menneskelige faktor er ikke blevet annulleret.
I den følgende figur ser vi, at der er et kraftigt spring i udførelsestiden for operationer på tjenesten. Begyndelsen af dette spring falder sammen med tidspunktet for implementering til applikationen. Vi overfører alle disse oplysninger som hændelser til automatiseringssystemet. Hvis ydeevnen af tjenesten ikke vender tilbage til normal efter den tid, vi har sat, kaldes der automatisk et script, der ruller versionen tilbage til den gamle.
Forringelse af driftsydelsen efter implementering.
2. Ressourcebelastning på 100 % - føj en node til routing
I det følgende eksempel bestemmer overvågningssystemet, at en af komponenterne oplever 100 % CPU-belastning.
CPU belastning 100 %
Der er flere forskellige scenarier mulige for denne begivenhed. For eksempel kontrollerer overvågningssystemet desuden, om manglende ressourcer er forbundet med en stigning i belastningen på tjenesten. Hvis det er tilfældet, udføres et script, der automatisk tilføjer en node til routingen, og derved genoprette funktionaliteten af systemet som helhed.
Skalering efter en hændelse
3. Mangel på plads på harddisken - diskrensning
Jeg tror, at mange mennesker allerede har automatiseret disse processer. Ved hjælp af APM kan du også overvåge den ledige plads på diskens undersystem. Hvis der ikke er plads, eller disken kører langsomt, kalder vi et script for at rense det eller tilføje plads.
Diskbelastning 100 %
4. Lav brugeraktivitet eller lav konvertering - skift mellem blå og grønne grene
Jeg ser ofte kunder, der bruger to sløjfer (blå-grøn implementering) til applikationer i et produktionsmiljø. Dette giver dig mulighed for hurtigt at skifte mellem filialer, når du leverer nye udgivelser. Ofte kan der efter implementeringen opstå dramatiske ændringer, som ikke umiddelbart er mærkbare. I dette tilfælde kan forringelse af ydeevne og tilgængelighed muligvis ikke observeres. For hurtigt at reagere på sådanne ændringer er det bedre at bruge forskellige metrics, der afspejler brugeradfærd (antal sessioner og brugerhandlinger, konvertering, afvisningsprocent). Følgende figur viser et eksempel, hvor der, når konverteringsraterne falder, sker skift mellem softwaregrene.
Konverteringsraten falder efter skift mellem softwaregrene.
Mekanismer til automatisk problemdetektion
Til sidst vil jeg give dig endnu et eksempel på, hvorfor jeg bedst kan lide Dynatrace.
I den del af min historie om automatisering af kvalitetstjek af samlinger i et testmiljø, bestemte vi alle tærskelværdier manuelt. Dette er normalt for et testmiljø; testeren bestemmer selv indikatorerne før hver test afhængigt af belastningen. I et produktionsmiljø er det ønskeligt, at problemer opdages automatisk under hensyntagen til forskellige baseline-mekanismer.
Dynatrace har interessante indbyggede kunstig intelligens-værktøjer, der baseret på mekanismer til bestemmelse af unormale metrikker (baselining) og opbygning af et kort over interaktion mellem alle komponenter, sammenligner og korrelerer hændelser med hinanden, bestemmer uregelmæssigheder i driften af din tjeneste og giver detaljeret oplysninger om hvert problem og den grundlæggende årsag.
Ved automatisk at analysere afhængigheder mellem komponenter, afgør Dynatrace ikke kun, om den problematiske tjeneste er grundårsagen, men også dens afhængighed af andre tjenester. I eksemplet nedenfor overvåger og evaluerer Dynatrace automatisk tilstanden af hver tjeneste inden for transaktionsudførelsen, og identificerer Golang-tjenesten som hovedårsagen.
Et eksempel på at bestemme årsagen til en fejl.
Følgende figur viser processen med at overvåge problemer med din applikation fra starten af en hændelse.
Visualisering af et opstået problem med visning af alle komponenter og hændelser på dem
Overvågningssystemet indsamlede en komplet kronologi af hændelser relateret til det problem, der opstod. I vinduet under tidslinjen ser vi alle de vigtigste begivenheder på hver af komponenterne. På baggrund af disse hændelser kan du indstille procedurer for automatisk rettelse i form af kodescripts.
Derudover råder jeg dig til at integrere et overvågningssystem med Service Desk eller en fejlsporer. Når der opstår et problem, modtager udviklere hurtigt fuldstændig information for at analysere det på kodeniveau i produktionsmiljøet.
Konklusion
Som et resultat endte vi med en CI/CD-pipeline med indbygget automatiseret softwarekvalitetstjek i Pipeline. Vi minimerer antallet af lavkvalitetssamlinger, øger pålideligheden af systemet som helhed, og hvis vores system stadig svigter, lancerer vi mekanismer til at genoprette det.
Det er bestemt værd at investere kræfter i at automatisere softwarekvalitetsovervågning; det er ikke altid en hurtig proces, men over tid vil det bære frugt. Jeg anbefaler, at du efter at have løst en ny hændelse i produktionsmiljøet med det samme tænker over, hvilke skærme du skal tilføje til kontrol i testmiljøet for at undgå, at en dårlig build kommer i produktion, og også laver et script til automatisk at rette disse problemer.
Jeg håber, at mine eksempler vil hjælpe dig i dine bestræbelser. Jeg vil også være interesseret i at se dine eksempler på målinger, der bruges til at implementere selvhelbredende systemer.
Kilde: www.habr.com