Lue
lisää:

Matti Grönroos

RTO ja RPO - Toipumistavoitteet

Kaikkihan muistamme vanhan kansansadun, jossa hiiri kissalle takkia ompeli. Hassustihan siinä kävi.

Tietotekniikan parhaisiin (?) perinteisiin kuuluu, että rakentamisvaiheessa järjestelmien toipumiskyvyn suunnitteluun ei juuri kiinnitetä huomiota. Sen sijaan katsotaan lopuksi, mitä syntyi. Vähän kuin hiiri kunkin sprintin jälkeen: ei tullut takkia, ei housuja ja tuluskukkaronkin kanssa oli vähän niin ja näin.

Asiaa olisi mahdollista tarkastella systemaattisemminkin, ja asettaa tavoitteita siinä kuin toiminnallisiakin. Toipumista ohjaamaan on tarjolla kaksi lyhennettä: RTO ja RPO, Recovery Time Objective ja Recovery Point Objective.

Kuten käyttökatko-osiomme kertoo, käyttökatkot ovat kovin mielenkiintoisia juttuja. Sen sijaan niitä oleellisempaan, eli käyttökatkoista toipumiseen yleensä jaksetaan kiinnittää vähemmän huomiota. Se ehkä ei ole niin seksikästä kuin uusimmilla työkaluilla koodaaminen, mutta sillä voi olla merkittävä vaikutus liiketoimintaan.

Höyrykoneiden IBM-keskuskoneiden aikoihin infrastruktuurin uudelleenkäynnistys oli hidas homma, mutta kun se oli valmis, reikäkortinlukijat alkoivat iloisesti lopsotella korttipakkoja nieluunsa ja tuotanto lähti käyntiin, kun oli lähteäkseen. Ylivertainen kiinnostus nimenomaan infran katkoihin lienee tältä ajalta. Tosin merkitystä on silläkin, että erilaiset mittariohjelmat ovat aina osanneet raportoida juuri tästä.

Kun liiketoiminta on tietotekniikasta kiinni, koko arvoketju on aihetta suunnitella siten, että häiriöiden sattuessa liiketoiminta ei kohtuuttomasti kärsi pitkittyneestä toipumisesta. Siksi on hyvä määritellä ainakin karkeasti kaksi toipumista ohjaavaa tavoitetta:

Siis mitä lähemmäs nollaa RTO:n ja RPO:n osalta lähestytään, sen syvemmältä kukkaroa joudutaan kaivamaan.

Jos sitten eritoten RTO:ta lähdetään viemään palvelutasosopimuksiin ja sanktioiduksi saakka, on välttämätöntä sopia siitä, mikä on käyttökatkon alkamisen ja erityisesti päättymisen kriteeri.

Alkamisaikakaan ei ole aivan yksikäsitteinen. Yleensä sellaiseksi katsotaan se hetki, kun joko käyttäjien antama ilmoitus saapuu palveluntuottajalle tai kun palveluntuottaja sen omilla valvontajärjestelmillä sen havaitsee. Jälkimmäinen ei välttämättä ole palvelunsaajan todennettavissa. Myös se on keskustelemisen paikka, katsotaanko ennen ennakoimatonta uudelleen käynnistystä tehty vianselvitys häiriönhallinnaksi vai osaksi käyttökatkoa.

Päättymisajassa sitten onkin enemmän valinnanvaraa.

Jokainen näistä – ja muutama muukin – on aivan validi vaihtoehto jollakin perusteella. Oleellista on löytää yhteinen näkemys. Puhdasta infrastruktuuripalvelua tuottava toimittaja mitä todennäköisimmin ei halua vastata ketjusta pitemmälle kuin kohtaan 4 saakka. Siitä huolimatta on hyvä löytää jokin taho, jonka vastuulla on saattaa toivuttaminen perille asti.