IT-infra voi toimia tänään täysin normaalisti ja sisältää silti riskejä, jotka näkyvät vasta häiriötilanteessa. Toimintavarmuus ei tarkoita sitä, ettei häiriöitä koskaan syntyisi. Se tarkoittaa, että liiketoimintakriittiset palvelut tunnetaan, ympäristön tilaa seurataan, vastuut ovat selkeät ja toiminta pystytään palauttamaan hallitusti myös silloin, kun jotain oikeasti tapahtuu.
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.
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.
Mitä tarkistaa
- Mitä tapahtuisi, jos järjestelmä olisi pois käytöstä kaksi tuntia. Entä kokonaisen työpäivän.
- Mihin liiketoiminnan prosessiin kukin järjestelmä vaikuttaa.
- Onko kriittisyys kirjattu johonkin vai perustuuko se hiljaiseen tietoon.
- Vastaako nykyinen palvelutaso järjestelmän kriittisyyttä.
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.
Mitä tarkistaa
- Onko RTO määritelty kriittisimmille järjestelmille.
- Onko RPO määritelty samoille järjestelmille.
- Tunteeko liiketoiminta nämä tavoitteet vai tietääkö ne vain IT.
- Pystyykö nykyinen ympäristö saavuttamaan ne.
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.
Mitä tarkistaa
- Ovatko tarvittavat tiedot palautettavissa.
- Kuinka kauan palautuminen kestää.
- Tunnetaanko järjestelmien riippuvuudet.
- Tiedetäänkö, missä järjestyksessä palveluita palautetaan.
- Ovatko ihmiset ja kumppanit selvillä omista vastuistaan.
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.
Mitä tarkistaa
- Kuka huomaa häiriön ensimmäisenä.
- Kuka reagoi ja kuka selvittää juurisyytä.
- Kuka vastaa palautuksesta.
- Milloin asia eskaloidaan seuraavalle toimijalle.
- Kuka lopulta vastaa siitä, että liiketoiminta pystyy jatkumaan.
Hyvässä IT-infrapalvelussa sovitaan teknisten ratkaisujen rinnalla myös palvelun rajat, vastuut, toimintamallit ja eskalaatiot. Tästä on konkreettinen esimerkki.
”Soforin kanssa yhteistyössä tehty palvelumalli on räätälöity nyt yksinomaan SSAB:n käyttöön, mikä mahdollistaa joustavan ja ketterän palveluhallinnan. Emme ole enää juurikaan sidoksissa muiden ympäristöjen ja isojen toimijoiden huoltokatkoihin.”
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ö.
Mitä tarkistaa
- Mitä ympäristöstä valvotaan ja mitä ei.
- Kuka vastaanottaa hälytykset ja mihin aikaan vuorokaudesta.
- Mitä hälytyksen jälkeen tapahtuu ja kuinka nopeasti.
- Seurataanko kapasiteetin ja suorituskyvyn kehitystä ennakoivasti.
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.
Mitä tarkistaa
- Mitkä komponentit voivat aiheuttaa laajemman käyttökatkon.
- Onko kriittisissä palveluissa riittävästi redundanssia.
- Onko varayhteyksien toimivuus testattu.
- Riittääkö kapasiteetti myös poikkeustilanteessa.
- Onko ympäristössä vanhentuvia ratkaisuja, joiden ylläpidettävyys muodostaa riskin.
- Tunnetaanko tärkeimpien toimittajien ja palveluiden väliset riippuvuudet.
Kaikkea ei kuitenkaan tarvitse kahdentaa eikä jokaiseen ympäristöön tarvita korkeinta mahdollista palvelutasoa. Oleellista on, että ratkaisut vastaavat liiketoiminnan todellista riskitasoa.
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.
Mitä tarkistaa
- Milloin ympäristön tilaa on viimeksi tarkasteltu liiketoiminnan tarpeita vasten.
- Onko ympäristölle olemassa kehityssuunnitelma.
- Kuka vastaa siitä, että suunnitelma pysyy ajan tasalla.
- Lähestyvätkö jotkin ratkaisut elinkaarensa loppua.
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.
Yleinen harhaluulo
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.
Merkkejä keskustelun tarpeesta
- Oman IT-tiimin aika kuluu pääasiassa nykyisen ympäristön ylläpitämiseen.
- Ympäristön vastuut ovat hajautuneet usealle toimijalle.
- Palautumisen toimivuudesta ei ole varmuutta.
- Nykyinen infrastruktuuri alkaa lähestyä elinkaarensa loppua.
- Liiketoiminta tai kapasiteettitarpeet ovat muuttuneet.
- Organisaatio tarvitsee ympärivuorokautista valvontaa tai tukea.
- Nykyisestä ympäristöstä puuttuu selkeä kehityssuunnitelma.
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-infrapalveluita organisaatioille, 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ä.
[…] ne ylipäätään saadaan selville. RTO- ja RPO-tavoitteiden määrittelystä kerromme tarkemmin oppaassa IT-infran toimintavarmuudesta, ja palautusten toteutus on osa Soforin datan […]