Mercury er en stigende stjerne blant programvarehus, og satser på et felt de selv har definert: optimering av IT i næringslivet, eller «business technology optimization». Selskapet var tidlig ute med å forstå at optimering av e-handel og transaksjonsorienterte systemer må ta utgangspunkt i det sluttbrukeren opplever. En bekreftelse på at alle ledd i kjeden virker som de skal, betyr ikke nødvendigvis at sluttbrukeren får den responstiden som er lovet i tjenestegarantiavtalen.
De ulike produktene Mercury har utviklet, inneholder alle diagnoseverktøy for kode og applikasjoner. I det nye produktet Mercury Diagnostics er alle diagnoseverktøyene samlet under ett, og kan brukes enten uavhengig av, eller integrert mot, Mercury-produktene LoadRunner, Performance Center og Business Availability Center.
– Fordelen med ett enhetlig diagnoseverktøy, er at man kan følge en applikasjon gjennom hele dens levetid, mener Espen Thilesen i Mercury Norge.
Thilesen forklarer at Mercury prøver å løse mange av de utfordringene som stilles i forretningsorienterte utviklingsmiljøer: Applikasjonsmiljøene blir mer og mer kompliserte, samtidig som utviklingstiden må kortes ned og det er et press for å sette ting ut i produksjon så fort som mulig.
– Det er stadig mer nødvendig å løpende utvikle applikasjonen mens den er i produksjon. I noen miljøer må IT-avdelingen forholde seg til hundrevis av applikasjoner. Det å støtte opp om den enkelte applikasjonen, er i ferd med å utkrystallisere som en egen rolle.
Thilesen peker også på hvordan stormaskinutviklere omskoleres til Java og .Net, slik at utviklingsmiljøet gjerne består av to grupper: de unge og nyutdannede, og de eldre og konverterte.
– Problemene denne utviklingen skaper blir veldig synlig når man er i en produksjonsfase. Alle flyr rundt for å prøve å finne ut hvor et gitt problem er. Det er ingen systematisk og enhetlig tilnærming, og det tar gjerne lang tid å få applikasjonen i gang igjen.
Mercurys nye diagnoseverktøy er bygget rundt en tretrinns metode for å gjøre det raskere å finne fram til hvilke årsaker som gjør at ting detter ut. Det overvåker at tjenestene er tilgjengelige – og varsler når for eksempel responstiden overskrider en viss terskel – siler seg gjennom alle leddene som transaksjonen må forbi, og stiller en diagnose der det faktisk er et problem.
– Overvåkingen («monitor») skjer fra tre perspektiver: bruker, applikasjon og infrastruktur. Vi legger opp målinger og terskelverdier for å fange opp problemer før de utløser skade på forretningsprosessen.
Siling («triage») betyr å gå gjennom transaksjonen fra sluttbruker, gjennom webtjener og applikasjonstjener og til databasen eller det bakenforliggende systemet, og finne ut nøyaktig hvor problemet oppstår. Denne prosessen gjør det blant annet mulig å finne fram til bestemte SQL-erklæringer som i en gitt situasjon gir nedsatt ytelse.
– Siling innebærer at vi måler hvor mye tid som tilbringes på klienten og på de ulike applikasjonslagene. Vi ser for eksempel at tiden på databasen er økt med x sekunder. Vi finner ut hvilken silo som sinker.
Siling er en kritisk operasjon der man har applikasjoner som står i produksjon kontinuerlig, samtidig som de endres mange ganger hver dag.
– I en bank kan det gjerne tillempes over 500 endringer i portalen i løpet av et år. Det eneste som blir konstant i et slikt miljø, er tjenesten som skal leveres. Man trenger et diagnoseverktøy som kan forklare hvorfor et søk som i en testsituasjon kunne gjennomføres på fem sekunder, plutselig tar ti i praktisk produksjon.
Thilesen mener at i en slik situasjon er det meningsløst å skille skarp mellom drift og utvikling. De to rollene krever ett diagnoseverktøy, slik at de kan lære av hverandre og tilføre hverandre kompetanse.
– Diagnose innebærer å ta de vanskeligste problemene innen utvikling og drift, særlig problemer som kommer og går, og som skyldes minnelekkasjer, synkronisering eller dataavhengige problemer. Vi kan lokalisere helt ned til en bestemt kodelinje der et problem oppstår. Det får vi til selv under tung belastning i produksjon, og vi fanger opp nøyaktig alle involverte parametere.
Verktøyet kan brukes på Java-miljøer, .Net-miljøer, og på miljøer dominert av ERP eller CRM.
