Nu är ämnet DevOps på hype. Kontinuerlig integration och leveranspipeline alla implementerar det. Men de flesta uppmärksammar inte alltid informationssystemens tillförlitlighet i olika stadier av CI/CD-pipelinen. I den här artikeln skulle jag vilja prata om min erfarenhet av att automatisera mjukvarukvalitetskontroller och implementera möjliga scenarier för dess "självläkning".
Jag arbetar som ingenjör på IT-serviceavdelningen på ett företag . Mitt kärnområde av expertis är implementering av olika system för övervakning av applikationsprestanda och tillgänglighet. Jag kommunicerar ofta med IT-kunder från olika marknadssegment angående aktuella frågor kring kvalitetsuppföljning av deras IT-tjänster. Huvudmålet är att minimera utsläppscykeltiden och öka frekvensen av utsläpp. Detta är naturligtvis allt bra: fler releaser - fler nya funktioner - fler nöjda användare - mer vinst. Men i verkligheten går det inte alltid bra. Med mycket höga distributionshastigheter uppstår omedelbart frågan om kvaliteten på våra utgåvor. Även med en helt automatiserad pipeline är en av de största utmaningarna att flytta tjänster från testning till produktion utan att påverka applikationens drifttid och användarupplevelse.
Baserat på resultaten av många samtal med kunder kan jag säga att kvalitetskontroll av släpp, problemet med applikationstillförlitlighet och möjligheten att dess "självläkande" (till exempel återgå till en stabil version) i olika skeden av CI /CD pipeline är bland de mest spännande och relevanta ämnena.
Nyligen arbetade jag själv på kundsidan - i nätbankens applikationsprogramvarusupporttjänst. Arkitekturen för vår applikation använde ett stort antal självskrivna mikrotjänster. Det tråkigaste är att inte alla utvecklare klarade av den höga utvecklingstakten; kvaliteten på vissa mikrotjänster blev lidande, vilket gav upphov till roliga smeknamn för dem och deras skapare. Det fanns historier om vilka material dessa produkter var gjorda av.
"Formulering av problemet"
Den höga frekvensen av releaser och ett stort antal mikrotjänster gör det svårt att förstå hur applikationen fungerar som helhet, både på teststadiet och i driftstadiet. Förändringar sker ständigt och det är mycket svårt att kontrollera dem utan bra övervakningsverktyg. Ofta, efter en nattsläpp på morgonen, sitter utvecklare som på en krutdurk och väntar på att ingenting ska gå sönder, även om alla kontroller lyckades i teststadiet.
Det finns en poäng till. I teststadiet kontrolleras programvarans funktionalitet: implementeringen av applikationens huvudfunktioner och frånvaron av fel. Kvalitativa prestationsbedömningar saknas eller tar inte hänsyn till alla aspekter av applikationen och integrationslagret. Vissa mätvärden kanske inte kontrolleras alls. Som ett resultat, när ett haveri inträffar i en produktionsmiljö, får den tekniska supportavdelningen reda på det först när riktiga användare börjar klaga. Jag skulle vilja minimera effekten av mjukvara av låg kvalitet på slutanvändarna.
En av lösningarna är att implementera processer för att kontrollera mjukvarans kvalitet i olika stadier av CI/CD Pipeline, och lägga till olika scenarier för att återställa systemet i händelse av en nödsituation. Vi kommer också ihåg att vi har DevOps. Företag förväntar sig att få en ny produkt så snabbt som möjligt. Därför måste alla våra kontroller och skript vara automatiserade.
Uppgiften är uppdelad i två delar:
- kvalitetskontroll av sammansättningar i teststadiet (för att automatisera processen att fånga sammansättningar av låg kvalitet);
- mjukvarukvalitetskontroll i produktionsmiljön (mekanismer för automatisk upptäckt av problem och möjliga scenarier för deras självläkning).
Verktyg för att övervaka och samla in mätvärden
För att uppnå de uppsatta målen krävs ett övervakningssystem som kan upptäcka problem och överföra dem till automationssystem i olika skeden av CI/CD-pipelinen. Det kommer också att vara positivt om detta system ger användbar statistik för olika team: utveckling, testning, drift. Och det är helt underbart om det också är för affärer.
För att samla in mätvärden kan du använda en uppsättning olika system (Prometheus, ELK Stack, Zabbix, etc.), men enligt min åsikt är APM-klasslösningar bäst lämpade för dessa uppgifter (), vilket kan förenkla ditt liv avsevärt.
Som en del av mitt arbete i supporttjänsten började jag göra ett liknande projekt med en APM-klasslösning från Dynatrace. Nu, som arbetar för en integratör, känner jag marknaden för övervakningssystem ganska väl. Min subjektiva åsikt: Dynatrace lämpar sig bäst för att lösa sådana problem.
Dynatrace ger en horisontell vy av varje användaroperation på en granulär nivå ner till kodexekveringsnivån. Du kan spåra hela kedjan av interaktion mellan olika informationstjänster: från front-end-nivåerna för webb- och mobilapplikationer, back-end-applikationsservrar, integrationsbuss till ett specifikt anrop till databasen.
. Automatisk uppbyggnad av alla beroenden mellan systemkomponenter
. Automatisk detektering och konstruktion av serviceoperationsvägen
Vi kommer också ihåg att vi behöver integrera med olika automationsverktyg. Här har lösningen ett bekvämt API som låter dig skicka och ta emot olika mätvärden och händelser.
Låt oss sedan gå vidare till en mer detaljerad titt på hur man löser dessa problem med hjälp av Dynatrace-systemet.
Uppgift 1. Automatisering av kvalitetskontroll av sammansättningar i teststadiet
Den första utmaningen är att hitta problem så tidigt som möjligt i applikationens leveranspipeline. Endast "bra" kodbyggen ska nå produktion. För att göra detta bör din pipeline i teststadiet innehålla ytterligare monitorer för att kontrollera kvaliteten på dina tjänster.
Låt oss ta en steg-för-steg titt på hur man implementerar detta och automatiserar denna process:
Bilden visar flödet av automatiska kvalitetsteststeg för programvara:
- utplacering av ett övervakningssystem (installation av agenter);
- identifiera händelser för att bedöma kvaliteten på din programvara (mått och tröskelvärden) och överföra dem till övervakningssystemet;
- generering av belastnings- och prestandatester;
- samla in prestanda- och tillgänglighetsdata i övervakningssystemet;
- överföring av testdata baserat på händelser för kvalitetsbedömning av programvara från övervakningssystemet till CI/CD-systemet. Automatisk analys av sammansättningar.
Steg 1. Utplacering av övervakningssystemet
Först måste du installera agenterna i din testmiljö. Samtidigt har Dynatrace-lösningen en trevlig funktion – den använder den universella agenten OneAgent, som är installerad på en OS-instans (Windows, Linux, AIX), upptäcker automatiskt dina tjänster och börjar samla in övervakningsdata på dem. Du behöver inte konfigurera en separat agent för varje process. Situationen kommer att vara liknande för moln- och containerplattformar. Samtidigt kan du också automatisera agentinstallationsprocessen. Dynatrace passar perfekt in i konceptet "infrastruktur som kod" (): Det finns färdiga skript och instruktioner för alla populära plattformar. Du bäddar in agenten i konfigurationen av din tjänst, och när du distribuerar den får du omedelbart en ny tjänst med en redan fungerande agent.
Steg 2: Definiera dina programkvalitetshändelser
Nu måste du bestämma dig för listan över tjänster och affärsverksamhet. Det är viktigt att ta hänsyn till just de användaroperationer som är affärskritiska för din tjänst. Här rekommenderar jag att konsultera med affärs- och systemanalytiker.
Därefter måste du bestämma vilka mätvärden du vill inkludera i recensionen för varje nivå. Det kan till exempel vara exekveringstid (uppdelad i medelvärde, median, percentiler, etc.), fel (logiskt, tjänst, infrastruktur, etc.) och olika infrastrukturmått (minneshög, skräpsamlare, trådantal, etc.).
För automatisering och användarvänlighet för DevOps-teamet dyker konceptet "Monitoring as Code" upp. Vad jag menar med detta är att en utvecklare/testare kan skriva en enkel JSON-fil som definierar kvalitetssäkringsmått för programvara.
Låt oss titta på ett exempel på en sådan JSON-fil. Objekt från Dynatrace API används som nyckel/värdepar (API-beskrivning finns här ).
{
"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 är en rad tidsseriedefinitioner:
- timesseriesId – måttet som kontrolleras, till exempel svarstid, antal fel, använt minne, etc.;
- aggregering - nivå av mätvärdesaggregation, i vårt fall avg, men du kan använda vilken som helst du behöver (avg, min, max, summa, count, percentil);
- taggar – objekttagg i övervakningssystemet, eller så kan du ange en specifik objektidentifierare;
- allvarlig och varning – dessa indikatorer reglerar tröskelvärdena för våra mätvärden; om testvärdet överskrider det allvarliga tröskelvärdet markeras vårt bygge som inte lyckat.
Följande figur visar ett exempel på användningen av sådana trösklar.
Steg 3: Ladda generering
När vi har bestämt kvalitetsnivåerna för vår tjänst måste vi generera en testbelastning. Du kan använda vilket som helst av testverktygen du är bekväm med, såsom Jmeter, Selenium, Neotys, Gatling, etc.
Dynatraces övervakningssystem låter dig fånga olika metadata från dina tester och känna igen vilka tester som hör till vilken releasecykel och vilken tjänst. Det rekommenderas att lägga till ytterligare rubriker till HTTP-testförfrågningar.
Följande figur visar ett exempel där vi, med hjälp av den extra rubriken X-Dynatrace-Test, indikerar att detta test avser att testa hur man lägger till en vara i kundvagnen.
När du kör varje laddningstest skickar du ytterligare kontextuell information till Dynatrace med hjälp av Event API från CI/CD-servern. På så sätt kan systemet skilja mellan olika tester.
. Händelse i övervakningssystemet om start av lastprovning
Steg 4-5. Samla in prestandadata och överför data till CI/CD-systemet
Tillsammans med det genererade testet sänds en händelse till övervakningssystemet om behovet av att samla in data om kontroll av servicekvalitetsindikatorer. Den specificerar också vår JSON-fil, som definierar nyckelmåtten.
Händelse om behovet av att kontrollera kvaliteten på programvara som genereras på CI/CD-servern för att skickas till övervakningssystemet
I vårt exempel anropas kvalitetskontrollhändelsen perfSigDynatraceReport (Prestanda_Signatur) - det här är klart för integration med Jenkins, som utvecklades av killarna från T-Systems Multimedia Solutions. Varje teststartshändelse innehåller information om tjänsten, buildnummer och testtid. Pluginet samlar in prestandavärden vid byggtid, utvärderar dem och jämför resultatet med tidigare byggnationer och icke-funktionella krav.
Händelse i övervakningssystemet om starten av en byggkvalitetskontroll.
Efter att testet är genomfört överförs alla mätvärden för att bedöma mjukvarans kvalitet tillbaka till ett kontinuerligt integrationssystem, till exempel Jenkins, som genererar en rapport om resultaten.
Resultatet av statistik om sammanställningar på CI/CD-servern.
För varje enskild konstruktion ser vi statistik för varje mätvärde vi ställer in under hela testet. Vi ser också om det förekom överträdelser av vissa tröskelvärden (varning och allvarliga tröskelvärden). Baserat på sammanställd statistik markeras hela bygget som stabilt, instabilt eller misslyckat. För enkelhetens skull kan du också lägga till indikatorer i rapporten som jämför den nuvarande byggnaden med den föregående.
Visa detaljerad statistik om sammansättningar på CI/CD-servern.
Detaljerad jämförelse av två sammansättningar
Om det behövs kan du gå till Dynatrace-gränssnittet och där kan du se statistiken för var och en av dina byggen mer detaljerat och jämföra dem med varandra.
Jämförelse av byggstatistik i Dynatrace.
Resultat
Som ett resultat får vi en "monitoring as a service"-tjänst, automatiserad i den kontinuerliga integrationspipen. Utvecklaren eller testaren behöver bara definiera en lista med mätvärden i en JSON-fil, och allt annat händer automatiskt. Vi får transparent kvalitetskontroll av releaser: alla meddelanden om prestanda, resursförbrukning eller arkitektoniska regressioner.
Uppgift 2. Automatisering av mjukvarukvalitetskontroll i en produktionsmiljö
Så vi har löst problemet med hur man automatiserar övervakningsprocessen vid teststadiet i Pipeline. På så sätt minimerar vi andelen lågkvalitetsenheter som når produktionsmiljön.
Men vad ska man göra om dålig programvara säljs eller något bara går sönder. För en utopi ville vi ha mekanismer för att automatiskt upptäcka problem och, om möjligt, själva systemet för att återställa sin funktionalitet, åtminstone på natten.
För att göra detta behöver vi, i analogi med föregående avsnitt, tillhandahålla automatiska kvalitetskontroller av mjukvaran i produktionsmiljön och basera dem på scenarier för självläkning av systemet.
Autokorrigering som kod
De flesta företag har redan en samlad kunskapsbas om olika typer av vanliga problem och en lista med åtgärder för att åtgärda dem, till exempel att starta om processer, städa upp resurser, återställa versioner, återställa ogiltiga konfigurationsändringar, öka eller minska antalet komponenter i klustret, byta blå eller grön kontur och etc.
Även om dessa användningsfall har varit kända i flera år av många av teamen jag pratar med, har få tänkt på eller investerat i att automatisera dem.
Om du tänker på det finns det inget alltför komplicerat i att implementera processer för självläkande applikationsprestanda; du måste presentera de redan kända arbetsscenarionerna för dina administratörer i form av kodskript (konceptet "autofix som kod") , som du skrivit i förväg för varje specifikt fall. Automatiska reparationsskript bör syfta till att eliminera grundorsaken till problemet. Du bestämmer själv de korrekta åtgärderna för att reagera på en incident.
Alla mätvärden från ditt övervakningssystem kan fungera som en utlösare för att starta skriptet, huvudsaken är att dessa mätvärden exakt avgör att allt är dåligt, eftersom du inte skulle vilja få falska positiva resultat i en produktiv miljö.
Du kan använda vilket system eller uppsättning system som helst: Prometheus, ELK Stack, Zabbix, etc. Men jag kommer att ge några exempel baserade på en APM-lösning (Dynatrace kommer att vara ett exempel igen) som också kommer att bidra till att göra ditt liv enklare.
För det första är det allt relaterat till prestanda när det gäller applikationsdrift. Lösningen tillhandahåller hundratals mätvärden på olika nivåer som du kan använda som utlösare:
- användarnivå (webbläsare, mobilapplikationer, IoT-enheter, användarbeteende, konvertering, etc.);
- servicenivå och drift (prestanda, tillgänglighet, fel, etc.);
- applikationsinfrastrukturnivå (värd OS-statistik, JMX, MQ, webbserver, etc.);
- plattformsnivå (virtualisering, moln, container, etc.).
Övervakning av nivåer i Dynatrace.
För det andra, som jag sa tidigare, har Dynatrace ett öppet API, vilket gör det väldigt enkelt att integrera med olika tredjepartssystem. Till exempel att skicka ett meddelande till automationssystemet när kontrollparametrar överskrids.
Nedan är ett exempel för interaktion med Ansible.
Nedan ska jag ge några exempel på vilken typ av automatisering som kan göras. Detta är bara en del av fallen; deras lista i din miljö kan bara begränsas av din fantasi och kapaciteten hos dina övervakningsverktyg.
1. Dålig implementering – återställning av version
Även om vi testar allt väldigt bra i en testmiljö, finns det fortfarande en chans att en ny version kan döda din applikation i en produktionsmiljö. Samma mänskliga faktor har inte avbrutits.
I följande figur ser vi att det finns ett kraftigt hopp i utförandetiden för operationer på tjänsten. Början av detta hopp sammanfaller med tidpunkten för distributionen till applikationen. Vi överför all denna information som händelser till automationssystemet. Om prestandan för tjänsten inte återgår till det normala efter den tid vi ställt in, anropas automatiskt ett skript som rullar tillbaka versionen till den gamla.
Försämring av driftprestanda efter driftsättning.
2. Resursladdning på 100 % - lägg till en nod till routing
I följande exempel fastställer övervakningssystemet att en av komponenterna upplever 100 % CPU-belastning.
CPU-belastning 100%
Det finns flera olika scenarier möjliga för denna händelse. Till exempel kontrollerar övervakningssystemet dessutom om bristen på resurser är förknippad med en ökning av belastningen på tjänsten. Om så är fallet exekveras ett skript som automatiskt lägger till en nod till routingen, och därigenom återställer systemets funktionalitet som helhet.
Skalning efter en incident
3. Brist på utrymme på hårddisken - diskrensning
Jag tror att många redan har automatiserat dessa processer. Med APM kan du också övervaka det lediga utrymmet på diskundersystemet. Om det inte finns något utrymme eller om disken körs långsamt, anropar vi ett skript för att rensa det eller lägga till utrymme.
Skivladdning 100 %
4. Låg användaraktivitet eller låg konvertering - växla mellan blå och gröna grenar
Jag ser ofta kunder som använder två slingor (blågröna utplaceringar) för applikationer i en produktionsmiljö. Detta gör att du snabbt kan växla mellan filialer när du levererar nya releaser. Ofta kan dramatiska förändringar inträffa efter driftsättning som inte märks omedelbart. I detta fall kan försämring av prestanda och tillgänglighet inte observeras. För att snabbt svara på sådana förändringar är det bättre att använda olika mätvärden som speglar användarbeteende (antal sessioner och användaråtgärder, konvertering, avvisningsfrekvens). Följande figur visar ett exempel där växling mellan mjukvarugrenar sker när konverteringsfrekvensen sjunker.
Konverteringsfrekvensen sjunker efter byte mellan mjukvarugrenar.
Mekanismer för automatisk problemdetektering
Slutligen ska jag ge dig ytterligare ett exempel på varför jag gillar Dynatrace mest.
I delen av min berättelse om att automatisera kvalitetskontroller av sammansättningar i en testmiljö bestämde vi alla tröskelvärden manuellt. Detta är normalt för en testmiljö, testaren bestämmer själv indikatorerna före varje test beroende på belastningen. I en produktionsmiljö är det önskvärt att problem upptäcks automatiskt, med hänsyn tagen till olika baslinjemekanismer.
Dynatrace har intressanta inbyggda verktyg för artificiell intelligens som, baserat på mekanismer för att bestämma onormala mätvärden (baselining) och bygga en karta över interaktion mellan alla komponenter, jämföra och korrelera händelser med varandra, bestämmer anomalier i driften av din tjänst och ger detaljerad information information om varje problem och grundorsaken.
Genom att automatiskt analysera beroenden mellan komponenter avgör Dynatrace inte bara om den problematiska tjänsten är grundorsaken, utan också dess beroende av andra tjänster. I exemplet nedan övervakar och utvärderar Dynatrace automatiskt tillståndet för varje tjänst inom transaktionsexekveringen, och identifierar Golang-tjänsten som grundorsaken.
Ett exempel på att fastställa grundorsaken till ett fel.
Följande bild visar processen för att övervaka problem med din applikation från början av en incident.
Visualisering av ett uppkommande problem med visning av alla komponenter och händelser på dem
Övervakningssystemet samlade in en fullständig kronologi av händelser relaterade till problemet som uppstod. I fönstret under tidslinjen ser vi alla nyckelhändelser på var och en av komponenterna. Baserat på dessa händelser kan du ställa in procedurer för automatisk korrigering i form av kodskript.
Dessutom råder jag dig att integrera ett övervakningssystem med Service Desk eller en buggspårare. När ett problem uppstår får utvecklare snabbt fullständig information för att analysera den på kodnivå i produktionsmiljön.
Slutsats
Som ett resultat slutade vi med en CI/CD-pipeline med inbyggda automatiska kvalitetskontroller av programvara i Pipeline. Vi minimerar antalet sammansättningar av låg kvalitet, ökar tillförlitligheten för systemet som helhet, och om vårt system fortfarande misslyckas lanserar vi mekanismer för att återställa det.
Det är definitivt värt att satsa på att automatisera kvalitetsövervakning av programvara; det är inte alltid en snabb process, men med tiden kommer det att bära frukt. Jag rekommenderar att du efter att ha löst en ny incident i produktionsmiljön omedelbart funderar på vilka monitorer som ska läggas till för kontroller i testmiljön för att undvika att en dålig build kommer in i produktionen, och även skapar ett script för att automatiskt korrigera dessa problem.
Jag hoppas att mina exempel kommer att hjälpa dig i dina ansträngningar. Jag kommer också att vara intresserad av att se dina exempel på mått som används för att implementera självläkande system.
Källa: will.com