torsdag den 25. oktober 2012

Periodiske fejl


Nogen gange kan man som tester være så heldig at komme i berøring med fejl som kun viser sig periodisk. Når jeg siger heldig, så er det med en smule ironi, for disse fejl kan være utroligt svære at finde, netop på grund af deres periodiske natur. Det er dog altid spændende at se hvor disse periodiske fejl fører en hen og ikke mindst hvad løsningen på dem er.

Når man har med periodiske fejl at gøre, så er det mønsteret på hvornår de opstår der er vigtigt at følge, men end det egentlige symptom. Grunden til dette er at fejlsituationer aldrig opstår af sig selv, de skal trigges af et eller andet, og det er triggeren der er vigtig at finde. Hvis fejlen syntes at dukke op uden noget som helst mønster, er det bare fordi du ikke har gennemskuet mønsteret endnu.
Årsagen til at jeg understreger det med mønsteret er at hvis ikke du kan redegøre for nøjagtigt hvorfor den periodiske fejl er opstået, og det kan du kun når du kan forklare dens mønster, så kan du heller ikke være sikker på at den fix der er blevet lavet løser problemet fuldt ud. Mønsteret er derfor super vigtigt i forhold til at vide om man har fundet rod årsagen til problemet.

På det projekt jeg arbejder på i øjeblikket var der ikke en men tre periodiske fejl i sidste uge. Da vi nærmer os en release så bliver vi nød til at fange disse problemer og få dem løst inden vi skal i produktion, så der var idømt bug klapjagt.

Første periodiske fejl havde symptomet at en service operation af og til fejlede med en datafejl selv om alle data var til stedet og valide. Efter kyndig granskning af diverse dataload routiner kunne fejlen konstateres ved at man havde glemt at bede om et enkelt datasæt i en ordnet rækkefølge. Det bevirkede at service operationen i langt de fleste tilfælde opførte sig fint, men i ca et ud af halvtreds gange fejlede den da data blev loadet i en anden række følge. Løsning: tilføj en "ORDER BY" til SQL udtrykket og den var 100% løst.

Anden periodisk fejl havde symptomet at et kald til et eksternt system fejlede hver anden gang. I starten var vi meget fokuseret på om det var en round-robin loadbalancer eller lignende hvor 50% af den underliggende kapacitet var nede. Dette blev dog gjort til skamme da der godt nok var en loadbalancer, men at der kun var en node bag ved loadbalanceren. Vi vidste imidlertid at loadbalanceren var baseret på Apaches mod_balancer som i nogen tilfælde kan være noget buggy hvorfor vi valgte at kører uden om den og direkte på den bagvedliggende node. Dette løste problemet, og vi kunne derfor kaste os over at finde ud af hvad der var i vejen med loadbalanceren. Roden til problemet viste sig at være at loadbalanceren ikke var sat op til at kunne håndtere HTTP1.1 KeepAlive forbindelser. Løsning: Opdateret konfiguration af loadbalanceren til at understøtte KeepAlive forbindelser.

Tredie periodiske fejl havde symptomet at integrationen til et eksternt system af og til droppede netværksforbindelsen. Dette var en fejl vi havde set før, og også løst før, men nu tilsyneladende var tilbage. Det er naturligvis mest nærliggende at kigge på den tidligere løsning for at se om der er noget der er ændret. Det viste sig at der var noget der var ændret. En exception type var blevet ændret hvilket gjorde at den tidligere udviklede fejlretning var blevet deaktiveret. Ved hurtigt at ændre tilbage kom den tidligere fejlrettelse på banen igen.

Der er blevet brugt mange timer på at finde ud af hvad der var fejlen bag ved disse tre fejlsituationer. Men det der er det vigtige er at der er blevet gravet hele vejen ned til man har fundet rod problemet, for kun der kan man nogen lunde sikkert sige at fejlen er løst. Hvis vi ikke havde hundet rod årsagen, og problemet var gået i sig selv igen, ville det jo ikke være til at vide hvornår det dukkede op igen.
Det skal også siges at det på ingen måde er nemt at finde disse periodiske fejl, og det at det lykkedes skyldes det høje kompetence niveau hos den gruppe af udviklere der stod for at finde og rette disse fejl.