Application Performance Management 2.0: Få kontroll på responstiden

Vet du hva sluttbrukerne dine opplever av responstider på dine mest kritiske forretningstransaksjoner? Hadde det ikke vært greit å ha det på ett dashboard? Her er et praktisk eksempel.

Å drive med ytelsesmålinger i et produksjonsmiljø var tidligere en stor teknisk utfordring. Mange spilte inn de mest kritiske forretningstransaksjonene med forskjellige skript-verktøy og spilte dem av med en gitt intervall på roboter som gjerne stod nede i datahallen, eller i beste fall spredd rundt på noen avdelingskontorer.

Ofte så endte man ikke opp med å måle de viktigste forretningstransaksjonene, for de var for vanskelige å gjenskape. Dermed endte man opp med å måle innlogging og et par enkle oppslag.

Så for omtrent 10 år siden begynte det å dukke opp løsninger som kunne ta en kopi av nettverkstrafikken, dekode det og kalkulere seg frem til responstid på enkle URL’er og databasespørringer. Dette krevde store servere, prober og meget eksakte nettverksspeilinger for å få det hele til å fungere sammen.

Denne måten å måle ytelse på ble kalt «Real User Monitoring». Det fungerte ganske bra så lenge vi hadde et datasenter og hovedsakelig fysiske servere. Når så verden de siste fire-fem årene har blitt mer og mer virtualisert, og stadig flere deler av tjenestene flyttes ut av datahallen i kjelleren og opp i skyen, så blir denne måten å måle ytelse på ganske utfordrende, og til tider umulig.

Velkommen til Application Performance Management 2.0

Gjør du et søk på erfaringer bedrifter har hatt med ytelsesmålinger, som regel kalt Application Performance Management (APM), så finner du mye negativt. Det er vanskelig å måle, tidkrevende, og svarene på hvor ytelsesproblemene ligger er ikke alltid overbevisende eller klare.

De siste årene har vi sett en ny generasjon med Application Performance Management-verktøy stige frem. Disse verktøyene baserer seg på å installere agenter på selve applikasjons-serverne. De går inn i selve rammeverket til applikasjonen din og måler med imponerende nøyaktighet hvor raskt applikasjonen din responderer og hvor i kildekoden din problemet er når ting går tregere enn normalt.

Ikke nok med det, verktøyene er veldig enkle å installere og komme i gang med. Vi snakker nå om timer før vi ser verdi, ikke dager eller uker. Verktøyene spytter også ut automtisk genererte forretningstransaksjoner og flytdiagrammer.

Her er ett reelt eksempel på flytdiagram generert av APM-verktøyet AppDynamics:
AppDynamics_Application_FlowMap

Når noe går tregt her, så kan man automatisk drille ned og se eksakt hvor responstiden forsvant hen:
AppDynamics_CallDrillDown

Dette ser vi raskt at passer svært godt inn i en DevOps-verden. Grensene mellom utvikling og drift viskes ut og man får et grensesnitt der utvikling og drift kan jobbe sammen med det samme datagrunnlaget.

Ikke er de nye Application Performance Management-verktøyene spesielt dyre heller.

Så hvor er utfordringen?

Det er jo alltid en hake, ikke sant!?

Vel, ikke teknisk, utfordringen nå blir å prioritere hva du skal fokusere på. Hvis vi tar eksempelet med AppDynamics, så gjør dette verktøyet automatisk oppdagelse og definisjon av forretningstransaksjoner. Det kan dermed fort bli opp mot 200 transaksjoner å holde styr på. Da er det umulig å prioritere og fokusere.

Derfor er utfordringen nå å kartlegge og prioritere hva man skal fokusere på. Ideelt bør man begrense antall transaksjoner ned til de 10-20 viktigste.

Undertegnede har nylig implementert AppDynamics hos en kunde på ikke mindre enn syv forretnings-applikasjoner. For hver applikasjon har jeg hatt møter med applikasjonseier fra IT, leverandørene av applikasjonene og med superbrukere som faktisk bruker applikasjonene og har pulsen på hva som er viktigst for dem.

Resultatet er at vi nå overvåker mellom 10-20 forretningstransaksjoner per applikasjon. Samtidig har vi dashboards som henger på storskjermer i lokalene som kun fokuserer på de fire til fem aller mest kritiske transaksjonene i hver applikasjon. Fokuset er på transaksjonene som, hvis de ikke fungerer, koster bedriften reelle kroner og øre.

Her er dashboardet for en av applikasjonene:
AppDynamics_Dashboard

Det vi ser her er en nettbutikk der vi har definert de fire viktigste transaksjonene sluttbrukerne utfører. Vi ser i grønt hvor mange transaksjoner som utføres akkurat nå med tilfredstillende responstid, så har vi satt terskelverdier for trege og veldig trege transaksjoner, dette visualiseres i oransje og rød farge. Tilslutt så rapporterer vi også på antall artikler kundene klikker på, som ikke lenger finnes.

Her kan vi potensielt hente ut hvilken kunde det er som ikke fant varen, og kontakte kunden med riktig URL eller alternativ vare. Mulighetene for å oppdage hvor responstids- og tilgjengelighetsproblemer koster oss penger er enorme, men det er også muligheter for å automatisere handlinger som kan rette opp situasjonen som har oppstått.

Vi har et stort team med erfarne APM-konsulenter fra Sopra Steria som kan hjelpe deg med å levere god ytelse fra første stund til dine brukere. Ta kontakt med meg, så snakker vi mer om det.

Gaute er ansatt i Sopra Steria som senior løsningsarkitekt og faggruppeleder innen det vi kaller Application Intelligence & Monitoring. Han har over 18 års erfaring og har jobbet i Sopra Steria siden 2011.

En kommentar om “Application Performance Management 2.0: Få kontroll på responstiden

Legg inn en kommentar