Suorituskykyvaatimukset järjestelmäarkkitehtuurin suunnittelussa

Timo Suominen / Up The Sleeves
Copyright © KONE Corporation
Globaali liiketoiminta vaatii
suorituskykyiset tietojärjestelmät
KONE Oyj on piristävä poikkeus haastavassa globaalissa taloudellisessa tilanteessa.
Liiketoiminnan kasvaessa on selvää, että myös tuotekehityksen ja sitä tukevien ICTpalveluiden tulee toimia yskimättä - ollen mielellään jopa askeleen, pari edellä vallitsevaa kysyntää. Tästä johtuen KONE Oyj:n tuotetiedon ja tuotteen elinkaarenhallinnassa
(PDM/PLM) onkin merkittävästi panostettu järjestelmien suorituskyvyn suunnitteluja testausprosessiin (Performance Testing & Engineering process). Yrityksen noin
12.000 PDM/PLM-käyttäjän verkosto kattaa koko toimitusketjun tuotekehityksestä
aina myynnin ja tuotannon kautta kunnossapitoon sekä alihankintaverkostoon asti.
8
Valokyna_1_2015.indd 8
Valokynä 1/2015
21.3.2015 9:40:31
Y
rityksen Global Development
-toiminto vastaa liiketoimintaa tukevien prosessien ja tietojärjestelmien kehityksestä. Konfiguroituvien
tuotteiden, tietomallien ja varsin
mittavien tuoterakenteiden hallinta
ovat haaste tuotekehityksen (Solution Creation) ja tilaus-toimitus
(Delivery) prosessien, kuten myös
tietojärjestelmien suorituskyvyn
osalta. Global Developmentissa
elintärkeää ovat erityisesti liiketoiminnan jatkuvuuden varmistaminen
(business continuity) sekä R&D volyymien kasvaessa, globaalien tietojärjestelmien suorituskyvyn takaaminen. Proaktiivinen järjestelmän
monitorointi ja ennalta määritellyt
suorituskykymittarit (KPI, Key Performance Indicator ) antavat vankan
perustan liiketoiminnan tukemiselle.
Oikeat mittarit ja tulokset
Järjestelmämielessä nopean reagoinnin edellytyksenä on, että on
valittu oikeat KPI:t seurantaan
sekä määritelty niille tavoitearvot.
”Mittareita määritettäessä tulee tunnistaa potentiaaliset suorituskyvyn
pullonkaulat liiketoimintaprosessissa, yleisyys, toistuvuus ja asettaa
ensisijaiset mittarit niiden seurantaan”, toteaa Pekka Puurunen,
KONE Oyj:n PDM Solution Owner .
Seuraavaksi luodaan vastaavat
käyttötapaukset ( use case ), joille
määritellään lähtöarvot ( baseline )
ja tavoitearvot kokemusten myötä.
Mittareita seurataan systemaattisesti, jotta poikkeamiin voidaan
reagoida nopeasti. KONE:een
t u o t e t i e d o n h a l l i n n a s s a m i t t a re i na toimivat muun muassa tietyn
h i s s i n k o n f i g u ro i n t i a i k a , e n n a l t a
määritellyn tuotteen tuoteraken-
Tehtyjen Performance Engineering &
Testing -aktiviteettien avulla voidaan
varmistaa ja jopa parantaa tuoteprojektien läpimenoaikoja riittävällä
suorituskyvyllä esimerkiksi tuotekonfiguraatioiden testauksessa
sekä varmistaa tilaus-toimitus prosessin toimintavarmuus. Saatavuus
tavoitteena pidetään 99.5 % rajaa.
Kohti tulevaisuutta
Kaiken tämän PDM/PLM-kehityksen mahdollistajana on yhtiön
yritysjohto, jonka kanssa kehityksen prioriteeteista ja linjauksista
käydään säännöllistä ajatustenvaihtoa kehitys- roadmap ja -portfolio
t a so l l a . Ko s k a m a a i l m a a k a a n e i
tunnetusti rakennettu päivässä,
valmistaudutaan PDM/PLM-järjestelmäkehityksessä jo tulevaisuuden
haasteisiin. ”Muutamia tulevaisuuden kehitysalueita ovat muun muassa valmistautuminen volyymien,
datamäärien ja konfiguraatioiden
kasvuun, PDM/SAP -rajapinnan
kehittäminen sekä mobiili- ja pilvipalveluiden käytön laajentaminen.” listaa Puurunen lopuksi.
Globaalius ja liiketoiminnan
kasvu
Yritysten liiketoimintaympäristö
on muuttunut yhä globaalimmaksi. Toimipisteet sijaitsevat usealla
mantereella, maantieteelliset etäisyydet ovat suuria ja yrityksen
liiketoiminnan tulee pyöriä kellon
ympäri. Yritykset myös verkostoituvat entistä enemmän ja tietoa
pitää pystyä jakamaan turvallisesti
ja hallitusti. Tuotteet ja palvelut
ovat yhä monimutkaisempia ja
täten syntyvän- ja myös tarvitta-
”Suunnittelematon käyttökatko aiheuttaa merkittävät kustannukset”
teen avaamisaika sekä vakioidun
hakutoimenpiteen suorittaminen.
Näitä seurataan monitorointipalvelun avulla ja reagoidaan, mikäli
trendissä alkaa näkyä poikkeamia.
PDM:n ja siihen rinnastettavien
oheisjärjestelmien saatavuus ( availability ) on muunnettavissa myös
rahaksi tuottavuuden kautta. ”Mikäli
järjestelmän globaalissa saatavuudessa esiintyy suunnittelematon
käyttökatko, ovat tuottamattomuuden kautta kustannukset merkittävät”, arvioi Pekka Puurunen.
van informaation määrä kasvaa
vuosittain. Lisäksi yhä enemmän
yritykset myös markkinoivat ja
myyvät tuotteitaan internetissä.
Mitä on hyvä suorituskyky?
Va a t i m u k s e t t i e t o j ä r j e s t e l m i e n
suorituskyvylle ovat haastavia ja
niiden toteuttaminen vaatii monesti
suuria ponnistuksia ja yhteistyötä.
Suorituskyvyn testauksella ja jatkuvalla monitoroinnilla saavutetaan
useita rahalla mitattavia hyötyjä.
KONE Oyj kuuluu alansa johtaviin yrityksiin ja tarjoaa asiakkailleen edistyksellisiä hissejä,
liukuportaita ja automaattiovia
sekä monipuolisia ratkaisuja
niiden huoltoon ja modernisointiin. Eri asiakasryhmien
tarpeiden ymmärtäminen on
ohjannut yhtiön toimintaa jo
sadan vuoden ajan.
KONEen tavoitteena on tarjota paras käyttäjäkokemus
kehittämällä ja toimittamalla
ratkaisuja, jotka mahdollistavat
ihmisten liikkumisen rakennuksissa sujuvasti, turvallisesti,
mukavasti ja viivytyksettä yhä
enemmän kaupungistuvassa
ympäristössä. Vuonna 2014
KONEen liikevaihto oli 7,3 miljardia euroa ja henkilöstömäärä
vuoden lopussa yli 47 000. Yhtiön B-sarjan osake noteerataan
NASDAQ OMX Helsinki Oy:ssä.
KONE:lta artikkeliin haastateltiin
Solution Owner (PDM and R&D
Management Solutions), Pekka
Puurusta, joka vastaa PDM/PLMalueen järjestelmäkehityksestä
osana Global Development:ia.
Näin ollen tietojärjestelmän muutospäätös voidaan tehdä turvallisesti
luottaen siihen, että käyttöönottovaiheessa liiketoiminnalle ei tuoteta
harmia. Järjestelmäarkkitehtuuri ja
tarvittava kapasiteetti pystytään
optimoimaan - ei siis hankita eikä
makseta kapasiteetista, jota todellisuudessa ei tarvita eikä käytetä.
Tietojärjestelmän skaalautuvuuteen
saadaan näkyvyys, jolloin tiede tään jo etukäteen kuinka paljon
järjestelmän käyttöaste ja yrityksen
liiketoiminta voivat kasvaa ilman
lisäinvestointeja ja muutostarpeita.
Järjestelmän stabiilius saadaan
varmistettua, jolloin liiketoiminnan
vaatimukset liittyen järjestelmän
saatavuuteen ( availability ) voidaan
saavuttaa. Suorituskyvyn ylläpitäminen vaatii toistuvaa testausta
järjestelmämuutoksien yhteydessä;
päivittäistä monitorointia, analysointia ja raportointia. ”Hyvän
suorituskyvyn saavuttaminen on
PDM/PLM-järjestelmille erittäin kriittistä globaalissa liiketoimintaympä r i s t ö s s ä ” s u m m a a IM Fe llo ws
Oy:n toimitusjohtaja Ismo Unkuri.
Valokynä 1/2015
Valokyna_1_2015.indd 9
9
21.3.2015 9:40:32
Suorituskykytestauksen päävaiheet.
Syy ja sen seuraus…
Järjestelmän suorituskyvyn analysointi on erittäin tärkeää ajatellen
suorituskyvyn turvaamista myös
tulevaisuudessa. Järjestelmän
suorituskyvyn ylläpitämiseen sekä
stabiiliuden varmistamiseen on
käytetty paljon aikaa ja resursseja
käyttöönottovaiheessa. Tämän
suuren ja intensiivisen työmäärän
jälkeen yleensä huokaistaan helpotuksesta, kun järjestelmä on saatu
tuotantokäyttöön. Tämän johdosta saattaa suorituskyvyn jatkuva
seuraaminen jäädä pienemmälle
huomiolle ja pahimmassa tapauksessa suorituskyky alkaa rapautua hitaasti. Tyypillisesti kukaan
ei edes muista millä vasteajalla
ja kuinka järjestelmä suoriutui
tehtävistään heti käyttöönoton
jälkeen. Lisäksi vuosien mittaan
järjestelmään tehtyjen muutosten lista voi olla niin pitkä, että
niistä on mahdoton löytää syyja seuraussuhteita järjestelmän
suorituskyvyn heikkenemiselle.
IM Fellows yrityksenä:
•
•
•
•
10
Valokyna_1_2015.indd 10
Järjestelmäriippumaton toimija
40+ vuoden kokemus ICT
-kehityksestä ja -teknologioista
PLM/PDM-järjestelmien kehitys- ja käyttöönottopalvelut
Tietojärjestelmien suorituskyvyn varmentaminen ja järjestelmäarkkitehtuuripalvelut
Järjestelmän suorituskyvyn analysointi ja monitorointi edellyttää vertailukohtia
valituista toiminnoista sekä eri resurssien käytöstä (prosessoriteho, muistinkäyttö, levyliikenne jne.).
Valokynä 1/2015
21.3.2015 9:40:34
Ihminen yksi muuttujista
Myös ihmiset järjestelmän ympärillä
voivat vaihtua, jolloin kokemusperäinen (eli niin sanottu hiljainen tieto)
järjestelmän alkuperäisestä suorituskyvystä hämärtyy. Tämän vuoksi on
erittäin tärkeää luoda tietojärjestelmälle jo ennen käyttöönottoa kattava
suorituskyvyn monitorointisuunnitelma tavoitetasoineen, johon kerätään
suorituskykymittaukset pääasiallisista (ja eniten käytetyistä) toiminnoista.
Lisäksi tarvitaan myös tietoa kuinka
järjestelmän eri systeemikomponentit
(web-, sovellus- ja tietokantapalvelin)
suoriutuvat päivittäisestä kuormasta.
On hyvä tiedostaa, että koskaan
ei ole liian myöhäistä aloittaa järjestelmän suorituskyvyn analysointia ja monitorointia. Tärkeintä on
sen aloittaminen ja ensimmäisen
vertailukelpoisen vertailukohdan
luominen. Vertailukohta sisältää vasteaika trendit valituista järjestelmän
toiminnoista sekä trendit järjestelmän eri komponenttien resurssien
(prosessoriteho, muistinkäyttö, le-
Valokyna_1_2015.indd 11
vyliikenne jne.) käytöstä tyypillisenä
työpäivänä, jolloin järjestelmässä
esiintyy myös huippukuorma. Sovittu baseline mahdollistaa järjestelmän suorituskyvyn vertaamisen
ja analysoinnin järjestelmämuutoksien jälkeen, joilla epäillään olevan
vaikutusta järjestelmän suorituskykyyn. Tällaisia muutoksia voivat olla:
• Käyttöjärjestelmän tietoturvapäivitykset
• Käyttöjärjestelmän konfiguraatiomuutokset
• Yksittäisen järjestelmäkomponentin (Java virtuaalikoneen,
tietokannan) päivitys
• Järjestelmän käyttämän verkkotai laitearkkitehtuurin muutokset
• Suuret massatietojen siirrot harmonisointien yhteydessä
• Uusien sovelluskomponenttien
käyttöönotto
”Luotettava ja vertailukelpoinen
baseline varsinaisesta tuotantoympäristöstä on ensiarvoisen tärkeää kun
järjestelmälle suunnitellaan suorituskykytestausta” kertoo IM Fellows Oy:n
johtava konsultti Marko Väätänen.
Monitorointi on sijoitus
Jatkuvalla järjestelmän monitoroinnilla ja suorituskyvyssä tapahtuvien poikkeamien analysoinnilla
pystytään näkemään ovatko ne
todella poikkeamia, vai onko järjestelmässä tapahtunut jokin pysyvä
suorituskykyä heikentävä muutos.
Vastaavasti aivan samalla tavalla
jatkuvan monitoroinnin avulla voidaan varmistaa, että esimerkiksi
suorituskykytestauksen avulla löydetyt järjestelmän suorituskykyä
parantavat toimenpiteet toimivat
myös tuotantoympäristössä. Jatk u v a m o n i t o ro i n t i t u o t t a a m y ö s
tietoa kuinka järjestelmä kuormittaa järjestelmän eri osa-alueita.
”Tämä on todellakin rahan arvoista
tietoa, kun suunnitellaan vaikkapa
tuotantojärjestelmän siirtoa uuteen
palvelinkeskukseen tai siirtymistä
kolmannen osapuolen pilvipalveluihin” toteaa Väätänen lopuksi.
Artikkeli jatkuu Valokynässä 2/2015. „
21.3.2015 9:40:34
Timo Suominen / Up The Sleeves
Copyright © KONE Corporation
Suorituskykyvaatimukset
järjestelmäarkkitehtuurin
suunnittelussa
Uuden järjestelmän arkkitehtuurin suunnittelu tulee perustua olemassa olevan
järjestelmän kapasiteettitietojen käyttöön. Ensimmäinen tärkeä suunnittelun
lähtökohta on tieto loppukäyttäjien määrästä. Kuinka paljon käyttäjiä vierailee järjestelmässä kuukausittain, viikoittain ja päivittäin? Nämä ovat yksinkertaisia perustietoja, mutta paljon muutakin tulee ottaa huomioon ja kartoittaa.
8
Valokynä 2/2015
M
ikä on maksimaalinen yhtäaikainen käyttäjäistuntojen määrä
päivässä? Minkä tyyppisiä (tietoa
hakevia vai sitä muokkaavia sekä
lisääviä) käyttäjiä järjestelmässä
vierailee ja mikä heidän jakaumansa on? Minkä tyyppisiä asiakassovelluksia (client application)
käyttäjät käyttävät järjestelmän
kanssa ja mikä on näiden sovellusten jakauma? Loppukäyttäjien
l i s ä k s i P L M - j ä r j e s t e l m ä l l e k u o rmaa aiheuttavat tyypillisesti myös
erilaiset integraatiot tai muut
t a u s t a - a j o p ro s e s s i t ( e s i m e r k i k s i
raportointi). Näiden osalta olisi
hyvä tietää myös transaktioiden
määrä tunnissa tai päivässä.
Kun meillä on tieto järjestelmän
ulkopuolelta tulevasta kuormasta, voidaan tarkastella kuorman
jakautuminen tietojärjestelmän
palvelimien kesken. Olemassa
olevasta järjestelmästä käydään
läpi kukin sovelluskerros (www-,
sovellus- ja tietokantapalvelimet)
ja tarkastellaan kuinka monta
palvelinta kullakin kerroksella on
tarvittu nykyisen kuorman hoitamiseen. Kunkin palvelimen osalta
tarkastellaan järjestelmäresurssien
(prosessoriteho, muistinkäyttö, levy-IO:n määrä ja levyalueiden koot)
käyttöastetta. Samoin tietokanta- ja tiedostopalvelimien osalta
tarkastetaan fyysinen datan määrä.
Sisään tulevan verkkoliikenteen
määrä sekä verkkoliikenteen määrä
palvelinten välillä on myös tärkeä
t i e t o , j o s j ä r j e s t e l m ä s i i r re t ä ä n
kokonaan uuteen ympäristöön.
Varautuminen tulevaisuuteen
Nykyisen kapasiteetin lisäksi
tulee ottaa huomioon myös tulevaisuuden näkymät. Nykyisellään
fyysisten serverien odotettavissa
olevaksi eliniäksi lasketaan noin
4 vuotta, minkä ajan järjestelmän
tulisi kyetä tarjoamaan yrityksen
tarvitsema kapasiteetti ilman isoja
muutoksia arkkitehtuurissa ja suurta laitteistoinvestointia. Suunnittelun pohjaksi on hyvä selvittää myös
ulkoiset vaatimukset PLM-järjestelmälle ainakin 2-3 vuoden ajalle.
Näitä vaatimuksia voivat asettaa
mm. yrityksen laajentumisstrategia, uudet käyttäjäryhmät (mukaan
lukien alihankkijat) ja mahdolliset
uudet toiminnallisuudet sekä uudet
integraatiot muihin järjestelmiin.
Usein uudet käyttäjäryhmät tuovat mukanaan myös suuren määrän
dataa järjestelmään esimerkiksi
yritysostojen tapauksessa. ”Luonnollisesti kaikkea ei kuitenkaan
pystytä arvioimaan ennalta vaikka pääsisimmekin kurkistamaan
yrityksen johdon strategioita,
vaan sovellusarkkitehtuurin on
oltava myös helposti skaalautuva
järjestelmäarkkitehtuurin asetta -
kuormaa aiheuttavia käyttäjiä, mikä
PLM-järjestelmissä on usein suurimpien R&D-yksiköiden läheisyydessä. Järjestelmän siirtoprojekteissa kannattaa tavoitteeksi ottaa
vasteaikojen parantaminen suurimmalle osaa käyttäjistä, varautuen siihen, että osalle käyttäjistä
vaikutus voi olla lähtökohtaisesti
myös negatiivinen. Huonompien
verkkoyhteyksien päässä olevien
käyttäjien vasteaikoja voidaan
optimoida erilaisten verkkolaitteiden, tai tarvittaessa myös paikallisten replica-serverien avulla.
Suorituskyvyn määritelmän
taustoitusta
T ietojärjestelmän suorituskyvyn
testaus alkaa aina suorituskyvyn
määrittelystä testauksen kohteena olevalle järjestelmälle oli
sitten kyseessä PLM-järjestelmä
tai tuotannonohjausjärjestelmä
tai mikä tahansa muu järjestelmä.
”Sovellusarkkitehtuurin oltava helposti skaalautuva”
mien rajojen puitteissa” toteaa
Teemu Snickeri, PDM Platform
Owner. Skaalautuvuutta voidaan
hakea suunnitteluvaiheessa joko
horisontaalisti tai vertikaalisti.
Haasteet hajautetussa liiketoimintaympäristössä
Useimmilla yrityksillä on nykyisin
toimintaa monilla eri paikkakunnalla, kokonaan eri maissa tai
jopa maanosissa. Tämä asettaa
suuria vaatimuksia ennen kaikkea
verkkoyhteyksille, joten heti alkuun
onkin tarpeen tehdä järjestelmän
käyttäjien kartoitus verkkoyhteyksien suhteen. Järjestelmän tulisi
sijaita verkkoyhteyksien kannalta
mahdollisimman lähellä suurinta
Huomionarvoista on myös, että organisaatiot ovat järjestelmien ympärillä erilaiset. Esimerkiksi samaa
PLM-järjestelmää voidaan käyttää
täysin eri tavalla riippuen yhtiöstä
ja heidän liiketoiminta-alueestaan.
PLM-järjestelmä on hyvä esimerkki
siitä, että saman järjestelmän
sisälläkin voi olla hyvin erilaisia vaatimuksia eri toimintojen
suorituskyvylle. Yksinkertaisten
t u o t e t i e t o n ä y t t ö j e n a v a u t u m ise n
voidaan olettaa tapahtuvan vähintään 3 sekunnissa, mutta kovin
re a l i s t i s e l t a e i v a i k u t a v a a t i m u s
siitä, että yli 10 000 riviä sisältävä
ja vähintään 5 eri tasolle avautuva
tuoterakenne avautuu loppukäyttäjän ruudulle samassa ajassa.
Käyttäjämäärät
Max. /pv /vko /kk
Sovelluspalvelimet
Aktiivi-passiivi kohdennetut
komponentit = 2 x kapasiteetti
Load Balancer cluster =
helposti skaalattavissa
Nykyinen
kapasiteetti
SLA varmistuksen
vaatimukset
suorituskyvyn kannalta
Palvelinten kuorma
Tietokantapalvelin
Datamäärät
Verkkoliikenne
Palvelimien määrä
Web-palvelimet
Uuden järjestelmän
arkkitehtuurisuunnittelu
Sijainnin vaikutus vasteaikoihin
eri saiteilla
Palvelimien määrä/
web-palveluprosessien määrä
Datacenterin
sijainti
Palvelinten kuorma
Yrityksen laajentumisstrategiat
Arvio tulevasta
kapasiteetin
tarpeesta
Business tarpeet
Uudet käyttäjäryhmät
Uudet toiminnallisuudet
Lisääntynyt data
Sovellusarkkitehtuuri
Skaalautuvuus
Mitä tulee ottaa huomioon uuden järjestelmän arkkitehtuurisuunnittelussa.
Valokynä 2/2015
9
Useimmilla yrityksillä on nykyisin toimintaa monilla eri paikkakunnalla, kokonaan
eri maissa tai jopa maanosissa. Tämä asettaa suuria vaatimuksia ennen kaikkea
verkkoyhteyksille.
Tä m ä n j ä l k e e n v a l i t a a n s o p i va kuormitustestaustyökalu sekä
testattavan järjestelmän testin aikaiseen monitorointiin käytettävät
apuohjelmat, jotka yleensä ovat
käyttöjärjestelmästä riippuvaisia.
Suunnitteluvaiheen lopuksi luodaan
yksityiskohtainen aikataulu suunniteltujen testien suorittamiseksi.
Tämän jälkeen seuraa suorituskykytestien automatisointivaihe, mikä
on yleensä kaikkein työläin vaihe jos
suorituskykytestausta ollaan tekemässä ensimmäistä kertaa. Tässä
vaiheessa luodaan testiscriptit
valituille käyttötapauksille ja ne parametrisoidaan. Parametrisointi tarkoittaa sitä, että käyttötapauksille
luodaan tarvittavat syötearvot, joita
vaihdellaan valitun logiikan mukaisesti tai satunnaisesti. Parametrisoinnin lisäksi suorituskykyscripteille täytyy määritellä käyttötapausten
eri vaiheiden väliin viiveitä, jotka
mallintavat todellisen loppukäyttäjän toimintaa järjestelmän kanssa.
Interaktiivisuus vs. integraatio
Eri testityypit
Edellä kuvatun kaltaiset vasteaikavaatimukset ovat hyvin tyypillisiä
interaktiivisille tietojärjestelmille,
jotka ovat suorassa vuorovaikutuksessa loppukäyttäjän kanssa.
Yleensä vasteaika vaatimukseen lisätään myös vaatimus järjestelmän
skaalautuvuudesta eli tavoitteena
oleva vasteaika pitää pystyä tarjoamaan myös kun järjestelmässä
on 200 tai 400 yhtaikaista käyttäjää. Interaktiivisen järjestelmän
tapauksessa on tärkeää, että
yhtäaikaiset loppukäyttäjät saavat
tehtyä tehtävänsä järjestelmässä
ilman turhaa odottelua. Mutta on
olemassa myös kokonaisia järjestelmiä tai niiden osia joille vasteajan
sijaan on tärkeämpää kuinka monta
tapahtumaa tai pyyntöä ne pystyvät käsittelemään tietyssä ajassa.
Klassinen esimerkki tällaisesta on
kahden eri järjestelmän välinen
integraatioalusta. Sen osalta on
paljon tärkeämpää se kuinka monta integraatiopyyntöä se pystyy
käsittelemään yhtaikaa kuin se,
että mikä on yksittäisen pyynnön
käsittelyaika. PLM-järjestelmän
tapauksessa esimerkkinä voitaisiin
käyttää vaikka tuotekonfiguraattorille asetettavaa vaatimusta:
kuinka monta tuotekonfiguraatiota
PLM-järjestelmä pystyy generoimaan tietyssä ajassa. Suorituskykyvaatimusten määrittelyssä voi-
10
Valokynä 2/2015
daan hyödyntää olemassa olevaa
tuotannon jatkuvaa monitorointia.
Sieltä saadaan realistista tietoa
v a s t e a j o i s t a , j o i t a v o i d a a n s u oraan hyödyntää kun määritellään
tavoitteita suorituskykytesteihin.
Asiakkaan kanssa liikkeelle
käyttötapauksista
Suorituskykytestausprosessi aloitetaan aina järjestelmän yleisempien käyttötapausten valinnasta
yhteistyössä asiakkaan kanssa.
Tämän jälkeen valituille käyttötapauksille määritetään suorituskykyvaatimus riippuen siitä, onko
kyseessä interaktiivinen toiminnallisuus vai tausta-ajona suori tettava toiminto. Suorituskykytestaukseen valitut käyttötapaukset
myös kuvataan yksityiskohtaisesti,
j o tta t i e d e t ä ä n m i t ä e r i v a i h e i t a
kukin käyttötapaus pitää sisällään.
Suorituskykytestauksen suunnitteluvaiheessa määritellään myös
käytettävä testiympäristö ja testiskenaario, jossa huomioidaan
muun muassa seuraavia asioita:
• Testikäyttäjien jakauma maantieteellisesti eri lokaatioihin
(jos kyseessä on globaali järjestelmä)
• Tarvittavan testidatan ja testikäyttäjien luonti testiympäristöön
• Te s t i k ä y t t ä j i e n j a k a u m a e r i
käyttäjärooleihin
Viimeinen vaihe suorituskykytestauksessa on tietenkin suorituskykytestien suorittaminen, testitulosten analysointi ja raportointi. Tämä
vaihe on yleensä erittäin suoraviivainen, koska suoritettavat testiajot
ovat aika pitkälle määritelty suunnitteluvaiheessa. Testauksen alkuvaiheessa luodaan vertailukohta (baseline), jolla tarkoitetaan testituloksia
mitkä pystytään 100 % varmuudella
t o i s t a m a a n . Tä t ä v e r t a i l u k o h t a a
pidetään erityisenä kiintopisteenä,
johon verrataan testituloksia meneillään olevan suorituskykytestauksen
aikana ja tulevaisuudessa tapahtuvien testien osalta. Suorituskykytestit voidaan ryhmitellä niiden
luonteen mukaisesti seuraavasti:
Testauksella saavutettavat hyödyt
Lopputuloksena on siis suorituskykytestauksen läpäissyt järjes telmä ja testiraportti, jossa kerrotaan kuinka järjestelmä käyttäytyy
erilaisissa kuormitustilanteissa.
Lisäksi testien tuloksia voidaan
suoraan käyttää optimaalisen lopullisen tuotantoympäristön suunnitteluun ja valintaan. ”Testiraportin avulla pystytään säästämään
rahaa ja myös välttämään järjestelmäkapasiteetin ylimitoitus.”
kertoo IM Fellows Oy:n johtava
konsultti Marko Väätänen.
„
Testityyppi
Sisältö, tavoitteet
Optimointitesti
Testissä vaihdellaan järjestelmän suorituskykyyn vaikuttavia parametreja ja haetaan
järjestelmälle tai järjestelmän yhdelle komponentille (esimerkiksi sovelluspalvelin)
parasta mahdollista suorituskykyä.
Skaalautuvuustesti
Testin tarkoituksena on löytää maksimaalinen kuorma minkä järjestelmä pystyy
hoitamaan hyväksyttävällä vasteajalla (interaktiiviset järjestelmät) tai transaktioiden
määrällä (tausta-ajo, raportointi- tai integraatiotyyppiset järjestelmät).
Kestotesti
Testissä käytetään noin 10-30 % pienempää kuormaa kuin mikä on nykyinen tai
arvioitu huippukuorma tuotannossa. Testin tarkoituksena on selvittää, että pysyykö
järjestelmän suorituskyky vakiona.
Arkkitehtuuriset testit
Testeissä on tarkoitus löytää paras arkkitehturaalinen konfiguraatio järjestelmälle.
Tyypillisimmät suorituskykytestityypit.
KONE:lta artikkelin kirjoittamiseen osallistui Senior Business Analyst, PDM Platform Owner (Global Development) Teemu Snickeri.
KONE Oyj kuuluu alansa johtaviin yrityksiin ja tarjoaa asiakkailleen edistyksellisiä hissejä, liukuportaita ja automaattiovia sekä
monipuolisia ratkaisuja niiden huoltoon ja modernisointiin. Eri asiakasryhmien tarpeiden ymmärtäminen on ohjannut yhtiön
toimintaa jo sadan vuoden ajan.
KONEen tavoitteena on tarjota paras käyttäjäkokemus kehittämällä ja toimittamalla ratkaisuja, jotka mahdollistavat ihmisten
liikkumisen rakennuksissa sujuvasti, turvallisesti, mukavasti ja viivytyksettä yhä enemmän kaupungistuvassa ympäristössä.
Vuonna 2014 KONEen liikevaihto oli 7,3 miljardia euroa ja henkilöstömäärä vuoden lopussa yli 47 000. Yhtiön B-sarjan osake
noteerataan NASDAQ OMX Helsinki Oy:ssä.
IM Fellows yrityksenä:
Järjestelmäriippumaton toimija
40+ vuoden kokemus ICT kehityksestä ja teknologioista
PLM/PDM järjestelmien kehitys- ja käyttöönottopalvelut
Tietojärjestelmien suorituskyvyn varmentaminen ja järjestelmäarkkitehtuuripalvelut
Kirjoitus on jatkoa 1/2015 julkaistulle
artikkelille ’Globaali liiketoiminta vaatii
suorituskykyiset tietojärjestelmät’.