Globaali liiketoiminta vaatii suorituskykyiset tietojärjestelmät

Transkriptio

1 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 PDM/PLM-käyttäjän verkosto kattaa koko toimitusketjun tuotekehityksestä aina myynnin ja tuotannon kautta kunnossapitoon sekä alihankintaverkostoon asti. 8 Valokynä 1/2015

2 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 tuotetiedonhallinnassa mittareina toimivat muun muassa tietyn hissin konfigurointiaika, ennalta määritellyn tuotteen tuoterakenteen 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. 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 tasolla. Koska maailmaakaan ei 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 Suunnittelematon käyttökatko aiheuttaa merkittävät kustannukset 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 tarvittavan informaation määrä kasvaa vuosittain. Lisäksi yhä enemmän yritykset myös markkinoivat ja myyvät tuotteitaan internetissä. Mitä on hyvä suorituskyky? Vaatimukset tietojärjestelmien 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 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 tiedetää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äristössä summaa IM Fellows Oy:n toimitusjohtaja Ismo Unkuri. Valokynä 1/2015 9

3 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ä: 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.). 10 Valokynä 1/2015

4 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ö, levyliikenne 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ä. Jatkuva monitorointi tuottaa myö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.

5 Timo Suominen / Up The Sleeves Suorituskykyvaatimukset järjestelmäarkkitehtuurin suunnittelussa Copyright KONE Corporation 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

6 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 lisäksi PLM-järjestelmälle kuormaa aiheuttavat tyypillisesti myös erilaiset integraatiot tai muut tausta-ajoprosessit (esimerkiksi 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ä tieto, jos järjestelmä siirretää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 asettamien 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 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 Tietojä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 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 tuotetietonäyttöjen avautumisen voidaan olettaa tapahtuvan vähintään 3 sekunnissa, mutta kovin realistiselta ei vaikuta vaatimus siitä, että yli 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 Palvelimien määrä/ web-palveluprosessien määrä Aktiivi-passiivi kohdennetut komponentit = 2 x kapasiteetti Load Balancer cluster = helposti skaalattavissa SLA varmistuksen vaatimukset suorituskyvyn kannalta Uuden järjestelmän arkkitehtuurisuunnittelu Nykyinen kapasiteetti Tietokantapalvelin Web-palvelimet Palvelinten kuorma Datamäärät Verkkoliikenne Palvelimien määrä Palvelinten kuorma Sijainnin vaikutus vasteaikoihin eri saiteilla Datacenterin sijainti Arvio tulevasta kapasiteetin tarpeesta Business tarpeet Yrityksen laajentumisstrategiat 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

7 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älkeen valitaan sopiva 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 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ä voidaan hyödyntää olemassa olevaa tuotannon jatkuvaa monitorointia. Sieltä saadaan realistista tietoa vasteajoista, joita voidaan suoraan 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 suoritettava toiminto. Suorituskykytestaukseen valitut käyttötapaukset myös kuvataan yksityiskohtaisesti, jotta tiedetään mitä eri vaiheita 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 Testikäyttäjien jakauma eri käyttäjärooleihin Eri testityypit 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 toistamaan. Tätä vertailukohtaa 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ärjestelmä 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. 10 Valokynä 2/2015

8 Testityyppi Optimointitesti Skaalautuvuustesti Kestotesti Arkkitehtuuriset testit Sisältö, tavoitteet Testissä vaihdellaan järjestelmän suorituskykyyn vaikuttavia parametreja ja haetaan järjestelmälle tai järjestelmän yhdelle komponentille (esimerkiksi sovelluspalvelin) parasta mahdollista suorituskykyä. 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). Testissä käytetään noin % pienempää kuormaa kuin mikä on nykyinen tai arvioitu huippukuorma tuotannossa. Testin tarkoituksena on selvittää, että pysyykö järjestelmän suorituskyky vakiona. 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 Yhtiön B-sarjan osake noteerataan NASDAQ OMX Helsinki Oy:ssä. IM Fellows yrityksenä: - Järjestelmäriippumaton toimija 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.