Küsimusele „kui kaua võib ettevõte töötada ilma raamatupidamissüsteemita“ vastatakse tavaliselt „mitte tunnikski“. Küsimusele „kui mitu töötundi võite endale lubada kaotada, kui süsteem tuleb varukoopiast taastada“ vastatakse „ühtegi“. Mõlemad vastused on arusaadavad, kuid ükski pole kasulik: nendele vastustele kavandatud varundussüsteem läheks maksma rohkem kui ettevõte ise.
Tegelik vastus on alati kuskil „mitte tunnikski“ ja „nädala“ vahel ning see on iga süsteemi puhul erinev. E-postil, raamatupidamisel, tootmise juhtimisel ja failiserveril on kõigil erinevad piirid. Et neist piiridest konkreetselt rääkida, on kaks mõõdikut: RTO ja RPO.
Selles artiklis selgitame neid ilma teooriata: mida need tähendavad, kuidas määrata need juhile, kellel pole IT-tausta, kuidas need muutuvad varundussageduseks ja taastekohaks ning kuidas need üles kirjutada nii, et need sobiksid NIS2 või DORA auditiks.
RTO: kui kaua te oodata saate
RTO (Recovery Time Objective) on pikim lubatud aeg süsteemi seiskumisest selle taas töötamiseni. Mitte aeg, mille jooksul IT lubab selle taastada, vaid aeg, mille möödudes hakkab ettevõte kandma tegelikku kahju.
Näiteid meie klientide igapäevast:
- Raamatupidamine. Kaubandusettevõttes ei saa ilma raamatupidamissüsteemita arveid välja anda ega kaupa vastu võtta. RTO on neli tundi: pool päeva saab töötada paberist saatelehtedega ja need hiljem sisestada, terve päeva mitte.
- E-post. Teenindusettevõttes, kus kogu suhtlus klientidega käib e-posti teel, on RTO üks tund. Logistikalaos, kus tellimused tulevad süsteemi kaudu ja e-posti kasutatakse sisesuhtluseks, on see päev.
- Tootmise juhtimissüsteem. Kui liin seiskub ilma süsteemita, mõõdetakse RTO-d minutites või kümnetes minutites ja varukoopiast taastamine ei ole üldse esimene vastus. Esimene vastus on dubleeritud süsteem.
RTO määrab ettevõte, mitte IT. IT vastab küsimusele, kas seatud RTO on saavutatav ja mis see maksab.
RPO: kui palju tööd te kaotada võite
RPO (Recovery Point Objective) on pikim lubatud periood andmeid, mille kaotada võite. Praktikas on see aeg viimasest töötavast varukoopiast intsidendini.
Samad näited:
- Raamatupidamine. Kui varukoopia tehakse igal ööl, kaob halvimal juhul terve tööpäev: selle päeva kõik arved, maksed ja laoliikumised. Kaks raamatupidajat sisestaksid need uuesti päeva või kahe jooksul. Ettevõte otsustab, et RPO on neli tundi, ja varukoopiaid tehakse iga nelja tunni tagant.
- E-post. Sõnumid, mis saabusid pärast viimast varukoopiat, ei kao Microsoft 365 keskkonnas, seega on RPO siin sagedamini seotud kustutatud või krüpteeritud andmetega kui ajaga. Päev tavaliselt sobib.
- Tootmissüsteem. Kaotatud tunnid tähendavad, et pole teada, mida toodeti ja milliste materjalidega. RPO on minutid, mis tähendab, et tegu pole enam varukoopiatega, vaid pideva replikatsiooniga.
RTO ja RPO on teineteisest sõltumatud. Teil võib olla süsteem, mille taastate tunniga, kuid kaotate päeva andmeid, ja vastupidi.
Kuidas hinnata seisaku maksumust ilma eurodeta
Juhid takerduvad sageli seisaku hinna määramisse. Seda pole vaja. Süsteemi kohta piisab kolmest lihtsamast küsimusest:
- Kui paljud inimesed lõpetavad töö, kui süsteem on maas? Kümme laotöötajat ja kaks raamatupidajat on kaksteist inimest, kes istuvad ja ootavad. Korrutage tundidega.
- Kui palju tellimusi, saadetisi või arveid tunnis selle süsteemi kaudu liigub? Need tuleb uuesti sisestada või need lähevad üldse kaduma.
- Mis juhtub kliendiga? Ta ei saa saadetist, ei saa vastust, ei saa maksta. Siit algavad lepingulised kohustused ja maine.
Kirjutage vastused kolmeveerulisse tabelisse: süsteem, mis seiskub tunni pärast, mis seiskub päeva pärast. RTO ja RPO tulenevad sellest loomulikult ning tavaliselt selgub, et kahekümnest süsteemist on tõeliselt kriitilised neli või viis. Just need väärivad suurimat osa varunduseelarvest.
Kuidas RTO ja RPO muutuvad tehnoloogiaks
Siin algab IT töö. Kaks mõõdikut juhivad kahte otsust.
RPO määrab varundussageduse
Kui RPO on päev, piisab öisest varukoopiast. Kui see on neli tundi, tehakse varukoopiad või hetktõmmised iga nelja tunni järel, mis on juba nõue salvestusele ja võrgule. Kui see on minutid, varukoopiad enam ei sobi ja vaja on reaalajas replikatsiooni teise asukohta. Iga samm allapoole on kallim, seega ei tohiks RPO olla lühem, kui ettevõte on tegelikult otsustanud.
RTO määrab, kuhu ja millest te taastate
Taasteaeg koosneb kolmest osast: kuni märkate, kuni leiate, kuhu taastada, ja kuni taastate. Kui serveriruum on maha põlenud, ei pruugi teist osa olla üldse, sest taastada pole kuhugi. Lühike RTO tähendab seega ette valmistatud asukohta.
| RTO | Mida see praktikas tähendab |
|---|---|
| Nädal | Piisab varukoopiast; uue serveri saab tellida ja ette valmistada |
| Päev | Vaja on varuasukohta, kus server varukoopiast üles tõsta |
| Tunnid | Vaja on eelnevalt ettevalmistatud keskkonda ja testitud protseduuri |
| Minutid | Vaja on dubleeritud süsteemi, mis töötab kogu aeg |
Meie PlanB taristu taaste on loodud just „päeva“ ja „tundide“ ridade jaoks: teie serverite varukoopiaid hoitakse meie pilves ja nende kõrval on ette valmistatud keskkond, kus need varukoopiad käivitatakse töötavate serveritena, kuni teie taristut parandatakse. Varundamise poolt katavad serverite varukoopiad teie määratud sagedusega.
Üks nüanss veel: RTO, mida keegi pole mõõtnud, on dokumendis vaid number. Tegeliku taasteaja saate teada ainult süsteemi isoleeritud keskkonda taastades ja kella vaadates.
Kuidas dokumenteerida NIS2 ja DORA jaoks
Mõlema regulatsiooni puhul on RTO ja RPO juhtimisteave, mitte tehniline teave. NIS2 nõuab tegevuse järjepidevuse ja varukoopiate haldamise meetmeid ning DORA nõuab IKT tegevuse järjepidevuse poliitikat selgete taastamiseesmärkidega oluliste funktsioonide jaoks. Praktikas piisab audiitorile ühest sellise ülesehitusega dokumendist:
- Süsteemide nimekiri koos nende kriitilisuse hinnanguga.
- Iga süsteemi kohta RTO, RPO ja see, kes need ärilises mõttes kinnitas.
- Milline tehniline meede kumbagi mõõdikut tagab: varundussagedus, salvestuskoht, taastekoht.
- Millal viimati kontrolliti, et mõõdikud on saavutatavad, ja mis oli tulemus.
- Millal dokumenti üle vaadatakse: vähemalt kord aastas ja pärast suuri muudatusi.
Kui valmistame ettevõtteid ette DORA nõueteks, koostame tavaliselt just selle dokumendi esimesena, sest kõik hilisemad varundus- ja taasteotsused sõltuvad sellest.
Kust alustada
- Tehke nimekiri kõigist ettevõtte süsteemidest ja vastake iga kohta küsimusele, mis seiskub tunni pärast ja mis päeva pärast.
- Määrake viiele kõige olulisemale süsteemile RTO ja RPO koos nende äriomanikega, mitte ainult IT-ga.
- Võrrelge sellega, kuidas varukoopiaid täna tehakse: kui RPO on neli tundi ja varukoopia on öine, on teil lünk, millest teate ainult teie.
- Taastage üks kriitiline süsteem isoleeritud keskkonda ja mõõtke tegelik RTO.
- Kui soovite, et teeksime selle töö koos teiega ja koostaksime auditile sobiva dokumendi, võtke meiega ühendust kontaktivormi kaudu.
