Nu is het onderwerp DevOps een hype. Continue integratie- en leveringspijplijn CI / CD iedereen voert het uit. Maar de meesten besteden niet altijd voldoende aandacht aan het waarborgen van de betrouwbaarheid van informatiesystemen in verschillende stadia van de CI/CD-pijplijn. In dit artikel wil ik het hebben over mijn ervaring met het automatiseren van softwarekwaliteitscontroles en het implementeren van mogelijke scenario's voor de “zelfherstel” ervan.

Bron

Ik werk als engineer op de IT-servicemanagementafdeling van een bedrijf "LANIT-integratie". Mijn kerngebied van expertise is de implementatie van verschillende applicatieprestatie- en beschikbaarheidsmonitoringsystemen. Ik communiceer vaak met IT-klanten uit verschillende marktsegmenten over actuele vraagstukken rond het bewaken van de kwaliteit van hun IT-diensten. Het belangrijkste doel is om de releasecyclustijd te minimaliseren en de frequentie van releases te verhogen. Dit is natuurlijk allemaal goed: meer releases - meer nieuwe functies - meer tevreden gebruikers - meer winst. Maar in werkelijkheid gaat het niet altijd goed. Bij zeer hoge inzetpercentages rijst meteen de vraag over de kwaliteit van onze releases. Zelfs met een volledig geautomatiseerde pijplijn is een van de grootste uitdagingen het verplaatsen van services van testen naar productie zonder de uptime van applicaties en de gebruikerservaring te beïnvloeden.

Op basis van de resultaten van talrijke gesprekken met klanten kan ik zeggen dat de kwaliteitscontrole, het probleem van de betrouwbaarheid van de applicatie en de mogelijkheid van “zelfherstel” (bijvoorbeeld terugdraaien naar een stabiele versie) in verschillende stadia van de CI worden vrijgegeven /CD-pijplijn behoren tot de meest opwindende en relevante onderwerpen.

Onlangs heb ik zelf aan de klantkant gewerkt - in de ondersteuningsdienst voor software voor online bankieren. De architectuur van onze applicatie maakte gebruik van een groot aantal zelfgeschreven microservices. Het meest trieste is dat niet alle ontwikkelaars het hoge ontwikkelingstempo aankonden; de kwaliteit van sommige microservices ging achteruit, wat aanleiding gaf tot grappige bijnamen voor hen en hun makers. Er waren verhalen over van welke materialen deze producten waren gemaakt.

"Formulering van het probleem"

De hoge frequentie van releases en het grote aantal microservices maken het lastig om de werking van de applicatie als geheel te doorgronden, zowel in de testfase als in de operationele fase. Veranderingen vinden voortdurend plaats en het is erg moeilijk om deze te beheersen zonder goede monitoringinstrumenten. Vaak zitten ontwikkelaars na een nachtelijke release in de ochtend als op een kruitvat en wachten tot er niets kapot gaat, hoewel alle controles in de testfase succesvol waren.

Er is nog een punt. In de testfase wordt de functionaliteit van de software gecontroleerd: de implementatie van de belangrijkste functies van de applicatie en de afwezigheid van fouten. Kwalitatieve prestatiebeoordelingen ontbreken of houden geen rekening met alle aspecten van de applicatie en de integratielaag. Sommige statistieken worden mogelijk helemaal niet gecontroleerd. Als gevolg hiervan komt de technische ondersteuningsafdeling er pas achter als er een storing optreedt in een productieomgeving als echte gebruikers beginnen te klagen. Ik wil de impact van software van lage kwaliteit op eindgebruikers minimaliseren.

Eén van de oplossingen is het implementeren van processen voor het controleren van de softwarekwaliteit in verschillende stadia van de CI/CD Pipeline, en het toevoegen van verschillende scenario's voor het herstellen van het systeem in geval van nood. We herinneren ons ook dat we DevOps hebben. Bedrijven verwachten zo snel mogelijk een nieuw product te ontvangen. Daarom moeten al onze controles en scripts worden geautomatiseerd.

De taak is verdeeld in twee componenten:

• kwaliteitscontrole van assemblages in de testfase (om het proces van het opvangen van assemblages van lage kwaliteit te automatiseren);
• softwarekwaliteitscontrole in de productieomgeving (mechanismen voor automatische detectie van problemen en mogelijke scenario's voor hun zelfherstel).

Hulpmiddel voor het monitoren en verzamelen van statistieken

Om de gestelde doelen te bereiken is een monitoringsysteem nodig dat problemen kan detecteren en deze kan overbrengen naar automatiseringssystemen in verschillende stadia van de CI/CD-pijplijn. Het zal ook positief zijn als dit systeem nuttige statistieken biedt voor verschillende teams: ontwikkeling, testen, bediening. En het is helemaal geweldig als het ook zakelijk is.

Om statistieken te verzamelen, kunt u een reeks verschillende systemen gebruiken (Prometheus, ELK Stack, Zabbix, enz.), Maar naar mijn mening zijn oplossingen van APM-klasse het meest geschikt voor deze taken (Monitoring van applicatieprestaties), wat uw leven aanzienlijk kan vereenvoudigen.

Als onderdeel van mijn werk bij de ondersteunende dienst ben ik begonnen met een soortgelijk project met behulp van een APM-klasseoplossing van Dynatrace. Nu ik voor een integrator werk, ken ik de markt voor monitoringsystemen redelijk goed. Mijn subjectieve mening: Dynatrace is het meest geschikt om dergelijke problemen op te lossen.
Dynatrace biedt een horizontaal beeld van elke gebruikershandeling, op granulair niveau tot op het niveau van de code-uitvoering. U kunt de hele keten van interactie tussen verschillende informatiediensten volgen: van de front-end niveaus van web- en mobiele applicaties, back-end applicatieservers, integratiebus tot een specifieke oproep naar de database.

Bron. Automatische constructie van alle afhankelijkheden tussen systeemcomponenten

Bron. Automatische detectie en constructie van het servicebewerkingspad

We onthouden ook dat we moeten integreren met verschillende automatiseringstools. Hier heeft de oplossing een handige API waarmee u verschillende statistieken en gebeurtenissen kunt verzenden en ontvangen.

Laten we vervolgens verder gaan met een meer gedetailleerde blik op hoe u deze problemen kunt oplossen met behulp van het Dynatrace-systeem.

Taak 1. Automatisering van de kwaliteitscontrole van assemblages in de testfase

De eerste uitdaging is om problemen zo vroeg mogelijk in de applicatieleveringspijplijn te vinden. Alleen ‘goede’ codebuilds zouden in productie moeten komen. Om dit te doen, moet uw pijplijn in de testfase extra monitoren bevatten om de kwaliteit van uw services te controleren.

Laten we stap voor stap bekijken hoe u dit kunt implementeren en dit proces kunt automatiseren:

Bron

De afbeelding toont de stroom van geautomatiseerde stappen voor het testen van de softwarekwaliteit:

1. inzet van een monitoringsysteem (installatie van agenten);
2. het identificeren van gebeurtenissen om de kwaliteit van uw software te beoordelen (metrieken en drempelwaarden) en deze over te dragen aan het monitoringsysteem;
3. het genereren van belasting- en prestatietests;
4. het verzamelen van prestatie- en beschikbaarheidsgegevens in het monitoringsysteem;
5. overdracht van testgegevens op basis van softwarekwaliteitsbeoordelingsgebeurtenissen van het monitoringsysteem naar het CI/CD-systeem. Automatische analyse van assemblages.

Stap 1. Implementatie van het monitoringsysteem

Eerst moet u de agents in uw testomgeving installeren. Tegelijkertijd heeft de Dynatrace-oplossing een leuke functie: het maakt gebruik van de universele agent OneAgent, die is geïnstalleerd op een besturingssysteeminstantie (Windows, Linux, AIX), detecteert automatisch uw services en begint met het verzamelen van monitoringgegevens daarover. U hoeft niet voor elk proces een afzonderlijke agent te configureren. De situatie zal vergelijkbaar zijn voor cloud- en containerplatforms. Tegelijkertijd kunt u ook het installatieproces van de agent automatiseren. Dynatrace past perfect in het ‘infrastructuur als code’-concept (Infrastructuur als code of IaC): Er zijn kant-en-klare scripts en instructies voor alle populaire platforms. U integreert de agent in de configuratie van uw dienst en wanneer u deze implementeert, ontvangt u onmiddellijk een nieuwe dienst met een reeds werkende agent.

Stap 2: Definieer uw softwarekwaliteitsgebeurtenissen

Nu moet u beslissen over de lijst met services en bedrijfsactiviteiten. Het is belangrijk om precies rekening te houden met die gebruikersactiviteiten die bedrijfskritisch zijn voor uw service. Hier raad ik aan om te overleggen met bedrijfs- en systeemanalisten.

Vervolgens moet u bepalen welke statistieken u voor elk niveau in de beoordeling wilt opnemen. Dit kan bijvoorbeeld de uitvoeringstijd zijn (verdeeld in gemiddelde, mediaan, percentielen, enz.), fouten (logisch, service, infrastructuur, enz.) en verschillende infrastructuurstatistieken (geheugenheap, garbage collector, aantal threads, enz.).

Voor automatisering en gebruiksgemak door het DevOps-team verschijnt het concept van “Monitoring as Code”. Wat ik hiermee bedoel is dat een ontwikkelaar/tester een eenvoudig JSON-bestand kan schrijven dat de meetgegevens voor softwarekwaliteitsborging definieert.

Laten we een voorbeeld van zo'n JSON-bestand bekijken. Objecten uit de Dynatrace API worden gebruikt als sleutel/waarde-paren (de API-beschrijving vindt u hier Dynatrace-API).

{
    "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
    }
  ]
}

Het bestand is een array van tijdreeksdefinities:

• timeseriesId – de statistiek die wordt gecontroleerd, bijvoorbeeld responstijd, aantal fouten, gebruikt geheugen, enz.;  
• aggregatie - niveau van aggregatie van metrische gegevens, in ons geval gemiddeld, maar u kunt elke gewenste waarde gebruiken (gem., min., max., som, aantal, percentiel);
• tags – objecttag in het monitoringsysteem, of u kunt een specifieke objectidentificatie opgeven;
• ernstig en waarschuwend – deze indicatoren reguleren de drempelwaarden van onze statistieken; als de testwaarde de ernstige drempel overschrijdt, wordt onze build gemarkeerd als niet succesvol.

De volgende afbeelding toont een voorbeeld van het gebruik van dergelijke drempels.

Bron

Stap 3: Lading genereren

Nadat we de kwaliteitsniveaus van onze dienstverlening hebben bepaald, moeten we een testlading genereren. U kunt elk van de testtools gebruiken waarmee u vertrouwd bent, zoals Jmeter, Selenium, Neotys, Gatling, enz.

Met het monitoringsysteem van Dynatrace kunt u diverse metadata van uw tests vastleggen en herkennen welke tests tot welke releasecyclus en welke dienst behoren. Het wordt aanbevolen om extra headers toe te voegen aan HTTP-testverzoeken.

De volgende afbeelding toont een voorbeeld waarbij we met de extra header X-Dynatrace-Test aangeven dat deze test betrekking heeft op het testen van de werking van het toevoegen van een artikel aan de winkelwagen.

Bron

Wanneer u elke belastingstest uitvoert, verzendt u aanvullende contextuele informatie naar Dynatrace met behulp van de Event API van de CI/CD-server. Op deze manier kan het systeem onderscheid maken tussen verschillende tests.

Bron. Gebeurtenis in het monitoringsysteem over de start van de belastingtest

Stap 4-5. Verzamel prestatiegegevens en breng gegevens over naar het CI/CD-systeem

Samen met de gegenereerde test wordt een gebeurtenis naar het monitoringsysteem verzonden over de noodzaak om gegevens te verzamelen over het controleren van servicekwaliteitsindicatoren. Het specificeert ook ons ​​JSON-bestand, dat de belangrijkste statistieken definieert.

Evenement over de noodzaak om de kwaliteit te controleren van software die op de CI/CD-server is gegenereerd voor verzending naar het monitoringsysteem

In ons voorbeeld wordt de kwaliteitscontrolegebeurtenis aangeroepen perfSigDynatraceReport (Prestatie_handtekening) - dit is klaar inpluggen voor integratie met Jenkins, ontwikkeld door de jongens van T-Systems Multimedia Solutions. Elke testlanceringsgebeurtenis bevat informatie over de service, het buildnummer en de testtijd. De plug-in verzamelt prestatiewaarden tijdens het bouwen, evalueert deze en vergelijkt het resultaat met eerdere builds en niet-functionele vereisten.

Gebeurtenis in het monitoringsysteem over de start van een bouwkwaliteitscontrole. Bron

Nadat de test is voltooid, worden alle statistieken voor het beoordelen van de softwarekwaliteit teruggestuurd naar een continu integratiesysteem, bijvoorbeeld Jenkins, dat een rapport over de resultaten genereert.

Het resultaat van statistieken over samenstellingen op de CI/CD-server. Bron

Voor elke individuele build zien we statistieken voor elke statistiek die we gedurende de hele test hebben ingesteld. Ook kijken we of er sprake is van overtredingen van bepaalde drempelwaarden (waarschuwing en zware dwangmaatregelen). Op basis van verzamelde statistieken wordt de gehele build gemarkeerd als stabiel, onstabiel of mislukt. Voor het gemak kunt u ook indicatoren aan het rapport toevoegen waarin u de huidige build vergelijkt met de vorige.

Bekijk gedetailleerde statistieken over samenstellingen op de CI/CD-server. Bron

Gedetailleerde vergelijking van twee samenstellingen

Indien nodig kunt u naar de Dynatrace-interface gaan en daar kunt u de statistieken voor elk van uw builds gedetailleerder bekijken en met elkaar vergelijken.

Vergelijking van buildstatistieken in Dynatrace. Bron
 
Bevindingen

Als gevolg hiervan krijgen we een ‘monitoring as a service’-service, geautomatiseerd in de continue integratiepijplijn. De ontwikkelaar of tester hoeft alleen maar een lijst met statistieken in een JSON-bestand te definiëren, en al het andere gebeurt automatisch. We ontvangen transparante kwaliteitscontrole van releases: alle meldingen over prestaties, resourceverbruik of architecturale regressies.

Taak 2. Automatisering van softwarekwaliteitscontrole in een productieomgeving

We hebben dus het probleem opgelost van het automatiseren van het monitoringproces in de testfase in Pipeline. Op deze manier minimaliseren we het percentage assemblages van lage kwaliteit die de productieomgeving bereiken.

Maar wat te doen als er slechte software wordt verkocht of als er iets kapot gaat. Voor een utopie wilden we mechanismen die problemen automatisch zouden detecteren en, indien mogelijk, dat het systeem zelf zijn functionaliteit zou herstellen, tenminste 's nachts.

Om dit te doen moeten we, naar analogie met de vorige paragraaf, voorzien in automatische softwarekwaliteitscontroles in de productieomgeving en deze baseren op scenario's voor zelfherstel van het systeem.

Autocorrectie als code

De meeste bedrijven beschikken al over een verzamelde kennisbank van verschillende soorten veelvoorkomende problemen en een lijst met acties om deze op te lossen, bijvoorbeeld het opnieuw starten van processen, het opschonen van bronnen, het terugdraaien van versies, het herstellen van ongeldige configuratiewijzigingen, het vergroten of verkleinen van het aantal componenten in het cluster, waarbij de blauwe of groene omtrek wordt gewijzigd, enz.

Hoewel deze gebruiksscenario's al jaren bekend zijn bij veel van de teams waarmee ik spreek, hebben slechts weinigen erover nagedacht of erin geïnvesteerd om ze te automatiseren.

Als je erover nadenkt, is er niets ingewikkelds aan het implementeren van processen voor zelfherstellende applicatieprestaties; je moet de reeds bekende werkscenario's van je beheerders presenteren in de vorm van codescripts (het concept "auto-fix as code") , die u voor elk specifiek geval vooraf hebt geschreven. Automatische reparatiescripts moeten gericht zijn op het elimineren van de hoofdoorzaak van het probleem. Je bepaalt zelf de juiste acties om op een incident te reageren.

Elke metriek uit uw monitoringsysteem kan fungeren als trigger om het script te starten. Het belangrijkste is dat deze metrieken nauwkeurig vaststellen dat alles slecht is, aangezien u in een productieve omgeving geen valse positieven wilt krijgen.

U kunt elk systeem of elke reeks systemen gebruiken: Prometheus, ELK Stack, Zabbix, enz. Maar ik zal enkele voorbeelden geven op basis van een APM-oplossing (Dynatrace zal weer een voorbeeld zijn) die je leven ook gemakkelijker zullen maken.

Ten eerste is er alles wat te maken heeft met prestaties in termen van applicatiewerking. De oplossing biedt honderden statistieken op verschillende niveaus die u als triggers kunt gebruiken:

• gebruikersniveau (browsers, mobiele applicaties, IoT-apparaten, gebruikersgedrag, conversie, enz.);
• niveau van service en bedrijfsvoering (prestaties, beschikbaarheid, fouten, etc.);
• niveau van de applicatie-infrastructuur (statistieken van het host-besturingssysteem, JMX, MQ, webserver, enz.);
• platformniveau (virtualisatie, cloud, container, enz.).

Niveaus monitoren in Dynatrace. Bron

Ten tweede heeft Dynatrace, zoals ik al eerder zei, een open API, waardoor het heel eenvoudig te integreren is met verschillende systemen van derden. Bijvoorbeeld het sturen van een melding naar het automatiseringssysteem wanneer regelparameters worden overschreden.

Hieronder ziet u een voorbeeld van interactie met Ansible.

Bron

Hieronder geef ik een paar voorbeelden van wat voor soort automatisering mogelijk is. Dit is slechts een deel van de gevallen; hun lijst in uw omgeving kan alleen worden beperkt door uw verbeeldingskracht en de mogelijkheden van uw monitoringtools.

1. Slechte implementatie – versie terugdraaien

Zelfs als we alles heel goed testen in een testomgeving, bestaat er nog steeds een kans dat een nieuwe release je applicatie in een productieomgeving kapot maakt. Dezelfde menselijke factor is niet geannuleerd.

In de volgende figuur zien we dat er een scherpe sprong is in de uitvoeringstijd van bewerkingen op de dienst. Het begin van deze sprong valt samen met het tijdstip van implementatie in de applicatie. Al deze informatie verzenden wij als gebeurtenissen naar het automatiseringssysteem. Als de prestaties van de service na de door ons ingestelde tijd niet weer normaal worden, wordt er automatisch een script aangeroepen dat de versie terugdraait naar de oude.

Verslechtering van de operationele prestaties na implementatie. Bron

2. Bronnen laden op 100% - voeg een knooppunt toe aan de routering

In het volgende voorbeeld stelt het monitoringsysteem vast dat een van de componenten een CPU-belasting van 100% ondervindt.

CPU-belasting 100%
 
Er zijn verschillende scenario's mogelijk voor dit evenement. Het monitoringsysteem controleert bijvoorbeeld bovendien of het gebrek aan middelen gepaard gaat met een toename van de belasting van de dienst. Als dat zo is, wordt er een script uitgevoerd dat automatisch een knooppunt aan de routing toevoegt, waardoor de functionaliteit van het systeem als geheel wordt hersteld.

Opschaling na een incident

3. Gebrek aan ruimte op de harde schijf - schijfopruiming

Ik denk dat veel mensen deze processen al hebben geautomatiseerd. Met APM kunt u ook de vrije ruimte op het schijfsubsysteem controleren. Als er geen ruimte is of de schijf langzaam draait, roepen we een script aan om deze op te schonen of ruimte toe te voegen.

Schijfbelasting 100%
 
4. Lage gebruikersactiviteit of lage conversie - schakelen tussen blauwe en groene takken

Ik zie vaak dat klanten twee loops (blauw-groen deploy) gebruiken voor applicaties in een productieomgeving. Hierdoor kun je snel schakelen tussen vestigingen bij het aanleveren van nieuwe releases. Vaak kunnen er na de inzet dramatische veranderingen optreden die niet direct merkbaar zijn. In dit geval wordt mogelijk geen verslechtering van de prestaties en beschikbaarheid waargenomen. Om snel op dergelijke veranderingen te reageren, is het beter om verschillende statistieken te gebruiken die het gebruikersgedrag weerspiegelen (aantal sessies en gebruikersacties, conversie, bouncepercentage). De volgende figuur toont een voorbeeld waarin, wanneer de conversiepercentages dalen, er wordt gewisseld tussen softwarebranches.

Het conversiepercentage daalt na het wisselen tussen softwarebranches. Bron

Mechanismen voor automatische probleemdetectie

Tot slot geef ik je nog een voorbeeld van waarom ik Dynatrace het leukst vind.

In het deel van mijn verhaal over het automatiseren van kwaliteitscontroles van samenstellingen in een testomgeving hebben we alle drempelwaarden handmatig bepaald. Dit is normaal voor een testomgeving; de tester bepaalt zelf de indicatoren vóór elke test, afhankelijk van de belasting. In een productieomgeving is het wenselijk dat problemen automatisch worden gedetecteerd, waarbij rekening wordt gehouden met verschillende basismechanismen.

Dynatrace heeft interessante ingebouwde hulpmiddelen voor kunstmatige intelligentie die, gebaseerd op mechanismen voor het bepalen van afwijkende statistieken (baselining) en het opbouwen van een kaart van de interactie tussen alle componenten, het vergelijken en correleren van gebeurtenissen met elkaar, afwijkingen in de werking van uw service vaststellen en gedetailleerde informatie verstrekken informatie over elk probleem en de hoofdoorzaak.

Door automatisch de afhankelijkheden tussen componenten te analyseren, bepaalt Dynatrace niet alleen of de problematische dienst de hoofdoorzaak is, maar ook de afhankelijkheid van andere diensten. In het onderstaande voorbeeld bewaakt en evalueert Dynatrace automatisch de gezondheid van elke service binnen de transactie-uitvoering, waarbij de Golang-service als hoofdoorzaak wordt geïdentificeerd.

Een voorbeeld van het vaststellen van de hoofdoorzaak van een storing. Bron

De volgende afbeelding toont het proces voor het monitoren van problemen met uw applicatie vanaf het begin van een incident.

Visualisatie van een opkomend probleem met weergave van alle componenten en gebeurtenissen daarop

Het monitoringsysteem verzamelde een volledige chronologie van gebeurtenissen die verband hielden met het probleem dat zich voordeed. In het venster onder de tijdlijn zien we alle belangrijke gebeurtenissen op elk van de componenten. Op basis van deze gebeurtenissen kunt u procedures instellen voor automatische correctie in de vorm van codescripts.

Daarnaast raad ik je aan om een ​​monitoringsysteem te integreren met Service Desk of een bugtracker. Wanneer er zich een probleem voordoet, ontvangen ontwikkelaars snel volledige informatie om dit op codeniveau in de productieomgeving te analyseren.

Conclusie

Als gevolg hiervan kwamen we terecht bij een CI/CD-pijplijn met ingebouwde geautomatiseerde softwarekwaliteitscontroles in Pipeline. We minimaliseren het aantal assemblages van lage kwaliteit, vergroten de betrouwbaarheid van het systeem als geheel en als ons systeem nog steeds faalt, lanceren we mechanismen om het te herstellen.

Het is zeker de moeite waard om moeite te investeren in het automatiseren van de monitoring van de softwarekwaliteit; het is niet altijd een snel proces, maar na verloop van tijd zal het vruchten afwerpen. Ik raad je aan om na het oplossen van een nieuw incident in de productieomgeving meteen na te denken over welke monitoren je moet toevoegen voor controles in de testomgeving om te voorkomen dat een slechte build in productie komt, en ook een script te maken om deze problemen automatisch te corrigeren.

Ik hoop dat mijn voorbeelden u zullen helpen bij uw inspanningen. Ik ben ook geïnteresseerd in uw voorbeelden van meetgegevens die worden gebruikt om zelfherstellende systemen te implementeren.

Bron

Bron: www.habr.com