De flesta prestandatester utförs i en dedikerad miljö, just för att kunna upprepa testerna för applikationsändringar och/eller infrastrukturförändringar och se om dessa håller måttet i kommande produktion.
Dagens applikationer blir mer och mer komplexa i så motto att det finns beroenden till andra system. Vid prestandatester i dedikerad prestandatestmiljö löser man det oftast med ”stubbar”, dvs program som ”simulerar svaret från den externa källan. Fördelen är ju att du kan genomföra testerna, men nackdelen är ju att du förenklar verkligheten.
Ovanstående kombinerat med att det finns utmaningar att efterlikna produktionsmiljön i testmiljön, exempelvis exakt konfigurering i infrastrukturen, gör att vissa frågeställningar som verksamheten söker svar på kan tacklas/kombineras med andra tester än de tradionella prestandatesterna/redundanstesterna i dedikerad miljö.
Jag vill ge två exempel på frågeställningar när test i produktion kan vara en fördel.
Kontrollera redundansen, eller vad händer om redundant enhet slutar fungera samt vad händer vid volymökning.
Kontrollera redundansen
I de flesta applikationer finns det infrastruktur som skall klara av så pass enkla scenarier som att om en webbserver, filserver, databasserver, switch, brandvägg, etc. etc. fallerar, skall användaren inte drabbas av detta.
Visst, innan produktionssättning utfördes säkert tester med ovannämnda scenarier, som bekant så ändras infrastruktur och applikationer under tiden, detta kan påverka redundansen.
Vad händer vid volymökning
I de flesta fall har prestandatester i dedikerad prestandatestmiljö utförts och man vet konsekvenserna av ökad volym, exempelvis ökning av antalet besökare på webbsiten, ökande batchbearbetning i kombination med onlinetrafiken etc. etc. Men även här har vi verkligheten, att applikationer/infrastruktur ändras och som alternativ/komplement till prestandatester i dedikerad miljö så kan man utför dylika tester i produktion.
Så nu är det bara att göra testerna i produktion 🙂 , eller ?
Tänk på följande innan:
– Du har mätningar i realtid i produktion inom nivåerna servrarnas hälsa (cpu,ram, I/o), operativsystemens hälsa inklusive databas, applikationens hälsa, aktiv samt passiv övervakning av slutanvändarnas svarstider, dedikerade robotar/program som läser av hälsan direkt mot en webserver (istället för att gå via exempelvis lastbalanseraren).
– Du har gjort upp en plan när testerna skall utföras och har försäkrat dig om att alla ”experter” är på plats.
– Du har en uppgjord handlingsplan, om det är så att vissa mätparametrar börjar nå kritiska siffror, action sker exempelvis avbryt testerna. Och kritiska siffror har du fått från tidigare prestandatester.
– En general leder arbetet och har kontakt med alla intressenter under testets gång.
Sammanfattning.
Det är bättre att under kontrollerade former finna defekter än att dessa uppdagas kl 03 00 på lördag morgon. Chaos monkey (https://en.wikipedia.org/wiki/Chaos_Monkey) då det gäller redundansen, utnyttjas av Netflix, det finns dock mellanlägen … 🙂 Kontakta oss på Lights In Line så kan vi ha en förutsättningslös diskussion i ämnet.
