Cómo definir el RTO y el RPO de una aplicación empresarial: guía práctica de planificación

El RTO y el RPO responden a preguntas distintas sobre la recuperación

El objetivo de tiempo de recuperación (RTO) es el tiempo que un sistema o proceso empresarial puede permanecer fuera de servicio antes de que el impacto resulte inaceptable. El objetivo de punto de recuperación (RPO) es la cantidad de datos recientes que la empresa puede permitirse perder, expresada como un periodo de tiempo.

Imagina que una aplicación falla después de que se haya realizado la última copia de seguridad recuperable la noche anterior. El RPO describe la cantidad de trabajo introducido desde ese punto de recuperación que podría perderse. El RTO describe cuánto tiempo puede tolerar la empresa que la aplicación no esté disponible mientras se restaura y vuelve a estar operativa.

Estos objetivos están relacionados, pero uno no determina el otro. Una empresa podría necesitar recuperar una aplicación rápidamente, aunque pueda volver a crear algunos datos recientes; o podría tolerar una interrupción más prolongada, pero tener muy poca tolerancia a la pérdida de transacciones.

Empieza por el flujo de trabajo empresarial, no por el servidor

Haz una lista del trabajo que facilita la aplicación antes de hablar de objetivos de recuperación. Un CRM puede servir para ventas y atención al cliente; una tienda en línea, para consultar productos, realizar pedidos y procesar pagos. La pregunta importante es qué no pueden hacer las personas cuando la aplicación no está disponible o sus datos están desactualizados.

Para cada flujo de trabajo, identifica quiénes se ven afectados, si el trabajo se detiene por completo y qué alternativas existen. Por ejemplo, el personal quizá pueda registrar solicitudes temporalmente en otro sistema aprobado, pero esa solución alternativa podría ser lenta, limitada o inadecuada para ciertos datos.

Un buen punto de partida es una evaluación breve del impacto en el negocio: identifica los procesos críticos, los sistemas de los que dependen y las consecuencias de una interrupción. Incluye a las personas que realizan el trabajo, no solo a quien se ocupa de la aplicación.

• Indica el flujo de trabajo y las funciones de la aplicación de las que depende.
• Identifica al personal, los clientes o los socios afectados por una interrupción.
• Registra cualquier proceso manual o alternativo, sus limitaciones y quién puede autorizar su uso.
• Anota qué actividades empresariales deben reanudarse primero.

Calcula el impacto de una interrupción en distintos periodos

No elijas un RTO porque una cifra concreta parezca tranquilizadora. Calcula qué implica una interrupción en varios periodos, como un corte breve, una parte de la jornada laboral y una interrupción más prolongada. Los intervalos adecuados dependen de cómo funciona la empresa.

Ten en cuenta las ventas perdidas, los compromisos de servicio incumplidos, el personal que no puede trabajar, las decisiones retrasadas y los clientes que podrían acudir a otro lugar. Pregunta en qué momento el impacto combinado supera lo que la empresa puede asumir. Ese punto ayuda a definir un objetivo de RTO; no demuestra que la recuperación vaya a completarse para entonces.

Distingue el tiempo necesario para restablecer el acceso técnico del tiempo necesario para reanudar el proceso empresarial. Una aplicación puede estar en funcionamiento mientras el personal todavía debe verificar registros, confirmar el acceso o resolver el trabajo pendiente.

• Describe las consecuencias de una interrupción en cada intervalo que elijas.
• Incluye tanto las alteraciones operativas como los efectos financieros directos.
• Identifica el punto en que una solución alternativa deja de ser aceptable.
• Acuerda qué significa que el flujo de trabajo esté «recuperado», no solo que el servidor esté en funcionamiento.

Elige el RPO analizando qué datos se pueden volver a crear

Para cada flujo de trabajo, identifica los registros que se crean o modifican durante las tareas habituales y pregúntate cuánta de esa información podría reconstruirse después de una interrupción. Un catálogo de productos quizá pueda recuperarse de otra fuente, mientras que los pedidos, pagos o cambios recientes en los datos de clientes podrían ser difíciles o imposibles de recrear con exactitud.

El periodo de pérdida de datos aceptable puede variar entre las distintas partes de una misma aplicación. Piensa qué ocurriría si la empresa tuviera que volver a introducir el trabajo reciente y si esa reintroducción podría ser completa, oportuna y segura. Incluye el riesgo de duplicar registros o generar incoherencias si las personas utilizan una solución alternativa durante una interrupción.

Expresa el RPO como una tolerancia empresarial, no como una suposición sobre la frecuencia con la que se guardan los datos. Después, hay que comprobar que las medidas de recuperación se ajusten a esa tolerancia.

• Enumera los datos importantes de cada flujo de trabajo, incluidas las transacciones, los archivos subidos y los cambios en registros existentes.
• Clasifica cada elemento como fácil, difícil o imposible de recrear.
• Pregunta cuánto trabajo reciente podría repetirse sin generar costes, confusión o riesgos inaceptables.
• Registra la antigüedad aceptable de los datos recuperables para cada flujo de trabajo.

Identifica las dependencias que también se necesitan para la recuperación

Una aplicación es solo una parte del servicio. La planificación de la recuperación debe incluir las tecnologías y los servicios auxiliares que afectan al proceso empresarial, aunque normalmente no se consideren críticos por sí solos.

Traza el recorrido que sigue una persona para completar el trabajo. Según la aplicación, ese recorrido puede incluir una base de datos, archivos subidos, identidad o autenticación, DNS, enrutamiento, certificados TLS, correo electrónico u otros servicios externos. Confirma qué dependencias son esenciales, quién las gestiona y qué debe ocurrir antes de que los usuarios puedan volver a trabajar.

Ten en cuenta también las integraciones y los socios externos. Es posible que una aplicación restaurada no permita completar el flujo de trabajo si un servicio conectado esencial no está disponible o si hay que revisar su conexión.

• Enumera la aplicación, la base de datos y los archivos necesarios para el flujo de trabajo.
• Incluye las dependencias de acceso, nombres de dominio y conexión cuando corresponda.
• Registra los servicios externos y los socios de los que depende la aplicación.
• Identifica a una persona responsable o un contacto para cada dependencia y anota el orden de recuperación.

Define objetivos distintos cuando varíe la importancia para el negocio

Aplicar un único RTO y un único RPO a todas las aplicaciones puede ocultar diferencias importantes. Define los objetivos para cada aplicación o flujo de trabajo según su impacto empresarial, su tolerancia a la pérdida de datos y las alternativas disponibles.

Por ejemplo, el flujo de trabajo que recibe pedidos de clientes puede tener necesidades de recuperación distintas de las de un proceso interno de elaboración de informes que use la misma aplicación. Documenta el motivo de cada diferencia para que los objetivos reflejen las prioridades del negocio y no una clasificación informal del software.

Si varios flujos de trabajo dependen de una sola aplicación, indica cuál determina la prioridad de recuperación. Asegúrate de que las personas responsables de esos flujos de trabajo estén de acuerdo con los objetivos propuestos.

• Agrupa las aplicaciones o los flujos de trabajo según su impacto empresarial, no solo por conveniencia técnica.
• Asigna un RTO y un RPO a cada grupo o caso de uso pertinente.
• Explica el motivo empresarial de cada objetivo.
• Revisa los conflictos cuando una aplicación dé servicio a flujos de trabajo con prioridades distintas.

Comprueba que los objetivos sean alcanzables

Un objetivo solo es útil si la implementación y las medidas de recuperación elegidas pueden respaldarlo razonablemente. Compara cada objetivo con las formas reales de recuperar la aplicación y sus datos. Ten en cuenta las dependencias, el tiempo necesario para tomar decisiones, el acceso al proceso de recuperación y el trabajo necesario para verificar el servicio restaurado.

No des por hecho que la frecuencia de las copias de seguridad equivale al RPO, ni que disponer de una copia de seguridad demuestra que se puede cumplir el RTO. La organización debe entender qué incluye la recuperación, cómo se restablecen los datos y servicios necesarios y cómo se confirma que todo está listo para reanudar la actividad.

Airbip gestiona implementaciones de aplicaciones de catálogo como cargas de trabajo Docker en sus servidores en la nube, automatiza el enrutamiento y los certificados TLS mediante Traefik y Let’s Encrypt, y ofrece comprobaciones de DNS, gestión del ciclo de vida de los servicios y copias de seguridad configurables diarias, semanales y mensuales. Estas capacidades no garantizan que se alcance un RTO o un RPO concreto. Revisa los detalles del servicio vigente y las necesidades de recuperación de tu aplicación específica antes de decidir si la solución es adecuada.

Si las medidas de recuperación no pueden respaldar los objetivos propuestos, revisa los objetivos, la solución alternativa del negocio o el enfoque de implementación. No presentes como garantía un objetivo que no se ha probado.

• Confirma qué datos y dependencias cubren las medidas de recuperación.
• Comprueba cómo se inicia la recuperación y quién tiene acceso y autoridad para hacerlo.
• Compara los tiempos de las copias de seguridad y los procedimientos de restauración con los objetivos de RPO y RTO.
• Identifica las carencias, las suposiciones y las decisiones que se deben validar antes de confiar en los objetivos.

Convierte los objetivos en un plan de recuperación con responsables y pruebas

Documenta algo más que el RTO y el RPO. Un plan práctico indica quién decide que debe iniciarse la recuperación, quién lleva a cabo cada paso, quién verifica que la aplicación se pueda utilizar y quién se comunica con el personal, los clientes o los socios.

Establece puntos de decisión claros: cómo se detecta un incidente, quién está autorizado para declarar una interrupción, cuándo debe utilizarse una solución alternativa y qué comprobaciones hacen falta antes de reanudar el trabajo normal. Incluye el orden de restauración de las dependencias y el proceso para gestionar el trabajo creado durante la interrupción.

Prueba el plan y registra lo ocurrido. Un objetivo de recuperación es una meta que debe validarse, no una prueba de que la recuperación vaya a cumplirla. Los ejercicios pueden revelar responsabilidades poco claras, accesos que faltan, dependencias pasadas por alto o una brecha entre el objetivo declarado y el proceso de recuperación.

Después de una prueba o de una interrupción real, actualiza los objetivos y los procedimientos cuando sea necesario. Los cambios en los flujos de trabajo, la importancia de los datos, las integraciones o las condiciones operativas pueden hacer que un plan de recuperación anterior deje de ser preciso.

• Asigna responsables de la toma de decisiones, de la recuperación y de las comunicaciones.
• Redacta los pasos de recuperación y el orden de las dependencias con un lenguaje que el equipo de respuesta pueda seguir.
• Define las comprobaciones que confirman que el servicio y el flujo de trabajo empresarial se pueden utilizar.
• Prueba el plan, registra los resultados y haz seguimiento de las carencias pendientes.
• Revisa los objetivos cuando cambien los procesos empresariales o las dependencias de la aplicación.