RPO kuvaa tietojen menetyksen ikkunaa, jonka olet valmis hyväksymään; RTO kuvaa keskeytystä, jonka pyrit pitämään sen sisällä. Määritä molemmat hyödylliselle liiketoimintatoiminnolle ja todista sitten palautusjärjestys harjoituksessa. Pelkkä varmuuskopiointiaikataulu tai palvelinmääritys ei vahvista kumpaakaan tavoitetta.
Aloita palvelusta, jota ihmiset voivat käyttää
Palautustavoitteista tulee hyödyllisiä, kun ne kuvaavat liiketoimintatoimintoa yksittäisen koneen sijaan. Palvelin voi käynnistyä, vaikka asiakkaat eivät vieläkään voi kirjautua sisään, noutaa tiedostoja tai suorittaa pyyntöä loppuun. Kirjoita lopputila tavallisella kielellä: valtuutetut käyttäjät voivat käyttää sovellusta ja tarvittavat tiedot ovat yhdenmukaisia. Tämä tekee tavoitteesta testattavan myös infrastruktuuritiimin ulkopuoliselle henkilölle.
Kysy sovelluksen omistajalta, mitä keskeytys estäisi ja mitä puuttuvat tiedot maksaisivat. Viikoittaisella julkaisulla ja tapahtumankäsittelysovelluksella voi olla erilaiset vastaukset. Käsittele syntyviä tavoitteita suunnittelutavoitteina, ei laiteluettelosta keksittyinä lupauksina. Kirjaa, kuka ne hyväksyi ja mitkä vikaskenaariot suunnitelma kattaa.
Erota kaksi kelloa
RPO koskee sitä, kuinka kauas taaksepäin palautetut tiedot voivat olla suhteessa häiriöön. RTO koskee sitä, kuinka kauan toiminto voi olla poissa käytöstä. Tuore varmuuskopio voi parantaa tietojen menetyksen ikkunaa, kun taas hidas palautus voi silti jäädä palautusaikatavoitteesta. Toisaalta nopea uudelleenkäynnistys voi palauttaa pääsyn sovellukseen, jonka uusimmat tiedot eivät ole säilyneet.
Määritä vertailukohdat. Päätä, milloin tapahtuman kello alkaa, mikä lasketaan palautetuksi toiminnaksi ja miten käyttökelpoinen tietopiste tunnistetaan. Pidä tavoitteet erillään mitatuista tuloksista: tavoite on se, mitä tavoittelet; harjoitus näyttää, mitä nykyinen prosessi saavutti. Palaa kumpaankin, kun sovellus tai tietoaineisto muuttuu.
Budjetoi palautuksen jokainen vaihe
Käytännöllinen RTO-budjetti sisältää havaitsemisen, arvioinnin, valtuutuksen, pääsyn palautusympäristöön, palautuksen, sovelluksen validoinnin ja uudelleenavaamisen. Tiedostojen kopiointiaika on vain yksi osa. Jos palautusavaimen haltija ei ole käytettävissä, teoreettisesti nopea varmuuskopio voi silti olla käyttökelvoton. Luettele riippuvuudet ja varmista, että palautustiimi voi tavoittaa ne tarkasteltavan vian aikana.
Anna jokaiselle vaiheelle alustava aika ja korvaa sitten arviot havainnoilla. Tässä havainnollistavassa kahden tunnin budjetissa palautus saa suurimman osuuden, mutta validointiin jää silti suojattua aikaa. Luvut kuvaavat suunnitteluesimerkkiä, eivät SwissOctet-palvelun toimitusta. Jos kokonaisuudessa ei ole marginaalia, suunnittelua on parannettava ennen kuin tavoite on uskottava.
| Palautusvaihe | Havainnollistava osuus | Kerättävä todiste |
|---|---|---|
| Havaitse ja arvioi | 15 minuuttia | Hälytyksen saapuminen ja tapahtumapäätös |
| Valmistele palautusympäristö | 20 minuuttia | Pääsy ja kokoonpano käytettävissä |
| Palauta tiedot ja palvelu | 50 minuuttia | Suoritettu palautus yhdenmukaisilla tiedoilla |
| Validoi ja avaa uudelleen | 25 minuuttia | Käyttäjän polku onnistuu |
| Varautumismarginaali | 10 minuuttia | Odottamaton työ kirjattu |
Tarkista todellinen tietojen menetyksen ikkuna
Joka tunti ajastettu työ ei automaattisesti tuota yhden tunnin RPO:ta. Epäonnistunut työ, viivästynyt siirto tai käyttökelvoton kopio voi tehdä viimeisimmästä palautettavasta pisteestä paljon vanhemman. Tarkkaile onnistunutta suoritusta ja tilaa, joka voidaan todella palauttaa. Jos sovelluksessa on useita tietovarastoja, varmista, että niiden palautuspisteet ovat yhteensopivia sen sijaan, että lukisit jokaista aikaleimaa erikseen.
Valitse harjoituksen aikana viitetapahtuma, kuten valtuutettu testitietue, joka on luotu tunnetulla hetkellä. Tunnista palautuksen jälkeen uusin kelvollinen tietue ja mittaa ero. Käytä vaaratonta testidataa. Tämä antaa käytännöllisen tuloksen ja paljastaa oletukset, jotka vain työn onnistumisen näyttävä koontinäyttö saattaisi jättää piiloon.
Valitse strategia budjetin puitteissa
Varmuuskopiointi ja palautus, valmiit varaympäristöt ja replikoidut sovellusmallit vaihtavat kustannuksia ja monimutkaisuutta palautusnopeuteen. Replikointi voi vähentää joitakin viiveitä, mutta voi myös toistaa vahingossa tapahtuneen poiston tai sovellusvirheen. Varaympäristö, joka on ajautunut pois toimivasta kokoonpanosta, luo oman riskinsä. Valitse strategia dokumentoimiesi vikaskenaarioiden ja tavoitteiden perusteella.
Harkitse pientä palvelua, jonka tavoite on neljä tuntia, ja suurempaa tietoaineistoa, jonka pelkkä palautus kestää harjoituksessa kuusi tuntia. Nopeamman verkkoportin ostaminen on vain hypoteesi: tallennuksen luvut, vastaanottavat kirjoitukset ja sovelluksen palautus voivat hallita tilannetta. Paranna mitattua rajoittavaa vaihetta, pienennä palautusjoukkoa tai vaihda strategiaa ja harjoittele uudelleen.
Harjoittele vaarantamatta tuotantoa
Käytä eristettyä palautusympäristöä ja määriteltyä harjoitusikkunaa. Varmista, että palautetut työt eivät voi lähettää oikeita ilmoituksia, vastaanottaa julkisia maksuja tai kirjoittaa tuotannon integraatioihin. Testaa pääsy, tietojen eheys ja edustavat käyttäjäpolut ennen kuin katsot harjoituksen valmiiksi. Ota mukaan henkilö, joka ei kirjoittanut alkuperäistä menettelyä, jotta puuttuvat ohjeet paljastuvat.
Pidä aikajanaa harjoituksesta, saavutetusta palautuspisteestä ja jokaisesta keskeytyksestä, jonka puuttuva tieto aiheutti. Hyödyllinen raportti ilmoittaa mitatun tuloksen, eron tavoitteeseen ja konkreettisen korjaavan toimenpiteen. Toista merkityksellisten muutosten jälkeen ja projektin tärkeyteen sopivin väliajoin.
Pidä suunnitelma käyttökelpoisena vian aikana
Säilytä palautusmenettelyä paikassa, johon tiimi pääsee käsiksi ilman, että se on kokonaan epäonnistuneen sovelluksen varassa. Pidä tunnistetiedot ja salausavaimet suojatussa paikassa, jossa on testattu käyttöoikeusprosessi. Päivitä yhteystiedot, tietoaineistojen koot ja riippuvuudet projektin kehittyessä. Vanhentunut suunnitelma voi kuluttaa aikamarginaalin ennen kuin palautus edes alkaa.
Kun vertailet SwissOctet-kokoonpanoja, erota palautusarkkitehtuurisi luettelon valinnaisista varmuuskopiointivaihtoehdoista. Varmista, mitä vaihtoehto kattaa, missä palautustiedot säilytetään ja kuka suorittaa palautuksen. Luettelo ei vahvista sovelluksen RPO:ta tai RTO:ta. Mitattu prosessisi ja todelliset palveluehdot muodostavat perustan tälle päätökselle.
Käytännön tarkistuslistasi.
- Määritä palautettu liiketoimintatoiminto.
- Hyväksy erilliset RPO- ja RTO-tavoitteet.
- Budjetoi havaitseminen, pääsy, palautus ja validointi.
- Mittaa uusin käyttökelpoinen tietopiste.
- Harjoittele eristetyssä ympäristössä.
- Kirjaa puutteet ja toista olennaisten muutosten jälkeen.
Olennaiset yksityiskohdat.
Onko RTO sama kuin käytettävyysaika?+
Ei. RTO on palautustavoite keskeytysskenaariolle. Käytettävyysaika mittaa saatavuutta tietyllä ajanjaksolla; toinen ei vahvista toista.
Takaako tunneittainen varmuuskopiointi yhden tunnin RPO:n?+
Ei. Tarkista valmiit, käyttökelpoiset kopiot ja sovelluksen yhdenmukaisuusvaatimukset. Epäonnistuneet työt ja viivästyneet siirrot voivat kasvattaa palautettavissa olevien tietojen eroa.
Täytyykö jokaisen projektin käyttää varapalvelinta?+
Valitse strategia projektin palautustavoitteiden ja mitatun palautusprosessin perusteella. Varapalvelin lisää kustannuksia ja toiminnallista monimutkaisuutta, eikä se ole automaattisesti tarpeen.
Mene lähteelle.
Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista.
- NIST SP 800-34 Rev. 1: Contingency Planning Guide nvlpubs.nist.gov
- AWS Well-Architected: Määritä palautustavoitteet docs.aws.amazon.com
- Microsoft Learn: Liiketoiminnan jatkuvuus, korkea käytettävyys ja katastrofipalautus learn.microsoft.com
Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen.