Etsitkö tietoa siitä, mitä termit RTO, RPO, BIA jne. tarkoittavat?
Käyn tässä artikkelissa läpi neljä (4) jatkuvuuden hallintaan liittyvää termiä selityksineen.
Käytän itse jatkuvuuden hallinnasta tulevaa metodiikkaa riskien hallinnan lisäksi myös IT-infran ja tukipalvelujen mitoitukseen.
Kun olet lukenut kirjoituksen, tiedät, mitä esimerkiksi RTO tai MTPD tarkoittaa.
Aloitetaan kuitenkin ihan lyhyellä johdannolla jatkuvuudenhallintaan. Mistä oikein on kyse?
Mihin jatkuvuudenhallintaa tarvitaan?
Lähes jokaisen organisaation ydinprosessit ovat nykyään riippuvaisia IT-järjestelmistä. Siksi jokainen johtaja joutuu miettimään, millaisia riskejä näihin IT-järjestelmiin kätkeytyy.
Jatkuvuuden hallinnassa on kyse siitä, että järjestelmien kyky kestää katkoja ja niihin liittyvät tukijärjestelyt pyritään mitoittamaan organisaation tarpeiden mukaiseksi.
Tähän liittyy mm. sen arvioiminen, millaisia katkoja organisaatio hyväksyy. Lisäksi voidaan arvioida, miten hyvin järjestelmät sietävät erilaisia häiriöitä ja mitä häiriöistä seuraisi.
Usein tällaiset pohdinnat liittyvät Disaster Recovery -suunnitelmien tekemiseen tai ainakin Disaster Recovery -valmiuksien arvioimiseen.
Jatkuvuuden hallinnan keinoja voi käyttää kuitenkin muuhunkin.
Jatkuvuuden hallinnan avulla voidaan myös arvioida, onko nykyinen IT rakennettu liian kevyeksi tai toisaalta liian järeäksi. Voisiko organisaatio säästää rahaa mitoittamalla IT paremmin toiminnan tarpeita vastaavaksi?
Itse käytän jatkuvuuden hallinnan metodiikkaa hyvin monessa tilanteessa. Jatkuvuuden hallinta sopii esimerkiksi sen arvioimiseen, miten kriittistä asiakkaan toiminta on IT:n kannalta.
Jotta tällaisia arviointeja ja keskusteluja voidaan käydä, tarvitaan parametreja, jotka kuvaavat tärkeitä suureita. Käsitellään nyt joitakin näistä yksi kerrallaan.
BIA (Business impact Analysis)
BIA (Business Impact Analysis) eli suomeksi liiketoiminnan vaikutusanalyysi pyrkii vastaamaan kysymykseen, millaisia vaikutuksia erilaisilla haitallisilla tekijöillä voisi olla tarkasteltavaan liiketoimintaprosessiin.
Vaikutusanalyysi on pohjana toiminnan jatkuvuutta uhkaavien riskien arvioinnille sekä toimintojen väliselle priorisoinnille ja niiden välisten riippuvuuksien tunnistamiselle.
BIA voidaan tehdä esimerkiksi skenaariotyön avulla. Silloin pyritään aluksi tunnistamaan erilaisia haitallisia skenaarioita. Sen jälkeen arvioidaan, mitä nämä skenaariot voisivat tarkoittaa liiketoimintaprosessin kannalta.
Ideaalitilanteessa BIAn tuloksena on euromääräisiä arvioita erilaisten tapahtumien seurauksista. Tämä auttaa johtoa arvioimaan, pitäisikö vaikutuksia pyrkiä pienentämään.
RTO (Recovery Time Objective)
RTO (Recovery Time Objective) kertoo tavoitellun toipumisajan keston.
RTO määrittelee siis ajan, jonka kuluessa kyseessä oleva asia tai toiminto tulee saada palautettua ennalleen. Aika voidaan ilmoittaa sekunteina, minuutteina, tunteina tai vuorokausina.
RTO kertoo siis ajan, jonka sisällä järjestelmän pitäisi toipua ongelmasta. RTO ei kuitenkaan ole ehdoton takaraja toipumiselle vaan ennemminkin tavoite. RTO:ta voidaan käyttää apuna esimerkiksi SLA-vaatimusten määrittelyssä.
Esimerkki
Kaupan kassajärjestelmän RTO määrittelee sen ajan, jonka kassajärjestelmä saa ongelmatilanteessa enintään olla alhaalla.
Vilkkaan nettikaupan kassajärjestelmän RTO voi olla erittäin lyhyt, ehkä joitakin minuutteja, koska asiakkaat siirtyvät hyvin nopeasti toisen kaupan asiakkaiksi, jos tutun kaupan kassajärjestelmä ei toimi.
Toisaalta jos firman brändi on hyvin vahva, asiakkaat todennäköisesti palaavat, kun järjestelmä taas toimii.
Saman firman matkalaskuohjelma ei kuitenkaan ole yhtä kriittinen. Yleensä matkalaskujen tekeminen ei ole ihan päivästä kiinni, vaikka toimimattomuus voikin harmittaa sitä onnetonta, jonka kohdalle toimimaton järjestelmä sattuu.
RTO on helppotajuinen käsite ja siksi sitä voi käyttää johdon kanssa käytäviin keskusteluihin. Jokaisen organisaation kannattaa käydä keskustelua siitä, mikä eri järjestelmien RTO:n pitäisi olla.
RPO (Recovery Point Objective)
RPO (Recovery Point Objective) kertoo sen pisteen, johon järjestelmä pitäisi pystyä palauttamaan, jos sitä kohtaa häiriö. RPO ilmoitetaan yleensä sekunteina, minuutteina tai tunteina.
RPO kertoo, miten paljon dataa saa hävitä, jos häiriö ilmenee juuri ennen seuraavan varmuuskopion ottamista.
Käytännössä RPO siis kertoo sen, miten usein järjestelmän tila halutaan varmistaa esimerkiksi varmuuskopioimalla.
RPO on käyttökelpoinen termi, kun suunnitellaan esimerkiksi varmuuskopioinnin käytäntöjä. Miten usein järjestelmästä pitää ottaa varmuuskopioita? Jos järjestelmän RPO on tiedossa, varmuuskopiointikäytäntöjen suunnittelu on helpompaa.
Toinen käyttökohde RPO:lle on korkean käytettävyyden ratkaisuiden suunnittelus (High Availability eli HA).
Kolmas käyttökohde löytyy katastrofivalmiuden parantamiseen tähtäävässä Disaster Recovery -suunnittelussa.
Esimerkki
Pankki ei halua, että sen asiakkaiden tekemiä transaktioita voi hävitä missään olosuhteessa. Pankkijärjestelmän RPO on siis nolla. Silloin kaikki järjestelmän transaktiot pitää varmistaa välittömästi.
Toisaalta monen järjestelmän osalta on ihan hyväksyttävää, että tietoja voidaan menettää yhden työpäivän verran. Tällöin RPO voi olla esimerkiksi 24h. Tämä ei tarkoita sitä, että varmuuskopioita otettaisiin tällöin vain kerran vuorokaudessa.
Jos varmuuskopiointiin on kustannustehokkaita tapoja, voidaan varmistuksia ottaa useammankin. RPO kertoo siis vain tavoitteen varmistuksille.
MTPD (Maximum Tolerable Period of Disruption)
Maximum Tolerable Period of Disruption eli MTPD on terminä peräisin jatkuvuussuunnittelun maailmasta. Se pyrkii kuvaamaan organisaation kestämän maksimikatkon pituuden.
Kun RTO kertoo tavoiteajan toipumiselle, MTPD kertoo ajan, jonka kuluttua ongelmat kasvavat kestämättömiksi. Periaatteessa MTPD voi kertoa, milloin organisaatio voi joutua lopettaa toimintansa sen vuoksi, että keskeiset IT-järjestelmät eivät toimi.
Käytän itse MTPD:tä johdon kanssa käytävissä keskusteluissa toipumisajan takarajan tunnistamiseksi. MTPD on tietyllä tavalla vahvempi termi kuin RTO, koska RTO eli tavoiteaika toipumiselle on helppo laittaa hyvin lyhyeksi.
Jos tehdään ajatusleikki, jossa koko IT-ympäristö menee alas, johdon on usein helppo tunnistaa kriittiset järjestelmät, joiden puuttuminen alkaa ensiksi tuottamaan ongelmia. Kun mietitään, mikä on ehdoton takaraja näiden järjestelmien palauttamiseksi, saadaan moneen tarkoitukseen käyttökelpoinen maksimikatkon kesto. Tämä ajanhetki on MTPD.
Miten MTPD:tä voi käyttää?
Maximum Tolerable Period of Disruption on hyvä työkalu arvioitaessa IT-infran kahdennusten ja järjestelmien tuen riittävyyttä.
Kysy toimitusjohtajalta, missä vaiheessa häiriö IT:ssä aiheuttaa niin suuria ongelmia, että kustannukset tai ongelmat alkavat kasvaa eksponentiaalisesti.
Kysy IT:ltä, missä ajassa konesali saadaan palautettua toimintaan, jos konesali tuhoutuu. Onko realistista, että palautuminen tapahtuu MTPD:n aikana?
Jos näyttää siltä, että palautuminen pahimmista skenaarioista ei onnistu johdon antaman MTPD-arvon sisällä, on löytynyt aito liiketoimintaa uhkaava riski ja sitä kautta business case IT-infran uudelleen järjestelyille tai ainakin Disaster Recovery -kyvykkyyksien parantamiseksi.
Yhteenveto
Nämä jatkuvuuden hallinnan termit on hyvä hallita, kun suunnitellaan IT-ympäristöjä:
- RTO luo pohjan esimerkiksi SLA-vaatimusten määrittelylle
- RPO puolestaan auttaa varmistusten suunnittelussa
- MTPD auttaa arvioimaan IT-infran toipumiskykyä ja toimii disaster recovery -suunnittelun pohjana
Näistä parametreista on apua suunnittelussa erityisesti silloin, kun ne määritellään yhdessä muun organisaation kanssa. Tyypillinen ongelma IT-yksiköissä on se, että IT pyrkii arvaamaan oikeat arvot muun organisaation puolesta. On paljon hedelmällisempää mennä kysymään, mitä muut ajattelevat asiasta.
BIA on luonteeltaan erilainen termi, koska se viittaa seurausten arvioimiseen. Jos haluat lukea lisää siitä, miten Business Impact Analyysia voi tehdä oikeasti, lue juttu, jossa kerrotaan, miten teimme Oras Groupin kanssa tämän tyyppisen harjoituksen. Löydät kirjoituksen täältä.
Jos pidit tästä artikkelista, myös seuraavat artikkelit voivat olla kiinnostavia: