RTO ja RPO - Toipumistavoitteet

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:

• RTO Recovery Time Objective, joka ilmaisee katkon hyväksyttävän enimmäiskeston. Tällä tavoitteella on varsin merkittävät kustannusvaikutukset. On aivan eri asia toivuttaa 10 gigatavun tietokanta 10 tunnissa kuin 100 gigatavun yhdessä tunnissa. RTO on siis business case! Järjestelmät ja infrastruktuuri pitää rakentaa siten, että tämä tavoite toteutuu. Kumpikaan yksin yleensä ei kykene kantamaan vastuuta varsinkaan tiukoista RTO-tavoitteista.
• RPO Recovery Point Objective, joka ilmaisee, kuinka paljon (ajassa mitaten) työtä saa enintään mennä hukkaan uudelleen tehtäväksi. Nykyaikaisilla tietokantajärjestelmillä on mahdollisuus päästä RPO-tavoitteessa nollaan, mutta nämä ratkaisut tehdään RTO:n kustannuksella. Kunnollisella tietokantasuunnittelulla ja infran kanssa tehtävällä yhteistyöllä on mahdollista päästä toimivaan kompromissiin. Eritoten on hyvä huomata, että pelkillä päivittäisvarmistuksilla ei ole mahdollista päästä alle 24 tunnin RPO-tavoitteisiin.

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.