Mistä tiedät, onko IT-infran toimintavarmuus riittävällä tasolla?

Vaikeampi kysymys on, kuinka moneen kohtaan listasta organisaatiossanne pystytään vastaamaan varmasti kyllä. Käy seuraavat seitsemän kysymystä läpi oman ympäristönne kanssa. Jokaisen kohdalla kerrotaan, miksi asialla on väliä ja mitä kannattaa tarkistaa.

1. Mitkä järjestelmät ovat oikeasti kriittisiä?

Kaikkien järjestelmien ei tarvitse toimia samalla palvelutasolla. Pitäisi kuitenkin tietää, mitkä järjestelmät, yhteydet ja palvelut ovat sellaisia, joiden häiriintyminen vaikuttaa suoraan tuotantoon, toimituksiin, asiakaspalveluun tai työntekijöiden kykyyn tehdä työnsä.

Teollisuusympäristössä muutaman tunnin käyttökatko voi tarkoittaa aivan eri asiaa kuin tavallisessa toimistoympäristössä. Siksi IT-infraratkaisuja ei pitäisi arvioida vain teknologian perusteella, vaan suhteessa siihen, kuinka kriittistä niiden tukema liiketoiminta on. Kun kriittiset järjestelmät on tunnistettu, niiden ympärille voidaan määritellä tarkoituksenmukainen käytettävyys, valvonta, varmistukset ja palautumisen tavoitetasot. Nämä muodostavat perustan Soforin IT-infrapalveluille.

2. Onko palautumiselle määritelty tavoite?

Monessa organisaatiossa varautumiseen on panostettu, mutta vähemmälle huomiolle jää kysymys siitä, kuinka nopeasti toiminnan pitäisi häiriön jälkeen jatkua. Tähän liittyy kaksi käsitettä. RTO eli Recovery Time Objective kertoo, kuinka pitkän käyttökatkon liiketoiminta voi hyväksyä. RPO eli Recovery Point Objective kertoo, kuinka paljon dataa voidaan enintään menettää.

Näitä ei tarvitse tarkastella vain teknisinä termeinä. Liiketoiminnan kannalta olennaista on, mitä käyttökatko tai datan menetys aiheuttaisi. Jos tähän ei ole yhteisesti sovittua vastausta, teknisen ympäristön on vaikea täyttää odotuksia, koska tavoitetta ei ole määritelty.

3. Milloin palautuminen on viimeksi testattu?

Varmuuskopiointi on tärkeä osa jatkuvuutta, mutta se ei yksin todista, että toiminta pystytään palauttamaan. Varmuuskopio suojaa tietoa. Palautuminen todentuu vasta testissä. Varmuuskopio voi olla olemassa ja silti palautuminen voi osoittautua hitaammaksi tai monimutkaisemmaksi kuin on oletettu.

Häiriötilanne ei ole paras hetki huomata, että palautumiseen liittyvä prosessi perustui oletuksiin. Voit tarkistaa oman vastuunjakonne kolmessa minuutissa maksuttomalla IT-vastuunjaon itsearviolla. Palautumisen toimintamallit ovat osa Soforin datan varmistuspalveluita.

4. Kuka tekee mitä häiriötilanteessa?

Moderni IT-ympäristö muodostuu harvoin yhden toimijan ratkaisuista. Mukana voi olla oma IT-tiimi, pilvipalveluita, verkkotoimittaja, sovellustoimittajia, infrakumppani ja muita teknologiakumppaneita. Normaalitilanteessa kokonaisuus voi toimia hyvin. Häiriötilanteessa ratkaisevaa on kuitenkin se, ovatko vastuut aidosti selkeitä.

Jos ensimmäinen tehtävä häiriötilanteessa on selvittää, kenelle ongelma kuuluu, kallista aikaa menetetään jo ennen varsinaisen ongelman ratkaisemista. Sama periaate koskee pilviympäristöjä, joissa ilman selkeää omistajuutta teknisesti toimivakin kokonaisuus voi muuttua vaikeasti hallittavaksi. Lue lisää Azure-pilvipalveluiden hallintamallista.

Hyvässä IT-infrapalvelussa sovitaan teknisten ratkaisujen rinnalla myös palvelun rajat, vastuut, toimintamallit ja eskalaatiot. Tästä on konkreettinen esimerkki.

5. Näettekö ongelmat ennen käyttäjiä?

Toimintavarmuutta ei pitäisi arvioida vain sen perusteella, kuinka nopeasti häiriöön reagoidaan. Kypsässä toimintamallissa ympäristön kapasiteettia, suorituskykyä ja poikkeamia seurataan jatkuvasti, jotta muutoksiin voidaan reagoida jo ennen kuin käyttäjä huomaa ongelmaa.

Pelkkä hälytys ei kuitenkaan vielä ratkaise mitään. Hälytyksen rinnalle tarvitaan sovittu toimintamalli siitä, kuka reagoi, kuinka nopeasti ja mitä sen jälkeen tapahtuu. Ennakoivasta valvonnasta ja sen merkityksestä olemme kirjoittaneet tarkemmin artikkelissa Hallintapalvelut eivät ole vakuutus vaan käytäntö.

6. Onko infrassa yksittäisiä vikapisteitä?

IT-infran toimintavarmuus muodostuu kokonaisuudesta. Palvelimet voivat olla vikasietoisia, mutta ongelma voi löytyä esimerkiksi verkkoyhteydestä, tallennuksesta, kapasiteetista, fyysisestä ympäristöstä tai kriittisestä ulkopuolisesta palvelusta. Siksi yksittäisten teknologioiden sijaan pitäisi arvioida niiden välisiä riippuvuuksia.

Myös infrastruktuurin ulkopuoliset riippuvuudet kannattaa tunnistaa. Esimerkiksi datan sijainti, palveluntarjoajat ja kansainväliset riippuvuudet voivat olla osa organisaation jatkuvuusriskiä, kuten kirjoitimme artikkelissa Onko datasi turvassa suurvaltapolitiikan heilahteluilta.

Kaikkea ei kuitenkaan tarvitse kahdentaa eikä jokaiseen ympäristöön tarvita korkeinta mahdollista palvelutasoa. Oleellista on, että ratkaisut vastaavat liiketoiminnan todellista riskitasoa.

7. Kehittyykö infra liiketoiminnan mukana?

Toimintavarmuus ei ole projekti, joka valmistuu kerran. Organisaatio muuttuu, liiketoiminta kasvaa ja järjestelmiä tulee lisää. Pilven ja oman ympäristön suhde muuttuu, tietoturvavaatimukset kehittyvät, kapasiteettitarpeet kasvavat ja teknologia vanhenee. Tämän vuoksi tänään hyvin toimiva IT-infra ei automaattisesti ole oikea ratkaisu kolmen vuoden päästä.

Toimintavarman infrastruktuurin pitäisi sisältää myös ympäristön tilan, kapasiteetin ja kehitystarpeiden säännöllistä tarkastelua suhteessa liiketoiminnan muutoksiin. Soforin Define Build Maintain -mallissa ylläpidossa havaitut kehitystarpeet viedään takaisin määrittelyyn, jotta ympäristö kehittyy liiketoiminnan mukana eikä vain yksittäisten projektien kautta.

IT-kumppanin tehtävä ei ole vain ylläpitää nykyistä. Hyvä kumppani auttaa tunnistamaan, milloin nykyiseen ympäristöön kannattaa tehdä muutos ennen kuin siitä muodostuu ongelma.

Toimintavarmuus ei tarkoita mahdollisimman raskasta IT-infraa

Yksi yleinen harhaluulo on, että korkea toimintavarmuus tarkoittaisi automaattisesti mahdollisimman kallista, monimutkaista ja kaikkialta kahdennettua infrastruktuuria. Näin ei tarvitse olla. Hyvä IT-infraratkaisu lähtee liiketoiminnan todellisesta tarpeesta. Yhdessä järjestelmässä muutaman tunnin käyttökatko voi olla hyväksyttävä, kun taas toisen on toimittava käytännössä ympäri vuorokauden.

Olennaisinta on tietää, missä korkea käytettävyys on liiketoiminnan kannalta välttämätöntä ja missä ei. Tämä vaikuttaa myös kustannuksiin. Kun palvelutasot, kapasiteetti, varmistukset ja vastuut suhteutetaan todellisiin tarpeisiin, IT-infrasta voidaan rakentaa samanaikaisesti sekä toimintavarma että tarkoituksenmukainen.

Milloin IT-infrakumppanin kanssa kannattaa keskustella?

Ulkoisen IT-kumppanin tarve ei yleensä ala siitä, että kaikki olisi jo rikki. Keskustelu on perusteltu esimerkiksi silloin, kun näistä useampi pitää paikkansa.

Tällaisessa tilanteessa ensimmäisen askeleen ei tarvitse olla suuri infraprojekti tai koko ympäristön ulkoistaminen. Usein hyödyllisempää on aloittaa nykytilasta ja selvittää, mikä ympäristössä toimii hyvin, missä ovat suurimmat riskit ja mikä olisi seuraava järkevä kehityskohde. Sofor tarjoaa IT-infrapalveluitaorganisaatioille, joiden ympäristöissä toimintavarmuus, selkeä vastuunjako ja jatkuva kehittäminen ovat liiketoiminnan kannalta olennaisia.

Usein kysytyt kysymykset IT-infran toimintavarmuudesta

Mitä IT-infrapalveluihin kuuluu?

IT-infrapalvelut voivat sisältää esimerkiksi palvelin- ja pilviympäristöjen operointia, valvontaa, kapasiteetin ja suorituskyvyn seurantaa, varmistuksia, palautumista, tietoliikennettä, tukea ja infrastruktuurin jatkuvaa kehittämistä. Palvelun sisältö kannattaa määritellä organisaation ympäristön ja liiketoimintavaatimusten perusteella.

Milloin IT-infran ylläpito kannattaa ulkoistaa?

Ulkoistaminen voi olla järkevää esimerkiksi silloin, kun oman IT-tiimin aika halutaan vapauttaa kehittämiseen, ympäristö vaatii osaamista tai valvontaa, jota ei ole järkevää rakentaa kokonaan sisäisesti, tai kun vastuita halutaan selkeyttää yhden kumppanin kanssa.

Mitä hyvältä IT-kumppanilta kannattaa vaatia?

Teknisen osaamisen lisäksi kannattaa arvioida kumppanin vastuunottoa, palvelutasojen selkeyttä, valvontaa, palautumisen toimintamalleja, kykyä kehittää ympäristöä sekä näyttöä vastaavista liiketoimintakriittisistä ympäristöistä.