El objetivo de tiempo de recuperación es una decisión, no un ajuste
El objetivo de tiempo de recuperación dice cuánto puede estar caído un sistema antes de que resulte inaceptable. No es una cifra que salga de la técnica: sale del negocio, y la técnica se construye después a su medida.
Dos cifras, dos preguntas
Se nombran juntas y miden cosas distintas. Confundirlas lleva a comprar la solución equivocada.
Objetivo de tiempo frente a objetivo de punto de recuperación
El RTO va de tiempo sin sistema. El RPO va de trabajo perdido. Los dos cuestan dinero, y lo cuestan en sitios distintos.
- RTO: cuánto hasta que funcione otra vezMedido desde que algo falla hasta que el usuario puede continuar. Incluido el tiempo que cuesta decidir que se va a recuperar: esa parte se olvida en casi todas las estimaciones y en la práctica suele ser la más larga.
- RPO: cuánto trabajo puede desaparecerLa distancia entre la última copia utilizable y el momento de la caída. Un RPO de una noche significa que puede haber que repetir un día entero. Para algunos sistemas está bien; para la gestión de pedidos, normalmente no.
- Aprietan botones distintosUn RTO más corto exige estar preparado: un entorno listo, gente que pueda conmutar. Un RPO más corto exige copiar más a menudo o de forma continua. Se pueden elegir por separado, y suele ser lo sensato.
- Se fijan por sistemaUn solo RTO para toda la organización lleva a invertir de más donde no hace falta y de menos donde sí. La lista puede ser corta, pero es por sistema.
Cómo se llega a un RTO que se sostiene
Cuatro pasos. El primero es el único que no trata de TI, y decide el resto.
Pregúnteselo al proceso, no a TI
Qué pasa en el trabajo si este sistema no está: va más lento, va a mano, o no va. Solo en el tercer caso se defiende un RTO corto, y entonces suele defenderse fácil.
Calcule lo que hace una hora de parada
No en una cifra genérica, sino en sus propias unidades: pedidos que no entran, gente que espera, entregas que se mueven, compromisos que no se cumplen. Ese número acorta de golpe la conversación sobre lo que cuesta recuperar.
Mida lo que consigue hoy
Restaure una vez un sistema en un entorno aparte y cronométrelo. Casi toda primera medición decepciona, y es la cifra más útil de todo el ejercicio: la única que no es una estimación.
Elija, y anote lo que cuesta la elección
Entre el RTO deseado y el medido hay una distancia, y esa distancia cuesta dinero o se acepta. Ambas son respuestas válidas; no escribirlo no lo es, porque entonces la elección aparece durante la caída.
Por qué en la práctica no se cumple un RTO
Cuatro causas que vemos una y otra vez, y ninguna está en el software de copias.
- El reloj empezó antes de lo pensadoLa detección y la decisión cuentan. Si pasa una hora hasta que alguien se da cuenta de que va en serio y otra hasta que alguien puede decidir, la mitad de un RTO de cuatro horas se ha ido antes de que ocurra nada.
- La restauración nunca se ejecutóUna copia que termina bien no es una restauración que termina bien. Certificados que faltan, licencias atadas a hardware e integraciones hacia fuera solo aparecen al devolverlo.
- Querer recuperarlo todo a la vezSin un orden, el RTO de cada sistema se convierte en el del más lento. Un orden acordado de antemano quita la discusión en el momento en que no hay tiempo para ella.
- No había nadie de guardiaLa técnica estaba lista y las personas no. Quien promete un RTO corto debería decir también quién lo cumple un domingo por la mañana, y ahí es donde una empresa externa marca la diferencia.
Preguntas que nos hacen sobre esto
Las más habituales, respondidas en breve.
¿Qué significa exactamente objetivo de tiempo de recuperación?
El tiempo que puede pasar entre la caída de un sistema y el momento en que el usuario puede continuar. Incluido el tiempo para darse cuenta y decidir que se va a recuperar, la parte que casi todas las estimaciones olvidan.
¿Cuál es la diferencia entre RTO y RPO?
El RTO mira hacia delante: cuánto hasta que vuelva a funcionar. El RPO mira hacia atrás: cuánto trabajo se pierde desde la última copia utilizable. Un RTO más corto exige estar preparado, un RPO más corto exige copiar más a menudo.
¿Cómo sé qué RTO conseguimos hoy?
Restaurando un sistema en un entorno aparte y cronometrándolo. Es la única cifra de todo el ejercicio que no es una estimación, y casi toda primera medición decepciona.
¿Medimos lo que consiguen hoy?
Restaurar un sistema en un entorno aparte y dejar correr el reloj. Es el camino más corto a un RTO que no sea una estimación, y normalmente también a la primera sorpresa.
Conocimiento práctico de TI en tu bandeja
Nuevas guías sobre gestión, seguridad y el puesto de trabajo, escritas por quienes hacen el trabajo. Sin discursos comerciales, y puedes darte de baja con un clic.