Miten kriittisen tärkeistä ohjelmistoista tehdään vahvoja?

Terveydenhuolto, energia, maatalous: siinä muutama esimerkki toimialoista, joille cinialaiset rakentavat ohjelmistoratkaisuja. Hankkeet auttavat pyörittämään yhteiskunnan rattaita, ja osaan niistä kohdistuu erittäin korkeita saatavuus- ja turvallisuusvaatimuksia. Mitä erityistä kriittisten järjestelmien ohjelmistokehityksessä pitää ottaa huomioon?

Senior Program Manager Raine Ronni ja Chief Software Engineer Antti Koskimäki tekevät töitä hätäkeskustietojärjestelmä ERICAn parissa. Laajuudessaan ja vaativuudessaan ERICA on Suomen oloissa poikkeuksellinen ohjelmisto ja palvelu, mutta sen kehittämisen periaatteet istuvat muihinkin kriittisiin järjestelmiin.

Erittäin korkeat saatavuusvaatimukset voivat tehdä huoltoikkunoista hyvin kapeita, tai sitten huoltoikkunoita ei yksinkertaisesti ole. Vakaus, kestävyys ja turvallisuus on rakennettava osaksi ohjelmistoratkaisua alusta asti. Muun muassa nämä vaativat huomiota:

• Teknologiavalinnat ja ohjelmistokehityksen käytännöt
• DevOps ja testaaminen
• Yllättäviin ongelmatilanteisiin varautuminen

“Ohjelmistokehitys on ihmislähtöistä”, Koskimäki muistuttaa. “Asenne on kaikkein tärkein asia: sen ymmärtäminen, että teemme tiettyjen laatuvaatimusten mukaista järjestelmää. Sen alla sitten hyödynnämme oppikirjoista opittuja prosesseja.”

Teknologiat eivät saa pienistä hätkähtää

Jokaisen järjestelmän rakentaminen lähtee liikkeelle kokonaisuuden hahmottamisella ja käyttäjien näkökulman ymmärtämisellä. Miten sen jälkeen edetään, jos kyseessä on korkeiden turvallisuusvaatimusten ohjelmistoratkaisu?

“Kyllähän se lähtee teknologiavalinnoista. Niitä arvioidaan huolellisesti ja etsitään juuri kyseiseen ongelmaan sopivimmat vaihtoehdot. Taistelunkestävyys on se olennainen juttu: kriittisten järjestelmien kohdalla emme välttämättä surffaa aivan aallonharjalla uusien teknologioiden suhteen vaan haluamme seurata ensin, että ne varmasti toimivat. Olemme jatkuvasti hereillä ja arvioimme haavoittuvuuksia komponenteissa ja kirjastoissa”, Ronni kertoo.

Ohjelmistokehityksen laatua varmistetaan alusta asti esimerkiksi: 

• ketterän kehityksen menetelmillä
• huolellisella koodikatselmoinnilla
• monivaiheisella, jatkuvalla testaamisella
• sekä kattavilla lokituskäytännöillä.

“Kriittisen järjestelmän tietoturva syntyy ennen kaikkea varautumisesta. Jokaisen toteutuksen tekovaiheessa on mietittävä läpi mahdolliset virhetilanteet, mutta myös keinot niistä toipumiseen”, Ronni sanoo.

“Ohjelmistokehityksen prosesseissa ei sinänsä ole mitään yksittäistä tekijää, jonka nostaisin jalustalle. Tärkeintä on yhteinen tahtotila siihen, että sovittuja prosesseja noudatetaan huolellisesti”, Koskimäki täydentää.

“Automaatiota tarvitaan, kun paukutamme ympäristöä moninkertaisilla avainluvuilla”

ERICA-järjestelmässä jokainen, pienikin muutos koetellaan moneen kertaan: 

“Käytössä on paljon eri ympäristöjä tuotantoon, koulutukseen, testaamiseen ja raportointiin”, Ronni luettelee. “Olemme panostaneet todella paljon DevOps-puoleen: asennusautomaatioon sekä toistettavuuteen. Virtuaalikoneita ei tarvitse pystytellä käsin, vaan kone tekee saman minuuteissa tai tunneissa. Toistettavuus tuo laatua.”

Automaatioon on satsattu myös testauspuolella. Kriittisten järjestelmien ohjelmistokehityksessä onkin tyypillistä, että pelkästään testausympäristöjä on käytössä useita: sekä toiminnalliseen että “rikkovaan” suorituskykytestaukseen.

“Automaatiota tarvitaan, kun paukutamme ympäristöä moninkertaisilla avainluvuilla vaatimustasoon nähden. Eihän sitä käsin yksinkertaisesti pystyisi tekemään. Esimerkiksi vuositasolla hätäkeskuksiin tulee lähes kolme miljoonaa hätäilmoitusta, joiden käsittelyä me testauksessa simuloimme. Kuormitustestausta teemme paljon myös kompressoimalla, eli ikääntymistestausta puristetaan tiukkaan aikaan: ajamme järjestelmään viikon verran vuoden edestä testikuormaa. Näin pystymme huomaamaan muistivuotojen tyyppiset ongelmat ajoissa”, Ronni havainnollistaa.

“Testaamallahan ei laatua tehdä, vaan laatu tehdään toteutusvaiheessa: teknologiavalinnoilla, osaamisella ja sparraamisella, katselmoinneilla ja hyvällä yhteisellä suunnittelulla. Mutta testaaminen on silti kokonaisuuden kannalta todella tärkeää ja antaa olennaista tietoa, jotta potkuria ei tarvitse kolauttaa samaan kiveen montaa kertaa.”

Täysin virheetöntä järjestelmää ei ole

Koskimäki muistelee asiakaspalaveria, jossa häneltä kysyttiin, miten virheilmoitukset voisi välttää kokonaan. Hänellä oli sekä huonoja että hyviä uutisia:“Täysin bugittoman softan toimittaminen on käytännössä mahdotonta. Sen sijaan voin luvata asiakkaalle, että kriittiset polut on varmistettu niin ettei järjestelmä hetkahda, vaikka eteen tulisikin jokin odottamaton ongelma. Olemme onnistuneet, kun järjestelmä täyttää tärkeimmät tehtävänsä katkeamattomasti. Se edellyttää pitkälle vietyjä suunnitelmia häiriötilanteiden varalle.”

Korkea saatavuus varmistetaan monentamisen ja verkottamisen menetelmillä.

“Mitä tapahtuu, jos tietoliikenneyhteys katkeaa? Entä jos jokin palvelimista kaatuu? Vikatilanteiden ennakointi on rakennettava sisään korkean saatavuuden kriittisen järjestelmän arkkitehtuuriin. On henkseleitä, on vyötä, jotteivät housut putoa ihan helpolla”, Ronni kertoo. 

Arkkitehtuurin ja testaamisen lisäksi on kyse valvonnan kehittämisestä: “Pyrimme lisäämään järjestelmään koko ajan automaattisia silmiä ja korvia. Näin huomaamme ajoissa huolestuttavat trendit, kuten levynkulutuksen kasvun.”

Ihmiset tekevät kriittisestä järjestelmästä turvallisen

Tietoturva riippuu sekä teknologiasta että inhimillisistä muuttujista. Kriittisissä, korkeiden turvallisuusvaatimusten hankkeissa: 

• työntekijöiden on käytävä läpi turvaselvitys, 
• työasemat ovat omia suojattuja ympäristöjään ja 
• työyhdistelmät rakennetaan niin, ettei yksittäisen ihmisen tekemä virhe aiheuta vakavia riskejä.

Palataan vielä siihen asenteeseen – tekijään, jonka Antti Koskimäki mainitsi kaikista tärkeimmäksi. Mistä syntyy yhteinen halu tuottaa korkea laatua?

“Meillä on monta osaajaa, jotka ovat viihtyneet samassa porukassa jo pitkään”, hän kertoo. “Keskusteluissa on tullut esiin, että tärkein syy sitoutumiseen on mielekkyys – teet työtä, jolla on konkreettinen tarkoitus. Sillä on väliä, että järjestelmä oikeasti toimii. Hyvin tehdystä työstä voi silloin olla ylpeä”.

Toisin sanottuna: “Kun kuulen sireenin äänen tai näen siniset valot taustapeilissä, siihen suhtautuu eri tavalla kuin ennen.”

Raine Ronni on samoilla linjoilla: “Kokonaisuus syntyy monien eri roolien ihmisistä – tuoteomistajat, palvelumuotoilu, arkkitehdit, kehittäjät, testaajat ja palvelutuotanto – jotka pelaavat samassa joukkueessa. Itsellänikin on takana pitkä työura ennen hätäkeskustietojärjestelmää ja Ciniaa, mutta kyllä tämän porukan osaaminen kestää komeasti vertailun mihin tahansa.”