Vele organisaties onderschatten het belang van een testomgeving waarop een wijziging in de infrastructuur getest kan worden. Een recent voorbeeld helpt hopelijk om de neuzen weer in de juiste richting te krijgen. De ‘Commonwealth Bank of Australia’ legde met een foute patch een groot deel van de desktop en server infrastructuur plat.
Hoewel het in wezen een fout in de distributiemethode bleek, waarbij een patch bedoeld voor slechts een kleine hoeveelheid desktop pc’s op een groot deel van alle desktop pc’s en servers werd uitgerold, is dit toch voor een deel toe te schrijven aan het niet goed testen. Had men er tijd in gestoken om te achterhalen wat de impact zou zijn als de patch op het verkeerde systeem zou worden uitgerold, dan hadden ze waarschijnlijk veel beter opgelet bij het uitrollen van deze update, want “Testen is het bepalen van een risico! Hoe beter er getest wordt, hoe kleiner het risic”.
Risico afwegingen. Tijd, geld en kwaliteit.
Ook binnen het testen komt de duivelsdriehoek weer om de hoek kijken. Deze driehoek bestaat uit Geld, Tijd en Kwaliteit. Als er aan één van deze drie word getrokken, heeft dit gevolgen voor de andere. Oftewel: Minder tijd of geld resulteert in mindere kwaliteit. Hogere kwaliteit kan alleen met meer tijd en dus ook meer geld. Het verwachtte risico kan een tester helpen in het bepalen van deze resources. Ervaring en kennis van de omgeving is dan ook een pre in een goede tester.
Niet alleen goedpaden, maar ook foutpaden.
Bij het uitvoeren van een test, wordt er vaak alleen maar naar de goedpaden gekeken, terwijl er juist ook vaak naar de foutpaden moet worden gekeken. Binnen de infrastructuur houdt dat in: Niet alleen maar uitgaan van een correcte installatie op de juiste servers, maar dus ook een mislukte installatie op de foutieve servers. Wat is de impact daarvan? Is deze server nadien nog bruikbaar? Dit zijn manieren om een correcte risico inschatting te kunnen doen.
Testomgeving en Productieomgeving.
Veel bedrijven hebben gelukkig het licht gezien, en hebben een Ontwikkel, Test & Acceptatie-straat (OTA) ingericht. In principe wordt er getest in de Testomgeving om te controleren of de systemen na de update of wijziging technisch nog functioneren. Dit is de zogeheten systeemtest die uitgevoerd wordt door een tester of een techneut. Daarna wordt er een acceptatietest gedaan om te controleren of er nog steeds gewerkt kan worden met de systemen na de update of wijziging. Deze acceptatietest dient uitgevoerd te worden door een senior gebruiker of een functioneel applicatiebeheerder. Alle onderdelen die geraakt worden met een wijziging dienen getest te worden. Hoe breder de test, hoe kleiner het risico.
De testomgeving behoort op functioneel vlak een kopie te zijn van de productieomgeving. Dat is een punt waar het vaak fout gaat. Er wordt aan alle kanten bespaard op de testomgeving. Minder servers, andere – vaak goedkopere – storage, en vele meer consolidatie van applicaties op de servers. Verouderde besturingssystemen, geen of verouderde antivirus oplossingen zijn veel te vinden in een testomgeving. Op capaciteit behoeft de testomgeving niet gelijk te zijn met de productieomgeving, er zijn immers nooit zoveel gebruikers aanwezig op als in de productieomgeving. Maar voor wat betreft de gebruikte hardware en software zou deze wel gelijk moeten zijn. Juist vanwege het correct kunnen testen van een infrastructurele wijziging.
Testplannen?
Wat moet er getest worden? Hoe gaan we het testen? Dit zijn zaken die horen te zijn beschreven in een testplan. T-MAP houdt daarbij zelfs een overkoepelend Mastertestplan aan als paraplu-document voor alle andere testplannen. Het correct volgen van een goed geschreven testplan zorgt weer voor een hogere kwaliteit van de uitgevoerde test.
Plan, Do, Check & Act.
Elke wijziging in de infrastructuur behoort getest te worden. Echter, deze wijziging heeft nog veel meer omhanden. Alle testplannen, test- en acceptatieomgevingen behoren gecontroleerd en bijgewerkt te worden. Het testen van een oudere versie van een applicatie heeft geen nut, als er in de productie een nieuwere versie wordt gebruikt.
Goed testen hoort bij een correcte invulling van beheer, en zorgt uiteindelijk voor een hogere kwaliteit en ook beschikbaarheid van de ict-infrastructuur. Het is dan ook raadzaam voor bedrijven om deze functie goed te beleggen, en voldoende tijd te reserveren voor het uitvoeren van testen.
Hier wil ik eigenlijk niet eens meer woorden aan vuil maken. Al meer dan 30 jaar behoort het tot professionaliteit om minimaal volgens het OTAP principe te werken. Wie dat nu nog niet weet of gewoonweg niet doet is geen knip voor de neus waard.
Erik,
Mooi onderwerp vooral na wat er op 19 juni bij RBS fout ging.
Het doorvoeren van een wijziging volgens OTA is zeker een “must” maar geen garantie voor de juiste werking van het systeem in de productie. Bijvoorbeeld een databaseserver die na een update en OTA geen rare dingen heeft vertoond zou in de productie wanneer 300 gebruiker er gebruik van gaan maken met verschillende foutmeldingen terugkomen. Hoe lost je dit snel op?
Het uitvoeren van OTA kent o.a. deze problemen:
-Hoe maak je een kopie die 100% gelijk is aan het betreffende productiesysteem,
-Hoe kun je het systeem exact als in de productie uittesten en belasten (test door een sr.user of applicatiebeheerder is niet voldoende),
-Hoe weet je wat het effect van deze wijziging is op andere systemen die direct of indirect van dit systeem afhankelijk zijn (je test alleen deze server en niet de rest van je productie)
-Hoe kun je alle wijzigingen in deze drie fase (OTA) goed documenteren om dit in productie uit te voeren.
Ik mis in je artikel nog een onderdeel! Roll Back scenario.
Heb je dit allemaal goed gedaan dan is de vraag hoe kun je een goed roll back scenario realiseren waarmee je snel en zonder verdere verstoring in de productie naar het originele systeem terug kan gaan!
Met andere woorden, hoe kun je gehele OTA van A tot Z automatiseren (inclusief roll back secnario) in korte “tijd” met hoge “kwaliteit” en “betrouwbaarheid”?
Citrix heeft hier een antwoord op: Citrix Provisioning Server
Met Provisioning Server kun je altijd binnen een aantal minuten:
-Een exacte kopie trekken van je productie server (bijvoorbeeld je Oracle database),
-Wijzigingen doorvoeren en na eerste test(en) in de productie opnemen,
-Als het niet goed gaat snel en binnen een paar seconden teruggaan naar het oorspronkelijke systeem (of zelfs x versie verder terug)
Uiteraard zijn er andere oplossingen waarmee je min of meer dezelfde doel kan bereiken.
P.s voor degene die niet bekend is met Citrix Provesioning Server, dit product heeft niks te maken met de overige producten van Citrix zoals XenApp, Xen, XenDesktop etc, dit kun je altijd los aanschaffen.
@Ronald, true: Maar helaas komt het nog altijd voor dat er te weinig tijd wordt gestoken in het goed en gestructureerd testen. Maar bedankt voor je reactie.
@Reza: Mijn stuk ging vooral over het testen van een wijziging om het risico te verlagen. Het verzinnen van een rollback scenario valt imo onder het kopje ‘Change Management’. En dat staat hier dan weer even los van (hoewel het natuurlijk wel met elkaar te maken heeft).
Overigens is dit in de huidige virtuele wereld nog veel makkelijker, daar je of op hypervisorniveau, of op storageniveau een exacte kopie van de server of omgeving kan maken voorafgaand aan de wijziging. Gaat het fout, dan zet je de kopie terug. Gaat het goed, dan verwijder je de kopie weer. Natuurlijk is dit heel simplistisch gezegd, maar het gaat dan om het idee.
Dit vereist wel een goede gestructureerde manier van beheer.
Een compleet testprocedure bestaat uit OTA+P. Met het oog op wat er in de P-fase gaat gebeuren, worden verschillende activiteiten verricht, een daarvan is rollback activiteiten. Uiteraard kun je dat doorschuiven naar CM-fase maar als het zover is dan komt het weer bij de terug.
Een rollback kun je inderdaad met virtualisatie realiseren. Maar er zijn genoeg organisaties die nog geen virtualisatie ingevoerd hebben of beschikken over virtualisatie maar dat niet voor bepaalde systemen willen gebruiken (van wege hoge kosten van productlicentie in de virtuele omgeving zoals Oracle)
@Ronald,
Ik wil bepaald niet stellen dat je ongelijk hebt, maar je diskwalificeert nu wel het overgrote deel van je vakgenoten wegens een feit waar zij meestal niet de zeggenschap over hebben.
Dit artikel is een open deur. Organisaties die niet testen zijn niet volwassen. De investeringen in een OTA straat, de P heb je al, vallen weg tegen de risico;s die worden gelopen als gevolg van downtime of andere malheur. Met virtualisatie is de inrichting van een OTA straat makkelijker, met name als je gebruik maakt van de gratis hypervisors in de OT straat, ook roll-backs en roll forwards zijn eenvoudiger.
Ik ben principeel tegen het testen van situaties die normaal gesproken in professionele organisaties, met juist change management, niet voorkomen. Dit is tijdverspilling, verleng de testprocedure en vergt veel oplosstijd, wat ga je met de resultaten doen, het werkt niet, maar dat had je al kunnen verwachten.
Dus steek je tijd in de juiste testcases en changemanagement.
Voor de testmethode zou ik gebruik maken van Tmap, er is sinds kort een officiële versie van Tmap infrastructuur, gratis te downloaden bij Sogeti, de moeder van Tmap. Dit is nuttiger dan zelf iets gaan bedenken zoals de schrijver suggereert.
Tijd, geld & kwaliteit, maar voeg daar ook competentie en kunde aan toe.
Daarnaast is OTAP ook gewoon een kosten afweging. Er zijn ook methoden mogelijk waarmee je niet per se een scheiding hoeft te maken tussen ontwikkel / test en acceptatie gewoon op productie kan plaatsvinden. Zeker als je een zeer krachtige roll-back methode hebt zoals Reza al schrijft.
Per situatie kun je een ander scenario prefereren. Standaardisatie is een krachtig principe en zou voor standaard zaken zoveel mogelijk ingezet moeten worden.
Maar alles OTAP-pen uit principe is gewoon een kostbare en niet efficiente zaak. Traditioneel en deels achterhaald.
Met OTAP kunnen zaken gewoon nog prima in het honderd lopen. Ik heb liever scherpe mensen dan scherpe procedures…