10. Testen & Monitoren

Hoe verhoog je de kwaliteit van integraties?

Op een gegeven moment is de fabriek opgezet en rollen de taarten en gebakjes van de band. Aleksandra wil hier natuurlijk niet naast gaan staan om elke taart eerst te bekijken voordat deze wordt uitgeleverd. Ze moet er op kunnen vertrouwen dat het werkt.

Althans, als alles goed gaat, hoeft ze niets te weten. Maar natuurlijk gaat niet altijd alles goed. Om te zorgen dat er zoveel mogelijk goed gaat wordt er eerst veel getest, en als het dan toch fout gaat gebruiken we monitoring om daarvan op de hoogte worden gebracht. Zowel testen als monitoren kan heel ver gaan (zelfs zo ver dat het een fulltime job voor velen is).

Testen en monitoren gaan beide over de kwaliteit en continuïteit van de productieomgeving. Het testen vangt zoveel mogelijk gevallen af voordat een integratie in productie gaat, terwijl de monitoring deze kwaliteit bewaakt, nadat deze in productie is gegaan.

Testen

Voordat een taart van de band af komt rollen doorloopt het proces vele stappen. Net als bij de stappen in een recept, zullen de ingrediënten langs verschillende machines gaan voordat ze omgetoverd zijn in een lekkere taart. Bij het opzetten van de taartenfabriek zorgen de ingenieurs en machinebouwers ervoor dat het bakproces efficiënt en in een logische volgorde verloopt.

De fabriek krijgt hiervoor twee docks, elk aan een andere zijde van de fabriek. Aan de ene kant een onramp, waar leveranciers de ingrediënten komen leveren en aan de andere kant een offramp, waar de taarten klaar staan voor de afnemers. Daartussen zitten de verschillende machines die de ingrediënten samen brengen, deeg kneden, de lagen opbouwen en de garnering aanbrengen. Als de taart klaar is, wordt deze verpakt en op de offramp geplaatst.

In de fabriek worden de verschillende stappen per machine getest. Tenslotte wordt er nog gekeken naar hoeveel taarten er precies geproduceerd kunnen worden om pieken op te vangen.

Een standaardintegratie

Ook een integratie kun je beschouwen als productieproces met een onramp en offramp. Onramp is het gedeelte waar databerichten worden aangeleverd of opgehaald en offramp waar deze worden verstuurd of aangeboden. Daartussen zitten verschillende bewerkingsstappen. Bij elkaar horende bewerkingsstappen worden vaak in een module gezet. In integratie kan een productielijn er als volgt uit zien:

Op dit proces kun je allerlei verschillende testen uitvoeren. Het testproces geeft aan in welke volgorde en door wie deze test wordt uitgevoerd. Niet-geslaagde testen levert herstelwerk voor de ontwikkelaars of werk voor derden partijen.

Basisprocestesten van een integratie:

1. Connectietest: een nieuwe integratie start met het testen van de verbinding. De reden daarvan is dat er hier een afhankelijkheid is van derde partijen. Dit zijn bijvoorbeeld de leveranciers of de netwerkbeheerders. Dit is het testen van het onramp- of offramp-blok. Je wilt deze problemen snel tackelen, zodat alle verbindingen zonder problemen lopen.
2. Unittest: het testen van de programmatuur. Een unittest is in dit stadium nog niet heel relevant, maar is vooral van belang bij latere wijzigingen. Deze test controleert of de programmatuur bij een wijziging nog steeds werkt, zoals verwacht. De connecties worden bij een unittest vervangen door een mockup.
3. Integratietest: deze test met real life input controleert of een bericht goed verwerkt wordt door de module en de output goed ontvangen wordt. Soms wordt deze test ook gezien als onderdeel van een unittest zonder mockups.
4. Smoke test: na de release van een integratie is de smoke test een check of alles vergelijkbaar werkt op een test of acceptatie-omgeving. Hiermee test je vooral de uitrol. Vraag je zelf hierbij af of de uitrol volledig is, maar denk vooral ook aan verschillen tussen de ontwikkel- en testomgeving, zoals verbindingen en omgevingsvariabelen (properties). Het doel is ook om technische fouten op te sporen, zodat er goed ketengetest kan worden.
5. Ketentest: test van een volledige integratie door middel van scenario’s. Deze loopt van bron naar doelapplicatie (end-to-end). Hier wordt daadwerkelijk ook naar de functionele inhoud van de output gekeken. Allereerst meestal door de gangbare situatie (happy flow) te testen en vervolgens ook de alternatieve scenario’s en de foutscenario’s. De ketentest is de meest volledige test. Als deze slaagt. dan werkt de integratie functioneel.
6. Releasetest: de beheerder test de uitrol op de acceptatie-omgeving. Hiermee bekijkt hij of aan alle acceptatiecriteria (technische overdracht) is voldaan.
7. Load test: de beheerder test of de interface met gangbare load (op basis van representatieve data) functioneert. Eveneens worden de maximale capaciteit en eventuele bottlenecks getest.
8. Shadow test: de beheerder test op een pre-productiesysteem met live data of een nieuwe wijziging geen fouten oplevert. Deze test is minder gangbaar bij een kleinere omgeving en zie je voornamelijk bij een grotere upgrade of bij migraties naar een ander integratieplatform.
9. Acceptatietest: de gebruikersorganisatie test een integratie op basis van real life data. Ze zien de integratielaag als een blackbox en gaan alleen van de applicatielaag uit. Data wordt direct ingevoerd bij de bron en het resultaat gecontroleerd bij de doelsystemen.

Deze verschillende testen met elk hun eigen rol vormen samen het testproces:

De meeste integratietesten verschillen enigszins van het testen van applicaties. De laatste draaien vooral om of de functionaliteit, zoals de eindgebruikers die gebruiken. Bij integratietesten gaat het veel meer om de in- en output van data. Oftewel, komt een databericht tijdig, compleet en juist aan bij zijn bestemming?

Monitoring

Alle verschillende testen hebben als doel de kans te verhogen dat een integratie op productie goed draait en werkt zoals verwacht. Maar hoe weet je dit zeker? Als er iets fout gaat wil je dit toch ook weten? En je wilt weten wat er precies fout gaat, waar het precies fout gaat en hoe je het kunt verhelpen…

Aleksandra zit samen met haar medewerkers lekker te lunchen. Dan horen ze een waarschuwingssignaal uit de fabriekshal komen. “Er zal wel weer een croissantje vastzitten”, grapt ze. Maar Thomas kijkt al op zijn mobiel. Daar heeft hij een alert zien binnenkomen. Het gaat fout in de toppingsmachine. “Ik ben al onderweg!”

Door te monitoren detecteer je als er iets fout gaat, maar goede monitoringssystemen kunnen ook al detecteren voordat er iets fout gaat. Dit is het verschil tussen reactieve en preventieve monitoring. Daarnaast kunnen monitoringssystemen ook data verzamelen en statistieken tonen om trendanalyses te doen. Een aantal voorbeelden:

1. Reactieve monitoring: een ontvangend systeem is niet beschikbaar. Verschillende berichten zijn uitgevallen en in de error queue geplaatst. De monitoring geeft hier een alert van. De beheerder kan deze alert op zijn telefoon krijgen of de volgende dag als rapport op de mail ontvangen. Eventueel kan hij het bericht handmatig nogmaals aanbieden, zodra het ontvangend systeem weer in de lucht is.
2. Preventieve monitoring: er vindt een ophoping plaats op een queue, de berichten lopen nog door, maar nieuwe berichten kunnen voor blokkades zorgen. Het monitoringssysteem geeft hiervoor preventief een waarschuwing af. Er kunnen dan eventueel extra instanties bij worden geplaatst, zodat de berichten weer doorlopen.
3. Trendanalyses: er is een klein memory leak, waardoor er elk dag een beetje meer geheugen wordt gebruikt. Na een half jaar zou de module “OutOfMemory” zijn. De preventieve monitoring kan bij 90% een waarschuwing geven, maar grafieken laten precies de trend zien.

Over het algemeen worden de analyse en de acties die erop volgen uitgevoerd door de beheerders. Dit komt vaak omdat het om onvoorziene zaken gaat, die niet uit het testen zijn gekomen, of die door randsystemen worden veroorzaakt.

Er kunnen ook automatische acties worden ondernomen, zoals opnieuw verbinden, herstarten of inzetten van een foutafhandelingsproces. In omgevingen zoals microservices of stateless containers kunnen services soms automatisch opschalen bij drukte.

Alerts komen natuurlijk niet zomaar op de telefoon van een beheerder. Vaak dienen softwarecomponenten te worden opgevoerd als items. Aan items kunnen triggers worden gekoppeld, waaruit weer een event komt. Tenslotte kunnen hier acties aan worden gekoppeld (zoals een notificatie van de alert of een herstart).

Type monitoring

Binnen de integratielaag kun je op verschillende niveaus de integraties monitoren.

1. System monitoring

Systeem is het laagste niveau. Op dit niveau worden verschillende technische componenten, zoals servers, netwerk en virtual machines, gemonitord. Denk hierbij aan logs, queues, caches, geheugen en processorgebruik. Op basis van items, triggers en events worden alerts opgesteld. Bekende systemen zijn Zabbix, Nagios en Cacti.

A Zabbix Dashboard

2. Performance Monitoring

Performance monitoring kijkt naar complexe problemen met de prestaties van integraties door bottlenecks op te sporen en te diagnosticeren, om een verwacht niveau van dienstverlening te handhaven. Je kijkt hierbij vooral naar de load van de totale integratie of naar specifieke stappen (de bottlenecks). Ook kijk je naar verwerkings- en responsetijden tussen de verschillende componenten. Bekende monitoringsoftware is New Relic, Dynatrace en Datadog.

3. Chain Monitoring

Het monitoren van de keten is een end-to-end-benadering van monitoring. Een applicatie stuurt bijvoorbeeld gedurende de dag duizenden berichten. De ketenmonitoring gaat na hoeveel berichten er precies zijn gestuurd, welke stappen die hebben doorlopen, hoeveel er zijn fout gegaan en hoeveel er door de doelsystemen zijn ontvangen.

De ketenmonitoring vangt meestal een bericht log of notificatie op met behulp van een aantal velden, zoals de naam van de stap, het ID van het bericht, de timestamp, het type log (INFO, WARN, ERROR etc.) en soms ook het complete bericht.

Soms wordt het hele proces als één transactie gezien en kun je het bericht door de keten heen volgen. Bekende systemen voor het monitoren van de keten zijn Elastic, Splunk en Grafana/Prometheus. Vaak kunnen deze niet alleen de verschillende stappen en aantallen meten, maar ook de tijd die een stap kost (op een hoger niveau dan Performance Monitoring).

Elastic Dashboard

Network Mapping & Time Diagrams

Integratielagen bestaan vaak uit verschillende middleware-componenten die meerdere services bevatten. Vaak zijn er wel architectuurplaten en designs die de onderlinge samenhang van componenten laten zien, maar dat is in design time, niet in run time. Om een overzicht te krijgen van hoe deze componenten in productie in runtime met elkaar samenhangen kunnen live network maps gebruikt worden.

Network maps kunnen zowel op systeem-, performance- en ketenmonitoring gemaakt worden. Op systeemniveau laten ze bijvoorbeeld het netwerk en de servers zien en de data in bytes. Bij performance monitoring zul je op de lijnen kunnen klikken om de verwerkings- en responsetijd te kunnen bekijken. Bij ketenmonitoring zul je op applicatie- en serviceniveau de verschillende aantallen kunnen bekijken en een bericht door de keten kunnen volgen.

Network maps geven vooral een beeld van hoe de verschillende componenten met elkaar samenhangen. Ketens en tijden worden vaak in tijdsdiagrammen weergegeven. Deze laten per bericht, per stap zien hoe een bericht wordt verwerkt.

Message Flow Diagram: Intersystems Iris

Data-driven werkwijze

Goed testen en monitoren is vaak ook nodig omdat de integratielaag wordt gebruikt (sommigen zeggen: misbruikt) om zaken op te lossen die een organisatie moeizaam in de applicatielaag kan realiseren. Vaak omdat standaardapplicaties of clouddiensten (SaaS-applicaties) worden ingezet die weinig flexibiliteit bieden.

Systemen worden vaak ontwikkeld door verschillende partijen. De middenlaag ertussen zorgt in de basis voor communicatie, maar in de praktijk voor veel meer. Een beperkte set van logica waar er beperkt ruimte is voor fouten en interpretatie is helaas een utopie. Vaak moet er in de integratielaag berichten worden getransformeerd of verrijkt. Versiebeheer van de applicaties is daarbij essentieel.

Het kan voorkomen dat er in de bronsystemen een bug wordt verholpen in de ene applicatie waarbij een veld verdwijnt, hernoemd of toegevoegd wordt, die vervolgens in de integratie een transformatiefout oplevert. De bug is dan succesvol getest in de applicatie en live gezet. De fout wordt dan vaak toegeschreven aan de middleware. Essentieel is dus dit deel mee te testen en ketentesten uit te voeren.

Het is slim om berichten te gebruiken die output zijn van een andere applicatie en het proces waardoor het bericht “ontstaat” na transformatie en verrijking geschikt te maken voor de application user test (AUT). Hierdoor ontstaan veel minder integratie-issues op het moment dat alle systemen aan elkaar worden geknoopt voor livegang.

Het juist loggen en monitoren van deze integratie, zodra zij in productie zijn, is vervolgens weer belangrijk voor de ‘bewijslast’ van waar iets fout gaat en wie het moet oplossen. Een integratie is een keten aan schakels en vaak wordt na een fout ergens een plek in de keten aangewezen die hiervoor verantwoordelijk is. De juiste data kan aantonen of dit ook daadwerkelijk het geval is.

Als er iets fout gaat is een alert vanuit de monitoring al handig, maar soms wil je ook data-gedreven werken en over langere tijd zien wat de trends zijn om zo de juiste beslissingen te kunnen nemen. Deze kunnen worden gebruikt om de schaalbaarheid van de omgeving te verhogen.

[embed]11. Lessons learned! Waar loop je in de integratie praktijk tegenaan?raymondmeester.medium.com

Inhoudsopgave:

[embed]Data Integratie Edit descriptionraymondmeester.medium.com