Det var en gång...

Flera decennier inom QA ger en del dråpliga och insiktsgivande berättelser att förmedla. För min egen skull har jag börjat beskriva en del av dessa här.

Detta är en av dem.

Sub-optimala prestandatester i deployflödet

När jag jobbade i ett team på ICA insåg vi att många av våra problem i både test och i prod uppstod på grund av missade eller felaktiga manuella handgreppsfel i deployflödet när vi gjorde nya releaser.

Jag föreslog att vi skulle försöka scripta upp deployen för att slippa detta och försåg de seniora utvecklarna med verktygsstöd för detta och någon vecka senare hade vi en mycket stabilare deploy-förfarande.
Detta var några år innan någon av oss hade hört om CI/CD eller liknande men vi tyckte att det funkade bra och vi fick mycket bättre stabilitet i våra förfaranden.

Det visade sig snart att vi nu behövde börja versionshantera dataschemaändringar och sådant också så det medförde en del nya utmaningar, men inget som var olösbart.

Vi lade till och med in automatisk exekvering av vissa smoketester i detta deploy-flöde och då tänkte jag att det vore fiffigt att ta med lite prestandatester i detta flöde också.

Jag hittade ett prestandatestverktyg som kunde exekvera från command-line och vi satte igång att scripta upp tester av standardflödet och införliva även dessa i delploy-proceduren.

Det verkade gå bra och vi kände oss allt mer trygga i att releasa ofta och tryggt.

...tills det plötsligt small en dag.

Plötsligt gick systemet ner. Det visade sig vara prestandaproblem. Ytterligare analys visade att prestanda var superbra i huvudflödena. Eftersom det var samma prestandatester som gick hela tiden var huvudflödena supertrimmade. Däremot hade vi lagt till en del ny funktionalitet och ingen hade uppdaterat prestandatesterna till att testa även dessa för prestanda.

Det visade sig att det snabbt blev lås i databasen (inte deadlocks, men läslås när samma DB-poster läses väldigt mycket) när flera använde denna funktionalit samtidigt.
En annan gång var det ett metodanrop till en extern tjänst som plötsligt sändes fyra gånger för varje transaktion istället för en gång som tidigare. Det simulerade inte våra färdiga script alls - och hade inte någon möjlighet att göra det heller.

Min tilltro till prestandatester i byggflödet har för evigt tagit en törn av denna upplevelse.

Det bästa alternativ jag faktiskt har hittat är det sätt att prestandatesta nattens bygge som vi använde på Thomas Cook. Där snapshotades databasen i produktion klockan 8 varje kväll och kopierades till en specialtestmiljö, och alla transaktionerna i webbfrontarna strömmades ner på disk. Klockan tio spelades alla dessa inspelade transaktioner upp på specialtestmiljöns frontend-servrar och man kollade hur lång tid det tog för dessa att komma igenom hela flödet och vilka fel som uppstod i loggarna.

Lärdom