Recovery time

Recovery time er den tid, det tager at genetablere en ressource eller tjeneste til et aftalt funktionsniveau. En brugbar måling kræver et defineret startpunkt og et konkret slutpunkt, eksempelvis fra driftsafbrydelsen til en kontrolleret brugeropgave igen fungerer.

Tiden kan omfatte afklaring, beslutning, gendannelse, genopbygning af afhængigheder og validering. Hvis et værktøj kun måler selve restorejobbet, skal den snævrere måling beskrives som sådan.

Hvorfor er begrebet vigtigt?

En tjeneste er ikke nødvendigvis tilbage, når en virtuel maskine er startet. Identiteter, netværk, databaser, integrationer og kapacitet kan stadig forhindre brugerne i at arbejde. Målingen skal derfor svare til den funktion, virksomheden har brug for.

Recovery time bruges til at vurdere, om et beredskab kan opfylde det aftalte Recovery Time Objective (RTO). RTO er målet; den observerede varighed viser resultatet i et bestemt forløb. Afvigelser giver et konkret grundlag for at forbedre adgang, procedurer og tekniske afhængigheder.

Typisk misforståelse

En hurtig dataoverførsel er ikke det samme som hurtig genetablering af hele tjenesten. Et færdigt backupjob siger heller ikke noget om tiden til en fremtidig gendannelse. AWS Backup angiver eksempelvis, at restoretid kan variere med belastning og kapacitet og ikke har en særskilt tids-SLA fra tjenesten.

Recovery time fortæller heller ikke, hvor nye de gendannede data er. Det vurderes gennem det valgte recovery point og RPO, mens tiden til at komme i drift måles særskilt.

Eksempel

En fiktiv ordreportal skal i en øvelse genetableres inden for to timer. Teamet aftaler at måle fra den simulerede afbrydelse kl. 09.00, indtil en testbruger kan gennemføre og genfinde en prøveordre.

Databasen er gendannet kl. 10.10, men login og integrationer er først afprøvet kl. 10.45. Recovery time er derfor 105 minutter efter den aftalte definition, ikke restorejobbets kortere varighed. Øvelsen opfylder totimersmålet for det afprøvede scope; den beviser ikke, at alle katastrofescenarier kan håndteres lige så hurtigt.

Best practice

• Aftal startpunkt, slutpunkt, omfang og nødvendigt funktionsniveau med serviceejeren.

• Registrér både samlet varighed og deltrin, så ventetid og tekniske flaskehalse bliver synlige.

• Medtag identiteter, nøgler, netværk og eksterne afhængigheder i realistiske prøver.

• Kontrollér en konkret brugeropgave og datakvaliteten før accept, ikke kun et grønt jobresultat.

• Gentag øvelsen efter væsentlige ændringer, og beskriv hvilke hændelser og forudsætninger den dækkede.