In mijn vorige blog heb ik geschreven over de link tussen Capacity Management en performancetesten, welke in praktijk toch vaak minder zichtbaar blijkt te zijn en welke voordelen er te halen zijn wanneer die link meer gelegd zou worden. In dit blog wil ik ingaan op de voordelen die bij performancetesten gehaald kunnen worden uit goed Configuration Management.
Configuration Management
Wikipedia beschrijft het hier eigenlijk al heel mooi: “Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional and physical attributes with its requirements, design and operational information throughout its life.”
Veelal krijgt Configuration Management vorm in een registratiesysteem, waarbij niet altijd even duidelijk is wat er met de geregistreerde data gebeurt. Ik heb verschillende systemen voorbij zien komen die gebruikt werden om Configuration Items (CI’s) in vast te leggen. Een veelgehoorde klacht onder medewerkers, is dat het bijhouden van dergelijke systemen omslachtig is, of dat “alle administratieve rompslomp” de oorzaak ervan is dat er een lange doorlooptijd gerekend wordt om een nieuw component te leveren in een vrij simpele omgeving.
Wat je ook vaak ziet, in een omgeving waar de controle hierop minder is, is dat het systeem achterloopt op de werkelijkheid. Om sneller de service te kunnen leveren worden de administratieve zaken uitgesteld en soms vergeten. De lijst is niet compleet, of sommige componenten krijgen gewoon helemaal geen plaats binnen het systeem, waarmee men dan de doorlooptijd wil verkorten. Uiteindelijk raakt men dan het overzicht kwijt en kunnen incidenten zich voordoen. De medewerkers, die betrokken waren bij een oud stuk infrastructuur, zijn inmiddels niet meer in dienst en niemand weet meer wat zich eigenlijk binnen dat stuk van het netwerk afspeelt. Een kwalijke zaak, toch gebeurt het.
Configuration Management bij performancetesten
Een bij performancetesten gebruikte methode van het gebruik van Configuration Management: het vergelijken van een testomgeving met de productie-omgeving. Ook het bepalen van de scope van de performancetesten kan een goed ingerichte Configuration-Management-database uitkomst bieden door het verschaffen van een snel en compleet overzicht van betrokken interfaces en componenten.
Ook zou er gemakkelijker gekeken kunnen worden naar de risico’s die er zijn bij het schalen van de testomgeving. Het blijkt vaak dat, na gesprekken met betrokken beheerders, naar boven komt dat een test-omgeving precies is wat men zegt: production-like, maar in veel opzichten toch nog zeer afwijkend van productie, waar je bij het testen op performance toch een kleiner verschil had verwacht en gewenst. Wat de verschillen zijn tussen de twee omgevingen, zou vanuit Configuration Management snel duidelijk moeten kunnen worden. Netwerkcapaciteit, rekencapaciteit (CPU: aantal cores en snelheid), beschikbaar geheugen en opslagruimte en -snelheid (disk read-and-write) zijn allemaal interessante eigenschappen om bij te houden en te kunnen vergelijken tussen productie en test. Veel van deze gegevens zijn te halen uit type-nummers, waarbij het bijhouden van het type-nummer al voldoende kan zijn. Een tijdbesparend alternatief kan zijn om verschillende samenstellingen van systemen vast te leggen, waarbij je een soort eigen type-nummer creëert.
Het beste is dan natuurlijk om gelijke systemen neer te zetten voor zowel productie als in de acceptatie-testomgeving waarop je de performancetesten uitvoert en slechts schaalt op het aantal systemen in beide omgevingen waarover de load wordt verdeeld.
Schalen om te besparen blijft altijd echter een overweging die niet licht genomen moet worden, zeker niet bij high-risk-applicaties. Schalen betekent namelijk altijd dat je niet met de werkelijke productie-piekload kan testen en dus bottlenecks in productie kan missen, wanneer er een hogere load dan de getestte load de keten belast.
Conclusie
Voor het vaststellen van de risico’s die overblijven door het testen op een production-like-omgeving en het vaststellen welke delen uit een keten je mee gaat nemen in de performancetesten (scope) kan een goed opgezet configuration-management-systeem veel tijd besparen. Een valkuil is dat het systeem te veel tijd kost en daardoor niet efficiënt gebruikt wordt. Bedenk dus goed hoe je het meest efficiënt gegevens kan koppelen om met het registreren van zo min mogelijk gegevens zoveel mogelijk informatie kan achterhalen.
Wellicht interessant: https://www.interlinksoftware.com/configuration-management/
Dit systeem ken ik zelf niet, maar de website geeft een aardig beeld van wat je ermee kan. Indien jij, als lezer, ervaring hebt met dit systeem ben ik erg benieuwd naar ervaringen.
In mijn volgende blog wil ik kort ingaan op de SCRUM-ontwikkelmethode in combinatie met beheer volgens ITIL.
