ES 
PT 
EN 
Todo plan de recuperación se apoya en dos números. El RTO, que es el tiempo máximo aceptable entre la caída y el regreso del servicio, y el RPO, que es la pérdida máxima de datos aceptable, medida en tiempo. Casi toda empresa mediana o grande tiene esos dos números escritos en algún documento.
Lo que casi ninguna puede mostrar es cómo llegó a ellos.
La diferencia importa porque un número sin método no sobrevive al primer incidente. Se definió en una reunión, por consenso, y el día de la crisis se descubre que la arquitectura nunca se dimensionó para cumplirlo, o que el plazo prometido no incluía la mitad del trabajo que exige la vuelta a la operación. Este artículo trata del método: de dónde sale cada número, quién responde por él y cómo verificar que tiene sentido antes de convertirse en compromiso.
Si la duda todavía está un paso atrás, en qué es un plan de recuperación y qué entra en él, el artículo sobre DRP cubre esa capa.
Primero viene el MTD, y no es el RTO
Este es el error más común, y no parece un error.
TI le pregunta al negocio cuánto tiempo aguanta la operación sin el sistema. El negocio responde 72 horas. TI anota un RTO de 72 horas. Todos salen conformes de la reunión.
El número que acaban de definir no es el RTO. Es el MTD.
El NIST SP 800-34 Rev. 1, guía de planificación de contingencia del instituto de estándares estadounidense, separa los dos con claridad. El MTD, Maximum Tolerable Downtime, es el tiempo total de indisponibilidad que el responsable del sistema está dispuesto a aceptar, con todos los impactos considerados. El RTO es el tiempo máximo que un recurso puede quedar indisponible antes de que haya un impacto inaceptable sobre los demás recursos, sobre los procesos de negocio y sobre el propio MTD.
La frase del documento que resuelve la confusión es esta: como el RTO tiene que garantizar que el MTD no se exceda, el RTO normalmente debe ser más corto que el MTD.
El motivo es práctico. Entre que el sistema vuelve a responder y la operación vuelve a funcionar hay trabajo. Los registros hechos a mano durante la caída hay que digitarlos. Las integraciones que quedaron detenidas tienen que procesar la cola acumulada. Alguien tiene que verificar que los saldos cierren antes de liberar la facturación. Ese tiempo no es de TI, pero consume el mismo reloj.
Entonces, si el negocio aguanta 72 horas y la conciliación lleva 24, el RTO es de 48 horas. El ejemplo que el propio NIST usa en su plantilla de análisis de impacto es exactamente ese: proceso de pago a proveedor con MTD de 72 horas, RTO de 48 horas y RPO de 12 horas.
La cuenta es simple. Hacerla en el orden equivocado es lo que produce planes que fallan dentro del plazo prometido.
La pregunta no es sobre el sistema, es sobre el proceso
Lo segundo que atrasa el trabajo es preguntar cuál es el RTO del ERP.
Nadie sabe responder eso, y quien responde está adivinando. El ERP sostiene facturar, comprar, pagar, cerrar el mes y consultar históricos, y esos cinco procesos tienen tolerancias completamente distintas. Facturar no espera un día. Consultar históricos espera una semana sin que nadie lo note.
El NIST organiza el análisis de impacto en tres pasos, y el primero es determinar los procesos de negocio y la criticidad de la recuperación. La unidad de análisis es el proceso, no el servidor. Solo después vienen los recursos que cada proceso consume, y por último el orden de recuperación de esos recursos.
En la práctica esto invierte la conversación. En lugar de listar sistemas y preguntar cuánto aguanta cada uno, se lista lo que la empresa hace, se descubre cuánto aguanta cada actividad, y recién ahí se mapea de qué sistemas depende cada una. El RTO de un servidor pasa a ser consecuencia: es el plazo más ajustado entre los procesos que dependen de él.
El efecto colateral es bienvenido. Cuando el número sale del proceso, deja de ser opinión de TI y pasa a tener dueño en el área de negocio.
Cómo convertir "es crítico" en un número comparable
En la primera ronda, todo es crítico. Eso no es mala voluntad, es falta de escala. Sin una vara común, "crítico" es la única palabra disponible para decir "es importante para mí".
El NIST lo resuelve pidiendo que la organización cree categorías de impacto y les asigne valores, de modo que se pueda medir el nivel de severidad que causaría una caída. El ejemplo del documento usa el costo como categoría, con tres rangos: severo, cuando las horas extra, la contratación temporal y las multas pasan de un millón de dólares; moderado, en el orden de los quinientos cincuenta mil; y mínimo, en el orden de los setenta y cinco mil. La guía es explícita al decir que esas cifras son solo un ejemplo y deben revisarse para reflejar la realidad de cada organización.
El valor de esa vara no está en la precisión. Está en obligar a comparar. Cuando dos áreas tienen que ubicar su propio proceso en la misma escala de dinero, la lista de prioridades aparece sola.
Tres preguntas que funcionan mejor que "es crítico":
¿Qué pasa en la cuarta hora? La pregunta genérica recibe una respuesta genérica. La pregunta con hora marcada recibe un escenario: en la cuarta hora el transportista se va sin cargar, y la entrega se atrasa un día.
¿Existe una forma manual de seguir? Si existe, el MTD es más largo de lo que parecía. Si no existe, es más corto. El NIST pide esa información de forma explícita en el relevamiento, y es la respuesta que más mueve los números.
¿Cuánto tiempo aguanta la forma manual? Un cuaderno y una planilla funcionan por algunas horas. Después de eso, la cola de digitación pasa a ser el nuevo problema, y ese tiempo se descuenta del MTD.
El RPO es una pregunta sobre retrabajo, no sobre backup
El RPO suele tratarse como un parámetro técnico de la rutina de copia. No lo es.
El NIST es directo en dos puntos. El primero: el RPO representa el punto en el tiempo, anterior a la caída, hasta el cual los datos del proceso deben recuperarse, considerando la copia más reciente disponible. El segundo, que casi siempre pasa inadvertido: a diferencia del RTO, el RPO no se considera parte del MTD. Es un factor aparte, de cuánta pérdida de datos tolera el proceso.
Eso tiene una consecuencia práctica. Quien responde el RPO no es quien administra el backup, es quien va a redigitar. La pregunta correcta es cuántas horas de registros puede rehacer el equipo a mano sin frenar el resto del trabajo, y con qué riesgo de error.
Y hay una prueba de honestidad que conviene hacer antes de publicar el número. El RPO no puede ser menor que el intervalo entre las copias. Un RPO de quince minutos con backup nocturno es una intención, no una capacidad. Si el número que el negocio necesita es más corto que la ventana actual, la conversación dejó de ser sobre el número y pasó a ser sobre cambiar la tecnología de copia, que es lo que detalla el artículo sobre backup en la nube .
La prueba de realidad: ¿el número cabe en la tecnología y en el presupuesto?
Definido el MTD por proceso, derivado el RTO y acordado el RPO, falta la parte que el negocio no tiene cómo saber solo: cuánto cuesta cada rango.
El NIST describe esto como un balance de costos. Cuanto más larga la caída, más caro el perjuicio. Cuanto más corto el RTO, más caras las soluciones de recuperación. El documento observa que el punto de equilibrio entre esas dos curvas es distinto para cada organización y cada sistema, porque depende de las restricciones financieras y de los requisitos de operación.
Para convertir eso en orden de magnitud, la documentación de arquitectura de AWS publica los rangos que cubre cada estrategia en REL13-BP02:
- Backup y restauración: RPO en horas, RTO en hasta 24 horas. Con copias continuas y recuperación a un punto en el tiempo, el RPO puede bajar al orden de los cinco minutos.
- Pilot light: RPO en minutos, RTO en decenas de minutos.
- Warm standby: RPO en segundos, RTO en minutos.
- Activo-activo en más de una región: RPO próximo a cero, RTO potencialmente cero.
Esos rangos sirven como verificación, no como catálogo. Si el negocio pidió un RTO de diez minutos y la arquitectura actual es backup y restauración, la distancia no se cubre con esfuerzo el día del incidente. Se cubre con inversión, o el número cambia.
Vale registrar también lo que los proveedores no garantizan. Microsoft afirma en la documentación de su framework de arquitectura que publica garantías de RTO y RPO solo para algunos productos. Para el resto, el número es responsabilidad de quien diseñó la solución, y no del contrato de servicio.
¿Y cuándo no se puede? El NIST prevé el caso: cuando no es viable cumplir el RTO de inmediato y el MTD es inflexible, la situación debe documentarse formalmente, con un plan de acción e hitos para corregirla. Registrar la brecha es una decisión defendible. Escribir un número que nadie puede cumplir no lo es.
El RTO y la meta de disponibilidad tienen que cerrar
Existe una contradicción que aparece en casi todo documento de requisitos y casi nunca se nota, porque los dos números viven en páginas distintas.
En una página está la meta de disponibilidad, normalmente 99,9%. En la otra está el RTO, normalmente algunas horas.
La tabla de objetivos de nivel de servicio del framework de arquitectura de Microsoft muestra lo que permite 99,9%: 43,20 minutos de indisponibilidad por mes, u 8,76 horas por año.
Compare con el RTO. Un solo incidente que consuma un RTO de cuatro horas ya gasta casi la mitad del presupuesto anual de indisponibilidad de una meta de 99,9%. Dos incidentes así en el año revientan la meta, aunque los dos se hayan atendido exactamente dentro del plazo acordado.
No es que uno de los números esté equivocado. Es que faltó el tercero: cuántos incidentes por año supone la meta. Sin él, los dos primeros no se hablan, y la empresa cumple el RTO e incumple la meta en el mismo incidente.
Quién firma el número
En la definición del NIST, el MTD es el tiempo que el responsable del sistema está dispuesto a aceptar. Está dispuesto, en singular. Es una persona, no un comité.
Eso tiene efecto práctico en tres momentos. En la definición, porque alguien tiene que bancar la elección cuando aparece el costo de la arquitectura. En el incidente, porque es quien autoriza el regreso a la operación normal. Y en la revisión, porque el número envejece: un proceso que cambió de volumen, un sistema que ganó una integración nueva, una operación que pasó a atender otro huso horario.
Por eso la planilla de criticidad necesita tres columnas que suelen faltar: el nombre de quien respondió, la fecha de la respuesta y qué dispara una nueva revisión.
Cómo conduce Integrity-UX este trabajo
Empezamos por el relevamiento con las áreas de negocio, proceso por proceso, con la vara de impacto armada antes de la primera reunión. De esa etapa sale el MTD de cada proceso, con dueño y fecha.
Después mapeamos las dependencias de cada proceso y derivamos el RTO por recurso, descontando el tiempo de reprocesamiento y verificación. El RPO se acuerda con quien hace la carga de datos, y se verifica contra la ventana real de las copias.
Con los números cerrados, presentamos lo que cada rango exige de arquitectura y de inversión, y dónde hay brecha entre lo que se pidió y lo que la infraestructura actual entrega. El resultado es una tabla corta, de proceso, MTD, RTO, RPO y estrategia, que cabe en una página y sirve de base para el plan de recuperación.
Próximos pasos
Si su empresa ya tiene RTO y RPO definidos, vale una prueba rápida: tome el número de un proceso e intente responder quién lo definió, en qué fecha, y si descuenta el tiempo de reprocesamiento. Si las tres respuestas no aparecen, el número necesita revisión antes de cualquier inversión en arquitectura.
Para entender dónde entran estos números en el plan completo, el artículo sobre DRP trata la estructura del documento y la frecuencia de prueba. Para la capa de copias, que es donde el RPO se cumple o no, el artículo sobre backup en la nube cubre la retención y la regla 3-2-1.
Si prefiere conversar sobre su caso, la página de DRP tiene el contacto directo.
Preguntas frecuentes
¿Cuál es la diferencia entre MTD y RTO?
El MTD es el tiempo total de indisponibilidad que la empresa acepta para un proceso de negocio. El RTO es el plazo para que el recurso de TI vuelva a funcionar. Como entre que el sistema vuelve y la operación vuelve hay reprocesamiento y verificación, el RTO tiene que ser más corto que el MTD. El NIST SP 800-34 Rev. 1 registra esa relación de forma explícita.
¿Quién define el RTO y el RPO?
El negocio define la tolerancia, y TI traduce esa tolerancia en arquitectura y costo. En la definición del NIST, el MTD es el tiempo que acepta el responsable del sistema, lo que implica una persona con nombre, no un consenso de reunión.
¿El RPO puede ser menor que el intervalo del backup?
No. El RPO está limitado por la copia más reciente disponible. Si la copia es nocturna, el RPO real es de hasta 24 horas, sea cual sea el número escrito en el documento. Reducir el RPO exige cambiar la frecuencia o la tecnología de copia.
¿Cómo definir el RTO si todas las áreas dicen que el sistema es crítico?
Creando una vara de impacto con rangos y valores, como recomienda el NIST, y preguntando por escenarios con hora marcada en lugar de criticidad en abstracto. Cuando las áreas tienen que ubicar sus propios procesos en la misma escala, la priorización aparece.
¿Un RTO de cuatro horas es compatible con 99,9% de disponibilidad?
Depende de cuántos incidentes por año supone la meta. Una meta de 99,9% permite 8,76 horas de indisponibilidad por año, según la tabla de nivel de servicio de Microsoft. Un solo incidente de cuatro horas consume casi la mitad de ese presupuesto.
